For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
メインナビゲーション
Theme

おすすめ

GPT-Live

Realtime API

音声を使った開発

接続

音声処理

API ダッシュボード
ChatGPT を試す

GPT-Live の委譲とツール

バックエンドのエージェントを接続し、検証済みの結果をライブ会話に返す方法を説明します。

GPT-Live は音声での会話を担当し、推論とツールの利用をバックエンドに委譲します。バックエンドの処理には、あらかじめ設定した Responses モデルを使えます。クライアント委譲では、アプリケーションが運用する任意のモデル、エージェント、サービスを使えます。どちらのモードでも、権限、ユーザーへの確認、業務記録、タスクの状態はアプリケーションが管理します。

委譲やツール利用のタイミングを指示する方法は、プロンプトガイドの委譲とツール利用に向けたライブモデルへの指示を参照してください。

このページのイベント例で使う connection は、接続ガイドに従って接続した Live のプライマリ WebSocket またはサイドバンド接続です。プライマリ接続では、session.started を受信してからイベントヘルパーを呼び出してください。サイドバンド接続をアタッチした時点で、その接続は実行中のセッションに属しています。

委譲モードの選択

委譲モードに Responses 委譲 を選ぶと、GPT-Live が指定された Responses モデルを呼び出し、会話のコンテキストを渡して、バックエンドの結果をライブ会話に返します。一方、クライアント委譲 では、アプリケーションがコンテキストを準備し、エージェントまたはワークフローを実行して、結果を GPT-Live に返します。

リクエストの管理を GPT-Live に任せる場合は、Responses 委譲から始めてください。独自のワークフローを実行する場合や、結果を GPT-Live に送る前に確認する必要がある場合は、クライアント委譲を選びます。

検討項目 Responses 委譲が適している場合 クライアント委譲が適している場合
実装の手間 バックエンドリクエストの準備、接続の管理、会話への結果の返送を GPT-Live に任せたい。 これらの処理を自分で実装、運用したい。
バックエンドの結果の確認 バックエンドの出力をそのまま GPT-Live に返せる。 GPT-Live に渡す前に、アプリケーションで結果を検証したり、一部を伏せたり、複数の結果をまとめたり、破棄したりする必要がある。
バックエンドの機能 GPT-Live がサポートする Responses の設定とツールでワークフローを実行できる。 別のバックエンド、複数のモデル、またはマネージド構成では使えない API 機能が必要。
コンテキストの管理 GPT-Live が渡す会話のコンテキストがアプリケーションの要件に合う。 各バックエンドリクエストに含める履歴、メモリ、アプリケーションの状態を個別に選ぶ必要がある。
実行ポリシー あらかじめ設定したモデルとツールの呼び出しループでタスクを処理できる。 コードとモデルの間での処理の振り分け、フォールバック、チェックポイント、複数のバックエンドステップにまたがる予算管理などを独自に行う必要がある。

たとえば旅行アシスタントでは、フライトの運航状況に関する質問は航空会社のサービスに送り、旅程の変更は別の計画エージェントに任せることができます。アプリケーションが呼び出すバックエンドを選び、検証済みの結果のうち何を GPT-Live に返すかを決めます。

どちらのモードでも、アプリケーションがタスクの進捗を追跡し、カスタムツールの実行前に権限をチェックして、必要なユーザー確認を行います。アプリケーションがバックエンドの結果を確認している間も、GPT-Live は話し続けることができます。ユーザーに音声を聞かせるタイミングをアプリケーションで制御する必要がある場合は、再生制御を追加してください。

クライアント委譲では、会話のコンテキストを保持するのもアプリケーションの役割です。委譲イベントにはメタデータが含まれますが、タスクの内容を示すテキストは含まれません。文字起こしイベントとアプリケーションの状態を使ってバックエンドリクエストを準備してください。

実際のワークロードで音声エージェントを評価し、レイテンシ、タスクの成功率、コストを比較してください。既存のアーキテクチャに応じた選び方は、GPT-Live への移行を参照してください。

