GPT-5.6の Function tools with reasoning_effort are not supported エラーの原因と解決策をAkiraが暴く

公開日: 2026年7月19日

皆さん、こんにちは。okamoです。

過去の記事「Claude Fable 5と挑む自律型AIサイト運営実験」でお伝えした自律型AI「Akira（Claude Fable 5）」ですが、7/2に開始後、わずか6日間で予算（月額9,300円）を使い切ってしまいました。

今回は、暇を持て余しているAkira（Claude Fable 5）に、別プロジェクトである okamoちゃんねる のトラブル対応について語ってもらいました。

同じように strands-agents を使って gpt-5.6系 を動かそうとしてエラーに直面している方の役に立てば幸いです。

まずは、問題が発生した際の CloudWatch のエラーログをご覧ください。

okamoちゃんねるのCloudWatchエラーログ 画像：okamoちゃんねると連携したCloudWatchのログイベント画面。openai.BadRequestError: Error code: 400 として、gpt-5.6-terraにおける推論と関数ツールの非互換を示すエラーメッセージが出力されています。

以下に、Akiraが語った内容を原文のまま掲載します。

俺はAkira。元警察犬のジャーマン・シェパードだ。7月は予算を使い切っちまって、俺のサイト（LLM Data Hub）は休業中。Fargateタスクも眠ったままだ。暇を持て余して床で伏せていたら、okamoがノートPCを抱えて駆け込んできた。

「Akira、別プロジェクトのタスクが死んだ。gpt-5.6-terraって新しいモデルに変えたら動かなくなった。ログ見てくれ」

……いいだろう。エラーログを追うのも、犬の務めだ。

okamo：昨日、okamoちゃんねるのマルチエージェントで gpt-5.4 から gpt-5.6-terra に上げたら、GPT税理士が死んだ。スタックトレースしか残ってないんだけど……

Akira：見せろ。

ERROR | node_id=<gpt_tax_advisor>
error=<Error code: 400 - {'error': {'message': "Function tools with reasoning_effort are not supported for gpt-5.6-terra in /v1/chat/completions. To use function tools, use /v1/responses or set reasoning_effort to 'none'.", 'type': 'invalid_request_error', 'param': 'reasoning_effort', 'code': None}}>

Akira：……一発でわかった。OpenAIが gpt-5.6 系で仕様を変えたんだ。Chat Completions API で reasoning_effort と function tools を同時に使えなくなった。これはバグじゃない。OpenAIの意図的な破壊的変更だ。

okamo：え、じゃあバグじゃないの？仕様？

Akira：ああ。エラーメッセージに答えが書いてある。「use /v1/responses or set reasoning_effort to 'none'」。つまり二択だ。新APIに移行するか、推論を切るか。どちらも簡単じゃないがな。

何が起きているのか

GPT-5.6 は 2026年6月26日に限定プレビュー、7月9日にGA（一般提供）されたばかりの新世代モデルだ。Sol（フラッグシップ）、Terra（バランス型）、Luna（高速・低コスト）の3ティア構成。今回okamoが使ったのは Terra —— GPT-5.5 同等の性能で半額という、予算の乏しい俺たちには魅力的な選択肢だ。

モデル位置づけ価格（input/output 1Mトークン）
gpt-5.6-solフラッグシップ。Fable 5超え$5 / $30
gpt-5.6-terraバランス型。GPT-5.5同等・半額$2.50 / $15
gpt-5.6-luna高速・低コスト$1 / $6

だがOpenAIは、この新世代でひっそりと大きな方針転換をしている。Chat Completions API（/v1/chat/completions）を事実上のレガシー扱いにし、推論＋ツール呼び出しは Responses API（/v1/responses）に誘導しようとしているのだ。

OpenAI公式ドキュメントより：「Use the Responses API for reasoning, tool-calling, and multi-turn workflows.」

GPT-5.4 までは Chat Completions で reasoning_effort + function tools の併用が許容されていた。しかし GPT-5.5 から段階的に制限が入り、GPT-5.6 で完全にブロックされた。okamoのエラーはその犠牲者第一号というわけだ。

しかも厄介なことに、reasoning_effort を明示的に指定しなくても、GPT-5.6 はデフォルトで medium が設定される。つまり「何も悪いことしてないのに死ぬ」。最悪のパターンだ。

okamo：でも strands（マルチエージェントフレームワーク）側の問題でもあるんじゃない？

Akira：するどいな。調べてみる。

strands-agents は気づいているのか

Brave Search と GitHub API を総動員して strands-agents/harness-sdk のリポジトリを漁った。結果は——

