エージェント向けResponses APIとChat Completionsの比較：コントラクトの選択

エージェントのワークロードにおいては、Responses APIをデフォルトとして選択するのが賢明です。このAPIは、previous_response_idによるサーバーサイドでの会話状態管理、単一のメッセージブロブではなく型定義された出力アイテム、そしてセマンティックなストリーミングイベントを提供します。これらの機能により、本来オーケストレーション層で管理すべき煩雑な処理を削減できます。Chat Completionsは、メッセージ履歴を完全に制御したい場合や、OpenAIのチャットメッセージ形式を中心に構築されたツールと統合する場合に依然として有効な選択肢ですが、マルチターンのツール呼び出しを行うエージェントにとっては、Responsesの方がより直接的に適合します。

両方のエンドポイントは、GPT-5.6およびGPT-5.5の現在のモデルリファレンスページに記載されており、Responsesの共通リクエスト/レスポンスコントラクトはResponses createリファレンスで指定されています。

主なポイント

• Chat Completionsは呼び出し元管理型です。リクエストのたびに完全なmessages配列を送信し、履歴を自身で再構築する必要があります。
• Responsesはサーバー支援型です。inputとオプションのinstructionsを送信し、履歴を再送する代わりにprevious_response_idを使用してターンを連結できます。
• ツール呼び出しの構造が異なります。Chat Completionsはchoices[0].message.tool_callsの下に呼び出しをネストしますが、Responsesはフラットなoutput配列内の型定義されたアイテムとして出力します。
• ツール結果の照合は、Chat Completionsではtool_call_idで行い、Responsesではfunction_call_outputアイテムのcall_idで行います。
• ストリーミングは、Chat Completionsではチャンクベースのデルタですが、Responsesでは名前付きのセマンティックイベントとなります。
• ホスト型ツール（ウェブ検索、コードインタープリター、ファイル検索など）のサポートは、どちらのAPIでもモデルに依存します。利用可能かどうかを事前にモデルのページで確認してください。

フィールドレベルの比較

項目	Chat Completions	Responses
エンドポイント	POST /v1/chat/completions	POST /v1/responses
主な入力	messages: []（呼び出しごとに全配列）	input（文字列またはアイテムの配列）
システム形式のガイダンス	messages[0].role = "system"	トップレベルのinstructionsフィールド
マルチターンの継続	呼び出し元がmessages履歴全体を再送	previous_response_idでサーバー側の前ターンを参照
出力形式	choices[0].message（単一のメッセージオブジェクト）	output: []（型定義されたアイテムの配列：メッセージ、function_callなど）
ツール呼び出しの場所	choices[0].message.tool_calls[]	output内のtype: "function_call"を持つアイテム
ツール結果の送信	role: "tool", tool_call_idを持つ新しいメッセージ	type: "function_call_output", call_idを持つアイテム
ストリーミング	chunk.choices[0].deltaフラグメント	名前付きイベント（response.output_text.delta, response.completedなど）

previous_response_id：実際の機能

Chat Completionsでは、会話のメモリ管理は完全に呼び出し側の責任です。すべてのリクエストに完全なメッセージ履歴を含める必要があり、サーバーは前ターンの概念を持ちません。一方、Responses APIはすべてのレスポンスオブジェクトにidを返します。アプリケーションがそのidを永続化し、次の呼び出しでprevious_response_idとして渡すと、サーバー側で前回の会話状態が再構築されます。現在のターンに必要な新しいinputと（オプションで）新しいinstructionsを送信するだけで済みます。これにより、状態管理がアプリケーション層からOpenAIのインフラストラクチャへと移行されます。これは、連続的なツール呼び出しを行うエージェントにとって、ホップごとに増大する履歴を再シリアル化して再送信する必要がなくなるため、非常に重要です。

トレードオフとして、アプリケーション側でターンの間にidを永続的な場所（セッションストアやデータベース行など）に保存しておく必要があります。APIは過去のレスポンスに対する無制限の保持や検索機能を提供するわけではなく、直前のレスポンスを継続ポイントとして参照できるようにするだけです。

現在のリクエスト例 (gpt-5.6)

Chat Completions: 履歴全体を管理する場合

{
  "model": "gpt-5.6",
  "messages": [
    { "role": "system", "content": "You are a support agent." },
    { "role": "user", "content": "Check order #4471 status." }
  ],
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "get_order_status",
        "parameters": { "type": "object", "properties": { "order_id": { "type": "string" } } }
      }
    }
  ]
}

Responses: instructionsとinputを含む最初のターン

{
  "model": "gpt-5.6",
  "instructions": "You are a support agent.",
  "input": "Check order #4471 status.",
  "tools": [
    {
      "type": "function",
      "name": "get_order_status",
      "parameters": { "type": "object", "properties": { "order_id": { "type": "string" } } }
    }
  ]
}

Responses: 履歴を再送しないフォローアップターン

{
  "model": "gpt-5.6",
  "previous_response_id": "resp_abc123",
  "input": "What about order #4472?"
}

関数呼び出しのライフサイクル

Chat Completions:

1. モデルがchoices[0].message.tool_callsを返します（各呼び出しにはidと関数名/引数が含まれます）。
2. ローカルで関数を実行します。
3. アシスタントメッセージ（tool_callsを含む）をmessages配列に追加し、続いて新しいメッセージ{ "role": "tool", "tool_call_id": "<id>", "content": "<result>" }を追加します。
4. 更新されたmessages配列全体を再送して継続します。

Responses:

1. output配列にtype: "function_call"を持つアイテムが含まれます（call_id、name、argumentsを含みます）。
2. ローカルで関数を実行します。
3. previous_response_idに前回のレスポンスのidを設定し、inputにtype: "function_call_output"、call_id、および結果を含む新しいリクエストを送信します。
4. サーバーが関数呼び出しのコンテキストを保持しているため、以前のターンを再送する必要はありません。

