システムプロンプトの8割を削っても性能が落ちない — Claude 5世代の「コンテキストエンジニアリング新ルール」を読む

筆者は Claude Code を日々の業務に使うなかで、CLAUDE.md（プロジェクトごとの指示ファイル）に指示を書き足すたびに「この指示はどこまで細かく書くべきなのか」という迷いを抱えてきました。2026年7月24日、Anthropic はこの問いに正面から答える記事 “The new rules of context engineering for Claude 5 generation models” を公式ブログで公開しました。執筆者は同社技術スタッフの Thariq Shihipar 氏で、翌25日（日本時間）には本人のXアカウント（@trq212）にも全文が投稿されています。本記事はその内容を整理して紹介します。掲載する図版はすべて同ポスト（@trq212）に掲載されたものからの引用です（作図: Anthropic）。

結論 — 6つのベストプラクティスが「通説」になった

記事の中心的な報告は次の一文です。

We removed over 80% of Claude Code’s system prompt for models like Claude Opus 5 and Claude Fable 5 with no measurable loss on our coding evaluations.

（Claude Opus 5 や Claude Fable 5 といったモデル向けに、Claude Code のシステムプロンプトの80%以上を削除したが、コーディング評価で測定可能な性能低下はなかった）

そのうえで記事は、旧世代モデルでは有効だったが現在は通説（myth）と化した6つのベストプラクティスを、新しい指針と対にして示しています。

図1: 旧世代モデルの6つのベストプラクティス（左、取り消し線）と Claude 5 世代の新しい指針（右）

以下、前提となる問題意識から順に見ていきます。

前提 — プロンプトとコンテキストは別物である

記事はまず、ユーザーが入力する「プロンプト」と、モデルが実際に受け取る「コンテキスト」を区別します。Claude にメッセージを送るとき、プロンプトはコンテキスト全体のごく一部にすぎず、大部分はシステムプロンプト・スキル・CLAUDE.md・メモリなどから組み立てられます。この組み立てを設計する営みがコンテキストエンジニアリングです。

プロンプトとの本質的な違いは汎用性にあります。プロンプトは目の前のタスクに特化して書けますが、コンテキストは多数のリクエストにまたがって使われるため、ユーザーが何を頼んでくるか分からない前提で書かなければなりません。この「汎用的な指示をどう書くか」という問題の最適解が、モデルの世代交代で大きく動いた——というのが記事の主題です。

束縛を解く（Unhobbling） — 過剰な制約は矛盾を生む

Anthropic が自社内の Claude Code 利用記録を読み返したところ、システムプロンプト・スキル・ユーザーの依頼が衝突し、1つのリクエストの中に矛盾する指示が同居している例が見つかったといいます。記事が挙げるのは「必要に応じてドキュメントを残すこと」と「コメントを追加しないこと（DO NOT add comments）」が同時に存在するケースです。

図2: 1つのコンテキストに矛盾しうる指示が同居する例。Claude はすべてを読み、整合させてから行動を決める必要がある（図中の文言は説明用の例示）

Claude はユーザーの意図を汲んで正しい答えにたどり着けるものの、重複・矛盾した指示があるとその整合に余分な思考を割くことになります。こうした強い制約は、かつてはファイルの誤削除といった最悪ケースを避けるために必要でした。しかし現行世代では、その多くを削除し、周囲の文脈とモデル自身の判断に任せられることが分かった、と記事は述べています。

また、制約を減らせるもう一つの背景として道具立ての変化も挙げられています。かつての Claude Code は記憶・情報・指針の置き場を CLAUDE.md に頼っていましたが、現在はメモリ・アーティファクト・スキルが揃い、セッションをまたいだコンテキストの読み込み・共有の経路が増えています。

6つの転換

1. ルールを与える → 判断に任せる

Claude Code の公開当初は、最悪ケースを確実に避けるため、常に正しいとは限らない強い指示をあえて書いていたといいます。記事が示す旧システムプロンプトの実例がこれです。

In code: default to writing no comments. Never write multi-paragraph docstrings or multi-line comment blocks — one short line max.

（コードでは、既定でコメントを書かないこと。複数段落のdocstringや複数行のコメントブロックは決して書かない——短い1行を上限とする）

この指示は一部のプロンプトに対しては端的に誤りです。ドキュメントについてはユーザー自身の好みがありえますし、非常に複雑なコードの特定箇所には複数行のコメントブロックが必要な場合もあります。それでも旧世代モデルでは、このガードレールなしに書かれるコメントの多くが不適切だったため、トレードオフとして受け入れていた——と記事は説明します。新しいシステムプロンプトでは、同じ箇所が次の一文に置き換えられています。

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

（周囲のコードと同じように読めるコードを書くこと。コメントの密度・命名・慣用に合わせる）

禁止事項の列挙が、判断基準の提示に変わっていることが分かります。

2. 例を示す → インターフェースを設計する

ツールの使い方は例で教える——これがかつてのツール利用の第一のルールでした。しかし最新世代では、例を与えることがかえって探索の幅を狭める（constrains them to a certain exploration space）ことが分かったといいます。

代わりに勧められるのは、ツール・スクリプト・ファイルそのものの設計を見直すことです。Claude に与えるパラメータをより表現力豊かにできないかを考えます。記事はタスク管理ツール（TodoWrite）を例に、status パラメータを pending・in_progress・completed の列挙型として定義するだけで使い方のヒントになり、「in_progress は常に1件まで」という一文が求める挙動を定義する、と説明しています。

図3: TodoWrite ツールの説明の改訂前後。約9,100文字の使用例集が、列挙型と短い制約の設計に置き換えられた

3. すべて前置きに書く → 段階的開示を使う