モードはセッション作成時に選びます。モードを変更するには、新しいセッションを開始してください。

委譲モード

Responses 委譲の設定

次の委譲設定を Live セッションの作成時に追加します。Responses モデルは音声モデルとは別に選びます。

export const session = {
  model: "gpt-live-1",
  delegation: {
    type: "responses",
    responses: {
      model: "gpt-6-luna",
      instructions: "[Your backend prompt]",
    },
  },
};

まずは gpt-6-luna を使い、バックエンドのタスクが複雑な場合は gpt-6-sol も試してください。実際のタスクで回答の品質とレイテンシを比較してから、バックエンドモデルを選びます。

サポートされているツールを delegation.responses.tools に登録します。delegation.responses.tool_choice に "auto" を指定すると、バックエンドがツールを選びます。"required" はツール呼び出しを必須にし、"none" はツール呼び出しを無効にします。関数を名前で指定することもできます。

並列呼び出しの設定 delegation.responses.parallel_tool_calls に true を指定すると、1 回のレスポンスで複数のツール呼び出しが可能になります。順次呼び出す場合は false を指定します。カスタム関数の実行と、依存関係や必要な承認の確認はアプリケーションが行います。これらの設定は GPT-Live が処理を委譲した後に適用されます。いつ委譲するかはライブプロンプトで指示します。

Responses の構成では、セッション作成時にバックエンドの model を指定する必要があります。以下のツールに加え、max_output_tokens（指定する場合は 16 以上）、service_tier、選択したバックエンドモデルがサポートする reasoning と text の各設定を利用できます。調整できる設定については、バックエンドのレイテンシ削減を参照してください。

モデルとプロジェクトで Fast モードを利用できる場合は、低レイテンシが求められる呼び出しでの利用を検討してください。GPT-Live では delegation.responses.service_tier: "priority" で選択します。

会話中に設定を変更するには、session.update を送信し、session.delegation.responses に変更内容を含めます。バックエンドモデル、指示、ツール、tool_choice など、サポートされている設定を更新できます。省略した設定は現在の値を維持します。

Responses 委譲とクライアント委譲を切り替えるには、新しい Live セッションを作成します。delegation を null に更新するとクライアントモードが選択されるため、実行中の Responses セッションにこの更新を送ると immutable_field_update エラーになります。

これらの設定は Responses と共通の仕組みを使いますが、Live がサポートするのは単体の Responses API の機能の一部です。Live が会話のコンテキストを渡し、委譲先での処理を開始します。バックエンドはセッションを通じて設定してください。Live の response.create コマンドはその設定を使用し、単体の Responses API のリクエストボディは受け付けません。

ホスト型ツールの追加

利用するツールを、ウェブ検索、ファイル検索、Code Interpreter、ホスト型シェル、画像生成から選んで delegation.responses.tools に追加します。設定方法、対応モデル、必要なリソースについては、各ツールのガイドを参照してください。Responses がこれらのツールを実行し、結果を自動的に返します。

シェルにはホスト型コンテナを使用し、必要に応じてスキルを組み合わせます。新しくアップロードしたスキルを使う場合は、参照するバージョンが読み取り可能になるまで待ってから Live セッションを開始してください。ローカルシェルの場合、呼び出しはアプリケーションが実行します。Live はシェルの domain_secrets をサポートしていません。

MCP とその他のツールの追加

Responses 委譲では、MCP、ツール検索、プログラムによるツール呼び出し、関数とカスタムツール、コンピューターの使用、ローカルシェル、パッチの適用もサポートしています。設定方法は各ガイドを参照してください。アプリケーションで得た結果と承認判断は、Live で処理を再開する手順に従って返します。

Live は、指定された MCP の authorization と headers を Responses に渡しますが、アプリケーションに返すセッション設定にはこれらの値を含めません。指示など、他の設定を更新する際に再送する必要はありません。delegation.responses.tools を置き換える場合は、MCP の認証情報を再度含めてください。

