API ゲートウェイを介したブラウザーセーフなリアルタイム AI: エフェメラル トークン、テナント ポリシー、および音声セッション コントロール

ブラウザとモバイル アプリは、有効期間の長いプロバイダー API キーを受信しないでください。ただし、リアルタイム音声 AI の場合、すべての音声パケットをゲートウェイ経由で送信すると、遅延、運用コスト、障害モードが増加する可能性があります。より良いパターンは、ゲートウェイをコントロール プレーン内に保持することです。ユーザーを認証し、テナント ポリシーを適用し、予算を確保し、限定された短期間のリアルタイム認証情報を作成し、遅延の影響を受けやすいメディアが必要に応じてプロバイダーのリアルタイム トランスポートを使用できるようにします。

この記事では、AI API ゲートウェイを介して音声エージェント、通話アシスタント、モバイル家庭教師、サポート副操縦士、またはアプリ内音声インターフェースを構築するチームの実装パターンについて説明します。目標は、テナント ガバナンスを失うことなくブラウザの安全性を確保することです。

問題: 直接リアルタイム接続は制御をバイパスします

プレーンなサーバー側プロキシは、キーと可観測性を一元化するため魅力的です。標準的なテキスト リクエストの場合、多くの場合、これが適切なモデルです。リアルタイムオーディオは異なります。音声セッションには、継続的なマイク入力、双方向オーディオ出力、中断、ツール呼び出し、および厳密な遅延の予測が含まれる場合があります。ゲートウェイ経由ですべてのメディアをプロキシすると、ゲートウェイがポリシーや課金サービスではなく、帯域幅を大量に消費するメディア リレーに変わる可能性があります。

ブラウザからプロバイダへの直接接続は遅延を解決しますが、別の問題が発生します。

• ブラウザは標準プロバイダ API キーを安全に保持できません。
• アプリが直接接続する場合、テナントの予算チェックがスキップされる場合があります。
• モデル、地域、音声、モダリティ、ツールの制限がクライアント側の約束となります。
• 使用状況の帰属が不完全または遅延する
• セキュリティ チームは、セッションの開始前に監査可能な意思決定ポイントを失います。

実際の設計は、「すべてのバイトをプロキシする」というものではありません。それは「セッションごとにブローカー」です。

事実、推奨事項、予測

事実: リアルタイム AI プロバイダーは、WebRTC、WebSocket、SIP などの低遅延トランスポートをサポートすることが増えています。 OpenAI のリアルタイム API の公開ドキュメントでは、WebRTC を含む低遅延リアルタイム インターフェイスについて説明しています。 Azure OpenAI リアルタイム WebRTC ガイダンスでは、WebRTC 接続を開始する前にバックエンド トークン サービスを使用して一時トークンを取得するブラウザー アプリケーションについて説明し、クライアント アプリケーションで標準 API キーを使用しないように警告しています。 OpenAI Agents SDK リアルタイム ガイダンスでは、バックエンドが有効期間の短い一時的なクライアント トークンを作成し、ブラウザがそれを使用して WebRTC 接続を確立するフローも推奨しています。

推奨事項: ゲートウェイをセッション認証局として扱います。リアルタイム セッションが存在できるかどうか、どのモデル、どのリージョン、どのテナント、どの予算で、どのツールを使用できるかを決定する必要があります。クライアントは、承認されたセッションを開始するために必要な最小限の有効期限の短い認証情報のみを受け取る必要があります。

予測: リアルタイム プロバイダー API はしばらくの間、不均一な状態が続くでしょう。トークンの有効期間、セッション構成フィールド、サーバー側の切断制御、使用状況イベント、およびリージョンのサポートは異なります。ゲートウェイは、すべてのリアルタイム API が完全に移植可能であるかのように振る舞うのではなく、プロバイダーの機能を明示的にモデル化する必要があります。

リファレンス アーキテクチャ: リアルタイム コントロール プレーンとしてのゲートウェイ

ブラウザセーフなリアルタイム フローは 5 つの部分で構成されます。

ゲートウェイは、権限を維持するためにすべての音声フレームを中継する必要はありません。セッション作成の決定と調整パスを所有する必要があります。

推奨されるリクエスト フロー

造幣前のポリシーチェック

