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

Opus 5はthinkingが既定でオン、無効化には条件がある

Claude Opus 5は、Opus 4.8やOpus 4.7とは異なり、thinking(思考ブロックを使ったアダプティブシンキング)が既定でオンになって動きます。thinkingパラメーターを省略した場合の挙動が前世代と逆転している点は、移行時に見落としやすいポイントです。

thinkingを明示的に無効化するthinking: {type: "disabled"}は、effortがhigh以下のときだけ受け付けられます。xhighやmaxと組み合わせてdisabledを送るとエラー(400)になります。つまりOpus 5でthinkingを切る運用は、最初から選択肢が絞られた構成です。

thinkingを無効化した状態では、2つの不具合が時々現れます。どちらも「エラーにはならないが、動作がおかしくなる」型の不具合で、気づかないまま本番運用に乗ってしまうリスクがあります。

不具合1: ツール呼び出しがテキストとして漏れる

thinkingを無効化した状態では、Opus 5がツール呼び出しを構造化されたtool_useブロックではなく、ユーザー向けのテキストとして書いてしまうことがあります。

この不具合の厄介な点は、エラーが一切発生しないことです。ターンは正常に完了し、stop_reasonも通常どおり返ります。しかし実際にはツールは一度も実行されておらず、呼び出すはずだった内容がテキストとして応答に混ざるだけです。

エージェントループでこの不具合が起きると、影響は1ターンで終わりません。テキスト化された偽のツール呼び出しはそのまま会話履歴に残り、次のターン以降もモデルがそれを参照し続けます。この現象は、ツールを多用するワークロード、特に検索のようなツール呼び出しの多い処理で最も起きやすくなります。

不具合2: 内部XMLタグが可視応答に混入する

もう1つの不具合は、thinkingを無効化した状態で<thinking>タグなどの内部XMLタグが、そのままユーザーに見える応答へ漏れ出すというものです。

原因として名指しされているのが、システムプロンプト側の指示です。「考えるな」「推論するな」といった、モデルに思考を禁止するルールをシステムプロンプトに含めていると、このタグ漏れが悪化すると明記されています。thinkingを切るために「考えないで」と念押しした結果、かえって不具合が増える、という逆効果です。

なぜこの2つが起きるか — thinkingを切ると失われるもの

公式ドキュメントは原因の仕組みまでは説明していませんが、2つの不具合はいずれもthinkingを無効化した状態でだけ報告されている点が共通しています。Opus 5は既定でthinkingを使う設計であり、thinkingを丸ごと切ったときにだけ、ツール呼び出しのテキスト化と内部タグの混入という2つの症状が現れる、というのが確認できる事実です。

Sonnet 5側のドキュメントにも近い記述があります。Sonnet 5はthinkingを無効化すると、ツールへ手を伸ばしたり検索を検討したりする頻度自体が下がる、という記述です。モデルファミリ全体で見ても、thinkingの有無がツール呼び出しの挙動に直結していることがうかがえます。effortとthinkingの組み合わせ方は用途によっても変わり、Computer Useのような視覚系タスクでの推奨値はComputer Useのeffort推奨値にまとめています。

移行時に見落としやすい既定挙動の逆転

high以下という制約に加えて、もう1つ見落としやすいのが既定挙動そのものの逆転です。前世代のOpus系モデル(Opus 4.8 / 4.7)はthinkingパラメーターを省略すると無効化された状態で動いていました。Opus 5ではこの既定挙動が逆転し、省略時はアダプティブシンキングがオンになります。前世代のコードをそのまま動かすと、意図せず「thinkingが常時有効」なコードパスに変わっている、というケースが起こり得ます。

エージェントループでの実害の具体例

不具合1(ツール呼び出しのテキスト化)が特に厄介なのは、単発の応答では気づきにくい点です。たとえば検索ツールを使うエージェントが、本来ならtool_useブロックで検索クエリを送るはずが、そのクエリをテキストとして書き出してしまったとします。ツールは実行されないため検索結果は返らず、モデルは次のターンで「検索したはずなのに結果がない」状態から会話を続けることになります。会話履歴には失敗した(実行されなかった)ツール呼び出しの文面がそのまま残り、後続のターンの判断材料に混入し続けます。