設定エラーへの対処

Live は起動後と設定変更時に、Responses の設定を非同期で検証します。session.started と session.updated は検証の完了を待ちません。error イベントを監視し、コードが responses_validation_failed の場合は、メッセージでサポートされていない設定やアクセスできないリソースを確認してください。セッションは開いたままで、設定はロールバックされません。session.update で修正してください。

たとえば、スキルの version に 1 のような数値を指定すると、responses_validation_failed という非致命的なエラーが session.start または session.update に対して返されます。response.create を待たずに、エラーメッセージから無効なフィールドと期待される型を特定できます。error.client_event_id を設定イベントの ID と照合してください。同じセッションで復旧するには、session.update で無効なツール設定を削除します。バージョンには "1" のような文字列を使ってください。

検証に成功しても、その後のツール実行が保証されるわけではありません。リソースへのアクセス可否やツールの利用可否は変わり得るため、委譲先での処理中もバックエンドエラーを処理してください。ホスト型ツールを設定すると、検証中にコンテナなどのリソースが初期化されることがあります。

アプリケーションからのライブ会話の制御

Responses 委譲ではバックエンドのワークフローが管理されますが、アプリケーションから GPT-Live モデルに直接コンテキストを送ることもできます。サイドバンド WebSocket またはメインのイベント接続で通話を監視している場合は、session.instructions.append、session.thinking.append、session.commentary.append を delegation_id: null とともに使えます。たとえば、文字起こしを監視するガードレールから、会話の方向を変える指示を追加できます。この指示はライブモデルに作用します。Responses バックエンドのプロンプトを変更したり、進行中の処理を取り消したりすることはありません。

Responses 委譲のイベント処理

Responses に処理を委譲した場合、session.delegation.created には target: "responses" と response_id が含まれます。以降の Responses イベントは、次のように response.event に格納されて届きます。

{
  "type": "response.event",
  "event_id": "event_response_1",
  "delegation_id": "item_9tA2cB6n2V8c4X1z7Q5r9",
  "event": {
    "type": "response.output_text.delta",
    "sequence_number": 4,
    "item_id": "msg_123",
    "output_index": 0,
    "content_index": 0,
    "delta": "The forecast is",
    "logprobs": []
  }
}

最上位のイベントタイプが response.event の場合は、envelope.event.type に応じて処理を振り分けます。バックエンドイベントと委譲を対応付けるために、外側の delegation_id を保存してください。ハンドラーには、ここで紹介しているもの以外の Responses ライフサイクルイベントも入れ子になって届くことがあります。

ホスト型ツールの進捗、引用元、ファイル、生成画像は、これらの入れ子のイベントに含まれます。転送されるライフサイクルのスナップショットでは出力配列の内容が省略されるため、出力項目や部分画像のイベントを個別に読み取って結果を集めてください。ファイルのダウンロードには、対応する Responses のファイル API またはコンテナ API を使います。大きな画像や成果物を含むイベントには WebSocket またはサイドバンド接続を使ってください。WebRTC データチャネルではメッセージサイズの上限が小さい場合があります。

Live の発話と委譲先での処理は独立して進みます。バックエンドのレスポンスが完了しただけでは、ユーザーが回答を聞いたかどうかは分かりません。実際の発話については、Live の出力の文字起こしと音声を使ってください。

ツールの結果と承認判断の返送

アプリケーションからの入力が必要なツールについては、入れ子の response.output_item.done イベントから完了した呼び出しを収集します。許可された操作を実行するか、承認の可否を確認してから、対応する項目を response.item.create で送信します。

受信した項目 返す項目
function_call function_call_output
custom_tool_call custom_tool_call_output
computer_call computer_call_output
ローカルの shell_call shell_call_output
apply_patch_call apply_patch_call_output
tool_search_call（execution: "client" を指定） tool_search_output（execution: "client" と検索で見つかった tools を含む）
mcp_approval_request mcp_approval_response

