Claude Opus 5でthinkingを無効化すると起きる2つの不具合

Opus 5でthinkingを切ると何が起きるか

Claude Opus 5はthinking(アダプティブシンキング)が既定でオンです。Opus 4.8やOpus 4.7ではthinkingを省略すると思考なしで動いていたので、省略時の挙動が前世代と逆になっています。

thinking: {type: "disabled"}が通るのは、effortがhigh以下のときだけです。xhighやmaxと組み合わせると400になります。

この構成にすると、2つの不具合が時々現れます。どちらもエラーを出さずに起きるので、ログを見ていても気づけません。

症状から原因を切り分ける

エージェントが「検索したはずなのに結果がない」まま話を進める、あるいは画面にタグが出る。運用中に見えるのはこうした症状です。

不具合1が厄介なのは、影響がそのターンで終わらないことです。テキストになった偽の呼び出しは会話履歴に残り、後続のターンでもモデルがそれを参照します。検索クエリを本文に書き出したまま次のターンへ進めば、モデルは「呼んだのに結果が返らない」状態から続きを組み立てます。

不具合2は、応答をそのまま画面に流す実装で表に出ます。人が読まない自動化パイプラインでは、発見が遅れます。

呼び出し側で網を張るなら、ツールを渡したのにtool_useが1つも無いターンを拾う方法があります。次のPythonは筆者が書いた検知の一例で、実際の不具合を再現して確かめたものではありません。

import re
 
TOOL_NAMES = {"web_search", "get_weather"}  # 自分のツール名に置き換える
XML_LEAK = re.compile(r"</?(thinking|scratchpad|system)\b", re.I)
 
def check_turn(resp, tools_given: bool) -> list[str]:
    text = "".join(b.text for b in resp.content if b.type == "text")
    used_tool = any(b.type in ("tool_use", "server_tool_use") for b in resp.content)
    problems = []
    if tools_given and not used_tool and any(n in text for n in TOOL_NAMES):
        problems.append("ツール呼び出しがテキスト化した疑い")
    if XML_LEAK.search(text):
        problems.append("内部タグの混入")
    return problems

Anthropic提供のサーバーツール(検索など)の呼び出しはserver_tool_useブロックで返るので、判定に含めています。ツール名が本文に出ただけの正常な説明文も拾うので、検知したら履歴へ積む前にターンを捨てて再試行する、といった扱いになります。タグ名の正規表現は例示です。

不具合の原因はどこまで分かっているか

公式ドキュメントは仕組みまでは説明していません。確認できるのは、2つの症状がthinkingを無効化した状態で報告されているという点までです。

Sonnet 5の側にも近い記述があります。thinkingを無効化するとツールへ手を伸ばす頻度や検索を検討する頻度が下がり、ツールに頼る運用ではシステムプロンプトで明示的に促すよう書かれています。ファミリー全体で、thinkingの有無がツール呼び出しの挙動に効いている形です。同じドキュメントは、effortもツール使用量のつまみだと書いています。highやxhighでは、検索やコーディングのエージェント作業でツール使用が大きく増えます。thinkingを切ったうえでeffortまで下げる構成は、ツールを使う頻度の面で二重に不利になると考えられます。組み合わせた効果までは、公式に書かれていません。

effortとthinkingの組み合わせは用途でも変わります。Computer Useのような視覚系タスクの推奨値はComputer Useのeffort推奨値にあります。

回避策は「切らない」が最優先

両方の不具合に共通する第一の緩和策は、thinkingを有効なまま残し、トークンコストをeffortの引き下げで抑えることです。ドキュメントには、多くのタスクでloweffortのthinking有効が、同程度のコストのthinking無効より良い結果になるとあります。

effort 5段階の使い分けはClaude effortの使い分けガイドにあります。thinkingを切りたくなったら、先にeffortをlowやmediumへ下げられないかを見ます。

無効化をやめるときに直すコード

thinkingを残す方針に切り替えるとき、変えるのはthinkingとeffortの2行です。あわせてmax_tokensを見直します。max_tokensは思考と応答テキストの合計に掛かる上限なので、thinkingなしを前提に詰めていた値だと、応答が途中で切れることがあります。

resp = client.messages.create(
    model="claude-opus-5",
    max_tokens=16000,                        # 思考ぶんの余裕を見込む
    thinking={"type": "adaptive"},           # 省略しても同じ
    output_config={"effort": "low"},         # コストはここで抑える
    tools=tools,
    messages=messages,
)

effortの検証はリクエストごとに走ります。会話の途中でeffortをxhighへ上げる実装でdisabledを送り続けていると、それまで通っていた続きのリクエストが400になります。

thinkingの設定を切り替えるタイミングにも決まりがあります。ツールを呼んで結果を返す途中でthinkingを切り替えても、APIはエラーにしません。代わりに、そのリクエストのthinkingを黙って無効にします。disabledからadaptiveへ移すなら、アシスタントのターンが終わったあとの次のリクエストで変えます。thinkingが動いたかどうかは、応答にthinkingブロックがあるかで確かめられます。

