Responses APIとChat Completionsの違いと使い分け

OpenAIのAPIを使うとき、Responses APIとChat Completions APIのどちらを選ぶべきか迷う人は多い。結論から言うと、これから新しく作るならResponses APIを選ぶのが公式の推奨で、すでにChat Completionsで動いているコードは今すぐ止める必要はなく、機能ごとに少しずつ移せばよい。

主な違いは、入力と出力の形(messages配列とItemの配列)、会話状態の持ち方、ツール呼び出しの扱い、Structured Outputsの指定場所、ストリーミングのイベント形式の5つだ。さらに、OpenAIの最新モデルガイドには、GPT-6 AstraとGPT-6.1 SolでツールをAPIから使うにはResponses APIが必要だという記述がある(2026年10月14日確認、詳しくは後述)。

この記事では、OpenAI公式ドキュメントのMigrate to the Responses API、Conversation state、Deprecations、最新モデルガイド、モデル一覧の各ページを実際に開いて確認できた内容だけを根拠に、機能差・書き方の違い・移行手順・判断の目安を整理する。確認できなかった点は断定せず、そのように明記している。

Responses APIとChat Completionsの違いを先に一言で

Responses APIは、OpenAIがChat Completionsを発展させる形で用意した新しいAPIの基本形で、組み込みツールの利用や会話状態の保持を前提にしている。Chat Completionsは引き続きサポートされるが、公式は新規プロジェクトにはResponsesを推奨している。

公式の移行ガイド(Migrate to the Responses API)の冒頭には、Chat Completionsはサポートが続くが、新規プロジェクトにはResponsesが推奨されるという趣旨の太字の一文がある(2026年10月14日確認)。つまり、Chat Completionsがすぐに使えなくなるわけではない。一方で、これから作るものをどちらで作るかと聞かれれば、公式の答えはResponsesだ。

見たい点	Chat Completions	Responses API
エンドポイント	/v1/chat/completions	/v1/responses
入力	messages配列	input(文字列またはItemの配列)と、トップレベルのinstructions
出力の読み方	choices[0].message.content	SDKのoutput_text、またはoutput配列のItem
会話状態	開発者が履歴を自分で保持して毎回送る	previous_response_id、Itemの手動引き継ぎ、Conversations APIから選ぶ
組み込みツール	使えない	Web検索・ファイル検索・コンピュータ操作・コードインタプリタ・MCPなど
Structured Outputs	response_format	text.format
ストリーミング	deltaを持つチャンク	型付きのイベント(response.output_text.deltaなど)
複数候補(n)	使える	提供されない

この表は、移行ガイドの比較・対応表の記述に沿って編集部がまとめたものだ。以降の章で、それぞれの行を公式の記述と照らして詳しく見ていく。

Responses APIとは何か(公式の位置づけ)

Responses APIは、Web検索・ファイル検索・コンピュータ操作・コードインタプリタ・リモートMCPといった組み込みツールを、1回のAPIリクエストの中で呼び出せるエージェント的な設計の統一インターフェースである。

公式の移行ガイドは、Responses APIを「エージェントのようなアプリケーションを作るための統一インターフェース」として説明し、組み込みツール、前のレスポンスを渡せる複数ターンのやり取り、テキストと画像のネイティブなマルチモーダル対応を挙げている(2026年10月14日確認)。同じガイドの「Responses benefits」の節では、メリットとして、推論モデルでの性能、1回のリクエスト内で複数のツールを呼べるエージェント的なループ、キャッシュ利用率の改善によるコスト面、store: trueによる状態保持、柔軟な入力、暗号化された推論、今後のモデルへの対応が並んでいる。

呼び出し方はシンプルで、inputに文字列かメッセージのリストを渡し、システムレベルの指示はinstructionsに分けて渡す。公式ガイドのコード例は次のとおりだ。

from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-6-astra", instructions="You are a helpful assistant.", input="Hello!"
)
print(response.output_text)

このコードに出てくるgpt-6-astraは、公式の移行ガイドのAPI用コード例で使われているモデルIDだ。モデルごとの位置づけは後の章で整理するが、モデルそのものの詳しい特徴を知りたい場合はGPT-6 Astraの記事を参照してほしい。

Chat Completions APIとは何か(現状のサポート状況)

Chat Completions APIは、role付きのmessages配列を送り、応答をchoices配列で受け取る、これまでOpenAIのAPIの中心だった呼び出し方式で、公式ドキュメントの上では現在もサポートされている。

