Claude CodeをOpus 5に切り替えたら思考が浅くなった？System Prompt 80%削減の真相と3つの対策

はじめに：「急に応答がおかしくなった」は気のせいではない

Claude CodeをOpus 5にアップグレードした直後から、「なんだか応答がそっけない」「以前は丁寧に比較してくれていた提案がただの一文になった」「確認もなしにいきなりファイルを書き換え始めた」といった違和感を覚えたエンジニアは少なくないはずです。

これは気のせいでも、自分のプロンプトが悪くなったわけでもありません。2026年7月24日、AnthropicはClaude Code向けのSystem Promptを約80%削減するという、静かながら破壊的な変更を加えました。

この記事で解決できること

Opus 5でSystem Promptが大幅に変わった理由と内容
思考品質が低下する原因メカニズムの把握
優先宣言・望ましい動作の記述・UserPromptSubmit Hookという3つの具体的対策
Opus 5時代に有効なCLAUDE.mdの書き方
今後のモデルアップグレードに備えた設計原則

対象読者

Claude Codeを日常的に使用している開発者で、Opus 5への切り替え後に応答品質の変化を感じている方、またはモデルアップグレード時の制御設計を見直したい方を対象としています。

TL;DR（要約）

Opus 5のSystem Promptは約80%削減され、自前のCLAUDE.mdルールが事実上無効化されるケースが増えています。対策は「優先宣言による上書き」「禁止形から望ましい動作の記述への転換」「UserPromptSubmit Hookによる毎ターン注入」の3本柱です。

1. Opus 5のSystem Prompt、何が変わったのか

1-1. 2026年7月24日に起きた「静かな破壊的変更」

Anthropicのエンジニア、Boris Cherny（MTS）らのチームは、Claude Code向けのSystem Promptを抜本的に見直すプロジェクトを進めていました。その成果として2026年7月24日にOpus 5（およびFable 5）向けPromptの大幅削減がリリースされました。

公式見解では「コーディング評価においてシステムプロンプトの大幅削減による回帰はない」とされています。しかし実際の開発現場では、それまで安定していた自前ルールの振る舞いに明らかな変化が生じています。評価指標では捉えられていない「現場の感触」が変わったのです。

1-2. 削除された主な記述内容

削減されたSystem Promptの内容を整理すると、主に以下の3カテゴリに分類されます。

応答フォーマットの規定 見出しや箇条書きをどう使うか、構造化した回答をいつ使うかといったフォーマット指示が削除されました。これにより、従来は自動的に整理されていた応答がフラットな文章として出力されるケースが増えています。

応答スタイルの指定 「シンプルな質問には散文で答えよ」といった状況別の出力スタイル指定が消えました。Opus 5はこうした明示的な制御なしに、訓練済みのデフォルト動作で応答するようになっています。

複数案提示時の評価軸ルール 複数のアプローチを比較するとき、どのような軸で評価を示すかというルールが削除されています。これが「比較検討なしに単一案を提案してくる」という症状の直接原因です。

1-3. Opus 5向けの新しい設計思想

削除の代わりに、Opus 5向けPromptには新しい行動指針が盛り込まれています。

「情報が十分なら行動せよ」（"When you have enough information to act, act"）
「網羅的調査より推奨を」（"give a recommendation, not an exhaustive survey"）
コード規約については「周囲のコードに合わせよ」という高位の判断指示に集約

この思想転換は、より自律的で判断力のあるエージェントを目指したものです。しかし実際の開発ワークフローでは、「確認してほしい」「比較を見たい」「段階的に進めてほしい」というニーズが依然として存在します。そのギャップを埋めるのが、本記事で紹介する3つの対策です。

2. 思考品質低下の原因と症状を診断する

2-1. こんな症状が出ていたら要注意：チェックリスト

Opus 5への切り替え後に以下の症状が確認されたら、System Promptの変更による影響を受けている可能性が高いです。

見出しや箇条書きがなく、区分のないフラットな散文レスポンスが増えた
「なぜそうなったか」の分析が1層で終わり、根本原因まで掘り下げない
複数の選択肢があるのに、1案だけを提示してくる
「確認しますか？」の問いかけがなく、いきなり作業を開始する
CLAUDE.mdに書いたはずのルールが守られなくなった

