ボイスエージェントのための安全な発信者認証フローの設計

Voice agents are rapidly evolving from simple FAQ responders to action-taking systems that modify accounts, process transactions, and access sensitive customer data. This shift introduces a critical challenge: How do you verify caller identity in a conversational AI system where traditional visual authentication methods don't exist?

ボイスエージェントがサブスクリプションの更新や口座残高の取得、返金の開始などを行う場合、人間のコールセンターと同じ厳格さで発信者を認証する必要がありますが、やり取りはすべて音声ベースです。人間のオペレーターが会社の方針に従うのとは異なり、AIエージェントにはLLMの判断に頼らない、決定論的かつツールベースの認証が求められます。

この記事では、エンタープライズ導入現場でForward Deployed Engineerとして培った実績ある認証パターンを紹介します。埋め込みウィジェット向けのセッション認証から、電話特有の方法やOTP認証まで、5つの主要アプローチを解説し、それぞれをElevenLabsプラットフォーム上で決定論的なワークフローゲーティングを使って実装する方法を説明します。

特に重要なのは、認証を会話の推測に任せてはいけない理由を示すことです。認証は、分離されたサブエージェントやツールベースの検証、条件付きワークフロー分岐によって設計し、認証済みユーザーだけが特権操作に到達できるようにする必要があります。

決定論的認証のためのアーキテクチャ基盤

認証済みユーザーだけがアカウント関連情報にアクセスできるようにするため、ElevenLabsのワークフローによる厳格な環境・アクセス分離を推奨します。認証は必ず、成功・失敗をブール値で返すツールコールとして実装し、ElevenLabsのワークフロービルダーでディスパッチツールとして設定してください。

転送条件をツールコールの結果に直接リンクすることで、アカウントデータにアクセスできるサブエージェントは認証成功後のみ到達可能となり、未認証ユーザーから完全に隔離されます。これにより認証はLLMの判断に依存せず、決定論的に行われ、認証が確認されない限り下流ノードへの進行を防げます。

代替案として、転送式（transfer expression）を信頼できる転送方法として利用できます。これらの式は、ツールコールの結果で更新される動的変数を参照します。

実装例

Salesforceでユーザー認証（ツールコール）を行い、成功した場合はSalesforceから顧客取引データを取得（別のツールコール）し、その後このデータを使って顧客とやり取りや必要なアクションを行うサブエージェントにユーザーを転送します。

ユーザー本人確認の方法

これらの認証方法はElevenLabsプラットフォームで標準サポートされていませんが、CRMやバックエンド／データベースと連携するサーバーサイドツールを使って実装できます。認証データはそちらに保存されます。

ホストアプリケーション認証

ウェブサイトに埋め込まれたボイスエージェントの場合、ホストアプリケーションがユーザーのセッションデータ（ログイン状態、アカウントID、セッショントークンなど）を、エージェント／ウィジェット初期化時に動的変数として渡せます。これらの変数はツールコール時にも自動で挿入されるため、別途認証を求めずに統合システムからパーソナライズされたデータを取得できます。

この方法により、ユーザーがすでにホストアプリケーションで認証されているため、シームレスなサポートフローが実現します。カスタム設定で導入するか、ElevenLabsウィジェットを利用して、ウィジェット設定時に変数を渡すことも可能です（例：<elevenlabs-convai dynamic-variables='{"user_id": "123", "account_tier": "premium"}'>）。

Documentation on Dynamic Variables:

• https://www.11labs.ru/docs/agents-platform/customization/personalization/dynamic-variables#pass-variables-at-runtime 

知識ベース認証（KBA）

ボイスエージェントが発信者にアカウント番号や郵便番号、生年月日、セキュリティ回答などの認証情報を尋ねます。サーバーサイドツール（Webhookやクライアントサイド）が、これらの値をデータベース（CRMやIDストアなど）と照合します。ツールは、ブール値（is_error）と説明テキストを含む成功／失敗結果を返します。決定論的ワークフローゲーティングで実装可能です。必要情報を尋ねた後、ツールディスパッチを設定し、ツールの成功／失敗ステータスに応じて分岐するワークフロー条件付き転送エッジを使い、認証済みユーザーを「特権」エージェントノードへ誘導します。