最も重要な施行ポイントは、一時的なトークンが鋳造される前です。ブラウザが有効期間の短い認証情報を取得すると、プロバイダがセッションの更新、切断、オブザーバー、またはコールバックの制御をサポートしない限り、セッション中の適用が制限される場合があります。

ゲートウェイは少なくとも以下をチェックする必要があります:

• テナントのステータス: アクティブ、一時停止、トライアル、前払い、請求済み、または隔離済み。
• ユーザー資格: このユーザーがテキスト チャットだけでなくリアルタイム音声を使用できるかどうか。
• 許可されたモデル プロファイル: クライアントが提供する任意のモデル ID ではなく、承認されたリアルタイム モデルまたはデプロイメントです。
• リージョンと保持ポリシー: 選択したプロバイダーのリージョンと機能セットがテナントのデータ ルールに一致するかどうか
• 最大セッション時間: たとえば、プランにより 5、15、または 30 分です。
• 許可されるモダリティ: 音声入力、音声出力、テキスト、画像、またはツール呼び出し。
• 音声と指示のテンプレート: ポリシーによって固定または制限されます。
• 利用可能な予算: 前払い残高、予約されている月額枠、または機能ごとの使用上限。
• 同時実行性: テナントレベルおよびユーザーレベルのアクティブ音声セッション
• 不正行為の制御: ユーザー リスク フラグ、発信元レピュテーション、異常な通話速度、またはテナント キル スイッチ。

安全なデフォルトは、あいまいなリクエストを拒否することです。クライアントがテナントのリアルタイム ポリシーにないモデル、ツール、音声、またはリージョンを要求した場合、ゲートウェイはアクセスを黙って拡大するのではなく、明確なポリシー エラーを返す必要があります。

セッション記録のデザイン

プロバイダーの資格情報を作成する前に、ゲートウェイ側のセッション レコードを作成します。これにより、プロバイダの作成は成功してもブラウザが接続しない場合でも、監査アンカーが得られます。

{
  "session_id": "rt_01j...",
  "テナントID": "テナント_123",
  "end_user_id": "user_hash_456",
  "プロバイダー": "プロバイダー_a",
  "provider_session_id": null、
  "model_profile": "音声サポート標準",
  "upstream_model_or_deployment": "リアルタイムモデル-x",
  "地域": "イーストス",
  "session_config_hash": "sha256:...",
  "allowed_modalities": ["audio_input", "audio_output"],
  "allowed_tools": ["lookup_order_status"],
  "tool_approval_policy": "approve_side_Effects",
  "budget_reservation_id": "resv_789",
  「最大期間秒数」: 900、
  "発行日": "2026-08-21T10:00:00Z",
  "expires_at": "2026-08-21T10:01:00Z",
  "client_origin": "https://app.example.com",
  "device_id_hash": "sha256:...",
  "ステータス": "鋳造中"
}

デフォルトでは、生のマイク音声や完全なプロンプトは保存されません。構成ハッシュ、ID、ポリシー決定、および監査、サポート、請求に十分な最小限のメタデータを保存します。記録が必要な場合は、明示的かつ同意を意識し、テナント ポリシーに基づいて記録してください。

一時的なトークン鋳造エンドポイント

ゲートウェイ側のエンドポイントは次のようになります。

POST /v1/realtime/sessions
認可: ベアラー 
コンテンツタイプ: application/json
{
  "テナントID": "テナント_123",
  "end_user_id": "user_hash_456",
  "機能": "support_voice_agent",
  "origin": "https://app.example.com",
  "device_nonce": "8f3b...",
  "requested_profile": "音声サポート標準"
}

応答では、アップストリーム ランタイム キーが公開されるべきではありません。

{
  "session_id": "rt_01j...",
  "プロバイダー": "プロバイダー_a",
  "トランスポート": "webrtc",
  "client_secret": "ephemeral_secret_here",
  "expires_at": "2026-08-21T10:01:00Z",
  「承認されました」: {
    "model_profile": "音声サポート標準",
    「最大期間秒数」: 900、
    "モダリティ": ["オーディオ入力", "オーディオ出力"],
    "ツール": ["ルックアップ_オーダー_ステータス"]
  }
}

オリジン、認証されたユーザー セッション、テナント、および nonce に発行をバインドします。プロバイダーはこれらのバインディングのすべてをネイティブにサポートしていない可能性があるため、ゲートウェイでできることを強制してください。つまり、ミント試行のレート制限、予期せぬオリジンの拒否、デバイスのメタデータの記録、トークンの有効期間の短縮などです。

