長く使えるボイスエージェントの構築：現場配属型エンジニアリングから得た教訓

多くの組織では、サポート業務のポイントソリューションは長い間「ディフレクション（問い合わせ回避）」で評価されてきました。つまり、通話件数を減らし、ライブエージェント（人間の担当者）とのやり取りを最小限に抑えることが重視されてきたのです。しかし、ディフレクションは必ずしも問題解決を意味しません。この2つの間にギャップがあり、そこが顧客体験の分断点となっています。このギャップを埋めるには、エージェントがデータだけでなく、実際に対応できるシステムにもアクセスできることが必要です。その結果、エージェントは返金処理や購入手続きの案内、必要に応じて状況を把握した上で人間の担当者に引き継ぐことができます。これにより、企業は大規模な顧客対応が可能になり、人間のサポートチームの負担を大幅に減らしつつ、顧客と担当者の双方にとってより良い体験を実現できます。最近のRevolutでの導入事例では、世界で7,000万人の顧客を持つフィンテック企業において、解決までの時間が8分の1に短縮され、通話成功率は99.7％を達成しました。

この規模の変革を進めるには、企業のコアミッションと密接に結びつけ、経営層の強い後押しのもと、段階的に進める必要があります。技術面では、非構造化環境での推論には本質的なリスクが伴うため、慎重な管理が不可欠です。エージェントにCRM（顧客管理システム）を横断して操作したり、POSシステムで注文を変更したり、案件をエスカレーションできる権限を与える場合、ガバナンスモデル自体がモデルそのものと同じくらい重要になります。重要なのは、エージェントが実際の業務をこなせるかどうかではなく、安全かつ継続的に運用するためにどのような仕組みが必要かという点です。

この記事では、私たちの経験をもとに、初回導入から全社規模へのスケールまで、成功するエージェントのポイントをご紹介します。

エージェントの出荷とソフトウェアの出荷の違い

エージェント構築の詳細に入る前に、ボイスエージェントの導入と従来型ソフトウェアの導入を比較してみましょう。企業が何十年も行ってきた従来のソフトウェア導入と比べると、エージェントは「従来型ソフトウェア」と「コアオーケストレーター」という2つの要素に分けて考えることができます。

ソフトウェア：

ソフトウェア：可観測性とガバナンス

コアオーケストレーター

コアオーケストレーターのコンポーネントは本質的に予測が難しいですが、エージェントの回答品質や体感レイテンシーなど、実行時のパフォーマンスを左右します。従来のソフトウェアと異なり、これらのコンポーネントは自然言語や音声を扱うため、入力の幅が非常に広く、言い回しや文脈、バックグラウンドノイズ、ユーザーの行動のちょっとした違いで、出力が大きく変わることがあります。そのため、従来のテストだけでは不十分です。エージェントは何百ものテストケースを完璧にクリアしても、本番環境では予想外の失敗をすることがあります。バージョン管理、A/Bテスト、電話連携や初回メッセージの設定などが該当します。これらの要素は導入後にほとんど変化しないため、動作が非常に予測しやすいのが特徴です。堅牢なエンジニアリングにより、これらの機能を迅速に構築し、指標・トレース・ログなどで本番環境のパフォーマンスを深く把握できます。このレイヤーでのレイテンシ改善は、キャッシュ、コネクションプーリング、インフラ拡張、プロトコル最適化など、よく知られた手法で確実に効果を発揮します。

このレイヤーでのレイテンシーも決定的ではなく、モデル推論時間、音声アーティファクトの挿入、ツールの呼び出しチェーン、生成系システム特有のばらつきなどが影響します。これらをうまく管理するには、評価フレームワークや本番監視、そして事前の想定だけでなく実際の会話データに基づいて継続的に改善する姿勢が必要です。

この違いを理解することで、組織は導入の進め方を考えやすくなります。まずはリスクの低い、組織にとって意味のあるユースケースから始め、システムへの信頼が高まるにつれて段階的に拡大していくのが理想です。

リリースサイクル

パスファインダーの選定

音声エージェントの導入を始めるチームにとって、適切なパスファインダー（先行事例）の選定は非常に重要な初期判断です。これは多くの人が思うほど技術面だけの話ではありません。早期に成功を積み重ね、終わりのないPOC（概念実証）から抜け出せるチームには共通点があります。それは、次の質問に明確に答えられることです。

