タイトル：Opus 5に切り替えたらルールが効かなくなった話 ── CLAUDE.mdが暗黙に依存していた「5つのデフォルト値」

はじめに

モデルを「Opus 5」に切り替えた途端、プロジェクトの CLAUDE.md （カスタム指示）が突然機能しなくなった経験はありませんか？

ルールは一文字も書き換えておらず、同じ会話、同じファイル、同じ書き方をしているにもかかわらず、以下のような現象が発生します。

• レスポンスの構造が崩れ、のっぺりとした長文になる
• 理由の説明が一段落で途切れる
• こちらが返事をする前に、勝手にツールの実行（Function Calling）を始める

こういう場面に遭遇すると、多くの人は「Opus 5の性能が落ちたのでは？」「プロンプトエンジニアリングが悪いのか？」と疑います。しかし、根本原因はもっと深いところにあります。

あなたの書いたルールがこれまで機能していたのは、単に「あなたがそう書いたから」だけではありません。

なぜプロンプトは突然効かなくなるのか？

CLAUDE.mdは「絶対値」ではなく「差分」である

エージェントに届く指示は、単一のテキストではなく「合成物」です。具体的には以下の3層レイヤーで構成されています。

1. System（土台）: 開発元が設定したシステムプロンプト
2. Harness（枠組み）: 実行フレームワークのデフォルト値やモデルの学習による「振る舞いの癖」
3. User（差分）: あなたが CLAUDE.md に書いたカスタムルール

私たちが書いているルールは、この「土台」の上にパッチとして重なっているだけのレイヤーです。

CSSの reset.css に例えると分かりやすい

この構造は、WebフロントエンドにおけるCSSと全く同じです。
<h1> タグに何のプロパティを指定しなくても、大きく太く表示されるのはブラウザのデフォルトスタイル（土台）が機能しているからです。

もしここで reset.css を適用して土台を変えてしまったらどうなるでしょうか？自分で書いたCSS（差分）を一行も変更していなくても、レイアウトは完全に崩壊します。

プロンプトでも同じことが起きています。前の世代のモデルでは「デフォルト値への微調整」として機能していた指示が、新世代では「デフォルト値が消えた空白を埋める唯一の指示」になったり、逆に「新しいデフォルト値と真正面から衝突する指示」になったりします。テキスト自体は不変でも、ベースモデルが変われば指示の「意味」は可変になるのです。

症状は「エラー」ではなく「劣化」として現れる

この問題が厄介なのは、エラーを吐かないという点です。
ルールの読み込みは成功し、モデルも正常にレスポンスを返してきます。ただ、以前なら「よしなに」やってくれていた構造化や、作業前の確認プロセスがスキップされるだけです。

エラーであればログを追えますが、劣化の場合は「今日はAIの調子が悪いな」で片付けられがちです。「消えてしまったデフォルト値（＝元々自分が明示的に書いていなかった仕様）」の存在に人間は気づきにくく、結果として新モデルへの評価が不当に下がってしまいます。

棚卸しすべき5つの「隠れデフォルト値」

では、私たちは何を確認すべきでしょうか？
経験上、ベースモデルが勝手に肩代わりしてくれていて、かつ私たちが CLAUDE.md に書き漏らしやすい項目は、以下の5つに集中しています。

自分のルールに「明文化して書かれているか？」をチェックしてみてください。

1. レスポンスの構造化
   見出し、リスト、段落分け、結論の配置など。明記していないのに整然とした出力が得られていたなら、それは土台の力です。
2. 「自律性」の閾値（先に聞くか、すぐ動くか）
   情報不足時に「質問を返す」か「推測してツールを実行する」かの閾値。世代によって「情報が揃ったらすぐ動く」側に偏る傾向があります。
3. 検証の癖（セルフチェック）
   コードを書いて終わりにするか、実行結果を確認（Verify）してから報告するか。
4. トークンの冗長性
   どの程度詳しく説明するか。「回答が浅くなった」と感じる場合、モデルの推論力が落ちたのではなく、デフォルトの「冗長さの閾値」が下がっただけのことが多いです。
5. 文脈の一貫性の維持
   前のターンで確立した分類や専門用語を次ターンに引き継ぐ力。長時間のコンテキスト維持は、モデルが暗黙的に補完しているケースが多いです。

これらについて、「明文化しているか？」 × 「もしこの機能が消えたら致命的か？」 でマトリックスを作り、危険な領域を洗い出します。

対策：全てを明文化すべきか？

では、これら5つを全て CLAUDE.md に書き込めば良いのでしょうか？
結論から言うと、それはアンチパターンです。

何でもかんでも明文化すると、プロンプトが肥大化し、Attentionが分散して重要な指示が薄まります。ベースモデルに無料で「タダ乗り」できる部分は、そのまま任せるのがベストプラクティスです。

判断基準は以下の通りです。

• エラーとして現れるもの：気づいてから修正（追記）すれば間に合うので放置でOK。
• 劣化（サイレント障害）として現れるもの：気づけないため、事前に明文化しておく価値がある。（上記の5項目はすべてこちらに該当します）

ベストプラクティス：ルールに「前提」をコメントとして残す

次回のモデル移行コストを下げるための、具体的な書き方の提案です。
ルールを書く際、指示だけでなく「なぜその指示を書いたのか（どんなデフォルト値の消失を補っているのか）」をコメントアウト等で必ず併記してください。

CLAUDE.mdの記述例

<!-- 
✅ 構造化の明示 
（※Opus 3時代はベースモデルがデフォルトで担っていたが、Opus 5への切り替えでフラットな出力になるようになったため明文化 / 2026-07） 
-->
- 回答は必ず「結論」「理由」「具体例」の見出しをつけて構造化してください。

<!-- 
✅ ツール実行前の確認
（※新モデルは自律性が高く、情報不足でも推測で実行開始してしまうため、ストッパーとして明記）
-->
- 実行環境に変更を加えるコマンド（ファイル上書き等）を実行する際は、必ず事前にユーザーの許可を得てください。