コンテキストエンジニアリングとは何か
コンテキストエンジニアリングとは、AIに毎回渡される「前提情報の設計」を指す言葉です。Anthropic の定義ではシステムプロンプト・スキル・CLAUDE.md・メモリなど、利用者が打ち込むプロンプト以外の情報源から組み立てられる文脈のすべてが対象になります。
プロンプトとコンテキストの違い
プロンプトとコンテキストは別物として設計する
両者の違いは「使い回されるかどうか」です。プロンプトはその場限りなので思い切り具体的に書けます。一方コンテキストは多数のリクエストに横断して適用されるため、同じようには具体化できません。利用者がどんな依頼をしてくるか分からないまま、汎用の指針を用意する。そこが難しいところです。
厄介なのはこの最適解が、モデルの進化とともに動くことです。かつて有効だった書き方が、新しい世代では逆効果になります。今回の公表はその転換点が来たという報告でした。
But when you send a message to Claude, the prompt is only a small part of the context it gets. Much of your context is assembled from your system prompt, Skills, CLAUDE.md files, memory, and other sources. We call this context engineering, and it makes a big impact on the results you generate when using Claude Code or in building your own agents. ／ Unlike a prompt, context is used generally across many requests, so it cannot be as specific. How do you build these general prompts and guidance for Claude, especially when you don't know what a user's prompt might be? — コンテキストの構成要素、およびプロンプトとの性質の違いに関する記述より
システムプロンプトを8割削っても劣化しなかった
もっとも目を引く数字がこれです。AnthropicはClaude Opus 5 や Claude Fable 5 のような新世代モデル向けに、Claude Code のシステムプロンプトを80%以上削りました。それでも自社のコーディング評価に測定可能な損失は出ていません。
原因として挙げられているのは Claude Code を過剰に制約していたことです。社内の利用ログを読み返したところ、1つのリクエストの中で矛盾する指示が複数見つかりました。たとえば「必要に応じてドキュメントを残せ」という指示と「コメントを書くな」という指示が、システムプロンプト・スキル・利用者の依頼の間で衝突していたといいます。
モデルは利用者の意図を汲んで正解にたどり着けますが、そのために重なり合った矛盾する指示を先に整理しなければなりません。この整理コストが丸ごと無駄だった、という構図です。かつては最悪のケースを避けるために必要だった制約も、いまは削って周辺の文脈と判断に委ねられる、と説明されています。トークンの消費そのものを見直す観点はClaude Codeの起動トークン消費の記事でも扱っています。
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. ／ Overall, we found that we were overconstraining Claude Code, both through our system prompt and in our CLAUDE.md files and skills. ／ Generally, Claude can interpret the user's intent to get to the right answer, but Claude must think more carefully about these overlapping and conflicting messages before deciding what to do. — 削減の実績および過剰制約に関する記述より
入れ替わった6つの常識
公式ブログはこれまでのベストプラクティスのうち6つが「神話（myths）」になったとして、Then（かつて）とNow（いま）の対で示しています。まずは全体像から。
コンテキストエンジニアリングの Then → Now（6項目）
| # | かつての常識（Then） | いまの常識（Now） |
|---|---|---|
| 1 | ルールを与える | 判断に委ねる |
| 2 | 使用例を見せる | インターフェースを設計する |
| 3 | 先に全部載せる | 必要になったら読み込む |
| 4 | 繰り返し書く | ツールの説明を簡潔に1箇所へ |
| 5 | CLAUDE.mdに記憶を書く | 自動メモリに任せる |
| 6 | 単純な仕様書 | 情報量のある参照物 |
①ルールで縛るのをやめ、判断に委ねる
Claude Code の提供開始当初はファイルを消してしまうような最悪のケースを避ける必要がありました。そのため常に正しいとは限らない強い指示を、あえて置いていたといいます。旧システムプロンプトには「コードでは既定でコメントを書くな。複数段落のdocstring（関数の先頭に置く説明文）や複数行のコメントブロックは絶対に書くな。短い1行だけにしろ」といった文言が入っていました。
しかしこの指示は一部の依頼では明確に間違いになります。利用者に独自の好みがある場合や、複雑なコードに複数行の説明が要る場合です。古いモデルではこうしたガードレール（暴走を防ぐための強制ルール）がないとコメントの品質が保てず、トレードオフを飲むしかありませんでした。
新しい世代のモデルは判断力が上がり、明示的なルールなしでもこの種の決定をうまく扱えます。そこで新しいシステムプロンプトでは、指示が1文に置き換わりました。「周囲のコードと同じように読めるコードを書け。コメントの密度・命名・書き癖を合わせろ」。禁止の列挙から基準の提示への転換です。
In code: default to writing no comments. Never write multi-paragraph docstrings or multi-line comment blocks — one short line max. Don't create planning, decision, or analysis documents unless the user asks for them — work from conversation context, not intermediate files. ／ In the new system prompt we say: Write code that reads like the surrounding code: match its comment density, naming, and idiom. — 旧システムプロンプトの文言と、新しい文言の対比より
②使用例をやめ、インターフェースを設計する
ツールの使わせ方で最重要とされてきたのは「使用例を見せること」でした。ここも反転しています。新しいモデルでは使用例がかえって探索の範囲を狭めてしまうと分かったためです。
代わりに推奨されているのはツールやスクリプト、ファイルそのものの設計を考えることです。どんなパラメータを渡せるのか、それをどうすればより表現力のある形にできるのか。労力の向け先をそちらへ移します。
公式が挙げている例が分かりやすいので紹介します。Todoツールでは状態を pending・in_progress・completed という列挙型（取りうる値をあらかじめ限定した型）にしておくだけで、使い方のヒントが伝わります。そのうえで「in_progress は常に1つに保つ」という一言を添えれば、求める振る舞いが定義できます。長い使用例を並べるより、型と短い制約のほうが強く効くということです。
The number one rule for tool usage was to give Claude examples on how to use them. With our newest models, we've found that giving examples actually constrains them to a certain exploration space. Instead of using examples, think more about the design of your tools, scripts and files- what parameters does Claude have and how can they be more expressive? — 使用例からインターフェース設計への転換に関する記述より
③先出しをやめ、必要になったときに読み込む
Claude Code のシステムプロンプトにはコードレビューや検証の詳しい手順が書き込まれていました。常に要る情報ではないものの、要るときには決定的に重要だったからです。
いまは違います。Claude Code が「適切なタイミングで適切な文脈を読み込む」ことに十分に習熟したため、検証とコードレビューはそれぞれ独立したスキルへ切り出され、必要なときだけ呼ばれるようになりました。この考え方は progressive disclosure（段階的開示）と呼ばれます。
対象はスキルだけではありません。ツールにも「遅延読み込み」が適用され、一部のツールは使う前に検索して定義を取りに行く方式になりました。使われるまで文脈を消費しないまま、ツールの数を増やせます。自分の CLAUDE.md やスキルにも同じ考えが使えます。「見つけてもらえないから1箇所に全部集めておく」というのはよくある誤解で、正しくは適切なタイミングで読み込めるファイルの木を作ることです。
Since then, Claude Code has gotten very competent at using progressive disclosure- loading the right context at the right times. For example, we moved verification and code review into their own skills that Claude Code could selectively call. ／ A common myth is that you want to make these a central repository for every known practice that you might run into, because Claude would not find it otherwise. Instead, consider having a tree of files that can be loaded at the right time. — 段階的開示への転換と、集中管理という誤解に関する記述より
残り3つの転換（繰り返し・記憶・参照）
前章の3つが設計思想の話だとすれば、残りの3つはより実務寄りの変更です。いずれも「二重に持っていたものを片方に寄せる」という共通の形をしています。
④繰り返し指示をやめ、ツールの説明に一本化する
以前のモデルは指示を繰り返さないと従わないことがありました。文脈の最初より最後にある指示のほうが効きやすい、という傾向もありました。そのためシステムプロンプトの中にツールへの言及を置き、さらにツールの説明にも指示を書く二重構造になっていたといいます。
この重複は削除できることが分かりました。ツールの使い方はツールの説明側に書き、システムプロンプトからは外す、という一本化です。同じことを2箇所に書かないだけの話ですが、①で述べた「矛盾する指示」の温床が確実に減ります。
Earlier Claude models could sometimes need repeated instructions or be more likely to listen to instructions at the end of their context window than at the start. This meant our system prompt would sometimes have references to tools in the main system prompt as well as instructions in the tool description. ／ We found we could delete these repeat examples and put instructions on how to use tools in the tool descriptions rather than the system prompt. — 旧モデルにおける指示の位置の効きやすさ、および重複の削除に関する記述より
⑤CLAUDE.mdへの手書き記憶をやめ、自動メモリに任せる
かつては # ホットキーで CLAUDE.md へ書き込み、記憶として残す運用が推奨されていました。いまは Claude が作業や利用者に関連する事柄を自動的に記憶するため、手で書き溜める必要が薄れました。CLAUDE.md を記憶の置き場として使うのをやめ、後述する「落とし穴の記述」に用途を絞るのが新しい形です。
We used to encourage users to save things to Claude's memory, by using the # hotkey to write to their CLAUDE.md automatically. Instead, Claude now automatically saves memories that are relevant to the work and to you. — 手書きの記憶から自動メモリへの転換に関する記述より
⑥単純な仕様書をやめ、情報量のある参照物を使う
プランモードでは計画を Markdown ファイルとして保存し、必要なときに参照させる運用が一般的でした。長期のプロジェクトなら、仕様をコードベース内に置いておく方法も定番です。
いまはもっと複雑な参照物を扱えます。単純な Markdown ではなく、Claude が生成する成果物であるアーティファクト（HTML形式の生成物）も参照させられます。仕様をコードの形で与えるのも有効で、詳細なテストスイートや、他のコードベースにある移植元の関数がそのまま仕様になります。
さらに「ルーブリック（評価基準表）」という形もあります。良いAPI設計とは何かという判断基準をルーブリックで渡し、検証役のエージェントに基準へ沿っているか確かめさせる、という使い方です。
But we've found that Claude can handle increasingly more complicated references. Instead of simple markdown files, Claude can reference HTML artifacts created by our new artifacts feature. ／ You may also give Claude references in the form of code. A spec may also be a detailed test suite, or a function in a different codebase that Claude might port. ／ Rubrics are another form of references. Rubrics allow Claude to try and verify your taste in a particular field (e.g. what does a good API design look like) by using dynamic workflows and spinning up verifier agents with those rubrics. — 参照物の高度化・コードによる仕様提示・ルーブリックに関する記述より
自分のCLAUDE.mdとスキルをどう削るか
ここまでは Anthropic 側の話です。では、自分の設定をどう見直せばよいのか。公式ブログはコンテキストの構成要素ごとに指針を示しています。
構成要素ごとの書き方の指針
CLAUDE.mdは「自明でないこと」にトークンを使う
CLAUDE.md についての指針は明確です。リポジトリが何のためのものかは簡潔に書き、トークンの大半はコードベース内部の「落とし穴」に充てます。たとえば「型定義は1つの巨大なファイルにまとめており、他の場所には置かない」といった、その組織固有の約束事です。
逆に避けるべきは、ファイルシステムやリポジトリを見れば分かる「自明なこと」です。トークンを食うだけでなく、①で述べた矛盾の温床にもなります。検証手順のように独自の指示が複数あるなら、CLAUDE.md に書き連ねず検証スキルとして切り出し、CLAUDE.md から参照させます。
Keep your CLAUDE.md lightweight and briefly describe what your repo is for, but spend most of the tokens on gotchas inside of the codebase. … Avoid stating 'the obvious' things Claude should know by looking at your file system or your repo. — CLAUDE.md に何を書き、何を書かないかに関する記述より
スキルは軽いガイドとして書き、長ければ分割する
スキルは「必要になったときに情報を見つけるための軽いガイド」と捉えるよう示されています。重要度が特に高い領域を除けば、過剰に制約しないほうがよいとされています。長いスキルは段階的開示を効かせるため、複数のファイルへ分割します。
スキルが最も効くのは、自分やチーム、製品に固有の見解・知識・慣行を記録したときだとされています。一般論を書き写す場所ではない、ということです。
参照物についても指針があります。ファイルは @ で言及して参照に含められますが、一般にはコードの形になっているファイルを優先すべきだとされています。Claude がよく理解している言語で、明確かつ高い忠実度の指示になるからです。デザインについては説明文やスクリーンショットより、HTML のモックアップのほうが良い結果を生むと具体例が挙げられています。
Think of skills as lightweight guides to let Claude find information when needed. Avoid making them overconstrained, except in highly important areas. ／ Generally you should prefer files that are in code as it provides clear, high-fidelity instructions to Claude in a language it knows very well. — スキルの書き方と、参照物にコードを優先すべき理由に関する記述より
/doctor コマンドで機械的に見直す
手作業ですべてを読み直す前に、用意されている道具を使う手があります。Anthropic はこの記事で示したベストプラクティスを claude doctor に組み込んでおり、Claude Code の /doctor コマンドでスキルと CLAUDE.md の分量を適正化できると案内しています。
削る作業そのものは地道です。自分のシステムプロンプトやスキル、CLAUDE.md を横断して重複と自明な記述を落としていきます。公式も、自分たちが行ったのと同じ簡素化が利用者側でも必要になるかもしれない、と書いたうえでこのコマンドを案内しています。
コンテキストを削る作業では、削除前後でどれだけ分量が変わったかを把握しておくと判断の材料になります。トークン数の厳密な計測はモデルごとに違いますが、文字数の増減を押さえるだけでも「どのファイルが重いか」の当たりは付きます。
無料ツール文字数カウントテキストの文字数・単語数・行数をリアルタイムでカウント。レポートやSNS投稿に。今すぐ使ってみる →
We've put these best practices in `claude doctor;` use the command /doctor in Claude Code to rightsize your skills, and CLAUDE.md files. ／ Across your system prompt, skills, and CLAUDE.md files, you may need to simplify just like we did. We rolled out a new command called `claude doctor,` which will help you do this automatically as well. — `/doctor` コマンドの用途と、利用者側でも簡素化が必要になる旨の記述より
まとめ：コンテキストエンジニアリングは「足す」から「減らす」へ
コンテキストエンジニアリングの新ルールは、結局のところ1行に収まります。モデルの判断力が上がったぶん、人間が書く前提情報は減らせる。長く書くほど良い結果が出るという前提が逆転しました。まずそこを受け入れるのが出発点になります。
Anthropic 自身が Claude Code のシステムプロンプトを8割以上削って測定可能な劣化を出さなかった以上、手元の CLAUDE.md やスキルにも同じだけの余地はあるはずです。まずは /doctor を通し、そのうえで「ファイル構成を見れば分かること」と「2箇所に書いてあること」から削る。この順序が着手しやすいと思います。
ただしこれは Opus 5・Fable 5 世代での結果です。古い世代のモデルを併用しているなら、同じ削減がそのまま通るとは限りません。手元で削るときは、削除前後の分量を測って効果を確かめながら進めるのが確実です。
無料ツール文字数カウントテキストの文字数・単語数・行数をリアルタイムでカウント。レポートやSNS投稿に。今すぐ使ってみる →
