在庫データを補充プロダクトにする：欠品アラートから発注ワークフローまで

在庫が10を下回ったらアラートを出す。一見、最も単純なデータプロダクトです。しかし本番で運用を始めると、チームからはすぐに質問が出ます。どの倉庫か、どのバリエーションか、販売可能在庫か手持ち在庫か、引当済みの注文数量は含めるのか、輸送中の在庫はいつ届くのか、どれだけ発注するのか、どのサプライヤーに発注するのか、推奨は実行されたのか。数値が欠品や受注残を減らせるのは、購買や在庫移動のワークフローに組み込まれたときだけです。

r/InventoryManagementの複数プラットフォームの在庫管理に関するスレッド（https://www.reddit.com/r/InventoryManagement/comments/1uq9l7k/how_do_you_all_keep_inventory_straight_across/）では、記憶や古いスプレッドシートを頼りに複数チャネルを管理した結果、同じ在庫を複数の注文に引き当ててしまうセラーの状況が語られています。投稿や返信は個々の状況を反映したものであり、特定のソフトウェアが自動的に問題を解決することを証明するものではありません。そこから得られる有益な問いは次のとおりです。どのシステムの在庫数を正とするのか、チャネルの識別子をどうマッピングするのか、更新に失敗したときに誰へ通知するのか。

予測の検討に先立つ在庫オブジェクトの定義

チャネルをまたぐと、同じ現物商品に社内SKU、プラットフォームの出品ID、商品ID、バリエーションID、バーコードが付いていることがあります。色、サイズ、入り数、セット商品の構成を誤って対応付けると、システムは誤った数値をかえって速く同期してしまいます。初期バージョンでは、販売予測モデルをいきなり学習させる前に、人の手で検証できる商品マスターデータを整備すべきです。

最小限の在庫キーには通常、在庫アイテム、バリエーション、ロケーション、数量状態が必要です。Shopifyの数量と状態の管理ガイド（https://shopify.dev/docs/apps/build/orders-fulfillment/inventory-management-apps/manage-quantities-states）でも、ProductVariant、InventoryItem、InventoryLevel、Locationを別々のオブジェクトに分けています。チャネルの出品は販売の入り口であり、そのまま社内の商品主キーにすべきではありません。マッピングテーブルには、誰がデータを確認したか、いつ有効になったか、1対多の関係かどうか、さらにセット品の分解時、バンドル品、代替品の数量をどう計算するかを記録する必要があります。

ShopifyのInventoryLevelリソース（https://shopify.dev/docs/api/admin-graphql/latest/objects/InventoryLevel）は、在庫を特定のロケーションにおける在庫アイテムの数量として表し、販売可能、手持ち、輸送中、引当済みといった状態を個別の数量状態として扱います。このモデルがすべてのプラットフォームを代表するわけではありませんが、ロケーションと状態の情報がなければ「このSKUは8個ある」という記述は不完全だとよくわかります。

販売可能在庫・手持ち在庫・引当済み在庫・輸送中在庫を単一の現在庫にまとめられない理由

Shopifyの在庫アプリガイド（https://shopify.dev/docs/apps/build/orders-fulfillment/inventory-management-apps）では、incoming、on_hand、available、committed、reserved、damaged、safety_stock、quality_controlといった状態を区別しています。on_handは物理ロケーションにある総数量を表しますが、その一部は引当済み、予約済み、破損、品質検査待ちの場合があり、すべてを新規注文の受付に使えるわけではありません。

補充プロダクトでは、少なくとも4つの業務指標を表示する必要があります。今すぐ販売可能な数量、既存注文に引当済みの数量、物理的な在庫数量、そして販売可能になる予定時期を含む輸送中数量です。プラットフォームがその一部しか提供しない場合は、引き算でもっともらしく正確な実在庫を導き出そうとするのではなく、カバー範囲を明示してください。

安全在庫は、ユーザーに見えない形で販売可能数量から差し引く固定値ではありません。プロダクトでは、安全在庫のルール、適用ロケーション、有効期間をユーザーが確認できるようにすべきです。販促期間、供給の変動、新商品の立ち上げ期には異なるバッファが必要になることがあり、自動調整を行う場合は理由と操作の監査ログを残す必要があります。

イベント更新と定期照合の併用

