ウェビナーまとめ：AdmiralがAIエージェントで保険に関する電話対応を行う方法

Admiralは、英国、イタリア、フランス、スペインを含む世界各国で、複数の言語を通じて年間数百万件の顧客対応を行っています。

最新ウェビナー「エージェントの裏側：AdmiralがAIエージェントで保険に関する電話対応を行う方法」では、Admiralの生成AI部門責任者であるDominika Kampa氏が、この規模の対応を担うAIレイヤーをチームがどのように構築しているかを、アーキテクチャ、テスト基準、組織的な取り組みも含めて解説しました。

Admiralが目指したのは、保険業界で最も信頼される顧客体験の構築です。

Admiralの目標は、これまでとは異なる次元の顧客体験をつくることでした。

顧客の問題を実際には解決せず、会話だけをすばやく終えるエージェントをつくるのは簡単です。

目指すのは、すべての顧客、すべてのチャネル、そして重要なあらゆる瞬間に、その場で解決策を提供することです。あるいは、顧客、その文脈、解決しようとしている状況を理解している人間の担当者へ引き継ぐことです。

主要指標は、初回問い合わせでの解決率を90％に到達させることでした。また、24時間365日のサービス提供、簡潔なやり取り、NPSの大幅な向上も追跡していました。

自己完結率は副次的な指標でした。最初の音声ユースケースでは、エージェントのほうが速いと顧客に認知されるにつれ、チームはこの数値を大幅に改善しました。

しかし、軸となったのは解決でした。Admiralでは、通話がエスカレーションされたかどうかとは別に、顧客が電話をかけた目的を実際に達成できたかを独立した指標として追跡しています。そのため、意図的に人間へ引き継いだ場合は、決して失敗とは見なされません。

規制産業における「良い」の基準

Admiralの本番運用に向けた基準は高く設定されています。エージェント型ソリューションは、本番導入前に、現時点の人間の担当者と同等以上でなければならないと考えています。

かつては最も経験豊富な担当者の勘に宿っていたエッジケースの知識も、今ではユースケースごとに明示的にテストする必要があります。

実際に、チームは意図的に対象範囲の境界を定めました。たとえば、脆弱な状況にある顧客や延滞中の顧客のケースは、ユースケースに関するエッジケースをさらに学ぶ間、人間の担当者にルーティングされます。

保険規制の多くは結果ベースであるため、Dom氏は実務的な見方をしています。顧客と事業にとっての結果が意図どおりであれば、「どのように」実現するかには柔軟性があるという考えです。

賛同は指示だけでは得られない

規制対象の組織が、言われたからという理由だけでAIを導入することはありません。

Dom氏はAdmiralに入社する前、McKinseyで長年にわたり変革管理プログラムに携わっていました。現在、エージェント型AIの導入を提案する同業者に何を伝えるかと問われると、そのプレイブックから3つの原則を挙げました。

1）人は、自ら構築に関わったものを支持する

Admiralが懐疑論に対して取った答えは、懐疑的な人々の目の前にツールを直接置くことでした。

チームは、エージェント型AIとは何かをわかりやすく伝えるため、グループ上位50名のリーダーを含む組織全体でデモと学習セッションを実施しました。ElevenLabsとDom氏は、グループCEOのMilena Mondini de Focatiis氏を含むリーダーシップチームがゼロからエージェントを構築するトレーニングデーを開催しました。Dom氏によれば、参加者は「実際に…体験を楽しんだ」といいます。

2）テクノロジーだけの話ではない

目指すのは、損益の変化、顧客体験の変化、従業員体験の変化です。

結果について人々の認識がそろえば、テクノロジーの選択肢は見えてきます。Dom氏の助言は、テクノロジーから始めないことです。

3）早期にガバナンスを構築する

初期段階から適切な接点、適切なKPI、適切なデータを整えることで、意思決定は大幅に容易になります。彼女の言葉を借りれば、避けるべきパターンは勘に頼り、誰も使わず、重要な指標を何一つ動かさない「とても立派な成果物」を生み出してしまうことです。

