Claude 5世代のcontext engineering — Claude Codeがプロンプトを8割削った理由

背景 — 8割削っても評価が落ちなかった

Claude Codeのシステムプロンプトは、Claude Opus 5とClaude Fable 5向けに8割以上が削られました。コーディング評価に測定できる低下はなかった、とAnthropicのThariq Shihipar氏は2026年7月24日の開発者ブログで書いています。

削った理由は「制約のかけすぎ」です。内部利用のトランスクリプトを読むと、1つのリクエストの中でシステムプロンプト・Skills・ユーザーの依頼が食い違う例が見つかっています。「ドキュメントは適宜残す」と「コメントは書かない」が同居する、といった具合です。

Claudeは意図を汲んで正解にたどり着けます。ただ、重なり合う指示や矛盾する指示の整合を取るために、より多く考える必要が出ます。かつては最悪の事態を避けるために要った制約も、周囲の文脈と判断力に任せて消せる場面が増えた、というのが出発点です。

定石の見直しは6つあります。実行中の文脈管理はAnthropicのContext Engineering論が扱っており、この記事は実行前から置いてある指示を削る話です。6つの中身と、手元のCLAUDE.mdやSkillsへの当てはめ方を順に追います。

ルールで縛るより、判断に任せる

最初の見直しは、禁止や既定値を並べる書き方です。Claude Codeの旧システムプロンプトには、次の趣旨の記述がありました。

• コードでは、既定ではコメントを書かない
• 複数段落のdocstringや複数行のコメントブロックは書かない(最大1行)
• ユーザーが求めない限り、計画・決定・分析の文書を作らない

これらは一部の依頼では誤りになる指示です。ユーザーに独自の流儀がある場合や、複雑なコードの一部に複数行の説明が要る場合です。それでも旧モデルでは、ガードレールがないとコメントが不適切になるケースが多く、このトレードオフは受け入れるしかありませんでした。

新しいシステムプロンプトでは、これが1文になりました。

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

禁止事項の列挙から、周囲のコードに合わせるという基準1つへの置き換えです。基準が1つなら、他の指示と衝突しにくくなります。

CLAUDE.mdに「コメントは書くな」「1関数は20行以内」のような一律の規則を積んできたなら、同じ見直しが効きます。例えば次のように、規則を基準に言い換える形が考えられます(ブログの例を手元に当てはめた一例で、公式の推奨文面ではありません)。

# 変更前
- コメントは書かない
- docstringは1行まで
 
# 変更後
- 周囲のコードのコメント密度・命名・慣用に合わせる
- 例外: src/billing/ は税計算の根拠をコメントで残す

例外は具体的な場所とともに書くほうが、一律の禁止より衝突が少なくなります。

使用例を並べるより、道具の形を考える

ツールの使い方には使用例を添えるのが定石でした。最新のモデルでは、使用例がかえって探索の範囲を狭めます。

代わりに考えるのは、ツールやスクリプト、ファイルの設計です。Claudeにどんなパラメータを渡せるか、それをもっと表現力のある形にできないか、という問いになります。

例はTodoツールです。status を pending / in_progress / completed の列挙にするだけで、使い方の見当がつきます。「in_progress は1件だけにする」という指示が、期待する挙動を定めます。説明を足すのではなく、取りうる値そのものが説明になる設計です。

自作のスクリプトやMCPツールにも当てはまります。自由記述の文字列で受けていた引数を、取りうる値が限られた列挙にできないか。この問いが、使用例を何本も書くより先に来ます。

全部を最初に置かず、必要な時に読ませる

Claude Codeは、コードレビューや検証の詳細な手順もシステムプロンプトに入れていました。毎回は要らないが、要るときには欠かせない情報です。

その後Claude Codeは、適切なタイミングで適切な文脈を読み込むことが得意になりました。検証とコードレビューは、必要なときだけ呼ばれる独立したSkillに移されています。

この考え方はツールにも広がっています。一部のツールは遅延読み込み(deferred loading)で、エージェントがToolSearchで完全な定義を検索してから使います。Taskツール群のように数を増やしても、必要になるまでコンテキストを占めません。

CLAUDE.mdやSKILL.mdを「あらゆる実践の置き場」にしてしまう思い込みがあります。見つけてもらえないのが不安で全部を書き込む、という動機です。代案は、必要な時に読み込めるファイルのツリーを作ることです。

CLAUDE.mdからSkillsへ手順を移す際のコスト面は、CLAUDE.mdをSkillsに移行してコストを削減する方法が具体的です。

繰り返しをやめ、使い方はツール説明に書く

旧モデルは、指示を繰り返さないと聞き漏らすことがありました。コンテキストの先頭より、末尾の指示に従いやすい傾向もありました。

そのためシステムプロンプトの本体にもツールへの言及があり、ツール説明にも同じ指示がある、という二重管理が生じていました。新世代のモデルでは、この重複を削っても問題が出なくなりました。使い方はシステムプロンプトではなくツール説明に書きます。

自分でエージェントを組む場合も、ツールの使い方を説明する場所は1か所に決められます。同じ指示を2か所に置くと、片方だけ更新されて食い違うリスクも生まれます。

記憶と仕様書の置き場所が変わった

記憶はCLAUDE.mdから自動メモリへ

