音声エージェント向けの安全な発信者認証を設計する
- 公開日
- 最終更新日
音声エージェントは、単純なFAQ応答システムから、アカウントの変更、取引の処理、機密性の高い顧客データへのアクセスを行うシステムへと急速に進化しています。この変化により、重要な課題が生じています。従来の視覚的な本人確認手段が存在しない会話型AIシステムで、発信者の本人確認をどのように行うのでしょうか？
音声エージェントがサブスクリプションの更新、口座残高の取得、返金の開始を行える場合、人間のコールセンターと同等の厳格さで、完全に音声ベースのやり取りを通じて発信者を認証する必要があります。企業ポリシーに従う人間のエージェントとは異なり、AIエージェントにはLLMの判断に依存しない、決定論的でツールベースの認証が必要です。
この記事では、エンタープライズ導入におけるForward Deployed Engineerとしての経験から得られた、実証済みの認証パターンを紹介します。埋め込みウィジェット向けのセッションベース認証から電話固有の手法、OTP検証まで、5つの主要なアプローチを取り上げ、ElevenLabsプラットフォームで決定論的なワークフローゲーティングを用いて実装する方法を解説します。
最も重要なのは、認証を会話からの推論に任せてはならない理由を示すことです。認証は、分離されたサブエージェント、ツールベースの検証、認証済みユーザーだけが権限を必要とする操作に到達できるようにする条件付きワークフロールーティングによって設計する必要があります。
概要
- 音声エージェントの発信者認証は、決定論的かつツールベースでなければならず、LLMによる会話上の推論に委ねることはできません。
- ホストアプリケーション認証では既存のセッションデータをエージェントに渡すため、すでにログインしているユーザーが再認証を行う必要はありません。
- 知識ベース認証では、アカウント番号や生年月日など、発信者が提供した情報をサーバーサイドのツール呼び出しでバックエンドシステムと照合して検証します。
- 電話システムへの導入では、発信者番号などのシステム動的変数を使用してサイレントに認証できます。ただし、発信者番号はなりすましや共有が可能なため、第2要素と組み合わせる必要があります。
- ワンタイムコード検証では、SMSまたはメールでコードを送信し、バックエンドサービスを通じて検証します。
決定論的認証を支えるアーキテクチャ
認証済みユーザーだけがアカウント関連情報にアクセスできるよう、ElevenLabsのワークフローで環境とアクセスを厳格に分離することをおすすめします。認証は必ず、成功または失敗をブール値で出力するツール呼び出しとして実装し、ElevenLabsワークフロービルダー内でディスパッチツールとして設定してください。
転送条件をツール呼び出しの結果に直接リンクすることで、アカウントデータにアクセスできるサブエージェントには認証成功後にのみ到達でき、未認証ユーザーからは完全に分離された状態を保てます。これにより、認証はLLMの判断に委ねられない決定論的なものとなり、本人確認なしで下流ノードへ進むことを防げます。
代替手段として、信頼性の高い転送方法である転送式を使用できます。これらの式は、ツール呼び出しの結果によって更新される動的変数を参照します。
実装例
Salesforceでユーザーを検証します（ツール呼び出し）。成功した場合は、Salesforceから顧客の取引データを取得し（別のツール呼び出し）、そのデータを使って顧客とやり取りし、必要に応じてほかの操作を実行するサブエージェントへユーザーを転送します。
ユーザー本人認証の方法
これらの認証方法はElevenLabsプラットフォームに標準搭載されていません。認証データが保存されているCRMやバックエンド／データベースと連携する、サーバーサイドツールを通じて実装できます。
ホストアプリケーション認証
Webサイトに埋め込まれた音声エージェントでは、ホストアプリケーションがエージェント／ウィジェットの初期化時に、ログイン状態、アカウントID、セッショントークンなどのユーザーセッションデータを動的変数として渡せます。これらの変数は同じ動的変数を介してツール呼び出しに自動挿入されるため、個別の認証を求めずに、連携システムからパーソナライズされたデータを取得できます。
ユーザーはすでにホストアプリケーションで検証済みのため、シームレスなサポートフローを実現できます。カスタム設定で構成することも、ElevenLabsウィジェットを使用してウィジェット設定から実行時に変数を渡すこともできます（例：<elevenlabs-convai dynamic-variables='{"user_id": "123", "account_tier": "premium"}'>）。
動的変数のドキュメントで、完全な設定方法をご確認ください。
知識ベース認証（KBA）
音声エージェントは、アカウント番号、郵便番号、生年月日、秘密の質問への回答などの認証データを発信者に求めます。サーバーサイドツール（Webhookまたはバックエンド呼び出し）が、これらの値をデータベース（CRMやIDストアなど）と照合して検証します。ツールは、ブール値のステータス（is_error）と説明テキストの両方を含む成功／失敗の結果を返します。
これは決定論的なワークフローゲーティングで実装できます。必要な情報を求めた後、ツールディスパッチを設定し、ツールの成功／失敗ステータスに応じて分岐するワークフローの条件付き転送エッジを使用して、認証済みユーザーを「権限付き」エージェントノードへルーティングします。
このアプローチは、不正利用リスクの要件に応じて、静的な秘密の質問と動的な「アウト・オブ・ウォレット」形式の検証の両方に対応します。
サーバーツールおよびエージェントワークフローのディスパッチツールノードのドキュメントで、詳しくご確認ください。
システム動的変数（電話のみ）
電話ベースの会話（TwilioまたはSIPトランク経由）では、エージェントはsystem__caller_id（発信者の電話番号）を含む、電話固有のシステム変数に自動的にアクセスできます。この変数は会話の開始時に自動入力されます。
次の2つの方法で参照できます。
- プロンプト／メッセージ内：二重中かっこを使用して参照します。例：{{system__caller_id}}。実際の値に置き換えられます。
- ツールパラメータ内：ツールパラメータでこれらの変数を使用するよう設定すると、プロンプトで言及せずにサイレント認証を行えます。
たとえば、発信者番号をCRM検索エンドポイントへ自動的に渡すようツールを設定すれば、着信番号が顧客の登録番号と一致するかをエージェントがサイレントに検証し、ユーザー認証を行えます。ツール呼び出しの代わりに、会話開始前に実行される会話開始Webhookとして認証を設定することもできます。
セキュリティに関する注意：発信者が登録済みとは異なる番号を使用する場合があり、保存された番号に権限のない人物がアクセスできる可能性もあるため、発信者番号ベースの認証には事前の顧客オプトインを求めるか、追加の認証方法（知識ベースの質問など）と組み合わせる必要があります。
詳しくは、システム動的変数および開始Webhookのドキュメントを参照してください。
高度な知識ベース／秘密の質問による認証
エージェントは、一連の秘密の質問を行い、発信者があらかじめ定めた数の質問に正解した場合にのみアクセスを許可することで、ユーザーを認証できます。あらかじめ定義したリスト（生年月日、郵便番号、ペットの名前など）からランダムに質問を選ぶようエージェントに指示し、データベースへのツール呼び出しで発信者の回答を検証できます。
認証ツールは、現在の成功回数を含むJSONレスポンスを返します。ツール割り当てを使用すると、この回数が自動的に抽出され、動的変数（例：auth_success_count）に保存／更新されます。検証に成功するたびに、変数の値が増加します。
必要な検証回数（例：3回）に達すると、ワークフロー式の条件が動的変数の値を確認し、権限付きサブエージェントノードへ遷移します。この式では比較演算子（例：auth_success_count >= 3）を使用し、認証ステータスに基づいて決定論的にアクセスを制御します。
エッジとフロー制御のドキュメントには、参照できる詳細情報があります。
ワンタイムコード
これは、SMSまたはメールでユーザーのデバイスにワンタイムコードを送信する汎用的な方法です。アクセスを取得するには、ユーザーが検証のためにそのコードをエージェントへ伝える必要があります。
実装ワークフローの詳細は以下のとおりです。
- コード生成：エージェントは、専用エンドポイントへのサーバーツール呼び出しでプロセスを開始します。この操作により、安全なワンタイムコードが生成され、ユーザーが希望するチャネル（SMSまたはメール）で送信されます。
- ユーザーへの入力依頼：エージェントは、受け取ったコードをユーザーに入力するよう求めます。音声モードでは、ユーザーがコードを声に出して伝え、それがスピーチtoテキストで取得されます。
- コード検証：エージェントは2回目のツール呼び出しで、ユーザーが提供したコードをバックエンドの検証サービスに送信します。バックエンドは、コードが一致すること、有効期限が切れていないこと、すでに使用されていないことを検証します。
- ワークフロールーティング：エージェントは検証レスポンスに基づいて処理します。成功：コードが正しければ、成功条件によりユーザーはワークフローの認証後部分へ進みます。失敗：コードが正しくない場合、エージェントは再入力を求めるか、フォールバック手順（新しいコードの送信など）を開始できます。
セキュリティ上の考慮事項：総当たり攻撃を防ぐためにレート制限を実装し、コードの有効期限は短く（3～5分）設定し、再試行回数を追跡・制限する必要があります。音声でのやり取りでは、コード取得時のスピーチtoテキストの精度を確保するため、確認プロンプトの使用を検討してください。
ElevenAgentsで安全な音声認証を始める
これらの認証方法は、特定のソリューションを押し付けるものではなく、柔軟に組み合わせられる構成要素です。具体的なリスク特性、規制要件、ユーザー体験の目標に応じて選択してください。カスタマーサービスボットと、取引を扱う銀行アシスタントでは、必要なセキュリティが異なります。このプラットフォームなら、保護とユーザー体験のバランスを保ちながら、脅威の変化や要件の拡大に応じてセキュリティ戦略を進化させられます。
ElevenAgentsは、上記で説明した決定論的なワークフローゲーティング、ディスパッチツール、電話固有の変数を提供します。これにより、LLMの判断に決して依存しない発信者認証を構築できます。
ElevenAgentsプラットフォームでワークフロービルダーの全機能をご覧いただくか、営業部門にお問い合わせいただき、今すぐ最初の認証済み音声エージェントワークフローの構築を始めましょう。
