Claude Opus 5 における浅い思考の問題に対する解決策

概要

Claude Code を Opus 5 に切り替えた直後から、応答の散文傾向が急に強まり、思考が浅くなる (構造化して考えられない) 変化が出ました。

調べていくと、モデルが悪いのでも rules が壊れたのでもなく、Claude 5 世代で Opus 5 に配られる本体 system prompt が大きく変わり、旧来の rules がその前提で書かれていなかったのが原因でした。

この記事は、その切り分けと、rules を新しい system prompt に合う形へ直すまでの記録です。「モデルを新世代に上げたら CLAUDE.md や rules の効きが変わった」と感じている Claude Code 利用者向けです。

困っていたこと

同一セッション・同一 rules のまま、モデルを Opus 5 へ切り替えた直後から次が起きました。

• 状況説明が、見出しも区分もないフラットな長文になる
• 原因の説明が 1 層で止まる (症状を並列に並べるだけで「なぜ」を掘らない)
• 複数案を出すときに評価軸が付かない
• 一度立てた区分や番号が、次のターンで別の区分に組み替わる
• こちらの発話に返答せず、いきなりツール実行 (作業) に入る

厄介なのは、その場で「もっと深く考えて」と促し直しても、浅い思考のまま散発的な回答が返ってくることでした。指摘を重ねても噛み合わず、ほぼ議論にならずに喧嘩になる。

単発の回答品質の問題ではなく、対話を通じた検討そのものが成立しなくなっていました。

重要な手がかり

同じ rules でも他のモデルでは起きない (この違いの詳細は末尾のおまけで扱う)。rules 側の劣化なら、どのモデルでも同じように出るはず。変えたのはモデルだけなので、「rules が前提にしている環境」の側が変わったと考えて調べ始めた。

原因: Opus 5 に配られている system promptの変化

Claude 5 世代の Claude Code は、本体 system prompt が旧世代から約 8 割削減されています。手元で Opus 5 に実際に配られている prompt を実測すると (output style 等の注入を無効化した状態で、自身の prompt を原文引用させて確認。Claude Code 2.1 系、2026-07。バージョンにより変わる可能性があります)、構成は次のとおりでした。

