本文へスキップ
KNOWLEDGE — SHOPIFY NEWS
Shopifyの販売不可がコミット済みへ｜APIはreservedからcommittedに変更
Shopifyが2026年8月5日、下書き注文と移動・出荷が押さえる在庫の扱いを変えると発表しました。管理画面の「販売不可」にあった分が「コミット済み」へ移り、「手持ち」と「販売可能」は変わりません。壊れる変更ではありませんが、数字の意味が変わります。
Summary
この記事の要点3つ
結論から書きます。売れる在庫は減りません。減るのは「販売不可」という表示上の数字で、その分が「コミット済み」に移ります。
置き場所が変わる
下書き注文と移動・出荷が押さえている在庫は、これまで「販売不可」に入っていました。これが「コミット済み」へ移ります。「手持ち」と「販売可能」は変わりません。ただし下書き注文の押さえは、［在庫を予約］を使ったときだけ発生します。
一度きりなのは移行だけ
押さえ方をコミット済み側に統一する変更は、今後も続きます。データの付け替えだけが一度きりです。
公式が示した対応
押さえを見分けたいなら、今後は「コミット済み」側を見る。これがShopifyの公式推奨です。
Basics
前提：Shopifyの在庫状態と、管理画面での呼び名
Shopifyの在庫は1つの数字ではなく、状態ごとの内訳として管理されます。今回の話は、その内訳のどこに在庫が置かれるかという話です。前提はShopifyの基礎解説にまとめています。
中核はShopifyヘルプセンター「在庫状況を理解する」の次の1行です。「手持ち在庫は、コミット済み、販売不可、販売可能の各在庫の合計で構成されます」。コミット済みと販売不可のあいだで数量が動いても、その合計である手持ちは変わりません。
本記事は管理画面の日本語に合わせ「下書き注文」と書きます。原語は draft order、「移動・出荷」は transfers と shipments です。ヘルプセンター内でも表記は揺れ、「コミット済み」は「引当済み」、「販売不可」は「利用不可」とも書かれています。
| 管理画面の表示 | APIの状態名 | ヘルプセンターの定義（要約） |
|---|---|---|
| 手持ち | on_hand | ロケーションにあるすべての在庫ユニット。コミット済み・販売不可・販売可能の合計にあたる。 |
| 販売可能 | available | 販売できる在庫。どの注文にもコミットされておらず、下書き注文用にも予約されていない。 |
| コミット済み | committed | 注文に含まれているものの、まだ発送されていないユニット数。 |
| 販売不可 | reserveddamagedquality_controlsafety_stock | 4つの状態をまとめた集計。下書き注文用の予約、アプリによる確保、破損・品質管理・安全在庫などを含む。 |
| 仕入れ | incoming | 在庫転送やアプリからロケーションへ向かっている途中の在庫。手持ちには含まれない。 |
販売不可は、この4つをまとめた集計です。根拠はshopify.dev「Manage inventory quantities and states」にあります。同ページはこの4つを「unavailable states」と呼んでいます。
制約も1つあります。shopify.devは、committed の数量をAdmin APIから調整・移動できないと明記しています。動くのは注文の作成とフルフィルメントのときだけです。移行後の見え方を手作業で元に戻すことはできません。直せるのは、値を読む側の解釈だけです。
Numbers
数字で見ると、どう動くか
数値に置き換えると分かりやすくなります。以下は理解のための仮の数値です。公式が示した事例ではありません。下書き注文が8個分の在庫を押さえているストアを想定します。
| 管理画面の項目 | 移行前 | 移行後 |
|---|---|---|
| 手持ち | 100 | 100 |
| 販売可能 | 60 | 60 |
| コミット済み | 30 | 38 |
| 販売不可 | 10 | 2 |
移行前の販売不可10の内訳は、下書き注文の押さえが8、破損や安全在庫が2だとします。移行後は、この8がコミット済みへ移ります。手持ちの100は、どちらの列でもコミット済み・販売不可・販売可能の合計と一致します。移行前は30と10と60、移行後は38と2と60です。物理的な在庫は1つも動いていません。
APIの側では、reserved が8だけ減り、committed が8だけ増えます。残った販売不可の2は破損と安全在庫なので、damaged と safety_stock に入っています。これらは reserved とは別の状態です。したがって、この例では reserved は0になります。アプリによる確保など reserved に残る理由があるストアでは、0にはなりません。
販売不可が減っても、売れる在庫は増えません。販売可能の60は動きません。
Official
公式発表の内容
Shopifyは2026年8月5日、shopify.dev のチェンジログでこの変更を公開しました。区分は Update、対象APIは Admin GraphQL API です。冒頭の1文が趣旨を示しています。原文は「We're consolidating how in-progress inventory holds are represented.」です。進行中の在庫の押さえ方を、どう表現するかを統一する、という説明です。
対象は、変更が走る時点で在庫を押さえたままのアクティブな下書き注文と、オープンな移動・出荷です。要点は次の3点です。
恒久的な変更と、一度きりの移行
原文は「quantities that previously appeared under reserved will now appear under committed」と書いています。引き当て済みで未フルフィルメントの在庫を、すべて
committedが表す形にする、とも説明されています。一度きりだと明記されているのは、その時点の押さえを付け替えるデータ移行のほうです。※今後押さえられる分がどちらに入るかは、チェンジログに直接の一文がありません。上の記述からの読み取りです（FAQで詳述）。合計も販売可能数も動かない
「available and on_hand quantities are unaffected.」と明記されています。さらに、動くのは販売できない側の2つの入れ物のあいだだけだとも書かれています。どちらに入っていても販売可能にはならず、買い手が購入できる数も変わりません。
公式が推奨する読み替え
下書き注文や移動・出荷の押さえを見分ける目的で
reservedに頼っているなら、今後はcommittedを読むべきだと書かれています。これは推奨として明記されたものです。あわせて、既存のクエリを動かし続けるためのコード変更は不要とも記されています。
自社コードのどこを見ればよいかも書かれています。名指しされているのは InventoryLevel. です。これを読んでいるアプリでは reserved が減り、committed が同じだけ増えると説明されています。
レポートについての注記もあります。状態別に調整を出すレポートには、値の移行に加えて一回限りの修正エントリが記録されます。対象は移行時点の下書き注文と移動・出荷に限られ、移行前の履歴データはそのまま残ります。
このチェンジログには、対象プランと対象地域についての記載がありません。記載がないことと「すべてが対象である」ことは別なので、本記事では断定しません。移行が実行される日時の記載もありません。
Who
影響を受けるのは誰か
最初に、大きく振り分けます。下書き注文による在庫の押さえは、自動では起こりません。［在庫を予約］という操作を明示的に行ったときだけ、その在庫が押さえられます。
Shopifyヘルプセンター「下書き注文の作成」にこう書かれています。「アイテムを確保しない場合、数量は「販売可能」な在庫ステータスのままとなり、他のお客様も購入できます」。予約するには、その商品で在庫追跡が有効になっている必要もあります。［在庫を予約］を使っていないストアには、下書き注文由来の押さえがそもそも存在しません。ただし在庫を保持したままの移動・出荷がある場合は、そちらが今回の対象になります。完了・キャンセル・解放済みの押さえは、すでに在庫を押さえていないため対象外です。
押さえが存在するとして、次は読み取り側です。確認が必要なのは、状態別の在庫数量をAPIで取得している仕組みです。受注から出荷までを管理画面で完結させているなら、作業は発生しません。該当するのは次の3つです。
自社開発の連携コード
状態名を指定して在庫数量を取得しているなら、該当します。
基幹・倉庫システム（OMS・WMS）
引き当て済みの在庫を状態別に取得して同期しているなら、同期先の数字が変わります。
在庫連携アプリ
複数チャネルの在庫を状態別に突き合わせている場合は、提供元への確認が要ります。
逆に、available だけを取得している仕組みは影響を受けません。多くの在庫同期は「あと何個売れるか」を知りたいので available を読んでいます。on_hand だけの棚卸し系も同じです。
影響は、壊れるという形では出ません。reserved は有効な数量名のまま残るため、クエリはエラーになりません。返る数が小さくなる、あるいは0になるだけです。エラーが出ないぶん、気づかないまま数字がずれるほうが現実的です。連携コードの改修が必要になった場合の設計はShopifyアプリ開発で扱っています。
Our View
セルフプラスの見解
ここからはセルフプラスの分析です。公式発表に書かれている内容そのものではありません。要点は、これが一過性の出来事ではなく、恒久的な表現の変更だという点です。
1. 一度きりの移行として片づけると、判定が狂ったままになります。「一度きりのデータ移行」という表現だけを読むと、過ぎ去った出来事に見えます。実際には、今後作成する下書き注文も committed に入ります。reserved を読んで押さえの数を数えていた処理は、予約の運用を続けるかぎり、実態より小さい値を返し続けます。読み替えは一度で済みますが、やらなければずっと外れたままです。
2. 状態別の数量を読む設計は、そもそも追従コストを抱えています。今回の変更では、フィールドの削除も改名もありません。それなのに、返る数字の意味だけが変わります。この形の変更は、型チェックでもテストでも検知できません。設計指針としては、在庫連携の軸を available に置くことをおすすめします。状態別の数量を読むのは、本当に必要な業務だけに絞ってください。
3. レポートと履歴には段差が入ります。状態別の数量を日次で記録していると、移行のタイミングで販売不可が落ち、コミット済みが上がります。実態が変わっていないのにグラフが動くため、事情を知らない担当者が異常として扱う恐れがあります。移行に気づいた日付の注記を1行残しておくと、後日の調査が1回減ります。
これは「今すぐ直さないと危ない」種類の変更ではありません
フィールドの削除も改名もなく、クエリがエラーになることもありません。販売できる在庫も減りません。それでも本記事で扱ったのは、値の意味が変わることに気づかないまま運用が続く形になりやすいためです。期限が切られた移行ではないので、急いで着手する必要はありません。
Scope
適用範囲と限界
本記事が断定していないことを、行動に移る前に明示します。対象プランと対象地域は、チェンジログに記載がありません。実行日時の記載もありません。
プランと地域は「記載がない」だけで、対象範囲は確認できていません
チェンジログにはプラン別・地域別の条件が書かれていません。書かれていないことを「制限がない」と読み替えるのは推測になります。ShopifyとShopify Plusで扱いが分かれるかどうかも、公式には確認できていません。自社が該当するかどうかは、管理画面の在庫内訳と、APIが返す実際の値で確かめるのが最も確かです。
ヘルプセンター（日本語）は、このチェンジログを反映していません
ヘルプセンターの日本語ページは、2026年8月13日に確認した時点で、変更前の挙動をそのまま説明しています。本記事は2026年8月5日付のチェンジログに従います。ヘルプセンターの「コミット済み」の定義には、次の一句が含まれます。「下書きが注文になるまでコミット済み在庫としてカウントされません」。同じ趣旨の記述が、同ページ内に2箇所あります。チェンジログを採る理由は、日付が新しく、変更を告知した一次情報そのものだからです。ヘルプセンターの記述が誤りだという意味ではなく、まだ反映されていないという意味です。
完了の判定方法や、対象となった下書き注文の件数は公表されていません。本記事では推測しません。管理画面の表示も、ストアの設定や画面の版によって異なる可能性があります。
Action
明日から何をすべきか
まず切り分けます。受注から出荷までを管理画面だけで完結させ、［在庫を予約］も使っていないストアなら、この発表のための作業はありません。以下は、状態別の在庫数量をAPIで読んでいるか、［在庫を予約］を運用しているストア向けです。1と2は見るだけです。3は本番ストアのデータを変える操作なので、末尾の注意を先に読んでください。
今の内訳を控える
対象になる商品を数点選びます。［在庫を予約］した下書き注文がある商品と、在庫を保持したままの移動・出荷がある商品です。商品ページの在庫カードで「販売不可」と「コミット済み」の数をスクリーンショットに残します。移行がまだ走っていなければ、これがそのまま移行前の記録になります。商品ページの在庫カードには過去の内訳が残らないため、先に控えておく価値があります。状態別の在庫調整レポートを取っている場合は、そちらでも追えます。
在庫調整レポートで修正エントリを探す
移行が走ると、在庫調整レポートに一回限りの修正エントリが記録されます。実行済みかどうかを直接確認できる手がかりです。管理画面の［分析］＞［レポート］を開き、［カテゴリー］フィルターで［在庫］に絞り込みます。Shopifyヘルプセンター「在庫レポート」によれば、この中の「在庫調整の変更」レポートが、期間内の調整を状態別に表示します。記録があれば実行済み、なければ未実行か、対象の在庫が無かったかです。閲覧にはスタッフに「ストア分析」の権限が要ります。レポートが見当たらない場合は、次の3の結果で判断してください。
テスト用の下書き注文で［在庫を予約］まで行う
状態別の在庫数量をAPIで読んでいる場合のみ、ここまで進んでください。管理画面の表示が変わるだけなら、1と2で足ります。これは本番ストアのデータを変える操作です。実施前に、下の副作用の注意を先に読んでください。在庫に余裕のあるテスト商品を1つ決め、下書き注文に追加したうえで、［…］＞［在庫を予約］を実行します。予約の有効期限を選んで完了すると、そこで初めて在庫が押さえられます。この操作をしないと在庫は販売可能のままで、何も動きません。結果の読み方は3通りです。コミット済みが増えたなら、今後の押さえはコミット済み側に入ります。販売不可が増えたなら、自社ではまだこの変更が適用されていない可能性があります。どちらも動かないなら、その商品で在庫追跡が無効か、予約の操作ができていません。
コードとベンダーに当たる
自社開発の連携コードは、
InventoryLevel.の形で検索するのが最短です。外部のシステムやアプリは、提供元へ「在庫数量をどの状態名で取得しているか」をそのまま質問してください。quantities(names: ["reserved"]) availableしか使っていないという回答であれば、確認はそこで終わりです。判定条件を決め直す
reservedを「下書き注文で押さえられている数」として使っていた処理は、判定の根拠を変える必要があります。committedに切り替えるだけでは、確定した注文の引き当てと下書き注文の押さえが同じ数字に混ざります。両者を区別する必要があるなら、在庫の状態ではなく注文側のデータを見てください。区別が要る業務なのかどうかから、担当者と決めるのが早道です。
3を本番ストアで行うときの副作用
予約している間は、その分の在庫が売れなくなります。在庫に余裕のある商品を選び、確認が終わったら下書き注文を削除して押さえを解放してください。作成した下書き注文は、ほかのスタッフからも見えます。さらに、この操作自体が在庫調整レポートに記録として残ります。レポートのグラフが動いて異常と誤解される、という先ほどの話と同じです。実施した日付と目的を共有しておくと安全です。開発ストアがあるなら、そちらで試すのが安全です。
自社の連携が該当するかどうかの切り分けだけでも、無料相談で持ち込んでいただいて構いません。
FAQ
この発表に関するよくあるご質問
今後作成する下書き注文は、販売不可とコミット済みのどちらに入りますか。
コミット済みです。ただし、チェンジログに直接そう書かれた一文はありません。「今後は committed に現れる」「引き当て済みの在庫すべてを committed が表す」「今後は committed を読むべき」。この3つの記述からの読み取りです。
在庫レポートや過去の在庫履歴の数字も変わりますか。
在庫調整レポートには、移行にともなう一回限りの修正エントリが記録されるとチェンジログに書かれています。対象は移行時点の下書き注文と移動・出荷だけです。移行前の履歴データはそのまま残り、手持ちと販売可能の合計も変わりません。
移行はいつ実行されますか。もう終わっているのですか。
チェンジログに実行日時の記載はありません。原文は when the change runs という書き方で、完了を示す表現も使われていません。本記事も完了したとは書きません。実行済みかは在庫調整レポートの修正エントリで確かめられます。見当たらない場合はテスト用の下書き注文で確かめます。
複数ロケーションのストアでは、どのロケーションの数字が動きますか。
在庫の状態はロケーション単位で管理されます。これは shopify.dev の在庫オブジェクトの構造によるもので、チェンジログはロケーションに触れていません。内訳が動くのは、その在庫を押さえているロケーションだけです。
販売不可が0になったら、売れる在庫が増えたということですか。
違います。チェンジログは、数量が販売できない状態どうしのあいだを移動するだけだと明記しています。販売可能の数量は影響を受けず、買い手が購入できる数も変わりません。物理的な在庫が増えたわけでもありません。
関連する仕様変更もあわせてご覧ください。注文API側の挙動変更はShopifyの配送先変更で税を再計算にまとめました。商品データ側はShopifyコレクションのマルチソース・バリアント対応で整理しています。
