HUAWEI CONNECT 2026で、企業向けAI Agent、音声エージェント、業界別の業務適用について考える機会がありました。UdeskはH3ホール B02に出展し、会期中には「企業向けAI Agentと顧客体験イノベーション実践フォーラム」も開催しました。
そこで改めて感じたのは、企業Agentではモデルが何を生成できるかより、どこまで任せるかを実装可能な形で決める方が難しいということです。ここからは当日の展示内容を説明するのではなく、問い合わせAIを業務に入れる際の概念設計例として、三つの境界を整理します。
Agentと業務システムの境界
顧客が「返金状況を確認したい」と言ったとき、必要なのは支払状態の参照です。「返金してほしい」なら、返金条件の確認と実行候補の生成が必要になります。似た問い合わせでも、READとWRITEを同じToolへまとめるべきではありません。
Toolはシステム単位ではなく、業務Action単位で狭く切ります。order_apiを一つ渡すより、get_order_status、check_refund_eligibility、issue_refundを分け、引数Schemaと副作用を明示します。WRITEには冪等キー、実行前条件、確認済みの根拠を要求します。
{
"intent": "refund_request",
"order_id": "ORD-1024",
"proposed_action": "issue_refund",
"permission": "write",
"preconditions": ["identity_verified", "refund_eligible"],
"confirmation": "required",
"idempotency_key": "refund-ORD-1024-v1"
}
LLMがToolを選べても、実行条件までモデルの自由判断にしないことが大切です。モデルはAction候補を出し、業務側のPolicyが前提条件を検証し、通過した場合だけToolを実行する構造にします。
自動処理と有人対応の境界
有人対応への切り替えは、Agentが失敗した後の避難先ではありません。本人確認ができない、規則が衝突する、顧客が明示的に担当者を希望する、音声で訂正が続き意図を確定できない、といった条件を先に定義します。
Handoff時には会話全文だけでなく、確定した顧客情報、対象注文、実行済みの参照、未解決の判断、切り替え理由を構造化して渡します。人が最初から聞き直すなら、Agentと人の境界は接続されていません。
if action.has_side_effect and not user_confirmed:
return ASK_CONFIRMATION
if identity_unverified or policy_conflict:
return HANDOFF(reason, verified_context)
return EXECUTE
音声では、発話の割り込みも状態変化として扱います。顧客が「やはりキャンセルしない」と訂正した時点で、保留中のActionを破棄し、意図を取り直す必要があります。自然な音声だけを評価しても、業務上の誤実行は見つかりません。
通用Agentと業界業務フローの境界
製造業、リテール、通信事業者では、同じ問い合わせでも状態と規則が違います。業界差を巨大なSystem Promptへ書き足すと、変更箇所が追えず、テスト範囲も曖昧になります。
共通化するのは、意図理解、状態保持、Tool呼び出し、HandoffといったAgentの仕組みです。業界固有の受付条件、承認順序、例外規則は、WorkflowとPolicyへ分離します。例えば返品なら、REQUESTED → ELIGIBILITY_CHECK → CUSTOMER_CONFIRMATION → REFUND_PENDING → RESOLVEDの状態を持ち、各遷移で許可するActionを限定します。
この分離により、モデルを変更しても業務規則を作り直さずに済みます。反対に、規則が改定されたときもPrompt全体を調整せず、対象Policyとテストケースを更新できます。
設計の起点は委任範囲
企業向けAgentの設計では、モデル、Tool、Workflowを一つの塊として考えない方がよいと思います。Agentが提案し、Policyが許可し、業務システムが実行し、必要な場面では人が引き継ぐ。この責任分担が決まると、評価すべき失敗も具体的になります。これは、私たちがUdeskの企業顧客体験とAI Agentの場面で継続して考えている課題でもあります。
皆さんは問い合わせAIを設計するとき、Tool権限、有人Handoff、業界Workflowのどこから境界を決めますか。実装で最も崩れやすかった部分があれば、ぜひ知りたいです。