food-delivery-demo ── 原則の両立が難しい点を動くコードで検証する

単一巨大エージェント vs マルチエージェント（Arachne 実装）── 設計の違い

単一の巨大エージェントに全責務を集約した場合と、マイクロサービス原則に従ってマルチエージェントに分割した場合で、何が異なるか。 以下の対比表は、実装選択による具体的な差分を示しています。

各項目の詳細は下の「原則ごとの両立検証」セクションで確認できます。

このデモの読み方

このデモの主眼は、サービス数やエージェント数ではありません。各原則で何がぶつかりやすく、どう対応したかを確認することです。 以下に、原則ごとの「両立が難しいポイント」と、その確認場所を対応させています。

既存システムへの段階的導入を想定している場合： 以下の検証・統合優先度を参考にしてください。この順序は既存の設計原則から導出されており、各ステップで原則を損なわずに統合できます。

ステップ1：外付け会話窓口から始める（support-service 相当） 既存 API に一切の変更を加えず、独立した会話インターフェースを追加します。リスクが最小で、チームがエージェント運用に慣れるフェーズです。
ステップ2：自然言語フロントドアを入口に追加する（order-intake-agent 相当） 既存 API 契約を変えず、API の手前に自然言語解釈層を追加します。入出力の型が既存システムと一致することで、変更の局所性が保証されます。
ステップ3：service-local agent に展開する（menu-service / delivery-service 相当） 各サービスが独自の system prompt・skill・tool で判断を担うようにします。この段階で DeterministicModel パターンによるテスト整備の重要性が明らかになります。

サービス構成図

全サービスの依存関係。実線は通常の HTTP 呼び出し、点線はオプショナルまたは非同期の呼び出しを示します。

flowchart LR
    UI[customer-ui]
    CS[customer-service]
    OS[order-service]
    MS[menu-service]
    KS[kitchen-service]
    DS[delivery-service]
    PS[payment-service]
    SS[support-service]
    RS[registry-service]
    HA[hermes-adapter]
    IA[idaten-adapter]
    IC([icarus-adapter])
    DB[(PostgreSQL)]
    RD[(Redis)]

    UI --> CS
    UI --> OS
    OS --> MS
    OS --> DS
    OS --> PS
    OS -.->|post-order| SS
    MS --> KS
    OS -->|discover by capability| RS
    DS -->|discover by capability| RS
    RS --> HA
    RS --> IA
    RS -. not available .-> IC
    OS --> DB
    OS --> RD
    

注文フロー（4 ステップ）

カスタマーが注文を確定するまでの 4 ステップと、各ステップでのサービス間通信を示します。

sequenceDiagram
    actor B as Browser
    participant OS as order-service
    participant OA as order-intake-agent
    participant MS as menu-service
    participant KS as kitchen-service
    participant DS as delivery-service
    participant RS as registry-service
    participant PS as payment-service

    Note over B,PS: Step 1 — suggest
    B->>OS: POST /api/order/suggest
    OS->>OA: normalize intent
    OA-->>OS: NormalizedOrderIntent
    Note right of OA: 自然言語意図を capability 境界へ接続
    OS->>MS: grounding handoff
    MS->>KS: inventory check
    KS-->>MS: stock + ETA
    MS-->>OS: MenuSelectionDecision
    OS-->>B: suggested items

    Note over B,PS: Step 2 — confirm-items
    B->>OS: POST /api/order/confirm-items
    OS-->>B: items confirmed

    Note over B,PS: Step 3 — confirm-delivery
    B->>OS: POST /api/order/confirm-delivery
    OS->>DS: delivery options
    DS->>RS: discover ETA services
    RS-->>DS: hermes + idaten
    DS-->>OS: DeliveryPlan
    OS-->>B: delivery options

    Note over B,PS: Step 4 — confirm-payment
    B->>OS: POST /api/order/confirm-payment
    OS->>PS: charge
    PS-->>OS: charged
    OS-->>B: order confirmed
    

UI スクリーンショット

実際に起動中の food-delivery-demo から取得したスクリーンショットです。

/home

ホームダッシュボード

メニューカタログ・注文履歴・キャンペーン情報を表示します。

/order

Step 2: AI メニュー提案

4 ステップ注文 workflow の提案フェーズ。入力意図に沿って候補メニューと ETA を提示します。

/support

会話型サポート

注文フローとは独立したサポート専用チャット。キャンペーン・稼働状況確認も行えます。

/agents

サービスビューワー

registry-service に登録されたサービスのプロンプト・スキル・API 仕様を閲覧できます。