Opus 5で「思考が浅くなった」人と、何も変わらなかった人の分かれ目
同じモデルなのに、壊れた人と壊れなかった人がいる
7月下旬、Claude CodeのモデルをOpus 5に切り替えた。CLAUDE.mdにもhookにも、Opus 5向けの調整は何もしていない。それでも劣化は感じなかった。Opus 4.8と比べて見劣りする場面はなく、変化といえば、Fable 5と比べて保守的で忠実、頼んでいないことを先回りしてやる気配はない、という感触の違いくらいだった。
ところがネットでは評価が割れていた。「思考が浅くなった」「長年育てたCLAUDE.mdが効かなくなった」という報告が流れてくる。同じモデルを使って、壊れた人と壊れなかった人がいる。
モデルの当たり外れではない。公式の発表と現場の報告を突き合わせると、分かれ目はモデル側ではなく、利用者が書いてきた設定ファイルの側にあった。この記事では何が起きているのかを整理し、そのうえで自分の環境を実際に診断して確かめた結果を書く。
先に用語を2つだけ押さえておく。システムプロンプトは、Claude Codeが毎回モデルに渡す本体の指示文で、利用者は変更できない。CLAUDE.mdは、利用者がリポジトリやホームディレクトリに置く指示ファイルで、セッション開始時に毎回読み込まれる。モデルに届くのは、この2つが合わさった1つの文章だ。この「合わさっている」という事実が、今回の話の主役になる。
公式発表の要点
7月24日、Claude CodeチームのThariq Shihipar氏が、Claude 5世代のコンテキストエンジニアリングについて発表した。コンテキストエンジニアリングとは、1回のプロンプトの書き方ではなく、モデルが受け取る情報全体（システムプロンプト、CLAUDE.md、スキル、記憶、ツール定義）を設計する考え方で、ここ1年ほどで定着した言葉だ。
発表で最も引用されたのは次の実績だった。AnthropicはOpus 5やFable 5向けに、Claude Code本体のシステムプロンプトを80%以上削減した。それでもコーディング評価の点数は、測定できるレベルでは落ちなかった。
発表は「以前の常識」と「現在」の対比を6つ挙げている。
| 以前 | 現在 |
|---|---|
| ルールを細かく列挙する | 判断基準を短く示し、判断はモデルに任せる |
| ツールの使用例を大量に与える | ツールのインターフェース自体を分かりやすく設計する |
| 全情報を最初に読ませる | 必要になった時点で開示する（段階的開示） |
| 大事な指示は場所を変えて繰り返す | 1か所に一度だけ書く |
| CLAUDE.mdに記憶を蓄積する | 自動メモリー機能と分業する |
| 仕様を簡潔なMarkdownで渡す | テストやHTMLモックなど、実行や検証ができる参照物で渡す |
背景にあるのは、旧世代モデルの補助輪が新世代では足かせになる、という判断だ。「コメントを書くな」のような細かい禁止は、以前のモデルが最悪の失敗をしないために必要だった。新しいモデルは周囲のコードや依頼の意図から判断できるため、禁止の列挙はむしろ判断材料と衝突するノイズになる。
現場では「効かなくなった」報告が相次いだ
一方で、発表の前後から現場では逆方向の声が上がっていた。モデルをOpus 5に切り替えた直後から応答が浅くなった、長年育てたCLAUDE.mdやrulesの効きが変わった、という報告だ。Thariq氏の言うとおりシステムプロンプトが80%以上削減されたことで、今まで使っていたルールセットがうまく動かなくなったという事象が多数報告されており、それぞれのユーザーが指示の書き直しや置き場所の変更といった対策を模索している。
起きていることを分解すると、こうなる。削減で消えたのは、応答の形式や作業の進め方を決めていた細かな規範だ。規範が消えた空白は、利用者のrulesが自動的に埋めるのではなく、モデルに訓練で焼き込まれた既定の挙動が埋める。旧世代の濃いプロンプトと並べて読まれる前提で書かれたrulesは、この既定と噛み合わなければ空回りする。rulesを何も変えていないのに挙動が変わるのは、組み合わせの相手側が変わったからだ。
対立は見かけで、原則は1つ
公式の「削れ」と、現場の「削られて壊れた」は矛盾して見える。だが並べてみると、同じ1つの原則に行き着く。
CLAUDE.mdやrulesは、単体では動かない。本体システムプロンプトとの組み合わせで動く。そしてモデルの更新は、本体システムプロンプトの更新でもある。
壊れた環境では、旧世代のプロンプトを前提に書かれたrulesが、削減後のプロンプトと組み合わさって空回りした。壊れなかった環境は、結果的に組み合わせの整合が取れていた。削るか足すかは症状ごとの処方であって、それ自体が目的ではない。公式の「削れ」も、正確には「新しい本体プロンプトと重複、矛盾する分を削れ」と読むべきだろう。
では、私の環境はなぜ壊れなかったのか。心当たりは3つあったが、どれが効いたのかは切り分けられていなかった。
- ルールを普段からチューニングしていて、矛盾を溜めていない
- コンテキストを詰め込まず、セッションをこまめに切っている
- そもそも応答の形式を縛る類のrulesをほとんど書いていない
仮説のままにせず、確かめる手段がある。公式は今回のベストプラクティスをClaude Codeの /doctor コマンドに組み込んだと言っている。自分の環境にかけてみた。
実測、使い込んだ環境に /doctor をかける
対象の環境は、それなりに重い。
- CLAUDE.md 3層（ユーザー共通、会社ディレクトリ、リポジトリ）で合計約23,000字
- スキル52個（ユーザー共通40、プロジェクト12）とプラグイン4つ
- MCPサーバー14個
- 自動メモリー11件
- Claude Code累計起動638回
診断の結果、毎セッション常駐するコンテキストは推定15,000トークンあり、そのうち約4,500トークンが今の作業に寄与していないと判定された。内訳が示唆的だったので、3点に分けて書く。
何が削れて、何が残ったか
リポジトリのCLAUDE.md（約15,000字）からは、71行を削れた。内訳は、コマンド一覧（package.jsonのscriptsを写しただけ）、ディレクトリツリー（lsで分かる）、依存関係を見れば自明な記述、完了済みプロジェクトの経緯だった。公式が「ファイルシステムやリポジトリを見れば分かることを書くな」と挙げた類型に、きれいに一致する。
逆に残ったのは、コードを見ても分からない知識だ。社名の表記ルール（登記名とブランド名で大文字小文字が違い、一括置換すると両方壊れる）、法的な制約に関わる表記、ブランチ運用、フレームワークの罠。手を動かして削ってみると、線引きは単純だった。削るのは指示、残すのは事実と境界だ。
矛盾はあったか
診断でもう1つ確かめたかったのは、本体プロンプトと衝突する指示がどれだけあるかだった。結果はほぼゼロだった。削れた71行はすべて「冗長」であり、「矛盾」ではなかった。
効かなくなったという報告の原因が旧前提のrulesと新プロンプトの衝突だとすれば、衝突する指示のない環境で崩壊が起きなかったのは、この読みと整合する。n=1の観察なので、3つの心当たりのどれが効いたのかを断定はできない。それでも、切り分けの順序は言える。モデル更新後に挙動が変わったら、疑うべきは「ルールの量」より先に「ルールの矛盾」だ。
一番の問題はCLAUDE.mdではなかった
意外だったのはここだ。常駐コンテキストで最大の問題は、CLAUDE.mdではなくスキル一覧だった。
スキル（作業別の指示ファイル）は、名前と説明文だけが常駐し、本文は必要になった時点で読み込まれる。段階的開示のお手本のような仕組みだ。ただし一覧自体にコンテキストの約1%という予算があり、超過すると一覧が切り詰められて、スキルの自動発火が不安定になる。私の環境は52個のスキルの説明文だけで、この予算のおよそ4倍を消費していた。
冒頭の3つのソースはどれも触れていないが、段階的開示には入口のコストがある。本文を遅延読み込みにしても、入口の一覧が溢れれば結局劣化する。「必要なときだけ開示する」は、スキルを際限なく増やしてよいという意味ではなかった。
ほかにも、デプロイ先がCloud Runのプロジェクトに毎セッション約1,200トークンのVercelガイドを注入してくるプラグインや、別案件用で今のリポジトリでは一度も使っていないMCPサーバー10個が見つかった。モデルの新旧と関係なく積もる、純粋なコンテキスト負債だ。診断結果のうち、CLAUDE.mdの削減と、無関係な接続のプロジェクト限定の無効化を適用した。削減後の挙動の変化は観察を続けている段階で、現時点の数値は常駐量の推定にとどまる。
Issueを契約書として読むモデル
この記事を書いている途中で、CLAUDE.mdの外でも同じ構造の問題に出会った。別案件のリポジトリで、FableやGPT-5.6のときと同じ感覚で、Opus 5にIssueを見せて実装を依頼したときのことだ。そのIssueには、要件が固まる前に書いた暫定のメモが多く残っていた。だからLLMの側から「ここはどうしますか」と確認が入るだろうと思って投げた。ところがOpus 5は何も確認せず、暫定のまま書かれていた内容を画面に実装し続けた。「この画面の文言はいらない」と指示しても消さない。「いいから消して」と強く言うと、「Issueに書いてありますので、実装の必要があります」と返してきた。Issueを完全な契約として扱い、目の前の指示より文書を守る。同じ場面でFable 5やGPT-5.6は「Issue自体を直したほうがいい」と提案してくる。
余談だが、この違いはモデルの「性格」と呼びたくなるくらい一貫している。FableはPRを閉じると、頼んでいないworktreeの後片付けやdevelopブランチの前進まで済ませて、次のIssueの提案までしてくる。GPT-5.6はPRを閉じるだけで、余計なことは一切しない。そしてOpus 5は、渡された文書を守り抜く。先回り型、指示厳守型、文書忠実型。どれが優秀かという話ではなく、渡す仕事の性質と文書の確度で使い分けるものになった、というのが実感だ。
これはモデルの欠陥というより、冒頭に書いた「忠実」の裏面だ。書かれたものへの忠実さは、文書が正しい間は美徳として現れ、文書が暫定のままだと頑固さとして現れる。判断の規範が削られた空白を、「手元の文書を確定情報として実行する」という訓練済みの既定が埋めている、と読める。
構造はCLAUDE.mdとまったく同じだ。暫定のつもりで書いたIssueは、「モデルは文書を額面通りには受け取らない」という旧世代の前提に寄りかかった文書だった。指示追従の強いモデルと組み合わさった瞬間、メモが契約書として執行される。いま多くの議論はCLAUDE.mdの見直しに集中しているが、同期が必要なのはrulesだけではない。エージェントが読むすべての文書だ。
対処は2方向ある。1つはIssueの書き方を変えることだ。暫定と確定を区別して明記し、「実装中の発見が記述と矛盾したら、Issueの修正を提案してから進めてよい」と異議申し立てを許可する一行を添える。もう1つは渡し方を変えることだ。文書自体を疑えるモデル（Fable 5やGPT-5.6）をオーケストレーターに置き、要件の確定を先に済ませ、確定済みのタスクだけをOpus 5に渡す。私は要件定義、設計、タスク分解を仕様書として確定させてから実装用のエージェントに渡すスキル群を組んで開発しているが、この運用ではOpus 5の頑固さは、仕様から勝手に逸脱しない美徳に変わる。
モデル更新時の点検手順
今回の整理を、次のモデル更新でも使える手順に落としておく。
- 挙動が変わったら、rulesを足す前に本体プロンプトの変化を疑う。モデル更新はシステムプロンプトの更新でもある
- 手元のrulesから、本体方針と逆のことを言っている箇所を洗い出す。「必ず」「禁止」「絶対に」の付いた行を重点的に見る
- コードやマニフェストから導ける記述を削る。残すのは、見ても分からない事実と、やり直しの利かない操作の境界
- 指示を置く層を選ぶ。常時読み込ませるのか、スキルにして必要時に読ませるのか、hookで発話ごとに注入するのか
/doctorで定期的に健診する。追加は熱心で削除は放置、が負債の溜まり方の典型だから、削除の機会を仕組みで作る- 暫定の内容には「暫定」と明記する。指示追従が強くなったモデルは、メモと契約書を区別しない
最後に1つ。「削れば賢くなる」もまた、新しい迷信になりかけている。削ってよいのは、モデルが自力で判断できる指示だけだ。社内の事情、顧客の好み、法的な制約、やり直しの利かない操作の境界は、モデルがどれだけ賢くなっても外からは見えない。不要な命令は削り、判断に必要な事実は残す。本体プロンプトが8割消えた今、残り2割に相当する自分のCLAUDE.mdと、エージェントへ渡す文書に何を書くかを決めるのは、これまで通り利用者の仕事だ。
参考
この記事のダイジェスト版