不具合2(内部XMLタグの混入)も同様に、ログを人間がその場で確認しない自動化パイプラインでは発見が遅れがちです。ユーザー向けの応答に<thinking>のようなタグがそのまま表示されると、UI側でタグが素通りしてユーザーに見えてしまう、という体験上の問題に直結します。

対処法1(推奨): thinkingを切らずeffortを下げる

第一の対処は、thinkingを無効化しないことです。両方の不具合の主な緩和策は「thinkingを有効なままにして、トークンコストはeffortの引き下げで制御する」という方針で、多くのタスクではloweffortでthinking有効の方が、thinking無効化と同程度のコストでより良い結果を出す、とまで書かれています。

effortパラメーターの5段階と使い分けの基本はClaude effortの使い分けガイドで解説しています。thinkingを切る前に、まずeffortをlowやmediumへ下げる余地がないかを検討するのが安全な順序です。

対処法2: どうしてもthinkingを切る場合の緩和指示

システム上の制約でthinkingを無効化したままにする必要がある場合、両方の不具合を同時に緩和する単一の指示文があります。

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タグ」を名指しで禁止する指示は、一般的な形の指示より効果が薄いという記述です。「<thinking>タグを書くな」のように具体的なタグ名を挙げるのではなく、「内部・システムのタグを含めるな」という一般則にとどめる方が、実際には有効に働きます。

thinkingの有無と自己検証・ナレーションの関係

thinkingが有効な状態のOpus 5には、指示しなくても自分の作業を検証する性質があります。「非自明なタスクには最終検証ステップを入れる」といった明示的な検証指示は、Opus 5向けのプロンプトから外すことが推奨されています。こうした指示は前世代向けに書かれたものが多く、Opus 5では既に自律的に行っている検証と二重になり、品質を上げないままトークンを浪費するだけになるためです。

公式ドキュメントが述べているのは、thinkingが有効なOpus 5には指示なしの自己検証があるという事実と、thinkingを無効化した状態でツール呼び出しのテキスト化・内部タグ混入という2つの不具合が時々起きるという事実の2つで、両者を直接結ぶ説明はありません。ただし、thinkingを切ったまま運用する場合は、モデル側の自己検証に頼らず、呼び出し側でツール呼び出しの形式を検証する仕組みを別途持つ方が安全です。

ナレーション(エージェント作業中の実況)の量は、thinkingの有無とは別の軸で制御します。Opus 5は既定でナレーションが多めのスタイルを取るため、ナレーションを絞りたい場合はthinkingの設定とは別に、更新の頻度と形をプロンプトで具体的に指示します。

モデル世代ごとのthinking既定挙動

thinkingパラメーターを省略したときの既定挙動は、モデル世代によって異なります。移行作業では、この違いを取り違えないことが前提になります。

Opus 4.8やOpus 4.7からOpus 5へ移行するコードでは、thinkingパラメーターを何も指定していなかった箇所が、意図せず「thinking有効」の挙動に変わります。逆方向の移行でも、既存コードのthinkingとeffortの組み合わせを一度洗い出しておくのが安全です。

2つの対処法の比較

公式ドキュメントの表現をそのまま読むなら、disabledを選ぶ理由は「effortを下げるだけでは満たせない別の制約がある場合」に限られます。単純にコストを下げたいだけなら、thinkingを切らずにeffortで調整する方が、不具合のリスクを抱えずに済みます。

まとめ

Opus 5でthinkingを無効化すると、ツール呼び出しがテキストとして漏れる不具合と、内部XMLタグが応答に混入する不具合の2つが時々発生します。どちらもエラーを出さずに静かに起きるため、エージェントループでは会話履歴が汚染される形で影響が蓄積します。推奨されるのは、thinkingを切ること自体を避け、コスト調整をeffortの引き下げで行うことです。thinkingを無効化せざるを得ない場合だけ、タグ名を名指ししない一般的な緩和指示を添えます。Opus 5のモデル仕様全体はClaude Opus 5の使い方と仕様で確認できます。