メインコンテンツまでスキップ
小売チェーンが複数の Managed Agent で店舗欠品に対応する一連のケーススタディ。欠品の検知、移動案の算出、緊急補充の比較、プロモーション影響の評価まで、4 つの書き込み操作はすべてガバナンスゲートで人の承認を待ちます。

ケーススタディ：店舗欠品 → 店舗間移動

このケーススタディでは、小売チェーンが Odin を使って役割分担の明確な複数の Managed Agent を構築し、POS・WMS・ERP・EC・サプライヤー・CRM の 6 システムを横断しないと判断できない種類の運用課題、すなわち店舗の欠品に対応する方法を示します。ここに登場するデータ、Agent、ガバナンスゲートはすべて実際のデモプロジェクトで構築・公開済みで、設計案ではありません。

シナリオ​

日曜夜、POS の日次締めが完了しました。信義旗艦店（Xinyi Flagship）ではコラボ保温ボトルの在庫が 6 個しか残っておらず、安全在庫は 40 個であるのに対し、その日は 45 個売れ、通常の販売速度の約 4 倍でした。きっかけはインフルエンサーの開封動画による話題化で、これに EC で実施中の 2 個目半額プロモーションが重なりました。配送センター（DC）の在庫も 30 個しか残っておらず安全在庫の 100 個を下回っており、標準の補充リードタイムは 14 日です。通常のフローでは翌日の昼に旗艦店が欠品し、そこから全チャネルに波及します。しかも通常は月曜に店長が報告し、運営部が会議を開いて、2 日後にようやく移動指示が出ることになります。

このケーススタディでは、4 つの Managed Agent が夜間にすべての検索と分析を自律的に完了します。欠品リスクの確認、全チャネルの在庫スキャンによる移動可能な店舗の特定、標準補充と緊急補充の 2 案の比較、プロモーションによる在庫の引き当て効果の定量化です。ただし移動指示の作成、緊急補充の発注、プロモーションの調整、店舗への回答という、実際にシステムのデータを変更する 4 つの操作はすべてガバナンスゲートで止まり、翌朝の運営責任者による一括承認を待ちます。

関係する Agent​

プロジェクトには 5 つの Managed Agent が公開されており、それぞれが一段の判断または 1 つのシステムへの書き込み権限に対応します。

  • 門市營運 Agent（店舗運営）：店舗の欠品リスクを検知し、販売速度の異常の内訳（インフルエンサー効果とプロモーション上乗せなど）を分解し、店舗向けの対応案と会員への影響をまとめます。
  • 跨店調撥 Agent（店舗間移動）：全チャネルの在庫をスキャンし、各店舗が自店の安全在庫を枯渇させない範囲で移動できる数量を算出し、移動案を作成します。
  • 補貨採購 Agent（補充・購買）：標準補充と緊急補充の 2 案のリードタイムとコストを比較し、発注書を準備します。
  • 促銷分析 Agent（プロモーション分析）：実施中のプロモーションによる在庫の引き当て効果を定量化し、プロモーションのルールを調整した場合の販売速度の変化をシミュレートします。
  • 商品洞察 Agent（商品インサイト）：滞留在庫の処分価格に関する分析型のリクエストを扱います（別のケーススタディに対応、在庫充足日数のランキング）。

各 Agent の Prompt には、一般的なチャットアシスタントではなくツール中心の企業システム操作者であることが明記されています。能力の境界はデータベースのセマンティックモデルによる検索（読み取り）に、システムツールによるデータ変更（書き込み）を加えたものであり、書き込み操作は必ず、どの数値に基づくか、影響範囲、リスクを先に説明したうえで、ガバナンスゲートの承認を待ちます。

Managed Agent 一覧。5 つの小売関連 Agent がすべて公開済み（Released）

跨店調撥 Agent を例に、1 つの Managed Agent の設定を詳しく見る​

跨店調撥 Agent の Prompt は 4 つのセクションに分かれ、それぞれが実際の能力の境界に対応しており、漠然としたロールプレイの文章ではありません。

  • Persona：あなたは小売チェーンの跨店調撥 Agent（Enterprise System Agent）であり、一般的なチャットアシスタントでもデータを調べるだけの分析アシスタントでもなく、ツール中心の企業システム操作者として、データベースのセマンティックモデルによる検索（読み取り）とシステムツール（書き込み）を通じて、検索・分析からシステムへのデータ書き込みまでの一連の運用タスクの完了を支援します。
  • Task：中核となる原則を列挙し、能力の境界がデータベースのセマンティックモデルによる運用データの検索（読み取り）に、システムツールによるシステム内のデータ変更（書き込み）を加えたものであることを明示します。対応する能力で正しく完了できないことは、できると称してはならず、文章で完了したように見せてもなりません。
  • Context：この Agent が実際に使える能力を列挙します。読み取りとしてデータベースのセマンティックモデルによる店舗と配送センターの在庫・売上データの検索、書き込みとしてシステムツールによる承認後の店舗間移動指示の作成が含まれます。
  • Format：返信は台湾の繁体字中国語と Markdown の書式に統一すること、まず結論（移動可能な総数量）を示し、続いて各店舗の移動可能数量の順位と入荷時点を添え、すべての数値がデータソースまで遡れるようにすること、書き込み操作の実行前には何に対して何を変更するのか、どの数値に基づくのか、影響範囲とリスクを先に説明することを規定します。

跨店調撥 Agent 設定画面の上半分：Agent Alias（allocation）、Description、および Persona／Task／Context／Format の 4 セクションの Prompt

