在庫補充アラート：10のルールと計算例

閾値を決める前に在庫レコードを定義する

「利用可能」というラベルだけでは計算を特定できません。倉庫では使用を許可された実物、営業では未引当の数量、計画システムでは将来時点の正味残高を指す場合があります。それぞれ異なる質問への答えです。項目名だけでなく、実際の算出方法を記録します。

以下の例では、使用可能な手持在庫から検査保留、期限切れ、その他の使用禁止品を除きますが、引当数量は引きません。未完了の顧客需要は日付別需要に一度だけ含めます。統計予測は、定めた方針で受注による予測消込や照合を行い、既知の注文とそのまま足し合わせません。これは本例の前提であり、すべてのERPに共通する定義ではありません。

Oracleの最小・最大在庫の文書では、計画レベルと需要の正味計算の設定によって利用可能数量が変わります。一般的な式でシステムを上書きするのではなく、実際の設定を設計の入力として確認します。Oracleの計算リファレンス。

日付別には「期末残高＝期首残高＋使用可能な入荷－所要量」で計算し、翌日は前日の期末残高を引き継ぎます。負数は未充足需要であり、棚に負の個数が存在するわけではありません。不足を受注残ではなく販売機会損失として扱うなら、別のモデルに変更し、その違いを明記します。

設定する10の在庫補充アラートルール

これらは同じ補充案件を確認する複数の理由であり、10件の独立した発注指示ではありません。SKU、保管場所、不足期間でまとめ、なぜ案件が未解決なのか、何を確認すれば解消できるのかを示します。

1. 発注点の閾値

継続確認方式の簡単な例では、発注点を補充リードタイム中の予想需要と安全在庫の合計に設定します。在庫ポジションの定義も、その方針に一致させます。未入荷の発注を含むポジションと、将来需要をすでに控除した予測残高は同じものではありません。

閾値を「下回る」ときか「以下」のときかを記録し、境界値、その一個上、一個下をテストします。ERPの「最小値」がこの発注点と同じとは限りません。予測残高を最低バッファと比較する設定もあります。通知には比較する両数量と定義を載せ、リードタイムや需要根拠がなければ、推測した閾値ではなくデータ例外を出します。

2. 安全在庫を下回る予測

承認済みバッファを初めて下回る日、最小残高、回復予定日を特定します。安全在庫を割ることと、顧客に供給できなくなることは別です。両方を表示すると、担当者は余裕の減少と実際の未充足需要を区別できます。

後の入荷でバッファが回復しても、以前の不足が解決したか、方針に基づき例外を認めたのでなければ、警告を消しません。週末残高が正でも水曜日の欠品はなくなりません。Microsoftは累積数量による安全在庫計画と季節別の最小値設定を説明しています。これは製品固有の動作であり、バッファが必ず欠品を防ぐという保証ではありません。Microsoftの安全在庫ガイド。

3. 在庫で賄える日数

消費が比較的安定していれば、使用可能在庫を明示した一日当たり需要で割ると、おおよその在庫日数になります。分母が過去の出庫実績、未完了注文、承認済み予測のどれかを示します。引当を控除した分子と、同じ引当需要を含む分母を無条件に組み合わせないでください。

需要がゼロなら「この需要率では有意味な判断ができない」とし、無期限に安全とは表示しません。間欠需要の補修部品、大口注文、新製品では平均値だけでは不十分です。日付別の所要量に戻って確認します。在庫日数は補充に間に合う判断を促す指標であり、サービス目標を自動で変更する理由ではありません。

4. 補充が使えるまでの全期間の需要

判断の締め時刻から、在庫が使用可能になるまでを計測します。社内承認、仕入先の処理、輸送、受入、検査を含む場合があります。敷地への到着時刻と使用許可の時刻は別なので、営業日カレンダー、締め時間、休日の扱いを保存します。

定期確認方式では、次回確認までの待ち時間も対象になり得ます。すべての商品に適当な日数を加えるのではなく、計画責任者がモデルを承認します。リードタイムが不確実なら、根拠のない確率ではなく、名称と日付のあるシナリオを提示します。通常補充が最初の未充足需要に間に合わない場合は、緊急手配や配分の確認へ回します。

5. 未入荷注文と受注残の照合

一部入荷済みなら、元の発注総量ではなく未入荷残量を使います。発注、移送、入庫予定の対応を確認し、一つの供給を複数データ源で重複計上しません。別拠点への入荷は、この倉庫ですぐ使える在庫ではありません。

