音声エージェント向けの安全な発信者認証を設計する
- 公開日
- 最終更新日
音声エージェントは、単純な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プラットフォームでワークフロービルダーの全機能を確認するか、営業チームにお問い合わせいただき、今日から最初の認証済み音声エージェントワークフローの構築を始めましょう。
