出典: Claude by Anthropic

結論から言うと、Claude Code自身のシステムプロンプトは80%以上削られ、それでもコーディング評価で測定可能な性能低下はなかったとAnthropicは報告しています。CLAUDE.mdが数百行に膨らみ、「禁止事項」の箇条書きばかりになっていないでしょうか。指示を足すほど賢くなるはず、という前提が、Claude 5世代のモデルでは崩れつつあります。この記事では、Anthropicが公開した新しい指針の中身と、自分のCLAUDE.md・スキルを今日どう見直すかを具体的に整理します。

Claude Codeのシステムプロンプトが80%以上削減された

Anthropicは2026年7月24日、公式ブログ The new rules of context engineering for Claude 5 generation models を公開しました。Claude Opus 5やClaude Fable 5といったClaude 5世代のモデル向けに、Claude Codeのシステムプロンプトを大幅に削ったという内容です。

同ブログによると、システムプロンプトの80%以上を削除しても、コーディング評価（coding evaluations）で測定可能な性能低下はなかったとされています。指示を減らしたのに性能が維持された、という点がこの発表の核心です。

具体的な削減量については、約800トークンから164トークンへ減ったと複数の海外メディアが報じています。ただしAnthropic公式ブログ本文でこの数値がそのまま明記されているかは確認できていないため、参考値として捉えるのが安全です（2026-08-07時点）。

そして重要なのは、Claude Codeのシステムプロンプト自体は非公開で、読者が直接いじれるものではないという点です。私たちが実践できるのは、この設計思想を自分のCLAUDE.md・カスタムエージェント・スキルに応用することです。

何が変わったのか｜6つの転換をやさしく解説

公式ブログは、コンテキスト設計の変化を6つの転換として整理しています。旧アプローチと新アプローチを並べると、方向性がはっきり見えてきます。

出典: Claude by Anthropic

とくに効いているのが「ルール→判断」です。禁止事項を並べるほどモデルの自由度は下がり、想定外のケースで硬直します。一般的な判断基準を一つ与えるほうが、結果的に望ましい出力に近づくという考え方です。

表の「手動メモリ→自動メモリ」は、CLAUDE.mdを都度手動で書き換えて情報を残していた運用から、作業中に得た関連情報をClaudeが自動的に記憶する仕組みへの移行を指します。「単純な仕様書→リッチな参照物」は、箇条書きだけの簡素な仕様書ではなく、背景や理由まで含んだ情報量の多い参照資料を渡すことで、モデルがより妥当な判断を下せるようにする発想です。

なぜ性能が落ちなかったのか｜コンテキストエンジニアリングとprompt engineeringの違い

結論を先に言うと、削られた指示の多くはモデルが自力で妥当な判断を下せる範囲のものであり、明示的なルールで縛らなくても質を保てたためです。

前提として、context engineering（コンテキストエンジニアリング）はprompt engineeringとは別の規律とされています。prompt engineeringが1回のリクエストへの指示を最適化する作業であるのに対し、後者は複数リクエストにわたって再利用されるコンテキスト全体の設計を指します。

出典: Claude by Anthropic

対象はシステムプロンプト・Skills・CLAUDE.md・メモリなど複数ソースに及びます。つまり「1つのプロンプトを磨く」のではなく、「どの情報を、いつ、どの層に置くか」を設計する話に変わったわけです。

現場の感触も同じ方向を示しています。Claude CodeのエンジニアリングリードであるThariq Shihipar氏は、AI Engineer World’s Fairでのチャットで「例示を削除したことは非常に有効だった。モデルは我々が与えた例より創造的だったから」と述べています（Simon Willison氏のレポート、2026-07-21投稿）。

同席したCat Wu氏は、”always verify”のような絶対的表現はエッジケースで壊れやすいため、”most of the time…”のような柔らかい表現に和らげる（soften the prompt）べきだと指摘しています。絶対命令の多用は、むしろ品質を下げうるということです。常に成り立つよう書かれた命令は、想定外の状況に出会った瞬間に「命令通りにはできない」という矛盾を起こし、かえって不自然な振る舞いを招きやすいと考えられます。