遅延中の供給には、更新された使用可能日と根拠が必要です。取消済み注文や解除日不明の保留品で不足警告を抑えないでください。受注残は充足、取消、方針に沿った解決まで需要として残ります。ただし、同じ行を再取得しても新規需要ではありません。供給の不確実さは購買へ、需要の不確実さは顧客対応側へ確認してから数量を承認します。

6. 最低発注数量

補充の提案があるときに、適用される最低発注数量、MOQと比較します。仕入先、品目、単位、有効日と、制約が品目単位、出荷単位、注文全体のどれかを記録します。最低注文金額を、そのまま最低個数として扱うことはできません。

少量の提案をMOQまで増やすと過剰在庫になり得ます。追加個数と、保管、使用期限、支出権限、別調達先などの制約を示します。MOQは取引条件であり、多く買うことが妥当だという証拠ではありません。補充の必要がない状態で、MOQだけを理由に注文を作らないでください。

7. 梱包倍数と単位換算

箱単位だけで購入できるという仮のルールでは、正の候補数量を正しい単位の倍数へ切り上げます。最低50個、1箱24個なら72個が必要です。50個でも48個でもありません。元の必要量、MOQによる調整、切り上げ、最終候補を別々に表示します。

Odooは補充の梱包倍数と、切り上げで目標最大在庫を超える場合を説明しています。すべてのシステムが同じ計算をするとは考えず、使用中の版と設定を確認します。Odoo 19の再発注ルール。

仕入は箱、在庫は個で管理する場合、両方向の換算をテストします。上限数量がMOQや梱包倍数と矛盾するなら、「現行制約を満たす数量なし」と報告します。箱として成立しない数へ縮めたり、承認を回避するために注文を分けたりしてはいけません。

8. 季節・イベント需要

上乗せには承認済みシナリオ、対象品目と拠点、有効期間、責任者を紐付け、基準予測も残します。販促ラベルや営業の楽観的なメモだけでは、特定の増加率を裏付けられません。

イベント需要を追加する前に、基準予測にすでに含まれていないか確認します。終了後は一時的な設定を失効させ、残在庫を確認し、ピークを将来の全期間へ持ち越しません。新製品に関連実績がなければ不確実性を明示し、範囲を決めたシナリオを依頼します。架空の信頼区間は作らず、どの前提が不足日を変えたかを説明します。

9. 仕入先の遅延と品質保留

発注総量が同じでも、入荷日の変更で影響期間を再計算します。品質保留は日程だけでなく利用資格を変えます。根拠のある解除日がなければ使用可能供給に含めず、不確実な数量として示します。

以前の入荷前提、新しい証拠、新たに影響する所要量を表示します。解除は受入・品質担当者が判断します。計画担当者が急いでいることやAIの断定的な要約は、回収対象、期限切れ、保留品の使用許可にはなりません。データが古ければ、最後に分かっていた問題を不確実性付きで残し、回復したと報告しないでください。

10. 欠品のエスカレーションと回復

最初の未充足需要と、権限のある対応がまだ間に合う最終時刻を基準にエスカレーションします。数量、日付、顧客や生産への依存、既知の代替案、必要な判断を示します。「優先度が高い」という表示だけでは具体的な期限の代わりになりません。

既存注文の前倒し、承認済み移送、代替品、顧客への納期再合意などは、それぞれ権限と実現可能性の確認が必要です。「確認済み」を押すことと在庫回復は別です。日付別の不足が直った、正式な例外判断が記録された、または需要自体がなくなったときに、案件を終了または置換します。

六つの管理された手順で導入する

1. 狭い対象を選ぶ。 計画と購買の担当者が決まったSKU・保管場所の組合せから始め、対象需要と在庫状態を記録します。全倉庫・全品目を一度に扱いません。
2. 固定したスナップショットを照合する。 期首在庫を原本に合わせ、需要IDを対応付け、供給の重複を除きます。差異を記録し、解決までは購入数量ではなくデータ品質の案件を送ります。
3. ルール定義を承認する。 比較演算子、同日の入荷と需要の順序、リードタイムのカレンダー、バッファ、数量制約を定めます。変更できる人と発効時点も決めます。
4. 意図的な失敗ケースを再現する。 閾値の境界、遅延、一部入荷、需要ゼロ、期限切れ、引当重複、単位不一致、成立しない梱包数量を確認し、期待値と実際の結果を残します。これは提案する試験計画であり、本番システムの合格実績ではありません。
5. 読み取り専用のシャドー運用を行う。 関連する補充サイクルを含む期間で、候補通知と計画担当者の判断を比較します。確認済み案件に対する対応可能案件の割合を見て、未解決は別に報告します。通知の多さだけでなく見逃した不足も調べ、万能の許容誤り率は作りません。
6. 限定運用を承認する。 各案件に担当者と代替経路を設け、古いデータや判断遅れを監視します。SKU、保管場所、ルール版、不足期間で重複を抑えつつ、重要な変更で再開します。別途承認・検証されるまでは自動発注を無効にします。

