GPT-Live の委任とツール

Responses 委譲の設定

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

1
2
3
4
5
6
7
8
9
10export const session = {
  model: "gpt-live-1",
  delegation: {
    type: "responses",
    responses: {
      model: "gpt-5.6-terra",
      instructions: "[Your backend prompt]",
    },
  },
};

1
2
3
4
5
6
7
8
9
10
11
12from openai.types.live.session_config_param import SessionConfigParam

session: SessionConfigParam = {
    "model": "gpt-live-1",
    "delegation": {
        "type": "responses",
        "responses": {
            "model": "gpt-5.6-terra",
            "instructions": "[Your backend prompt]",
        },
    },
}

まずは GPT-5.6 Terra を使うか、コストを重視するワークロードには GPT-5.6 Luna をお試しください。バックエンドモデルを選ぶ前に、実際のタスクで回答の品質とレイテンシーを比較してください。

サポートされているツールを delegation.responses.tools に登録します。バックエンドが使用できるツールは delegation.responses.tool_choice で制御します。"auto" はバックエンドに選択を任せ、"required" はツール呼び出しを必須にし、"none" はツール呼び出しを禁止します。関数名を指定して選択することもできます。独立した検索を同時に実行できるようにするには delegation.responses.parallel_tool_calls を true に設定し、呼び出しを順番に実行する必要がある場合は false に設定します。カスタム関数の実行と、依存関係や承認要件の適用は、引き続きアプリケーションが担います。これらの設定は、ライブモデルに委譲を強制するものではありません。

Responses の設定では、作成時にバックエンドの model を指定する必要があります。tools では、function の定義と web_search のエントリがサポートされています。また、max_output_tokens（設定する場合は 16 以上）、service_tier、および選択したバックエンドモデルがサポートする reasoning と text の設定も利用できます。調整できる設定については、バックエンドのレイテンシーの削減を参照してください。

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

会話の変化に応じて、session.delegation.responses の変更内容を含む session.update を送信すると、新しい Live セッションを開始せずに、バックエンドモデル、指示、利用可能なツール、tool_choice、その他のサポートされている設定を更新できます。省略した設定は、それまでの値を保持します。delegation を null に設定するとクライアントモードが選択されますが、実行中の Responses セッションをリセットすることはできません。モードを切り替えようとすると、immutable_field_update エラーで失敗します。

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

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

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 エンベロープ内に格納されて届きます。

1234567891011121314{
  "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": []
  }
}

envelope.event.type に応じて処理を振り分け、外側の delegation_id を保持してください。トップレベルの response.* の値をすべて、ラップされていない Responses イベントとして扱わないでください。ネストされた Responses ライフサイクルイベントが追加されても対応できるようにしてください。

Live の発話と委譲された処理は、それぞれ独立して進行します。バックエンドのレスポンスが完了しても、それだけでユーザーが回答を聞いたことにはなりません。やり取りのうち発話された部分には、Live の出力文字起こしと音声を使用してください。

クライアントで実行する関数呼び出しの完了

ネストされた 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 アイテムとして追加します。

1
2
3
4
5
6
7
8
9
10
11export 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"}',
    },
  });
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17from openai.resources.live.live import AsyncLiveConnection
from openai.resources.live.sideband import AsyncSidebandConnection
from openai.types.responses.response_input_item_param import ResponseInputItemParam


async def send_update(
    connection: AsyncLiveConnection | AsyncSidebandConnection,
) -> None:
    item: ResponseInputItemParam = {
        "type": "function_call_output",
        "call_id": "call_123",
        "output": '{"status":"confirmed","order_id":"order_123"}',
    }
    await connection.response.item.create(
        event_id="tool_result_1",
        item=item,
    )

その後、明示的にレスポンスを続行します。

1
2
3
4
5
6export function sendUpdate(connection) {
  connection.send({
    type: "response.create",
    event_id: "continue_1",
  });
}

1
2
3
4
5
6
7
8
9
10from openai.resources.live.live import AsyncLiveConnection
from openai.resources.live.sideband import AsyncSidebandConnection


async def send_update(
    connection: AsyncLiveConnection | AsyncSidebandConnection,
) -> None:
    await connection.response.create(
        event_id="continue_1",
    )

