在庫・再発注アラートワークブックを設計する

Q: 「在庫・再発注アラートワークブックを設計する」を使用する前に、何を準備すればよいですか？

「在庫・再発注アラートワークブックを設計する」を使用するには、在庫業務と意思決定、フィールド・出典・サンプル値、再発注と例外のポリシーを準備してください。プレースホルダーは、確認可能な情報だけで置き換えます。詳細が不明な場合は、モデルに推測させず、不明であることを明示してください。

Q: 「在庫・再発注アラートワークブックを設計する」の結果は、どのような場合にまだ使用できませんか？

提示された証拠から、記載された成果である「再発注式、例外キュー、照合チェックを備えた管理された在庫ワークブック」をまだ作成できていない場合や、未解決の前提、承認の不足、創作した詳細に依存している場合、その結果は使用できません。チェック項目を公開可否の判断基準として使い、裏付けのない出力を磨くのではなく、元の入力を修正するか、権限を持つ担当者を指名してレビューを依頼してください。

Q: 「在庫・再発注アラートワークブックを設計する」では、どの AI ツールのテスト記録がありますか？

2026-08-28 時点で、「在庫・再発注アラートワークブックを設計する」の公開テスト記録には ChatGPT が掲載されています。これは実行記録があることを示すだけで、今後の製品バージョンとの互換性や同一の結果を保証するものではありません。別のツールやバージョンでは、すべての制約を明示したまま、使用前に結果のチェック項目をもう一度確認してください。

著者: AILesson9 分でセットアップテスト済み:ChatGPTレビュー日: 2026-08-28

クイック回答

購買判断を創作せず、使用可能在庫、需要、リードタイム、未完了の供給、再発注ロジック、例外対応の担当を追跡する. 入力するもの: 在庫業務と意思決定, フィールド、出典、サンプル値, 再発注と例外のポリシー. 期待される結果: 再発注式、例外キュー、照合チェックを備えた管理された在庫ワークブック.

コンテキストを追加

テキストはこのブラウザ内に留まります。AILesson Prompts は、そのテキストをモデルやサーバーに送信しません。

在庫業務と意思決定フィールド、出典、サンプル値再発注と例外のポリシー

あなたのプロンプト

未入力のフィールドはプレースホルダーとして表示されたままなので、プロンプトをコピーして編集できます。

提示された業務、データ、承認済みポリシーを使って、Excel の在庫・再発注アラートワークブックを設計してください。

品目、拠点、レビュー、需要、サービス、権限、仕入先の制約、アラート後の対応：
[operation]

粒度、在庫、引当、使用不能数、未完了の供給、日付、需要、リードタイム、発注制約、コスト、更新、品質：
[data]

使用可能数、需要期間、安全在庫、再発注/目標ロジック、丸め、古いデータ/遅延への対応、上書き、承認、除外：
[policy]

SKUと拠点の組み合わせごとに1行とし、ソースの事実、計算フィールド、ポリシーパラメータ、推奨アクション、承認済み注文を分けてください。手持在庫の構成を照合し、使用可能在庫、在庫ポジション、リードタイム終了時の予測在庫、発注点、発注数量を区別します。承認済み期間内に入荷予定の未完了供給だけを含め、遅延または入荷日が不確実な供給は例外として残してください。必要量を計算した後に梱包単位と MOQ を適用します。必須の需要、リードタイム、単位、仕入先、データ鮮度の入力が欠けている場合、発注を推奨してはいけません。アラートを購買承認として扱わないでください。シート構成、データ辞書、パラメータ表、Excel Table の数式、アラートの優先順位、条件付き書式ルール、例外と承認のワークフロー、サンプル行、在庫/PO の照合、更新管理、不要・再発注・MOQ/梱包単位への丸め・過剰・欠品・欠損/古いデータ・遅延 PO・需要ゼロ・上書きのテストを返してください。

Playgroundで試す

デフォルトで非公開プロンプトの組み立てはブラウザ内で行われます。組織が許可しない限り、機密情報を AI サービスに入力しないでください。

入力から結果へ

具体例

具体的なコンテキストを加えると、このレシピが実用的な結果になる様子をご覧ください。

実際の入力

在庫業務と意思決定: 小規模な修理部品倉庫で、中央拠点は1か所、SKU は180件です。購買担当者が毎週月曜日にレビューします。目標は仕入先のリードタイム中の欠品を避けることであり、サービス水準を統計的に最適化することではありません。ワークブックは Review/Reorder/Stockout/Data issue のアラートを出します。購買担当者が Excel の外で承認し、PO を作成します。仕入先には梱包単位と MOQ があります。自動発注は行いません。
フィールド、出典、サンプル値: Main 拠点の SKU 1件につき1行。フィールドは SKU、Description、Unit、OnHand、Reserved、Damaged、OpenPOQty、EarliestConfirmedDue、AvgWeeklyDemand、LeadTimeWeeks、SafetyStock、PackSize、MOQ、Supplier、LastStockRefresh、LastDemandRefresh、OverrideTarget、OverrideReason。サンプル Filter-F9：Unit は each、OnHand 42、Reserved 8、Damaged 2、OpenPOQty 24、入荷確認日は2026年9月8日、AvgWeeklyDemand 15、LeadTimeWeeks 2、SafetyStock 12、PackSize 6、MOQ 24、Supplier は North Parts、更新日は2026年8月31日。レビュー日は2026年9月1日。SKU の重複はありません。日付と数量は空欄の場合があります。
再発注と例外のポリシー: Available=OnHand-Reserved-Damaged。InventoryPosition=Available+レビュー日からリードタイム終了日までに到着する未完了 PO。遅延または未確認の PO は除外し、フラグを付けます。LeadDemand=AvgWeeklyDemand×LeadTimeWeeks。ReorderPoint=LeadDemand+SafetyStock。Target=LeadDemand+SafetyStock+レビュー1回分の期間における需要。ただし、理由を伴う承認済み OverrideTarget がある場合は上書きします。InventoryPosition<ReorderPoint の場合、raw need=Target-InventoryPosition。提案数量は PackSize の倍数へ切り上げ、少なくとも MOQ とします。Available<0 の場合、Stockout/record issue を再発注より優先します。必須データが7日より古い場合は Data issue。需要ゼロで在庫がある場合は、ゼロ除算エラーではなく No reorder です。