このアプローチは、詐欺リスクの要件に応じて、静的なセキュリティ質問と動的な「ウォレット外」スタイルの認証をサポートします。

ツールに関するドキュメント：

• https://www.11labs.ru/docs/agents-platform/customization/tools/server-tools 
• https://www.11labs.ru/docs/agents-platform/customization/agent-workflows#dispatch-tool-node 

システム動的変数（電話のみ）

電話（TwilioやSIPトランク経由）での会話では、エージェントは電話特有のシステム変数（system__caller_id＝発信者の電話番号など）に自動でアクセスできます。この変数は会話開始時に自動でセットされ、2通りの方法で参照可能です。1）プロンプト／メッセージ内：二重中括弧で参照（例：{{system__caller_id}}）すると、実際の値に置き換わります。2）ツールパラメータ内：これらの変数を使うようツールパラメータを設定し、プロンプトで触れずにサイレント認証が可能です。

例えば、ツールを設定して発信者IDを自動でCRMの照会エンドポイントに渡し、着信番号が顧客の登録番号と一致するかをサイレントで認証できます。ツールコールの代わりに、会話開始前に実行されるWebhookとして認証を設定することも可能です。

セキュリティ注意：発信者が登録外の番号を使う場合や、登録番号が第三者に知られている場合もあるため、発信者IDベースの認証は事前の顧客同意が必要、または追加認証（知識ベース質問など）と組み合わせて使うべきです。

システム動的変数と開始Webhookに関するドキュメント：

• https://www.11labs.ru/docs/agents-platform/customization/personalization/dynamic-variables#system-dynamic-variables 
• https://www.11labs.ru/docs/agents-platform/customization/personalization/twilio-personalization 

高度な知識ベース／セキュリティ質問認証

エージェントが複数のセキュリティ質問を出し、発信者が所定数正解した場合のみアクセスを許可できます。エージェントは事前リスト（生年月日、郵便番号、ペットの名前など）からランダムに質問を選び、回答をデータベースへのツールコールで検証します。

認証ツールは現在の正解数を含むJSONレスポンスを返します。ツールアサインメントを使うことで、この数値は自動で動的変数（例：auth_success_count）に抽出・保存・更新されます。認証ごとに変数が増加します。

必要な認証数（例：3）に達したら、ワークフロー式条件で動的変数の値をチェックし、特権サブエージェントノードへ遷移します。式では比較演算子（例：auth_success_count >= 3）を使い、認証状況に応じて決定論的にアクセスを制御します。

ドキュメントはこちら：https://www.11labs.ru/docs/agents-platform/customization/agent-workflows#edges-and-flow-control 

ワンタイムコード

この方法は汎用的で、ワンタイムコードをSMSやメールでユーザーの端末に送信します。ユーザーはそのコードをエージェントに伝え、認証を受けてアクセスします。

実装ワークフロー：

1. コード生成：エージェントがサーバーツールコールで専用エンドポイントにリクエストし、安全なワンタイムコードを生成して、ユーザーの希望するチャネル（SMSやメール）に送信します。
2. ユーザープロンプト：エージェントがユーザーに受け取ったコードの入力を求めます。音声モードでは、ユーザーがコードを口頭で伝え、音声認識で取得します。
3. コード検証：エージェントがユーザー入力のコードを2回目のツールコールでバックエンドの検証サービスに送信します。バックエンドはコードが一致し、有効期限切れや既使用でないかを確認します。
4. ワークフロー分岐：エージェントは検証結果に応じて処理します。成功：コードが正しければ、成功条件で認証後のワークフローへ進みます。失敗：コードが間違っていれば、再入力を促すか、リカバリー手順（例：新しいコード送信）を実行します。

セキュリティ考慮点：総当たり防止のためレート制限を設け、コードの有効期限は3～5分程度にし、再試行回数も管理・制限してください。音声認識の場合は、コード取得時の確認プロンプトも検討しましょう。

まとめ

これらの認証方法は柔軟な構成要素であり、決まった解決策ではありません。選択肢はリスクプロファイルや規制要件、ユーザー体験の目標に合わせて選んでください。カスタマーサービスボットと銀行取引を扱うアシスタントでは必要なセキュリティが異なります。プラットフォームの柔軟性により、脅威や要件の変化に合わせてセキュリティ戦略を進化させ、常に保護とユーザー体験のバランスを保てます。