Engineering · アーキテクチャ
コンテキスト工学の新ルール — プロンプトを削ると性能が上がる、Claude 5世代が示す6つの設計転換
「コンテキスト工学（Context Engineering）」とは、システムプロンプトに何を書くかではなく、AIモデルが最善の判断を下せるようコンテキスト全体を設計するアプローチ。2026年7月24日、Anthropicは Claude Code のシステムプロンプトを80%以上削除してもコーディング評価での性能低下がなかったと報告し、より有能なモデルほど手厚い指示が逆効果になるという洞察を示しました。
要点
- ✓Anthropicは2026年7月24日、Claude Code のシステムプロンプトの80%以上を削除し、コーディング評価での測定可能な性能低下がなかったと報告した（Thariq Shihipar、claude.com/blog、2026-07-24）。
- ✓旧世代モデル向けに手調整された多数のルール・例示は、Claude 5世代では「ルール競合」を起こし、モデルが本来のタスクより先にルール解釈に推論トークンを消費してしまう。
- ✓新しい設計指針は「薄いシステムプロンプト・厚いアーティファクト（コード・テストスイート・ルーブリック）・薄いスキル（必要時のみ動的注入）」の3層構造（同ブログ、2026-07-24）。
- ✓6つの転換：（1）ルール→判断力、（2）例示→インターフェース設計、（3）一括注入→スキルによる動的開示、（4）重複指示→ツール定義への集約、（5）手動メモリ→自動メモリ、（6）Markdownスペック→コード・テスト・ルーブリックへの置換（同ブログ）。
- ✓この転換はモデルの世代交代のたびに起きうる。旧世代向けのプロンプト資産をそのまま流用することのコスト（競合・推論トークン消費）は、より高性能なモデルほど顕在化する。
プロンプトを削ったら、性能が上がった
2026年7月24日、AnthropicのThariq Shihiparは、一つの実験結果を発表しました。Claude Code のシステムプロンプトの80%以上を削除したところ、コーディング評価での測定可能な性能低下がなかった——それどころか、旧来のルールがモデルの動作を妨げていたことが明らかになったのです（claude.com/blog「The new rules of context engineering for Claude 5 generation models」、2026-07-24）。
この結果は、AIプロンプト設計の常識を覆します。「AIを賢く動かすには、細かく指示を書き込むほど良い」というプロンプト工学の前提が、高性能モデルでは逆効果になることを示したのです。
なぜ削除が機能したのか。旧世代のモデル向けに慎重に手調整されたルールや例示は、当時は最悪ケースを防ぐ「ガードレール」として機能していました。しかし Claude 5世代のような高性能モデルにとって、それらは互いに競合する指示の集合体になっています。モデルは本来のタスクに取り組む前に、どのルールが優先するかを解釈するために推論トークンを消費してしまうのです。Anthropicはこの現象を、制約を外すことでモデルが本来の判断力を発揮できるようにする「アンホブリング（unhobbling）」と表現しています（同ブログ）。
手厚い指示が、賢いモデルの足かせになる
Anthropicが示した6つの設計転換
（B）Anthropicが報告した「コンテキスト工学の新ルール」は、6つの設計転換として整理されています（Thariq Shihipar、claude.com/blog、2026-07-24）。これらは Claude Code チームの知見であり、エージェント設計全般の一般論として参照できます。
- ルール → 判断力へ: 細かいルールで行動を縛るより、目的と文脈を明確に伝えモデルの判断力に委ねる。有能なモデルほど具体的なルールより意図を理解して動ける。
- 例示 → インターフェース設計へ: プロンプト内の few-shot（例示）を増やすより、ツール定義やスキルとして設計する。例示はプロンプト肥大化の主因であり、構造化されたインターフェースで代替できる。
- 一括注入 → スキルによる動的開示へ: すべての文脈を最初からプロンプトへ詰め込む（upfront context）のではなく、スキルを通じて必要な時・必要な範囲だけを注入する（progressive disclosure）。
- 重複指示 → ツール定義への集約へ: システムプロンプトとツール定義の両方に同じ内容を書くのは競合の原因。ツール定義へ集約し、プロンプト側は削る。
- 手動メモリ → 自動メモリへ: CLAUDE.md などの手動管理ファイルによる記憶より、自動メモリ機能へ委ねる。手動管理は古い情報が蓄積して「旧ルール」になるリスクがある。
- Markdownスペック → 豊かな参照へ: 自然言語のMarkdown仕様書より、コード・テストスイート・ルーブリックといった豊かな参照（rich references）を使う。モデルはコードやテストケースをより正確に理解できる。
6つの転換の根底にある思想は「モデルに指示するより、モデルが判断できる環境を整える」という方向への移行です。プロンプト工学が「何を書くか」を最適化していたとすれば、コンテキスト工学は「何を書かないか」と「どこに・いつ・どう与えるか」を設計します。
agens での対応（実装と設計の線引き）
（A）agens のスキル機能は「必要な時だけ注入する動的開示（転換点3）」を体現します。スキルはタスクの文脈に応じてオンデマンドで注入され、使わないスキルはコンテキストを汚しません。（A）自動メモリはセッションをまたいだ情報を自動管理し、手動管理ファイルへの依存（転換点5）を軽減します。（A）サンドボックス内のアーティファクト——コード実行結果・生成ドキュメントなど——は「厚い参照（転換点6）」として機能し、プロンプトへの自然言語記述の代わりに豊かな文脈をモデルへ提供します。（B）6転換点はAnthropicの報告であり、業界の設計方向性を示す一般論として参照しています。
Claude 5世代がエージェント設計に与える含意
コンテキスト工学の転換は、Claude 5世代モデル（Opus 5・Fable 5）で特に顕著です。Anthropicは2026年7月24日、Opus 5を発表。高度なエージェント・コーディング・コンピューター操作のタスクを担う新モデルとして位置づけています（claude.com、2026-07-24）。
Anthropicはこの転換に伴い「/doctor」コマンドも提供しています。このコマンドは、既存のスキルファイルやCLAUDE.mdを検査し、新世代モデルに適したサイズへの調整を支援します（同ブログ）。旧世代向けに積み上げたルールが新世代モデルでは逆効果になるという問題を、診断ツールとして対処するものです。
（B）一般設計論として: エージェントが使うモデルが世代交代するたびに、最適なコンテキスト構造も変わります。かつて「細かく指示を書けば動く」だったものが「意図を伝えて委ねる」になる——この転換は、エージェント設計を継続的にメンテナンスする必要があることを示しています。過去のプロンプト資産をそのまま流用することのコスト（競合・推論トークン消費）は、より高性能なモデルほど顕在化します。agens が複数のモデルをシームレスに切り替えられる設計を持つ理由の一つは、この世代交代コストを最小化するためでもあります（詳しくは「モデルフリー設計」を参照）。
よくある質問
コンテキスト工学とプロンプト工学の違いは何ですか？
「プロンプトを削ると性能が上がる」はすべてのモデルに当てはまりますか？
「薄いシステムプロンプト」と「厚いアーティファクト」をどう使い分けますか？
agens はコンテキスト工学の原則をどのように反映していますか？
最終更新: 2026-07