出力例

シート：InventoryInput、OpenPO detail、Parameters、ReorderReview、Exceptions、ApprovalLog、Reconciliation。計算された提案を BuyerDecision、ApprovedQty、PONumber、ApprovedAt と分けて管理します。

Filter-F9 では、Available=42−8−2=32。9月8日入荷予定が確認された PO は、9月15日に終わる2週間の範囲内にあるため、InventoryPosition=32+24=56。LeadDemand=15×2=30、ReorderPoint=30+12=42、既定の Target=30+12+15=57。56は42を下回らないため、目標より1単位少なくても状態は No reorder です。このポリシーでは、Target ではなく ReorderPoint を基準に再発注を開始します。

テーブル数式：Available =[@OnHand]-[@Reserved]-[@Damaged]。複数の PO がある場合に単一の集計値を信用せず、EligibleOpenPO は状態と入荷予定日の条件を使って PO 明細から合計します。InventoryPosition=Available+EligibleOpenPO。LeadDemand=AvgWeeklyDemand*LeadTimeWeeks。ReorderPoint=LeadDemand+SafetyStock。条件を満たしたときの RawNeed=MAX(0,Target-InventoryPosition)。丸め後の提案には =MAX([@MOQ],CEILING.MATH([@RawNeed],[@PackSize])) を使用できますが、その前に PackSize/MOQ が正の値であることを検証します。

アラートの優先順位：重複/必須フィールド/型/古いデータ → Data issue。Available<0 → Stockout or record issue。リードタイム範囲に影響する遅延/未確認 PO → Review supply。在庫ポジションが ReorderPoint 未満 → Reorder review。それ以外 → No reorder。条件付き書式は、色だけを使った入れ子のロジックではなく、状態テキストに従います。テストには、在庫ポジション35で RawNeed 22、提案24となるケース、RawNeed 25を30へ丸めるケース、需要0でポリシーどおり No reorder となるケース、範囲終了の1日後に到着する PO を除外してフラグを付けるケース、Supplier 欠損または更新から8日経過したデータで提案をブロックするケース、Override は target、reason、reviewer、date がすべてある場合に限り使用するケースを含めます。更新のたびに OnHand の件数/合計をソースと照合し、OpenPO の対象数量/除外数量を PO 台帳と照合します。

これがうまくいく理由

1
在庫ポジションと物理的な使用可能在庫を分けることで、未完了注文が現在の不足を覆い隠すのを防げます。
2
承認フィールドにより、計算上の推奨が無許可の購買指示になるのを防げます。

結果を確認

在庫、引当、使用不能数、入荷予定の供給、リードタイム需要、安全在庫、単位が一貫して定義されていますか？
欠損、古いデータ、遅延、重複、不確実な入力により、再発注の推奨が停止または格下げされますか？
計算上の必要量、丸め後の提案、レビュー担当者の判断、実際の注文が別々のフィールドになっていますか？

安心して使うために

よくある質問

このレシピをいつ使うか、何を用意するか、どの場面で人による確認が依然として重要かについての実践的な回答です。

「在庫・再発注アラートワークブックを設計する」を使用する前に、何を準備すればよいですか？

「在庫・再発注アラートワークブックを設計する」を使用するには、在庫業務と意思決定、フィールド・出典・サンプル値、再発注と例外のポリシーを準備してください。プレースホルダーは、確認可能な情報だけで置き換えます。詳細が不明な場合は、モデルに推測させず、不明であることを明示してください。

「在庫・再発注アラートワークブックを設計する」の結果は、どのような場合にまだ使用できませんか？

提示された証拠から、記載された成果である「再発注式、例外キュー、照合チェックを備えた管理された在庫ワークブック」をまだ作成できていない場合や、未解決の前提、承認の不足、創作した詳細に依存している場合、その結果は使用できません。チェック項目を公開可否の判断基準として使い、裏付けのない出力を磨くのではなく、元の入力を修正するか、権限を持つ担当者を指名してレビューを依頼してください。

「在庫・再発注アラートワークブックを設計する」では、どの AI ツールのテスト記録がありますか？

2026-08-28 時点で、「在庫・再発注アラートワークブックを設計する」の公開テスト記録には ChatGPT が掲載されています。これは実行記録があることを示すだけで、今後の製品バージョンとの互換性や同一の結果を保証するものではありません。別のツールやバージョンでは、すべての制約を明示したまま、使用前に結果のチェック項目をもう一度確認してください。

さらに探す方法