原典: The new rules of context engineering for Claude 5 generation models
一行要約
Claude 5 世代では旧世代向けに書いた制約が過剰になっていた —— Claude Code は Opus 5 / Fable 5 向けの system prompt を8割以上削ってもコーディングの評価が落ちなかった。規則を与えるより判断に任せ、例を見せるより道具を設計し、全部を前置きせず必要なときに読ませる。
要点
8割を削っても落ちなかった
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 Opus 5 や Claude Fable 5 のようなモデル向けに、Claude Code の system prompt の80%超を削ったが、コーディングの評価では測れるほどの低下は無かった。
原因は過剰な制約。社内の transcript を読むと、system prompt・skill・ユーザーの依頼が「適宜ドキュメントを残せ」と「コメントを書くな」のように1つのリクエストの中でぶつかっていた。Claude はたいてい意図を汲めるが、重なり合い矛盾する指示を前に、より慎重に考えなければならない。
以前と今（6つ）
| 以前 | 今 |
|---|---|
| 規則を与える | 判断に任せる |
| 例を見せる | インターフェースを設計する |
| 全部を前置きする | 段階的に開示する |
| 繰り返して書く | ツールの説明は簡潔に |
| CLAUDE.md に記憶させる | auto memory |
| 単純な仕様 | 豊かな参照 |
規則 → 判断: 旧 system prompt は「コメントは書かない。複数段落の docstring は書くな、1行まで」と言っていたが、一部の prompt では誤りだった。新しい system prompt の一文:
Write code that reads like the surrounding code: match its comment density, naming, and idiom.
周りのコードのように読めるコードを書け。コメントの密度、命名、慣用に合わせよ。
例 → 設計:
With our newest models, we’ve found that giving examples actually constrains them to a certain exploration space. Instead of using examples, think more about the design of your tools, scripts and files- what parameters does Claude have and how can they be more expressive?
最新のモデルでは、例を与えることがかえって探索の範囲を狭めると分かった。例を使う代わりに、ツール・スクリプト・ファイルの設計を考えよ —— Claude が持つパラメータは何か、それをどうすればもっと表現力のあるものにできるか。
（Todo ツールでは、status を pending / in_progress / completed の列挙にするだけで使い方が伝わり、「in_progress は1つ」の指示が望む振る舞いを定める）
前置き → 段階的な開示: 検証とコードレビューを system prompt から専用の skill に移した。ツールも一部を deferred loading にし、使う前に ToolSearch で定義を探させる。CLAUDE.md や SKILL.md も、知りうる慣行を全部入れる中央リポジトリにするのではなく、適切なときに読まれるファイルの木にする。
繰り返し → 簡潔な説明: 旧モデルは context の終わりの指示によく従ったので、ツールの話を system prompt とツール説明の両方に書いていた。重複を消し、ツールの使い方はツール説明に置く。
単純な仕様 → 豊かな参照: plan の markdown の代わりに、artifacts の HTML、コード、詳細なテストスイート、移植元の関数、rubric（dynamic workflows で検証エージェントに持たせ、好みを確かめさせる）を参照させる。
自分の context に当てはめる
- system prompt —— 製品の context に強く結びつく。Claude Code なら触らないだろうが、自前の harness を作るならここに時間をかける
- CLAUDE.md —— 軽く保ち、リポジトリが何のためのものかを短く書き、トークンの大半をコードベースの落とし穴に使う。ファイルシステムやリポジトリを見れば分かる「当たり前」は書かない。検証の手順が独特なら verification skill を作って CLAUDE.md から参照する
- skill —— 必要なときに情報を見つけるための軽い案内。とても重要な領域以外では縛りすぎない。長いものは多くのファイルに分ける。自分・チーム・製品に固有の意見・知識・慣行を入れるときに最も良い
- 参照 ——
@で含める。コードで書かれたファイルを優先する
For example, a HTML mockup of a design will generally produce better results than a description of the design or a screenshot.
たとえば、デザインの HTML モックアップは、デザインの説明やスクリーンショットより、たいてい良い結果を生む。
/doctor（claude doctor） に、skill と CLAUDE.md の大きさを整えるこれらの慣行が入っている。
そのまま使える具体例
Write code that reads like the surrounding code: match its comment density, naming, and idiom.CLAUDE.md の点検:
- リポジトリの目的は短く、落とし穴に多く書いているか
- ファイルシステムを見れば分かることを書いていないか
- 独特な手順は skill に分け、CLAUDE.md から参照しているか
- 互いに矛盾する指示（system prompt・skill・CLAUDE.md の間）が無いか
原典で言及されている関連文書
- effective-context-engineering-for-ai-agents — context engineering
- a-harness-for-every-task — 適切なときに読まれるファイルの木、dynamic workflows