移行ガイドは、Chat Completionsはサポートが続くため、ユーザーの操作の流れ(フロー)を1つずつ移行できると説明している。あわせて、時間をかけてすべてのフローをResponses APIへ移すことを推奨している(2026年10月14日確認)。

では廃止の予定はあるのか。OpenAIのDeprecationsページを2026年10月14日に開いて確認した範囲では、/v1/chat/completionsを廃止対象として挙げる項目は見当たらなかった。同ページに/v1/chat/completionsが出てくるのは、2024年に廃止された/v1/editsの推奨される移行先としての記載だった。したがって、このページを根拠に「Chat Completionsは近く廃止される」と書くことはできない。

ただし、サポートが続くことと、新しいモデルの機能をすべて使えることは別の話だ。特にツール呼び出しでは、モデルごとに制限がある。次の章で、機能面の差をまとめて確認する。

機能比較表(できること・できないこと)

公式の機能対応表では、テキスト生成・画像入力(Vision)・Structured Outputs・Function calling・Web検索は両方のAPIで使え、ファイル検索・コンピュータ操作・コードインタプリタ・MCP・画像生成・推論サマリーはResponses APIだけが対応し、音声(Audio)はChat Completionsが対応でResponsesは「Coming soon」と記載されている。

移行ガイドに掲載されている機能対応表(Capabilities)を、2026年10月14日に確認して日本語の表にすると次のようになる。

機能	Chat Completions API	Responses API
テキスト生成	対応	対応
音声(Audio)	対応	Coming soon(公式表記のまま)
画像入力(Vision)	対応	対応
Structured Outputs	対応	対応
Function calling	対応	対応
Web search	対応	対応
File search	非対応	対応
Computer use	非対応	対応
Code interpreter	非対応	対応
MCP	非対応	対応
Image generation	非対応	対応
Reasoning summaries	非対応	対応

この表で例外なのが音声(Audio)だ。Responses側は公式表で「Coming soon」とされている。音声を中心にした機能を今すぐ組みたい場合は、Chat Completions側、またはRealtime系の仕組みを検討することになる。なお、公式のモデル一覧には、音声入出力向けのモデルとして、Chat Completions向けのものとRealtime向けのものが別々に掲載されている(2026年10月14日確認)。

逆に、ファイル検索、コードインタプリタ、複数のリモートMCPサーバーを1つのリクエストで組み合わせたいエージェント的な用途では、公式の対応表を見る限りResponses APIが前提になる。

モデルによって変わる注意点(ツール呼び出しとreasoning_effort)

OpenAIの公式ガイドによると、GPT-6 AstraとGPT-6.1 SolはChat Completionsにも対応するが、ツール呼び出しにはResponses APIが必要で、GPT-6 SolとGPT-6 LunaがChat Completionsで関数呼び出しを使えるのはreasoning_effortがnoneのときに限られる。

この点は、API版の最新モデルガイド(Using GPT-6)に書かれている。同ガイドの移行クイックスタートには、ツール呼び出しはResponses APIを使うこと、GPT-6 AstraとGPT-6.1 SolはChat Completionsに対応するがツール呼び出しはResponsesが必要なこと、GPT-6 SolとGPT-6 LunaはChat Completionsでの関数呼び出しがreasoning_effortをnoneにした場合に限られることが書かれている(2026年10月14日確認)。GPT-6.1 Solの項目にも、ツール呼び出しにはResponses APIを使い、Chat Completionsはツールなしのリクエストに対応するという趣旨の記述がある。

さらに、移行ガイドの「Additional differences」には、GPT-5.4以降、Chat Completionsではreasoning_effortがnone以外のときにツール呼び出しをサポートしないという記述がある。推論を使いながらツールを呼ぶ構成が必要なら、Responses APIを選ぶ理由として最も分かりやすい。

モデル(APIのモデルID)	Chat Completionsでのツール呼び出し(公式ガイドの記載)
GPT-6 Astra(gpt-6-astra)	ツール呼び出しにはResponses APIが必要
GPT-6.1 Sol(gpt-6.1-sol)	ツール呼び出しにはResponses APIが必要
GPT-6 Sol(gpt-6-sol)	関数呼び出しはreasoning_effort: "none"の場合に限る
GPT-6 Luna(gpt-6-luna)	関数呼び出しはreasoning_effort: "none"の場合に限る