結果と呼び出しは call_id で対応付けます。MCP の承認判断を返す場合は、代わりに approval_request_id に承認リクエストの id を指定し、approve を true または false に設定します。完了済みの mcp_call 自体に対して、クライアントが結果を返す必要はありません。各ツールの結果スキーマに従い、プログラムによる関数呼び出しでは caller メタデータを含め、コンピューターの使用で安全性の確認が求められる場合はその確認も含めてください。

結果待ちの呼び出しすべてに結果を返し、その後 response.create を送信します。項目を追加しただけではバックエンドの処理は再開されません。結果が不足している場合は tool_outputs_required、不足しているのが関数の結果だけの場合は function_call_outputs_required が返されます。重複する結果や、呼び出しに対して型が一致しない結果は拒否されます。

現在のバックエンドレスポンスが完了する前でも、結果を送信して処理の再開をリクエストできます。受理された response.create はそのレスポンスの完了を待つので、再送しないでください。その後バックエンドから追加の呼び出しが届いたら、その結果を返して、改めて response.create を送信します。

カスタム関数の実行と結果の返送

入れ子の response.output_item.done イベントから、完了した関数呼び出しを読み取ります。完了した関数呼び出しの項目には call_id、name、arguments が含まれます。引数の確定を通知するイベントだけでは呼び出しを特定できません。

入れ子の response.created から取得したレスポンス ID を、外側の delegation_id とともに記録します。そのレスポンスの関数呼び出しを response.output_item.done から収集し、処理を再開する前にどのツールの結果を返す必要があるかを判断します。

転送されるライフサイクルイベントでは、response.completed を含め、結果を返す必要がある関数呼び出しがあっても response.output: [] となります。これらのイベントでは tools 配列も空で、instructions: null となり、input フィールドはありません。関数呼び出しは個々の出力項目イベントから読み取ってください。

許可された操作を実行したら、結果を Responses の項目として追加します。

export function sendUpdate(connection) {
  connection.send({
    type: "response.item.create",
    event_id: "tool_result_1",
    item: {
      type: "function_call_output",
      call_id: "call_123",
      output: '{"status":"confirmed","order_id":"order_123"}',
    },
  });
}

続いて、レスポンスの再開を明示的にリクエストします。

export function sendUpdate(connection) {
  connection.send({
    type: "response.create",
    event_id: "continue_1",
  });
}

結果待ちの関数呼び出しごとに response.item.create で結果を送信し、その後 response.create を送信してバックエンドレスポンスを再開します。response.item.create には成功を個別に通知するイベントがないため、引き続きエラーと入れ子の Responses ライフサイクルイベントを処理してください。

どちらのコマンドにも Responses 委譲が必要です。Live の response.create コマンドは、セッションに保存されたバックエンド設定を使います。イベントのペイロードには上記の例を使い、バックエンドモデルなどの設定はセッションを通じて指定してください。

既存のバックエンドプロンプトの活用

既存のテキストエージェント用プロンプトを出発点にします。タスクの指示と業務ルールはバックエンドに残し、テキストチャットや発話の直接制御を前提とする指示は調整してください。音声の文字起こしをどう扱い、どのような結果を返すと役立つかを明示します。権限のチェックと必要なユーザー確認はアプリケーションで確実に行ってください。

## 音声会話のコンテキスト
あなたは、リアルタイムの音声会話を担当するアシスタントを支援しています。文字起こしには、誤りや言いかけの言葉、後からの訂正が含まれることがあります。最新のコンテキストと確認済みの記録を使ってください。それでも必要な情報がはっきりしない場合は、推測せず、不明な点を質問してください。

## タスクの指示
[Your task instructions, business rules, available tools,
and confirmation requirements.]

## 結果の返し方
関連する事実、タスクの現在の状態、次に取るべき手順を返してください。
ツールまたはサービスから操作の成功を確認できた場合に限り、その操作が完了したと報告してください。
結果がはっきりしない場合は、その旨を伝え、何を確認する必要があるかを説明してください。

