ケーススタディ：店舗欠品 → 店舗間在庫移動（利用者視点）
《店舗欠品 → 店舗間在庫移動》は Odin | Asgard Studio の視点から、管理者が店舗間在庫移動 Agent をどう構築し、照会できる Semantic Model とガバナンスゲートをどうマウントするかを紹介しています。本記事は同じ小売デモプロジェクトを引き継ぎ、Sindri 利用者の視点から見ます。業務担当者は Agent がどう構築されたかを知る必要がまったくなく、チャット画面で一言尋ねるだけです。
シナリオ
運用担当者が Sindri にサインインし、零售 (IaC) という Project に切り替えると、画面には店舗間在庫移動、商品インサイト、プロモーション分析、補充発注、店舗運営の 5 つの公開済み Agent が並びます。どれを選ぶべきか判断する必要はなく、そのまま入力ボックスに入力します。
信義旗艦店で明日欠品する聯名鈦保溫瓶（SKU-8801）について、余剰在庫があって移動できる店舗はどこですか。それぞれどれだけ回せますか。
Sindri が店舗間在庫移動 Agent に委譲する
質問を送信すると、Sindri がこの依頼をどの Agent に渡すべきか判断します。画面には順に Thought for a moment の処理表示、自動生成された対話タイトル SKU-8801 跨店調撥分析 が現れ、続いて Subagents パネルが allocation（Odin のケーススタディにある店舗間在庫移動 Agent）への委譲を示し、マウントされた Semantic Model をリアルタイムで照会します。
数秒後、完全な分析結果が返ります。信義旗艦店の現在庫、安全在庫、日平均販売速度と欠品見込み時期、続いて全チャネルの移動可能総量（102 件）、そして優先順に並べた各店舗の移動可能数と移動後のカバー日数です。最後に Agent は自分で移動伝票を作成することはせず、3 つの案（A：上位 3 店、B：全店舗、C：カスタム）を提示し、どれを採用するか利用者の確認を待ちます。
ガバナンスゲート：チャット画面で実際に承認する
利用者は続いてこう返答します。
案 A を実行し、上位 3 店の移動伝票を作成してください
Agent はシステムへ書き込むツールの呼び出しを準備します。このステップが店舗間在庫移動 Agent の設定で触れられているガバナンスゲートで、Sindri 側では承認ダイアログとして現れます。呼び出すツールセット（ts-wms）とツール（create_transfer_order）、展開して確認できる実際の入力内容、そして現在が何番目の未処理のツール呼び出しか（たとえば 1 / 3）が示されます。利用者はこの対話ではすべて許可、今回のみ許可、拒否のいずれかを選べます。
3 件の移動伝票（板橋、竹北、花蓮）を 1 件ずつ承認すると、Agent が実行結果を報告します。各移動伝票の伝票番号、出荷元店舗、宛先店舗、数量に加え、移動後の信義旗艦店の在庫見込み（86 件が入って約 2.0 日分をカバー）が添えられます。最後に、移動で稼げるのは約 2 日の余裕にすぎないことを自ら注意喚起し、補充発注も並行して開始することを提案し、続けて補充案を検討するか尋ねます。
このケースが示すこと
- 利用者は背後にどの Semantic Model があるか、どの Agent が何を担当するかを知る必要がありません。自然言語で問題を説明するだけで、Sindri が各 Agent の委譲説明に従って自動的に転送します。
- 照会と分析（読み取り）は Agent が自律的に行います。システムデータを変更する操作（書き込み）は必ずガバナンスゲートで止まり、利用者はチャット画面でツール名と実際の入力内容を確認したうえで、許可するか拒否するかを自分で判断できます。送信すればそのまま実行されるわけではありません。
- 同じ Agent、同じガバナンスゲートの設定が、Odin では管理者から見た構築の詳細であり、Sindri では利用者から見て、リスクを自ら知らせ承認を待ってから動くアシスタントになります。