これはケーススタディです：サプライチェーンにおけるAI
すべてのレストランチェーンには同じ“汚れた秘密”があります。誰も実際に、どれだけの食べ物を廃棄しているのかを把握していないのです。
私は、12拠点のレストランチェーン向けにシステムを手がけました。そこでは在庫管理の全プロセスが“感覚”で回っていました。キッチンマネージャーが朝7時に入ってきてあたりを見て、「鶏肉が少ないな」と思い、調達に電話して「20kg送って」と言う。それだけです。それがシステムでした。
データはない。追跡もない。フィードバックループもない。人間が冷蔵庫を見て、電話をかけるだけです。
混乱として始まったもの
12のレストランすべてで、毎日実際に何が起きているのかを説明します。
朝（店舗ごと）：
キッチンマネージャーが目視で巡回します。直感と経験に基づいて、何が不足しているかを決めます。それを紙に書きます。書かないこともあり、その場合はただ覚えています。中央の調達オフィスに電話し、必要なものを口頭で伝えます。調達オフィス：
担当者がスプレッドシートに注文を入力します。次に3〜4社の仕入先に電話して見積もりを聞きます。同じ仕入先。 同じ会話。毎週、同じことが繰り返されます。見積もりを比較して、最安のものを選び、発注します。翌日：
配送が到着します。すべて揃っている場合もあれば、そうでない場合もあります。キッチンマネージャーが注文書と照合します。何かおかしければ、また調達に電話します。電話が増えるだけです。誰も話さないギャップ：
日中、キッチンは食材を使います。しかし、実際にどれだけ使ったのかと、どれだけ注文したのかを誰も追跡していません。鶏肉を20kg注文しました。POSシステムには、約12kg使うはずの料理を売ったことが表示されます。日が終わると、3kg残っています。残りの5kgはどこへ行ったのでしょうか。誰も知りません。そもそも誰もその問いをしていません。月末：
12人の各店舗マネージャーが、発注コストをそれぞれスプレッドシートにまとめます。そして本部にメールします。本部側の誰かが、12個のスプレッドシートを手作業で統合してP&Lレポートを作ります。だいたい8時間かかります。レポートには誤りだらけですが、誰も確認するだけのエネルギーがありません。
本部は統合されたレポートを見て、問題を見つけようとします。しかしできません。廃棄データがありません。仕入先のパフォーマンスデータもありません。どの店舗が過剰発注しているのかも分かりません。つまり、判断は手探りなのです。
私はこのワークフローに14ステップをマッピングしました。以下が内訳です。
パターンは明確です。大半のステップは機械的で、ツールで自動化できます。判断が必要なステップはMLモデルで置き換えられます。そして最大の問題（ステップ11）は、そもそも“悪いプロセス”ですらなく、“プロセス自体が欠けている”ことです。
# 在庫＆調達オートメーション・パイプライン
| ステップ | コンポーネント | 理由 |
|-----------------------------------|---------------------------------------------|-----|
| 目視での在庫確認 | TOOL（デジタル計量器＋POSデータ）をトリガーとして使用 | 目視ではなく実測で置き換える。POSは何が売れたかを教えてくれる。計量器は何が残っているかを示す。毎朝届くこのデータが、システム全体を起動するトリガーになる。 |
| 注文リストを書き込む | 決定論的ML（需要予測器） | 回帰モデルが曜日、予約、天気、過去の販売、現在の在庫を受け取り、正確な注文数量を出力する。これは言語の問題ではない。数学の問題だ。 |
| 調達に電話する | TOOL（自動ルーティング） | 電話そのものが不要になる。システムが計算された注文を調達ワークフローへ送る。 |
| スプレッドシートに入力する | TOOL（データベース） | スプレッドシートを構造化データベースに置き換える。注文は自動的に記録される。 |
| 見積もりのために仕入先へ電話する | TOOL（仕入先API） | 仕入先はAPIまたは週次のアップロードで価格リストを提供する。システムが自動で問い合わせる。 |
| 見積もり比較、仕入先を選ぶ | 決定論的ML（仕入先スコアラー） | 価格＋オンタイム納品率＋品質の却下率でスコアリングする。LLMに“考えさせる”のではなく、重み付きスコアリングモデルだ。 |
| 発注する | TOOL（仕入先API） | ガードレール内で自動実行する。 |
| 配送が到着 | TOOL（配送確認） | キッチンマネージャーがアプリで受け取りを確認する。数量は注文に紐づけて記録される。 |
| 注文と配送の照合 | TOOL（自動マッチング） | システムが受領分と注文分を比較する。食い違いを検知する。 |
| 食い違いを解決 | HUMAN CHECKPOINT | 10%を超える食い違いは、完全な文脈付きで調達マネージャーにエスカレーションする。小さな差異は自動で承認され、ログに記録される。 |
| 使用量を注文量と追跡 | 決定論的ML（廃棄検知） | 20kgを注文。POSは料理に使った分として12kgを示す。計量器は3kgが残っていることを示す。未計上の5kg＝廃棄。モデルはベンチマーク以上の店舗をフラグする。 |
| 月次のコスト集計 | TOOL（自動レポート） | すべての注文はすでにデータベースに入っている。月次合計はSQLクエリで取得できる。 |
| 12店舗を統合 | TOOL（ダッシュボード） | すべての拠点にまたがる1つのクエリ。リアルタイム。 |
| 異常のレビュー | LLM（ナラティブ）＋HUMAN CHECKPOINT | LLMが読みやすい要約を生成する。「店舗7の鶏肉コストはチェーン平均より23%高い。廃棄率はチェーン平均9%に対して18%。」人間が読み、次に何をするか判断する。 |
注： LLMはちょうど1回だけ登場します。最後にです。ナレーションのために。つまり、このパイプライン全体でLLMが意思決定を1つも行うことはありません。
システムアーキテクチャ
システムには並行して動作する3つのレイヤーがあります。
レイヤー1：レストランエージェント（x12、独立して稼働）
各レストランが独自のエージェントを動かします。同じロジック、異なるデータです。互いを待ちません。
トリガー：毎日 午前5時
→ [TOOL] POSの売上データを取得（昨日分）
→ [TOOL] デジタル計量器の読み取りを取得（現在の在庫）
→ [決定論的ML] 需要予測器
入力：曜日、予約、天気、
昨日の売上、過去の傾向、
現在の在庫
出力：食材ごとの注文数量
信頼区間付き
→ [決定論的ML] 廃棄検知器
入力：昨日の開店時在庫、
受領した配送、POS由来の使用量、
計量器からの閉店時在庫
出力：食材ごとの廃棄量
閾値を超えるかどうかのフラグ
→ [TOOL] API経由で仕入先価格を照会
→ [決定論的ML] 仕入先スコアラー
入力：現在の価格、過去のオンタイム率、
品質の却下率
出力：食材ごとの順位付けされた仕入先
レイヤー2：意思決定の分岐
ここでシステムが「人間が必要なもの」と「不要なもの」を決めます。
IF 注文 < ₹50K
AND すべての品目が優先仕入先
AND 廃棄レベルが通常：
→ 仕入先API経由で自動実行
→ データベースへログ記録
IF 注文 ≥ ₹50K
OR 標準外の仕入先
OR 異常な数量（平均の>2倍）：
→ 人間のチェックポイント
→ 調達マネージャーが承認/修正/却下
→ 承認された注文を実行
返却形式: {"translated": "翻訳されたHTML"}IF waste flag triggered (>15% waste on any ingredient):
→ ALERT restaurant manager + head office
→ [LLM] 廃棄分析ブリーフを生成
→ HUMAN が調査して根本原因を記録
自動実行の経路はルーチンを処理します。人間のチェックポイントが異常を捉えます。廃棄アラートが未知の事態を扱います。3つの経路、明確なルール、曖昧さなし。
Layer 3: Head office consolidation agent
毎日および毎月実行します。すべてを集約します。
DAILY:
→ [TOOL] 12拠点にわたる注文・コスト・廃棄を集計
→ [DETERMINISTIC ML] 異常検知器
原価ベンチマークより上／下に位置するレストランをフラグ付け
→ ダッシュボード更新
MONTHLY:
→ [TOOL] データベースから連結P&L（損益計算書）を生成
→ [DETERMINISTIC ML] トレンド分析
→ [LLM] 月次ナラティブを生成：
「チェーン全体のフードコスト：売上の32.4%（目標30%）。
上位：レストラン2が28.1%。
要注意：レストラン9が37.2%。
野菜で22%の廃棄率が要因。」
→ HUMAN CHECKPOINT：本部がレビューし意思決定
The feedback loop
これが、システムが時間とともに賢くなる理由です。
すべての注文、すべての配送、すべての廃棄測定、すべての需要予測が保存されます。システムは予測精度を追跡します。
「火曜日のレストラン3について18kgの鶏肉需要を予測しました。実際は21kgでした。誤差：16%。」
これは需要予測器にフィードバックされます。数週間、数か月にわたって、モデルは各レストランのパターンを学習します。レストラン5は毎週金曜日に必ず急増することを学習します。
レストラン9は、毎回のモンスーン期に野菜の廃棄が高くなります。サプライヤーBは、祝祭日の間に配送時間が遅れます。
MLモデルは静止しません。メモリ層が、単なる意思決定ではなく結果を捉えるため、改善されます。
Failure mode analysis
すべてのコンポーネントは、いずれ必ず故障します。問題は「故障するかどうか」ではなく、「故障したときに何が起こるか」です。
POSデータフィードが停止： キッチンマネージャーが昨日の推定カバー数を手動で入力します。システムは、直近の類似した日の実績を代理として使用します。アラートはITへ送られます。
スケールの誤動作またはスタッフが計量を飛ばす： システムは欠落した読み取り値を検知し、計算された在庫へフォールバックします：昨日の在庫 + 配送 - POSの使用量。完璧ではありませんが、何もしないよりはましです。
需要予測器が大きく外す： 最近の誤差が大きい場合、信頼区間は自動的に広がります。低信頼の予測には20%のバッファを付け、人間によるレビューをフラグ付けします。モデルは週次で再学習します。
サプライヤーAPIがダウン： 注文はキューに積まれます。注文の詳細を添えて、調達担当者にSMS通知を送信し、電話で手作業での発注を行います。確認された時点でアプリに注文を記録します。
廃棄検知器が誤検知（false positive）を出す： 廃棄アラートは、エスカレーションの前にしきい値超えが2日以上連続して必要です。単日の急増は記録されますが、アラームは発動しません。アラート疲れを減らします。
自動実行のバグが発注数量を10倍にする： 強力なガードレール。自動発注が、そのレストランにおけるその食材の直近4週間平均の3倍を超えることはありません。3倍を超えるものは人間の承認が必要です。各拠点ごとの日次支出上限。
LLMが月次レポートで数字を幻覚する： LLMは数値を生成しません。すべての数値は、構造化データとしてデータベースから取得されます。LLMはそれらを自然言語で包むだけです。LLMが利用できない場合でも、元の数値を載せたダッシュボードは引き続き動作します。
設計原則： いずれかのMLコンポーネントが失敗した場合、システムは現在の手作業プロセスへ劣化（フォールバック）します。より悪い何かへは劣化しません。最悪のシナリオは「今日のやり方に戻ること」です。これは崖ではなく下限です。
結論：
MLが判断します。LLMが説明します。人間が承認します。これがパターンです。