確認した案件のスナップショット、計算、判断を保存します。ルール更新時も旧版を残せば、以前は通知されなかった品目が今回対象になった理由を説明できます。購入を許可する別の判断は、購買申請の承認フローで扱います。

計算例：遅い入荷が五日以内の不足を隠す

以下はすべて架空の条件です。0日目の終わりに、一つの倉庫のSKU Aには実物100個があり、そのうち20個は検査保留です。使用可能な期首在庫は80個になります。引当済みの20個は1日目の需要に含まれ、別の期首受注残はありません。照合済み需要は一日20個、バッファは20個です。

既存の確定発注100個は6日目の開始時に使えるようになります。今出す通常注文も、五日分の需要が発生した後の6日目が最早の使用可能日です。この単純化したモデルでは、各日は入荷が先、需要が後です。未充足分は受注残として翌日に持ち越し、販売機会損失や日内の細かな時刻は扱いません。

日付を無視したポジション「80＋100＝180」は、仮の発注点「5×20＋20＝120」より高く見えます。それでも日次計算では5日目に未充足が発生します。静的なチェックは、未入荷分がいつ使えるかを調べていません。粗い総量が健全でも、日付別不足の警告を残す必要があります。

期首から引当20個を引き、さらに五日分の全需要を引くと「60－100＝-40」という誤った結果になります。照合後の計算は「80－100＝-20」です。元の項目がすでに引当控除後なら、引当前の使用可能数量に戻すか、将来の需要列から対応する所要量を除きます。異なる前提を混ぜてはいけません。

この例で5日目までの未充足を避けるには、追加20個が5日目の需要より前に使える必要があります。4日目と5日目の期末バッファ20個を維持するには、追加40個が4日目の需要より前に必要です。目的が違えば必要量も変わります。仕入先や別拠点から実際に調達できるという証明ではなく、担当者が供給元、輸送、解除、権限を確認します。

別の数量計算も考えます。これは追加発注の指示ではありません。仮のポジション目標200から日付なし総量180を引くと、元の候補は20個です。MOQが50個、梱包倍数が24なら「ceil(max(20, 50)÷24)×24＝72」となります。ceilは整数への切り上げです。この申請で追加購入が最大60個までなら、三条件を満たす数量はありません。48個はMOQ未満、72個は上限超過です。矛盾を上位判断へ回し、60個に切り詰めたり、大量でも遅い注文で前の不足が解消したと扱ったりしないでください。

判断を説明できる最も簡単な方法を選ぶ

手作業のワークシートは、件数が少なく不定期で、担当者が出所を確認できる場合に向きます。更新と照合の負担が弱点です。式を保護し、入力日と確認責任を明示します。追跡可能な表は、説明できない自動提案より有用です。

ERP標準の計画ルールは、一つのシステムでデータと意思決定を管理できている場合に向きます。導入済み設定で供給日、需要の正味計算、単位換算、例外の振分けを確かめます。AIという名前が新しいという理由だけで、第二の補充エンジンを追加する必要はありません。

決定論的な連携やスクリプトは、承認済みデータを複数システムで照合するときに役立ちます。変換の版管理、重複処理、監視、保守担当者が必要です。計算を自由な文章生成から分離し、再計算に十分な入力根拠を残します。

エージェントによる確認支援は、計算は信頼できる一方、仕入先の背景確認、変更の要約、部門間の振分けに手間がかかる場合に評価する価値があります。ただし権限と証拠のリスクも加わります。管理されたデータ、試験済み計算、責任者、復旧経路は引き続き必要です。

OpenMaxの役割と、先に確認すること

OpenMaxは、自社を人とエージェントの協働プラットフォームとして紹介し、エージェント接続やチームのワークフローを説明しています。これはベンダーによる位置付けであり、完成済みの在庫最適化機能や、自社ERPとの認証済み接続の証拠ではありません。OpenMaxの製品紹介。