同じ最新モデルガイドには、reasoning_effortに関して、GPT-6 AstraとGPT-6.1 Solはnoneに対応せず、代わりにlowを使うという記述もある。既存のコードでnoneを指定している場合、モデルを切り替えるときに合わせて見直す必要がある。このように、APIの選択とモデルの選択は連動する。モデルの系統そのものを整理したい場合は、ChatGPT最新モデルの違いと使い分けの記事も判断材料になる。

リクエスト形式の違い(messages配列とinput/Itemの違い)

Chat Completionsは入力も出力も「Message」の配列で扱うのに対し、Responses APIは入力と出力を「Item」の集合として扱い、メッセージ・関数呼び出し・関数の実行結果などを別々のItem種別として区別する。

移行ガイドは、Chat Completionsの入力と結果がMessageの配列であるのに対し、Responses APIはItemを使うと説明している。ItemはさまざまなタイプのUnionで、messageもfunction_callもfunction_call_outputもItemの一種だ。Chat Completionsでは多くの関心事が1つのMessageにまとまっているが、Itemは互いに独立していて、モデルのコンテキストの基本単位をよりよく表す、というのが公式の説明だ。同じ質問を送る場合のコードは次のようになる。

# Chat Completions
completion = client.chat.completions.create(
    model="gpt-6-astra",
    messages=[
        {
            "role": "user",
            "content": "Write a one-sentence bedtime story about a unicorn.",
        }
    ],
)
print(completion.choices[0].message.content)

# Responses
response = client.responses.create(
    model="gpt-6-astra",
    input="Write a one-sentence bedtime story about a unicorn.",
)
print(response.output_text)

なお、Chat Completionsはnパラメータで複数の候補(choices)を返せるが、Responses APIはこのパラメータを持たず、生成は1つだけだと移行ガイドに書かれている。1回のリクエストで複数案を受け取る使い方をしている場合は、移行後に別々のリクエストへ分ける必要がある。

ツールも関数も使わず、テキストだけのメッセージ入力であれば、同じ配列をそのままinputに渡せるという例も公式ガイドにある。

context = [
    {"role": "system", "content": "You are a helpful assistant."},
    {"role": "user", "content": "Hello!"},
]

completion = client.chat.completions.create(model="gpt-6-astra", messages=context)

response = client.responses.create(model="gpt-6-astra", input=context)

つまり、テキストだけを生成する単純なフローは、移行の最初の一歩に向いている。関数呼び出しやマルチモーダル入力を使っているフローは、下の章で見る形の変更が加わる。

レスポンス形式の違い(choicesとoutput配列の違い)

Chat Completionsのレスポンスはchoices配列の中にmessageを持つ形で返るのに対し、Responses APIのレスポンスはoutputという配列の中に、reasoningやmessageなど種類の違うItemが並んで返る。

移行ガイドに載っているレスポンス例の構造を、フィールドを一部省略して示す。Chat Completionsはchoicesの中にmessageが入る。

{
  "id": "chatcmpl-C9EDpkjH60VPPIB86j2zIhiR8kWiC",
  "object": "chat.completion",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "..."
      },
      "finish_reason": "stop"
    }
  ]
}

一方、Responses APIはoutputの中に、reasoning用のItemとmessage用のItemが別々に並ぶ。

{
  "id": "resp_68af4030592c81938ec0a5fbab4a3e9f05438e46b5f69a3b",
  "object": "response",
  "output": [
    { "id": "rs_...", "type": "reasoning", "content": [], "summary": [] },
    {
      "id": "msg_...",
      "type": "message",
      "status": "completed",
      "content": [{ "type": "output_text", "text": "..." }],
      "role": "assistant"
    }
  ]
}

公式ガイドは、最終的なテキストだけが欲しいときはSDKのoutput_textヘルパーを使い、推論・ツール・マルチモーダル出力を扱うフローではresponse.outputを巡回してItemのtypeごとに処理するよう説明している。output_textヘルパーはResponses側のSDKにあり、Chat Completions側のSDKにはないとも書かれている。

実装で起きやすいのは、choices[0].message.contentを読んでいた箇所を機械的に置き換えたときに、outputの先頭がmessageだと思い込んでしまうミスだ。推論を伴うモデルでは、先頭にreasoningのItemが入ることがある。後述の「よくある移行ミス」で公式が挙げている項目と同じ内容なので、チェックリストに加えておくとよい。

会話状態(state)の管理方法の違い

Chat Completionsでは会話履歴を開発者が自分で保持して毎回送る必要があるのに対し、Responses APIでは、前回のレスポンスを参照するprevious_response_id、出力Itemの手動での引き継ぎ、永続的な会話オブジェクトを使うConversations APIの3つから選べる。