続行する前に、保留中のツール呼び出しに必要な結果をすべて送信してください。関数の結果を追加しても、レスポンスは自動的には続行されません。response.item.create には単独の成功確認通知はありません。エラーと、その後に届くネストされたレスポンスのライフサイクルイベントの処理を続けてください。

response.create は、セッションで設定されたバックエンドを使用して、Responses に委譲する処理を作成または続行するための Live コマンドです。このイベントには、Responses API の作成リクエストボディ、バックエンドモデルの上書き指定、delegation_id を付けないでください。どちらのコマンドも Responses 委譲が必要です。

クライアント委譲の設定

Live セッションの作成時に delegation を設定します。

1
2
3
4
5
6export const session = {
  model: "gpt-live-1",
  delegation: {
    type: "client",
  },
};

1
2
3from openai.types.live.session_config_param import SessionConfigParam

session: SessionConfigParam = {"model": "gpt-live-1", "delegation": {"type": "client"}}

これにより、セッションでクライアント委譲が選択されます。バックエンドは別途設定してください。モデルまたはサービス、指示、ツール、処理の振り分け方法はアプリケーションで選択します。そのバックエンドに Responses API を使用する場合は、アプリケーションが送信する Responses リクエストでモデルとツールを設定します。Live セッションは、これらのバックエンドツールを設定したり実行したりしません。

GPT-Live が支援を求めると、アプリケーションは会話とアプリケーションのコンテキストからバックエンドリクエストを構築し、処理を実行して、どの結果を返すかを判断します。ツールを実行する前に、権限と必要な確認を必ず適用してください。バックエンドリクエストごとに関連するコンテキストを提供できるよう、会話履歴全体をアプリケーションで保持してください。

アプリケーションでの会話コンテキストの保持

クライアント委譲では、 文字起こしの収集と現在のタスク状態の保持を自分で行ってください。

session.input_transcript.delta と session.output_transcript.delta をリッスンしてください。これらのイベントには、delta 内の文字起こしテキストと、start_ms および end_ms のタイムスタンプが含まれます。「はい」のような短い返答や、「金曜日ではなく木曜日です」のような訂正、以前に伝えられた詳細を理解できるだけの履歴を保持してください。文字起こしの断片はユーザーの発話ターン全体を表すものではなく、文字起こしに誤りが含まれる場合もあります。

別のイベントである session.delegation.created には、offset_ms タイムスタンプと、delegation.id や delegation.target などの委譲メタデータが含まれます。ユーザーの発話やタスクのテキストは 含まれません 。文字起こしイベントとアプリケーションの状態を使って、ユーザーの意図を把握してください。更新内容をそのリクエストと対応付けられるよう、delegation.id を保存してください。

長い記録とツールの出力全体はバックエンドで保持してください。セッションを置き換える場合は、アプリケーションから関連するコンテキストを復元し、処理を繰り返す前に、どの操作がすでに実行済みかを確認してください。

クライアント委譲の受信

session.delegation.created で委譲を識別します。

12345678910{
  "type": "session.delegation.created",
  "event_id": "event_delegation",
  "offset_ms": 1000,
  "delegation": {
    "id": "item_9tA2bF3h7K9m2P5q8R1s4",
    "type": "delegation",
    "target": "client"
  }
}

event.delegation.id を読み取ります。委譲オブジェクトに含まれるのはメタデータであり、タスクのテキストではありません。委譲された作業を処理する独自のハンドラーに必要な文字起こしとアプリケーションのコンテキストを保持してください。現在の ID には、この例のように item_ プレフィックスが付いています。ただし、ID 全体を内部構造に立ち入らない不透明な値として扱い、自分で組み立てたり解析したりせず、そのまま返してください。

その ID を使って結果を返します。

1
2
3
4
5
6
7
8export function sendUpdate(connection) {
  connection.send({
    type: "session.commentary.append",
    event_id: "result_123",
    delegation_id: "item_9tA2bF3h7K9m2P5q8R1s4",
    content: "The order shipped today and should arrive tomorrow.",
  });
}

1
2
3
4
5
6
7
8
9
10
11
12from openai.resources.live.live import AsyncLiveConnection
from openai.resources.live.sideband import AsyncSidebandConnection


async def send_update(
    connection: AsyncLiveConnection | AsyncSidebandConnection,
) -> None:
    await connection.session.commentary.append(
        event_id="result_123",
        delegation_id="item_9tA2bF3h7K9m2P5q8R1s4",
        content="The order shipped today and should arrive tomorrow.",
    )

