Claude Code で Claude Opus 5 に切り替えたあと、「考えが浅い」「すぐ動くが検証が薄い」「逆に報告とトークンだけ膨らむ」と感じることがあります。能力が落ちたように見えても、一次仮説として疑うべきはモデルそのものより、lean system prompt が既定になった Claude Code と、Opus 4.x 時代に書いた長い CLAUDE.md / rules の衝突です。

📑目次
  1. なぜ「浅い」ように感じるのか — lean prompt と旧 rules の衝突
  2. 公式が示す Opus 5 / Fable 5 のプロンプト原則
  3. 比較表 — 旧 rules ハーネス vs Opus 5 lean 向けハーネス
  4. CLAUDE.md・rules 改修手順(削除 → 追加 → 棚卸し)
  5. 導入チェックリスト — 試す / 直す / 戻す判断
  6. よくある質問(FAQ)
  7. まとめ

本記事では、Claude Code 公式 changelog、Anthropic の Prompting Claude Opus 5 / Fable 5、および ITmedia AI+・THE DECODER・AI革命・note(まさお)などの独立報道・運用解説を突き合わせ、削除候補・追加候補・before/after 観測までを実務チェックリストに落とします。


なぜ「浅い」ように感じるのか — lean prompt と旧 rules の衝突

結論から言うと、Opus 4.7 以前向けの長い行動拘束を、Fable 5 / Opus 5 世代の lean 既定に載せると挙動がズレます。モデルが「考えなくなった」のではなく、本体の system prompt が薄くなった前提で、ユーザー側 rules だけが厚い状態が起きやすい、というのが再現しやすい見立てです。

lean system prompt が既定になるモデル範囲

Claude Code 公式 changelog の出荷記述は次のとおりです。

The lean system prompt is now the default for all models except Haiku, Sonnet, and Opus 4.7 and earlier

ここから読み取れる運用上の意味は次です。

  • 出典: Claude Code changelog
  • Haiku / Sonnet / Opus 4.7 以前を除くモデルでは lean system prompt がデフォルト
  • Opus 4.7 では問題が目立たず Opus 5 で急に rules の効きが変わった、という体感の一次説明になる

独立報道が示す約 80% 削減

独立報道も同じ方向を指します。

  • ITmedia AI+(2026-07-09)は、Anthropic の Tariq Shihipar 氏の講演を伝え、Claude Code のシステムプロンプトを約 80% 削減し、従来渡していた動作例(examples)も与えない方針にしたと報じています。
  • THE DECODER(2026-07-02)も同様に約 80% 削減を伝え、Fable 5 クラスは smaller system prompt を好み、examples が創造性を制約し得ること、hard rules(do not)から context 誘導へ舵を切ったことを整理しています。
  • AI革命は CHANGELOG v2.1.154 の lean 既定を実装根拠として引用し、削るのは細かい行動拘束、増やすのは理由・意図・ツールだと編集方針を示しています。
ITmedia AI+のClaude Codeシステムプロンプト約80%削減報道の画面
独立報道(ITmedia AI+)が伝える lean system prompt 方針

出典


「プロンプト不要」ではない — 起きやすい二極

ここで重要なのは「プロンプト不要」ではない点です。本体が lean 化したあとに、CLAUDE.md 側で次のような条項を載せ続けると、二極が起きやすくなります。

  • 「必ず最終検証」
  • 「毎回 fresh subagent でレビュー」
  • 長い禁止列挙と行動例の複製

起きやすい結果は次の2つです。

  1. 指示が過拘束になり、モデル既定の自己検証・act-first と競合してトークンと報告量だけ増える
  2. あるいは意図が伝わらず、短絡的に見える出力(浅い感)が増える

まずは能力劣化ラベルを貼る前に、harness(CLAUDE.md / Skills / project rules)を疑うのが合理的です。


公式が示す Opus 5 / Fable 5 のプロンプト原則

Prompting Claude Opus 5

