長く使える音声エージェントを構築する：フォワードデプロイメントエンジニアリングから得た教訓

多くの組織では長年、サポート業務向けの個別ソリューションを、問い合わせ削減率で評価してきました。つまり、通話量を減らし、有人エージェントとのやり取りを最小限に抑えることです。しかし、問い合わせ削減は問題解決と同じではありません。この差にこそ、顧客体験が損なわれる原因があります。その差を埋めるには、データだけでなく、それに基づいて対応するために必要なシステムにもアクセスできるエージェントが必要です。その結果、エージェントは返金処理、チェックアウトフローの案内、状況に応じた完全なコンテキスト付きでの有人エージェントへの引き継ぎを行えます。これにより、企業は大規模に顧客対応を処理でき、有人サポートチームの負担を大幅に減らしながら、通話の両者にとっての体験を改善できます。Revolutとの最近の導入事例では、世界で7,000万人の顧客にサービスを提供するこのフィンテック企業において、解決までの時間を8分の1に短縮し、通話成功率99.7%を達成しました。

この規模の変化には、企業の中核的なミッションと密接に結び付け、経営層の強力な支援のもとで、段階的に取り組む必要があります。技術面では、非構造化された環境での推論には、慎重に管理すべき固有のリスクが伴います。エージェントに顧客関係管理（CRM）全体での操作、POSシステムでの注文変更、ケースのエスカレーションを行う能力を与えるなら、ガバナンスモデルはモデル自体と同じくらい重要です。焦点となるのは、エージェントが実務を担えるかではなく、それを安全かつ繰り返し導入するためにどのような仕組みが必要かです。

本記事では、初回導入から組織全体の顧客対応業務への拡張まで、成功するエージェントに必要な要素を経験に基づいてご紹介します。

エージェントのリリースとソフトウェアのリリースの違い

エージェント構築をさらに詳しく見る前に、数十年にわたり企業が行ってきた従来のソフトウェア導入と、音声エージェントの導入を比較してみましょう。この視点では、エージェントは従来型ソフトウェアとコアオーケストレーターという、2つの異なるコンポーネントに分けられます。

ソフトウェア

コアオーケストレーター

従来型ソフトウェアのコンポーネントは、主にエージェントの提供方法とパフォーマンスの改善を目的としています。ElevenAgentsでは、たとえばバージョニング、A/Bテスト、電話機能、最初のメッセージの設定などが含まれます。これらのコンポーネントは導入後のドリフトがほとんどなく、動作の予測可能性が高いのが特徴です。堅牢なエンジニアリング手法により、組織はこれらの機能を迅速に活用し、厳密なメトリクス、トレース、ログを通じて、本番環境でのパフォーマンスを深く把握できます。このレイヤーでのレイテンシー改善は、キャッシュ、コネクションプーリング、インフラのスケーリング、プロトコル最適化といった、確立されたパターンに従います。いずれも結果を決定論的に予測できる信頼性の高い手段です。

コアオーケストレーターのコンポーネントは性質上予測が難しい一方で、回答品質と体感レイテンシーの両面で、エージェントの実行時パフォーマンスを左右します。従来型ソフトウェアと異なり、これらのコンポーネントは自然言語とオーディオを扱います。入力空間は実質的に無限であり、表現、コンテキスト、バックグラウンドノイズ、ユーザー行動のわずかな変化が、時間とともに大きく異なる出力を生む可能性があります。そのため、従来のテストだけでは不十分です。数百件のテストケースで完璧に動作しても、予測が難しい形で本番環境において失敗する場合があります。

このレイヤーのレイテンシーも、モデルの推論時間、聴覚的アーティファクトの挿入、ツール呼び出しチェーン、生成システムに固有のばらつきに左右されるため、決定論的ではありません。こうしたコンポーネントを適切に管理するには、評価フレームワーク、本番監視、導入前の仮説だけに頼らず実際の会話データに基づいて継続的に反復する姿勢を中心とした、別の規律が必要です。

この違いにより、組織が導入にどう取り組むべきかが決まります。まずは組織にとって重要でありながらリスクの低いユースケースから始め、システムへの信頼が高まるにつれて計画的に拡張します。

リリースサイクル

先導役となるユースケースの選定

音声エージェントの導入を始めるチームにとって、適切な先導役を選ぶことは、初期段階で最も重要な意思決定の一つです。そして、これは多くの人が思うほど技術の問題ではありません。早期に成果を上げ、終わりのないPOCの深みを避けられるチームには共通点があります。以下の問いに明確に答えられることです。