注文、キャンセル、返金、入荷、移動、棚卸はいずれも在庫を変動させます。イベント駆動の同期はレイテンシを減らしますが、定期的な全件照合の代わりにはなりません。Webhookには遅延、重複、順序の入れ替わり、欠落が起こり得ますし、チャネルが一部の状態についてしかイベントを送信しない場合もあります。

Shopifyの公式ドキュメントには、committed、reserved、damaged、safety_stock、quality_controlなどの状態が変更されても、対応する在庫Webhookは発火しないと記載されています。inventory_levels/updateを購読するだけでは、状態変更を完全には把握できません。プロダクトでは、各ソースの機能に応じて補完的なクエリと照合サイクルを設計する必要があります。

各在庫イベントでは、ソースイベントID、品目マッピング、ロケーション、状態、増減数量、ソースのタイムスタンプ、受信タイムスタンプ、処理結果を保持すべきです。冪等キーで二重減算を防ぎ、バージョンまたは時刻に基づくルールで処理順序の入れ替わりに対処し、定期的なスナップショットで累積イベントと現在のソース値との差異を検出します。

同期の失敗は例外キューに回す必要があります。あるチャネルの更新が成功し、別のチャネルで失敗した場合に、全体として成功と報告してはいけません。サイト内のAPIエラーと自己修復に関するガイド（https://everyinfra.com/build/api-errors-self-healing）は、レート制限、タイムアウト、権限の問題、無効なマッピング、ソース側のエラーを区別し、それぞれを具体的なリトライ手順や手動対応手順に対応付けるのに役立ちます。

欠品アラートから説明可能な補充推奨への進化

固定しきい値は、非常に安定した小規模な運用には適していますが、リードタイム、販売速度の変化、既発注分、最小発注数量を考慮できません。説明可能な補充推奨では、少なくとも次の内容を示します。使用した販売期間、現在の販売可能在庫と輸送中在庫、想定リードタイム、目標在庫日数、仕入先の制約、推奨数量です。

数式をAIの提案の裏に隠さないでください。予測モデルを使う場合でも、ユーザーは主要な入力値と感度指標を確認できる必要があります。リードタイムが7日から21日に変わると推奨がどう変わるのか、外挿すべきでないプロモーション時の販売データを誰が除外できるのか、履歴データのない新商品にはどのような初期仮定を適用するのか、といった点です。

補充候補は3つのカテゴリに分かれます。

• 即時対応：現在の販売可能在庫、引当、輸送中の注文、リードタイムに基づき、補充が届く前に欠品が発生すると予測されます。
• 要確認：販売データまたはリードタイムのデータが不足しており、システムが不足しているフィールドを一覧表示し、確認担当者の候補を提示します。
• 補充不要：在庫が十分にある場合、輸送中の在庫で需要をまかなえる場合、または商品が廃番もしくは在庫処分中の場合です。

「補充不要」は恒久的なステータスではありません。推奨には生成日時、使用した在庫バージョン、失効条件を含め、大口注文や供給遅延が発生した際、または実地棚卸しが行われた際には再計算する必要があります。

補充プロダクトの最終到達点となる購買ワークフロー

アラートを受け取った後も、購買担当者は仕入先の選定、最小発注数量と梱包の確認、予算申請、発注書の作成、出荷の追跡、入荷と品質検査の管理を行う必要があります。プロダクトが在庫残量低下のメールを送るだけでは、ユーザーは結局、複数のシステムにまたがる同じ情報の照合に時間を費やすことになります。

発注候補カードには、品目、ロケーション、欠品予測日、推奨数量、輸送中で未完了の注文、仕入先とリードタイム、算出根拠、例外項目を含めることができます。自動で発注するのではなく、指定された担当者が確認した時点で購買タスクを生成します。自動発注は財務面と在庫面のリスクを生むため、権限付与、上限、ロールバックの設計を組み込んだ別の機能として開発すべきです。

入荷したからといって、すべてがすぐに販売可能になるわけではありません。数量差異、破損、品質検査のステータスを書き戻し、発注書の分納では未納残を管理し続ける必要があります。全体のサイクルは、提案、承認、発注、輸送中の追跡、入荷、販売可能化、事後分析であり、通知をクリックして終わりではありません。