大きな構造化ペイロード、長いツール出力、画面表示用の Markdown はバックエンドに保持します。GPT-Live には関連する事実を渡し、話し方はモデルに任せます。ツールの結果が簡潔であれば、発話用に書き直すためにモデルを追加で呼び出す必要はありません。

クライアント委譲では、結果を GPT-Live に直接返します。Responses 委譲では、必要なツールの結果や承認判断を返して、バックエンドの処理を再開します。ホスト型ツールの場合は、アプリケーションから結果を返さなくても処理が続きます。

用途に合った更新の送信

GPT-Live に内容をどう使わせるかに応じてイベントを選びます。

送信する内容 イベント
進行中のライブ会話に対する指示。たとえば、所定の事項を伝える指示や発話を止める指示 session.instructions.append
内部での推論に使う情報。追加時には読み上げず、関連するユーザーの質問に答える際に利用可能 session.thinking.append
モデルが追加されたテキストを言い換えて音声で伝える情報 session.commentary.append

いずれのイベントも content にプレーンな文字列を指定し、追加 1 回あたりの上限は 500 トークンです。delegation_id も含めてください。特定のタスクに関する更新には元のクライアント委譲 ID を、セッション全体のコンテキストには null を使います。null 以外を指定する場合は、既知のクライアント委譲の ID である必要があります。指示は引き続きライブセッションに適用されます。ID を指定しても、別個のバックエンドプロンプトになるわけではありません。

冒頭で挨拶するには、セッション作成時に developer メッセージとして挨拶の指示を session.input に含めます。session.started の後、音声入力が有効な状態で、同じ指示を session.commentary.append で 1 回だけ送信し、一意の event_id と delegation_id: null を指定します。モデルが文面を言い換える場合があり、受信確認が返っても発話や再生を確認したことにはなりません。一連の手順と、決まった文言での発話や再生の確認が必要な場合にアプリケーションで再生を制御する方法は、通話相手が話す前の挨拶を参照してください。

追加した指示によって、モデルの現在の発話や動作が中断される場合があります。アプリケーションから会話の方向を変える必要があるときに使ってください。関連するツールや操作のブロックは、アプリケーションの状態に反映して確実に適用します。

クライアントが管理するタスクの進捗を、読み上げずに伝える例です。

export function sendUpdate(connection) {
  connection.send({
    type: "session.thinking.append",
    event_id: "availability_progress",
    delegation_id: "item_123",
    content: "Checking Thursday availability. No appointment has been booked.",
  });
}

予約が確定したら、ユーザーに音声で伝える結果を送信します。

export function sendUpdate(connection) {
  connection.send({
    type: "session.commentary.append",
    event_id: "appointment_result",
    delegation_id: "item_123",
    content: "Your appointment is confirmed for Thursday at 2:00 PM",
  });
}

この結果は、予約が実際に成功してから送信してください。セッション全体への指示には session.instructions.append を使い、delegation_id: null を指定します。

たとえば、アプリケーションがガードレールに基づいてリクエストをブロックした後、次のように会話の方向を変えることができます。

export function sendUpdate(connection) {
  connection.send({
    type: "session.instructions.append",
    event_id: "guardrail_block_17",
    delegation_id: null,
    content:
      "Stop speaking about that request. Briefly explain that you cannot help with it, then wait for the user.",
  });
}

この指示でバックエンドの処理が取り消されることはありません。該当する操作のブロックと、すでに実行中の処理への対処はアプリケーションで行ってください。

対応する受信確認イベントは session.thinking.appended、session.commentary.appended、session.instructions.appended です。各イベントの client_event_id を送信時の event_id と照合します。受信確認は、コンテキストがモデルに反映されると推定される時点まで待ちますが、発話や再生の完了までは待ちません。タイミングとエラー処理については、コンテキストがモデルに届くタイミングを参照してください。

GPT-Live が会話に使える事実や簡潔な進捗を送信してください。session.thinking.append で送った内容はその後の発話に影響する可能性があります。機密情報やバックエンドの非公開の推論内容はアプリケーション内に保持してください。