ボイスエージェント導入を始めるチームにとって、適切なパスファインダー（先導役）の選定は初期の最重要決定事項の一つです。これは多くの人が思うほど技術的な話ではありません。早期に成果を出し、終わりなきPOC（概念実証）ループを回避できるチームには共通点があります。それは、次の問いに明確に答えられることです。

• このユースケースは、どのようにしてビジネス価値を測定可能な形で生み出すのか？ 最初に選ぶべきユースケースは、技術的に面白いものではなく、すでにビジネスが重視している成果に最もインパクトを与えられるものです。これは売上への影響、コスト削減、顧客満足度など、リーダーがすでに追っている指標で測定されます。ビジネス価値との直接的なつながりがなければ、エージェントを最適化するための反復サイクルを正当化しづらくなり、技術が本領を発揮する前に勢いが失われてしまいます。
• ユーザーにとって、エージェントの役割や目的がすぐに理解できるか？役割の曖昧さは、開発から本番への移行時に最もよくある問題の一つです。エージェントが何をできて何をできないのかをユーザーが理解していないと、評価用テストでは想定しなかった方法で限界を試されます。役割が明確なエージェントは、初回メッセージで期待値を伝え、範囲外のリクエストにも適切に対応します。
• 良い・悪いインタラクションとは何か、それを具体的な評価基準として定義できるか？良いインタラクションとは、単にタスクを完了するだけでなく、ユーザーが「理解された」と感じ、適切なタイミングでエスカレーションが行われ、結果がビジネスの意図と合致している状態です。評価基準は、タスク完了率やエスカレーション率などプラットフォームで取得できる定量指標と、会話内容自体を分析するトランスクリプトベースの基準に分かれます。トランスクリプトベースの基準を早期に定めることで、チームは明確な目標を持って開発できます。また、これが自然な「本番移行の基準」となります。エージェントが評価基準を安定してクリアし、プラットフォーム指標も安定すれば、本番移行の自信が持てます。基準がなければ、移行の判断は主観的になりがちです。
• パフォーマンスとコントロールのトレードオフは何か、今はどちらが重要か？エージェントに自律性を持たせるほど、自然で柔軟な対話が可能になりますが、検証済みの範囲外で動作するリスクも高まります。プロンプトの制約や厳格なエスカレーションロジックでコントロールを強めればリスクは減りますが、エージェントが堅苦しく感じられることも。どちらか一方に偏るのは良くありません。早期に厳しくしすぎると、ただのIVR（自動音声応答）になってしまいますし、信頼構築前に自由度を上げすぎるとサポート負担が増えます。成熟度ごとにこのバランスをどう取るかが、モデル設定やエスカレーションロジック、知識の持たせ方（プロンプト内か外部参照か）を左右します。

初期開発の基盤づくり

実行フェーズに移る際、チームはソフトウェア開発の歴史ある手法を活用できます。テスト駆動開発（TDD）は、エージェントをコア指標に沿わせ続けるための枠組みを提供します。

実行フェーズに移る際、チームはソフトウェア開発の歴史ある手法を活用できます。テスト駆動開発（TDD）は、構築中もエージェントがコア指標に沿っているかを保つための枠組みとなります。

初期テストが揃ったら、エージェント開発はシステムプロンプトから始まります。ここでエージェントのルールやトーン、アプローチを定義します。何をすべきか、何をしてはいけないか、役割の境界でどう振る舞うかなどです。よく設計されたシステムプロンプトは、内容だけでなく構造も重要です。指示を明確に区分し、関連するガイダンスをまとめ、条件付き表現を避けることで、エージェントの一貫性が大きく向上します。この段階でよく参照するのがプロンプトガイドです。エージェントテスト（エージェントが期待される特定の動作を繰り返し検証するもの）です。前者は実際の有人通話をレビューすることで最適化されます。後者は、最初は想定される動作セットから始め、新たな動作やイレギュラーケースが見つかるたびに拡張していきます。

