Apsara Conference 2026では、AIがモデル能力からAgenticな業務実行へ進む流れが強く打ち出されています。Udeskの展示でAgent OSや企業向けAI Agentについて話すなかで、Customer Support Agentを本番へ移す際の構成を改めて整理したくなりました。

問い合わせを一つ通して考える

たとえば顧客から「昨日返品した商品が、まだ返金されていません」と届いたとします。自然な回答文を返すだけならLLMで対応できますが、問い合わせを解決するには、本人と注文を特定し、返品と返金の規定を確認し、注文管理と決済の状態を取得し、必要であれば調査チケットを作り、処理が終わるまで状態を保持しなければなりません。自動処理できない場合は、ここまでの確認結果を担当者へ渡します。
この例では、設計対象はLLMの入出力ではなく、問い合わせが解決するまでのシステム全体です。以下は特定製品の仕様ではなく、PoCから本番へ進める際に最低限分離しておきたい六つの役割です。
処理の全体像

Channel and Identity

Webチャット、メール、電話などの入力を共通イベントへ変換し、顧客ID、会話ID、言語、チャネル固有の制約を付与します。本人確認前の利用者に注文情報を返さないよう、認証状態もこの段階から持たせます。

Context and Knowledge

会話履歴だけでなく、顧客属性、対象注文、現在のチケット、適用する規定を集めます。検索結果には文書IDと版を残し、後から「どの情報で判断したか」を確認できるようにします。権限のないナレッジは検索候補へ入れません。

Reasoning and Policy

LLMは意図を推定し、必要なToolと次の行動候補を作ります。ただし返金上限や本人確認など、結果が確定している業務規則はPromptだけに委ねず、ポリシー判定として外出しします。モデルの判断と企業が許可する行動を分けるためです。

Tools and Workflow

注文照会、返金状態の確認、チケット作成などを明示的なToolとして定義します。入力Schema、権限、タイムアウト、再試行条件、副作用の有無をTool契約に含めます。更新系Toolではidempotency_keyを必須にすると、再試行時の二重処理を避けやすくなります。

Task State and Runtime

長い処理では会話の外にタスク状態が必要です。waiting_for_payment、needs_approval、resolvedのような状態と、実行済みTool、次回実行時刻、失敗理由を保存します。外部システムの応答待ちや担当者承認の後でも、同じ処理を安全に再開できます。

Human Handoff and Governance

Agentが権限を持たない場合、確信度が低い場合、顧客が人を希望した場合は担当者へ移します。引き継ぐのは会話全文だけではなく、本人確認の結果、参照した規定、実行済み操作、未解決の判断です。同時に監査ログ、個人情報のマスキング、保持期間、停止手段を運用設計へ含めます。

Task Schemaを会話から分ける

Runtimeが扱う状態は、チャット履歴から毎回推測せず、構造化して保存します。最小例は次のようになります。

title.rb

task_id: cs_20260922_001
intent: refund_status
customer_id: verified_customer_id
order_id: order_reference
state: waiting_for_payment_gateway
completed_tools:
  - get_return_status
pending_action: get_refund_status
idempotency_key: refund_check_unique_key
handoff_reason: null
knowledge_refs:
  - refund_policy_v12

このSchemaの目的はモデルに読ませる情報を増やすことではありません。再開、監査、担当者への引き継ぎに必要な事実を、会話文とは別の信頼できる状態として持つことです。モデルを変更しても、この状態とTool契約が維持されれば、業務側の作り直しを抑えられます。

最初に通すべきテスト

本番前には正常系だけでなく、注文が見つからない、ナレッジが競合する、Toolがタイムアウトする、同じイベントが二度届く、処理途中で担当者へ移る、といったケースを一連のシナリオとして試します。各ケースで確認するのは最終回答だけではありません。呼び出したTool、状態遷移、権限制御、再実行時の挙動、引き継ぎ情報までを期待値に含めます。
Customer Support Agentを本番化するとき、設計対象はLLMではなく「問い合わせが解決するまでのシステム全体」になります。Udeskのように企業のカスタマーサービスを扱う現場でも、この単位で考えることで、対話の品質と業務処理の安全を同じ設計に置けます。Support Agentを本番導入するとしたら、皆さんはどのレイヤーから先に固めますか。