移行ガイドは、Chat Completionsでは会話状態を手動で管理する必要があると説明し、Responsesでの状態管理の選択肢として次の3つを挙げている(2026年10月14日確認)。

• previous_response_idを使い、OpenAI側に過去のレスポンスの文脈を持たせる。
• 前のoutputのItemを次のリクエストのinputに戻し、自分でコンテキストを管理・整理する。
• 永続的な会話オブジェクトが必要なときは、Conversations APIを使う。

1つ目の方法は、次のように書く。

res1 = client.responses.create(
    model="gpt-6-astra", input="What is the capital of France?", store=True
)

res2 = client.responses.create(
    model="gpt-6-astra",
    input="And its population?",
    previous_response_id=res1.id,
    store=True,
)

ここで注意したいのは2点ある。1点目は料金だ。公式は、previous_response_idを使っても、チェーン内の過去のレスポンスの入力トークンはすべてAPIの入力トークンとして課金されると明記している。実装の手間は減るが、コスト削減の仕組みではない。2点目はinstructionsだ。移行ガイドによると、previous_response_idは前のレスポンスのトップレベルのinstructionsを引き継がないため、変わらない指示は毎回のリクエストで渡し直す。

長期の会話オブジェクトを使う場合は、Conversation stateガイドにあるとおり、Conversations APIで会話を作り、そのidをResponses APIのconversationパラメータに渡す。このガイドは、会話オブジェクトを、固有の識別子を持つ長期的なオブジェクトで、セッションやデバイスをまたいで使い続けられるものとして説明している。

conversation = openai.conversations.create()

response = openai.responses.create(
    model="gpt-6-astra",
    input=[{"role": "user", "content": "What are the 5 Ds of dodgeball?"}],
    conversation=conversation.id,
)

データの保持期間にも違いがある。同ガイドによると、Responseオブジェクトは既定で一定の期間(TTL)保存され、storeをfalseにすると保存しないようにできる。一方、会話オブジェクトとその中のItemにはそのTTLが適用されない(2026年10月14日確認)。具体的な保存期間は同ガイドのデータ保持の項に書かれているので、運用前に確認してほしい。

会話状態に関する対応表と保存の扱い

Chat CompletionsからResponses APIへ移すときは、messagesはinputに、システム指示はinstructionsに、関数の実行結果はcall_idで結ぶfunction_call_outputのItemに対応づけ、nによる複数生成は対応するものがない。

移行ガイドの「Map Messages to Items」の節に沿って、概念の対応をまとめると次のとおりになる(2026年10月14日確認)。

Chat Completionsの概念	Responses APIでの対応
messages[]	input(文字列、またはInput Itemの配列)
System / developerの指示	トップレベルのinstructions。既存のやり取りを保ちたいときは互換のあるメッセージItem
Userメッセージ	role: "user"のinput message Item
Assistantメッセージ	response.outputの中のoutput message Item(手動で状態管理するならinputに戻す)
Tool / function call	function_callというoutput Item
Tool / function result	call_idで呼び出しと結ぶfunction_call_outputというinput Item
nによる複数生成	Responsesでは提供されない(複数案が必要なら別々のリクエストにする)

保存の扱いも押さえておきたい。移行ガイドには、Responsesは既定で保存され、Chat Completionsは新しいアカウントで既定で保存される、どちらのAPIでもstore: falseで保存しないようにできると書かれている。Zero Data Retention(ZDR)など、データ保持に制約がある組織は、Responses APIを状態保持ありでは使えない場合がある。その場合は、store: falseにしたうえで、返ってくる暗号化された推論Itemをそのまま保持して次のリクエストで渡す方法が公式に示されている。ZDRの組織ではstore: falseが自動で適用されるとも記載されている。

Structured Outputsの書き方の違い

構造化出力を指定する場所が変わっており、Chat Completionsではresponse_formatにjson_schemaを指定するのに対し、Responses APIではtext.formatにスキーマを指定する。

移行ガイドは、Responses APIではresponse_formatからtext.formatへ定義が移ったと説明している。公式のStructured Outputsガイドにも詳細がある。両者を並べると次のようになる。

# Chat Completions
completion = client.chat.completions.create(
    model="gpt-6-astra",
    messages=[{"role": "user", "content": "Jane, 54 years old"}],
    response_format={
        "type": "json_schema",
        "json_schema": {
            "name": "person",
            "strict": True,
            "schema": {
                "type": "object",
                "properties": {
                    "name": {"type": "string", "minLength": 1},
                    "age": {"type": "number", "minimum": 0, "maximum": 130},
                },
                "required": ["name", "age"],
                "additionalProperties": False,
            },
        },
    },
    reasoning_effort="medium",
)

