音声エージェント向けの安全な発信者認証を設計する
- 公開日
- 最終更新日
音声エージェントは、単純な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）と説明テキストを含む成功／失敗の結果を返します。
これは決定論的なワークフローゲーティングで実装できます。必要な情報を求めた後、ツールディスパッチを設定し、ツールの成功／失敗ステータスに基づいて分岐するワークフローの条件付き転送エッジを使って、認証済みユーザーを「権限付き」エージェントノードへルーティングします。
このアプローチは、不正利用リスクの要件に応じて、固定の秘密の質問と動的な「out-of-wallet」形式の検証をサポートします。
サーバーツールとエージェントワークフローのディスパッチツールノードのドキュメントで詳細をご確認ください。
システム動的変数（電話システムのみ）
電話ベースの会話（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プラットフォームでワークフロービルダーの全機能をご覧いただくか、営業に問い合わせるから、最初の認証済み音声エージェントワークフローの構築を今すぐ始めましょう。