システムプロンプトと並行して、エージェントのコアコンポーネント（LLM、テキスト読み上げ（TTS）モデル、ボイス）を設定します。LLMの選定は主にレイテンシーとパフォーマンスのトレードオフで、速度重視のモデルは推論力を多少犠牲にしがちです。TTSは、表現力、低レイテンシー、多言語対応など、ユースケースの要件によって最適な選択が異なります。ボイスは技術的な選択であると同時に、ブランドの意思決定でもあります。組織の印象を左右するため、エンジニアだけでなくブランドやマーケティングチームも関わるべき数少ない設定項目です。そのため、ボイス選定は開発の最初や最後でボトルネックになることなく、他の作業と並行して進められます。ElevenAgentsでは1万以上のボイスが利用でき、合うものがなければ独自にクローンや作成も可能です。

ここから、エージェントにはオプションでナレッジベース、

これらの基盤が整えば、エージェントを実際にテストできる状態になります。ナレッジベースやツール、チャネル設定などで拡張できます。追加するたびに新たなテスト対象も増えます。電話連携や外部DBアクセス、顧客の代わりにアクションを実行する機能など、どれも評価基準に照らして慎重に検証する価値があります。ツールを追加する場合は、システムプロンプトやツール説明で、いつ・どのように使うかを明示し、エージェントが一貫して適切に使えるようにします。

本番運用への準備

基盤づくりの段階で定義したテストや評価基準を、構築済みのエージェントに適用していくことで、開発は「テスト追加→失敗箇所特定→システムプロンプトや設定の修正→再テスト」という短いサイクルになります。この段階での多くの失敗はモデル自体ではなく、プロンプトの問題です。単独では明確に思えた指示が、会話中では曖昧だったり、初期テストスイートで想定していなかったエッジケースが現れたりします。こうしたケースごとに、会話から新たなNext Turnテストを作成できます。いつ反復を止めるかは明確です。エージェントが複数回のテストで評価基準を安定してクリアし、タスク完了率やエスカレーション率などのプラットフォーム指標も許容範囲に収まったときです。だからこそ、基準を事前に定めておくことが重要です。基準がなければ、準備完了の判断が曖昧になり、ゴールが動いてしまいます。

実際、多くのチームは、繰り返し発生する少数の失敗パターンが大半の問題を占めていることに気づきます。よくあるのは、プロンプトの曖昧さ（指示が矛盾・不十分で予測不能な動作になる）、ツールの誤用（文脈を間違えてツールを呼び出す、または必要な時に呼び出さない）、エスカレーションのずれ（過剰にエスカレーションする、または引き継ぐべき会話を保持し続ける）などです。これらはプロンプトの修正で対応できます。関連指示の強化、明示的な例の追加、エスカレーション閾値の調整などで十分なことが多いです。問題は、本番前にこれらを見逃すことです。

よくある失敗は、テストスイートの合格を保証と勘違いすることです。ハッピーパス（理想的な流れ）しかカバーしていないスイートは簡単に合格しますが、意味はほとんどありません。拒否応答、会話中の方向転換、曖昧な入力、ツール多用時のやり取りなど、幅広いケースをカバーしてこそ結果に重みが出ます。同様に、シミュレーションテストを省略しターン単位のテストだけに頼ると、会話全体でしか現れない失敗（文脈のずれや初期の小さなミスが後半に大きな問題になるなど）を見逃します。繰り返し発生する失敗パターンを解消し、エージェントがエッジケースにも柔軟に対応できるようになれば、ステージング環境での追加反復の価値は下がります。その時点で、より価値のあるフィードバックは実際の会話から得られます。

本番移行は、反復が終わるという意味ではありません。学びの中心がシミュレーションテストから本番会話の記録に移るということです。移行時に定めた評価基準が、以降の本番パフォーマンスの基準となり、サイクルは続きます。

フィードバックループ、評価、反復のやめどき

テストが定義され実行されると、パイプラインのギャップがすぐに見えてきます。

この段階で最も重要なのは、変更を「仮定」ではなく「検証」することです。1つの失敗を直す修正が、別の問題を密かに生むこともあります。ElevenAgentsはバージョン管理に対応しており、チームは新しいバージョンをユーザーの一部にだけ適用して効果を検証し、全体展開前に改善が本当に成果につながっているかを確認できます。これにより、改善が別の失敗を生むリスクを抑えられます。

失敗しやすいポイントバージョン管理に対応しており、全体展開前に一部ユーザーで新バージョンをテストできます。これにより、改善が本当に成果につながっているか、失敗パターンが別の形で現れていないかを確認できます。

