nonbee.dev
✂️

CLAUDE.md、太らせすぎてない？ — Claude 5 世代のコンテキストエンジニアリング新ルール

Claude CodeAIコンテキストエンジニアリングCLAUDE.md

はじめに

CLAUDE.md、育ててますか？ 筆者は育てています。応答スタイル、ワークフロー、git 運用。「AI にちゃんと動いてほしければ、ちゃんと指示を書く」が常識だったので、真面目な運用のつもりでした。

そこに Anthropic からこんな記事が出ました。いわく、Claude Code のシステムプロンプトを80%以上削除したが、コーディング評価で測定可能な性能低下はなかった。

We removed over 80% of Claude Code's system prompt for models like Claude Opus 5 and Claude Fable 5 with no measurable loss on our coding evaluations.

え、あの丁寧に書いたルールたち、要らなかったの？ という話です。要点をまとめつつ、筆者の CLAUDE.md を新ルールで監査してみます。

元記事はこちら: https://claude.com/blog/the-new-rules-of-context-engineering-for-claude-5-generation-models

TL;DR

Claude 5 世代（Opus 5 / Fable 5 など）向けの「Then → Now」は6つ：

Then（これまで）Now（これから）
ルールを与える判断力に任せる
例をたくさん見せるインターフェースを設計する
全部を先頭に書く段階的開示（progressive disclosure）
大事なことは繰り返すツール説明に一度だけ書く
CLAUDE.md に手動でメモ自動メモリに任せる
Markdown の仕様書HTML・テスト・実コードなどリッチな参照

CLAUDE.md の書き方も明快で、リポジトリの説明は短く、トークンの大半は「ハマりどころ（gotchas）」に使う。ファイルを見れば分かる当たり前のことは書かない、です。

モデルが賢くなったので、縛りが足かせになった

旧世代のモデルは判断力が足りなかったから、細かいルールで縛る必要があった。今のモデルは判断できるので、縛りがむしろ性能を妨げる（hobble する）——これが記事の前提です。

象徴的なのがコードコメントの扱いで、以前は「コメントを書きすぎるな」系の細かいルールが並んでいたのが、今は一文に置き換えられています。

Write code that reads like the surrounding code: match its comment density, naming, and idiom.

個別のルールを列挙する代わりに、判断の基準だけ渡す。指示が重なって矛盾していると、モデルはどれに従うか余計に考え込むので、ルールを減らすこと自体に価値があります。

もうひとつ意外だったのが例示です。few-shot はプロンプトの王道テクだったのに、最新モデルでは例が探索空間を狭める副作用の方が目立つそうです。

With our newest models, we've found that giving examples actually constrains them to a certain exploration space.

代わりに、ツールのパラメータを pending / in_progress / completed のような列挙型で定義するなど、インターフェース自体で使い方を伝えることが推奨されています。例文で教えるのではなく、型で伝える。プログラマには馴染み深い考え方ですね。

筆者の CLAUDE.md を新ルールで監査してみた

筆者のグローバル CLAUDE.md は39行＋rules 23行。軽量な部類だと思っていましたが、新ルールの目で読み返すと「当たり前のこと」系がしっかり混ざっていました。

- Avoid hard-coding values unless absolutely necessary.
- Follow existing patterns in the codebase before introducing new ones.

書いた当時は真面目な指示のつもりでしたが、ハードコードを避けろなんて今の Claude は言われなくてもやります。削除候補です。

一方で、残す価値を確信したのがハマりどころのメモです。筆者の環境には「cmux 経由の Claude Code は .zshrc を読まないので、環境変数は .zshenv に置く」という一行があります。ファイルシステムをいくら眺めても分からない、踏んだ人間だけが知っている情報。トークンを使うべき gotcha はこういうやつです。

実は昨日、これを地で行く出来事がありました。ブログのデプロイ時に velite --watch がビルドと並走して本番が一瞬404になる罠を踏み、その場でデプロイ手順のスキルに「デプロイ前に watch を止める」と追記したんです。CLAUDE.md やスキルはこういう傷の記録になっていくのが正しい姿なんだと腑に落ちました。

なお、記事では CLAUDE.md とスキルの「右サイズ化」を手伝う /doctor コマンドも紹介されています。ターミナルの claude doctor はインストール診断のみで、右サイズ化はセッション内の /doctor が本命のようです。実際に整理を実行したら続報を書きます。

所感

少し前に書いた auto mode の記事と構図が同じだと思いました。あちらは「権限プロンプトの97%を人間は読まずに承認していた」でしたが、今回も、丁寧にルールを書いて安心していたのは人間の側で、モデルの役には立っていなかった可能性がある。

とはいえ書く仕事がなくなったわけではなく、判断基準は渡す、ハマりどころは書く、実物を見せる。教育係からオンボーディング設計者に役割が変わった、というのが筆者の理解です。

まとめ

  • Claude Code のシステムプロンプトを80%以上削除しても、コーディング評価で性能低下なし
  • ルールの列挙をやめて判断基準を渡す。例示は探索空間を狭めるので、型・列挙・パラメータ名で伝える
  • CLAUDE.md は「リポジトリ概要＋ハマりどころ」に絞る。ファイルを見れば分かることは書かない
  • 筆者の監査結果: 「ハードコード避けろ」系は削除候補、「.zshenv に環境変数」系の gotcha は残す
  • セッション内の /doctor が右サイズ化を支援してくれる（試したら続報）

しばらくは CLAUDE.md の断捨離がはかどりそうです。ではまた！