はじめに
2026年7月24日、Claude Opus 5 の発表と同日に、Anthropic の公式ブログで「The new rules of context engineering for Claude 5 generation models」という記事が公開されました。著者は Thariq Shihipar 氏（Anthropic, Member of Technical Staff）です。
この記事の目玉は、次の一文に集約されます。
removed over 80% of Claude Code's system prompt ... with no measurable loss on our coding evaluations
Claude 5 世代モデル向けに Claude Code のシステムプロンプトを80%以上削除しても、コーディング評価で測定可能な劣化がなかった、という実測報告です。細かいルールを書き連ね、例を大量に貼り、あらゆる情報を前置きする ── これまで筆者を含む多くの人が積み上げてきたコンテキストエンジニアリングの「定石」が、モデルの世代交代によって見直しを迫られています。
本記事では、この公式ブログの内容を一次情報ベースで整理し、2025年9月の旧公式ガイダンス「Effective context engineering for AI agents」との差分と、今日から自分の CLAUDE.md や Skill に反映できるポイントをまとめます。
この記事で分かること
- Anthropic が示した「旧ルール → 新ルール」6つの転換
- System Prompt / CLAUDE.md / Skills / References の4層コンテキスト設計
- 2025年の旧ガイダンスから何が変わり、何が変わっていないか
対象読者
- Claude Code / Cowork で CLAUDE.md や Skill を運用している人
- システムプロンプトが年々肥大化していて薄々まずいと思っている人
前提知識
- Claude Code の基本操作（CLAUDE.md、Skill、ツール定義あたりの用語が分かる程度）
なお、掲載先は anthropic.com ではなく Anthropic の製品ブログ claude.com/blog です。Medium に同名の非公式まとめ記事も存在するので、参照する際は URL を確認してください。
背景：なぜ「ルールの山」が積み上がったのか
旧世代のモデルは、放っておくと最悪ケースを踏むことがありました。消してはいけないファイルを消す、頼んでいないリファクタリングを始める、コメントを書きすぎる。だから運用側は「〜するな」「必ず〜せよ」というガードレールをプロンプトに積みました。筆者の CLAUDE.md にも、過去のヒヤリハットの数だけ禁止事項が堆積しています。
Anthropic はこの構造を逆転させました。記事の全体テーマは "Unhobble Claude"（Claude の足枷を外す） です。Claude 5 世代（Opus 5 / Fable 5）はニュアンスのある判断を自力でこなせるため、過剰な制約や互いに矛盾する指示はガードレールではなく性能の足枷として働く、という主張です。80%削減の実測は、その裏付けとして提示されています。
本論1：旧ルール → 新ルール、6つの転換
記事が挙げる転換を Before / After で整理します（出典はすべて本体記事）。
| # | 旧ルール | 新ルール |
|---|---|---|
| 1 | ルールを与える | 判断を委ねる |
| 2 | 例を与える | インターフェースを設計する |
| 3 | 全部前置きする | 段階的開示（progressive disclosure） |
| 4 | 大事なことは繰り返す | ツール記述に一本化 |
| 5 | CLAUDE.md への手動メモリ | 自動メモリ |
| 6 | 単純な Markdown 仕様書 | リッチな参照物 |
1. ルールを与える → 判断を委ねる
記事の例が分かりやすいです。旧来は "default to writing no comments"（デフォルトでコメントを書くな）のような厳格ルールを書いていたところを、新世代では次のように書き換えます。
Write code that reads like the surrounding code: match its comment density, naming, and idiom.
「コメント禁止」ではなく「周囲のコードに合わせよ」。ルールの列挙をやめて判断基準を渡す、という転換です。禁止事項の網羅は原理的に終わらないのに対し、判断基準は1行で無数のケースをカバーします。
2. 例を与える → インターフェースを設計する
few-shot でツールの使用例を並べるより、ツールの型設計そのもので意図を伝えるほうが効く、という主張です。記事の例では、Todo ツールのステータスを自由文字列ではなく enum（pending / in_progress / completed）にすること自体が、どんな使用例よりも正しい使い方を規定します。
// 使用例を10個書くより、この型定義のほうが雄弁
interface TodoItem {
content: string;
status: "pending" | "in_progress" | "completed";
}
これは MCP サーバーやツールを自作している人にはそのまま効く話で、「説明とサンプルを盛る」より「パラメータ空間を狭く正しく切る」が先です。
3. 全部前置きする → 段階的開示
検証手順やコードレビュー手順をシステムプロンプトに常駐させるのをやめ、必要になったときに Claude 自身が読みに行ける Skill に分離します。あわせて、ツール定義を必要時にだけ完全ロードする deferred loading（ツール検索）、CLAUDE.md や Skill をツリー構造に分割して適切なタイミングで読み込ませる構成が推奨されています。
ここで筆者が思い出したのが、Vercel の評価記事「AGENTS.md outperforms skills in our agent evals」です。Vercel の実験では「Skill はそもそも呼ばれない」（評価ケースの56%で未呼び出し）ことが弱点で、常時コンテキストの AGENTS.md が勝つ結果でした。今回の Anthropic の記事は、その呼び出し判断の精度がモデル側で改善したことを前提に、段階的開示へ寄せ直す提案だと読めます（Anthropic の記事自体が Vercel の評価に言及しているわけではなく、ここは筆者の解釈です）。つまりどちらへ倒すべきかはモデル世代依存であり、固定の正解として暗記しないほうがよさそうです。
4. 繰り返す → ツール記述に一本化
「重要な指示はシステムプロンプトとツール説明の両方に書く」という冗長化をやめ、ツールの使い方はツール定義側にだけ書きます。二重管理は矛盾の温床でもあるので、保守の観点でも素直な整理です。
5. 手動メモリ → 自動メモリ
# ホットキーで CLAUDE.md に手動追記していた記憶管理から、Claude が文脈上重要なことを自動で保存する方式への移行が示されています。CLAUDE.md は「人間が意図を持って書く薄いファイル」に回帰していく流れです。
6. 単純な仕様書 → リッチな参照物
Markdown の計画書1枚を渡すのではなく、HTML モックアップ、仕様として機能するテストスイート、他コードベースの参照実装、評価基準を定めた rubric、さらに verifier エージェントを組み込んだワークフローなど、忠実度の高い参照物を渡すことが推奨されています。「デザインの文章説明やスクリーンショットより HTML モックのほうが良い」という指摘は、実感とも一致します。
本論2：4層のコンテキスト・アーキテクチャ
記事は、コンテキストを次の4層で組み立てることを提案しています。
- System Prompt: 作っているプロダクトに強く依存する動作環境の記述。
- CLAUDE.md: 軽く保つ。リポジトリの目的と gotcha（落とし穴）中心。自明なことは書かない。
- Skills: チームやプロダクト固有の意見・ベストプラクティスをエンコードした軽量ガイド。長くなったら複数ファイルに分割して段階的開示。
-
References:
@メンションで渡す詳細情報。コード参照を優先し、デザインは HTML モックで。
あわせて、Skill や CLAUDE.md が肥大化していないかを診断して「適正サイズ化（rightsize）」する /doctor コマンドも紹介されています。なお、筆者は本稿執筆時点で /doctor を未検証です（記事内の紹介ベース）。
2025年の旧ガイダンスから、何が変わって何が残ったか
2025年9月の「Effective context engineering for AI agents」を読んで運用してきた人向けに、差分を整理します。
残った考え方：コンテキストは有限資源（attention budget）であり、長くなるほど想起精度が落ちる（context rot）。目指すのは "the smallest possible set of high-signal tokens"。just-in-time な情報取得、長時間タスクでの compaction、コンテキスト外へのノート永続化（agentic memory）、サブエージェントによるコンテキスト分離 ── この土台は変わっていません。
変わった点：旧ガイダンスは「ハードコードされた脆いロジックと曖昧すぎる指示の間の適切な高度（Goldilocks zone）を探せ」というバランス論でした。新ルールはそこから一歩進んで、明示ルールの大半を能動的に削除し、判断そのものをモデルに委ねる方向に振り切っています。バランス点が「書く量を最適化する」から「消せるだけ消す」へ動いた、と言えます。
ハマりどころ
1. 「80%削減」を自分の環境にそのまま外挿しない。 原文は "no measurable loss on our coding evaluations" と限定付きです。Anthropic 内部のコーディング評価での結果であり、手元のワークロードで同じ削減率が安全という保証はありません。消すなら評価（手元のスモークタスクでも可）とセットで段階的に進めるのが安全です。
2. 記事は Claude Code / Claude 5 世代前提。 API を直接叩いて旧世代モデルも併用している場合、ルール撤去は逆効果になり得ます。API 勢の実装パターンとしては、2025年の旧記事と Claude Cookbook のコンテキストエンジニアリング（compaction / memory の実装例）のほうが具体的です。
3. 「消す」対象はルールであって情報ではない。 リポジトリ固有の gotcha、ドメイン知識、非自明な制約はむしろ CLAUDE.md や Skill に残すべき中身です。消すのは「モデルが自力で判断できることへの指図」であって、「モデルが知り得ないこと」ではありません。ここを混同すると必要な文脈まで失います。
4. 削減の前にバックアップと差分管理を。 システムプロンプトや CLAUDE.md の削減は不可逆な劣化に気づきにくい変更です。git 管理下で少しずつ削り、挙動の変化を観察できる状態でやるのが安全です。
まとめ
- Anthropic は Claude 5 世代向けに Claude Code のシステムプロンプトを80%超削減し、コーディング評価で劣化なしと報告した。テーマは "Unhobble Claude"
- 転換は6つ：ルール列挙→判断委任、例示→インターフェース設計、前置き→段階的開示、繰り返し→ツール記述一本化、手動メモリ→自動メモリ、単純仕様→リッチ参照
- コンテキストは System Prompt / CLAUDE.md / Skills / References の4層で設計し、
/doctorで適正サイズを保つ - attention budget や context rot といった2025年からの土台は不変。変わったのは「最適な量を書く」から「消せるだけ消す」への態度
筆者もまずは自分の CLAUDE.md から、「過去のヒヤリハット由来の禁止事項」を判断基準の1行に置き換えるところから始めてみます。ビフォーアフターはまた別記事にまとめる予定です。
参考
- The new rules of context engineering for Claude 5 generation models（claude.com/blog, 2026-07-24） ― 本記事の一次情報
- Effective context engineering for AI agents（Anthropic Engineering, 2025-09-29） ― 旧公式ガイダンス
- A Harness for Every Task: Dynamic Workflows in Claude Code（claude.com/blog, 2026-06-02） ― verifier エージェント / rubric の背景
- A Field Guide to Claude Fable 5: Finding Your Unknowns（claude.com/blog, 2026-07-06） ― Claude 5 世代との協働パターン
- Claude Code Docs
- Claude Cookbook: Context engineering tools