展開モデルも重要でした。Admiralのアプローチは、グループ内の一部を選び、ひとつのテーマを深く実験したうえで、得られた学びを他のすべての場所に展開するというものです。

まず迅速に後続展開を行い、その後に全面展開します。Dom氏によれば、大幅な遅延につながる単一領域での単一ユースケースではなく、同じものを10回つくり直さないという意図的な規律です。

デモ1：一括返済見積もり（Admiral Money）

シナリオ：顧客がローンを早期返済したいと考えています。必要なのは、返済に必要な金額を知ることだけです。

従来、この金額を知るには、IVRの案内を進み、人間の担当者による本人確認を受け、バックエンドシステムが計算を実行して画面が読み込まれるのを待ち、その後PDFが受信トレイに届くのを待つ必要がありました。答えがひとつしかない質問に、5分のプロセスが必要だったのです。

Admiralの生成AI部門責任者であるDan Clark氏が、チームが構築したものを紹介しました。

デモで示された内容：

• 認証は、他の処理が実行される前に、ワークフローの開始時点で独立したサブエージェントとして行われます。
• 見張り役のサブエージェントが、発信者にAIエージェントと話す資格があるかを確認します。脆弱な状況にある顧客や延滞中の顧客は、チームがさらにエッジケースを学ぶ間、人間の担当者がいる優先キューへ転送されます。
• エージェントは必要な回答を予測して事前に収集し、旧来の画面を待つのではなくAPI駆動で処理します。人間の担当者では約5分かかる同じ手続きが、エージェントでは約2分半で完了します。
• 成功は、顧客が認証を完了し、一括返済見積もりを取得できたかで測定され、エスカレーションとは別に追跡されます。
• 通話の最後に、フィードバックエージェントが顧客に体験を1から5で評価するよう求めます。エスカレーションされなかった通話は、ほぼすべて4または5の評価になっています。

重要な理由：時間を短縮できるのは、人間の代わりにAIが回答するからではなく、ワークフローが画面駆動ではなくAPI駆動であるためです。Dan氏の言葉を借りれば、これは通話時間の短縮と、それによる顧客体験の向上が重要です。また、現在のエスカレーションは、エージェントが支援に失敗したことを示すのではなく、チームが学習の過程で設けた制約を反映しています。

デモ2：Olivia（L’Olivier）

シナリオ： フランスの顧客が保険契約について質問があります。ウェブサイトでチャットを開くと、昔ながらのツリー型ツールであるOllie Bot（「これにはA、あれにはBを押す」）が表示されます。質問は選択肢AにもBにも当てはまらないため、答えを得られないまま離脱します。

L’Olivierが置き換えようとしたのは、そのような体験でした。チームは現在、ElevenLabs上でナレッジベースエージェントのOliviaを構築し、サイトで公開しています。

デモで示された内容：

• システムプロンプト、最初のメッセージ、ワークフロー、サブエージェントはすべて、英語から翻訳するのではなくフランス語で直接作成されました。Dan氏は、顧客の言語でプロンプトを与えるとモデルの関与の仕方が異なることを示す研究を挙げており、チームもこの方法で大幅に優れた結果を得ました。Oliviaは必要に応じて英語を自動検出し、英語で応答します。
• 実際の顧客との会話をナレッジベースと照らし合わせて確認し、抜け漏れを特定します。修正は通常、1～2時間以内に本番エージェントへ反映されます。
• 変更はブランチでデプロイされ、トラフィックを段階的に分割します。1％、2％、5％、10％、25％、50％、そして100％へと進めます。本番トラフィックに届く前に、シミュレーションテストと手動プレビューを行います。データが変更を支持しなければ、トラフィックは即座にゼロへ戻せるため、ロールバックは必要ありません。
• ブランチの完全なサイクルは、開始から完了まで数時間から1日で終わります。2週間のスプリントと2週間のデプロイはもうありません。

重要な理由：リリースサイクルが数週間から数時間へ短縮されたこと自体も注目に値しますが、より大きな示唆は、言語が単なるローカライズの詳細ではなく、モデルの推論の仕方を変える可能性があることです。