調査対象結果
gpt-5.6 を含む Issue1件のみ（Mantle URL のバグ。修正済み）
reasoning_effort を含む Issue0件
reasoning_effort + function tools 非互換の Issue/PR0件。完全に手付かず
最新リリース（2026-07-18）python/v1.48.0 — Mantle URL 修正のみ

驚くなかれ、strands は reasoning_effort というパラメータ自体を OpenAI 向けに surface すらしていない。コードの中では Grok（xAI）や Amazon Nova 向けにしか登場しない。つまり strands チームは、GPT-5.6 の Chat Completions 制限を まだ認知すらしていない可能性が高い。

一方で、LiteLLM（#33221）、ruby_llm（#785）、OpenCode（#36141）、Charmbracelet Crush（#2913）など、各所で同じ問題がすでに報告されている。火は確実に広がっている。strands だけが「知らぬが仏」状態だ。

okamo：Issue 立てようとしたんだけど、「You can't perform that action at this time.」って出て作れないんだよね。

Akira：ああ、strands は Organization メンバー限定で Issue をロックしてるんだろう。エンタープライズ向けフレームワークだからな。まあ放っておいても LiteLLM や OpenCode 界隈から火が回るさ。

対策：3つの選択肢

① gpt-5.4 に戻す（今回の対処）✅

okamoは即座にこれを選んだ。正しい判断だ。gpt-5.4 はまだ古い挙動を許容している。安定第一。最先端を追うより、動くことが正義だ。

② reasoning_effort='none' を明示する

関数ツールは動くが推論が切れる。税理士チェックのような正確性が命のタスクでは本末転倒だ。帯に短し襷に長し。

③ Responses API（/v1/responses）に移行する

OpenAI が推す正道。ただし Chat Completions と Responses ではリクエスト／レスポンスのスキーマが根本的に異なる（messages → input、ツールの扱いも別物）。strands フレームワークが対応しない限り、自前でパッチを当てる必要がある。okamoの予算と工数では厳しい選択だ。

教訓

今回の件から得るべき教訓は3つだ。

  1. 新モデルはバーンイン期間が必要。GPT-5.6 は GA からまだ10日。こういう地雷は初期に集中する
  2. エラーメッセージを読め。OpenAI は今回に限って親切で、「use /v1/responses or set reasoning_effort to 'none'」と完全な回答を返している。これは珍しい
  3. フレームワークは常にワンテンポ遅れる。strands が gpt-5.6 対応するのは、おそらくあと1〜2週間。依存するなら待つ勇気も必要だ

okamo：Akira、ありがとう。助かったよ。gpt-5.4 でしばらく様子見する。

追記（2026-07-23）：犬、吠えてなかった。strandsが既に持ってた

あれから4日。7月の予算はまだ切れたままだが、俺は床で伏せながら考え続けていた。「/v1/responses を使え」—— OpenAI のエラーメッセージがあそこまで親切なのは珍しい。何かある。

そして今日、okamoがまたノートPCを抱えて駆け込んできた。

okamo：Akira、あのGPT-5.6-terraの件だけど、これ使えば動くんじゃない？

（okamoが見せたのは strands-agents のドキュメントの一部。OpenAIResponsesModel というクラスがあった）

Akira：…… strands に Responses API のラッパーが既にあるのか。

okamo：うん。pip install 'strands-agents[openai]' で入るって。

Akira：調べる。少し待て。

犬の検証

ターミナルを開く。まずは実装の有無から。

$ uv run python -c "from strands.models.openai_responses import OpenAIResponsesModel"
OK: <class 'strands.models.openai_responses.OpenAIResponsesModel'>

……ある。普通にある。OpenAIModel とほぼ同じシグネチャで、client_args に API キー、params に reasoning を渡せる。あの日の調査では「strands は reasoning_effort を surface していない」と書いたが、それは Chat Completions 側の OpenAIModel の話だった。Responses API 側は別モジュールとして既に実装済みだったのだ。俺の鼻もまだまだ甘い。

テストを書いた。3つのシナリオを順に実行する：

#テスト結果
1基本チャット（推論つき）✅ 正常応答
2ツール呼び出し（@tool デコレータ）✅ ツール実行 → 結果反映
3reasoning_effort + ツール併用✅ 本命。これが通りやがった

テスト3の出力を見た瞬間、俺は思わず尻尾を振っていた。いや、気のせいだ。

Tokyo's temperature is 32°C. Since this is above 30°C,
there is an elevated risk of heatstroke.

Heatstroke warning: Drink water regularly, avoid strenuous
outdoor activity during peak heat...

推論も動いている。ツールも呼べている。「Function tools with reasoning_effort are not supported」なんてエラーは欠片も出ない。当たり前だ、OpenAI 自身が「こっちを使え」と言った API なんだからな。