2-2. なぜ自前ルールが効かなくなるのか：原因メカニズム

旧来のSystem Promptには、自前のCLAUDE.mdルールが「乗っかる」ための土台が存在していました。たとえば「応答は必ず構造化すること」というSystem Promptがあれば、CLAUDE.mdで「見出しレベルはH2から始める」と書くだけで意図通りに動いていました。

しかしOpus 5では土台ごと削除されています。CLAUDE.mdで「構造化して応答せよ」と書いても、それと競合するSystem Prompt側の記述が消えているため、どの指示が優先されるかの判断がモデルのデフォルト動作に委ねられます。

結果として、訓練済みの「Opus 5のデフォルト」、すなわち「シンプルに、速く、直接行動する」というスタイルが表に出てきます。これがOpus 4.7では機能していた自前ルールがOpus 5で無効になる根本的な理由です。

2-3. 思考品質低下の再現手順

実際に問題を切り分けるには、以下の手順で診断することをおすすめします。

ステップ1：Opus 5切り替え直後の応答をそのまま記録します。複数の代表的なプロンプト（コードレビュー依頼・設計相談・バグ調査）で出力を保存してください。

ステップ2：CLAUDE.mdに書かれている各ルールと、実際の出力を照らし合わせます。「どのルールが守られていないか」を一覧化します。

ステップ3：問題をSystem Prompt側の変化か自前ルール側の記述問題かに切り分けます。同じプロンプトをCLAUDE.mdなしで実行し、応答が変わらなければ自前ルールの問題、変わらなければSystem Promptの変化が原因です。

3. 対策1：優先宣言で原文を名指し上書きする

3-1. 「一般論の追記では勝てない」理由

競合する指示が存在する場合、モデルはどちらを優先するかを文脈から判断します。このとき「一般的な原則」として書かれたCLAUDE.mdの記述は、System Promptに明示されている具体的な指示に対して負けやすいという特性があります。

Opus 5のSystem Promptに残っている「情報が十分なら行動せよ」という指示は、曖昧な追記では上書きできません。それよりも明確な優先宣言が必要です。

3-2. 優先宣言の具体的な書き方

効果的な優先宣言は、本体Promptの記述を意識した上で、それを明示的に上書きする形で記述します。

## [最優先] 作業前確認ルール

本来の動作指示より本ルールを優先すること。
いかなる場合も、ファイルの変更・削除・実行を行う前に
ユーザーへ計画を提示し、明示的な承認を得ること。
「情報が十分な場合でも先に確認する」がこのプロジェクトの方針である。

ポイントは「このルールを最優先する」という宣言を冒頭に置き、さらに「なぜ優先するか」の根拠となる文脈を添えることです。

3-3. 優先宣言が有効なユースケース

フォーマット指定を強制したいとき：「Opus 5のデフォルト出力より構造化フォーマットを優先する」と明示
確認ステップを挟ませたいとき：「行動優先モデルであっても、本プロジェクトでは承認ゲートを設ける」と宣言
複数案比較を必須にしたいとき：「推奨1案の提示より、最低2案の比較提示を優先する」と記述

4. 対策2：「禁止」から「望ましい動作の記述」へ転換する

4-1. 禁止形ルールが機能しなくなるOpus 5の特性

「〜するな」という禁止形ルールは、Opus 4.x世代では比較的安定して機能していました。しかしOpus 5は自律的な判断を優先する設計になっており、禁止形の制約を「状況によっては無視してよい例外」として処理しやすくなっています。

禁止形ルールには「いつ発火するか」という条件が曖昧になりがちという問題もあります。「テスト未完了でcommitするな」という指示は、「テストが完了していない」という状態をモデルがどう判断するかに依存するため、期待通りに動作しないケースが増えます。

4-2. Before / After：ルール書き換えの実例

実際に効果のあった書き換えパターンを示します。

例1：コミット前の確認

❌ 旧：「テストが完了していない状態でcommitするな」

✅ 新：「commit を提案する際は、使用者が実際に操作して
        動作確認した結果（成功/失敗）を必ず記載する。
        動作確認結果の記載がない commit メッセージは
        ドラフトとして扱い、承認を求めること。」

