OpenAI Responses APIとChat Completions APIの違い｜移行手順と見送る条件【2026年10月】

Responses APIとChat Completions APIの違いは、入出力の形（messages と choices から、型付きItemの input と output へ）、会話状態をAPI側に持たせられるかどうか、Web検索などの組み込みツールを1回のリクエストで回せるかどうかの3点です。Chat Completions APIは今も公式にサポートされています。一方で、GPT-6 AstraとGPT-6.1 SolはChat Completionsではツールを呼べません。最新モデルでエージェントを作るなら、移行は事実上避けられなくなりました。2026年10月20日時点の公式ドキュメントと、openai Python SDK 3.35.1での手元確認を基に、違い・移行手順・料金・移行を見送る条件を整理します。

まとめ

• エンドポイントは /v1/chat/completions から /v1/responses へ。choices[0].message.content は output_text、response_format は text.format に変わる。
• Chat Completions APIは「引き続きサポート（remains supported）」。終わったのはAssistants APIで、2026年8月26日にsunset済み（現在は利用不可）。
• GPT-6 AstraとGPT-6.1 Solのツール呼び出しはResponses API専用。GPT-5.4以降はChat Completionsでツールを使うと reasoning_effort が none に限られる。
• 会話状態は previous_response_id／Itemの手動再送／Conversations APIの3通り。previous_response_id は前回の instructions を引き継がず、過去分の入力トークンも課金される。
• 移行で安くなるとは限らない。組み込みツールは呼び出し単位の別課金で、GPT-5.6以降はキャッシュ書き込みが通常入力の1.25倍になる。

Responses APIの基本｜エンドポイントと最小コード

/v1/responses へのリクエスト

リクエスト先は https://api.openai.com/v1/responses、認証はChat Completionsと同じAPIキーのBearerトークンです。既存の OPENAI_API_KEY をそのまま使えます。変わるのはパスとボディの構造です。

curl https://api.openai.com/v1/responses \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-6.1-sol",
    "instructions": "日本語で、事実だけを簡潔に答える。",
    "input": "社内規程の要約手順を3行で説明して"
  }'

Pythonの最小コードと output_text

Python SDKでは client.chat.completions.create() が client.responses.create() になります。system ロールに入れていた指示は instructions へ移します。テキストだけ欲しいときは output_text を読みます。

from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-6.1-sol",
    instructions="日本語で、事実だけを簡潔に答える。",
    input="Responses APIのエンドポイントは?",
)

print(response.output_text)

output_text はSDKのヘルパーで、output 配列のうちメッセージItemのテキストだけを連結します。SDKのHTTP層をモックに差し替えて確かめたところ（実APIは呼んでいません）、output が reasoning と message の2件で、メッセージに「前半。」「後半。」の2パートがある応答では、output_text は '前半。後半。' を返し、推論Itemは含みませんでした。SDKの導入とクライアントの初期化はOpenAI Python SDKの使い方｜インストールから最新クライアント・Responses APIまでで扱っています。モデルIDは2026年10月時点の OpenAIのLatest modelガイドに載るGPT-6系（gpt-6-astra／gpt-6.1-sol／gpt-6-luna）から選んでいます。

Chat Completions APIとの違い｜構造・ツール・サポート方針

データ構造の差分｜messages/choices から input/output Items へ

Chat Completionsの入出力はMessageの配列です。Responses APIは入力を input、出力を型付きItemの配列 output として返します。Itemには message のほか reasoning、function_call、function_call_output などの種類があり、1回の応答に推論・ツール実行・本文が並びます。公式のMigrate to the Responses APIが挙げる対応は次のとおりです。

ストリーミングは、response.created・response.output_text.delta・response.completed・error などのイベントを type で分岐して受けます。関数呼び出しでは response.function_call_arguments.delta も流れるため、Chat Completions用のチャンク処理はそのままでは使えません。関数呼び出しの往復そのものはFunction Callingとは｜仕組みとOpenAI APIでの実装をコードで解説、JSON Schemaで出力を縛る仕組みはLLM構造化出力とは？JSON Schemaで出力形式を保証する仕組みと実装・見送り条件を解説で整理しています。