セッション テンプレート: デフォルトでは狭い

リアルタイム セッション テンプレートは、一般的なチャット完了リクエストよりも制限を厳しくする必要があります。音声セッションはインタラクティブであり、リアルタイムで検査することが難しく、予想よりも長時間実行される可能性があります。

推奨されるテンプレート フィールドは次のとおりです:

• 固定モデルまたは導入: ゲートウェイ側のモデル プロファイルによって選択されます。
• 手順: テナントが承認した変数を含むサーバー制御のプロンプト テンプレート。
• 音声: 許可リストから選択されました。
• モダリティ: 製品で必要な場合を除き、テキスト、画像、またはツール モードを無効にします。
• 入力音声設定: サポートされている場合、検出、文字起こし動作、または無音処理を切り替えます。
• 出力制約: サポートされている場合の最大応答長または応答動作。
• ツール許可リスト: 機能に必要なツールのみ。
• セッションの有効期間: 認証情報の短い有効期限と最大通話時間。

厳格なテンプレートは柔軟性を低下させますが、コスト、コンプライアンス、サポートが容易になります。製品チームが動的な音声や指示を必要とする場合は、任意のクライアント設定をプロバイダに渡すのではなく、制御されたプロファイルのバリアントを公開します。

リアルタイム音声の予算管理

リアルタイムの使用量は、最終的なプロバイダーの使用量が到着する前に価格を設定するのが難しい場合があります。セッションは 5 秒または 20 分続く場合があります。これには、音声入力、音声出力、文字起こし、ツール呼び出し、テキスト トークンが含まれる場合があります。したがって、ゲートウェイは予約、上限、調整を組み合わせる必要があります。

鋳造前

• 最大期間、モデル、モダリティ、テナント プランから最悪の場合または控えめなセッション コストを見積もる
• クライアント シークレットを発行する前に予算を確保する
• テナントに十分な残高がない場合、または 1 日の音声制限に達している場合は、新しいセッションを拒否します。

セッション中

• アクティブなセッションと予想される書き込み速度を追跡する
• テナントとユーザーの同時実行数の上限を適用する
• プロバイダーがサポートする終了機能またはセッション更新機能が利用可能な場合は使用します。
• 異常なセッション継続時間、繰り返しの再接続、または異常な音声の使用に対してアラートをトリガーします。

セッション後

• プロバイダの使用状況イベントまたは最終使用状況レポート（利用可能な場合）を取り込む
• 予約された予算を実際の費用に設定します。
• 正確な使用が遅れたり不完全な場合は、調整されるまで控えめな予約を保留します。
• 使用状況をテナント、ユーザー、機能、モデル プロファイル、セッション ID に関連付けます。

これは、応答時の同期テキスト請求よりも正確ではありませんが、予約なしで直接認証情報を発行するよりも運用上安全です。

リアルタイム セッション内でのツール呼び出し

リアルタイム音声エージェントは、多くの場合、アカウントの検索、予約、チケットの更新、ワークフローのトリガーなどのツールを呼び出すことができるとさらに便利になります。ツールの実行をオーディオトランスポートとは別に扱います。

ブラウザのメディア接続は、副作用を実行する許可を暗示してはなりません。ゲートウェイまたはバックエンドは以下を強制する必要があります:

• ツール レジストリ: 各ツールには、所有者、スキーマ、スコープ、リスク レベルがあります。
• 許可リスト: セッション テンプレートには、使用可能なツールが正確にリストされます。
• 承認ゲート: 副作用のあるアクションには、ユーザーの確認、人による承認、またはポリシーの承認が必要です。
• 個別の認証情報: ツールの認証情報がブラウザ セッションに埋め込まれることはありません。
• 結合された監査証跡: すべてのツール呼び出しはリアルタイム セッション ID を参照します。

たとえば、サポート音声エージェントは lookup_order_status を自動的に呼び出すことができますが、refund_payment には明示的な確認とバックエンド承認イベントが必要な場合があります。リアルタイム プロバイダーは会話を調整できますが、ゲートウェイが権限の境界を管理する必要があります。

すべてのバイトをプロキシすることなく可視化