この段階で最も大きなミスは、段階的なロールアウトをせず、いきなり全ユーザーに変更を適用してしまうことです。段階的な展開がなければ、個々の変更の影響を切り分けられず、大規模になるほどプラットフォーム指標の改善や悪化の原因が分からなくなります。全ユーザーをテスト環境として扱うのはリスクが高いだけでなく、今後の意思決定に必要な観測性も失われてしまいます。

ロールアウト戦略以外にも、注意すべき失敗パターンが2つあります。1つは直近の失敗に過剰に反応することです。目立つ会話で問題が起きると、すぐに広範囲に修正したくなりますが、テストスイートを通さずにプロンプトを修正すると、以前は安定していた動作に逆戻りが起きやすくなります。どんな小さな変更でも新しい反復とみなし、必ずテストすべきです。もう1つは評価基準のずれです。時間が経つと、出荷プレッシャーなどで合格基準が無意識に下がってしまうことがあります。開発時に定めた評価基準を常に基準点とし、厳しすぎると感じた場合は、非公式に基準を下げるのではなく、意図的に見直すべきです。

自信を持ってスケールするために

トラフィックを増やすかどうかは、時間ではなく自信の問題です。拡大のサインは、エージェントが複数回のテストで評価基準を安定してクリアし、プラットフォーム指標も安定し、段階的なロールアウトでもコントロールグループと比べて大きな悪化が見られないときです。

この段階でよくある質問は、どれくらいのトラフィックがあれば十分かということです。1ブランチあたり100件未満の通話ではばらつきが大きく、結果を信頼して評価できません。25件で60％合格と100件で60％合格では、自信の度合いが大きく異なります。件数だけでなく、バッチが現実的な入力の幅（エッジケースや珍しい意図、大量のトラフィックでしか現れない失敗パターンなど）を十分にカバーできる規模であることも重要です。

トラフィックが増えるほど、うまくいっている点も課題もより明確になります。主要な失敗パターンを解消する前に拡大すると、サポート負担が増え、後戻りが難しくなります。

繰り返しと改善

どこで止めるかを知ることは、何を直すかを知るのと同じくらい重要です。反復には限界があり、開発時に定めた評価基準をエージェントが安定して満たしているときが、一旦立ち止まるサインです。その時点での追加変更は、リスクの方がリターンより大きくなります。

「基準を安定して満たす」とは状況によって異なります。データアクセスや連携が限定的なチームでは、エスカレーション率50％前後が現実的な上限になることもあります。データアクセスが十分な場合、最良の本番運用ではタスク完了率80％以上、エスカレーション率20％未満を目指すことが多いです。どんな数値よりも大切なのは安定性です。数週間にわたる本番トラフィックで一貫したパフォーマンスがあり、テストでも大きな悪化がなければ、それが本当のサインです。次の反復による改善幅が、リスクより小さくなったら、止めるタイミングです。

これは作業の終わりを意味しません。新しい要件が出てきたら、また最初からプロセスを始めます。最初の開発時のスコープ設定の質問は、2回目以降も同じように重要です。ただし、2回目以降はテストスイートや評価基準、運用経験があるため、最初のサイクルより有利です。この積み重ねが、ボイスエージェントから継続的な価値を得られる組織と、POC止まりの組織を分けるポイントです。

まとめ

私たちが見てきた中で、ディフレクション（回避）とリゾリューション（解決）のギャップを埋められたチームは、「良いとは何か」を開発前に定義し、反復サイクルを通じて規律を保ち、各デプロイを次の基盤と捉えています。会話型エージェントは一度きりの導入ではありません。実際の会話では、どんなテストスイートでも想定しきれないエッジケースが現れ、本番移行後も改善の取り組みは続きます。

ElevenAgentsはこの現実を前提に設計されています。エージェントテスト、会話分析、段階的ロールアウトが、POCを本当に顧客課題を解決できるシステムへと進化させる基盤です。単なる回避ではなく、解決に導くためのギャップを埋める価値があります。

ElevenAgentsはこの現実を前提に設計されています。エージェントテスト、会話分析、分岐展開が、POCを本当に顧客課題を解決できるシステムへと進化させる土台です。これこそが、埋めるべきギャップです。