ツール呼び出しの差分｜GPT-6 AstraとGPT-6.1 SolはResponses専用

Chat Completionsでも、検索専用モデルの gpt-5-search-api と web_search_options を使えばWeb検索ができます。通常の関数呼び出しで外部検索APIを使う構成では、モデルが返した関数呼び出しを受けて検索APIを叩き、結果を role: "tool" のメッセージに詰めて再送するループをアプリ側で書きます。Responses APIでは tools=[{"type": "web_search"}] と宣言すれば、検索の実行と取り込みが1回のリクエスト内で完結します。file_search、code_interpreter、リモートMCP、画像生成も同じ tools に並べられます。

2026年の移行判断で一番効くのは、モデル側の制約です。移行ガイドは「GPT-5.4以降、Chat Completionsは reasoning_effort が none 以外のときツール呼び出しに対応しない」と明記しています。さらにLatest modelガイドは、GPT-6.1 Solについて「ツール呼び出しはResponses APIを使う。Chat Completionsはツールなしのリクエストに対応」と書き、GPT-6 AstraとGPT-6.1 Solは none の推論レベル自体を持ちません。つまりこの2モデルでは、Chat Completionsのままツールを使う道がありません。推論を切れる gpt-6-sol・gpt-6-luna なら none でChat Completionsのツール呼び出しを残せますが、推論込みの性能は捨てることになります。GPT-6 Solと6.1 Solの差はGPT-6 Solとは？6.1 Solの変更点とLuna・Astraの使い分け【2026年10月】で比べています。

文法で出力を縛るカスタムツールは、Chat Completionsでは custom.format.grammar と1段深い位置に書くなど、ツール定義の形も両APIで異なります（GPT-5のCFG Function Callingとは｜Larkと正規表現で出力を制約するカスタムツールの実装【2026年10月】）。

サポート方針の差分｜Assistants APIは2026年8月26日に終了済み

移行ガイドは冒頭で「Chat Completionsのサポートは続くが、新規プロジェクトにはResponsesを推奨する」と書き、段階移行のチェックリストでも「Chat Completionsはサポートが続くので、ユーザーフローを1つずつ移せる」としています。「Chat Completionsが廃止される」という説明は、現時点の公式記述と合いません。

終わったのはAssistants APIです。Deprecationsページによると、2025年8月26日に廃止が告知され、移行先はResponses APIとConversations APIでした。Assistants migration guideには「2026年8月26日に正式にsunsetし、現在は利用できない」とあります。ガイドの対応表は次のとおりです。

注意点が1つあります。移行ガイドはAssistantの受け皿として再利用プロンプト（Prompts）を挙げていますが、Deprecationsページでは2026年6月3日に再利用プロンプトの非推奨が告知され、v1/prompts APIは2026年11月30日に停止予定です。今から移すなら、モデル・ツール・指示はアプリのコード側に持たせ、instructions と tools で毎回渡す形にしておくほうが二度手間になりません。Assistants APIの機能と終了までの経緯はOpenAI Assistants APIとは｜使い方・料金と2026年8月終了・Responses API移行にまとめています。

移行時の引数・会話状態・関数定義の差｜SDK 3.35.1のモック検証と公式仕様

openai Python SDK 3.35.1のHTTP層を httpx2.MockTransport に差し替え、実APIを呼ばずに送信ボディと引数の扱いを確かめました。Chat Completionsの引数を残したまま responses.create() に渡すと、次のように通信前に落ちます。

['n'] -> TypeError: Responses.create() got an unexpected keyword argument 'n'
['response_format'] -> TypeError: Responses.create() got an unexpected keyword argument 'response_format'
['messages'] -> TypeError: Responses.create() got an unexpected keyword argument 'messages'

この3つはPythonなら実行時に気づけます。以下では、nに依存する処理の移行、instructionsの引き継ぎ、関数定義とstrictの既定を詳しく説明します。

1. n で複数候補を取っていた処理。Responses APIには n がなく、1回のリクエストで返る生成は1つです。候補を並べて選ばせるUIは、リクエストを分けて並列に投げる形へ作り直します。

