Claude Opus 5.5でthinking無効のプロンプトを移行する — 代替指示を外しeffortで調整

Claude Opus 5でthinkingを無効化して動かしていたプロンプトは、Claude Opus 5.5ではそのまま使えません。Opus 5.5はthinking: {"type": "disabled"}を受け付けず、リクエストは400エラーになります。移行の実体は、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ブロックから始まるようになるため、コンテンツブロックをtypeで選び、ツール結果を返すときはthinkingブロックをそのまま渡します。

ここで見落としやすいのが、Opus 5では「thinkingを切ってeffortで代替する」という選び方が推奨の一つに過ぎなかった点です。Opus 5の公式ガイドは、thinkingを無効化する代わりにthinking有効・loweffortで運用する方が、同程度のコストでより良い結果になる場合が多いと述べています。無効化はコストを抑える手段の一つであり、選択の余地がありました。Opus 5.5ではその選択の余地自体がなくなり、thinkingは常時オンです。プロンプト側の意図は変わらなくても、達成手段はeffort一本に絞られます。

ステップ1: なぜthinkingを切っていたかを仕分ける

移行作業を始める前に、thinkingを無効化していた理由を仕分けます。理由によって、移行後にすることが変わるからです。

主な理由は3つに分かれます。

• コスト・レイテンシーの節約が目的だった場合は、ステップ3のeffort調整だけで置き換えられます
• モデルに推論を書き出させて、その文面を読んでいた場合は、ステップ2の指示削除と読み取り方法の変更が必要です
• Opus 5でthinkingを無効化したときに出ていた不具合(ツール呼び出しのテキスト化や内部XMLタグの混入)を避けるための緩和指示を入れていた場合は、ステップ2でその指示自体の必要性を再検証します

この2つの不具合の仕組みはClaude Opus 5でthinkingを無効化すると起きる2つの不具合で解説しています。thinkingが常時オンのOpus 5.5では、この不具合の発生条件(thinking無効化)そのものが成立しないため、緩和指示を残す効果は移行後に測り直す対象になります。1つのプロンプトが複数の理由を兼ねていることも多く、その場合は該当するステップを両方実施します。

ステップ2: 推論代替の指示を外す

モデルに「推論を書き出して」「ステップごとに考えを示して」と指示し、その文面を応答テキストから読んでいたプロンプトは、この指示を外します。Opus 5.5ではthinkingが常時オンなので、同じ情報は応答テキストではなくthinkingブロックに入っています。

読み取り方を変えるには、リクエストでthinking.displayを"summarized"に指定します。既定値の"omitted"のままだと、thinkingブロックの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": "..."}],
)

もう1点、reasoning_extractionという拒否カテゴリーがOpus 5.5で新設されています。応答テキストに内部推論をそのまま再現させようとする指示は、このカテゴリーで拒否される場合があります。「考えた過程をそのまま書いて」という指示を残すこと自体が拒否を招くリスクになるため、この指示は削除する対象です。

ステップ3: effortで思考量を調整する

effortはOpus 5.5がどれだけ思考するかを決める、唯一の直接的な調整項目です。thinkingが常時オンになった以上、コストとレイテンシーの調整はここに集約されます。

Opus 5.5の既定effortはmediumです。Opus 5の既定はhighだったため、effortを省略していたリクエストは、Opus 5.5では自動的に一段浅い思考で走ります。Anthropicの計測では、Opus 5.5のmediumはコーディングと知識作業のベンチマークでOpus 5のhighと同等かそれを上回り、コーディングの一部評価ではlowでも大きくコストを抑えたまま近い結果が出ています。

thinkingを無効化していた運用からの移行では、まずlowから始めて自分のトラフィックで計測し、品質が落ちたらmediumへ上げます。応答の最初の文字が出るまでの速さがまだ足りない場合は、システムプロンプトに「深く考えずに直接回答してください」という1行を加えると、さらに思考を減らせます。この1行を加えると品質が下がる場合があるため、追加時は必ず計測します。

max_tokensの見直しも必要です。thinkingのトークンは、応答に返らなくてもmax_tokensの上限に数えられます。thinking無効化を前提にmax_tokensを絞っていた設定は、Opus 5.5では応答が途中で切れる原因になります。長いエージェント的なターンでは、モデルの上限である128,000まで確保する運用がAnthropicの検証でうまく機能しています。

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配列の先頭にthinkingブロックが来ることがあります。

thinkingを無効化していたコードは、多くの場合response.content[0].textのように先頭ブロックを無条件にテキストとして読んでいます。この読み方はOpus 5.5では、先頭がthinkingブロックだった場合に空文字を読んでしまうか、想定と違う型のオブジェクトを扱うことになります。

# 旧: 先頭ブロックを無条件にテキストとして読む
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ブロックは変更せずそのまま次のリクエストに含めて返します。会話の途中でsystemやツール定義、過去のメッセージを書き換えると、それ以降のthinkingブロックが無効になり、条件によっては400エラーの原因になります。

旧instructionと移行後の対応表

thinking無効化前提のプロンプトに残っている指示は、パターンごとに対応が決まっています。仕分けが終わっていれば、この表で該当行を当てるだけで対応できます。

よくあるつまずき

effortをlowにしても思考が全く減らないことがあります。プロンプトの作り込みによって思考量は変わるため、lowでも一定の思考が残る設計はあり得ます。深さが期待どおり変わらないときの切り分けはeffortを変えてもthinkingの深さが変わらないときの原因切り分けにまとめています。

budget_tokensを使っていたコードは、フィールドの値を消すだけでは400が消えません。thinking: {"type": "enabled", "budget_tokens": N}という指定自体が400の対象なので、thinkingフィールドを外すか{"type": "adaptive"}に置き換えます。

effortを毎ターン変えてキャッシュ効率が落ちる場合があります。通常のeffortパラメーターでの変更はキャッシュを無効化するため、ターンごとに変えたいならper-message effort changeを使います。

「タグを出すな」という指示を残したままthinkingを有効化しても、効果が薄いままのことがあります。Opus 5の旧ガイドは、タグ名を名指しした指示より、内部・システムのタグ全般を禁じる一般的な指示の方が有効だと述べています。名指しの指示をそのまま残すと、意図した効果が出ない点に注意します。

まとめ

Opus 5でthinkingを無効化して書いたプロンプトは、Opus 5.5では動作の前提から変わります。推論代替の指示を外し、thinkingブロックの読み取り方をdisplay: "summarized"かブロックタイプの分岐に変え、コスト調整はeffortに一本化します。既定effortはmediumで、lowから検証を始めるのが安全な順序です。Opus 5.5全体の仕様はClaude Opus 5.5とはで、破壊的変更を含む移行の全体像はClaudeモデルの移行ガイドで確認できます。