旧来のシステムプロンプトには、コードレビューや検証の詳細な手順が常に含まれていました。常に必要なわけではないが、必要なときには決定的に重要な情報だったためです。現在の Claude Code は「適切なコンテキストを適切なタイミングで読み込む」段階的開示（progressive disclosure）に習熟しており、検証やコードレビューの手順は独立したスキルに移され、必要時に選択的に呼び出されるようになりました。

段階的開示はスキルに限りません。一部のツールは「遅延読み込み（deferred loading）」となっており、エージェントは ToolSearch というツールで完全な定義を検索してから使います。これにより、使われるまでコンテキストを消費しないツールを多数持てるようになっています。

同じ考え方はユーザー自身の CLAUDE.md やスキルのファイルにも適用できます。「Claude は自力で見つけられないだろうから、遭遇しうるすべてのプラクティスを1つのファイルに集約すべきだ」というのは通説であり、代わりに適切なタイミングで読み込めるファイルのツリーを構成することが勧められています。

4. 繰り返し書く → ツール説明はシンプルに一箇所へ

旧世代モデルには、指示を繰り返す必要があったり、コンテキストの冒頭より末尾の指示に従いやすかったりする傾向があり、そのため同じツールへの言及がシステムプロンプト本文とツール説明の両方に置かれることがありました。現行世代ではこうした重複を削除し、ツールの使い方はツール説明の側に一本化できることが分かったといいます。

5. CLAUDE.md にメモリを書く → 自動メモリに任せる

かつては # ホットキーで CLAUDE.md に覚え書きを追記する運用が推奨されていました。現在は、作業とユーザーに関連する記憶を Claude が自動的に保存する仕組み（auto-memory）に置き換わっています。

6. シンプルな仕様書 → リッチな参照

プランモードの Claude Code は、計画を Markdown ファイルとして保存し、必要時に参照する方式に大きく依存してきました。長期プロジェクトでは仕様書をコードベース内に置く運用も定番でした。しかし現行世代はより複雑な参照物を扱えるようになっており、記事は次の選択肢を挙げています。

• 単純な Markdown ファイルの代わりに、アーティファクト機能で作成した HTML を参照する
• 仕様を「コード」で与える——詳細なテストスイートや、移植元となる別コードベースの関数も仕様たりうる
• ルーブリック（評価基準表）を参照として与える——「良い API 設計とは何か」のような好みを、その基準を持った検証エージェントを立てて確認させる

自分のコンテキストにどう適用するか

記事の後半は、以上をコンテキストの層ごとの指針にまとめ直しています。

図4: 組み立てられるコンテキストの層。プロンプトの下に参照・システムプロンプト・CLAUDE.md・スキル・メモリが重なる

• システムプロンプト: 製品の文脈と強く結びつく層で、Claude がどの製品の中で何をしているのかを伝えます。Claude Code の利用者が触ることはまずありませんが、自前のエージェントを構築する場合は最も時間をかけるべき場所とされています
• CLAUDE.md: 軽量に保ち、リポジトリの目的は簡潔に。トークンの大半は、コードベース内の「落とし穴」（例: 型定義は単一のファイルに集約し、他の場所には置かない、といったそのリポジトリ固有の約束事）に使います。ファイルシステムやリポジトリを見れば分かる自明なことは書きません。検証手順のような詳細は独立したスキルに切り出し、CLAUDE.md からは参照だけを張ります
• スキル: 必要なときに Claude が情報を見つけるための軽量なガイドと捉えます。極めて重要な領域を除き、過剰な制約は避けます。長いスキルはファイルを分割して段階的開示に寄せ、自分・チーム・製品に固有の意見や知見を書き込むのが最も効果的とされています
• 参照（References）: ファイルを @ メンションして、現在の計画に関する深い情報を渡します。仕様ファイル・モックアップ・コードベース全体などが該当しますが、一般にはコードの形をしたファイルが望ましいとされています。Claude が熟知した言語による明確で忠実度の高い指示になるためで、たとえばデザインの HTML モックアップは、デザインの文章による説明やスクリーンショットより一般に良い結果を生む、と記事は述べています

最後に記事は、システムプロンプト・スキル・CLAUDE.md を自分たちと同じように簡素化してみることを読者に勧め、それを自動で支援するコマンド claude doctor（Claude Code 内では /doctor）を公開したことを紹介して締めくくられています。

まとめ

• Claude 5 世代（Opus 5・Fable 5 など）向けに Claude Code のシステムプロンプトは80%以上削除され、コーディング評価で測定可能な性能低下はなかったと報告されています
• 背景にあるのは過剰制約の問題です。システムプロンプト・スキル・ユーザー依頼の間で指示が重複・矛盾すると、モデルはその整合に余分な思考を割くことになります
• 旧世代で有効だった6つのベストプラクティス（ルールの列挙・使用例の提示・全情報の前置き・指示の繰り返し・CLAUDE.md への記憶・Markdown 仕様書）は通説となり、判断への委任・インターフェース設計・段階的開示・ツール説明への一本化・自動メモリ・リッチな参照に置き換えられました
• ユーザー側の実践は「CLAUDE.md は軽く、落とし穴に集中」「詳細はスキルに切り出して段階的開示」「仕様はテストスイートや HTML モックアップなどコードの形で渡す」に要約できます
• 既存の設定の簡素化を支援するコマンドとして claude doctor（/doctor）が提供されています

参考

• The new rules of context engineering for Claude 5 generation models — Claude Blog（2026年7月24日、執筆: Thariq Shihipar 氏） — 本記事の主たる出典
• @trq212 on X（2026年7月25日） — 著者本人による同記事の全文ポスト。掲載図版はすべて同ポストからの引用（作図: Anthropic）