ケーススタディ：AI カスタマーサポートによる注文問い合わせへのリアルタイム返信
このケーススタディは《店舗欠品 → 店舗間移動》と同じ小売デモプロジェクトを使いますが、Managed Agent ではなく Flow Agent を使い、より軽量な使い方を示します。顧客が EC サイトのサポートチャットで注文状況をリアルタイムに問い合わせ、AI が実データを直接検索して返信するため、有人サポートの対応を待つ必要がありません。
シナリオ
顧客が小売 EC サイトで商品を閲覧中、画面右側のサポートチャットに次のように入力します。
注文状況を確認したい
従来この種の問い合わせは有人サポートがオンラインになるまで返信されず、顧客は翌日まで回答を得られないことも多くありました。
このケーススタディでは AI サポートエージェントが直ちに対応します。顧客がメッセージを送信すると、EC サイトはすぐにそれをサポート管理画面の会話履歴に書き込んで顧客に応答し（AI の処理完了を待ちません）、同時にバックグラウンドでそのメッセージを、期限と範囲を限定したアクセス資格情報とともに Flow Agent に転送します。Agent はその資格情報を使って顧客の実際の注文データをリアルタイムに検索し、数秒で返信を生成して同じ会話に書き戻します。有人サポートはいつでも同じスレッドに入って引き継げ、AI の返信と衝突することはありません。
Flow Agent：サポートエージェント
プロジェクトの Flow Agent 一覧にはサポートエージェントが 1 つだけあり、wf-customer-service という Workflow に対応しています。
開くと 4 つのノードで構成されたビジュアルフローが表示されます。
- Entry：ワークフローの起点。
- Init：context の初期化。
- Agent：サポートエージェントの主応答（LLM stream）。実際にモデルを呼び出して返信を生成するノードで、成功時は Listen、失敗時は Error に接続します。
- Listen：顧客の入力を待ち、次のメッセージを受け取ると Agent に戻って対話を続けます。
- Error：エラーメッセージの送出（LLM 呼び出しが失敗した際のフォールバックノード）。
Agent ノードの Prompt：まず本人確認、その後に検索可否を判断
Agent ノードを開くと Stream LLM Completion Message 処理ノードで、Prompt では {{#if prevPayload.user}} を使ってこの顧客が会員としてログインしているかを判定します。
- ログイン済み：Prompt にこの顧客の会員番号が渡され、この顧客の注文を検索する必要がある場合は customer-service-api スキルの説明に従って API を呼び出して実データを取得すること、根拠なく回答したり注文内容を捏造したりしてはならないことが指示されます。
- 未ログイン（ゲスト）：Prompt では個人の注文データを一切検索できないこと、顧客が注文状況を尋ねた場合は会員ログインが必要であると伝えること、ほかの方法で推測を試みてはならないことが明示されます。
Prompt には <api_access> のセクションもあり、EC サイトの API を呼び出すために必要な接続情報は各対話ターンでプラットフォームが注入するため、Agent は注入された値をそのまま使うだけで、URL を推測したりドメインを書き換えたりしてはならないと説明されています。これにより Agent が検索範囲をこの顧客以外のデータに広げることを防ぎます。
このケーススタディと前のケーススタディの設計上の違い
《店舗欠品 → 店舗間移動》のケーススタディの Managed Agent と比べて、このサポートエージェントは意図的に異なる方針を選んでいます。
- 前のケーススタディでは Managed Agent に Semantic Model をマウントして検索していましたが、このケーススタディの Agent ノードは Semantic Model をマウントせず、Prompt で EC サイト自身の API を呼び出して注文データを取得するよう指示しています。注文データはもともとデータベースにあるため理論上は Semantic Model での検索も可能ですが、サポートチャットという場面では、いま対応しているログイン済みの顧客自身の注文だけを検索できることを担保する必要があります。どの会員番号を検索するかを LLM 自身に決めさせると、他人のデータを検索するよう説得されるリスクが生じるため、各対話ターンでプラットフォームが注入する短期のアクセス資格情報で API を直接呼び出す方式に変え、検索範囲を Prompt の制約ではなく資格情報のレベルで固定しています。
- このケーススタディは現時点では読み取りのみ（顧客自身の注文の検索）で、データを書き込む Automation Tool はマウントしていないため、ガバナンスゲートは不要です。今後この Agent に顧客の代わりの操作（返品交換申請の作成など）をさせる場合は、人の承認を必要とする書き込みツールを別途設計する必要があり、Agent が外部システムを直接呼び出して実際に影響のある操作を行うようにしてはなりません。