ウェビナーまとめ:AdmiralがAIエージェントで保険に関する電話対応を行う方法
- 執筆者
- Dana Muntean
- 公開日
- 最終更新日
聴くこの記事を聴く
Admiralは、英国、イタリア、フランス、スペインを含む世界各国で、複数の言語による年間数百万件の顧客対応を行っています。
最新のウェビナー「Behind the Agent: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)テクノロジーだけの話ではない
目指すのは、P&L、顧客体験、従業員体験の変化です。
成果について合意できれば、テクノロジーの選択肢はおのずと見えてきます。Dom氏は、テクノロジーから始めないことを勧めています。
3)ガバナンスを早期に構築する
初期段階から適切なタッチポイント、適切なKPI、適切なデータを用意しておくと、意思決定が格段に容易になります。彼女の言葉を借りれば、避けるべきなのは勘に頼り、誰にも使われず、重視するどの指標も改善しない「とても立派な成果物」に終わることです。
展開モデルも重要でした。Admiralでは、グループ内の一部を選び、ひとつのテーマを深く実験したうえで、そこで得た知見を他のすべての領域に展開しています。
まず迅速な横展開を行い、その後に本格展開します。Dom氏によれば、1つのドメインで1つのユースケースだけに取り組むと大幅に遅くなります。そこで、車輪の再発明を10回繰り返さないという明確な規律を設けています。
デモ1:完済見積もり(Admiral Money)
シナリオ:顧客がローンを早期に完済したいと考えています。必要なのは完済に必要な金額だけ、というシンプルな問い合わせです。
従来、この金額を知るには、IVRを操作し、人間の担当者による本人確認を受け、バックエンドシステムで計算が実行されて画面が読み込まれるのを待ち、その後PDFが届くのをメールボックスで待つ必要がありました。答えが1つだけの質問に、5分かかるプロセスです。
Admiralの生成AIグループ責任者であるDan Clark氏が、チームが構築したものを紹介しました。
紹介された内容:
- 認証は、他の処理より先にワークフローの開始時点で独立したサブエージェントとして実行されます。
- 見張り役のサブエージェントが、発信者がAIエージェントと話せる対象かを確認します。脆弱な状況にある顧客や延滞中の顧客は、チームがさらに多くのエッジケースを学習する間、人間の担当者が対応する優先キューへ転送されます。
- エージェントは必要な回答を予測してあらかじめ収集し、レガシー画面の表示を待つのではなく、API駆動で処理します。人間の担当者では約5分かかる同じ手続きが、エージェントでは約2分半で完了します。
- 成功は、顧客が認証を完了し、精算見積もりを取得できたかどうかで測定され、エスカレーションとは別に追跡されます。
- 通話の最後に、フィードバックエージェントが顧客に体験を5段階で評価するよう求めます。エスカレーションされなかった通話は、ほぼすべて4または5の評価です。
重要な理由:時間短縮は、AIが人の代わりに回答することだけによるものではなく、画面駆動ではなくAPI駆動のワークフローによるものです。Dan氏によれば、これは通話時間の短縮と、その結果としての顧客体験の向上が重要です。また、現在のエスカレーションは、チームが学習の過程で意図的に設けている制限を反映したものであり、エージェントが支援に失敗したことを意味するものではありません。
デモ2:Olivia(L’Olivier)
シナリオ:フランスの顧客が保険契約について質問があります。ウェブサイトでチャットを開くと、旧式のツリー型ツール(「これならA、あれならBを押す」)であるOllie Botが表示されます。質問は選択肢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の仕組みを理解し、アイデアを適切に構造化し、エージェント型コーディングを活用して提供することへの比重が高くなります。
コアチームの周囲では、業務の専門家とビジネスオーナーが、プロダクトと技術の人材とともに小規模なポッドを構成します。彼女の言葉を借りれば、「同じ部屋に閉じ込めて」一緒に構築・テストし、その後、実際の顧客に試してもらい改善点を見つけます。
McKinseyでは、テクノロジーに1ポンドを使うごとに、業務プロセスの再設計に3ポンド、変革管理に5ポンドを使うと言っていました。
Admiralのロードマップの優先順位付け
ここでもハブ&スポークモデルが機能しています。グループは、大規模プロジェクトに対して譲れない優先順位を設定します。リスクと価値がより高く、実現可能性がやや低い領域では、中央のサポートによってボトルネックを解消できます。スポークには、キャパシティがあり、トップダウンのガイドラインに従う限り、ボトムアップのイノベーションを進める余地があります。
チームが構築する将来のロードマップは、IVR、音声エージェント、担当者、チャネルのどこをまたいでも、顧客が同じことを繰り返す必要がない状態を目指しています。引き継ぎのたびに、文字起こしだけでなく、意図、感情、脆弱性のシグナルも引き継がれます。
セッション全編を見る
Admiralは、保険業界で最高の顧客体験を構築するという目標に近づくため、検証基準、組織内の賛同、テクノロジースタックを一体で再構築しました。
ウェビナー全編はこちら。
.webp&w=3840&q=80)
.webp&w=3840&q=80)