# Responses
response = client.responses.create(
    model="gpt-6-astra",
    input="Jane, 54 years old",
    text={
        "format": {
            "type": "json_schema",
            "name": "person",
            "strict": True,
            "schema": {
                "type": "object",
                "properties": {
                    "name": {"type": "string", "minLength": 1},
                    "age": {"type": "number", "minimum": 0, "maximum": 130},
                },
                "required": ["name", "age"],
                "additionalProperties": False,
            },
        }
    },
)

スキーマの中身は同じで、json_schemaの入れ子が1段浅くなり、nameとstrictとschemaがformatの直下に並ぶのが形の違いだ。移行作業としては、この置き場所を書き換えるのが中心になる。

Function calling(関数呼び出し)定義の違い

Chat Completionsの関数定義はtype: "function"の中にfunctionオブジェクトを入れる「外部タグ付け」で、Responses APIではnameやparametersを同じ階層に並べる「内部タグ付け」になっており、strictの既定の挙動も異なる。

移行ガイドは、関数呼び出しの形の違いを2つ挙げている。1つ目は関数定義のタグ付けの方式(外部か内部か)、2つ目はstrictの既定値だ。Chat Completionsの関数は既定で非strictだが、Responsesではstrictを省略するとstrictモードを試み、スキーマが対応できない場合は非strictのベストエフォートに戻り、解決後のツールをstrict: falseとして返す。非strictを明示的に保ちたい場合はstrict: falseを指定すると公式は説明している(2026年10月14日確認)。

// Chat Completions
{
  "type": "function",
  "function": {
    "name": "get_weather",
    "description": "Determine weather in my location",
    "strict": true,
    "parameters": {
      "type": "object",
      "properties": { "location": { "type": "string" } },
      "additionalProperties": false,
      "required": ["location"]
    }
  }
}

// Responses
{
  "type": "function",
  "name": "get_weather",
  "description": "Determine weather in my location",
  "parameters": {
    "type": "object",
    "properties": { "location": { "type": "string" } },
    "additionalProperties": false,
    "required": ["location"]
  }
}

実行結果の受け渡しにも違いがある。Responses APIでは、ツール呼び出しとその出力が別々のタイプのItemとして扱われ、call_idで対応づけられる。具体的な送り方は、公式のFunction callingガイドに沿って実装するのが確実だ。strictの既定値が入れ替わっているため、Chat Completions時代のスキーマをそのまま移すと、想定と違う挙動になる場合がある。移行後は、返ってきたツール定義のstrictの値を確認しておくとよい。

ストリーミングの違い

Chat Completionsのストリーミングはdeltaフィールドを持つ断片的なチャンクを返すのに対し、Responses APIのストリーミングはresponse.createdやresponse.output_text.deltaのような型付きのサーバー送信イベントを返す。

移行ガイドによると、テキストをストリーミングするときに見るべきイベントとしてresponse.created、response.output_text.delta、response.completed、errorが挙げられている。関数呼び出しのストリームではresponse.function_call_arguments.deltaやresponse.function_call_arguments.doneといったイベントも発生する。詳細は公式のストリーミングのガイドで確認できる。

実務では、既存のChat Completions用のストリーム処理をそのまま流用できない点が最大の注意点だ。イベントのtypeごとに分岐するハンドラーに書き換える必要がある。画面にテキストを流すだけの用途なら、まずresponse.output_text.deltaだけを拾う実装から始め、ツール呼び出しを使う段階でほかのイベントに対応を広げる進め方が考えやすい。

組み込みツールで何が変わるか

Chat Completionsでは、OpenAIが提供するホスト型ツールをそのまま使えず、検索などの処理は自分で関数として実装する必要があるが、Responses APIではtoolsにtypeを指定するだけでWeb検索などの組み込みツールを使える。

移行ガイドの「Upgrade to native tools」の節は、Chat Completionsではホスト型ツールをそのまま使えず、自前でツール連携を書く必要があるのに対し、Responsesではモデルに使わせたいツールを指定できると説明している。公式のWeb検索の例は次のようになる。

answer = client.responses.create(
    model="gpt-6-astra",
    input="Who is the current president of France?",
    tools=[{"type": "web_search"}],
)

print(answer.output_text)