かつては # キーで、記憶したい内容をCLAUDE.mdに書き込むよう勧めていました。今は、作業やユーザーに関係する内容をClaudeが自動で保存します。

Claude Codeのドキュメントでは、自動メモリは4種類のメモを残します。ユーザーの役割や好みを残す user、訂正や確認済みの進め方を残す feedback、コードやgit履歴から導けない進行中の作業を残す project、外部の情報の場所を残す reference です。コードから導ける内容と、CLAUDE.mdに既にある内容は保存しません。

CLAUDE.mdは「手で書く指示」、自動メモリは「Claudeが自分用に書くメモ」と役割が分かれます。

仕様書はMarkdownからHTMLアーティファクト、コード、ルーブリックへ

プランモードでは、プランをMarkdownファイルに保存してClaudeに参照させてきました。長いプロジェクトでは、仕様書をコードベースに置く方法もありました。

Claudeは、より複雑な参照物を扱えるようになりました。Markdownの代わりに、アーティファクト機能で作ったHTMLを参照できます。参照物はコードの形でも構いません。詳細なテストスイートや、別のコードベースにある移植元の関数も仕様になります。

ルーブリックも参照物の一種です。「良いAPI設計とは何か」のような好みを、ルーブリックとして渡します。Claudeは動的なワークフローで検証用のエージェントを立ち上げ、そのルーブリックで確かめられます。

層ごとに何を書くか

組み立てた文脈は、層ごとに書く内容が変わります。

CLAUDE.mdに書く価値があるのは、たとえば型定義を1つの巨大なファイルにだけ置く構成です。こうした「見れば分かるとは限らない決まり」に、トークンの大半を使います。検証手順が複数あるなら、検証用Skillを作ってCLAUDE.mdから参照します。

参照物は @ でファイルを指定して渡します。コードはClaudeがよく知る言語で書かれた高精度な指示になるため、参照物はコードの形を選ぶのが基本です。デザインの説明文やスクリーンショットよりHTMLのモックアップのほうが良い結果になりやすい、という例が挙がっています。

手元の設定を見直す手順

これらの指針は claude doctor に組み込まれ、Claude Code内の /doctor でSkillsやCLAUDE.mdを適正化できます。Claude Codeのドキュメントでは、役割が3つに分かれています。

prompt-auditはバンドルされた /claude-api Skill経由で動くため、skillOverrides でそのSkillをオフにしている場合や disableBundledSkills を設定している場合は使えません。

/doctor prompt-audit
/doctor prompt-audit .claude/skills/deploy

1行目は既定の範囲(CLAUDE.md、CLAUDE.local.md、AGENTS.mdと、.claude/ および ~/.claude/ 配下のrules・skills・commands・subagents・output styles)を点検します。2行目はパスを渡して1つのSkillだけを点検する形です。結果は所見と修正案のレポートで返り、適用を頼むまでファイルは変わりません。

/doctor 側のCLAUDE.md点検は、ディレクトリ構成や依存の一覧、アーキテクチャの概要のようにコードから導ける内容を削る提案をします。落とし穴・理由づけ・ツールの既定と違う規約は残します。この基準は、ブログが言う「落とし穴にトークンを使う」と同じ向きです。常時読み込まれる残りの指針を、必要な時だけ読み込まれるSkillやネストしたCLAUDE.mdへ移すことも提案されます。

Skillごとの文脈コストと利用頻度は /skill-doctor で見られます。使い方はClaude Codeのskill-doctorの使い方にあります。

Claude 5世代で、文脈づくりは盛る作業から削る作業へ

2025年9月のAnthropicの記事は、長時間エージェントを動かす手段として、必要な時に取りに行く方式、圧縮、ノート、サブエージェントを挙げていました。詳しくはAnthropicのContext Engineering論にあります。そこで主に扱ったのは、実行中に文脈をどう管理するかです。

今回のブログが扱うのは、実行前から置いてある静的な層を削る話です。盛る話から削る話へ、扱いの向きが反転しています。

旧モデル向けに足した規則は、モデルが変わると安全網ではなく、他の指示と衝突する原因になります。削減幅の大きさより、自分たちの旧来の記述を点検し直す姿勢のほうが、手元の設定を直す手がかりになります。

注意点もあります。8割削減と評価に差がないという結果は、Opus 5とFable 5のコーディング評価についてです。他のモデルや他の用途での結果は示されていません。Claude Codeでは、モデルによって短縮版のシステムプロンプトが既定になる仕組みがあり、これはClaude CodeのSIMPLE_SYSTEM_PROMPTで扱っています。手元でも、Haikuなど別のモデルを使うエージェントに同じ削り方を当てる前に、自分の評価で確かめるのが無難です。

まとめ

Claude 5世代のcontext engineeringは、足すことより、衝突しそうな指示を減らすことに重心が移っています。ブログの主張を実作業に落とすと、見直しの手がかりは3つです。

• 「〜するな」の一律規則は、基準1つ+具体的な例外に書き換えられないか
• CLAUDE.mdの内容のうち、コードを読めば分かるものはないか
• 毎回は要らない手順が、常時読み込まれる場所に残っていないか

最初の一歩は /doctor prompt-audit で、古い指示と矛盾を一覧にすることです。結果を見てから、削る箇所を決められます。