実務者が今すぐできること｜CLAUDE.md・スキルの見直し手順

手順1: /doctorで現状を棚卸しする

Claude Codeには /doctor コマンドがあり、公式ブログではこれを使ってスキルやCLAUDE.mdを「rightsize（適正なサイズに調整）」できると案内されています。まずは現状の分量を把握するところから始めましょう。

手順2: CLAUDE.mdを「落とし穴」中心に軽量化する

公式ブログはCLAUDE.mdを軽量に保つことを推奨しています。リポジトリの用途を簡潔に説明したうえで、大部分のトークンをコードベース内の落とし穴、つまり非自明な制約に割く形が理想です。逆に、自明な事柄は書かないよう述べられています。

手順3: 頻出手順はSkillsに切り出す

コードレビュー手順やリリース作業のような、毎回は不要だが時々必要になる情報は、CLAUDE.mdに常駐させずSkillsへ移します。必要になった時だけ読み込ませる段階的開示が、Claude Code自身が採った方針です。

手順4: 指示同士の矛盾を洗い出す

見落としやすいのが、システムプロンプト・ツール説明・ドキュメント間の食い違いです。公式ブログでも、「適切にドキュメントを残せ」と「コメントを追加するな」が同居する矛盾例が示されています。

出典: Claude by Anthropic

削ってよい指示・残すべき指示の見分け方

とはいえ、何でも削ればよいわけではありません。ビジネス実務寄りに指針を整理している bosio.digital の考え方を参考に、4つのテストで仕分けると判断しやすくなります。

残すべき代表例は、ブランドボイス、価格の下限、承認権限の線引き、機密保持ルールなどです。これらはコードベースを読んでも導出できず、間違えた時のコストも大きいためです。

一方で「変数名はキャメルケース」「セミコロンを付ける」といった、フォーマッタやLintが自動で直す類の指示は削減候補になります。判断基準は「モデルが推測できないか」と「失敗が高くつくか」の2軸です。

知っておきたい制限・注意点

読み進める前に、次の3点は押さえておいてください。

• 削減幅の解釈にはブレがある: 開発者Pawel Huryn氏の分析では、メモリ機能が無効なら2,686語→514語（約80%減）だが、有効時は830語（約70%減）にとどまるという指摘があります（Qiitaの二次紹介記事経由で確認、2026-08-07時点）。この分析が正しければ、「削除」というより「条件付きロードへの置き換え」という側面が強いことになります。第三者による再検証であり一次情報ではないため、公式の主張と併せて幅を持って受け止めるのが妥当でしょう。
• APIや旧世代モデルではそのまま当てはまらない可能性がある: APIを直接利用する場合や旧世代モデルを併用している場合、今回の指針がそのまま当てはまらない可能性があります。モデルごとに挙動が異なりうる前提で、自分の環境で小さく試すことをおすすめします。
• コスト削減の話と混同しない: トークン削減がそのままコスト削減に直結するという論調も見られますが、Anthropicが具体的な料金改定を約束した公式発表ではありません。仕様は変動しうるため、公式ブログで最新情報を確認してください。

まとめ｜今日から試すべきこと

今回の発表は「指示を足すほど賢くなる」という前提の見直しを迫るものです。Claude Code自身が80%以上のシステムプロンプトを削り、それでもコーディング評価で性能低下はなかったとされている以上、私たちのCLAUDE.mdにも削減余地があるはずです。

まずは /doctor を実行して現状を確認し、CLAUDE.mdを1ファイルだけ軽量化してみてください。禁止事項の列挙を1つの判断基準に置き換え、時々しか使わない手順をSkillsへ移すだけでも変化を体感できます。

削るときは4つのテスト（導出可能性・自動検出・常識性・失敗コスト）を通し、ブランドボイスや承認権限のような導出できない指示は必ず残しましょう。小さく試して、出力の質を自分の目で比べてみてください。