追加時に読み上げずにモデルの内部推論へ情報を加えるには、session.thinking.append を使います。モデルに読み上げさせたい結果には session.commentary.append を使います。モデルは、追加されたテキストを言い換えて伝えるように学習されています。追加する内容はすべて通常の文字列で、delegation_id が必須です。値が null の場合も省略できません。null 以外の ID は、既知のクライアント委譲を指す必要があります。

結果を繰り返し追加することで、同じクライアント委譲を継続できます。追加の確認応答は、コンテキストの注入が完了したと推定される時点の後に届きます。モデルが結果を取り込んだことや読み上げたこと、外部の操作が成功したことを証明するものではありません。

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16export 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.",
        },
      ],
    },
  });
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17from openai.resources.live.live import AsyncLiveConnection
from openai.resources.live.sideband import AsyncSidebandConnection
from openai.types.responses.response_input_item_param import ResponseInputItemParam


async def send_update(
    connection: AsyncLiveConnection | AsyncSidebandConnection,
) -> None:
    item: ResponseInputItemParam = {
        "type": "message",
        "role": "user",
        "content": [{"type": "input_text", "text": "My order number is A0042."}],
    }
    await connection.response.item.create(
        event_id="typed_order_number",
        item=item,
    )

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

クライアント委任では、入力された値を、会話を処理するバックエンドに直接送信します。その値が実行中のタスクを修正するものであれば、同じ処理を再び開始せず、そのタスクを更新します。session.thinking.append を使って事実を短くまとめた内容をライブセッションにも反映できます。ユーザーに音声で伝えるべき結果には session.commentary.append を使用します。

Responses 委任では、視覚認識に対応したバックエンドモデルを設定します。response.item.create で、Responses がサポートする画像入力アイテムをキューに追加し、response.create を送信してバックエンドの処理を実行または再開します。継続する前に、返却待ちの必要な関数の結果をすべて返します。Responses 委任の処理を参照してください。

クライアント委任では、委任されたリクエストを処理するバックエンドに、視覚入力を関連する会話やアプリケーションの状態とともに送信します。クライアントの結果返却フローを使って、得られた情報を簡潔に返します。

Responses 委任

Live は Responses への永続的な WebSocket 接続を管理し、接続と事前に決まっているリクエスト設定を準備して、利用可能な場合は以前のレスポンスの状態を再利用します。ホスト型バックエンドでは、これらの手順を自分で実装する必要はありません。再利用は、アクティブな接続と互換性のある状態に依存し、キャッシュヒットや特定のレイテンシを保証するものではありません。

delegation.responses でバックエンドを調整します。

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

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

クライアント委任

委任の受信から結果の返却までの処理経路は、アプリケーションが管理します。音声セッションの実行中に、その経路を準備します。

• バックエンド接続を再利用します。 委任のたびに接続し直すことがないよう、API クライアントと接続プールを維持します。Responses を繰り返し呼び出す場合は、永続的な Responses WebSocket 接続を検討してください。
• 事前に決まっている設定を準備します。 最初のリクエストで必要になる前に、指示、ツール、接続を初期化します。Responses の WebSocket モードでは、生成前に既知のリクエスト状態をウォームアップすることもできます。セットアップのガイドに従ってください。
• 役立つ結果をストリーミングします。 session.commentary.append で、検証済みの結果を意味のまとまった単位で返します。音声に出さずに進捗を伝えるには session.thinking.append を使用します。クライアント委任 ID を維持し、1 回の追加につき 500 トークンの上限を守ります。非公開の推論はバックエンドにとどめ、成功を伝える前にアクションの実行結果を確認します。
• 再利用できる入力を維持します。 指示、ツールの定義と順序、履歴の先頭から変更されていない部分を保持します。バックエンドがキャッシュと継続に対応している場合は、再利用できる内容の後に新しい情報を追加します。
• 不要なバッファリングを避けます。 役立つ結果が準備できたら、すぐに転送します。バッファリングは、出力を分類して意味のまとまった単位にするために必要な範囲にとどめます。処理段階を示す構造化メタデータの使用を推奨します。テキストのプレフィックスで進捗と結果を区別する場合は、プレフィックス全体を受信してからテキストを転送します。

この処理経路を Responses 委任と比較する際は、最初の役立つ音声回答が得られるまでの時間を測定します。