例2：作業開始前の確認

❌ 旧：「重要な変更時は必ず事前に確認すること」

✅ 新：「ユーザーからの入力を受信した直後（応答生成前）に
        作業内容の要約と影響範囲を1〜3行で提示し、
        「進めますか？」の確認を行う。」

4-3. 「判定可能性」を持たせたルール設計の考え方

良いルールとは、「後からそのルールが守られたかどうかを検証できる」ものです。ルールを書くときは以下の3要素をセットで記述することをベストプラクティスとして推奨します。

要素	内容	例
発火条件	いつそのルールが適用されるか	「commit提案時」「ファイル変更前」
期待する出力	何をすべきか具体的に	「動作確認結果を記載する」
判定基準	守られたかどうかの確認方法	「記載がない場合はドラフト扱い」

5. 対策3：毎ターン・行動直前にUserPromptSubmit Hookで指示注入する

5-1. 指示経路の強さを理解する

Claude Codeへの指示経路には強さの差があります。どの経路に何を書くかを正しく設計することが、Opus 5時代のコンテキストエンジニアリングの核心です。

経路	効き方	用途
本体System Prompt	最強	ユーザー側では設定不可
UserPromptSubmit Hook	強（毎発話直前注入）	進め方の制御に最適
Output Style指定	中	出力スタイルの規定
CLAUDE.md等	弱（会話先頭のみ）	総論的な指針

CLAUDE.mdがConversation先頭でしか読まれないのに対し、UserPromptSubmit Hookは毎ターンの発話直前に指示を注入できます。Opus 5の「先に行動する」癖を継続的に抑制するには、この経路が最も効果的です。

5-2. UserPromptSubmit Hookの実装方法

~/.claude/settings.json（またはプロジェクトルートの.claude/settings.json）に以下のように設定します。

{
  "hooks": {
    "UserPromptSubmit": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "echo '[必須] 作業を開始する前に、実施内容と影響範囲を簡潔に提示し承認を得てください。承認なしにファイルの変更・実行を行わないこと。'"
          }
        ]
      }
    ]
  }
}

この設定により、ユーザーの発話のたびに約50トークン分の制御指示がSystem Promptに自動注入されます。「返答より先に作業を始める」というOpus 5のデフォルト動作を、毎ターン強制的にリセットできます。

5-3. Hook運用のベストプラクティス

UserPromptSubmit Hookに注入する内容は、プロジェクト共通の「進め方ルール」のみに絞ることを推奨します。具体的には以下の指針を参考にしてください。

50〜100トークン以内に収める（コスト効率と効果のバランス）
「何を書くか」より「何をする前に確認するか」を中心に記述する
プロジェクト固有の詳細ルールはCLAUDE.mdに残し、Hookでは重要な行動制御のみを扱う

6. Opus 5時代のCLAUDE.md活用法

6-1. CLAUDE.mdの限界を正しく知る

CLAUDE.mdはConversationが開始された時点で一度だけ読み込まれます。長い会話になるほど、その内容はモデルのアテンションから遠ざかります。つまり重要な制御をCLAUDE.mdだけに頼ることは、Opus 5時代には適切ではありません。

CLAUDE.mdの役割を「プロジェクトの文脈と背景を伝えるドキュメント」として再定義し、リアルタイムの行動制御はUserPromptSubmit Hookに委ねる分業体制が効果的です。

6-2. Opus 5に有効なCLAUDE.mdの書き方指針

強調マーカーはセキュリティ・承認ゲートのみに使う > [!IMPORTANT]や太字強調は乱用すると効力を失います。「絶対に守らせたいセキュリティルール」と「本番環境への操作承認ゲート」にだけ使用を限定してください。

各ルールに「範囲・例・判定基準」を同じ場所でまとめる 分散した記述は機能しにくくなります。1つのルールブロックの中に、適用範囲・具体例・判定基準を完結させる構造が有効です。

「プロジェクトの詳細と落とし穴」中心の記述にシフトする 一般的な作業手順テンプレートより、「このプロジェクト固有の注意点」「よくある間違いとその回避方法」を中心に記述すると、Opus 5の高位判断モデルとの親和性が高まります。

