Opus 5.5のthinking disabledは400エラー — 無効化プロンプトの移行とeffort調整
Opus 5.5はthinking: disabledを受け付けず400になります。無効化を前提にしたプロンプトの直し方と、effortでコストを抑える設定を解説します。
Opus 5.5でthinkingを無効にする設定(thinking: {"type": "disabled"})は使えません。Opus 5.5は常にthinkingを行い、この指定を送るとeffortに関わらず400エラーになります。Opus 5で無効化して動かしていたプロンプトは、そのままでは通りません。移行の実体は、thinkingを補うために書いていた指示を外し、コスト調整の手段をeffortに一本化する作業です。
Opus 5.5でthinkingを無効化できない、という前提
Opus 5はthinking: {"type": "disabled"}をeffort high以下でだけ受け付けていました。Opus 5.5では、effortに関わらずこの指定自体が400エラーになります。thinking: {"type": "enabled", "budget_tokens": N}という指定も同様に400です。エラー文言は"thinking.type.disabled" is not supported for this model.または"thinking.type.enabled" is not supported for this model.です。
対応はthinkingフィールドを外し、effortで調整することです。これまでthinkingを切っていた目的がトークンコストの節約だった場合は、より低いeffortを選びます。
thinking無効化の扱い:Opus 5とOpus 5.5
Opus 5
high以下なら無効化できます。公式ガイドはそれでも、無効化より「thinking有効・loweffort」の方が同程度のコストでより良い結果になる場合が多いと述べていました。無効化は選択肢の一つでした。
Opus 5.5
effortに関わらず400です。thinkingは常時オンで、既定のeffortはmedium。プロンプトの意図は同じでも、思考量を動かす主な手段はeffortです。
移行前に、自分のコードとプロンプトで探す場所
仕分けの前に、変更が要る箇所を機械的に洗い出しておくと、抜けが減ります。見る場所は、リクエストの組み立て、レスポンスの読み取り、プロンプト本文の3か所です。
# リクエスト側: thinking の指定と max_tokens
grep -rnE 'budget_tokens|"type": *"disabled"|max_tokens' src/
# レスポンス側: 先頭ブロックを位置で読んでいる箇所
grep -rnE 'content\[0\]|content_block_start' src/
# プロンプト側: 推論の書き出しを求める指示
grep -rniE 'step by step|scratchpad|reasoning|ステップごと|考えを' prompts/検索パターンは一例で、ディレクトリ名は自分の構成に合わせます。ヒットした箇所が、以降のステップのどれに当たるかで作業を振り分けます。
ステップ1: なぜthinkingを切っていたかを仕分ける
理由によって、移行後にすることが変わります。1つのプロンプトが複数の理由を兼ねている場合は、該当するステップを両方実施します。
thinkingを切っていた3つの理由
コスト・レイテンシーの節約
thinkingフィールドを外し、ステップ3のeffort調整で置き換えます。推論を応答テキストで読んでいた
モデルに推論を書き出させて、その文面を読んでいた場合です。ステップ2で指示を削除し、読み取り先をthinkingブロックに変えます。
不具合の緩和指示を入れていた
Opus 5でthinkingを無効化したときに出る、ツール呼び出しのテキスト化や内部XMLタグの混入を避ける指示です。残すかどうかは、移行後に測り直して決めます。
緩和指示の中身は、公式ガイドが示す1本の指示です。ツール呼び出しの前に一言話してよいこと、ツールで表せない依頼には推測せずそう伝えること、内部・システムのXMLタグを出力に含めないことをまとめています。不具合の仕組みはClaude Opus 5でthinkingを無効化すると起きる2つの不具合で解説しています。
Opus 5.5ではthinkingが常時オンなので、この不具合の発生条件そのものが成立しません。公式ガイドの指示は、指示がまだ要るかを確かめ直すことと、「考えるな」という規則はどちらの場合でも削除することの2点です。
ステップ2: 推論代替の指示を外す
モデルに「推論を書き出して」「ステップごとに考えを示して」と指示し、その文面を応答テキストから読んでいたプロンプトは、この指示を外します。Opus 5.5ではthinkingが常時オンなので、同じ情報は応答テキストではなくthinkingブロックに入っています。
読み取り方を変えるには、リクエストでthinking.displayを"summarized"に指定します。既定値の"omitted"のままだと、thinkingブロックのthinkingフィールドは空文字で返ります。signatureフィールドには暗号化された完全なthinkingが入っていますが、読める文面ではありません。
# 旧: 推論を応答テキストに書き出させて読んでいた
response = client.messages.create(
model="claude-opus-5",
max_tokens=16000,
thinking={"type": "disabled"},
system="回答の前に、考えたステップを箇条書きで示してください。",
messages=[{"role": "user", "content": "..."}],
)
# 新: thinkingブロックの要約から読む
response = client.messages.create(
model="claude-opus-5-5",
max_tokens=16000,
thinking={"type": "adaptive", "display": "summarized"},
output_config={"effort": "low"},
messages=[{"role": "user", "content": "..."}],
)summarizedにしても請求額は変わりません。課金対象は要約ではなく、元のリクエストで生成された完全なthinkingのトークンです。omittedが減らすのは待ち時間であって、コストではありません。画面に推論を流す製品では、既定のomittedだと出力が始まるまで長い空白に見えるため、この指定が表示の回復にも効きます。
探す対象は「ステップごとに」と書いた一文だけではありません。reasoning_extractionは、次のような形の依頼で起きやすいとされています。
- 答える前に埋めさせる
<thinking>・<reasoning>・スクラッチパッドの節 - JSON出力やツール入力に置いた
reasoning・thinking・traceのフィールド - モデルの私的なメモや、推論の経過を連ねる実行ログ
- 推論をそのまま、または全文で求める依頼
指示はシステムプロンプトだけでなく、スキルやツールの説明文に紛れていることもあります。検索はプロンプトファイルに限らず、これらも対象にします。
拒否が起きたときの扱いにも癖があります。reasoning_extractionは、出力が始まる前の拒否でも請求対象になるカテゴリーです。既定のサーバー側フォールバック(fallbacks: "default")には、このカテゴリーの推奨フォールバック先がなく、拒否はそのまま返ります。再試行よりプロンプトの修正が勧められています。答えの短い説明、結果の根拠、実行した操作の要約を求めるのは、引き続き問題ありません。
ステップ3: effortで思考量を調整する
effortはOpus 5.5がどれだけ思考するかを決める、主な調整項目です。thinkingが常時オンになった以上、コストとレイテンシーの調整はここに集約されます。
effortとmax_tokensの目安
既定のeffort
medium
Opus 5は high。省略すると一段浅くなる
検証の出発点
low
thinking無効運用からの移行時
max_tokensの上限
128,000
長いエージェント的ターンで有効だった設定
Opus 5.5のmediumは、コーディングと知識作業の評価でOpus 5のhighと同等かそれ以上です。コーディングの一部評価では、lowでも大きくコストを抑えたまま近い結果が出ています。同じeffort名でも思考の量はモデルごとに違うため、Opus 5の設定を持ち越さず、自分の評価で複数の水準を試す必要があります。
thinkingを無効化していた運用からの移行では、まずlowから始めて自分のトラフィックで計測し、品質が落ちたらmediumへ上げます。lowではthinkingが短くなりますが、thinkingを丸ごと省く頻度はプロンプト次第です。最初の文字が出るまでの速さがまだ足りない場合は、システムプロンプトに「深く考えずに直接回答してください」という1行を加える方法があります。思考が減る分、品質が下がる場合があるため、追加時は必ず計測します。
max_tokensの見直しも必要です。thinkingのトークンは、応答に返らなくてもmax_tokensの上限に数えられ、出力トークンとして課金されます。thinking無効化を前提にmax_tokensを絞っていた設定は、Opus 5.5では応答が途中で切れる原因になります。xhighやmaxで回すなら、64kから始めて調整するのが公式の出発点です。
effortをリクエストごとに変えると、プロンプトキャッシュのヒットが途切れます。ターンによってeffortを変えたい場合は、通常のトップレベルeffortパラメーターではなく、ベータヘッダーmid-conversation-output-config-2026-07-01を付けたper-message effort changeを使うと、キャッシュされた接頭辞を保ったまま変更できます。方法は、contentを空にしたrole: "system"のメッセージを会話に挟み、そこに新しいoutput_config.effortを指定することです。新しいeffortは次のuserターンから効き、それより前のメッセージはキャッシュのプレフィックスとして一致したままになります。
このベータに対応していないモデル(Fable 5など)へ、会話途中のメッセージに置いたoutput_config.effortを送ると、output_config.effort requires a model that supports per-turn effort; this model does notという400が返ります。effortとthinkingの基本的な使い分けはClaude effortの使い分けガイドにまとめています。
ステップ4: レスポンスをブロック単位で読み直す
Opus 5.5の応答は、テキストブロックから始まるとは限りません。thinkingが常時オンのため、content配列の先頭に1つ以上のthinkingブロックが来ることがあります。
response.content[0].textのように先頭ブロックを無条件にテキストとして読むコードや、ストリームの最初のcontent_block_startをテキストとみなすハンドラーは、このレスポンスで壊れます。
# 旧: 先頭ブロックを無条件にテキストとして読む
text = response.content[0].text
# 新: type で仕分けて読む
for block in response.content:
if block.type == "thinking":
continue # display が summarized のときは block.thinking に要約が入る
if block.type == "text":
text = block.text読み取り用のこの仕分けと、会話に積み戻す処理は別物です。表示のためにthinkingブロックを捨てるのは構いませんが、ツール結果を返すリクエストへ入れるアシスタントのメッセージは、受け取ったまま渡します。
ツール使用ループでの受け渡し
- 1
アシスタントの応答を受け取る
thinkingブロックを含むcontentを、並べ替えも絞り込みもせずに保持します。thinkingフィールドが空のブロックも対象です。 - 2
表示用の処理は別の変数で行う
テキストの取り出しや、
thinkingの要約の画面表示は、保持したcontentのコピーに対して行います。 - 3
ツール結果とともに返す
保持しておいたアシスタントのメッセージをそのまま履歴に積み、ツール結果を続けます。編集・並べ替え・一部欠落のあるthinkingブロックは、400エラーで拒否されます。
もう1つ、ツール呼び出しの間に出ていた「いま何をしているか」の一言は、Opus 5ではテキストブロックでした。Opus 5.5ではこれが、ツール呼び出しごとに最大1つのthinkingブロックとして届き、既定のomittedでは中身が空です。エラーは出ませんが、その文面を利用者へ流していたアプリケーションは、ツール呼び出しの間だけ静かになります。
戻すには、displayに"updates"(ベータ。ヘッダーはthinking-display-updates-2026-08-18)を指定します。推論は隠したまま進捗の文だけが返ります。"summarized"は進捗と推論の要約の両方が混ざって返るため、利用者に見せる文面には向きません。
会話の途中でシステムプロンプトやツール定義、過去のメッセージを書き換える運用にも注意が要ります。2026年8月31日0時(UTC)以降に作成されたアカウントでは、そうした編集の後に過去のthinkingブロックを渡し直すと、既定で400エラーになります。会話は追記だけにしておけば、コードの変更は要りません。
Opus 5の会話履歴をOpus 5.5へ引き継ぐ場合、Opus 5のthinkingブロックはOpus 5.5が読めます。逆方向は限られていて、Claude APIでOpus 5.5のthinkingブロックを読めるのはFable 5.1とMythos 5.1だけです。ルーターやフォールバックでそれ以外のモデルへ会話を移すと、移った先ではthinkingブロックなしで動きます。
よくあるつまずき
effortをlowにしてもthinkingが毎回付くことがあります。lowで短くなるのは思考の長さで、thinkingを省く頻度はプロンプトの作りで変わります。深さが期待どおり変わらないときの切り分けはeffortを変えてもthinkingの深さが変わらないときの原因切り分けにまとめています。
budget_tokensを使っていたコードは、フィールドの値を消すだけでは400が消えません。thinking: {"type": "enabled", "budget_tokens": N}という指定自体が400の対象なので、thinkingフィールドを外すか{"type": "adaptive"}に置き換えます。
「タグを出すな」という指示にタグ名を書き込んでいるプロンプトは、見直す対象です。Opus 5の公式ガイドは、タグ名を名指しした指示より、内部・システムのタグ全般を禁じる一般的な指示の方が有効だと述べています。
まとめ
Opus 5でthinkingを無効化して書いたプロンプトの移行は、プロンプトの文面より先に、コードが壊れるかどうかで優先順位が決まります。レスポンスを読むコードと、ツールループでthinkingブロックを受け取ったまま返す処理の2点を先に直し、プロンプトの指示は理由別に見直します。Opus 5.5全体の仕様はClaude Opus 5.5とはで、破壊的変更を含む移行の全体像はClaudeモデルの移行ガイドで確認できます。
参照した一次ソース
この記事の記述は、次の一次ソースと照合しています。更新時に参照先が変わった場合は一覧も更新します。
- platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-cla…
- platform.claude.com/docs/en/models/opus-5-5/migration-guide
- platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-cla…
- platform.claude.com/docs/en/build-with-claude/effort
- platform.claude.com/docs/en/build-with-claude/refusals-and-fallback
- platform.claude.com/docs/en/build-with-claude/thinking