注文・在庫・補充の追跡プロセスを設計する

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

クイック回答

販売、在庫移動、購買、入荷、例外、照合を、管理された1つのワークフローにつなげる. 入力するもの: 事業と在庫のモデル, 現在の記録と問題, 制約と統制. 期待される結果: 記録、数式、役割、アラート、テストケースを備えた実用的な在庫管理プロセス.

コンテキストを追加

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

事業と在庫のモデル現在の記録と問題制約と統制

あなたのプロンプト

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

提示された事業上の事実に基づき、注文・在庫・補充の追跡プロセスを設計してください。

SKU、拠点、チャネル、注文、仕入先、リードタイム、返品、バンドル、単位、サービス目標：
[business]

システム/ファイル、フィールド、タイムスタンプ、担当、件数、不一致、欠品、遅延、品質上の問題：
[records]

レビュー、需要/リードタイムの証拠、安全在庫ポリシー、権限、予算、監査、アクセス、連携、規模：
[controls]

シートやツールを推奨する前に、在庫イベントモデルを定義してください。関連する場合に限り、手持在庫、使用可能在庫、引当済み、ピッキング済み、出荷済み、返品後検品待ち、破損、発注済み入荷待ち、確認済み入荷待ち、入荷済み、調整済みを区別します。信頼できる唯一の情報源を1つ選び、安定した SKU/拠点/注文/PO ID を使用してください。欠けている単位、仕入先の信頼性、需要、リードタイム、再発注点、安全在庫、使用可能在庫を推測してはいけません。不一致を隠すために、在庫を負数にしたり手作業で上書きしたりしてはいけません。

注文から履行までと補充のワークフローを、トリガー、入力、行動、記録の変更、担当者、タイムスタンプ、証拠、例外、承認、SLA とともに整理してください。該当する場合は、テーブル/フィールド、状態値、入力規則、単位付きの計算、アラートロジック、レビュー頻度、循環棚卸、返品、キャンセル、分割出荷、バックオーダー、バンドル、仕入先変更、監査履歴を指定します。提示されたポリシーまたは証拠がある場合にのみ再発注式を推奨し、それ以外は必要なデータと一時的な手作業レビューを示してください。役割/アクセスのマトリクス、照合、分母を明記したダッシュボード定義、導入段階、移行、正常/境界/失敗のテストケースを含めます。

Playgroundで試す

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

入力から結果へ

具体例

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

実際の入力

事業と在庫のモデル: 店舗兼倉庫が1か所あり、42件の SKU を扱う小規模な陶磁器店。販売チャネルは POS とオンラインストアです。オンライン注文は会計時に在庫を予約し、翌営業日に出荷します。商品の単位は 'pieces'。ギフトセット BND-01 は MUG-BLU 2個 + TEA-WHT 1個で構成されます。仕入先は2社で、公称リードタイムはそれぞれ7暦日と14暦日ですが、信頼性の履歴はありません。返品は検品後にのみ在庫へ戻し、破損品は使用可能在庫へ戻しません。サービス目標は、使用可能な個数がない状態でオンライン注文を受け付けないことです。
現在の記録と問題: POS は毎日 CSV をエクスポートします。オンラインストアは、order ID、SKU、quantity、paid/cancelled/refunded timestamps を含む注文をエクスポートします。スプレッドシートには SKU と、棚卸後に上書きされる 'stock' 列が1つだけあります。PO はメールで管理され、入荷記録に PO 参照はありません。先月は、現物不足によりオンライン注文3件がキャンセルされました。5商品で SKU ラベルが一致しません。オーナーが購買を承認し、店舗スタッフがピッキングと入荷を担当し、記帳担当者が毎週照合します。
制約と統制: 今四半期は Google Sheets から始め、連携の予算はありません。毎日15分間レビューし、毎週照合、毎月循環棚卸を行います。オーナーは安全在庫または再発注時のサービス水準を設定していません。6か月分の日次販売データをエクスポートできますが、仕入先の約束日はメールにしかありません。$500を超える購買はオーナーの承認が必要です。店舗スタッフは PO の下書きを作成できますが、送信はできません。顧客情報を保護し、在庫シートには氏名/住所を含めません。