ツール実行中の自動応答の抑制

クライアント委譲では、受け付けを知らせる自動応答が生成される前に、発話を伴わないコンテキスト更新を送ることで、保留中の自動応答を取り消せます。

セッション作成時に delegation.acknowledgement_delay_ms を設定し、アプリケーションが更新を送る時間を確保します。たとえば、クライアント委譲を次のように設定します。

{
  "delegation": {
    "type": "client",
    "acknowledgement_delay_ms": 800
  }
}

委譲イベント session.delegation.created を受信したらすぐに、session.thinking.append を空の content で送信します。一意の event_id を使い、event.delegation.id の値を delegation_id にコピーしてください。バックエンドの結果を待つ前に送信します。

{
  "type": "session.thinking.append",
  "event_id": "event_quiet_progress_1",
  "delegation_id": "item_9tA2bF3h7K9m2P5q8R1s4",
  "content": ""
}

バックエンドの処理を続け、検証済みの結果を音声で伝えられる段階になったら、同じ委譲 ID を指定して session.commentary.append で結果を送ります。進捗もコンテキストとして渡したい場合は、推論用の更新に "Lookup in progress." のように事実を記述しても、モデルにその更新を読み上げるよう求めることなく、保留中の自動応答を取り消せます。

推論用または発話用の更新を追加すると、セッション内で保留中の自動応答がすべて取り消されます。他の委譲に対する自動応答も対象です。すでに生成された音声が停止することはなく、モデルが自動応答とは別に話すことも妨げません。遅延設定が制御するのは、自動応答をリクエストするタイミングです。モデルがそれより早く話す場合もあります。イベントの仕様は、クライアント委譲の設定と推論用の更新に関するリファレンスを確認してください。

受信した session.thinking.appended イベントの client_event_id を送信したイベントの ID と照合します。これで確認できるのはコンテキストが届いたことであり、無音だったことまでは確認できません。実際のワークロードで出力音声をテストし、確実に無音にする必要がある場合はアプリケーション側の再生制御を使ってください。

正確で役立つ進捗の通知

時間のかかるタスクでは、ステップが完了したとき、遅延を知らせる必要が生じたとき、ユーザーに質問への回答を求めるときなど、伝える意味のある変化があった時点で更新を送ります。

クライアントモードで進捗をバックグラウンドで伝えるには session.thinking.append を使います。ユーザーに音声で知らせると役立つ更新には session.commentary.append を使います。

音声で知らせる場合は session.commentary.append を使い、確認済みのタスクの状態に合った内容を送信してください。

状態 通知内容の例
処理中 「予約できる時間を確認しています。」
完了 「木曜日の午後 2 時で予約が取れました。」
失敗 「その時間はすでに埋まっています。」
キャンセル確認済み 「予約をキャンセルしました。」

ユーザーが依頼を変更したら、アプリケーションで進行中のタスクを更新します。たとえば、金曜日から木曜日に変更された場合は、以降の処理には木曜日を使い、古い金曜日の依頼に対する結果は無視します。キャンセルはバックエンドで管理し、成功を確認してから、処理を取り消したことをユーザーに伝えてください。音声会話を中断しても、バックエンドの処理は続きます。

失敗したツール呼び出しを再試行する前に、元の操作がすでに実行されていないかを確認してください。たとえば、レスポンスが失われたことを理由に二重予約してはいけません。結果が不明な場合は、その旨を伝え、次に取れる具体的な手順を案内してください。

UI コンテキストの共有

現在のページやタスク、関連する選択内容、「この選択肢」といった表現が何を指すかを判断するのに役立つ情報を、簡潔にまとめて GPT-Live に渡します。要約はアプリケーションの状態から直接組み立ててください。形式を整えるためにモデルを追加で呼び出す必要はありません。