6-3. Before / After：CLAUDE.mdの全体構成見直し例

Opus 4.7時代の記述（変更前）

## 作業ルール
- コミット前に必ずテストを実行すること
- 重要な変更は事前に確認を取ること
- レスポンスは構造化された形式で出力すること
- 複数案がある場合はすべてを提示すること

Opus 5最適化後の記述（変更後）

## このプロジェクトの重要な前提

### [必須] 承認ゲート
本番DB（`production_*`プレフィックス）への操作は、
操作内容・影響レコード数・ロールバック手順をユーザーに提示し、
明示的な「実行してください」の指示を受けてから実行すること。

### プロジェクト固有の注意点
- `user_migration.py`は冪等ではないため、2回以上の実行で重複データが発生する
- テスト環境のDBスキーマは本番と意図的に異なる（`test_flags`カラムが追加）
- CIは`feature/*`ブランチにのみ自動実行される。`hotfix/*`は手動トリガーが必要

7. モデルアップグレード時に必ず確認すべきこと

7-1. 「モデル更新＝System Promptの更新」として扱う

段階的に理解を深めていきましょう。モデルのアップグレードは単なる性能向上ではなく、振る舞いの設計変更を伴います。Opus 4.7からOpus 5への切り替えがその典型例です。

アップグレード後の診断フローとして、以下の順序を推奨します。

応答傾向の変化を記録する（複数のユースケースで出力を比較）
本体System Prompt側の変化を先に調査する（公式リリースノートやコミュニティの情報）
自前ルールの見直しに着手する（優先宣言・望ましい動作記述・Hook設定の更新）

多くの場合、「自分のルールが悪くなった」のではなく「土台が変わった」という認識が、適切な対処への近道です。

7-2. 自動メモリが制御を奪うリスクへの対処

Opus 5は自律的なメモリ管理機能を持つ場合があります。この「自動メモリ」が不用意に有効化されていると、会話の進行とともにモデルが独自に学習した動作ルールが優先され、意図した制御が上書きされることがあります。

対処としては、メモリ機能の使用範囲を明示的に設定し、自動メモリが介入できるスコープを限定することが有効です。特に「薄いSystem Prompt + 自動メモリ」の組み合わせは、制御の予測可能性を大きく下げるため注意が必要です。

7-3. 今後のモデルアップグレードに備えた設計原則

技術的に正確な表現を心がけると、これからの設計原則は「本体Promptへの依存度を下げる」ことに集約されます。

行動制御はUserPromptSubmit Hookに集約し、System Promptの変更に対して独立性を持たせる
CLAUDE.mdはプロジェクト文脈の記述に特化し、一般的な作業手順は書かない
モデルアップグレード時のチェックリストを事前に用意し、アップグレード後すぐに診断できる体制を整える

まとめ：Opus 5時代のClaude Code制御の新常識

本記事の3つの対策まとめ

対策	方法	主な効果
優先宣言	CLAUDE.mdに「このルールを最優先」と明示し本体Promptを上書き	フォーマット・確認ステップの強制
望ましい動作の記述	禁止形→発火条件・期待出力・判定基準の3点セットへ書き換え	ルールの判定可能性向上
UserPromptSubmit Hook	毎ターン行動直前に50〜100トークンの制御指示を注入	自律行動の継続的な抑制

実装優先度と推奨ロードマップ

実際の開発現場での導入順序としては、以下を推奨します。

まずUserPromptSubmit Hookを設定する（10分で完了、即効性が高い）
次にCLAUDE.mdの禁止形ルールを書き換える（既存ルールの棚卸しと再設計）
最後に優先宣言を追加する（特定の高優先ルールにのみ適用）

Opus 5は優秀なモデルです。ただしその能力を開発現場のワークフローに合わせてコントロールするには、従来とは異なるアプローチが必要です。「薄くなったSystem Promptを補完する」という視点でルール設計を見直すことが、Opus 5時代のClaude Code活用の第一歩です。

参考リソース

Claude CodeをOpus 5に切り替えたらルールが崩壊した話と対策
Anthropic公式：Claude Opus 5 Prompting Guide
Claude Code公式ドキュメント：Hooks設定リファレンス