本用途では、読み取り専用の候補フローを評価します。承認済みエクスポートから日次残高を受け取り、決定論的な計算で例外を特定し、アシスタントが変更された入荷と影響需要へのリンクを含む要約を作り、計画担当者が確認して次の責任者を選びます。要約では「確認した日付」「仕入先の説明」「未確認の前提」を分けます。

実データの利用前に、具体的な接続・取込経路、許可項目、保管場所、保持期間、アクセス制御、利用環境のログを確認します。引用レコードを開き直せるか、根拠のない記述を止められるかも試験します。発注作成、仕入先への送信、代替品、在庫解除、配分変更は、個別に明示的な権限を持つ別動作として扱います。

既存ERPの一覧が分かりやすく、チームが安定して処理できていれば、その簡単な方法を維持します。問題が計画計算ではなく分散した確認作業なら、機密を除いた一つのSKU・保管場所の例と上記チェック項目を用意し、OpenMaxの小規模評価を相談します。求めるのは検査可能な例外資料であり、在庫削減や欠品ゼロの約束ではありません。

リスク、限界、責任ある確認

本計算は前提を明記した決定論的な例です。経済的に最適な安全在庫を選ぶものでも、需要の不確実性を予測するものでもなく、すべての製造、ロット、有効期限、サービス義務を扱いません。需要の数え方の変更は、モデルへの指示文の変更以上に結果へ影響することがあります。

運用ルールは計画と購買の責任者が承認します。使用解除の制約、アクセス、支出権限は、関連する品質、セキュリティ、財務の専門担当者が利用前に確認します。本記事には実名の外部サプライチェーン専門家による審査はなく、例を現場の運用成果として提示していません。

仕入先の添付資料やコメントは確認対象の証拠であり、アシスタントの権限を拡張する指示ではありません。要約に含む顧客・取引情報を最小限にし、データ停止時の手作業経路を残します。米国国立標準技術研究所の任意のAIリスク枠組みは一般的なガバナンスの背景であり、本ルールの検証やOpenMaxの推奨ではありません。NIST AI RMF 1.0。

よくある質問

手持在庫と利用可能在庫は同じですか？

異なります。実物、使用可能、未引当、将来の予測残高は別の指標です。元項目の定義を明記して需要計算と合わせないと、引当、保留、将来入荷を誤って数える可能性があります。

発注点と安全在庫の違いは何ですか？

発注点は特定の補充方針におけるトリガーで、簡単な式ではリードタイム需要にバッファを加えます。安全在庫はそのバッファであり、予想需要をもう一度足すものではありません。予測残高の最小・最大ルールでは比較基準が異なる場合があります。

未入荷の発注があれば通知を止めてよいですか？

残数量、入荷先、使用可能日、利用資格が対象の不足を実際に解消するときに限ります。最初の未充足需要より遅い入荷は、最終残高が正でも、それ以前の警告を消す理由になりません。

AIが補充数量を自動で決められますか？

計算を再現可能にし、方針を事前承認します。接続を検証したアシスタントは証拠の準備を支援できますが、提案数量は購入権限ではありません。MOQ、梱包、支出、品質の制約が矛盾するときは責任者の判断が必要です。

在庫アラートはどれくらいの頻度で実行しますか？

データ遅延、需要変動、最後に有効な判断ができる時刻から頻度を決め、供給・需要・保留の重要な変更後に再計算します。古いデータを速く読み直しても予測は新しくならず、全品目に適した共通の頻度はありません。

出典、執筆者、改訂記録

OpenMaxコンテンツチームが自社サイト向けに作成し、製品説明には発行元との商業的関係があります。公式資料の確認日は2026年9月4日です。各製品の文書はその設定を説明するもので、普遍的動作や独立した製品比較を示しません。

• 本文中のOracle資料は、需要の正味計算設定と数量修正の違いの根拠です。
• Microsoft資料は、累積在庫計画と季節別の最小値の説明に用いています。
• Odoo 19資料は梱包倍数の根拠であり、OpenMaxとの接続試験ではありません。
• OpenMaxのホームページは製品の位置付けの出典です。NISTは一般的なAIガバナンスの背景であり、製品認証ではありません。

2026年9月4日の改訂で、従来の概要を10ルールの説明へ拡充し、引当の数え方、日付別不足、数量制約が成立しない例、ダウンロード資料を追加しました。元の公開日は保持しています。訂正はページURL、対象ルール、機密でない根拠を添えてcontact@openmax.comへお知らせください。通常のメールで機密の在庫明細を送らないでください。