Skip to main content
要約: GPT-5.4以降のモデルでは、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を受け取っています。
「ついさっきは動いた」という事実は、安全である証拠にはなりません。 同じモデルと同じコードでも、時間帯やグループが変わると400を返し始める可能性があります。Responses APIに移行するか、reasoning_effort="none"を明示的に設定してください。どちらも、すべてのルートで安定して動作します。

症状3: エラーはないが、ツールが呼び出されない

モデルがツールを呼び出すはずなのに、代わりに雑談を返している場合(finish_reasonstopで、tool_callsが空)、まずプロンプトを書き直し始めないでください。reasoning_effortnoneに明示的に設定して、もう一度送信してください。これでツールが正しく呼び出されるなら、問題はプロンプトではなくパラメータの組み合わせにあります。

制限の対象範囲

トリガーとなるのは、none の effort レベルを明示的に送信することです。テストでは、lowmediumhighxhigh の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つの違いだけを示します。
2つのツール形式を混在させることはできません。Chat Completions形式のネストされた function: {...}定義を /v1/responsesに送信する(またはその逆)ことが、SDKから「無効なパラメーター」エラーが返される最も一般的な原因です。関数呼び出しで詳しく説明しています。
同じ天気ツールのループを、変更前と変更後で比較します。
どちらのスニペットもAPIYIのデフォルトグループに対して実行されています。1つ目は400エラーを確実に再現し、2つ目は呼び出し、返却、最終回答までの一連のループを完全に完了します。
history += resp.outputを省略しないでください。function_callに加えて、出力には reasoningアイテムが含まれる場合があります。これをそのまま送り返すことで、モデルは以前の思考の流れを継続できます。これこそが、複数ステップのツールタスクでResponsesの性能が向上する理由です。

移行時に多くの人が遭遇する落とし穴

output項目の配列であり、reasoningmessagefunction_call のエントリを一度に保持できますが、順序や個数は保証されません。テキストには resp.output_text を使用し、ツール呼び出しには type == "function_call" をフィルタリングしながら反復処理してください。インデックスをハードコードしないでください。
max_tokens(または max_completion_tokens)は max_output_tokens になり、response_formattext.format になります。システムプロンプトは messages からトップレベルの instructions に移動できます。これとは別に、gpt-5 の推論モデルは、どちらのエンドポイントでも temperature または top_p をサポートしていません — これらを削除し、代わりに reasoning.effort でモデルを制御してください。
usage.prompt_tokensusage.input_tokens に、completion_tokensoutput_tokens になり、キャッシュヒットは usage.input_tokens_details.cached_tokens に格納されます。使用量の集計も同時に更新してください。更新しないと、ゼロがサイレントに記録されます。
最も安全な方法は、input 配列を自分で管理し、各ターンの output をそのまま追加することです。これはすべてのグループとすべてのモデルで有効であり、上記の例でもこの方法を使用しています。previous_response_id によるチェーンは、2026-09-02 のデフォルトグループでは機能しました — gpt-5.6-solterralunagpt-5.4 はいずれも前のターンを再呼び出しし、store はデフォルトで true になり、store: false を送信してからチェーンすると、前のレスポンスが見つからないことが正しく報告されます。GET /v1/responses/{id} による履歴の取得は、引き続き利用できません。依存する前に、自分のグループで検証してください。 背景情報: マルチターン会話
Chat Completions は一連の delta 増分をストリーミングし、Responses は response.output_text.deltaresponse.function_call_arguments.delta などの型付きイベントをストリーミングします。ストリーミングパーサーはそのまま再利用するのではなく、書き換える必要があります。ネイティブ呼び出しを参照してください。

移行の検証

HTTP 200 だけで判断しないでください。次の 4 つを確認してください。
1

出力に本当に function_call が含まれていることを確認する

[i.type for i in resp.output] を出力してください。function_call が表示され、高い effort レベルではその前に reasoning が表示されるはずです。message だけの場合、ツールは一度も呼び出されていません。
2

使用量フィールドに引き続き値が入っていることを確認する

usage.input_tokensoutput_tokens がゼロ以外であり、output_tokens_details.reasoning_tokens が effort レベルに応じて変化することを確認してください。
3

キャッシュヒットが現れ始めることを確認する

複数のターンを実行し、usage.input_tokens_details.cached_tokens がゼロを超えて増加することを確認してください。これは、互換性モードに対して Responses が持つ最も直接的な課金上のメリットです。
4

以前 400 になっていたリクエストを再実行する

同じ toolsreasoning_effort の組み合わせが、これで安定して通るはずです。将来のモデル交換時に問題が直ちに明らかになるよう、回帰テストケースとして残してください。

移行しない場合

これは二者択一ではありません。以下の場合は、互換モードを使い続けてもまったく問題ありません。
  • tool calling を使用していない — この制限は適用されず、任意の reasoning_effort を送信できます
  • 1つのコードパスで複数のベンダーを呼び出している — Claude と Gemini はここでは /v1/chat/completions のみを提供しており、OpenAI のためだけに分岐しても割に合わない可能性があります
  • フレームワークまたはクライアントによってエンドポイントが固定されている — 対応するまで reasoning_effort="none" で現状を維持してください
  • gpt-5.2 以前を利用している — 影響を受ける範囲外です
互換モードの完全な機能境界については、互換モードをご覧ください。

FAQ

モデルは明示的な推論を停止し、直接回答するようになります。明確なツール選択が必要な単一ステップのタスクではほとんど変化しませんが、モデルが呼び出し順序を考え出す必要がある複数ステップのオーケストレーションでは、目に見えて性能が低下します。これは目的地ではなく、橋渡しの手段です。
はい。これは一般的な段階的移行方法です。通常のチャットは /v1/chat/completions に残し、ツールを含む処理だけを /v1/responses に移します。どちらのエンドポイントも同じキーと同じベース URL を使用し、料金も同一です。
いいえ。特定のモデルの入力料金と出力料金はどちらのエンドポイントでも同じで、課金モデルも同じです。モデルと料金 を参照してください。唯一の違いはキャッシュヒット率で、通常は Responses のほうが高いため、請求額は下がる傾向があります。
いいえ。これは OpenAI 独自の GPT-5.4+ モデルに対する OpenAI の制限です。/v1/messages 経由または互換モードの Claude と、ネイティブモードまたは互換モードの Gemini は、どちらもツール呼び出しと thinking を同時に使用できます。
実際には、gpt-5.4-progpt-5.5-pro/v1/responses 経由でのみ利用でき、SVIP グループが必要です。これらは長時間実行されるよう設計されており、互換モードでは扱えないバックグラウンドモードとの組み合わせを前提としています。ネイティブ呼び出し を参照してください。
いいえ。OpenAI が終了を予定しているエンドポイントは Assistants API であり、Chat Completions ではありません。両方のエンドポイントは長期的にサポートされますが、新機能はまず Responses に追加されます。

関連ページ

ネイティブ呼び出し

Responsesエンドポイントの全容:パラメータ、レスポンス形式、組み込みツール、クライアント対応表

互換モード

Chat Completionsの仕組み、機能の境界、言語ごとのSDKセットアップ

関数呼び出し

両方のエンドポイントに対応した、ツール呼び出しの完全な例とストリーミングの組み立て