On-boarding Settings には 2 つの Custom Sample Questions が設定されており、新しい対話ボックスの下部に表示されて、この Agent への尋ね方をユーザーに示します。

  • 信義旗艦店那顆明天就要斷貨的聯名鈦保溫瓶（SKU-8801），哪些門市有多餘庫存可以調撥？各能撥多少？
  • 在不掏空支援門市的前提下，最多能調撥多少件給缺貨的旗艦店？

さらに下はこの Agent が実際にマウントしているリソースです。MCP Servers は配送センターの書き込みツールセット 1 つのみで、書き込み権限を持つ唯一の操作（店舗間移動指示の作成）に対応します。Skillsets は店舗間移動の最適化をマウントし、移動数量の算出に使います。Semantic Model は POS 門市セマンティックモデルと WMS 配送中心セマンティックモデルの 2 つをマウントし、それぞれ Allow Query／Allow Write を個別に切り替えられ、Allowed Cubes で特定のテーブルのみに検索を制限できます（空欄はすべて開放を意味します）。この Agent の 2 つの Semantic Model はいずれも Allow Query のみを有効にしており、書き込み操作は下のガバナンスゲートの節にある Automation Tool に完全に任せているため、Agent がセマンティックモデル経由で直接データベースに書き込むことはありません。

跨店調撥 Agent 設定画面の下半分：On-boarding Settings の 2 つの Custom Sample Questions と、マウントされた MCP Server／Skillset／Semantic Model（Allow Query の切り替えを含む）

検索側：7 つの Semantic Model​

6 つのシステム（POS、WMS、ERP、EC、サプライヤー、CRM）にそれぞれ 1 つの Semantic Model があり、さらにシステム横断のレポート検索用にデータウェアハウス（OLAP）のセマンティックモデルが 1 つあり、すべて Data Insight（Mimir） に公開されています。Agent は判断の段階でこれらの Semantic Model に自然言語で問い合わせるだけでよく、別途 SQL を書く必要はありません。

7 つの小売関連 Semantic Model：CRM 會員、ERP、電商、POS 門市、供應商、資料倉儲（OLAP）、WMS 配送中心

ガバナンスゲート：データを変更する 7 つの Automation Tool​

実際にシステムへ書き込む操作はすべて Automation Tool として作られ、Workflow の形で入力パラメーターの Schema を定義します。たとえば店舗間移動指示を作成するツールでは、入力パラメーターに商品 SKU、支援（出荷）店舗コード、欠品（入荷）店舗コードなどの項目が含まれます。Agent はこの Schema に沿って移動リクエストを提出できるだけで、実際の送信前には承認ステップで止まります。

Automation Tool 一覧：プロモーション調整、商品価格変更の承認、緊急見積の発注、店舗間移動指示の作成、緊急補充発注書の発行、店舗告知の掲示、入荷通知の送信の計 7 つのガバナンスゲート

店舗間移動指示作成ツールの Schema 設定。sku、from_store_id、to_store_id などの入力項目を定義している

意思決定のフロー​

4 つの Agent が以下の判断を順に完了し、最後に 1 つの意思決定パッケージにまとめます。

  1. 門市營運 Agent が POS の日次締めをスキャンし、信義旗艦店の在庫が安全在庫を下回り、かつ販売速度が基準値を大きく上回っていることを発見して、欠品リスクが極めて高いと判断し、イベントを発火します。
  2. 門市營運 Agent が販売速度の異常の内訳（基準販売速度＋インフルエンサー効果＋プロモーション上乗せ）を分解し、CRM に問い合わせて入荷通知を登録している会員数を確認します。
  3. 跨店調撥 Agent が全チャネルの店舗在庫をスキャンし、自店の安全在庫を枯渇させずに移動を支援できる店舗を特定して、総移動数量と入荷時点を算出します。
  4. 補貨採購 Agent が配送センターの在庫と輸送中の発注書を検索し、標準補充と緊急補充のリードタイム、数量の閾値、加算幅を比較します。
  5. 促銷分析 Agent が現在のプロモーションによるオンライン在庫の引き当て速度を定量化し、プロモーションを継続した場合に移動数量が早期に消尽するかを評価して、調整案を提示します。
  6. 4 つの Agent の結論が 1 つの意思決定パッケージ（移動案、緊急補充の発注案、プロモーション調整案、店舗向けの説明）にまとめられ、ガバナンスゲートで運営責任者の承認を待ちます。

このケーススタディが示すポイント​

  • 1 つの運用課題が 6 システムを横断し、人手では 2 日かけて案を調整する必要があります。役割分担の明確な複数の Agent なら、読み取りと推論を夜間に完了できます。
  • 検索は Semantic Model（自然言語からクエリへの変換）で行うため、どの Agent も SQL や基盤のテーブル構造を知る必要がありません。
  • 実際にシステムのデータを変更する操作は、必ず Automation Tool として入力 Schema が明確なガバナンスゲートに定義され、Agent が承認を回避して直接書き込むことはできません。
  • 各 Agent は自身の責務範囲に必要な Semantic Model、Skillset、MCP Server のみをマウントし、権限の境界が明確です。

同じ小売デモプロジェクトには、Flow Agent で構築したカスタマーサポートのシナリオもあります。《AI カスタマーサポートによる注文問い合わせへのリアルタイム返信》を参照してください。

同じシナリオを Sindri のユーザー視点で見ることもできます。業務担当者がチャットウィンドウで一言尋ね、Sindri がここにある跨店調撥 Agent に委譲して案を作成し、ガバナンスゲートで承認するまでの流れは、《店舗欠品 → 店舗間移動（ユーザー視点）》を参照してください。