Chat Completions側の例では、検索を行うweb_search関数を自分で用意し、関数として渡している。同じ節には、その例がGPT-5.6 Terraを推論なし(reasoning_effort: "none")で使っているものであり、GPT-6 AstraとGPT-6.1 SolではツールにResponses APIが必要だという注記も付いている。ツールの組み合わせが増えるほど、自前実装と組み込みツールの差は大きくなる。ファイル検索やコードインタプリタなど、使いたいツールが複数あるなら、最初からResponses APIで設計したほうが作業は少なくて済む。

コスト・性能面で公式が言及していること

OpenAIは移行ガイドで、Responses APIには推論モデルでの性能向上とキャッシュ利用率の改善によるコスト面の利点があると説明しているが、これはOpenAIの社内評価に基づく記述で、自社のワークロードでの効果は別に測る必要がある。

移行ガイドの「Responses benefits」には、推論モデルをResponsesで使うと、同じプロンプトと設定でChat Completionsより性能が高くなる傾向があること、キャッシュの利用率が改善されてコストが下がる傾向があることが、いずれも社内評価(internal evals / internal tests)に基づくものとして書かれている(2026年10月14日確認)。具体的な改善幅の数値も公式ページに載っているが、あくまで社内テストの条件での値であり、すべてのプロンプトやワークロードで同じ結果が出るという意味ではない。この記事では、数値を一般的な期待値として紹介することはしない。

移行を検討するときは、自社の代表的なリクエストを選び、Chat CompletionsとResponsesでレイテンシー、トークン消費量、キャッシュの効き方を実際に比べるのが実務的だ。公式の段階的な移行チェックリストにも、挙動、レイテンシー、トークン使用量、エラーを比較してから、より多くのトラフィックをResponsesへ流すという項目がある。

料金そのものはモデルごとに異なる。公式のモデル一覧から各モデルのページに進み、利用するモデルの料金を確認してほしい。この記事のコード例に出てくるモデルIDは、あくまで公式ガイドのコード例に合わせたものだ。

どちらを選ぶべきか(新規開発・既存移行での判断基準)

これから新しく作る機能はResponses APIを選ぶのが公式の推奨ルートで、すでにChat Completionsで安定して動いている機能は、一括で書き換えず、フロー単位で段階的にResponsesへ切り替えるのが公式の提案する進め方である。

移行ガイドは、Chat Completionsのサポートが続くのでユーザーの操作の流れを1つずつ移行できること、時間をかけてすべてのフローをResponses APIへ移すことを推奨していることを述べている(2026年10月14日確認)。一括の書き換えを前提にしていない。これらを踏まえ、編集部で判断の目安を次のように整理した。

状況	目安	根拠となる公式の記述
これから新規に作るAPI連携	最初からResponses APIで作る	新規プロジェクトにはResponsesが推奨されている
ファイル検索・コンピュータ操作・コードインタプリタ・MCPを使いたい	Responses APIを選ぶ	機能対応表でChat Completionsは非対応
GPT-6 AstraやGPT-6.1 Solでツールを使う	Responses APIを選ぶ	最新モデルガイドでツール呼び出しにはResponsesが必要
推論を使いながら関数呼び出しもしたい	Responses APIを選ぶ	GPT-5.4以降、Chat Completionsはreasoning_effortがnone以外でのツール呼び出し非対応
音声入出力が中心の機能	当面はChat Completions(またはRealtime系)を検討する	機能対応表でResponsesのAudioは「Coming soon」
テキスト生成だけで安定して動いている既存機能	急がず、余裕のあるときに移す	Chat Completionsはサポートが続いている
会話履歴の管理が複雑になっている	Responsesの状態管理の導入を検討する	previous_response_idとConversations APIが用意されている

仮の例として、社内の問い合わせ内容を要約するだけの小さなツールがすでにChat Completionsで動いているとする。ツールもファイル検索も使っていないなら、急いで移す理由は小さい。同じ会社が、社内文書を検索して答えるアシスタントを新しく作るなら、ファイル検索を組み込みツールで使えるResponses APIで始めるほうが自然だ。この例はあくまで考え方を示す仮のもので、実在の事例ではない。

この表のうち、どれか1行にでも当てはまれば、そのフローはResponsesへ移す優先度が高い。逆に、どれにも当てはまらない単純なテキスト生成だけの機能は、急いで書き換える理由が小さい。API連携ではなく、ChatGPTの画面で会話の設計を試したいだけなら、カスタムGPT(GPTs)の作り方の記事から始める方法もある。

移行の手順(段階的に進める流れ)