2. previous_response_id は instructions を引き継がない。移行ガイドは「previous_response_id は前回のトップレベルの instructions を持ち越さないので、毎回送り直す」と書いています。モックで2回目の送信ボディを見ると、SDKも自動では足しません。

/v1/responses {"model": "gpt-6.1-sol", "input": "1文目", "instructions": "日本語で答える。"}
/v1/responses {"model": "gpt-6.1-sol", "input": "2文目", "previous_response_id": "resp_mock1"}

1回目だけに口調や禁止事項を書き、2回目以降で指示が効かなくなったように見える症状は、この仕様で説明がつきます。

3. 関数定義の入れ子と strict の既定。Chat Completionsは {"type": "function", "function": {"name": ...}} と function の中に定義を置き、strict を省略すると非strictです。Responsesは name・parameters を直下に置き、省略時はstrictを試みます。スキーマがstrictに合わない場合は非strictに落ち、解決後のツールに strict: false が付いて返ります。旧来の緩いスキーマを持ち込むと、必須項目の扱いが変わる可能性があります。

# Chat Completions
{"type": "function", "function": {"name": "get_weather", "parameters": {...}}}

# Responses
{"type": "function", "name": "get_weather", "parameters": {...}}

ほかに公式が「よくある移行エラー」として挙げるのは、output の全要素をメッセージとして扱う、手動で履歴を渡すときに推論Itemや関数呼び出しItemを落とす、関数の結果を call_id なしで返す、の3つです。

会話状態の3つの持ち方｜previous_response_id・手動再送・Conversations API

previous_response_id｜レスポンスIDによる文脈の引き継ぎ

直前のレスポンスIDを渡すと、その時点までの文脈が引き継がれます。アプリは履歴配列を持たずに済みます。ただしConversation stateガイドは「previous_response_id を使っても、チェーン内の過去の入力トークンはすべて入力トークンとして課金される」と明記しています。

INSTRUCTIONS = "日本語で答える。金額は税込と税抜を併記する。"

first = client.responses.create(
    model="gpt-6.1-sol",
    instructions=INSTRUCTIONS,
    input="請求書の明細は税抜1,000円と税抜2,000円、消費税率はともに10%です。税込合計はいくら?",
)

second = client.responses.create(
    model="gpt-6.1-sol",
    instructions=INSTRUCTIONS,      # 引き継がれないので毎回渡す
    previous_response_id=first.id,
    input="では税抜だといくら?",
)

遅延にも差があります。OpenAIの開発者フォーラムでは2025年9月、previous_response_id を使うとChat Completionsより応答が遅いという報告に対し、OpenAIのAPIエンジニアリングチームの担当者が「最速の遅延が必要なら store: false を使い、Chat Completionsと同様に全Itemを往復させる。そうすればデータベース参照を飛ばせる」と回答しています（Stateful Responses API Much Slower Than Chat Completions）。ツール呼び出しが多い処理には、接続を張ったまま差分だけ送るWebSocket modeもあり、公式は20回以上ツールを呼ぶ処理でエンドツーエンドが最大約40%速くなった例を挙げています。

Itemの手動再送｜履歴と入力トークン量の管理

前回の output を次の input に足して送る方式です。どのターンを残し、どこを要約に置き換えるかを自分で決められます。推論モデルでは推論Itemも含めて output を丸ごと積むのが条件で、Responses APIは暗号化された推論Itemを既定で返します。履歴の削り方はコンテキストエンジニアリングとは？プロンプトエンジニアリングとの違いと4つの実装手法の考え方がそのまま使えます。

history = [{"role": "user", "content": "請求書の明細は税抜1,000円と税抜2,000円、消費税率はともに10%です。税込合計はいくら?"}]

r1 = client.responses.create(
    model="gpt-6.1-sol",
    input=history,
    store=False,                 # Responseの保存を無効化（不正利用監視ログ等は別扱い）
)
history += r1.output             # 推論Itemを含めて全部積む
history.append({"role": "user", "content": "では税抜だといくら?"})

r2 = client.responses.create(model="gpt-6.1-sol", input=history, store=False)

Conversations API｜Assistants APIのThreadの受け皿

