学習目標:
- プロンプトエンジニアリングとコンテキストエンジニアリングの定義を言い直し、両者が「置き換え」ではなく「進化」である理由を述べる
- 「アテンションバジェット」と「コンテキストロット」という 2 つの考え方を使って、「ウィンドウは十分大きいのだから全部詰め込めばいい」の何が間違っているかを同僚に説明する
- 本シリーズの「Agent Harness Fundamentals: Loops and Control」コースで組んだハーネスのループの中で、コンテキストが増える一方で減らない箇所を指摘する
前提: 本シリーズの「Agent Harness Fundamentals: Loops and Control」コースを終え、stop_reason 駆動のループが手元で動いていること | 次: レッスン2 >>
本シリーズの「Agent Harness Fundamentals: Loops and Control」コースでは、次のようなループを手で書きました（簡略版。最大ターン数や予算などの 4 つの制御バルブはいったん省いてあります）:
あのときの関心はすべて制御フローに向いていました。stop_reason をどう読むか、制御バルブをどう取り付けるか。ここで角度を変えて messages 配列をじっと見てください——この配列は push されるだけで、一度も切り詰められません。1 ターンごとに、少なくとも 2 つのものが入ってきます。そのターンのモデルの返信（tool_use ブロックを含む）と、ツールが返した結果です。かさばるのはたいてい後者です。1 回の list_files が数百件のファイル名を返してくる場面や、ログ検索が数十 KB の生テキストを返してくる場面を思い浮かべてください。それらはその時点から永久にウィンドウに居座り、推論のラウンドごとに最初から読み直されます。
これは実装の手落ちではなく、エージェントというものの性質です。"An agent running in a loop generates more and more data that could be relevant for the next turn of inference"1（ループの中で動くエージェントは、次の推論ターンに関係しうるデータをどんどん生成していく）。しかもエージェントは自律性を握っているため、非常に多くのターンを走り続ける可能性があります2。本シリーズの「プロンプトエンジニアリング基礎: 効果的な指示の書き方」コースでは、1 つの指示を明確に書く方法を学びました——ですが、どれほどうまく書かれた指示でも、それはウィンドウの中の小さな 1 ブロックにすぎません。40 ターン目のエージェントの振る舞いを実際に決めるのは、その瞬間にウィンドウ全体に何が座っているか、です。
いまの観察を形式化すると、2 つの定義が得られます。
プロンプトエンジニアリング: "Prompt engineering refers to methods for writing and organizing LLM instructions for optimal outcomes"1（最適な結果を得るために LLM への指示を書き、構成する手法）。答える問いは「この指示を、最も効果が出るようにどう書き、どう並べるか？」です。
コンテキストエンジニアリング: "the set of strategies for curating and maintaining the optimal set of tokens (information) during LLM inference"1（LLM の推論中に、最適なトークン（情報）の集合を選び、維持するための戦略の集合）。答える問いは「今回の推論では、どのトークンがウィンドウにあるべきで、どれがあるべきでないか？」です。
視点が一段上がっていることに注目してください。前者は一度きりの執筆の問題で、書き上げればそれで固定されます。後者はループが 1 周するたびに答え直さなければならないトレードオフです。Anthropic はコンテキストエンジニアリングを、プロンプトエンジニアリングの自然な発展として明示的に位置づけています——"we view context engineering as the natural progression of prompt engineering"1——ですから、本シリーズの「プロンプトエンジニアリング基礎: 効果的な指示の書き方」コースで積み上げたスキルは、まったく無駄になりません。より大きな問題の部分集合になるのです。システムプロンプトは依然としてうまく書かれなければなりませんが、それはいまや管理すべき多くのコンテキスト要素の 1 つにすぎません。
コミュニティにはもっと過激な見方もあります。2026 年のあるエージェントエンジニアリングのロードマップは "Prompt engineering is dead as a standalone skill in 2026."3 と断言しています。ただしこれはそのロードマップの主観的な断定であり、本レッスンはコンセンサスとしては扱いません——Anthropic の言い回しははるかに慎重で、置き換えではなく進化です1。とはいえ、同じロードマップがコンテキストエンジニアリングに与えた一行の定義は覚えておく価値があります: "deciding what tokens are in front of the model at every step of the loop"3（ループのどのステップでも、どのトークンをモデルの目の前に置くかを決めること）。そして同じロードマップは、ハーネスがどれだけ効くのかも言い当てています: "Same model, different harness, completely different result."3 ——本シリーズの「Agent Harness Fundamentals: Loops and Control」コースの実験を通じて、すでに肌感覚として持っているはずのことです。
なぜこれが管理しなければならない対象なのでしょうか。ウィンドウが大きければ、あとは好きに使えるだけではないのでしょうか。ここで 1 つ目の物理的な事実が出てきます。
"LLMs have an "attention budget" that they draw on when parsing large volumes of context"1（LLM は大量のコンテキストを解析するとき、「アテンションバジェット」から引き出して使う）。厄介なのは、この予算が有限だということです: "Every new token introduced depletes this budget by some amount"1（新しく入ってくるトークンはすべて、この予算をいくらか消費する）。
たとえるなら、ウィンドウの容量は倉庫の床面積で、アテンションバジェットは荷物を探しに送り込む人員です。倉庫を 10 倍に広げても、人員はそれに合わせて増えません——棚が埋まるほど、本当に欲しい 1 点を掘り出すのは難しくなります。「念のため」の資料をもう 1 部ウィンドウに滑り込ませる行為は、無料のバックアップではありません。それを読んで関係ないと判断するコストとして、予算から実際に差し引かれます。
この見方に切り替えると、考え直す価値のある習慣がいくつも出てきます。「ウィンドウに収まるのだから、API ドキュメントを全文貼っておこう」——収まるかどうかは倉庫の話、うまく読めるかどうかは予算の話で、その 2 つは同じではありません。
予算が絶え間なく削られ続けることのマクロな帰結には、鮮やかな名前がついています。コンテキストロット（context rot）——"as the number of tokens in the context window increases, the model's ability to accurately recall information from that context decreases"1（コンテキストウィンドウのトークン数が増えるほど、そのコンテキストから情報を正確に想起する能力は下がる）。
取り違えやすい点が 2 つあるので、ここで釘を刺しておきます。
1 つ目、これは急落ではなく漸進的です。 この劣化は性能の傾斜として現れるのであって——"These factors create a performance gradient rather than a hard cliff"1——あるトークン数を超えた途端に動かなくなる硬い崖ではありません。ですからエラーは一切出ません。エージェントがじわじわ鈍くなるだけです。日常的な言い方をすると（これはエンジニアリングの経験上よく見る現れ方であって、出典に列挙されているわけではありません）、先に確認したはずの規約が忘れられ始め、すでに読んだファイルをまた読み、すでに直したバグが元に戻ります。アラームの鳴らない劣化は、エラーよりも追跡が困難です。
2 つ目、これは特定のモデルの癖ではなく一般則です。 他よりなだらかに劣化するモデルはありますが、"some models exhibit more gentle degradation than others, this characteristic emerges across all models"1（他より穏やかに劣化するモデルもあるが、この性質はすべてのモデルに現れる）。より強いモデルに乗り換えれば問題を先送りできますが、消し去ることはできません。
この 2 つを合わせると、本レッスン最初の礎石が得られます: "context, therefore, must be treated as a finite resource with diminishing marginal returns"1（したがってコンテキストは、限界収穫が逓減する有限の資源として扱わなければならない）。ウィンドウに押し込む 1000 番目のトークンと 10 万番目のトークンは、占める場所は同じでも、上乗せする価値はまるで違います。「多いほど安全」という直感は方向がちょうど逆で、余分に詰め込んだ「保険」の分だけ、本当に大事な情報へのモデルの注意が薄まります。
単発の質疑応答では、コンテキストロットに気づきさえしないかもしれません。ウィンドウは一度使われて捨てられ、トークン数もたいてい危険域には届きません。エージェントはこの問題を「たまに遭遇するもの」から「ターンごとに悪化していくもの」へ変えます。ループの中のデータは増える一方で減らず1、エージェントは自律的に多くのターンを走り続けうるからです2。冒頭のコードを見返してください——push されるばかりで何も返さないあの messages 配列こそが、この過程を具体化したものです。
現場のエンジニアリング経験も完全に一致します。Claude Code の公式ドキュメントは "Claude's context window fills up fast, and performance degrades as it fills."4（Claude のコンテキストウィンドウはすぐ埋まり、埋まるにつれて性能は劣化する）と述べ、コンテキストウィンドウを "the most important resource to manage."4（管理すべき最も重要な資源）と呼んでいます。同じドキュメントには、書き留めておく価値のある観察もあります: "A clean session with a better prompt almost always outperforms a long session with accumulated corrections."4 ——「長く話した」ことは「うまく話した」ことを意味しません。積み上がった訂正も、逸れていった脱線も、すべてウィンドウに座ったまま次のラウンドの推論に参加し続けます。
そこでコンテキストエンジニアリングの正確な位置づけはこうなります。これはチューニング段階で足す仕上げの磨きではなく、エージェントの信頼性の土台です。本シリーズの「Agent Harness Fundamentals: Loops and Control」コースの 4 つの制御バルブが管理するのは「ループを暴走させない」こと。このコースが取り付けるのはもう一組の機構、「ウィンドウを腐らせない」ことです。両方そろって初めて、あなたのハーネスは長時間のタスクを任せられるものになります。
長い時間軸のタスクに対して、Anthropic は 3 種類の技術を挙げています——"compaction, structured note-taking, and multi-agent architectures"（コンパクション、構造化されたノート取り、マルチエージェントアーキテクチャ）。狙いは、エージェントが "maintain coherence, context, and goal-directed behavior over sequences of actions"1（一連の行動を通じて一貫性、コンテキスト、目標志向の振る舞いを保つ）ことです。このコースはその道筋をたどります:
最後に、程度についての注意を 1 つ。ここに挙げた機構はどれも複雑さを増やします。そして Anthropic のエンジニアリングガイダンスはこう言います: "you should consider adding complexity only when it demonstrably improves outcomes."2（複雑さを加えるのは、それが結果を明確に改善すると示せるときだけにすべきである）。ですからこの先のどのレッスンも、「どうやるか」の前に「いつやる価値があるか」を説明します——すべてのエージェントにサブエージェントが要るわけではありませんし、すべてのタスクがコンパクションに値するわけでもありません。
>> レッスン2: コンテキストの解剖: システムプロンプト、ツール、そして例
Effective context engineering for AI agents — Anthropic Engineering — https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16 ↩17 ↩18 ↩19 ↩20
Building Effective AI Agents — Anthropic Engineering — https://www.anthropic.com/engineering/building-effective-agents ↩ ↩2 ↩3 ↩4
The 2026 Agent Engineering Roadmap — GitHub (codejunkie99/agent-roadmap-2026) — https://github.com/codejunkie99/agent-roadmap-2026 ↩ ↩2 ↩3 ↩4
Best practices for Claude Code — Claude Code Docs — https://code.claude.com/docs/en/best-practices ↩ ↩2 ↩3 ↩4
let response = await client.messages.create({
model: MODEL, max_tokens: 1024, tools, messages, // messages 配列に注目
});
while (response.stop_reason === "tool_use") {
messages.push({ role: "assistant", content: response.content });
const toolResults = await runToolUses(response.content, toolImpls);
messages.push({ role: "user", content: toolResults }); // ツール結果も入ってくる
response = await client.messages.create({
model: MODEL, max_tokens: 1024, tools, messages,
});
}