toolsと明示的なreasoning_effortを同時に(none以外の任意の値)/v1/chat/completionsに送信すると、上流で400エラーとして拒否される場合があります: Function tools with reasoning_effort are not supported ...。対処方法は2つあります。ツールを含むリクエストを/v1/responsesに移行する(推論とツールの両方を維持できるため推奨)か、reasoning_effort="none"を明示的に設定する(エンドポイントを維持する代わりに、推論を使用しない)方法です。toolsを含まないリクエストには影響ありません。まず、これに該当していることを確認してください
現れ方は3通りあります。2つ目が最も誤解しやすいものです。症状1: 明示的な400エラー
param: reasoning_effortが含まれます。これはOpenAIによる公式の制限であり、APIYIゲートウェイの問題ではありません。同じリクエストをOpenAIに直接送信しても、まったく同じ動作になります。
症状2: 成功することもあれば、失敗することもある
1つのモデルが複数の上流ルートの背後に配置されている場合があり、すべてのルートでこの制限が適用されるわけではありません。2026-09-02に、デフォルトのグループ、同じキー、同じ時間帯で、組み合わせごとに6回呼び出して独自に測定した結果は次のとおりです。gpt-5.6-solでこの400を受け取っています。
症状3: エラーはないが、ツールが呼び出されない
モデルがツールを呼び出すはずなのに、代わりに雑談を返している場合(finish_reasonがstopで、tool_callsが空)、まずプロンプトを書き直し始めないでください。reasoning_effortをnoneに明示的に設定して、もう一度送信してください。これでツールが正しく呼び出されるなら、問題はプロンプトではなくパラメータの組み合わせにあります。
制限の対象範囲
none の effort レベルを明示的に送信することです。テストでは、low、medium、high、xhigh の4つすべてでトリガーが発生しました。
reasoning_effort を省略してもトリガーは発生しません。 400 を確実に再現する gpt-5.6-luna ルートでは、4つすべての effort レベルで 400 が返されました。一方、パラメーターを省略した場合は、tool_calls が6回中6回、正常に返されました。そのため、緊急時の最小限の修正には2つの方法があります。none を明示的に設定するか、パラメーターを完全に削除してください。どちらの移行先を選ぶべきか
none は最終的な移行先ではなく、一時的な回避策として扱ってください。
エラーを回避することだけが目的ではありません
制限に一度も遭遇しなかったとしても、新規プロジェクトでは OpenAI が Responses を推奨しています。公式には、同じ推論モデルでも Responses 経由のほうが SWE-bench のスコアが高く、キャッシュの利用効率は Chat Completions より大幅に優れており、ウェブ検索やコードインタープリターなどの組み込みツールはここでしか利用できません。数値と詳細については、ネイティブ呼び出しをご覧ください。 キャッシュに関するポイントは、請求額に反映される点です。マルチターンエージェントはキャッシュヒットの恩恵を最も受けます。そして、マルチターンエージェントは、まさに上記の制限に遭遇する可能性が最も高いワークロードです。キャッシュの課金方法とヒット率の読み方については、プロンプトキャッシュをご覧ください。どのグループに該当しますか
コードで変更される点
完全なフィールドマッピングはネイティブ呼び出しに記載されています。ここでは、このページのテーマであるツール呼び出しに関係する、重要な4つの違いだけを示します。移行時に多くの人が遭遇する落とし穴
output は choices ではありません — その中をインデックスで参照しないでください
output は choices ではありません — その中をインデックスで参照しないでください
output は 項目の配列であり、reasoning、message、function_call のエントリを一度に保持できますが、順序や個数は保証されません。テキストには resp.output_text を使用し、ツール呼び出しには type == "function_call" をフィルタリングしながら反復処理してください。インデックスをハードコードしないでください。パラメータの名称変更: max_tokens、response_format、temperature
パラメータの名称変更: max_tokens、response_format、temperature
max_tokens(または max_completion_tokens)は max_output_tokens になり、response_format は text.format になります。システムプロンプトは messages からトップレベルの instructions に移動できます。これとは別に、gpt-5 の推論モデルは、どちらのエンドポイントでも temperature または top_p をサポートしていません — これらを削除し、代わりに reasoning.effort でモデルを制御してください。すべての使用量フィールドの名称が変更されます
すべての使用量フィールドの名称が変更されます
usage.prompt_tokens は usage.input_tokens に、completion_tokens は output_tokens になり、キャッシュヒットは usage.input_tokens_details.cached_tokens に格納されます。使用量の集計も同時に更新してください。更新しないと、ゼロがサイレントに記録されます。マルチターン: 履歴を自分で管理すれば常に機能しますが、チェーンの動作はグループによって異なります
マルチターン: 履歴を自分で管理すれば常に機能しますが、チェーンの動作はグループによって異なります
input 配列を自分で管理し、各ターンの output をそのまま追加することです。これはすべてのグループとすべてのモデルで有効であり、上記の例でもこの方法を使用しています。previous_response_id によるチェーンは、2026-09-02 のデフォルトグループでは機能しました — gpt-5.6-sol、terra、luna、gpt-5.4 はいずれも前のターンを再呼び出しし、store はデフォルトで true になり、store: false を送信してからチェーンすると、前のレスポンスが見つからないことが正しく報告されます。GET /v1/responses/{id} による履歴の取得は、引き続き利用できません。依存する前に、自分のグループで検証してください。 背景情報: マルチターン会話。ストリーミングは差分の連結ではなく、意味を持つイベントストリームです
ストリーミングは差分の連結ではなく、意味を持つイベントストリームです
delta 増分をストリーミングし、Responses は response.output_text.delta や response.function_call_arguments.delta などの型付きイベントをストリーミングします。ストリーミングパーサーはそのまま再利用するのではなく、書き換える必要があります。ネイティブ呼び出しを参照してください。移行の検証
HTTP 200 だけで判断しないでください。次の 4 つを確認してください。出力に本当に function_call が含まれていることを確認する
[i.type for i in resp.output] を出力してください。function_call が表示され、高い effort レベルではその前に reasoning が表示されるはずです。message だけの場合、ツールは一度も呼び出されていません。使用量フィールドに引き続き値が入っていることを確認する
usage.input_tokens と output_tokens がゼロ以外であり、output_tokens_details.reasoning_tokens が effort レベルに応じて変化することを確認してください。キャッシュヒットが現れ始めることを確認する
usage.input_tokens_details.cached_tokens がゼロを超えて増加することを確認してください。これは、互換性モードに対して Responses が持つ最も直接的な課金上のメリットです。以前 400 になっていたリクエストを再実行する
tools と reasoning_effort の組み合わせが、これで安定して通るはずです。将来のモデル交換時に問題が直ちに明らかになるよう、回帰テストケースとして残してください。移行しない場合
これは二者択一ではありません。以下の場合は、互換モードを使い続けてもまったく問題ありません。- tool calling を使用していない — この制限は適用されず、任意の
reasoning_effortを送信できます - 1つのコードパスで複数のベンダーを呼び出している — Claude と Gemini はここでは
/v1/chat/completionsのみを提供しており、OpenAI のためだけに分岐しても割に合わない可能性があります - フレームワークまたはクライアントによってエンドポイントが固定されている — 対応するまで
reasoning_effort="none"で現状を維持してください gpt-5.2以前を利用している — 影響を受ける範囲外です
FAQ
reasoning_effort=none にすると、具体的に何が失われますか?
reasoning_effort=none にすると、具体的に何が失われますか?
ツールを含むリクエストに対してのみ、エンドポイントを切り替えることはできますか?
ツールを含むリクエストに対してのみ、エンドポイントを切り替えることはできますか?
/v1/chat/completions に残し、ツールを含む処理だけを /v1/responses に移します。どちらのエンドポイントも同じキーと同じベース URL を使用し、料金も同一です。エンドポイントを切り替えると料金は変わりますか?
エンドポイントを切り替えると料金は変わりますか?
Claude と Gemini は影響を受けますか?
Claude と Gemini は影響を受けますか?
/v1/messages 経由または互換モードの Claude と、ネイティブモードまたは互換モードの Gemini は、どちらもツール呼び出しと thinking を同時に使用できます。Pro モデルが Responses 専用なのはなぜですか?
Pro モデルが Responses 専用なのはなぜですか?
gpt-5.4-pro と gpt-5.5-pro は /v1/responses 経由でのみ利用でき、SVIP グループが必要です。これらは長時間実行されるよう設計されており、互換モードでは扱えないバックグラウンドモードとの組み合わせを前提としています。ネイティブ呼び出し を参照してください。Chat Completions は廃止されるのですか?
Chat Completions は廃止されるのですか?