1. 正体と役割の宣言・セキュリティ方針 — 冒頭の前文
2. ハーネス仕様 (# Harness) — 出力は markdown として表示される、といった実行環境の説明
3. 環境情報と機能説明 (# Session-specific guidance / # Memory / # Environment / # Context management) — cwd・git 状態・モデル ID、memory や context 圧縮の仕組み
4. スコープ規律 (# Delivering work) — 依頼された範囲を勝手に狭めない・広げない
5. 訂正の作法 (# Corrections) — 訂正は簡潔に、謝罪や前置きを足さない

そして今回の症状に直結する特徴が 2 つあります。

• 特徴 1: 応答の書き方を規定する文が 1 つも無い。散文か構造か、見出しや表の使い方、簡潔さ — 旧世代の prompt に長く書かれていた応答形式の規定が、丸ごとありません。
• 特徴 2: 「まず動け」という自律方針が入った。原文から抜きます。"When you have enough information to act, act." "If you are weighing a choice, give a recommendation, not an exhaustive survey"

この 2 つの特徴で冒頭の症状を読み直すと、全部つながります。書き方の規定が無いので、モデルの素の出力傾向 — フラットな散文 — がそのまま出る。「網羅より推奨を」が評価軸の省略を後押しする。

ここで「規定が空白なら、こちらの rules が唯一の規定になって、むしろよく効くのでは」と思うかもしれません。実際は逆でした。この空白は利用者に委ねられた余白ではなく、モデルに訓練で焼き込まれた既定の動作へ委ねられたものです。lean prompt は「細かく書かなくても新世代モデルは内在化した行動に従う」という前提で削られており (後述の設計思想)、削られた規定の代わりを埋めるのは、こちらの rules ではなくモデルの学習済みの既定です。そして Opus 5の既定は、簡潔な散文で、確認より先に動く方向にありました。

こちらの旧 rules は「状況は構造で分解して書け」「複数案には評価軸を付けろ」「作業の前に返答しろ」という一般形の指示で、応答形式の規定が濃かった旧世代 prompt と並べて読まれる前提の書き方でした。prompt の文と並ぶ分にはそれで足りていましたが、訓練された既定を覆すには、書き方 (原文を名指しする具体性) も届き方 (行動の直前に届く位置) も弱すぎた。これが症状の正体で、後述の対策がちょうどこの 2 つ (書き方と届き方) に対応します。

「十分な情報が揃ったら動け」が、返答より先の作業着手を後押しする。そして、こちらの旧 rules は「状況は構造で分解して書け」「複数案には評価軸を付けろ」「作業の前に返答しろ」と、応答形式の規定が濃かった旧世代 prompt を前提に書かれていました。規定が空白になり自律方針が入った新しい prompt の下で、旧 rules は素の傾向を矯正できる書き方にも、確実に届く置き方にもなっていなかった。これが症状の正体です。

Anthropic 自身がこの削減を「lean system prompt」として changelog (v2.1.154) に載せており、背景には「新世代モデルは行動を訓練で内在化しているので、細かい指示はかえって摩擦や矛盾になる」という設計思想の転換があります。詳しい解説は Claude Code のシステムプロンプトが 80% 削減 — Fable 5 世代のプロンプト設計思想 が、一次情報は Claude Code changelog と Prompting Claude Fable 5 (公式ガイド) を参照してください。

つまり症状は「rules × そのモデルに実際に配られている prompt」の組み合わせで決まります。rules だけ見ていても原因にたどり着けません。モデル更新は本体 system prompt の更新でもある、というのが最初の教訓でした。

対策 1: 矛盾を洗い出して、原文を名指しで上書きする

まず全 rules を新しい system prompt と突き合わせ、逆のことを言っている箇所を洗い出しました。その上で、本体方針を上書きしたい rule は、本体の原文をそのまま引用して名指しで優先を宣言する形に書き直しました。

うまくいかなかった書き方から先に言うと、「複数案には評価軸を付けて書くこと」のような一般論の追記は効きません。

本体の "give a recommendation, not an exhaustive survey" と並んだとき、どちらを優先するかの手がかりがないからです。名指しなら衝突が明示され、優先が伝わります。

また、書き方の規定のようにそもそも prompt に無いものについては、上書きではなく「規定の空白をこちらの定義で埋める」指示として働きます。

もう 1 つ、発火条件の書き方も直しました。「重要な変更のときは」「本番環境と判断したら」のような条件は、モデルが自分でその分類に当てはめられなかった瞬間に不発になります。発火条件は「interrupt を受けた」「ユーザーの発話に訂正が含まれる」のような、解釈の余地がない観測へ書き換えました。

対策 2: 禁止ではなく、望ましい動きを書く

旧 rules は「〜するな」の蓄積でした。禁止は違反の検知には使えても、代わりに何をすべきかを運びません。新方針と衝突したとき、モデルには「禁止を避けつつ本体方針に従う」という抜け道ができます。そこで禁止形は、望ましい動きの記述へ変換しました。

• 変換前: 「テスト未完了の状態で commit を提案するな」
• 変換後: 「commit を提案する時は、その成果物を使う人の操作手順で動かした結果を本文に書く」

書き直した rule は、最後に次のチェックで判定しました。特にSystem Promptとぶつかる表現に関してはそこをうまく上書きする形に変えました｡

1. その rule の文だけで意味が閉じているか (適用範囲・例・判定基準が同じ場所にあるか)
2. 発火条件が観測できる事実か
3. 本体 system prompt と矛盾していないか
4. 望ましい動きが書かれているか (禁止の列挙になっていないか)
5. 判断の基準が 1 つか (場面の数え上げになっていないか)
6. 強調は本当に落とせないものだけに付いているか
7. 到達してほしい状態で書かれているか (手順やテンプレを先に埋めさせていないか)
8. 守られたかどうかを後から判定できるか

強調マーカー (IMPORTANT) も、セキュリティと承認ゲート系だけに絞りました。全部が強調されている文書は、何も強調されていない文書と同じです。

対策 3: 指示を「どの層で届けるか」を選ぶ

直すのは文面だけではありませんでした。Claude Code には指示をモデルへ届ける経路が少なくとも 4 つあり、実測すると効き方がはっきり違いました。

前提として、API は stateless なので、どの経路の内容も毎リクエスト (毎ターン) モデルへ送信されます。違いが出るのは「内容がいつ確定するか」と「prompt の中でどの位置に置かれるか = いま取ろうとしている行動からどれだけ近いか」です。

意外だったのは output style です。ドキュメント上は「system prompt を置き換える」機能ですが、セッション記録を確認すると毎ターンの attachment として配信されていました。

この output style には 2 種類の指示を書いていました。書き方 (対策 1 の名指し上書き: 構造で書く、評価軸を付ける) と、進め方 (ユーザー発話にはまず返答してから作業する) です。結果は分かれました。

書き方には改善の傾向が出た一方、進め方 — 「発話に返答せず作業に入る」癖 — は output style では止まりませんでした。この進め方の癖を最終的に止めたのは、UserPromptSubmit hook で毎発話の直後に 1 行注入する方法です。ツール実行より先に、この発話への返答 (回答、または受け止めと進め方) を本文で書くこと。

コストは wrapper 込みで 1 発話あたり約 50 token。100 発話でも 5,000 token 程度で、200K context に対して誤差です。ここから得た一般則はシンプルで、「変えたい行動の直前に、短く、毎回届ける」指示がいちばん効くということです。効かない指示の多くは、内容が悪いのではなく、行動の瞬間に手元に届いていませんでした。

効果

直した結果を、確認できた範囲で書きます。状況説明・原因説明に区分が戻る傾向。ただしセッション序盤はフラットな出力が残ることがあり、継続観察中

「返答せず作業に入る」癖は、output style 単独では直らず、毎発話注入の導入で止まった (導入直後のため効果は観察中)

まとめ

• モデル更新は、本体 system prompt の更新でもある。応答の傾向が急に変わったら、rules を足す前に本体側の変化を読む
• 本体方針と張り合う rule は、原文を名指しして優先を宣言する。一般論の追記は矛盾の中で負ける
• 発火条件は観測で書き、禁止ではなく望ましい動きを書く。自己分類頼みの条件と禁止の列挙は、モデルが変わったときに不発になりやすい
• 指示は層で選ぶ。行動の直前に短く毎回届ける注入が、手元では context の先頭に置かれた大きな rules よりずっと確実だった

参考1: 対策 1 で実際に使っている rule

本体原文を名指しで上書きする rule の、手元で使っている文面の抜粋です (環境に合わせて調整してください。手元では output style として置いています)。冒頭で名指ししている原文の一部 (散文方針など) は、モデルによっては prompt に存在しません (おまけ参照)。存在しないモデルでは、空白を埋める定義として働きます。

1# 報告と分解の形
2
3本指示は、Claude Code 本体の system prompt にある次の記述より優先する:
4"a simple question gets a direct answer in prose, not headers and sections" /
5"Use tables only for short enumerable facts" /
6"Don't make the reader cross-reference labels or numbering you invented earlier" /
7"If you are weighing a choice, give a recommendation, not an exhaustive survey." /
8"You are operating autonomously... proceed without asking." /
9"Text you write between tool calls may not be shown to the user."
10
11## 書き方
12
13状況の説明、原因の説明、複数案の提示では、内容の区分が読み手に伝わる形で書く。
14見出し、箇条書き、表のうち内容に合うものを使う。一言で答えられる質問には散文で答える。
15
16- 先に考えをまとめ、構造化は最後に行う。型を先に置いて埋めない。
17- 原因を説明する時は、観測した事象から「なぜ」を 2 層以上たどり、各層が何を指すかを書く。
18  並列に症状を並べただけで止めない。
19- 複数の案を出す時は、推奨とその理由を先に書き、続けて判断を左右する軸と案ごとの評価を示す。
20  軸を挙げられない時は案を出さず、何を調べれば軸が埋まるかを書く。軸の比較は表で書いてよい。
21- 一度立てた区分と番号は、同じ作業を続ける間は次の turn でも同じものを使う。
22  変える時は何を変えたかを先に書く。
23
24## 対話と進め方
25
26- 本体の「ユーザーはリアルタイムで見ていない」は事実ではなく既定値である。
27  このセッションで途中の発話・interrupt・訂正を 1 度でも受けたら、以後ユーザーは
28  見ているものとして扱う: 作業を小さく区切り、各ターンを必ず報告本文で終え、
29  質問を書いたターンはそこで止めて応答を待つ。
30- この環境で表示されるのはターン末尾の本文だけである。伝える内容はすべてターン末尾に置く。
31- 曖昧さ、承認が要る操作、目的の不明があるときの質問は正当な手段である。

参考2: なぜ Fable 5 / Opus 4.7 では起きなかったのか

本文は Opus 5 に絞りましたが、冒頭の「他のモデルでは起きない」の中身はこうでした。

• Opus 4.7 で起きない理由は単純で、lean prompt の適用対象外 (changelog の記載) のため、旧世代の長い prompt — 応答形式の規定が濃い、旧 rules が前提にしていたもの — のまま動いているからです。旧 rules と噛み合った状態が続いています。
• Fable 5 で起きない理由は意外でした。同じ Claude 5 世代なので同じ prompt だと思い込んでいたのですが、実測すると Opus 5 とは別の prompt が配られていました。

条件を揃えて (headless mode・output style 無効) それぞれのモデルに自身の prompt を原文引用させた比較です。

Fable 5 の # Communicating with the user には「結論を先に・読みやすさ優先・相手に合わせて書く」という規範があり、本文で引用した "give a recommendation, not an exhaustive survey" に加えて "a simple question gets a direct answer in prose, not headers and sections" のような散文方針も、この規範の一部として含まれています。書き方の規範を prompt 自身が持っているため出力の形が崩れにくく、手元の観察ではユーザー rules への追従も保たれていました。

まとめると、Opus 5 で強烈に出たのは 3 つが同時に揃ったからです。

1. 書き方の規定がゼロの prompt が配られ、素の出力傾向がむき出しになった
2. 「十分な情報が揃ったら動け」「網羅より推奨を」という方針が、即作業・軸の省略を後押しした
3. 旧 rules は規定の濃い旧 prompt を前提にしたままで、この空白を埋める形をしていなかった

なお当初は「同じ prompt に対する指示追従の容量がモデルごとに違う」という仮説で考えていましたが、実測で prompt 自体が別物と分かり撤回しました。モデル固有の追従性がどれだけ寄与しているかは、prompt を揃えた比較をしていないため分離できていません。