• このユースケースは、どのように測定可能なビジネス価値を生み出すか？最初に取り組むべきユースケースは、技術的に最も興味深いものではなく、すでにビジネスが重視している成果を最も動かせる可能性が高いものです。収益への影響、コスト削減、顧客満足度、その他リーダー層がすでに追跡し責任を負っている指標で測定します。ビジネス価値への直接的なつながりがなければ、エージェントを適切に仕上げるために必要な反復サイクルを正当化することが難しくなり、技術が価値を証明する前に勢いを失う可能性があります。
• エージェントの対象範囲と目的は、ユーザーにすぐ明確に伝わるか？対象範囲の曖昧さは、開発から本番へのドリフトを招く最も一般的な原因の一つです。エージェントにできることとできないことを理解していないユーザーは、評価スイートが想定していない形でその境界を試します。対象範囲が明確なエージェントは、最初のメッセージから期待値を設定し、範囲外のリクエストにも適切に対応します。
• 良い対話と悪い対話はどのようなものか。また、具体的な評価基準として定義できるか？良い対話とは、単にエージェントがタスクを完了することではありません。ユーザーが話を聞いてもらえたと感じ、適切なタイミングでエスカレーションされ、結果がビジネスの意図と一致していることです。評価基準は2つに分かれます。タスク完了率やエスカレーション率など、プラットフォームが取得する定量指標と、会話そのものの分析が必要な文字起こしベースの基準です。文字起こしベースの基準を早期に定義すれば、チームは構築すべき明確な目標を持てます。また、自然な本番稼働の判断基準にもなります。エージェントが一貫して評価基準を満たし、プラットフォーム指標が安定すれば、自信を持って本番へ移行できます。基準がなければ、本番稼働は主観的な判断になります。
• パフォーマンスとコントロールのトレードオフは何か。この段階でより重要なのはどちらか？エージェントの自律性を高めるほど、対話は自然で柔軟になりますが、検証済みの境界を越えて動作するリスクも高まります。制約付きのプロンプトや厳格なエスカレーションロジックによる強いコントロールはこのリスクを下げますが、エージェントが硬直的に感じられることがあります。どちらの極端も正解ではありません。早すぎる段階で制限をかけすぎると、単なる高機能IVRになってしまいます。信頼を確立する前に急ぎすぎると、得られる効果を上回るサポート負担が生じます。成熟度の各段階でこのバランスをどこに置くかを理解することで、モデル設定、エスカレーションロジック、エージェントの知識をプロンプト・取得情報・構造化された情報源のどこに持たせるかが決まります。

これらの問いに答えられれば、組織は戦略から実行へ移り、構築のスコープ設定を始める準備が整います。

初期構築の土台づくり

実行段階に移る際、チームはソフトウェアそのものとほぼ同じくらい歴史のある方法論を活用できます。テスト駆動開発（TDD）は、構築の全工程でエージェントを主要指標に沿わせ続けるための枠組みを提供します。

具体的には、開発チームとビジネス部門の関係者が共同で、次の2つの基礎的な成果物を定義・構築する必要があります。成功評価基準は、個別の通話と全体の両方において望ましい状態を定義するもので、エージェントテストは、エージェントが示すべき特定の行動を繰り返し検証するものです。前者は、実際の有人通話が発生した後にそれをレビューすることで、最も有用な知見が得られます。後者は、想定される行動の初期セットから始め、新たな行動が追加され、エッジケースが見つかるにつれて段階的に拡張します。

初期テストセットを用意したら、エージェント開発はシステムプロンプトから始まります。ここで、エージェントのルール、トーン、アプローチを定義します。何をすべきか、何をすべきでないか、役割の境界でどう振る舞うべきかを決めます。優れたシステムプロンプトでは、内容と同じくらい構造も重要です。指示を明確なラベル付きセクションに分け、関連するガイダンスをまとめ、条件付きの表現を避けることで、エージェントの一貫性は大きく向上します。この段階では、よくプロンプトガイドを参照します。

システムプロンプトと並行して、エージェントの中核コンポーネントを設定します。LLM、テキスト読み上げ（TTS）モデル、そして音声です。LLMの選定は主にレイテンシーとパフォーマンスのトレードオフであり、通常、速度に最適化されたモデルは推論能力の一部を犠牲にし、その逆もあります。TTSでは、表現力豊かな話し方、低レイテンシー、多言語対応のうち、ユースケースが最も必要とするものによって最適な選択が決まります。一方、音声は技術的な選択であると同時にブランドに関する選択でもあります。組織がすべての発信者にどう伝わるかを左右するため、エージェントを構築するエンジニアだけでなく、ブランドチームやマーケティングチームも関わるべき数少ない設定の一つです。つまり、音声の選定は開発プロセスの開始時や終了時のボトルネックにするのではなく、他の開発と並行して進められます。ElevenAgentsでは10,000以上の音声を利用でき、適したものがなければ独自の音声をクローンまたは作成できます。

