下書き注文・移動／出荷の在庫が reserved から committed へ引っ越す

図解 ： 下書き注文・移動／出荷の在庫が reserved から committed へ移行 Developer Changelog / 在庫 API 下書き注文・移動／出荷の在庫が reserved から committed へ引っ越す 「確保済みだがまだフルフィルされていない在庫」を committed に一本化する一度きりのデータ移行。available と on_hand は変わらず、購入可能数にも影響なし。フィールドの削除・改名も無し。 このページの構成 30秒で理解 ： 何が起きるのか 図解 ： 在庫バケットの内訳と移動 移行の対象になるもの／ならないもの 変わらないもの（ここが安心材料） アプリ開発者がやること レポートへの影響 技術者が押さえるべき5つのポイント 業務に活かせる3つのユースケース 提案で使える1行サマリ 1 30秒で理解 ： 何が起きるのか 「進行中の在庫ホールド」の表現方法を Shopify が統合する。 これまで 下書き注文・移動・出荷 のホールドは reserved に計上されていたが、これが committed に移される。 注文の在庫はもともと committed なので、 「確保済みだが未フルフィル」= committed という一本の意味に揃う。 これまで ： 意味が2つに割れていた 注文由来のホールドは committed、下書き注文・移動・出荷のホールドは reserved。同じ「押さえてある在庫」なのに読む場所が分かれていた。 これから ： committed に一本化 committed が「売約済みだがまだフルフィルされていない在庫すべて」を表す。下書き注文・移動・出荷のホールドもここに合流する。 これは 一度きりのデータ移行（one-time data migration） 。継続的に走り続ける処理ではなく、移行が走った時点のデータを付け替える性質のもの。 移行の実施日時・対象ショップの通知方法については 記載なし 。 2 図解 ： 在庫バケットの内訳と移動 ポイントは「 2 つの unavailable バケットの間で数量が移動するだけ 」ということ。総在庫は変わらず、購入者が買える数（available）も変わらない。 3 移行の対象になるもの／ならないもの 対象 移行される アクティブな下書き注文 （active draft orders） オープンな移動／出荷 （open transfers / shipments） いずれも 移行実行時点でまだ在庫をホールドしているもの に限られる。 対象外 変更されない 完了済み（completed）のホールド キャンセル済み（cancelled）のホールド すでに解放済み（already-released）のホールド これらは もう reserved 在庫を保持していない ため、そもそも動かす対象が無い。 「移行実行時点」という条件があるため、 移行の前後で下書き注文を作ったか閉じたかによって、どちらのバケットに乗るかが分岐する 。移行の具体的な実行タイミングは 記載なし のため、期間をまたぐ集計は注意。 4 変わらないもの（ここが安心材料） 項目 影響 内容 available / on_hand 影響なし 数量は一切変わらない。総在庫も不変で、動くのは 2 つの「unavailable」バケットの間だけ。 quantity name 両方とも有効 reserved も committed も、引き続き有効でクエリ可能な名前として残る。 フィールド定義 削除・改名なし API のフィールドは削除も改名もされない。スキーマ破壊は発生しない。 販売可能在庫 影響なし 買い手が購入できる数量は変わらない。ストアフロント側の見え方は変化しない。 既存クエリの動作 コード変更不要 クエリを動かし続けるためのコード修正は不要。 返る「値」だけが 2 つの状態の間でシフトする 。 移行前の履歴データ そのまま 移行以前の historical data は as-is で保持される。 5 アプリ開発者がやること 1 reserved 参照箇所を洗い出す InventoryLevel.quantities(names: ["reserved"]) を読んでいる箇所を全部リストアップする。 2 用途で仕分ける 「下書き注文／移動・出荷のホールドを検知する目的」で reserved を見ているものが対象。 3 committed を読むよう切り替える 該当箇所は今後 committed を読む。それ以外はコード変更不要。 読み替えの早見表 あなたのアプリがやっていること 移行後に起きること 対応 quantities(names: ["reserved"]) を読んでいる 影響ショップで reserved の値が減り 、その分 committed が増える 要確認 値の変動を前提にロジックを見直す reserved を使って下書き注文／移動・出荷のホールドを特定している その情報は reserved から消える 要変更 今後は committed を読む クエリが動き続けるかを心配している クエリ自体は壊れない 対応不要 コード変更は required ではない available / on_hand ベースで在庫連携している 何も変わらない 対応不要 静かに壊れる型のリスク ： クエリはエラーを出さず、返る数字だけが変わる。reserved の値でアラート閾値や在庫同期の判定をしているアプリは、 例外ではなく「数字がおかしい」という形 で表面化する。 6 レポートへの影響 在庫状態別のレポートを見ている場合 在庫の調整レポート（在庫状態ごとに調整を分解するタイプ）を使っているマーチャントには、 reserved の値が committed に移る様子 がそのまま表示される。 一度きりの補正エントリが出る 移行が走ったタイミングで one-time correction entry が記録される。対象は移行時点でアクティブな下書き注文とオープンな移動／出荷のみ。 on_hand と available の合計は変わらない 。そして移行前の履歴データは書き換えられずそのまま残る。つまり「棚卸しの数字が過去に遡って変わる」ことは起きない。 7 技術者が押さえるべき5つのポイント 1. スキーマ破壊ではなく「意味の統合」 フィールドの削除も改名も無く、reserved / committed のどちらもクエリ可能なまま。壊れるのは型ではなく 「reserved = 下書き注文のホールド」という暗黙の前提 のほう。 2. 合計は保存される（ゼロサム移動） unavailable の内訳が変わるだけで on_hand は不変。 reserved + committed の合計で見ている集計なら影響ゼロ 。逆に単独で見ている箇所だけが動く。 3. 移行の「実行時点」がスナップショット 対象は実行時点で在庫をホールド中のものだけ。完了・キャンセル・解放済みは対象外。 移行日時の明示は記載なし なので、日次バッチの差分検知は一時的に跳ねる可能性を織り込む。 4. レポートに補正エントリが1本入る 在庫調整レポートに一度きりの correction entry が現れる。 「原因不明の調整が入った」と誤読されやすい ので、BI 側の異常検知ルールを持っているなら事前に周知しておく。 5. 参照すべきは InventoryLevel.quantities(names:) と InventoryQuantity 影響範囲の中心は InventoryLevel の quantities(names: [...]) フィールドと、name ごとに返る InventoryQuantity オブジェクト。 どの API バージョンから適用されるか、対象ショップの判定条件は記載なし — 影響有無は自分のストアで実測して確認する。 8 業務に活かせる3つのユースケース USE CASE 1 受託アプリ・カスタム連携の「reserved 依存」棚卸し 課題 自社／顧客向けに作った在庫連携アプリが quantities(names: ["reserved"]) を読んでおり、移行後に値が黙って減る。エラーは出ないので気付けない。 打ち手 コードベースを "reserved" で全文検索 → 用途を「ホールド検知」と「単なる合計表示」に仕分け → 前者だけ committed 参照に切り替える。 効果 下書き注文・移動・出荷のホールドを取りこぼさずに検知し続けられる。クエリ自体の書き換えは不要なので改修は最小で済む。 技術メモ コード変更は「動かし続けるため」には不要で、必要なのは「意味を保つため」。両方の name が有効なままなので、 names: ["reserved","committed"] で両方取って比較しながら段階移行できる。 USE CASE 2 BI ダッシュボード／在庫レポートの「段差」を事前に説明する 課題 在庫状態別の調整レポートや BI 上の reserved 系グラフが、ある日を境に急落＋見慣れない補正エントリが 1 本入り、現場が「在庫事故か」と騒ぐ。 打ち手 移行が起きうる旨と「reserved → committed の付け替え＋一度きりの補正」であることを事前に共有し、ダッシュボードに注記を入れる。異常検知ルールを持つなら閾値を一時緩める。 効果 問い合わせ・緊急調査の空振りを回避。 on_hand と available は不変・履歴も as-is と言い切れるので、説明コストが小さい。 技術メモ 補正エントリの対象は移行時点でアクティブな下書き注文とオープンな移動／出荷に限られる。移行前の historical data は変更されないので、期間比較の基準線そのものは動かない。 USE CASE 3 「売約済み在庫」を1クエリで把握する運用への集約 課題 「押さえてあるがまだ出ていない在庫」を出すのに、注文分は committed、下書き注文・移動・出荷分は reserved と 2 か所を足し合わせるロジックを持っていた。 打ち手 移行後は committed ひとつで「spoken for but not yet fulfilled」を表せるため、集計ロジックを 1 本化する。 効果 受注残・引当在庫のレポート定義がシンプルになり、状態の取りこぼしによる数値ズレの原因が 1 つ減る。 技術メモ 切り替えは移行が実際に走った後に行うこと。移行前は下書き注文分が committed に入っていないため、先行して committed 単独に寄せると過小計上になる。移行日時は 記載なし のため、両方の値を並べて監視しながら切り替えるのが安全。 9 提案で使える1行サマリ 「下書き注文・移動・出荷の在庫ホールドが reserved から committed へ一度きりで移行 し、 committed が『売約済み・未フルフィルの在庫すべて』に統一される。 available / on_hand は不変、フィールドの削除も改名も無く、クエリは壊れない。 やることは『reserved でホールドを検知していた箇所を committed に読み替える』だけ。」 source ： shopify.dev / changelog / draft-order-and-transfer-shipment-inventory-is-moving-from-reserved-to-committed 関連ドキュメント ： InventoryLevel ／ InventoryQuantity published 2026-08-05