Anthropic の Prompting Claude Opus 5 は、スキャフォールド側の調整を公式に要求します。要点は次のとおりです。

  • 簡潔さは明示が必要: 既定のユーザー向け応答が長くなりがち。effort は thinking 量の制御であり、表示長の制御ではない
  • over-verification を削る: 指示なしでも自己検証するため、「最終 verification」「double-check」「fresh subagent review」の常設はトークン浪費になり得る
  • scope を明示: 狭いタスクでは依頼範囲を勝手に広げない
  • subagent 委譲を限定: 大規模で独立した並列作業に限定。数回のツールで終わる作業や自己検証への委譲は避ける
  • 進捗 cadence を書く: 最初のツール前の一文、重要時のみ更新、終了時は outcome 先行、など通信の粒度を明示する

Prompting Claude Fable 5

Prompting Claude Fable 5 では、次の舵取りが文書化されています。

  • act-first: 十分な情報があれば調査を延ばさず動く(”When you have enough information to act, act.”)
  • recommendation-not-survey: 選択肢の総覧より推奨を出す
  • 旧モデル向けに過詳細な Skills は品質を下げ得るため refactor
  • 「思考過程を本文に再現せよ」系は reasoning_extraction を誘発し得るため削除監査
  • capability 向上時は instructions / tools / guardrails を再評価し、意図(reason)を短く足す

運用メモ(note まさお)

運用面では note(まさお)が、公式 Opus 5 ガイダンスに沿って次の改修を整理しています。

  • 強制検証・常時 subagent レビューを削る
  • 簡潔さ・委譲条件・実況粒度・scope を足す

effort まわりの実務メモも有用です。

  • effort はタスクごとに見直す
  • thinking disabled より low effort + thinking 有効を検討する
  • xhigh/max と thinking disabled の組み合わせエラーに注意する

比較表 — 旧 rules ハーネス vs Opus 5 lean 向けハーネス

読者が自分の CLAUDE.md を棚卸しするときの判断軸を表にします。

旧 rules と lean 向けの対比

観点 旧世代向け rules が残りやすい形 Opus 5 / lean 向けの形
system prompt 長い禁止・手順・行動例の複製 lean 既定(4.7 以前は除外)を前提に薄い指示
検証 毎回最終検証・subagent レビュー強制 既定の自己検証を尊重し、過剰ステップを削除
長さ・口調 暗黙の長文・実況過多 簡潔さ・tone_preference 相当を明示
委譲 細かい作業も subagent 大規模独立並列のみ。手で数回で済む作業は委譲しない
Skills / CLAUDE.md 旧モデル用の過規定 brief instruction + 意図。/doctor で権利サイズ
評価 「従ったか」チェックリスト 報告行数・subagent 起動・トークン差分で before/after

出典(2026年7月時点)


表の使い方

左列の文言が CLAUDE.md に残っているほど、Opus 5 では「浅い/重い」の両方が出やすくなります。右列は公式と独立運用解説が共通して勧める方向です。


CLAUDE.md・rules 改修手順(削除 → 追加 → 棚卸し)

一度に全部書き換える必要はありません。衝突源をコメントアウト → 短い舵取りを足す → 1タスクで測るの順が安全です。

削除候補(衝突源)

  1. 「必ず検証して」「double-check」「最終 verification ステップ必須」
  2. 「fresh subagent でレビューして」系の常設
  3. 長すぎる禁止列挙・行動例の複製(本体が lean 化した前提と二重になる)
  4. 「思考過程を本文に再現せよ」系(Fable 5 の reasoning_extraction リスク)

追加候補(公式に沿う舵取り)

  1. 簡潔さ・長さの指示(tone_preference 相当)
  2. 進捗 cadence(いつ一行報告するか)
  3. タスク scope(広げない境界)
  4. subagent 委譲条件(大規模独立並列に限定)
  5. 依頼の背景(reason)を短く

棚卸しと運用メモ

AI革命が整理するように、Claude Code の /doctor はコードベースから導ける CLAUDE.md 記述の削減提案に使えます。コードを読めば自明な規約や、重複した禁止リストから削ると、指示の密度が下がります。

effort は「常に最大」に固定せず、代表タスクごとに見直します。失敗しても rules を全捨てせず、衝突した条項だけ切り戻すと、回帰時の原因切り分けが楽です。

Skills も CLAUDE.md と同様です。Fable 5 公式は旧モデル向け過詳細 Skills が品質を下げ得るとし、refactor を求めています。長い手順書を Skills に残している場合は、brief instruction + いつ発動するか + 意図、に圧縮する候補になります。


