一行でいうと
文脈は、長くすれば賢くなるわけではありません。渡す情報を増やすほど、モデルが正確に思い出す力はむしろ落ちていきます。コンテキストエンジニアリングは、この前提に立って、何を読ませ、何を捨てるかを設計する技術です。
言葉の来歴
この言葉は、Anthropicが作ったものではありません。
最初に言い出したのは、ShopifyのCEOであるTobi Lütkeです。2025年6月19日、X（旧Twitter）にこう投稿しました。
“I really like the term 'context engineering' over prompt engineering. It describes the core skill better: the art of providing all the context for the task to be plausibly solvable by the LLM.”
筆者訳プロンプトエンジニアリングよりコンテキストエンジニアリングという語の方が好きだ。この語の方が本質的なスキルをよく表している。それは、そのタスクをLLMが解決可能な形にするために必要な文脈を全て与える技術だ。
6日後の6月25日、Andrej Karpathyがこの投稿に「+1」を返し、後押ししました。
“+1 for 'context engineering' over 'prompt engineering'. People associate prompts with short task descriptions you'd give an LLM in your day-to-day use. When in every industrial-strength LLM app, context engineering is the delicate art and science of filling the context window with just the right information for the next step.”
筆者訳「プロンプトエンジニアリング」より「コンテキストエンジニアリング」に一票。人々はプロンプトを日常でLLMに与える短いタスク説明と結びつけて考えるが、実用レベルのLLMアプリではコンテキストエンジニアリングこそが、次の一歩のためにちょうど正しい情報でコンテキストウィンドウを満たす繊細な技芸であり科学なのだ。
1週間足らずのやり取りで生まれた言葉が、業界の共通語になりました。Anthropicは、この語を後から採用し、公式の定義を与えた側です。誰が最初に言ったかを正確に辿っておくことは、この講座の誠実さの一部です。
公式の定義
Anthropicは自社のエンジニアリングブログで、コンテキストエンジニアリングにこう輪郭を与えています。推論の間、最適なトークンの集合を選び、保ち続けるための戦略の集合。これが定義です。
目指す先も、はっきりしています。最小限で、かつ信号の濃いトークンの集合です。情報量の多さではなく、密度の高さを狙う考え方です。
プロンプトエンジニアリングが、1回の指示文をどう書くかという離散的な作業だったのに対して、コンテキストエンジニアリングはその指示文を含めて、会話全体を通じて何を読ませ続けるかを設計する営みです。射程が違います。
Context Rot（コンテキストロット）
トークン数が増えるほど、モデルの正確な想起能力は下がっていきます。Anthropicはこの現象をContext Rotと名付けています。
長く渡すほど賢くなるという直感は、ここで外れます。渡した情報の量と、モデルがそれを正確に使いこなす力は、比例しません。むしろ情報が積み上がるほど、今いちばん必要な一点を正確に取り出す精度が落ちていきます。
視点
長くするほど、思い出す力は落ちる
文脈を厚くすることは、賢くすることと同じではありません。渡す情報が増えるほど、モデルが今いちばん必要な一点を正確に取り出す力は、むしろ下がっていきます。
前回扱ったCLAUDE.mdの罠、肥大化すると本当の指示をClaudeが無視するようになるという話も、この現象の一つの現れです。目指すべきは文脈の長さを稼ぐことではなく、信号の濃さを保つことです。
altitude problem（高度の問題）
システムプロンプトや指示書の設計には、避けるべき両極端があります。Anthropicはこれをaltitude problem、高度の問題と呼んでいます。
一方の極端は、複雑で壊れやすいロジックを書き込みすぎることです。細かい条件分岐を全部ハードコードすると、想定していなかった場面で機能しなくなります。もう一方の極端は、曖昧すぎて具体的な信号を何も渡さないことです。方向性だけ示して判断材料を渡さない指示は、結局モデルに賭けているだけになります。
狙うのは、この2つの間のちょうどよい高度です。前回のCLAUDE.mdで見た「この一行を削除したら、Claudeは間違えるか」というテストは、実はこの高度を測る物差しでもあります。細かすぎず、曖昧すぎない一行だけを残す作業です。
長時間の仕事を保たせる3つの技法
長く自律的に働かせたい仕事では、文脈をどう保つかが精度を左右します。Anthropicは3つの技法を挙げています。
長時間の仕事を保たせる3つの技法
Compaction（圧縮）
上限が近づいたら会話を要約し、圧縮した版で再開する。アーキテクチャ上の決定・未解決のバグ・実装の詳細は残し、冗長な出力は捨てる
Structured note-taking（構造化されたメモ書き）
エージェントが節目ごとに、コンテキストの外へ進捗メモを書き残す
Sub-agent architectures（サブエージェント構成）
専門化したサブエージェントが自分のコンテキストで探索し、多くは1000から2000トークンに凝縮した要約だけを返す
最も軽い形のcompactionは、要約するまでもなく、役目を終えたツール結果をその場でクリアすることです。もう要らない情報を消すだけで、同じ効果の一部が得られます。
使い分けの基準もはっきりしています。会話の往復が多いタスクにはcompaction。マイルストーンが明確な反復開発にはnote-taking。並列に探索できる複雑な調査には、サブエージェント構成が向きます。
Claude Codeでは実際にどう動くか
上限が近づくと、Claude Codeは文脈を自動で管理します。公式ドキュメントは、その挙動をこう説明しています。
Claude Code manages context automatically as you approach the limit. It clears older tool outputs first, then summarizes the conversation if needed. Your requests and key code snippets are preserved; detailed instructions from early in the conversation may be lost. （上限に近づくと、Claude Codeは自動で文脈を管理する。まず古いツール出力から消し、それでも足りなければ会話を要約する。あなたの依頼と重要なコードは保たれるが、会話の早い段階で出した詳細な指示は失われることがある）
順番があります。まず古いツール出力が消え、それでも足りなければ会話そのものが要約されます。依頼の中身と重要なコードは残りますが、会話の早い段階で伝えた細かい指示は、消えることがあります。
対処は2つです。CLAUDE.mdに「Compact Instructions」という節を置いておくと、要約されるときにも残しておきたい情報を指定できます。もう一つは、/compact に焦点を渡す使い方です。
$/compact APIの変更に集中して要約して無関係な調査の記録を捨てながら、API設計に関する決定と実装の詳細だけを残して会話を圧縮する。
もう一つ、覚えておくとよい仕様があります。接続したMCPツールの定義は、既定では必要になるまで読み込まれません。つないだだけでコンテキストを消費するわけではない、という話です。
自分の運用に落とす
何を読ませるかと同じくらい、何を読ませないかが効きます。ここまでの回で扱ってきた道具は、実はすべてこの一点に集約されます。
道具の名前は違っても、狙っていることは同じです。信号の濃いトークンだけを、必要な範囲だけ、必要なタイミングで渡す。コンテキストエンジニアリングは、この講座でここまで学んできた個々の道具の使い方を、一段上から束ねる考え方です。
今日のまとめ
- コンテキストは長くすれば賢くなるわけではない。Context Rotにより、トークンが増えるほど正確な想起能力は下がる
- コンテキストエンジニアリングという語はAnthropic発ではない。2025年6月、Tobi LütkeとAndrej Karpathyの6日間のやり取りから広まった
- 長時間の仕事はcompaction・structured note-taking・sub-agent architecturesの3技法で保たせる。使い分けの基準は往復の多さと探索の並列度
明日のアクション
今使っているClaude Codeのセッションを1つ思い出してください。
そこで、(1) 今も残っている情報のうち、もう役目を終えているものは何か (2) その情報が今も文脈に残り続けることで、想起の精度を落としていないか、の2点を確認します。
思い当たる情報があれば、/compact に焦点を渡すか、思い切って /rewind で会話ごと戻してみてください。
次は、失敗したときに戻れる仕組み、Checkpointsです。