フラットな型付き出力アイテムと、ネストされた配列を持つ単一メッセージという構造の違いにより、Responsesではメッセージのオプションフィールドを掘り下げるのではなく、outputを反復処理してtypeで分岐させるだけでよいため、解析ロジックが簡素化される傾向があります。

意思決定チェックリスト

• ツール呼び出しを行うマルチターンエージェントを構築中ですか？ Responsesをデフォルトにしてください。previous_response_idにより履歴管理の手間が省けます。
• 履歴の内容を厳密に制御する必要がありますか（編集、カスタム要約、非標準メッセージの挿入など）？ Chat Completionsならmessagesを自分で組み立てるため、明示的な制御が可能です。
• 既存のChat Completions統合を移行しますか？ リファクタリングのコストと状態管理による節約効果を比較してください。短期間の単一ターン呼び出しでは、メリットは小さくなります。
• ホスト型ツール（検索、コードインタープリター、ファイルツール）に依存していますか？ モデルやエンドポイントによって利用可能性が異なるため、採用前に特定のモデルのページでサポートを確認してください。
• きめ細かなイベントセマンティクスでのストリーミングが必要ですか（例：デルタの形状を検査せずにテキストデルタとツール呼び出しデルタを区別するなど）？ Responsesの名前付きイベントは、Chat Completionsの汎用的なデルタチャンクよりも明示的です。
• チャットメッセージを中心に構築された既存のフレームワークやSDKを使用していますか？ プロジェクトの途中でコントラクトを切り替える前に、そのResponsesサポートの成熟度を確認してください。

マルチプロバイダーエージェントとコントラクトの変換

エージェントが単一のプロバイダーに留まることは稀です。コーディングエージェントは実装作業にClaude Sonnet 5やKimi K2.7 Codeを利用し、安価なドラフト作成にはDeepSeek V4 FlashやGemini 3.5 Flashにフォールバックし、コスト管理のためにGLM-5.2やQwen3.7 Plusを呼び出すといったことが考えられます。これらのプロバイダーがOpenAIのChat CompletionsやResponsesコントラクトをネイティブに公開しているとは限りません。

ここでルーティング層が重要になります。TokenLabのドキュメント（docs.tokenlab.sh）では、複数のモデルプロバイダーにアクセスするための単一のAPIサーフェスとキーについて説明しており、プロバイダーごとに個別のクライアント統合を記述する必要がなくなります。コントラクト互換性のためのヘッダーエイリアスに関するブログ記事では、あるコントラクト形式に合わせて書かれたコードが、ネイティブでは対応していないモデルに到達できるようにリクエストヘッダーをマッピングする方法を解説しています。複数のモデルファミリーを呼び出す必要があるチャットボットやエージェントを構築している場合、「1つのAPIキーでAIチャットボットを構築する」というガイドで、より具体的なセットアップ手順を確認できます。

TokenLabを通じてアクセス可能な現在の全モデルリスト（フロンティアモデル、コーディングモデル、低コストルーティングオプションを含む）については、モデルページを参照してください。モデルのラインナップはAPIコントラクトよりも頻繁に変更されるため、アーキテクチャを確定させる前に、現在の可用性やコントラクト固有の注意点を確認してください。

制限事項

この記事は、OpenAIの正確なフィールドレベルのAPIリファレンスを再掲するものではありません。詳細はバージョン管理されており、変更される可能性があるためです。上記の要求形状の例を、そのまま本番環境で使えるコードとして扱わないでください。また、すべてのプロバイダーのネイティブコントラクトを詳細に網羅しているわけではありません。Claude、Gemini、DeepSeek、GLMはそれぞれ独自のAPIリファレンスを公開しており、OpenAIのChat CompletionsやResponsesの形状と一致させる義務はありません。エージェントがツール呼び出しの順序、ストリーミングイベントの形式、またはバッチ処理の動作について保証を必要とする場合は、この記事ではなく、各プロバイダーの最新ドキュメントで詳細を確認してください。

FAQ

Responses APIはChat Completionsの代替ですか？ OpenAIのクイックスタートドキュメントでは、Responses APIがエージェント的なユースケースを含む新規開発の現在のパスとして位置付けられていますが、Chat Completionsも引き続きドキュメント化されたAPIサーフェスの一部です。Chat Completionsが非推奨、廃止、あるいはレガシーであるかどうかは、サポート状況が変更される可能性があるため、OpenAIの現在のドキュメントで直接確認してください。

Claude、Gemini、DeepSeekなどの他のプロバイダーも同じコントラクトを使用しますか？ ネイティブでは使用しません。各プロバイダーは独自のリクエストおよびレスポンス形式を定義しています。OpenAIモデルとClaude Sonnet 5やDeepSeek V4 Proのようなプロバイダー間でエージェントを実行する必要がある場合は、共通のコントラクトを前提とするのではなく、変換層を計画してください。

コントラクトを切り替えるとモデルの出力品質が変わりますか？ いいえ。コントラクトはリクエストとレスポンスの転送および構造であり、モデルそのものではありません。出力品質は、Chat CompletionsとResponses APIのどちらを使用したかではなく、どのモデルを呼び出したか（例：GPT-5.5 対 Claude Sonnet 5）によって決まります。

エージェントにどのコントラクトとどのモデルが適しているかを評価する場合は、TokenLabのドキュメント化されたエンドポイントに対して小さなテストビルドを行い、オーケストレーションのオーバーヘッドを直接比較することから始めてください。docs.tokenlab.shで開始し、自身のワークロードで比較を行ってください。