effortを会話の途中で変えたい場合、Opus 5はメッセージ単位のeffort変更(ベータ)に対応しています。ベータヘッダーmid-conversation-output-config-2026-07-01が必要で、プロンプトキャッシュが保たれます。トップレベルのeffortを次のリクエストで変えると、キャッシュ済みの接頭部は使えなくなります。

思考の文章を見せたくないだけなら、displayで足りる

応答にthinkingの文章を出したくないという目的でも、無効化は必要ありません。thinkingの設定にあるdisplayフィールドが、思考の要約を返すかどうかを決めます。"omitted"ではthinkingブロックのthinkingフィールドが空で返り、Opus 5ではこれが既定です。要約を見たいときだけ"summarized"を指定します。

omittedでもブロックの課金は変わらず、signatureに暗号化された思考が入ります。複数ターンの会話では、このブロックを変更せずそのまま戻します。ストリーミングでは思考の文字が流れないので、最終テキストの出始めが早くなります。

displayをdisabledと同時に送ると不正な指定になります。表示する対象が無いためです。

なお、displayが決めるのはthinkingブロックの返し方です。不具合2で本文に出る<thinking>タグは別の現象で、displayの設定の対象ではありません。

ナレーションを減らしたいなら、thinkingではなくプロンプトで調整する

エージェント作業中の実況(ナレーション)が多いことも、Opus 5の特徴です。何をするかを先に告げ、1メッセージあたりの出力も前世代より長くなりがちです。

公式が挙げている調整手段は、更新の頻度と形をプロンプトで具体的に書くことです。thinkingの設定はこの調整手段に含まれていません。ナレーション削減だけが目的なら、無効化に伴う2つの不具合を負う理由がありません。望む書き方の例を示す方が、書いてほしくないことを並べるより効くとも書かれています。

thinkingを切るときの緩和指示

どうしてもthinkingを無効化したまま運用する場合、2つの不具合を同時に和らげる単一の指示文があります。

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-opus-5",
    "max_tokens": 16000,
    "thinking": {"type": "disabled"},
    "output_config": {"effort": "high"},
    "system": "When you use a tool, you may say a brief sentence first. If no tool can express what the user asked for, say so instead of guessing. Do not include internal or system XML tags in your response.",
    "messages": [{"role": "user", "content": "..."}]
  }'

注意点が1つあります。<thinking>のような具体的なタグ名を名指しで禁じる指示は、一般形の指示より効果が薄いとされています。「内部・システムのタグを含めない」という一般則にとどめる方が有効です。

モデル世代ごとのdisabledの扱い

thinkingを省略したときの既定と、disabledが通るかどうかは、モデルごとに違います。

Opus 4.8や4.7からOpus 5へ上げるコードでは、thinkingを何も指定していなかった箇所が、意図せずthinking有効の挙動に変わります。移行の前に、既存コードのthinkingとeffortの組み合わせを洗い出しておきます。

Sonnet 5.5では、Sonnet 5で通っていたdisabledが400になります。最小設定のbetween_toolsはhigh以下のeffortでのみ受け付けられ、xhighとmaxではbetween_toolsも400です。詳しくはClaude Sonnet 5.5の解説にあります。

Opus 5.5では不具合の前提ごと消える

Claude Opus 5.5はAdaptive Thinkingが常時オンで、thinking: {"type": "disabled"}はeffortに関係なく400です。エラー文は"thinking.type.disabled" is not supported for this model.で始まります。

Opus 5のこの2つの不具合は「thinkingを切ったとき」だけの話なので、Opus 5.5では切る選択肢が無く、同じ形では踏めません。一方で、disabledを送っていた実装はそのままでは動かなくなります。直し方はthinkingを省略するか{"type": "adaptive"}にして、深さをeffortで決める形です。

応答の先頭にthinkingブロックが付くことがあるので、本文を先頭要素の位置で拾っていたコードも直します。typeがtextのブロックを選ぶ書き方にしておけば、ブロックの並びが変わっても影響を受けません。

Sonnet 5のドキュメントにも同じ方向の助言があります。Sonnet 4.6でthinkingを切っていたなら、thinkingを入れて低いeffortを試す、という内容です。モデルごとのドキュメントで、コスト調整はeffortで行うという同じ方向の助言が繰り返されています。

移行の全体像はClaude Opus 5.5の解説に、thinkingを切る前提で書いたプロンプトの直し方はClaude Opus 5.5でthinking無効のプロンプトを移行するにあります。

Opus 5の仕様全体はClaude Opus 5の使い方と仕様で確認できます。

まとめ

Opus 5で本当にthinkingを切る必要があるのは、effortを下げても満たせない制約があるときだけです。それ以外はthinkingを残してeffortで調整すれば、2つの不具合は踏みません。切る場合は、tool_useの有無とタグの混入を呼び出し側でも検知しておくと、静かな失敗を拾えます。