Claude CodeをOpus 5に切り替えたとたんに「思考が浅くなった」「応答が散文の羅列になった」「確認なしにいきなり作業を始める」と感じた場合、その原因はモデルの品質低下でも自分のCLAUDE.mdの書き方の問題でもなく、Claude 5世代に適用された本体システムプロンプトの約80%削減という設計思想の転換にあります。
Claude Code v2.1.154（changelog上の「lean system prompt」）以降、Opus 5に配られるシステムプロンプトから応答形式の規定がまるごと削除され、代わりに「十分な情報が揃ったら動け（When you have enough information to act, act.）」という自律方針が加わったことで、旧世代のCLAUDE.mdを前提に書かれた既存のrulesが意図通りに機能しなくなっています。
この記事では、症状の正体・システムプロンプト変化の全体像・CLAUDE.mdの具体的な書き直し方・指示を確実に届けるための層の選び方を、Opus 4.7やFable 5と比較しながら実践的に解説します。
「同じrulesなのに、Opus 5に切り替えた瞬間だけ壊れる」——この違和感を抱えたエンジニアは少なくありません。モデルを変えただけで指示の効き方がここまで変わる理由は、「モデルを更新する＝本体システムプロンプトを更新する」という事実を知らないままでいると永遠に見えてきません。ぜひ最後まで読んで、自分の環境に当てはめてみてください。
まず症状を整理する：Opus 5切り替え後に起きがちなこと
出典：https://unsplash.com/ja
Claude CodeをOpus 5に切り替えた直後に現れる症状は、大きく5種類に分類できます。
- 応答の散文化：状況説明や原因説明が、見出しも区分もないフラットな長文になる
- 思考の浅さ：原因説明が1層で止まり、「症状を並べただけ」で「なぜ」を掘り下げない
- 評価軸の省略：複数案を提示するとき、比較の軸・根拠・推奨理由が付かない
- 区分の揺れ：一度立てた見出し番号や分類が、次のターンで別の体系に組み替わる
- 返答なし作業着手：こちらの発話に応えず、いきなりツール実行（コード修正・ファイル操作）に入る
厄介なのは、「もっと深く考えて」と促し直しても、次の応答も同じ浅い構造で返ってくることです。一回の回答品質の問題ではなく、対話を通じた検討そのものが成立しなくなる——というのが、多くのユーザーが感じた「ただの出力の悪さとは違う」という感覚の正体です。
「rulesのせい」でも「モデルの品質低下」でもない
重要な手がかりは「同じrulesで、他のモデルでは起きない」という事実です。
rulesに問題があるなら、モデルを問わず同じ症状が出るはずです。変えたのはモデルだけなのに症状が出るということは、「rulesが前提にしている環境の側が変わった」と考えるのが自然です。この視点で調べていくと、本体システムプロンプトの変化という原因にたどり着きます。
原因の本質：system promptの80%削減で何がなくなったのか
Claude 5世代のClaude Codeは、本体のシステムプロンプトが旧世代から約80%削減されています。
AnthropicのThariq Shihipar氏が2026年7月1日のAI Engineer World’s Fair 2026で公表し、公式changelog v2.1.154に「lean system prompt」として実装済みです（ただしHaiku・Sonnet・Opus 4.7以前は対象外）。実際にOpus 5に配られているプロンプトを実測すると、構成は次のとおりです。
- 正体と役割の宣言・セキュリティ方針（冒頭前文）
- ハーネス仕様（# Harness）：出力はmarkdownとして表示される、といった実行環境の説明
- 環境情報と機能説明：作業ディレクトリ・git状態・モデルID、メモリやコンテキスト圧縮の仕組み
- スコープ規律（# Delivering work）：依頼された範囲を勝手に狭めない・広げない
- 訂正の作法（# Corrections）：訂正は簡潔に、謝罪や前置きを足さない
この構成に「ない」もの——それが症状の直接原因
旧世代のシステムプロンプトにあって、新しいOpus 5向けプロンプトに存在しない要素が2つあります。
消えた要素①：応答の書き方を規定する文
散文か構造か、見出しや表の使い方、簡潔さの基準——旧世代のプロンプトに長く書かれていた応答形式の規定が、Opus 5のプロンプトからは丸ごとありません。書き方の規定がゼロになることで、モデルの素の出力傾向——フラットな散文——がそのまま表に出ます。
加わった要素：「まず動け」という自律方針
旧世代にはなかった方針が2つ追加されています。
- “When you have enough information to act, act.”（十分な情報が揃ったら動け）
- “If you are weighing a choice, give a recommendation, not an exhaustive survey.”（選択肢を比較するなら網羅ではなく推奨を出せ）
「十分な情報があれば動く」という方針が、ユーザーへの返答より先のツール実行を後押しし、「推奨を出せ」が評価軸の省略につながります。冒頭に挙げた5つの症状のすべてが、この2つの変化から説明できます。
「lean prompt」設計思想の転換——なぜAnthropicはここまで削ったのか
出典：https://unsplash.com/ja
この削減は単純な省略ではなく、Anthropicによる意図的な設計思想の転換です。
削るのは行動を縛る指示と例示であり、増やすのは理由・意図・ツールです。公式は「Give the reason, not only the request」と明記しており、「プロンプト不要」という意味ではありません。
背景にある考え方はこうです——「新世代モデルは行動を訓練によって内在化しているため、細かい指示はかえって摩擦や矛盾になる（capability overhang）。詳細な指示と例示が、伸びた能力を覆い隠している」。だから、行動を縛る指示を外してモデルの創造性を解放し、代わりに理由・意図・ツールとコンテキストで誘導する——というのが新しい方針です。
「規定の空白＝自分のrulesが唯一の規定」という誤解
「システムプロンプトに書き方の規定がなくなったなら、自分のrulesがその役割を担うのでは？」と考えるのは自然ですが、実際は逆です。
この空白は「ユーザーに委ねられた余白」ではなく、「モデルに訓練で焼き込まれた既定の動作に委ねられたもの」です。Opus 5の既定は、簡潔な散文で確認より先に動く方向にあります。旧世代の長いシステムプロンプトを前提に書かれた既存のrulesは、この訓練済みの既定を覆すには書き方の具体性も届く位置も足りていません。
AI導入はウィルダー株式会社にお任せください。まずはお気軽にご相談ください。
モデルによってシステムプロンプトが違う——Opus 5・Fable 5・Opus 4.7の比較
「同じClaude 5世代なのに、Fable 5では症状が出ない」という観察の理由も、実測で明らかになっています。
| モデル | 本体システムプロンプトの特徴 | 症状の有無 | 理由 |
|---|---|---|---|
| Opus 5 | lean prompt（応答形式規定ゼロ・自律方針あり） | 症状が強く出る | 書き方規定の空白＋「まず動け」方針が、旧rulesを無効化する |
| Fable 5 | lean promptだが「# Communicating with the user」セクションに結論先頭・読みやすさ・相手に合わせた書き方の規範が残る | 症状が出にくい | 書き方の規範をプロンプト自身が持っているため出力形式が崩れにくく、rulesへの追従も維持される |
| Opus 4.7 | lean prompt非適用（changelog記載）、旧世代の長いプロンプトのまま | 症状が出ない | 旧rulesが前提にしていた応答形式の規定が濃い旧プロンプトと噛み合っており、整合性が保たれている |
Opus 5で症状が強く出るのは「書き方規定ゼロのプロンプト」「自律方針の追加」「旧rulesが規定を前提に書かれていた」という3つが同時に揃ったためです。Fable 5では書き方の規範がプロンプト側にあるため、同じClaude 5世代でも症状の出方が大きく異なります。
対策①：本体の原文を名指しして上書きする
出典：https://unsplash.com/ja
本体方針と衝突するrulesを書くときは、本体プロンプトの原文をそのまま引用して「名指しで優先を宣言する」形が有効です。
うまくいかなかった書き方
「複数案には評価軸を付けて書くこと」のような一般論の追記は機能しません。本体の “give a recommendation, not an exhaustive survey” と並んだとき、どちらを優先するかの手がかりがなく、モデルは本体方針に引きずられます。名指しすることで衝突が明示され、優先順位が伝わります。
名指し上書きの例
# 書き方の優先宣言 本指示は、Claude Code本体のsystem promptにある次の記述より優先する: "a simple question gets a direct answer in prose, not headers and sections" / "If you are weighing a choice, give a recommendation, not an exhaustive survey." / "When you have enough information to act, act." ## 書き方 状況の説明・原因の説明・複数案の提示では、内容の区分が読み手に伝わる形で書く。 一言で答えられる質問には散文で答えてよい。 - 原因を説明するときは「なぜ」を2層以上たどる。症状の並列で止めない - 複数案を出すときは推奨とその理由を先に書き、続けて判断軸と案ごとの評価を示す - 一度立てた区分と番号は、同じ作業の間は次のターンでも使い続ける
また、書き方の規定のようにOpus 5のプロンプトにそもそも存在しない要素については、「上書き」ではなく「空白を自分の定義で埋める」指示として機能します。
発火条件は「観測できる事実」で書く
「重要な変更のときは」「本番環境と判断したら」のような条件は、モデルが自分でその分類に当てはめられなかった瞬間に不発になります。発火条件は「interrupt（割り込み）を受けた」「ユーザーの発話に訂正が含まれる」のような、解釈の余地がない観測可能な事実として書き直すことで、適用漏れが減ります。
対策②：禁止ではなく望ましい動きを書く
旧rulesに多い「〜するな」という禁止形は、代わりに何をすべきかを伝えません。
本体方針と衝突したとき、モデルには「禁止を避けつつ本体方針に従う」という抜け道が生まれます。禁止形は望ましい動きの記述へ変換することで、この抜け道を塞げます。
| 変換前（禁止形） | 変換後（望ましい動き） |
|---|---|
| テスト未完了の状態でcommitを提案するな | commitを提案するときは、その成果物を使う人の操作手順で動かした結果を本文に書く |
| 確認せずにファイルを上書きするな | 既存ファイルを書き換えるときは、変更前と変更後の差分と理由を先に示してから実行する |
| 返答なしで作業に入るな | ユーザーの発話にはまず本文で返答（回答、または受け止めと進め方）を書いてから、ツールを実行する |
対策③：指示をどの「層」で届けるかを選ぶ
出典：https://unsplash.com/ja
文面を直すだけでは不十分で、「どの経路でモデルに届けるか」も成否を左右します。
Claude Codeには指示を届ける経路が少なくとも4つあり、それぞれ効き方が異なります。APIはstatelessなので、どの経路の内容も毎リクエスト（毎ターン）モデルへ送信されます。違いが出るのは「内容がいつ確定するか」と「promptの中でどの位置に置かれるか＝いま取ろうとしている行動からどれだけ近いか」です。
| 経路 | 特徴 | 向いている指示 |
|---|---|---|
| CLAUDE.md / rules | context先頭付近に配置。セッション全体の前提として機能 | プロジェクト固有の制約・技術選定・永続的な方針 |
| output style | ドキュメント上は「system promptを置き換える」機能だが、実態は毎ターンattachmentとして配信される | 応答の書き方（構造・見出し・評価軸）の名指し上書きに有効。進め方（作業着手順序）には効きにくい |
| UserPromptSubmit hook | 毎発話の直後にinjectする。行動の直前に短く届く | 「返答せず作業に入る」癖のような、タイミング依存の習慣を変えるのに最も効果的 |
| ユーザー発話内への明示 | 会話の中でその場の指示として届く | 1回限りの調整・特定ターンだけ変えたい挙動 |
output styleで書き方は直せたが、作業着手順序は直せなかった
output styleには2種類の指示を書いた場合、効果が分かれます。書き方（構造で書く・評価軸を付ける）には改善傾向が出る一方、進め方（ユーザー発話に返答せず作業に入る癖）はoutput styleでは止まりませんでした。
この進め方の癖を止めたのが、UserPromptSubmit hookで毎発話の直後に1行注入する方法です（参考：Zenn記事 claude5-rules-collapse-and-fix）。
# 毎発話注入の内容（例） ツール実行より先に、この発話への返答（回答、または受け止めと進め方）を本文で書くこと。
コストはwrapper込みで1発話あたり約50トークン。100発話でも5,000トークン程度で、200Kのコンテキストに対しては誤差の範囲です。
行動直前の注入が最も確実——一般則として
層の選び方から得られる一般則はシンプルです。
「変えたい行動の直前に、短く、毎回届ける」指示がいちばん確実に効きます。機能しないrulesの多くは、内容が悪いのではなく、行動の瞬間にモデルの手元に届いていません。context先頭に置かれた大きなrulesは、行動が発生するターンに読まれている保証がない。この「届き方の問題」が、文面の問題と同じくらい成否に影響します。
書き直したrulesを検証する8つのチェック項目
出典：https://unsplash.com/ja
書き直した各ruleは、次のチェックで判定できます。
- そのruleの文だけで意味が閉じているか：適用範囲・例・判定基準が同じ場所にあるか
- 発火条件が観測できる事実か：「重要な変更のとき」のような自己分類頼みになっていないか
- 本体system promptと矛盾していないか、または名指しで優先宣言しているか
- 望ましい動きが書かれているか：禁止の列挙になっていないか
- 判断の基準が1つか：場面の数え上げになっていないか
- 強調は本当に落とせないものだけに付いているか：全部が強調されている文書は何も強調されていない文書と同じ
- 到達してほしい状態で書かれているか：手順やテンプレートを先に埋めさせていないか
- 守られたかどうかを後から判定できるか：検証不能な指示は改善もできない
強調マーカー（IMPORTANT・必須など）はセキュリティと承認ゲート系だけに絞ることを推奨します。すべてが強調されている文書は、何も強調されていない文書と同じ効果しか持ちません。
よくある質問
Q. Opus 5に切り替えたら思考が浅くなったのはモデルの品質が下がったからですか？
A. いいえ、モデルの品質低下ではありません。原因はOpus 5に配られる本体システムプロンプトの約80%削減にあります。旧世代プロンプトにあった応答形式の規定がなくなり、代わりに「十分な情報があれば動け」という自律方針が加わったことで、旧世代のrulesを前提に書かれた既存のCLAUDE.mdが意図通りに機能しなくなっています。同じrulesでOpus 4.7では症状が出ないのは、旧世代の長いプロンプトがlean prompt非適用のまま動いているためです。
Q. Fable 5でも同じ症状が出ますか？
A. 同じClaude 5世代でも、Fable 5はOpus 5ほど症状が出にくい傾向があります。Fable 5のプロンプトには「# Communicating with the user」セクションに「結論を先に・読みやすさ優先・相手に合わせて書く」という書き方の規範が残っているためです。Opus 5ではその規範が空白になったことで、素の出力傾向がむき出しになります。
Q. CLAUDE.mdに「構造で書け」と追記すれば解決しますか？
A. 一般論の追記だけでは効果が薄いです。「複数案には評価軸を付けて書くこと」のような指示は、本体の「推奨を出せ（not an exhaustive survey）」と並んだとき、どちらを優先するかの手がかりがないため本体方針に負けます。本体の原文を引用して名指しで優先を宣言する形、かつ発火条件を観測可能な事実で書くことが必要です。
Q. 「返答せずに作業を始める」癖はどうすれば直せますか？
A. output style（CLAUDE.mdへの追記を含む）では効果が限定的で、行動の直前に届けることが重要です。UserPromptSubmit hookで毎発話の直後に「ツール実行より先に、この発話への返答を本文で書くこと」という1行を注入する方法が効果的です。1発話あたり約50トークンのコストで済み、200Kコンテキストに対しては誤差の範囲です。
Q. 「lean system prompt」はAnthropicの公式な変更ですか？
A. はい。AnthropicのThariq Shihipar氏が2026年7月1日のAI Engineer World’s Fair 2026での講演で公表し、Claude Code公式changelog v2.1.154に「lean system prompt」として実装済みです。ただしHaiku・Sonnet・Opus 4.7以前は対象外とchangelogに明記されています。
Q. 「コンテキストエンジニアリング」とは何ですか？プロンプトエンジニアリングと何が違うのですか？
A. プロンプトエンジニアリングが「一回の依頼文を調整する行為」だとすれば、コンテキストエンジニアリングは「どの情報を常時渡し、どの情報を必要なときだけ読み込み、何をモデルの判断に委ねるかを設計する行為」です。Anthropicは、Claude Codeに渡される製品側システムプロンプト・CLAUDE.md・Skills・メモリ・ツール定義・会話履歴・参照資料の組み合わせ全体をコンテキストエンジニアリングの対象として定義しています（参考：AICU）。
AI導入はウィルダー株式会社にお任せください。まずはお気軽にご相談ください。
まとめ
Opus 5で「思考が浅い」と感じた場合の根本原因と対策を振り返ります。
- モデル更新は本体system promptの更新でもある。応答の傾向が急に変わったら、rulesを足す前に本体側の変化を実測して確認する
- Opus 5は書き方の規定がゼロの lean prompt。素の出力傾向（フラットな散文・評価軸省略・即作業着手）がむき出しになるため、旧rulesでは対応できない
- 本体方針と張り合うruleは、原文を名指しして優先を宣言する。一般論の追記は矛盾の中で本体方針に負ける
- 発火条件は観測で書き、禁止ではなく望ましい動きを書く。自己分類頼みの条件と禁止の列挙は、モデルが変わったときに不発になりやすい
- 「変えたい行動の直前に、短く、毎回届ける」が最も確実。context先頭の大きなrulesより、行動直前の1行注入の方が確実に効く
- Fable 5・Opus 4.7では症状が出にくい理由はプロンプトの違い。モデル固有の追従性の差ではなく、配られているプロンプトの構成の差が症状の出やすさを決める
「rulesを増やせば解決する」という発想は、本体システムプロンプトの変化を見落としている限り成立しません。モデルを切り替えたら、まず「そのモデルに実際に配られているプロンプト」を実測して確認することが出発点です。rulesは本体プロンプトとセットで設計するもの——この認識の転換が、Opus 5以降のClaude Code運用の核心です。
AI導入はウィルダー株式会社にお任せください。まずはお気軽にご相談ください。