Chat CompletionsからResponses APIへの移行は、エンドポイントを/v1/responsesに変え、出力を型付きのoutput配列から読み、会話状態の持ち方を決める、という3つの変更を軸に、テキスト生成のフローから順に進めるのが公式の示す手順である。

移行ガイドは、移行を「/v1/responsesへリクエストを送る」「型付きのoutput配列から出力を読む」「ターンの間で状態をどう持つか選ぶ」という関連した3つの変更として扱うよう説明している。そのうえで、次のような「Incremental rollout checklist(段階的な導入チェックリスト)」を示している(2026年10月14日確認)。

1. テキスト生成のフローから着手する。
2. エンドポイント、リクエスト本文、出力の扱いを更新する。
3. そのフローがprevious_response_id、Itemの手動での引き継ぎ、Conversations APIのどれを使うかを決める。
4. 状態を持たない、またはZDRのフローではstore: falseを加え、推論の文脈を続けたいときは暗号化された推論Itemを含める。
5. 関数定義を移し、関数の出力に正しいcall_idが付くことを確認する。
6. Structured Outputsのスキーマをresponse_formatからtext.formatへ移す。
7. ストリーミングの処理を型付きイベントに合わせて更新する。
8. 自前のオーケストレーションを、合う場面ではOpenAIのホスト型ツールに置き換える。
9. より多くのトラフィックをResponsesへ流す前に、挙動・レイテンシー・トークン使用量・エラーを比べる。

1機能ずつ進めれば、途中で想定外の挙動が見つかっても、そのフローだけChat Completionsに戻して原因を調べられる。モデルIDの非推奨スケジュールの確認は、APIの選択とは別に必要な作業だ。OpenAIのDeprecationsページには、モデルの提供終了までの最低限の予告期間が、一般提供モデル、その派生版、プレビューモデルで分けて書かれており、プレビューモデルは短い予告で提供終了となる場合があるという記載がある(2026年10月14日確認)。具体的な期間は同ページの予告期間の項で確認できる。このページは、List modelsのエンドポイント(GET /v1/models)で、各モデルのshutdown_dateフィールドを確認する方法も案内している。非推奨化の考え方そのものはOpenAIモデル非推奨化戦略の記事で詳しく解説している。

Assistants APIを使っている場合

Assistants APIは2026年8月26日にサンセット(提供終了)したと公式の移行ガイドに書かれており、まだAssistants APIのコードが残っている場合は、Responses APIとConversations APIへの移行が必要になる。

OpenAIのDeprecationsページには、Assistants APIを2026年8月26日に削除すると事前に通知していたこと、推奨される移行先がResponses APIとConversations APIであることが記載されている。公式のAssistants移行ガイドの冒頭には、Assistants APIは2026年8月26日に正式にサンセットされ、利用できなくなったこと、新規の連携にはResponses APIを使うことが書かれている(2026年10月14日確認)。

この記事のテーマであるChat Completionsとの比較とは別の話だが、「OpenAIのAPIを古くから使っていて、どれから手を付けるべきか分からない」という場合の優先順位ははっきりしている。Assistants APIが残っているなら、それが最優先の移行対象だ。Chat Completionsは前述のとおりサポートが続いているため、そちらは機能単位で後から進められる。

よくある移行ミス(公式のチェック項目)

公式の移行ガイドは、choices[0].message.contentを読み続ける、outputの全Itemをメッセージだと思い込む、call_idを合わせない、response_formatを使い続ける、といった典型的なミスを「Check common migration errors」として挙げている。

移行ガイドが挙げている典型的なミスは、次のとおりだ(2026年10月14日確認)。

• response.output_textやresponse.outputではなく、choices[0].message.contentを読み続けてしまう。
• outputの全エントリをメッセージだと扱ってしまう。reasoning、ツール、関数呼び出しは別のItem種別である。
• 文脈を手動で次のレスポンスへ引き継ぐとき、reasoning、関数呼び出し、関数呼び出しの出力のItemを落としてしまう。
• 対応するcall_idを付けずに関数の結果を送ってしまう。
• Responsesのリクエストで、text.formatではなくresponse_formatを使ってしまう。
• Chat Completions用のストリーミングのチャンク処理を、型付きイベントに対応しないまま再利用してしまう。
• previous_response_idを使えば、過去の文脈の課金がなくなると思い込む。実際には、チェーン内の過去の入力トークンは入力トークンとして課金される。

