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