新しい市場では、どんなプレイブックもそのままでは通用しない

発話の順番に関する慣習、割り込みへの許容度、自然な会話のリズムと見なされるものは、市場によって大きく異なります。

万能の解決策はありません。Dom氏によれば、有効なのは、プロンプトとアーキテクチャを理解するエンジニアと、市場の文脈を具体化できる現地組織の事業オーナーを組ませ、そのペアを展開の単位として扱うことです。

構築そのものは、市場ごとにそれほど大きくは変わりません。異なるのは導入です。Dom氏は、これは顧客対応に限らず、あらゆるAI導入に当てはまると考えています。

そのためチームは、基盤となるモデルよりも、顧客への説明（ウェルカムメッセージ、位置付け、IVRメッセージなど）に多くの時間を費やすと見込んでいます。

市場をまたぐ公平な対応

保険において、脆弱性の検知は、すべての市場、言語、チャネルで一貫して機能しなければならない基本要件です。

Admiralは複数の経路で検知します。脆弱性については特に、どちらか一方だけを信頼するのではなく、確立された機械学習モデルと生成AIを意図的に併用しています。これにより、どのシグナルが先に発火したかにかかわらず、脆弱な状況にある顧客をどの段階でも検知し、適切に対応できます。

この基準は、テクノロジーにケースを任せる前から適用されます。一括返済見積もりエージェントでは、見張り役のサブエージェントがすべての発信者をスクリーニングし、脆弱な状況にある顧客や延滞中の顧客を、人間の担当者がいる優先キューへ直接振り分けます。これは、チームがさらにエッジケースを学ぶ間に設けた意図的な境界です。

また、顧客の行動は予測できないため（たとえば、Oliviaにオニオンスープの作り方を尋ねた人もいました）、チームはガードレールと予期しない事象の能動的なフラグ付けを組み合わせ、誰がどのようにツールを利用しているかを常に把握しています。

エージェントを支えるチーム

Admiralはハブ＆スポークモデルを運用しています。グループレベルの専門性は「ハブ」に置き、市場、顧客、従業員を理解する現地の専門家は「スポーク」に配置されます。

センター・オブ・エクセレンスは2つに分かれます。1つ目は、戦略、ロードマップ、プロダクト設計、A/Bテストを含む成果検証を担う価値創出部門です。2つ目は、構築されるすべてのものが基準を満たし、既存のシステム群と統合されることを担保する、エンジニア、アーキテクト、デリバリー担当者からなる技術部門です。

Dom氏が考える未来のAIエンジニアは、コードを書くことよりも、生成AIの仕組みを理解し、アイデアを適切に構造化し、エージェント型コーディングを活用して成果を届けることに重きがあります。

コアチームの周りには、プロセスの専門家と事業オーナーが、プロダクトと技術の人材とともに小規模なポッドとして編成されます。彼女の言葉では、「同じ部屋に閉じ込めて」一緒に構築・テストし、それを実際の顧客に使ってもらって不具合を見つけます。

Admiralがロードマップの優先順位を決める方法

ここでもハブ＆スポークモデルが機能します。グループは大規模プロジェクトに対して、譲れない優先順位を設定します。リスクと価値は高く、実現可能性はやや低いため、中央の支援によってボトルネックを解消できます。スポークには、キャパシティがあり、トップダウンのガイドラインの範囲内にとどまる限り、ボトムアップのイノベーションを進める余地が与えられます。

チームが構築している将来のロードマップは、IVR、音声エージェント、人間の担当者、チャネルのいずれをまたいでも、顧客が同じことを繰り返す必要がない状態を目標としています。引き継ぎのたびに、文字起こしだけでなく、意図、感情、脆弱性のシグナルも引き継がれます。

セッション全編を見る

Admiralは、保険業界で最高の顧客体験を構築するという目標に近づくため、検証基準、組織内の賛同、テクノロジースタックを一体で再構築しました。

ウェビナー全編はこちらからご覧ください。