Physical inventory feature preview 倉庫の「棚」を API で扱えるようになる

図解 ： Shopify Physical inventory feature preview（bins / counts / purchase orders の新 API） Developer Changelog / フィーチャープレビュー Physical inventory feature preview 倉庫の「棚」を API で扱えるようになる bins（棚・ラック）／ counts（棚単位の在庫数セット）／ purchase orders（発注データの読み取り）という 3 つのプリミティブが、GraphQL Admin API の unstable バージョンに先行公開。開発ストアでフィーチャープレビューを有効にしたときだけ叩ける。 このページの構成 30秒で理解 ： 何が公開されたのか 3つのプリミティブ（bins / counts / purchase orders） データ構造の図解 ： Location と Bin の関係 有効化の手順（3ステップ） できること／記事に書かれていないこと 技術者が押さえるべき5つのポイント 業務に活かせる3つのユースケース 提案で使える1行サマリ 1 30秒で理解 ： 何が公開されたのか これまで Shopify の在庫 API が扱えたのは「ロケーション単位の在庫数」まで。 今回のフィーチャープレビューでは、その一段下 —— マーチャントが実際に倉庫（stockroom）を整理するときに使う単位 、 つまり 棚（bins） ・ 棚単位の棚卸し（counts） ・ 発注（purchase orders） が API のプリミティブとして触れるようになる。 公開先は unstable GraphQL Admin API の unstable バージョンにのみ載っている。 まだ活発に開発中 のため、安定版になる前にスキーマと挙動へフィードバックを返せる、という位置づけ。 開発ストアで有効化して使う development store（または既存ストア）で「Physical inventory feature preview」を ON にして、そこに対してビルド・テストする。 未有効ストアは弾かれる プレビューを有効にしていないストアからの呼び出しは access error を返す。全ストアで一律に使える機能ではない。 2 3つのプリミティブ 記事で「What's included」として明示されているのは以下の 3 つ。 Bins 棚 ： ロケーション内の名前付き保管場所 「棚（shelf）」「ラック（rack）」のような、 ロケーションの中の保管場所 を名前付きで表現する。作成・更新ができ、 各 bin が持つ on-hand 数量を読み取れる 。 Counts 棚卸し ： bin 単位で on-hand をセット inventoryCountCreate ミューテーションで、 特定の bin にある特定の在庫アイテムの on-hand 数量をセットする 。加減算ではなく「その棚の実数はこれ」と確定させる操作。 Purchase orders 発注 ： 読み取りのみ GraphQL Admin API 経由で発注データを read できる。取得対象として明示されているのは purchase order 本体 ／ その line items ／ その supplier（仕入先） 。 非対称に注意。 bins は「作成・更新・読み取り」、counts は「セット（作成）」、purchase orders は 「読み取り」だけ が記事に書かれている。発注の作成・更新については 記載なし 。 3 データ構造の図解 ： Location と Bin の関係 bin が既存のロケーション在庫とどう統合されるか の具体例・詳細は、記事本文には書かれておらず「Physical inventory feature preview guide」を参照、とされている。 つまり「location の on-hand と bin の on-hand の整合はどう取られるか」は、 本記事だけでは判断できない（記載なし） 。ガイド側で必ず確認すること。 4 有効化の手順（3ステップ） 1 開発ストアを用意 development store を新規作成、もしくは既存のものを使う。 2 フィーチャープレビューを ON そのストアで「Physical inventory feature preview」を有効にする。 3 アプリを unstable に向ける physical inventory 系の query / mutation は すべて unstable バージョンで叩く設定にする。 3 ステップ目がポイント。 「physical inventory のクエリ／ミューテーションだけ unstable」 という切り分けが必要になるので、既存の安定版クライアントと共存させる構成をあらかじめ考えておくと後が楽。 5 できること／記事に書かれていないこと 項目 記事の記述 読み取れること bins 明記 作成・更新・on-hand 読み取り 棚マスタを外部から構築・同期できる counts 明記 inventoryCountCreate で bin 内アイテムの on-hand をセット 棚卸し結果の書き戻しが可能 purchase orders 明記（read のみ） PO 本体 / line items / supplier 入荷予定の参照はできる。書き込みは 記載なし API バージョン unstable のみ 安定版リリース時期は 記載なし 。破壊的変更は前提 対象ストア プレビュー有効ストアのみ。未有効は access error 本番ストアでの利用可否は 記載なし （案内は development store 前提） bin と既存 location 在庫の統合 ガイド参照とだけ記載 本文中には 記載なし 。ガイドで要確認 bin の階層・容量・対応プラン — 記載なし 6 技術者が押さえるべき5つのポイント 1. unstable = スキーマが動く前提で組む 「under active development」と明言されている。フィールド名・引数・戻り値が変わりうるので、 アプリ側に薄いアダプタ層 を挟み、ドメインモデルを API 形状に直結させないのが安全。 2. access error はストア単位の分岐条件 プレビュー未有効ストアからの呼び出しは access error。マルチストアに配布するアプリなら、 「physical inventory 機能が使えるストアか」を実行時に判定して UI を出し分ける 設計が要る。 3. count は「セット」であって「増減」ではない inventoryCountCreate は「特定 bin の特定アイテムの on-hand を設定する 」と書かれている。差分加算 API ではないため、 スキャン結果を積み上げてから最終値を投げる クライアント側の集計が必要になる。 4. purchase orders は read 専用として設計する 記事が挙げているのは read のみ。 発注の起票・更新を Shopify 側に持たせる前提の設計は現時点では立てられない 。発注のマスタは引き続き外部（基幹・WMS）側に置き、Shopify からは参照するのが無難。 5. 今フィードバックを出せる、というのがこのプレビューの本題 記事は「安定版になる 前に スキーマと挙動へフィードバックできる」ことを目的として明示している。日本の 3PL / 倉庫運用（ロケーション命名規則、ロット・賞味期限、棚移動）で足りない要素があるなら、 安定版が固まる前に検証して出すのが最もコスパの良い動き 。逆に言えば、今のスキーマを本番前提で作り込むのは早い。 7 業務に活かせる3つのユースケース USE CASE 1 倉庫の棚レイアウトを Shopify 側にコード化して持たせる PoC 課題 ロケーション単位でしか在庫が見えず、「どの棚にあるか」は現場のスプレッドシートや WMS にしか無い。ピッキング指示を出すたびに人が突き合わせている。 打ち手 開発ストアでプレビューを有効化し、既存の棚マスタ（棚番号・ラック名）を bins として作成・更新する API 連携を実装。各 bin の on-hand を読み取って可視化するところまで作る。 効果 「Shopify を在庫の正本にできるか」を、安定版を待たずに実データ構造で検証できる。PoC の成果をそのままフィードバックに回せる。 技術メモ bins は create / update / read が明示されている唯一の完全なプリミティブ。ただし bin と既存 location 在庫の統合仕様は本文に記載なし（ガイド参照）なので、そこを最初に潰す。 USE CASE 2 ハンディ端末での棚卸しアプリを、棚単位の実数入力で作る 課題 棚卸しがロケーション単位の総数入力しかできず、差異が出たときに「どの棚でズレたか」が追えない。原因調査に毎回時間がかかる。 打ち手 bin を選択 → 商品をスキャン → 実数を inventoryCountCreate で bin 単位に確定、という棚卸しフローを実装。棚ごとの確定履歴を残す。 効果 差異の発生源が棚レベルまで絞り込める。棚卸し作業を分割して並行実施できるようになり、締めの時間短縮につながる。 技術メモ counts は「on-hand をセットする」操作。スキャンごとに叩くと後勝ちで壊れるので、 端末側で棚ごとに集計を確定させてから 1 回投げる 設計にする。オフライン時のキューイングも要検討。 USE CASE 3 入荷予定ダッシュボード ： 発注データを読んで現場に見せる 課題 「何がいつ、どの仕入先から、いくつ入ってくるか」が発注担当者の手元にしかなく、倉庫側は入荷当日まで準備できない。 打ち手 purchase orders を GraphQL Admin API で読み取り、PO・line items・supplier を組み合わせた入荷予定ビューを作る。受け入れ先の bin と突き合わせて表示する。 効果 倉庫側が事前に受け入れスペースと人員を計画できる。仕入先別の入荷傾向も同じデータから見える。 技術メモ read のみが明示されているため、 ステータス更新や入荷検収の書き戻しは想定しない 。書き込みが必要ならその要件こそフィードバックとして Shopify に返す価値がある。 8 提案で使える1行サマリ 「Shopify の在庫が、ついに ロケーションより下の『棚』単位 で API から触れるようになる先行公開。 bins は作成・更新・読み取り、counts は棚単位の実数セット、purchase orders は読み取り。 まだ unstable かつ開発ストアでの有効化が前提なので、 今は本番導入ではなく PoC とフィードバックのフェーズ 。」 source ： shopify.dev / changelog / physical-inventory-feature-preview published 2026-07-17