導入チェックリスト — 試す / 直す / 戻す判断

次の条件に当てはまるなら、今週中に代表タスク1本で試す価値があります。

  • Opus 5 または lean 既定モデルを使っている
  • CLAUDE.md / project rules が 4.x 時代の長文のまま
  • 「浅い」「検証が薄い/重すぎる」「トークンだけ増える」のいずれかが再現する

チェックリスト

  1. ✅ changelog 上、対象モデルが lean system prompt 既定か確認する
  2. ✅ CLAUDE.md から強制検証・常時 subagent レビューを一時コメントアウトする
  3. ✅ 簡潔さ・scope・委譲上限・進捗 cadence を短く足す
  4. ✅ 同一タスクで報告行数・subagent 起動数・トークンを before/after 記録する
  5. /doctor または差分レビューで、コードから自明な記述を削る
  6. ✅ 失敗時はルールを全捨てせず、衝突条項だけ切り戻す

見送る・弱めるケース

規制・監査で外部検証証跡が必須のフローは、モデル既定の自己検証に任せきりにしないでください。その場合は モデルへの常設命令別レーンのレビュー(PR・人が見るチェックリスト・監査ログ) を分離します。公式が削るよう促しているのは「毎回の最終 verification / subagent verify をプロンプトに常設する」形であり、組織の品質ゲートそのものを否定するものではありません。


今週の次アクション

「削除3項目 + 追加3項目 + 数値1セット(行数・subagent・トークン)」を、使い慣れた代表タスク1本で完了させてください。差分が見えれば、チーム共有の CLAUDE.md テンプレにも同じ方針を横展開できます。


よくある質問(FAQ)

Q1. Opus 5 は本当に「考えが浅くなった」のか?

公式ドキュメントと独立報道が示す主因は、能力低下ラベルそのものより、Claude Code の lean system prompt 既定と旧 rules の過拘束のミスマッチです。まず harness を疑うのが合理的です。


Q2. lean system prompt は全モデルか?

公式 changelog は、Haiku / Sonnet / Opus 4.7 and earlier を除く全モデルで lean がデフォルトと記載しています。4.7 以前との差の説明に使えます。


Q3. 検証 steps を全部消してよいか?

Opus 5 公式は「常設の最終 verification / subagent verify」が over-verification になると警告しています。監査必須の作業は別プロセスに切り出し、モデルへの常設命令と混同しないでください。


Q4. Skills はそのままでよいか?

Fable 5 公式は旧モデル向け過詳細 Skills が品質を下げ得るとし refactor を求めています。AI革命も同様に注意を整理しています。brief instruction と意図へ圧縮するのが第一候補です。


Q5. 効果はどう測る?

note(まさお)が示すように、同一タスクでの報告行数・subagent 起動数・トークン差分で before/after を見るのが実務的です。「従ったか」チェックより、コストと可観測性の差分が判断材料になります。


関連記事:

まとめ

  • 「浅い」感の一次仮説は、lean system prompt × 旧 rules の衝突です
  • 公式の Opus 5 / Fable 5 に沿い、強制検証と過詳細 Skills を削り、簡潔さ・scope・委譲・cadence・意図を足します
  • changelog と独立報道で事実を固定し、代表タスク1本の数値観測で改修を完了させます
  • 監査必須の検証は別レーンに残し、モデル常設命令と品質ゲートを分けます

関連して、CLAUDE.md の設計パターンClaude Opus 4.7 と /effortClaude Code Skills の書き方 もあわせて参照すると、ハーネス全体の整理が進みます。

krona23

著者

krona23

IT業界20年以上の実務経験を持ち、日本国内有数のPVを誇る大規模Webサービスで事業部長・CTOを複数社で歴任。Windows/iOS/Android/Webと技術の変遷を経験し、現在はAIネイティブへの変革に注力。DevGENTでは、AIコードエディタ・自動化ツール・LLMの実践的な使い方を日英西3言語で発信中。

DevGENT について →

コメントを残す

Trending

DevGENTをもっと見る

今すぐ購読し、続きを読んで、すべてのアーカイブにアクセスしましょう。

続きを読む