AIエージェントは、顧客体験の中核を担っています。顧客はAIエージェントとの対話を通じて質問し、回答を得ながら解決へと進みます。ただし、AIの能力が進化するにつれ、その体験を裏側で支える仕組みの設計も変わりつつあります。
カスタマーサービスの自動化を大規模に展開するには、対話の中で問い合わせを解決するだけでは足りません。業務プロセスを実行し、判断や処理の正しさを検証し、処理の進め方を制御できることが必要です。さらに、対応結果から学び、次の解決の質を高めることも求められます。こうした機能は、顧客との対話を支えるほか、サポート担当者の支援、依頼内容の確認、処理の開始にも活用でき、バックグラウンドで先回りして動かすことも可能です。
そのため、自律型サポートワークフォース（Autonomous Service Workforce）は、顧客に応対するAIエージェントだけで構成されるものではありません。専門業務を担うエージェントと自動化の仕組みが連携し、解決に必要な作業を分担する体制です。対話を担うAIエージェントは引き続き顧客体験の中核にあり、その背後では、個別の判断、処理、確認、改善を受け持つエージェントが支えます。
価値があるのは、単にエージェントの数を増やすことではありません。すべてのプロセスを1つの巨大なエージェントや1人の統括管理者に依存させず、業務全体へ自動化を広げられることです。
複雑なプロセスを構成する、一つひとつの判断
エージェント型のプロシージャ（自動化の手順）を使えば、質問から解決まで、一連のユースケースを自動化できます。たとえば返金のプロシージャでは、注文番号の収集、注文状況の確認、返金ポリシーの確認、返金対象に該当するかどうかの判断、適切な処理の開始といった流れが考えられます。
顧客にとっては1件の依頼でも、企業側では通常、複数のチームが担当する判断や処理が連なっています。サポート部門には依頼の背景情報が必要です。財務部門は返金対象となる条件を定め、リスク管理部門は不審な動きがないかを確認し、業務運用部門が返金を実行する、といった分担が考えられます。
プロシージャはこれらの手順をつなぎますが、各業務の専門知識を持つ部門が変わるわけではありません。
自動化が広がると、プロシージャが扱う業務の範囲も広がり、関係するチーム、判断、システムが増えていきます。個々の手順は単純でも、連携先や例外処理、業務ロジックが積み重なれば、全体をひとまとまりとして管理することが難しくなります。
こうした複雑なプロシージャも、分割できない1つの自動化処理ではありません。成果に至るまでの仕事を順につないだものです。それぞれの仕事を定義すれば、何をしているかが明確になり、管理、再利用、統制、改善をより計画的に進められます。
カスタムエージェントが業務ロジックを機能に変える
カスタムエージェントを使えば、こうした仕事をそれぞれ専用のエージェントに任せられます。
返金可否判定エージェントは、必要な情報を集め、該当するルールを適用して、明確な判定結果を返せます。不正検知エージェントは、依頼について追加の確認が必要かどうかを評価できます。申請処理エージェント（Claims Agent）は、添付ファイルを読み、重要な情報を抽出して、その後の処理経路を判断できます。
これらのエージェントが担うのは、対話全体ではなく、特定の業務ロジックです。対話を担うAIエージェントは、必要に応じて専門エージェントを呼び出し、その出力を基に次の手順を判断して、結果を顧客に伝えます。
同じ専門エージェントを、サポート業務の別の場面でも活用できます。Agent Copilotから呼び出して人間の担当者を支援したり、アクションワークフローの一部として実行したりすることが可能です。顧客と直接話さず、対話と並行して動かすことも考えられます。たとえば検証エージェントなら、処理を実行する前に情報を確認できます。監視エージェントなら、特定の状態を検知し、顧客からの問い合わせになる前にアラートを出すことも可能です。
依存関係が見えにくい一体型のワークフローと、各業務の責任が明確なエージェント群を組み合わせた体制との違いは、ここにあります。
利点は管理のしやすさにとどまりません。判断や処理を再利用可能な機能にすれば、プロシージャごとに作り直さず、複数のユースケースで使えます。問題が起きた場合も、解決の仕組み全体をひとまとめに捉える必要はありません。ナレッジ、検証、判断、最終的な処理のどこに問題があるのかを特定できます。
改善すべき箇所も絞り込めます。対応結果のデータや運用中に得られる情報から、どの手順に指示の改善、背景情報の追加、ルールの変更、新たな処理が必要なのかを把握できます。実際に仕事が行われる単位で、エージェント群を改善していけるのです。
業務ロジックに応じた責任分担
このように構成要素を分けると、サービスの自動化を構築・管理する人の役割も変わります。
管理者が、AIエージェントの動作を最初から最後まで定義できるほど、すべての業務プロセスを詳しく理解する必要はなくなります。返金ポリシー、返品プロセス、不正検知ルール、アカウント関連のロジック、それらをつなぐあらゆるシステム連携を、すべて引き受ける必要もありません。
それぞれの判断に詳しいチームが専門知識を提供することで、各エージェントが業務に役立つようになります。財務部門は返金対象となる条件を定義し、そのルールを適用するエージェントの構築や保守に協力できます。リスク管理部門は不正の確認を担うことができ、物流部門は返品プロセスを定義できます。サポート部門は、顧客との対話と、依頼をエスカレーションする際の顧客体験に責任を持てます。
プラットフォーム上に会社の組織図を再現する必要はありません。必要なのは、誰がどの判断に責任を持つかを明確にし、管理できるようにすることです。
ここで役割を担うのが、AIサービスアーキテクトです。プラットフォーム、エージェント群の全体設計、そこから得られる成果に対する責任を引き続き持ちます。エージェント同士の連携方法、アクセスできるナレッジや実行可能なアクションを決め、ガードレール、検証、エスカレーション経路をどこに設けるかを設計します。
AIサービスアーキテクトは、各業務プロセスを担当するチームとも協力します。チームと一緒に専門エージェントを構築することも、チーム自身がロジックを定義・管理できるよう、ツールと責任を委ねることも可能です。そのうえで、各機能を組み合わせ、一貫した解決の仕組みを構築します。
各プロセスの担当チームは、自分たちのエージェントに組み込む専門知識に責任を持ちます。AIサービスアーキテクトは、それらをつなぐシステムに責任を持ちます。
個別の自動化から、エージェントが連携する体制へ
Zendesk Resolution Platform全体では、このような変化が進んでいます。顧客対応の最前線に1つの巨大なエージェントを置く自動化から、対話、ワークフロー、バックグラウンド処理を横断して動く、専門機能を備えたエージェント群へと移りつつあります。
各構成要素の目的と責任者が明確になれば、自動化の管理がしやすくなります。各チームが業務の専門知識を提供し、中央への集中による業務の停滞を避けられるため、自動化を拡大しやすくなります。1つの判断や処理を複数のユースケースに使えるので、再利用も容易です。顧客が問い合わせる前にエージェントが検証、監視、処理を実行できるため、先回りした対応も可能になります。
さらに、結果に影響した具体的な手順を特定して見直せるため、自動化の改善も進めやすくなります。
カスタムエージェントと、エージェントが連携する体制は、単にプロシージャにAIを追加するための別の手段ではありません。業務ロジックを再利用可能な機能へ変えるための仕組みです。
こうしてプラットフォームは、一体型から、機能ごとに分かれた構成へ、そして自ら改善する仕組みへと進化します。対話を担うAIエージェントは引き続き顧客体験の中心にあります。一方、解決の裏側の仕事は、適切な機能と専門知識を持ち、適切な責任者の下で動く専門エージェントが連携して分担します。