プロンプトのinstructionsの書き方に迷う場合は、プロンプトが伝わらない理由と書き方のコツの記事も参考になる。APIを触らず、ChatGPTの画面から使い方を確認し直したいときはChatGPTの使い方の記事、日常の文章作成やメール作成にそのまま使いたいときはChatGPTで文章作成・メール作成を行う記事を参照してほしい。コーディングの作業をCodexで進めたい場合はOpenAI Codexの使い方の記事、組織での導入を検討している場合はOpenAI Codex企業導入ガイドの記事が入口になる。

よくある質問(FAQ)

Q1. Chat Completions APIは廃止される予定なのですか?

公式の移行ガイドには、Chat Completionsはサポートが続くが、新規プロジェクトにはResponsesが推奨されると書かれている。2026年10月14日に開いたDeprecationsページでは、/v1/chat/completionsを廃止対象として挙げる項目は見当たらなかった。ただし、新しいモデルではツール呼び出しに制限がある場合があるため、モデルごとの記載を最新モデルガイドで確認してほしい。

Q2. 既存のChat Completionsのコードはそのまま動き続けますか?

公式は、Chat Completionsのサポートが続くため、ユーザーの操作の流れを1つずつ移行できると説明している。一括での書き換えを前提にせず、機能単位で段階的にResponses APIへ移す進め方が、公式のチェックリストにも示されている。

Q3. Responses APIでしか使えない機能はありますか?

公式の機能対応表では、File search、Computer use、Code interpreter、MCP、Image generation、Reasoning summariesの6項目がResponses API側のみの対応になっている。逆に、Audio(音声)はChat Completions側が対応で、Responses側は「Coming soon」と記載されている。

Q4. GPT-6 Astraでツール呼び出しを使うには、どちらのAPIを選べばよいですか?

OpenAIの最新モデルガイドでは、GPT-6 AstraとGPT-6.1 SolはChat Completionsにも対応するが、ツール呼び出しにはResponses APIが必要と書かれている。ツールを使う予定があるなら、Responses APIを選ぶことになる。

Q5. 会話履歴の管理はどちらが簡単ですか?

Chat Completionsでは、開発者がmessages配列を保持して毎回送る必要がある。Responses APIでは、previous_response_idで前回のレスポンスを参照する、前のoutputのItemを自分で引き継ぐ、Conversations APIで会話オブジェクトを作ってconversationパラメータに渡す、の3つから選べる。ただしprevious_response_idを使っても、チェーン内の過去の入力トークンは毎回課金対象になると公式が明記している。

Q6. previous_response_idを使えば料金は安くなりますか?

安くなるとは書かれていない。公式は、チェーン内の過去のレスポンスの入力トークンはすべて入力トークンとして課金されると明記している。実装の手間を減らす仕組みであり、コストを下げる仕組みとして期待しないほうがよい。

Q7. Structured Outputsの書き方はどう変わりますか?

Chat Completionsではresponse_formatにjson_schemaを指定する。Responses APIでは、同じ内容をtext.formatに指定する。公式の移行ガイドが、response_formatからtext.formatへ移ったと説明している。

Q8. Assistants APIを使っている場合はどうすればよいですか?

公式のAssistants移行ガイドには、Assistants APIは2026年8月26日にサンセットされ、利用できなくなったと書かれている。新規の連携にはResponses APIを使い、同ガイドの手順で移行する。

まとめ

Chat Completions APIは公式の移行ガイドでも引き続きサポートされており、今すぐ書き換えなければ動かなくなるという状況ではない。一方でResponses APIは、ツール呼び出し、会話状態の管理、Structured Outputsの構造など、多くの面でChat Completionsより新しい設計になっており、公式も新規プロジェクトでの利用を推奨している。特にGPT-6 AstraやGPT-6.1 Solでツールを使うなら、Responses APIが前提になる。

まず、自分のプロダクトが使っている機能を、この記事の機能比較表と判断の目安の表に照らしてみてほしい。ファイル検索、コンピュータ操作、コードインタプリタ、MCP、画像生成のいずれかを使う予定があるなら、選択肢はResponses APIになる。音声が中心の機能なら、Responses側の対応状況が「Coming soon」の間は、Chat Completions側で進める判断も十分に考えられる。

次のアクションとしては、コードの中でchoices[0].message.contentを読んでいる箇所と、messages配列を手動で組み立てている箇所を洗い出し、よくある移行ミスの一覧と突き合わせるところから始めるとよい。APIではなくまずChatGPTを日々の業務効率化に使いたい場合は、ChatGPTを仕事で活用して業務効率化する方法の記事から始める方法もある。