会話オブジェクトを作り、conversation パラメータに渡すと、そのIDに履歴が積まれます。セッションをまたぐ会話や、AssistantsのThreadから移す場合はこちらです。

conversation = client.conversations.create()

response = client.responses.create(
    model="gpt-6.1-sol",
    input=[{"role": "user", "content": "次の議事録を要約して：新機能の公開日は11月1日。担当は田中。公開前に佐藤が動作確認する。"}],
    conversation=conversation.id,
)

保存期間の違い｜Responseは30日・Conversationは期限なし

Responseオブジェクトは既定で30日保存され、store=False で止められます。一方、Conversationオブジェクトとその中のItemには30日のTTLがかかりません。会話に紐づけたレスポンスのItemも期限なしで残ります。データ保持の規程が「30日で消える」ことを前提にしているなら、Conversations APIは別扱いで審査が要ります。ゼロデータ保持（ZDR）の組織では store: false が自動で強制され、送り返した暗号化推論はメモリ上で復号して使われた後に破棄されます。ZDRで残るデータとステートレス実装の書き方はOpenAI ZDRとは：ゼロデータ保持で残るデータとPSPの設定手順で扱っています。

料金｜ツール課金とキャッシュの読み方

組み込みツールの単価

組み込みツールの課金単位は種類によって異なります。Web検索・File searchには呼び出し料金、File searchには保存料金、Hosted Shell・Code Interpreterにはコンテナの利用料金があり、モデルのトークン料金と合わせて計算します。下表はPricingページ（2026年10月20日時点）の値です。

コンピュータ操作は、以前の専用モデル computer-use-preview が2026年7月23日に停止しました（Deprecationsページ・代替は gpt-5.6-terra）。現在のComputer useガイドのサンプルは gpt-6.1-sol と gpt-6-astra で書かれ、GPT-6 Astraにはスクリプトを書かせて実行する方式を推奨し、computer ツールは代替として残しています。ベクトルストア検索の料金と対応形式はOpenAI File Searchとは｜Responses APIのベクトルストア検索・料金・対応形式で扱っています。

モデル単価とキャッシュ｜書き込みは1.25倍

100万トークンあたりの標準料金は、gpt-6-astra が入力$10.00／出力$50.00、gpt-6.1-sol が$2.00／$10.00、gpt-6-luna が$0.10／$0.50です（入力27.2万トークン以下の短コンテキスト）。

移行ガイドは、社内テストでキャッシュ利用率がChat Completions比で40〜80%改善したと書いています。推論モデルでSWE-benchが3%上がったという値も同じく社内評価で、どちらも第三者の検証値ではありません。キャッシュの計算は2026年に変わりました。Prompt cachingガイドによると、GPT-5.6以降はキャッシュ書き込みが通常入力の1.25倍、読み出しが0.1倍（GPT-6.1 Solは0.05倍）です。キャッシュ対象になる接頭辞は1,024トークン以上で、寿命は最後の書き込みか再利用から少なくとも30分です。読み出し料金が0.1倍の場合、通常入力1回分の費用を基準にすると、同じ接頭辞を1回書いて1回読む合計は1.35倍（キャッシュなしの2回分は2倍）、10回のリクエストで1回書いて9回読むと2.15倍（キャッシュなしは10倍）になります。読み出しが0.05倍のGPT-6.1 Solで同じ計算をすると、1.30倍と1.70倍です。キャッシュ対象の接頭辞を書き込んだ後に再利用しない場合、その部分には通常入力の1.25倍の料金がかかります。これはモデルのキャッシュ料金であり、Responses APIへの移行だけで発生する追加料金ではありません。

移行すべき条件と見送る条件

移行が必要・有利な3条件｜最新モデル＋ツール・組み込みツール・長いマルチターン