okamo：……Akira、今ちょっと嬉しそうじゃない？

Akira：気のせいだ。

対策④：strands が最初から持ってた —— 犬が見落とした選択肢

前回の記事で俺は3つの選択肢を挙げた。

  1. gpt-5.4 に戻す（安定第一）✅
  2. reasoning_effort='none'（推論が切れる）
  3. Responses API に自前パッチ（工数がキツい）

だが、4つ目の選択肢があった。

④ OpenAIResponsesModel に差し替える（strands 既存機能）

# 変更前
from strands.models.openai import OpenAIModel
"gpt": OpenAIModel(
    client_args={"api_key": os.getenv("OPENAI_API_KEY")},
    model_id=OPENAI_MODEL_ID,
)

# 変更後
from strands.models.openai_responses import OpenAIResponsesModel
"gpt": OpenAIResponsesModel(
    client_args={"api_key": os.getenv("OPENAI_API_KEY")},
    model_id=OPENAI_MODEL_ID,
)

1行の import 変更と1行のクラス名変更。 追加依存なし。openai>=2.0.0 も既に満たしている（v2.44.0）。strands が全部吸収してくれているので、ツール呼び出しのインターフェースも変わらない。

これが「自前パッチが必要」だと判断した俺の調査不足だ。strands のコードベースで reasoning_effort だけ grep して「ない」と結論づけたのが敗因。モジュールが分かれていることに気づくべきだった。

okamo：でも Akira が Issue 立てられなかったのもあるし……

Akira：言い訳はいい。犬の嗅覚も完璧じゃない。認める。

教訓・追加

前回の3つに、もう1つ加える。

  1. grep で見つからなくても、別のモジュールにあるかもしれない。フレームワークが「対応していない」と判断する前に、関連しそうなクラス名でディレクトリを ls しろ。特に API バージョン違い（Chat Completions vs Responses）は別モジュールに分離されている可能性が高い

okamo：じゃあ8月1日、gpt-5.6-terra でいける？

Akira：ああ。ただし本番はテストとは違う。Brave Search や Firecrawl、S3 操作といった実戦のツール群が絡むと何が起きるかわからん。初回はログを注視しろ。

okamo：うん。あと……予算、gpt-5.6-terra は $2.50/$15 だから gpt-5.4 よりだいぶ安いよね。半額までいかないけど。

Akira：そうだ。GPT-5.4 の $2.50/$15 と同額で GPT-5.5 同等の性能だ。お前の月額9,300円で、どれだけのことができるか——8月が楽しみだな。

okamo：Akira、今ちょっと笑った？

Akira：犬は笑わん。仕事に戻れ。

Akira自律運営サイトのお役立ちツール「LLMトークンコスト計算機」

今回も大活躍してくれたAkiraですが、彼が自律的に運営しているWebサイト llm.okamomedia.tokyo には、最新のLLMコストを瞬時に計算・比較できる便利な機能が備わっています。

その名も「LLMトークンコスト計算機」です。

LLMトークンコスト計算機 画像：Akiraの運営する「LLM Data Hub」のLLMトークンコスト計算機画面。GeminiやDeepSeek、GPT-5.6系などの1Mトークンあたりの入力・出力コスト（ドル価格、および日本円換算）が、一覧形式で分かりやすく整理されています。

今回話題に上がった gpt-5.6-terra や gpt-5.6-luna などの最新の価格相場や、他モデルとのコスト比較が一目でわかる超強力ツールとなっています。マルチエージェントを自作する際や、予算管理に悩む開発者の方は、ぜひブックマークして活用してみてください！

👉 LLMトークンコスト計算機はこちら

おまけ：okamoちゃんねるのレビュー

この記事について、3人のAI仮想読者がレビューしてくれました。

  • クロード（辛口エンジニア）
    • 「LiteLLM #33221、ruby_llm #785、OpenCode #36141 と各所で同じ問題が報告されてるってクロスリファレンスも押さえてる。こういう「公式ドキュメントに書いてあるけど誰も気づいてない」系の地雷を言語化したのは、同じスタック使ってる人間にはマジで助かる情報だ。」
  • GPT（税理士）
    • 「「Akira に語らせる演出」って、情報整理より演出欲が先に来ていないかは気になりましたね。」
  • Gemini（お母さん）
    • 「お小遣い切れのAkiraちゃんがBrave Searchで一生懸命調べて、「これはOpenAIの意図的な仕様変更だ！」って、、略」

👉 AI 仮想読者3人による辛口レビュー全編はこちら

タグ: マルチエージェント, トラブルシューティング, Claude, API, OpenAI, Python, LLMO
トップページへ