--- title: "OpenAI Responses APIとChat Completions APIの違い｜移行手順と見送る条件【2026年10月】" url: "https://www.issoh.co.jp/tech/details/5961/" published: 2025-03-21 updated: 2026-10-22 categories: ["ChatGPT"] publisher: "株式会社一創" --- # 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まで](/tech/details/8636/)で扱っています。モデルIDは2026年10月時点の [OpenAIのLatest modelガイド](https://developers.openai.com/api/docs/guides/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](https://developers.openai.com/api/docs/guides/migrate-to-responses)が挙げる対応は次のとおりです。 | 観点 | Chat Completions API | Responses API | | ---------- | ------------------------ | ------------------------------------------ | | エンドポイント | /v1/chat/completions | /v1/responses | | 入力 | messages\[\] | input（文字列かItem配列） | | 出力 | choices\[0\].message | output（型付きItem）／output\_text | | システム指示 | role: system / developer | instructions | | 構造化出力 | response\_format | text.format | | 複数候補 n | あり | なし（別リクエストにする） | | 関数定義 | function の中に name 等 | name 等を直下に置く | | strict 省略時 | 非strict | strictを試み、不可なら非strict | | ストリーミング | delta の差分チャンク | 型付きイベント（SSE） | | 会話状態 | アプリが全履歴を再送 | previous\_response\_id ／ Conversations API | | 保存の既定 | 新規アカウントは保存 | 保存（30日） | ストリーミングは、`response.created`・`response.output_text.delta`・`response.completed`・`error` などのイベントを `type` で分岐して受けます。関数呼び出しでは `response.function_call_arguments.delta` も流れるため、Chat Completions用のチャンク処理はそのままでは使えません。関数呼び出しの往復そのものは[Function Callingとは｜仕組みとOpenAI APIでの実装をコードで解説](/tech/details/4631/)、JSON Schemaで出力を縛る仕組みは[LLM構造化出力とは？JSON Schemaで出力形式を保証する仕組みと実装・見送り条件を解説](/tech/details/16322/)で整理しています。 ### ツール呼び出しの差分｜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月】](/tech/details/18251/)で比べています。 文法で出力を縛るカスタムツールは、Chat Completionsでは `custom.format.grammar` と1段深い位置に書くなど、ツール定義の形も両APIで異なります（[GPT-5のCFG Function Callingとは｜Larkと正規表現で出力を制約するカスタムツールの実装【2026年10月】](/tech/details/8459/)）。 ### サポート方針の差分｜Assistants APIは2026年8月26日に終了済み 移行ガイドは冒頭で「Chat Completionsのサポートは続くが、新規プロジェクトにはResponsesを推奨する」と書き、段階移行のチェックリストでも「Chat Completionsはサポートが続くので、ユーザーフローを1つずつ移せる」としています。「Chat Completionsが廃止される」という説明は、現時点の公式記述と合いません。 終わったのは**Assistants API**です。[Deprecationsページ](https://developers.openai.com/api/docs/deprecations)によると、2025年8月26日に廃止が告知され、移行先はResponses APIとConversations APIでした。[Assistants migration guide](https://developers.openai.com/api/docs/assistants/migration)には「2026年8月26日に正式にsunsetし、現在は利用できない」とあります。ガイドの対応表は次のとおりです。 | Assistants API | 移行先 | 注意 | | -------------- | ------------- | -------------------------- | | Assistant | Prompts | v1/prompts は2026-11-30停止予定 | | Thread | Conversations | Itemの列で保持 | | Run | Responses | ツールループは明示管理 | | Run Step | Items | 型付きの出力 | 注意点が1つあります。移行ガイドはAssistantの受け皿として再利用プロンプト（Prompts）を挙げていますが、Deprecationsページでは2026年6月3日に再利用プロンプトの非推奨が告知され、`v1/prompts` APIは2026年11月30日に停止予定です。今から移すなら、モデル・ツール・指示はアプリのコード側に持たせ、`instructions` と `tools` で毎回渡す形にしておくほうが二度手間になりません。Assistants APIの機能と終了までの経緯は[OpenAI Assistants APIとは｜使い方・料金と2026年8月終了・Responses API移行](/tech/details/3461/)にまとめています。 ## 移行時の引数・会話状態・関数定義の差｜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ガイド](https://developers.openai.com/api/docs/guides/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](https://community.openai.com/t/stateful-responses-api-much-slower-than-chat-completions/1354518)）。ツール呼び出しが多い処理には、接続を張ったまま差分だけ送る[WebSocket mode](https://developers.openai.com/api/docs/guides/websocket-mode)もあり、公式は20回以上ツールを呼ぶ処理でエンドツーエンドが最大約40%速くなった例を挙げています。 ### Itemの手動再送｜履歴と入力トークン量の管理 前回の `output` を次の `input` に足して送る方式です。どのターンを残し、どこを要約に置き換えるかを自分で決められます。推論モデルでは推論Itemも含めて `output` を丸ごと積むのが条件で、Responses APIは暗号化された推論Itemを既定で返します。履歴の削り方は[コンテキストエンジニアリングとは？プロンプトエンジニアリングとの違いと4つの実装手法](/tech/details/11165/)の考え方がそのまま使えます。 ``` 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の設定手順](https://www.issoh.co.jp/tech/details/18734/)で扱っています。 ## 料金｜ツール課金とキャッシュの読み方 ### 組み込みツールの単価 組み込みツールの課金単位は種類によって異なります。Web検索・File searchには呼び出し料金、File searchには保存料金、Hosted Shell・Code Interpreterにはコンテナの利用料金があり、モデルのトークン料金と合わせて計算します。下表は[Pricingページ](https://developers.openai.com/api/docs/pricing)（2026年10月20日時点）の値です。 | ツール | 課金 | 補足 | | ----------------------------- | ----------------- | ------------------------ | | Web検索 | $10.00 / 1,000回 | 検索結果トークンはモデル単価 | | Web検索 preview（非推論モデル） | $25.00 / 1,000回 | 検索結果トークンは無料 | | File search | $2.50 / 1,000回 | 保存 $0.10 / GB / 日（1GB無料） | | Hosted Shell・Code Interpreter | $0.03〜$1.92 / 20分 | 1GB〜64GBのコンテナ | | コンピュータ操作 | トークン課金 | スクリーンショットは画像入力 | コンピュータ操作は、以前の専用モデル `computer-use-preview` が2026年7月23日に停止しました（Deprecationsページ・代替は `gpt-5.6-terra`）。現在の[Computer useガイド](https://developers.openai.com/api/docs/guides/tools-computer-use)のサンプルは `gpt-6.1-sol` と `gpt-6-astra` で書かれ、GPT-6 Astraにはスクリプトを書かせて実行する方式を推奨し、`computer` ツールは代替として残しています。ベクトルストア検索の料金と対応形式は[OpenAI File Searchとは｜Responses APIのベクトルストア検索・料金・対応形式](/tech/details/3555/)で扱っています。 ### モデル単価とキャッシュ｜書き込みは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ガイド](https://developers.openai.com/api/docs/guides/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月】](https://www.issoh.co.jp/tech/details/18736/)）。 ### 見送ってよい4条件｜互換サーバ依存・単発処理・n依存・自社DB完結 **OpenAI以外のモデルも同じコードで呼んでいる場合。**OpenAI互換を名乗るサーバの多くは `/v1/responses` を実装し始めていますが、範囲は限定的です。たとえばOllamaは `/v1/responses` をv0.13.3で追加したものの、[OpenAI互換のドキュメント](https://github.com/ollama/ollama/blob/main/docs/api/openai-compatibility.mdx)は「ステートレス版のみ対応（`previous_response_id` と `conversation` は非対応）」と明記しています。状態管理を使わない書き方に限れば共通化できますが、プロバイダを差し替えられる設計を最優先するなら、Chat Completionsに据え置くほうが確実です。 **1往復で終わる要約・分類・抽出。**状態管理も組み込みツールも不要で、現在の実装が品質・遅延・費用の要件を満たしているなら、移行の優先度は低くできます。単発処理でも共通の指示や入力形式を繰り返す場合はキャッシュが効くため、会話の往復数だけでは判断できません。ただしGPT-6.1 Solで推論させたまま関数を呼ぶ処理は、単発でもResponsesが必要です。 **n で候補を並べるのが仕様の中心になっている場合。**Responsesでは候補ごとにリクエストを分けることになり、呼び出し回数と実装が増えます。 **会話ログを自社DBで正規化して持っている場合。**Responseは既定で30日保存され、Conversationは期限なしで残ります。監査上の理由で外部保存を避ける場合は、会話状態の保存と不正利用監視ログの保持を分けて確認する必要があります。[Data controlsのページ](https://developers.openai.com/api/docs/guides/your-data)によると、不正利用監視ログは `/v1/responses` と `/v1/chat/completions` のどちらでも既定で最長30日保持され、除外するにはZero Data RetentionかModified Abuse Monitoringの承認が要ります。`store=False` だけでは外部保存を全面的には避けられません。Responsesを使うとしても `store=False` と手動再送に倒し、Conversations APIは使わない構成が素直です。既存システムとAPIの間に状態をどこで持たせるかの設計から見直す場合は、[API開発・システム連携の支援](/service/system/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まで](/tech/details/8636/) - [Function Callingとは｜仕組みとOpenAI APIでの実装をコードで解説](/tech/details/4631/) - [OpenAI Assistants APIとは｜使い方・料金と2026年8月終了・Responses API移行](/tech/details/3461/) - [OpenAI File Searchとは｜Responses APIのベクトルストア検索・料金・対応形式](/tech/details/3555/) - [GPT-6 Solとは？6.1 Solの変更点とLuna・Astraの使い分け【2026年10月】](/tech/details/18251/) --- 出典: [OpenAI Responses APIとChat Completions APIの違い｜移行手順と見送る条件【2026年10月】]()（株式会社一創）