GPT-6 AstraかGPT-6.1 Solでツールを呼ぶなら、移行は必須です。Web検索やファイル検索をアプリ側のループで回しているエージェントも、Responsesに寄せるとループのコードが消えます。推論モデルで長いマルチターンを回す処理は、推論Itemの引き継ぎによる品質改善とキャッシュ再利用を評価する候補です。自社の評価データで正答率・入力費用・遅延を比較し、移行効果を判断します。移すときは、テキスト生成の1フローから始め、遅延・トークン量・エラー率を比べながら広げるのが公式チェックリストの順序です。長時間・多段階の処理で、ツール呼び出しのループ自体をOpenAIに任せたい場合は、Agents APIという選択肢もあります（OpenAI Agents APIとは？セッション実装・料金とSDKとの違い【2026年10月】）。

見送ってよい4条件｜互換サーバ依存・単発処理・n依存・自社DB完結

OpenAI以外のモデルも同じコードで呼んでいる場合。OpenAI互換を名乗るサーバの多くは /v1/responses を実装し始めていますが、範囲は限定的です。たとえばOllamaは /v1/responses をv0.13.3で追加したものの、OpenAI互換のドキュメントは「ステートレス版のみ対応（previous_response_id と conversation は非対応）」と明記しています。状態管理を使わない書き方に限れば共通化できますが、プロバイダを差し替えられる設計を最優先するなら、Chat Completionsに据え置くほうが確実です。

1往復で終わる要約・分類・抽出。状態管理も組み込みツールも不要で、現在の実装が品質・遅延・費用の要件を満たしているなら、移行の優先度は低くできます。単発処理でも共通の指示や入力形式を繰り返す場合はキャッシュが効くため、会話の往復数だけでは判断できません。ただしGPT-6.1 Solで推論させたまま関数を呼ぶ処理は、単発でもResponsesが必要です。

n で候補を並べるのが仕様の中心になっている場合。Responsesでは候補ごとにリクエストを分けることになり、呼び出し回数と実装が増えます。

会話ログを自社DBで正規化して持っている場合。Responseは既定で30日保存され、Conversationは期限なしで残ります。監査上の理由で外部保存を避ける場合は、会話状態の保存と不正利用監視ログの保持を分けて確認する必要があります。Data controlsのページによると、不正利用監視ログは /v1/responses と /v1/chat/completions のどちらでも既定で最長30日保持され、除外するにはZero Data RetentionかModified Abuse Monitoringの承認が要ります。store=False だけでは外部保存を全面的には避けられません。Responsesを使うとしても store=False と手動再送に倒し、Conversations APIは使わない構成が素直です。既存システムとAPIの間に状態をどこで持たせるかの設計から見直す場合は、API開発・システム連携の支援でも相談を受けています。

よくある質問

Chat Completions APIは廃止されますか？

2026年10月20日時点で廃止は告知されておらず、公式は「サポートは続く」としています。ただしGPT-6 AstraとGPT-6.1 Solでツールを呼ぶ場合はResponses APIが必要です。

Assistants APIはまだ使えますか？

使えません。2026年8月26日にsunsetし、移行先はResponses APIとConversations APIです。受け皿として挙げられた再利用プロンプト（v1/prompts）も2026年11月30日に停止予定です。

Responses APIのシステムプロンプトはどこに書きますか？

instructions パラメータです。previous_response_id でつないだ2回目以降には引き継がれないので、毎回渡します。既存の会話ログを保ったまま移すなら、input にロール付きのItemとして渡す方法もあります。

previous_response_id を使うと入力トークンの課金は減りますか？

減りません。チェーン内の過去の入力トークンはすべて課金されます。安くなるのはプロンプトキャッシュに当たった部分だけです。

Responses APIで構造化出力（JSON）を受け取るには？

response_format を text.format に移します。JSON Schema形式では、旧設定の json_schema 内にある name・schema・strict を text.format の直下へ移します。なお、response_format のまま渡すとopenai Python SDK 3.35.1では送信前に TypeError になります。

関連記事

• OpenAI Python SDKの使い方｜インストールから最新クライアント・Responses APIまで
• Function Callingとは｜仕組みとOpenAI APIでの実装をコードで解説
• OpenAI Assistants APIとは｜使い方・料金と2026年8月終了・Responses API移行
• OpenAI File Searchとは｜Responses APIのベクトルストア検索・料金・対応形式
• GPT-6 Solとは？6.1 Solの変更点とLuna・Astraの使い分け【2026年10月】