システムプロンプトの80%を削っても、評価は落ちなかった

Anthropic が2026年7月24日に公開した記事「The new rules of context engineering for Claude 5 generation models」は、かなり思い切った事実から始まる。Claude Opus 5 / Claude Fable 5 といった新世代モデル向けに、Claude Code のシステムプロンプトを80%以上削除したにもかかわらず、社内のコーディング評価に計測可能な劣化が出なかったというのだ。

著者は Claude Code チームの Thariq Shihipar 氏。以前公開された Fable 向けのプロンプティングガイドが「ユーザーが送るプロンプト」を扱っていたのに対し、この記事はプロンプト以外のすべて——システムプロンプト、Skills、CLAUDE.md、メモリ——を対象にしている。

プロンプトと違い、コンテキストは無数のリクエストにまたがって再利用される。だからこそ具体的にしすぎることができず、「ユーザーが何を書いてくるか分からない状態で、どこまで指示を書くべきか」という難しさが生まれる。そしてモデルの能力が上がるたびに、その最適解は動く。

問題は「過剰制約」だった

削減の出発点になったのは、Anthropic 社内での Claude Code 利用ログの読み込みだった。そこで見えたのは、システムプロンプト・Skills・ユーザー指示が互いに衝突している状態だ。

たとえば、同じひとつのリクエストの中に「必要に応じてドキュメントを残せ」という指示と「コメントを書くな」という指示が同居していた。Claude はユーザーの意図を汲んで最終的には妥当な答えに辿り着けるが、その前に「この矛盾をどう解釈すべきか」を考える必要が出てくる。制約が、判断コストを生んでいたということになる。

実際の書き換えも興味深い。旧システムプロンプトは「コメントを書くな」「複数行のコメントブロックや長いドキュメント文字列を書くな」「頼まれない限り計画や分析のファイルを作るな」といった禁止の列挙だった。新しいものは、周囲のコードに馴染むように書け——コメント密度も命名もイディオムも既存コードに合わせろ——という、方針を示す一文に置き換わっている。

6つの「かつて」と「いま」

記事は、これまでベストプラクティスとされてきたものが神話（myth）になったケースを6つ挙げている。

かつて	いま
ルールを与える	判断を委ねる
例を与える	インターフェースを設計する
すべて先頭に載せる	段階的開示を使う
繰り返し書く	ツール説明をシンプルに
CLAUDE.md にメモリを書く	自動メモリに任せる
シンプルな仕様書	リッチな参照

例を与えることが、逆に足かせになる

ツール利用における第一のルールは長らく「使い方の例を与えること」だった。ところが新世代モデルでは、例が探索空間を狭めてしまうことが分かってきた。例に引きずられて、そのパターンの範囲でしか動かなくなる。

代わりに投資すべきなのはインターフェース設計だという。ツール、スクリプト、ファイルが持つパラメータをどう表現力の高いものにするか。記事で挙げられている Todo ツールの例は分かりやすい。

使い方を長々と例示する代わりに、型と制約そのものに意図を埋め込む。API 設計の発想に近い。

段階的開示は、ツール定義にも及び始めた

Claude Code のシステムプロンプトには、コードレビューや検証の手順が詳細に書かれていた。常に必要なわけではないが、必要なときには決定的に重要な情報だ。これらは独立した Skill に切り出され、Claude が必要と判断したときだけ読み込まれるようになった。

さらに踏み込んでいるのがツール定義そのものの遅延ロードだ。一部のツールは定義を最初から context に載せず、ToolSearch で検索して初めて全体像が読み込まれる。これにより、使われないツールがコンテキストを圧迫しない状態で、ツールの総数を増やせる。

この考え方は CLAUDE.md や SKILL.md にもそのまま適用できる。「あとで見つけられないかもしれないから、起こりうることを全部書いておく」という発想は逆効果で、適切なタイミングで読み込まれるファイルのツリーを設計するほうが良い、というのが記事の主張だ。

仕様書はコードで書くほうが伝わる

プラン機能では markdown ファイルに計画を保存するのが定番だったが、Claude はより複雑な参照を扱えるようになった。HTML アーティファクト、詳細なテストスイート、別のコードベースにある移植元の関数——いずれも仕様として機能する。

ルーブリックも参照の一形態として挙げられている。「良い API 設計とは何か」といった判断基準をルーブリックとして与え、検証エージェントを立ち上げて確認させる。好みや美意識を、検証可能な形に落とし込むアプローチだ。

レイヤー別の実践指針

これらを踏まえて、自分のコンテキストをどう組み立てるか。記事は4つのレイヤーに分けて整理している。

CLAUDE.md については具体例も示されている。「型定義を1つのモノリシックなファイルに集約していて、他の場所には置かない」といった、ファイルシステムを眺めるだけでは分からない規約レベルの情報を書く。逆に、リポジトリを見れば分かることを書くのは無駄になる。検証手順が複数あるなら、verification skill として切り出し、CLAUDE.md からは参照するだけにする。

References で印象的なのは、デザインの指示なら説明文やスクリーンショットより HTML モックアップのほうが良い結果になるという指摘だ。Claude が最もよく知っている言語で、高い忠実度の指示を渡せるからだという。

削る前に、測る

ここが一番大事なところだと思う。Anthropic が80%を削り切れたのは、削った結果を測る評価基盤があったからだ。評価を持たずに同じことをすれば、それは単に指示を減らしただけになる。

記事の最後には /doctor コマンドが紹介されている。Claude Code 上で実行すると、Skills や CLAUDE.md を適正なサイズに整理する手助けをしてくれる。まずはこれをかけて、自分のコンテキストがどれだけ膨らんでいるかを見るところから始めるのが現実的だろう。

ハーネス設計から見たときの読みどころ

「コードで強制できるものはコードに」という設計方針でハーネスを組んでいる立場からすると、この記事の「ルールで縛るな、判断を委ねろ」という主張は一見すると正面衝突しているように見える。

ただ、よく読むと対象が違う。ゲートの通過条件、lint、テストの成否といった検証可能な事実はコードで強制すべきで、hooks やスクリプトが担うべき領域だ。一方で「コメントをどう書くか」「どういう構造にするか」といったスタイル判断は、明示ルールで縛るより周囲のコードに合わせさせたほうが良い。両者を切り分ければ矛盾しない。

むしろ実務的に効くのは、ツール定義の遅延ロード（ToolSearch）と、ルーブリック × 検証エージェントの組み合わせだろう。前者は MCP のツール数上限とコンテキスト圧迫という現実的な問題への公式側の回答であり、後者は人間のレビューゲートを部分的に自動化するための素材になる。