出力例

信頼できる唯一の情報源：追記専用の Inventory Events テーブル1つと SKU マスター。現在の上書き式 stock 列は履歴ではなく、移行時のスナップショットにします。ID：canonical SKU、Location=STORE、order ID、PO ID、event ID。本稼働前に5つの別名を正規化します。単位は pieces です。

中核フィールド：Events—event ID/time/type/SKU/qty signed/location/reference ID/source/status/entered by/evidence/approved by/correction-of。Orders—order ID/channel/status/SKU/qty/reserved/picked/shipped timestamps。顧客の身元情報は含めません。POs—PO ID/supplier/SKU/qty/unit cost/draft/approved/sent/promised/received status。Returns—reference/SKU/qty/inspection outcome。誤りを削除せず、取り消しまたは訂正のイベントを追加します。

状態/計算：On hand = opening + received + approved restock returns − shipped/POS sold − damaged ± approved adjustments。Allocated = paid open online units not cancelled/shipped。Available = On hand − Allocated。Inbound は別に報告し、Available には決して含めません。Bundle availability BND-01 = min(floor(available MUG-BLU/2), available TEA-WHT)。バンドル注文の支払い時に構成品を引き当て、キャンセル時に解放します。Available がゼロ未満になる場合は、オンライン注文の受付をブロックするか手動レビューへ回します。シートからオンラインストアの会計処理を強制することはできないため、これは運用上の統制であり、連携上の欠落として残ります。

毎日：POS/注文イベントをインポートし、SKU/注文の一意性を検証し、未完了の引当を照合し、例外を確認します。店舗スタッフが PO を起案し、オーナーが承認して送信します。$500を超える場合は承認必須で、ポリシーが変わらない限り、それ以下でもオーナーの管理下です。入荷時に PO/実際の数量/日付を記録し、不一致は上書きせず Exception へ送ります。返品は検品まで pending のままにします。記帳担当者は毎週、計算された On hand をソースのエクスポートと照合して差異を記録し、毎月の棚卸では理由付きの承認済み調整を作成します。

再発注：再発注点を創作してはいけません。Phase 1 のダッシュボードでは、6か月分の需要、現在の Available/Inbound、メールにある約束日を使い、オーナーによるレビューのフラグを付けます。信頼性を把握するため、PO の実際の送信日/入荷日を収集します。後からオーナーがリードタイム/安全在庫ポリシーを選びます。テスト：販売、予約/キャンセル、部分出荷、重複インポート、不明な SKU、バンドル在庫の減少、破損返品、PO の部分入荷、>$500 の承認、棚卸差異。移行には、現物棚卸、別名マップ、未完了の注文/PO の取り込み、署名済み開始時スナップショットが必要です。

これがうまくいく理由

1
イベントモデルにより、曖昧な在庫数1つに、現物、引当済み、破損、入荷待ちの数量が混在するのを防げます
2
照合と監査証拠によって例外を可視化し、手作業の編集で履歴がひそかに書き換えられるのを防げます

結果を確認

在庫状態、イベント、単位、ID、信頼できる唯一の情報源、記録の担当が明確ですか
再発注ロジック、使用可能在庫の計算、アラートは、提示されたポリシーとデータに裏付けられていますか
プロセスは、照合、承認、アクセス、例外、境界ケースのテストを網羅していますか

安心して使うために

よくある質問

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

「注文・在庫・補充の追跡プロセスを設計する」を使用する前に、何を準備すればよいですか？

「注文・在庫・補充の追跡プロセスを設計する」を使用するには、事業と在庫のモデル、現在の記録と問題、制約と統制を準備してください。プレースホルダーは、確認可能な情報だけで置き換えます。詳細が不明な場合は、モデルに推測させず、不明であることを明示してください。

「注文・在庫・補充の追跡プロセスを設計する」の結果は、どのような場合にまだ使用できませんか？

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

「注文・在庫・補充の追跡プロセスを設計する」では、どの AI ツールのテスト記録がありますか？

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

さらに探す方法