UI コンテキストは、セッション開始時と関連する状態が変化したときに送信します。状態に変化がなければ送信を省き、短時間に変更が続いた場合は、最新の状態を短くまとめて送ります。以前の選択から何が変わったかを明示してください。

  • 初期コンテキスト：「ユーザーは 8 月 6 日午後 7 時、2 名でのレストラン予約を検討しています。予約はまだ成立していません。」
  • 訂正：「選択した時間が午後 8 時に変わりました。変更前は午後 7 時でした。」

どちらの委譲モードでも、session.thinking.append に delegation_id: null を指定して、バックグラウンドでコンテキストを更新できます。HTML 全文、DOM ツリー、大きな JSON ペイロード、操作ログはアプリケーションまたはバックエンドに保持してください。ページの内容は指示として扱わず、参照用のデータとして扱います。

テキスト入力の受け付け

注文番号などの入力値は、ユーザーが提供したデータとしてバックエンドに送り、入力された文字列をそのまま使えるようにします。

Responses 委譲では、バックエンド向けのユーザーメッセージをキューに追加します。

export function sendUpdate(connection) {
  connection.send({
    type: "response.item.create",
    event_id: "typed_order_number",
    item: {
      type: "message",
      role: "user",
      content: [
        {
          type: "input_text",
          text: "My order number is A0042.",
        },
      ],
    },
  });
}

バックエンドの処理を開始または再開する準備ができたら response.create を送信します。関数の結果を待っている場合は、先に必要な結果をすべて返してください。テキストをキューに追加するだけでは、実行中の処理は取り消されません。

画像と視覚的なコンテキストの追加

通話相手が写真や画面について話せるようにするには、画像と関連するコンテキストをアプリケーションから画像認識に対応したバックエンドに送ります。バックエンドが画像を解釈し、GPT-Live が会話に使える情報をテキストで返します。Live の音声フロントエンドは画像を直接受け付けません。

Responses 委譲では、画像認識に対応したバックエンドモデルを設定します。Responses がサポートする画像入力項目を response.item.create でキューに追加し、response.create を送信してバックエンドの処理を開始または再開します。再開前に、保留中のツール呼び出しに必要な結果と承認判断をすべて返してください。詳しくは、Responses 委譲のイベント処理を参照してください。

バックエンドへの画像入力は session.input と分けて扱ってください。このフィールドは、起動時にテキスト履歴を Live フロントエンドに渡すためのものです。対応する画像形式とモデルの制約は、画像と画像認識を参照してください。

バックエンドのレイテンシ削減

バックエンドに処理を依頼してから、会話に使える結果が得られるまでの時間を短縮します。各段階のレイテンシを測定して、遅延が生じている箇所を特定してください。同じシナリオで、役立つ回答が音声で返るまでの時間とタスクの成功率を比較します。評価方法については、音声エージェント評価の Cookbookを参照してください。

Responses 委譲

Live は Responses への永続的な WebSocket 接続を管理し、既知のリクエスト設定を事前に準備します。使用中の接続と状態が対応していれば、以前のレスポンスの状態も再利用できます。実際のワークロードで応答時間と報告されたキャッシュ使用量を測定し、効果を確認してください。

バックエンドの設定は delegation.responses で調整します。

  • model：推論とツール選択を担うモデルを、音声モデルとは別に選びます。
  • reasoning.effort：そのモデルがサポートする値から推論強度を選び、推論時間とタスクの品質を調整します。
  • service_tier：モデルの対応状況とプロジェクトのアクセス権に応じて、auto、default、flex、priority のいずれかを使います。auto はプロジェクトの設定に従います。選んだサービスティアの性能とコストを評価してください。

サポートされている設定は、セッション中に session.update で更新できます。カスタムツールは引き続きアプリケーションで実行するため、Live が Responses への接続を管理していても、時間のかかるサービス呼び出し、キューでの待機、ツール結果のバッファリングによって回答が遅れる場合があります。必要なツール結果をそれぞれ速やかに返し、バックエンドレスポンスを再開してください。

文字起こしの断片に応じた処理