ここから、エージェントは必要に応じてナレッジベース、ツール、チャネル設定によって拡張できます。追加するたびに新たな機能が得られる一方、テストすべき範囲も広がります。電話機能のインテグレーション、外部データベースへのアクセス、顧客に代わってアクションを起こす機能のいずれであっても、スコープを拡張する前に評価基準に照らして十分に検証する価値があります。ツールを追加する場合は、システムプロンプトとツールの説明で、それぞれをいつ、どのように呼び出すかを明示的に示し、エージェントが一貫して適切なコンテキストで利用できるようにします。

これらの土台が整えば、エージェントをテストする準備は完了です。

本番稼働に向けて

土台づくりの段階で定義したテストと評価基準を、構築済みのエージェントに対して実行すると、開発は密なループになります。テストを追加し、失敗を特定し、システムプロンプトまたは設定を更新して、再び実行します。この段階で発生する失敗の大半はモデルの失敗ではなく、プロンプトの失敗です。単独では明確に見えた指示も、エージェントが会話の途中で遭遇すると曖昧だと分かることがあります。初期テストスイートが想定していなかったエッジケースも現れます。それぞれを会話から作成できる新たなNext Turnテストにします。反復をいつ止めるべきかには、明確な答えがあります。エージェントが複数回の実行にわたって一貫して評価基準を満たし、タスク完了率やエスカレーション率などのプラットフォーム指標が許容範囲内で安定したときです。だからこそ、構築前に基準を定義することが重要です。基準がなければ、準備完了の判断は主観的になり、ゴールは動き続けます。

実際には、ほとんどのチームで問題の大半は、少数の繰り返し発生する失敗パターンによって説明できます。最も一般的なのはプロンプトの曖昧さです。エージェントが矛盾した指示や不十分な指示を受け、予測不能な動作に陥ります。次にツールの誤用です。誤ったコンテキストでツールを呼び出したり、呼び出すべきときに呼び出さなかったりします。そしてエスカレーションのドリフトです。エージェントが過剰にエスカレーションする、または引き継ぐべき会話を抱え込み続けます。これらにはすべてプロンプトレベルの修正方法があります。該当する指示を明確化し、明示的な例を追加する、またはエスカレーションのしきい値を調整するだけで、通常は十分です。リスクは、本番稼働前にこれらを見逃すことにあります。

チームが最もよく犯す誤りは、合格したテストスイートをシグナルではなく保証として扱うことです。ハッピーパスだけをカバーするスイートは簡単に合格しますが、意味はほとんどありません。拒否、会話途中での方針転換、曖昧な入力、ツールを多用する対話までカバーして初めて、結果に重みが生まれます。同様に、シミュレーションテストを省略してターンレベルのテストだけに頼るチームは、会話全体を通じて初めて現れる失敗を見逃します。たとえば、エージェントが以前のターンを見失うコンテキストドリフトや、通話の序盤の小さなミスが悪い結果へと積み重なる複合エラーです。繰り返し発生する失敗パターンが解消され、エージェントがエッジケースのロングテールに完璧ではなく適切に対応できるようになれば、ステージングでの追加反復による限界価値は低下します。その時点では、実際の会話から得られるシグナルの方が価値があります。

本番稼働は、反復の終わりを意味しません。学習の中心が合成テストから本番の文字起こしへ移ることを意味します。本番稼働を決めた評価基準が、ライブパフォーマンスを測るベースラインとなり、そこからサイクルが続きます。

フィードバックループ、評価、反復を止めるタイミング

テストを定義して実行し始めると、パイプラインのギャップはすぐに見えてきます。会話分析により、チームは対話が失敗した正確な瞬間を特定し、そのシグナルから新しいテストを作成して、何を変更すべきかを判断できます。最も一般的な対応はプロンプトレベルです。ツール呼び出しの説明を明確にする、エッジケースへの指示をより具体的にする、実際には曖昧だったエスカレーション条件を明確化する、といった対応です。場合によっては問題がより深い層にあり、レイテンシーや推論品質がユースケースの要求を満たしていなければ、基盤となるモデル設定を見直す必要があります。

この段階で最も重要な規律は、変更を当然視せず検証することです。ある失敗を解決する修正が、別の失敗を静かに生むことがあります。ElevenAgentsはバージョニングをサポートしており、より広いユーザー層に展開する前に、ごく一部のユーザーに対して新しいイテレーションをテストできます。これにより、改善が失敗の形を別の場所へ移しているだけではなく、実際に成果を改善していることを確認できます。