ダイレクト WebRTC メディア フローにより、ゲートウェイの遅延と帯域幅の負荷が軽減されますが、可視性はプロバイダーのイベントと独自のセッション メタデータに依存するようになります。複数の証拠ソースに基づいて分析を設計します:

• ゲートウェイからのセッション作成記録。
• クライアント側のライフサイクル イベント（接続、切断、再接続の試行、マイクの拒否、通話の終了など）
• プロバイダのセッション ID、使用イベント、または最終的な使用記録。
• プロバイダの使用が遅れた場合の期間ベースの見積もり
• セッション ID によって結合されたツール呼び出しログ。
• 予算の予約と決済の記録

コントロールを起動する前に、プロバイダーのテレメトリが完全になるまで待たないでください。控えめな予約と明確な帰属から始めて、プロバイダーの使用状況レポートが成熟するにつれて決済の精度を向上させます。

セキュリティチェックリスト

• 標準プロバイダ API キーをブラウザまたはモバイル クライアントに送信しないでください。
• リアルタイムのセッション開始には、有効期間が短い一時的なクライアント シークレットを使用します。
• トークンの作成前にエンドユーザーを認証します。
• 可能な場合、ミントの決定をテナント、ユーザー、オリジン、ノンス、デバイスのメタデータにバインドする
• プロバイダーのランタイム認証情報をバックエンド ボールトまたはゲートウェイ シークレット ストアに保管します。
• プロバイダーのミントの前にセッション監査行を記録します。
• 任意のクライアント構成ではなく、テナントが承認したセッション テンプレートを使用します。
• 同時実行性、毎日の使用量、最大期間制限を適用します。
• 副作用に備えて、ツールのホワイトリストと承認ゲートを使用します。
• デフォルトでは、生のプロンプトと音声の保持を最小限に抑えます。
• トークンの有効期間、リージョン、ツール、使用状況イベント、終了制御に関するプロバイダー機能マトリックスを維持する

プロバイダーの機能マトリックス

リアルタイム API は異なるため、仮定ではなく機能に基づいてゲートウェイ アダプターをモデル化します。単純なマトリックスにより、ルーティングとポリシーの決定を推進できます。

{
  "プロバイダー_a": {
    "トランスポート": ["webrtc", "websocket"],
    "ephemeral_client_tokens": true、
    「token_ttl_秒」: 60、
    "server_side_disconnect": true、
    "session_update": true、
    "usage_events": "final_and_incremental",
    "地域": ["米国"、"EU"]、
    "tool_approval_supported": true
  }、
  "プロバイダー_b": {
    "トランスポート": ["ウェブソケット"],
    "ephemeral_client_tokens": true、
    「トークン_ttl_秒」: 120、
    "サーバー側_切断": false、
    「セッション更新」: false、
    "usage_events": "final_only",
    "地域": ["私たち"]、
    "tool_approval_supported": false
  }
}

テナントが EU 常駐とサーバー側の終了を必要とする場合、ゲートウェイは両方を満たすプロバイダーと展開にのみルーティングする必要があります。ポリシーを満たすプロバイダがない場合は、フェールクローズされます。

移行パス

初日からすべてのコントロールを構築する必要はありません。実際のロールアウトは次のとおりです。

実行可能な結論

リアルタイム音声 AI の場合、AI API ゲートウェイは自動的にメディア リレーになるべきではありません。より安全でレイテンシが低いアーキテクチャでは、ゲートウェイがコントロール プレーンを管理し続けることになります。つまり、ユーザーの認証、テナント ポリシーの適用、予算の確保、監査レコードの作成、狭い範囲の一時的な認証情報の作成、およびセッション後の使用状況の調整が行われます。

中心的な実装ルールは単純です。ブラウザは、有効期間の短いセッション シークレットを受信する場合がありますが、有効期間の長いプロバイダ キーを受信することはありません。厳密なテンプレート、オリジンを意識したミント、同時セッションの上限、ツールの承認、使用量の決済、プロバイダーの機能マトリックスなど、他のすべてはその境界に従います。これにより、API キー管理、AI API コスト管理、チーム API ガバナンス、AI 使用状況分析を諦めることなく、製品チームにリアルタイムの音声エクスペリエンスが提供されます。

関連記事

• ランタイム用プロバイダー認証情報ボールトキー
• 予算予約および決済台帳