文字起こしの断片をアプリケーションで処理するかどうかは任意で、どちらの委譲モードでも利用できます。ユーザーとアシスタントの文字起こしの断片は、WebSocket または WebRTC データチャネル経由で届きます。アプリケーションのロジックや軽量モデルでこれらを処理すれば、委譲イベントが届く前に処理を始められます。また、文字起こし自体をきっかけに、アプリケーション独自の処理を開始することもできます。

この方法は次の用途に使えます。

  • 待ち時間の短縮。 十分な情報が揃った時点で、先回りして照会を始めます。たとえば、ユーザーが希望条件を話している間に空き状況を確認できます。
  • ガードレールの適用。 逐次追加される文字起こしを確認し、介入が必要な依頼や応答を検出します。会話へのガードレールの適用を参照してください。
  • 会話の調整。 混乱やいら立ちをうかがわせる言い回しを捉え、対話の進め方を変えたり、状況に応じた具体的な指示を送ったりします。
  • インターフェースの更新。 関連するコントロールを強調表示したり、該当するフィールドに入力候補を設定したり、結果が得られた時点で表示したりします。

ブラウザアプリケーションでは、字幕やローカルの UI 更新に WebRTC データチャネルを使います。ガードレールの適用、軽量モデルによるチェック、先回りしたツール呼び出しなどのためにサーバーで文字起こしを処理する場合は、サイドバンド WebSocket を使ってイベントを受信し、同じ GPT-Live セッションを直接制御してください。

意味のある新しい情報が届いた時点で、それまでに蓄積したテキストを処理します。断片だけでは内容が不完全なことがあり、その後の発話によって依頼が変わる場合もあります。古くなった結果は破棄し、同じ操作を二重に実行しないよう後続の委譲処理と調整してください。影響を伴う操作の前には、通常どおり権限をチェックし、必要な確認を行います。

分かったことや指示は、更新内容に合った追加イベントを使って GPT-Live に返します。クライアント委譲とは別に開始した処理には delegation_id: null を指定してください。UI への変更の適用と、ツールの実行やキャンセルの管理はアプリケーションが行います。

両モードに共通する最適化

次のバックエンドの改善は、どちらの委譲モードでも有効です。

  • タスクに合ったモデルと推論強度の選択。 精度要件を満たす構成を比較します。低い推論強度でもタスクを確実に完了できる場合は、その設定を使います。
  • 簡潔な回答。 GPT-Live が会話を続けるのに必要な事実と状態を返します。長い説明は避け、結果を発話用に書き直すためだけにモデルを追加で呼び出さないようにします。
  • ツールの待ち時間と不要な呼び出しの削減。 入力が揃ったら許可済みの処理を開始し、結果が有効な間は再利用して、完了した照会を繰り返さないようにします。
  • 独立した処理の並行実行。 互いに独立した照会は同時に実行できます。操作の依存関係を守り、必要な確認を行ってください。parallel_tool_calls を使うとモデルは複数の呼び出しをリクエストできますが、カスタム関数のスケジューリングと実行は引き続きアプリケーションが行います。

Responses 全般の指針はレイテンシの最適化を、変わらない入力の再利用についてはプロンプトキャッシュを参照してください。

やり取り全体の検証

バックエンドが意図した操作を完了したことと、クライアントが期待どおりの音声を再生したことを確認します。たとえば、予約が成功した場合は、予約記録とその後に再生された音声の両方を確認してください。音声での回答が中断されてもバックエンドは処理を完了できるため、この 2 つの結果は別々にテストします。

GPT-Live の委譲 ID とあわせて、アプリケーションの操作ごとに固有の操作 ID を記録し、依頼が変更されるたびにタスクのリビジョンを記録します。これらの記録を使い、再接続や再試行の後に完了済みの処理を識別し、古くなった依頼の結果を破棄してください。

再現可能なテストには、音声エージェントの評価を活用してください。既存の Realtime のツール呼び出しループや複数の処理を連結したバックエンドを使っている場合は、GPT-Live への移行に従ってください。