RedditのClaude Codeコミュニティで大きな反響を呼んだスレッドがあります。
テーマは、Claude Codeのシステムプロンプト削減です。
AnthropicはClaude 5世代のモデル向けに、システムプロンプトを約80%削減しました。
あわせて、新しい指針も公開されています。
CLAUDE.mdやスキルに何を残すべきか、という内容です。
あなたがClaude Codeを使い込んでいるなら、この変更は他人事ではないはずです。
何が変わったのか
発表のポイントは、大きく3つあります。
まず、ハードルールの大半が削除されました。
「コメントを書くな」といった細かい禁止事項は、もう並べません。
その代わり、モデル自身の判断に任せる方針へ転換したのです。
次に、ツール説明文の中の具体例です。
新しいモデルにとって、これらの例は助けになりません。
むしろ、動きを縛る足かせになると指摘されています。
そして、CLAUDE.mdの構成方法です。
これまでは、1つのファイルへ全部を詰め込む形が主流でした。
しかし今後は、ファイルのツリーを作る形が推奨されています。
必要になったときに、必要なファイルだけが読み込まれる構成です。
さらに、新しく/doctorコマンドが追加されました。
このコマンドは、CLAUDE.mdやスキルの中身を監査してくれます。
つまり、もう存在しない古いモデルのために書かれたルールを洗い出せるわけです。
一言でいえば「プログレッシブ・ディスクロージャー」
スレッドで最も支持を集めたコメントは、この変更を一言で要約していました。
段階的開示、つまりプログレッシブ・ディスクロージャーです。
巨大で硬直したシステムプロンプトを、最初から全部読み込ませるのはやめる。
代わりに、モデルの判断を信頼する。
そして、特定のスキルやルールは必要になった場面でだけ読み込む。
考え方としては、それだけです。
しかし、これまでのプロンプト設計の常識を根本からひっくり返す転換でもあります。
実際に試した人たちの声
すでに新方針を試したユーザーからは、興味深い報告が上がっていました。
あるユーザーは、ルールとインフラを積み上げすぎていました。
そのせいで、新機能の開発が進まなくなっていたそうです。
そこで、思い切って全部を取り払いました。
すると、Opus 5がその場で単一の成果物を組み上げてしまったのです。
しかも、自分が構築していた仕組みより出来が良かったといいます。
このユーザーによれば、思いつくままに書き殴ったプロンプトでも問題ないそうです。
Opus 5は、そこから動く機能を作り上げてくれます。
古いモデルの時代は、細かく指定するのが有効でした。
硬いルールも、大量に用意する価値がありました。
しかし、いまは違います。
プロンプトは「言葉の袋（Bag of Words）」で十分です。
モデルを正解の近くまで運べれば、それでいい。
そんな感覚に変わってきたようです。
最大の懸念：複数モデルの使い分け
とはいえ、スレッドは称賛一色ではありません。
実務的な懸念も、数多く出ていました。
いちばん大きいのは、複数モデルを切り替えて使う場合の話です。
賢いOpus 5と、それより能力の劣るSonnetを併用していたらどうなるでしょうか。
判断任せの薄いコンテキストは、Opus 5には合います。
しかし、Sonnetには足りないかもしれません。
オープンモデルをClaude Codeにつないでいる人からも、同じ疑問が出ていました。
技術面では、ある程度の答えが示されています。
システムプロンプトは、リクエストごとにチャットコンテキストの先頭へ付加される仕組みです。
だから、モデル変更にあわせてプロンプトを差し替えること自体は問題ありません。
ただし、キャッシュは失われます。
もっとも、キャッシュはそもそもモデルに紐づきます。
そのため、モデルを変えれば維持できないという指摘もありました。
ちなみに、キャッシュの保持時間はサブスクリプションなら1時間です。
一方、APIはデフォルトで5分となっています。
APIでも、設定で1時間を選べます。
ただし、キャッシュ書き込みのコストは上がります。
より根深いのは、コンテキストファイルの管理コストです。
リポジトリごとに、別のコンテキスト一式を持っている。
しかも、それが10〜20リポジトリある。
そんなユーザーは、不満を漏らしていました。
新モデルへ移るたびに、全部を作り直すのかと。
同じコードベースで、SonnetとOpusをタブ違いで走らせるチームもあるでしょう。
その場合、正しい設定が2つ存在して食い違う事態になります。
方向性は正しい。
しかし、コンテキストファイルのバージョン管理という物語はまだ始まってすらいない。
そう表現するコメントもありました。
判断任せの落とし穴
もう1つ、鋭い指摘がありました。
モデルの判断は、魔法のように見える。
ただしそれは、90日目までの話だ、と。
その日、モデルは勝手に判断します。
「あなたのハウススタイルは交渉可能だ」と。
つまり、本当に譲れない制約もあるわけです。
そこには、明示的なルールがやはり必要になります。
では、どこに線を引けばいいのでしょうか。
コミュニティから生まれた実践的な工夫
スレッドには、この問いへの答えになりそうな工夫がいくつも投稿されていました。
譲れないルールだけをCLAUDE.mdに残す
短い「非交渉事項」のセクションを、CLAUDE.mdに置く。
そして、残りはモデルの判断に委ねる。
これが穏当な折衷案として支持を集めていました。
トピックではなく、失敗の代償で分ける
あるユーザーの整理は、さらに具体的です。
インラインに残すのは、失敗すると取り返しがつかないルールだけ。
たとえば「本番データに対して書き込みテストを実行しない」といったものです。
「出典を確認してから引用する」も、この類に入ります。
なぜなら、スキルファイルを読み込んだ後にしか出会えないルールでは遅すぎるからです。
一方、ハウススタイルや書式、ドメイン固有の手順はツリー側へ移します。
それらが意味を持つのは、すでにそのドメインに入っているときです。
そして、そのタイミングでちょうどファイルが読み込まれます。
スタイル適用を後処理に回す
コードスタイルのルールを先頭に置くと、モデルが過剰反応します。
そして、妙な挙動をしてしまうのです。
そう感じていたユーザーは、発想を逆転させました。
まず、モデルに自由に書かせます。
仕上がった段階で、リンタースキルを人間側から呼び出して整形するのです。
このスキルには、モデルから自動起動しない設定を付けておきます。
ツールの数を絞る
ツール定義そのものを減らす方向の報告もありました。
あるユーザーは、ツールを29個から14個へ絞りました。
すると、キャッシュされるプレフィックスが約40%縮んだそうです。
1セッション50ターンの積み重ねで考えれば、削減効果は無視できません。
古いルールは「傷跡」になる
このスレッドで印象的だったのは、蓄積したルールを「傷跡（scar tissue）」と呼ぶ表現です。
CLAUDE.mdに溜まっていくルールの多くは、古いモデルの欠点への対処でした。
しかし、モデルは賢くなりました。
いまとなっては、それらの行は助けになりません。
逆に、モデルと戦っています。
だからこそ、/doctorのような監査機能が地味に効くという評価でした。
ただし、反対の見方もあります。
あるユーザーは、複数のモデルを使い分けています。
それでも、モデル固有の記述は一切持っていないそうです。
新しいモデルが違う挙動を見せるのは、たいてい指定不足が原因です。
古いモデルがたまたまデフォルトでやってくれていた。
だから、書く必要に気づかなかっただけ。
やってほしいことを明確に書けば、新しいモデルは直せます。
しかも、古いモデルを壊しません。
この見方に立てば、古いプロンプトが新モデルを壊すわけではないのです。
単に、無駄なかさ増しだったということになります。
「意図」と「指示」を分けて書く
将来を見据えた提案も出ていました。
コンテキストに書く内容を、2種類に分けるという考え方です。
1つは、成果に対する自分の意図や要望。
もう1つは、その意図をモデルに実現させるための具体的な指示です。
前者は、モデルが変わっても通用します。
後者は、モデルごとに作り直しが必要です。
しかし、いずれツールが自動生成してくれるだろう、という見立てでした。
ツールに何をさせるかではなく、自分が何を望むかを書く。
シンプルな助言です。
しかし、モデルの世代交代を何度もくぐり抜けるための本質を突いています。
まとめ
AnthropicはClaude 5世代に向けて、Claude Codeのシステムプロンプトを約80%削減しました。
ハードルールを捨てて、モデルの判断を信頼する。
そして、コンテキストは必要なときに必要な分だけ読み込む。
コミュニティの評価は、遅すぎたくらいの正しい変更だというものでした。
一方で、課題も残っています。
複数モデルの併用や、コンテキストファイルの再構築です。
当面の現実解は、折衷案でしょう。
譲れないルールを少数だけ残して、あとは判断に任せる形です。
そして長期的には、モデルに依存しない「意図」を自分の言葉で残しておくことが効いてきます。
プロンプト設計の常識が、モデルの進化に追い越される。
私たちは、その瞬間をリアルタイムで見ているのかもしれません。
あなたのCLAUDE.mdにも、もう存在しないモデルのための傷跡が残っていないでしょうか。
一度、棚卸ししてみることをおすすめします。