データオブジェクトとステータスインターフェースについては、サイト内の統合データAPI設計ガイド（https://everyinfra.com/build/unified-data-api-guide）を参照してください。外部の商品価格も同時にモニタリングする場合は、補充の意思決定を価格モニタリングのサブスクリプション型プロダクト（https://everyinfra.com/blog/price-monitoring-subscription-product）と切り分けてください。価格の変化は購買判断に影響し得ますが、社内の在庫や供給の記録の代わりにはなりません。

複数倉庫・複数チャネル構成には明示的な引当ルールが必要

全社ベースで在庫があっても、特定の拠点での出荷能力が保証されるわけではありません。補充システムはまず、調達よりも在庫移動のほうが有利かどうかを判断すべきです。具体的には、他の倉庫に移動可能な在庫があるか、輸送日数とコストはどの程度か、移動によって別の拠点で新たな欠品が生じないかを確認します。在庫移動の推奨と発注の推奨では、必要なアクションも承認フローも異なります。

チャネルへの在庫配分にも同様にルールが必要です。総販売可能数をすべてのチャネルに同期すると過剰販売のリスクがあり、チャネルごとに固定の配分を設定すると在庫が滞留する恐れがあります。共有プール、チャネル上限、安全バッファーを設定することはできますが、プロダクト側では現在の戦略と直近の同期状況を表示する必要があります。リアルタイム運用でも同時注文、ネットワーク遅延、プラットフォーム側の処理時間は避けられないため、過剰販売ゼロを約束すべきではありません。

セット商品やまとめ売り商品では、注文イベントを構成品の消費量に変換する必要があります。たとえば、2個セットを1つ販売した場合、構成品の在庫を2個分減らさなければなりません。同じ構成品が複数のセット商品に含まれる場合、補充の推奨は構成品単位で需要を集計する必要があります。マッピングが不確かな場合は、誤った数量を伝播させるよりも、自動同期を停止して確認を求めるほうが安全です。

複雑な需要予測より先に価値をもたらすデータ品質ダッシュボード

補充のミスは、アルゴリズムよりも、リードタイムの欠落、SKUマッピングの誤り、棚卸しの遅れ、キャンセル注文の在庫戻し漏れ、輸送中ステータスの未更新に起因することが多くあります。プロダクトはこうした欠落を作業キューに落とし込み、仕入先が未設定の品目、実地棚卸しの期限を過ぎたロケーション、処理に失敗したイベント、納品予定日を過ぎた発注書を追跡できるようにすべきです。

予測は実績とも比較すべきです。予想欠品日と実際の欠品日、推奨数量と承認数量、そして入荷後に売り切るまでの日数を比較し、滞留在庫が生じていないかを確認します。手動での上書きは、モデルの失敗を示すノイズではなく、業務上の制約を理解するための価値の高いフィードバックです。

データ取得の中断は個別に追跡する必要があります。チャネルへのアクセス権が失効すると、販売数の急減をモデルが需要の減少と誤判断する恐れがあります。在庫照会が失敗すると、システムが過剰に再発注する可能性があります。データの鮮度とソースの健全性は、ビジネス指標と並べて表示すべきです。

1回の調達サイクルから始めるMVP

初期バージョンでは、1つのチャネル、1つの倉庫、販売頻度の高い数十SKUを対象にできます。まず品目マッピング、在庫状態、イベントの照合、発注候補カードを完成させ、1回の調達サイクル全体を通して検証します。複雑な需要予測、複数倉庫の最適化、自動発注はその後で構いません。

評価指標には、欠品を事前に警告できる期間、同期例外の検知までの時間、推奨を採用または修正した理由、緊急発注の件数、欠品と滞留在庫の変化、推奨から発注までの所要時間が含まれます。通知件数だけを測定したり、対照群なしに在庫の改善をすべてシステムの成果とみなしたりすることは避けてください。

本記事は在庫データをプロダクト化するための方法論を扱うものであり、EveryInfraが在庫管理や購買管理のプロダクトをリリースしたことを意味するものではありません。在庫データが価値を生むのは、ダッシュボードが更新されたときではありません。ソースの変更、同期の失敗、手動調整の後もシステムがデータの照合を続けるなかで、チームが説明可能な推奨に基づいて正しいアクションを完了したときです。