目次
出発点は「業務」
業界特化型AIエージェント（Industry Agents）を構築するにあたり、私たちが最初に疑った前提の1つが、「出発点はAIである」という考え方でした。実際はそうではなく、出発点は業務でした。
組織がAIの検討を始めるとき、「どんなAIエージェントを作るべきか」の問いから始まることがよくあります。私たちは、その問いの立て方が適切ではないと考えています。より良い問いは、「どの業務を自動化しようとしているのか」です。
この転換1つで、その後の設計判断のほぼすべてが変わります。顧客は、AIエージェントがどれほど賢そうに話すかで成功を測りません。仕事が片付いたかどうかで測ります。
本質は質問を理解することではなく、仕事をやり遂げること
返品のような単純な例を取っても、「返品」そのものを自動化したい人は実際にはいません。自動化したいのは、返品の裏にある判断です。
顧客は返品の条件を満たしているか、商品はまだポリシーの範囲内か、例外を認めるべきか。交換に応じられる在庫はあるか、結果を変えるべきリスクのシグナルはないか。誰かの承認が必要か、次にどのアクションを取るべきか。
それが業務です。会話は、その仕事が始まるきっかけにすぎません。
汎用型のAIモデルは、言葉を理解し、依頼について推論できます。しかし、顧客が何を言ったかを理解することと、企業が次に何をすべきかを理解することは同じではありません。最も大きな価値を生む仕事は、多くの場合、会話の裏側にあります。
私たちはこれを、サービスにおける「煩雑な中間工程（messy middle）」と呼んでいます。ビジネスのコンテキストやポリシー、システム、アクション、判断が交わる場所です。
1つの巨大なエージェントを作らなかった理由
私たちが下した最も重要な設計判断の1つは、あらゆることをこなそうとする1つの巨大なエージェントを作らない、というものでした。
企業はそのような体制で動いていないからです。小売業者には、購入サポート、返品、決済、不正対策、フルフィルメント（受注から出荷までの処理）、アカウント管理、そしてあらゆる例外を1人で担当する人はいません。いるのは複数のスペシャリストです。
AIも、この形に倣って作りました。
業界特化型AIエージェントは、それぞれ絞り込まれた業務を担います。たとえば、購入サポートとレコメンドを担当するAIエージェントがあれば、返品と交換を管理するAIエージェントもあり、返金や配送の問題にもそれぞれ別のAIエージェントが対応する、といった形です。オーケストレーション層がこれらのAIエージェントの間を調整し、適切なコンテキストを渡して、仕事を次のステップへ振り分けます。
その結果、システムはよりモジュール化され、AIエージェントごとに、テストや統制、測定、改善の対象となる範囲も小さくなります。
AIが毎回、業界を学び直す必要はない
小売業者の運営方法は一様ではありませんが、どの小売業者も返品を処理します。取引に関する異議申し立ての調査は、扱う金融商品が違ってもどの銀行も行う業務です。テクノロジー企業でも、作るソフトウェアにかかわらず、トラブルシューティングとアカウントの管理は共通の仕事です。
業務そのものは、驚くほど共通していることが少なくありません。各社の違いを生んでいるのは、ビジネスルールです。
そのため、業界特化型AIエージェントは、その業界の企業に共通する業務の専門知識を出発点にしています。第一弾の業界特化型AIエージェントは、購入サポートと商品探し、注文管理、返品と交換、返金、フルフィルメントと配送、請求と決済、プロモーション、テクニカルサポート、アカウント認証といったECの業務に焦点を当てています。
目的は、すべての企業を1つの運営モデルに押し込めることではありません。より良いスタート地点を提供することです。
第一弾の業界特化型AIエージェントは、購入サポートと商品探し、注文管理、返品と交換、返金、フルフィルメントと配送、請求と決済、プロモーション、テクニカルサポート、アカウント認証といったECの業務に焦点を当てています。
業界の専門知識で始め、自社の専門知識で仕上げる
ある小売業者は30日以内の返品を認め、別の小売業者は60日まで認めるかもしれません。長年の顧客には交換品を自動で承認する企業もあれば、一定の注文金額を超えると承認を必須にする企業もあります。
こうした違いは、珍しい例外ではありません。それこそがビジネスの実態です。
業界特化型AIエージェントは、こうした現実に合わせて機能するよう設計されています。自社のナレッジとポリシーを使い、関連データが存在するシステムに接続し、設定されたガードレールと承認経路の範囲内で動作できます。
ここが、業界特化型AIエージェントとカスタムエージェントがかみ合う場所でもあります。業界特化型AIエージェントは、業界に共通する業務の出発点を提供します。カスタムエージェントは、特定の企業に固有のポリシーや判断、例外、ワークフローを担います。
業界特化型AIエージェントは業界の共通点を理解し、カスタムエージェントは企業ならではの違いを理解します。
もし私がいま、業界特化型AIエージェントを導入するなら
どのAI機能を導入するかという問いから始めることはしません。まずは業務の洗い出しに取りかかります。
チームが週に数百回、数千回と処理している依頼は何か、ビジネスのコンテキストを必要とする判断はどれか。複数のシステムをまたぐワークフローはあるか、完了の定義が明確な業務はどれか。固定された手順ではなく、解釈や判断を必要とするプロセスはどこにあるか。
私なら、最初にこうした領域に目を向けます。
すべてのステップがまったく同じ経路をたどるなら、従来型の自動化のほうが適しているかもしれません。AIエージェントが向いているのは、ワークフローにコンテキストや解釈、経路の選択が必要な場合でしょう。
目的はAIエージェントの数を最大化することではなく、適切な業務を自動化することです。
アーキテクチャの考え方
業務が明確になれば、アーキテクチャの検討も容易になります。
AIエージェントには、依頼を理解するのに十分なコンテキスト、判断を左右するポリシーとナレッジ、仕事の完了に使うシステムとアクションへのアクセスが必要です。加えて、権限、ガードレール、エスカレーションに関する明確な統制も欠かせません。
そこで私たちは、業界特化型AIエージェントを実践的な4つの層で捉えています。
指示：AIエージェントは何に責任を持ち、どの判断基準に従うべきか
コンテキスト：顧客や会話、ビジネス、業務運営のどの情報が必要か
ツール：どのアクションやインテグレーション、ワークフロー、ナレッジ、他のエージェントを使えるか
統制：どの権限やガードレール、エスカレーション経路、評価基準が適用されるか
基盤となるモデルは重要ですが、システムの一部にすぎません。残りを決めるのは業務です。
具体例：返金リクエスト
ある顧客が「マウンテンバイクのリアディレイラーが初めて乗ったときに壊れました。返品して、新しいTrailProモデルと交換したいです」と伝えてきたとします。
AIエージェントはまず、顧客と注文を特定します。次に、判断に必要なコンテキストを集めます。購入履歴、配送状況、返品と保証のポリシー、在庫、決済情報、関連するリスクのシグナルです。
業界特化型AIエージェントは、商品と注文の詳細にはShopify、配送と返品の情報には返品管理・配送追跡サービスのNarvar、決済情報にはStripe、リスク情報にはEC向け不正検知サービスのRiskifiedを使えます。Zendeskは会話と顧客のコンテキストに加えて、依頼の処理方法を決めるナレッジとビジネスルールを提供します。
依頼が設定された条件を満たしていれば、AIエージェントは返品手続きを開始し、顧客に必要な案内を提供し、今後の流れを伝えられます。満たしていなければ、追加情報を求める、確認に回す、集めたコンテキストをそのまま添えて人間の担当者に引き継ぐ、といった対応が可能です。
顧客から見れば1つの会話ですが、その裏では連携したワークフローが動いています。
業界特化型AIエージェントの構築で学んだ4つのこと
- プロンプトよりもポリシーが重要です。役に立つAIエージェントは、誰が条件を満たすのか、何が例外に当たるのか、いつ行動すべきか、いつ人が依頼を確認すべきかを知っていなければなりません。こうした判断は明示されている必要があります。
- 業務は思った以上に多くのシステムにまたがっています。顧客には単純に見える依頼でも、CRM、注文管理、決済、在庫、不正検知、配送、社内ポリシーの各システムが必要になることがあります。データがどこにあるかは、顧客にとって問題ではありません。顧客が求めているのは、仕事が片付くことです。
- 専門特化により、AIは制御しやすくなります。業務が定義されていれば、テスト、測定、統制、改善の対象となる範囲は小さくて済みます。AIエージェントがどこで止まり、人間の担当者や他のAIエージェントがどこから引き継ぐべきかも把握しやすくなります。
立ち上げだけでなく、変化に備えて構築します。AIエージェントは構築して終わりではありません。ビジネスもポリシーも、製品や顧客も移り変わっていきます。業界特化型AIエージェントはZendeskに組み込まれているため、チームは構築、テスト、デプロイ、監視、改善を同じ環境で行えます。テストとシミュレーションでデプロイ前に問題を洗い出せるほか、トレーサビリティ（処理経過の追跡）により、AIエージェントがどのように結果に至り、どのナレッジやツールを使ったかを理解しやすくなります。
AIエージェントが本番稼働すると、パフォーマンスと成果のデータから、うまくいっている点、行き詰まっている点、変更が必要な点が見えてきます。こうしたシグナルは、ZendeskのResolution Learning Loopに取り込めます。この仕組みが、ビジネスの変化に合わせてチームがAIエージェントの指示、ナレッジ、ポリシー、アクションを継続的に改善する助けになります。
可能性はECにとどまらない
ECから始めるのは、業務に専門分野に特化したAIエージェントを問い入れる価値がとりわけ明確だからです。小売業者は、売上、コスト、顧客との関係に直結する反復的な業務を大量に抱えています。
しかし、このモデルの適用範囲はより広いものです。同じアプローチは、金融サービス、テクノロジー、ヘルスケアなどの業界にも応用できます。業務は異なっても、設計の原則は同じです。
起点は業界に共通する業務です。その専門知識をエージェントに組み込み、仕事を完了するために必要なシステムに接続したうえで、各企業に固有の部分は、その企業自身が制御できるようにします。
私たちが本当に作ろうとしているもの
サービスの未来は、あらゆることをこなそうとする1つの汎用AIエージェントではなく、専門分野に特化したAIエージェントたちが連携するワークフォースだと、私たちは考えています。
各AIエージェントには担当する業務があり、その業務に必要なコンテキストを理解し、必要なシステムとアクションを使えます。互いに連携しながら、顧客の依頼を会話から成果まで進められます。
私たちは、この考えに基づいて業界特化型AIエージェントを作りました。企業に設定すべきAIフレームワークをもう1つ増やしたり、業界にすでに存在する専門知識を各社に作り直させたりするためではありません。
出発点は業務です。エージェントに適切なコンテキストを与え、仕事が実際に行われるシステムに接続します。ルールを定義して成果を明確にし、そのうえで改善を続けます。
こうして、業界の専門知識がアクションに結びつきます。
「設計の単位はモデルではなく、業務である」