起こりうる問題

この段階で最も重大な誤りは、分岐ロールアウトを省略し、変更をユーザー全体に直接展開することです。段階的なロールアウトがなければ、特定の変更による影響を切り分けられません。大規模になるほど、プラットフォーム指標の改善や悪化を実際に引き起こしているものを把握することは、ほぼ不可能になります。ユーザー全体をテスト環境として扱うことは、単にリスクが高いだけではありません。今後自信を持って意思決定するために必要な可観測性を失うことになります。

ロールアウト戦略に加えて、注意すべき失敗モードが2つあります。1つ目は、直近の失敗を過度に重視することです。注目度の高い会話で問題が起きると、すぐに広範な修正を加えたくなるものです。しかし、完全なテストスイートを実行せずに行う反応的なプロンプト変更は、以前は安定していた動作にリグレッションを引き起こすことがよくあります。どんなに小さな変更でも、新しいイテレーションとして扱い、適切にテストすべきです。2つ目は評価のドリフトです。時間が経つと、特にリリースへのプレッシャーがあるとき、チームは無意識のうちにテスト合格の基準を下げてしまうことがあります。スコープ設定時に定義した評価基準を、常に拠り所にする必要があります。基準が厳しすぎると感じたなら、非公式に基準を緩めるのではなく、見直したうえで意図的に更新するべきです。

自信を持って拡張する

トラフィックを増やすかどうかは、時間ではなく確信に基づいて決めるべきです。拡張のシグナルは、エージェントが複数回のテスト実行で一貫して評価基準を満たし、プラットフォーム指標が安定し、分岐ロールアウトで対照群に対する有意なリグレッションが見られないことです。

この段階でよくある問いは、結論を出すにはどれだけのトラフィックが必要かということです。分岐あたり100件未満の通話バッチでは、結果を信頼して評価するにはばらつきが大きすぎます。25件中60%の合格率と100件中60%の合格率では、確信の度合いが大きく異なります。一定数を超えたうえで、バッチは想定されるエッジケース、まれな意図、大量のトラフィックでのみ現れ小規模サンプルではほとんど見られない失敗モードを含む、現実的な入力の全範囲を表面化させるのに十分な規模であるべきです。

トラフィックの増加は、うまく機能していることも、そうでないことも増幅します。主要な失敗パターンを解消する前に拡張すると、後から取り戻すのが難しいサポート負担が生じます。

繰り返し改善する

何を修正するかを知ることと同じくらい、どこで止めるかを知ることも重要です。反復には収穫逓減があり、停止すべきシグナルは、エージェントがスコープ設定時に定めた評価基準を一貫して満たしていることです。その時点では、追加の変更は得られる価値よりもリスクの方が大きくなります。

「一貫して基準を満たす」状態は、状況によって異なります。データアクセスが限定的、またはインテグレーションが不完全なチームでは、そうした制約が解消されるまで、エスカレーション率50%前後が現実的な上限となる場合があります。データアクセスが充実している場合、最も成果を上げている導入事例では、通常、タスク完了率80%以上、エスカレーション率20%未満を目標とします。どの単一の数値より重要なのは安定性です。本番トラフィックで数週間にわたって一貫したパフォーマンスを示し、テスト実行間で有意なリグレッションがないことこそが、真のシグナルです。次のイテレーションによる限界的な改善がリグレッションのリスクを下回るときが、止めるべきタイミングです。

これは、作業が完了したことを意味しません。新たな要件が生まれれば、プロセスは最初から始まります。最初の構築時に行ったスコープ設定の問いは、2回目でも同じように重要です。違いは、2回目のサイクルに入るチームは、最初のサイクルでゼロから構築したテストスイート、評価ベースライン、運用経験をすでに備えていることです。この積み重なる優位性こそが、音声エージェントから持続的な価値を得る組織と、概念実証から抜け出せない組織を分けるものです。

まとめ

問い合わせ削減と問題解決の差を埋めるチームには共通点があります。構築を始める前に望ましい状態を定義し、反復サイクルを通じて規律を維持し、各導入を次の導入の土台として扱うことです。会話型エージェントは一度きりの導入ではありません。実際の会話では、どんなテストスイートでも完全には予測できないエッジケースが明らかになり、改善の取り組みは本番稼働で終わりません。

ElevenAgentsは、この現実を前提に構築されています。エージェントテスト、会話分析、分岐ロールアウトは、概念実証を、単に問い合わせを減らすだけでなく大規模に顧客課題を実際に解決するシステムへ変える基盤です。埋めるべきなのは、この差です。