🧠 コンテキスト工学 — プロンプトエンジニアリングはもう古い？Anthropicが示すAIエージェント設計の新常識

📖 「プロンプト」から「コンテキスト」へ — パラダイムシフトの兆し

2023年頃まで、AIを上手に使う技術といえば「プロンプトエンジニアリング」でした。「この言葉を入れればいい」「この順番で書けば精度が上がる」——まるで魔法の呪文を探すような試行錯誤の時代です。

しかし2025年、AIエージェントが本格的に実用化され始めると、見えてきたものがありました。「どんな言葉を使うか」よりも「どんな情報を渡すか」が圧倒的に重要だということに。

Anthropicは2025年9月、この変化を明確に定義しました。新しい概念の名前は「コンテキストエンジニアリング（Context Engineering）」。プロンプトエンジニアリングの「次」の形です。

🔍 「コンテキスト」とは何か？

LLM（大規模言語モデル）に渡されるすべてのトークンが「コンテキスト」です。具体的には：

• システムプロンプト — AIに与える基本的な指示書
• ツール定義 — AIが使える道具の説明書
• MCP（Model Context Protocol） — 外部システムとの接続情報
• 外部データ — 検索結果、データベースクエリの結果など
• 会話履歴 — これまでのやり取りすべて

つまり、あなたがChatGPTやClaudeに入力している「質問文」は、コンテキストのほんの一部に過ぎません。AIエージェントの場合、背後で大量の情報が自動的にコンテキストに詰め込まれています。

ここで大切なのが、コンテキストは有限の「アテンション予算」だという考え方です。LLMが一度に処理できる情報量には上限があり、1トークン増えるたびにその予算は少しずつ消費されていきます。

⚠️ なぜコンテキストの設計が重要なのか

ここで一つ、直感に反する事実があります。コンテキストに情報をたくさん詰め込めば詰め込むほど、AIの精度は下がるのです。

この現象には名前がついています。「Context Rot（コンテキスト腐敗）」。針を干し草の山から探すベンチマーク実験で確認された現象で、コンテキストウィンドウ内のトークン数が増えるほど、モデルが正確に情報を引き出せなくなるというものです。

なぜこうなるのか。理由はTransformerアーキテクチャの構造にあります。Transformerはすべてのトークン同士の関係性を計算する仕組みで、トークン数がn個あれば、計算すべき関係性はn²になります。100個のトークンなら10,000組。1,000個なら1,000,000組。情報が増えれば増えるほど、一つ一つの関係性への「注意」が薄まってしまうのです。

実はこれ、人間のワーキングメモリとそっくりな問題です。人間も一度に覚えられる情報量には限界がありますよね。デスクに書類を100枚広げても、結局どこに何があったか分からなくなる。AIも同じなんです。

🧩 効果的なコンテキストの解剖学

では、どうやって限られた予算を最大限に活かせばいいのか。Anthropicは3つの重要な要素を解説しています。

📝 システムプロンプト — 「Goldilocks Zone」を狙え

システムプロンプトの最適な書き方は、童話の「ゴルディロックスと三匹のクマ」に例えられています。熱すぎず、冷たすぎない、ちょうどいい温度。

ある極端では、プロンプトにif-elseのような複雑な条件分岐をぎっしり詰め込むエンジニアがいます。脆くて、メンテナンスが大変で、少し状況が変われば壊れる。

もう一つの極端では、「適当に頑張って」というような曖昧な指示しか与えないケース。AIは具体的なシグナルを受け取れず、期待通りの動きができません。

最適なのはその中間。行動をガイドするのに十分具体的で、柔軟性を残すのに十分な余裕がある状態。Anthropicは、XMLタグやMarkdownヘッダーでセクションを分けることを推奨しています。

🔧 ツール設計 — 最小セットの法則

AIエージェントにたくさんのツールを与えれば与えるほど便利になる——と思いきや、逆効果です。

Anthropicが指摘する最も一般的な失敗パターンは「どのツールを使うべきか迷ってしまう」状態。ここで胸に手を当ててほしいのですが、人間のエンジニアが「この状況ならツールAかな？ツールBかな？」と迷うなら、AIエージェントも同じように迷うのです。人間以上に賢い判断ができるわけではありません。

したがって、ツールは機能の重複がない最小限のセットに絞るべき。各ツールが自己完結していて、エラーに強く、目的が明確であることが重要です。

💡 例示の科学 — エッジケースを詰め込まない

Few-shot prompting（例を提示する手法）は今でも有効なテクニックです。しかし、よくある失敗があります。

それはありとあらゆるエッジケースの例をプロンプトに詰め込むこと。「この場合こうして、あの場合こうして、それからあの時は……」と延々と続けても、AIは混乱するだけ。

Anthropicが推奨するのは逆のアプローチです。少数の多様で典型的な例を厳選すること。LLMにとって、例は「千語に値する絵」なのです。少数でも良い例があれば、AIはそこからパターンを読み取って未知の状況にも対応できます。

🚀 Just-in-Time検索の革命

ここからがこの記事のハイライトです。AIエージェントの設計において、情報の取得方法そのものが変わろうとしています。

従来のアプローチは「事前に全部ロードする」でした。推論の前に埋め込みベクトルで関連情報を検索し、全部コンテキストに詰め込む。いわば、試験前に教科書を全部暗記してから試験会場に向かうようなものです。

新しいアプローチは「Just-in-Time（必要な時に必要な分だけ）」。エージェントは軽量な参照情報（ファイルパス、クエリ、リンクなど）だけを持ち、実行時に必要に応じてデータを動的にロードします。

Claude Codeはこの方法の代表例です。CLAUDE.mdファイルは事前にコンテキストに読み込まれますが、コードベースの探索にはglobやgrepを使って必要なファイルだけをその場で取得します。巨大なデータベースを分析する際も、全部をコンテキストに入れるのではなく、クエリを書いて結果だけを取得。

考えてみれば、人間の認知と同じです。私たちは本の内容を全部暗記しません。目次と索引を知っていて、必要な時に該当ページを開く。フォルダ構造や命名規則も重要な手がかりになります。test_utils.pyというファイルがtests/フォルダにあるのかsrc/core_logic/にあるのかで、意味が全然違いますよね。

もちろん、すべてをJITにするのが常に正解ではありません。ハイブリッド戦略が最適解です。静的で変わらないデータ（プロジェクトの基本ルールなど）は事前にロードし、動的に変わるデータ（コードの最新状態など）は実行時に取得する。スピードと柔軟性のバランスを取るのがコツです。

⏳ 長時間タスクの3つの解決策

AIエージェントが数十分、あるいは数時間にわたって作業を続ける場面を想像してください。大規模なコード移行や、包括的なリサーチプロジェクトなど。こうした長時間タスクでは、トークン数がコンテキストウィンドウの上限を超えてしまいます。

「コンテキストウィンドウが大きくなれば解決するのでは？」と思うかもしれません。しかしAnthropicは明言しています。ウィンドウがどんなに大きくなっても、コンテキストの汚染と情報の関連性の問題は消えないと。ではどうするのか。3つの技術があります。

1️⃣ Compaction（圧縮）

会話がコンテキストウィンドウの上限に近づいたら、内容を要約して新しいコンテキストウィンドウで再開する手法です。

Claude Codeの実際の実装では、モデル自身にメッセージ履歴を要約させます。アーキテクチャの決定事項、未解決のバグ、実装の詳細は保持し、冗長なツール出力や古いメッセージは捨てる。圧縮後は「要約＋直近5つのファイル」だけで作業を続けられます。

コツは「何を残すか」の選択。小刻みすぎる圧縮は、後になって重要だったと分かる情報を捨ててしまうリスクがあります。最も安全で軽い圧縮はツール呼び出し結果のクリア。一度使ったツールの生の結果は、履歴の深いところで見る必要がありませんからね。

2️⃣ Structured Note-taking（構造化メモ）

エージェントが定期的に外部ファイルにメモを書き込む手法。このメモは後でコンテキストウィンドウに読み戻されます。

この手法の面白い事例が「Claude Plays Pokémon」です。ClaudeがポケモンをプレイするというTwitchプロジェクトで、エージェントは何千ものステップにわたって正確な記録を維持していました。「過去1,234ステップの間、1番道路でポケモンを訓練している。ピカチュウは目標の10レベルに対して8レベル上がった」といった具合に。

何も指示していないのに、エージェントは探索した地域のマップを作成し、達成したキー成果を記録し、戦闘の戦略ノートまで残しました。コンテキストがリセットされた後でも、自分のメモを読み直して何時間ものトレーニングやダンジョン探索を継続できたのです。これは、コンテキストウィンドウだけで情報を維持していたら絶対に不可能だったことです。

3️⃣ Sub-agentアーキテクチャ

一つのエージェントがプロジェクト全体の状態を維持しようとするのではなく、専門のサブエージェントに集中タスクを任せる手法です。

メインエージェントは司令塔に徹し、各サブエージェントはクリーンなコンテキストウィンドウで作業します。サブエージェントがタスクを完了したら、結果だけをメインエージェントに報告。メインエージェントは結果だけを受け取るので、大量の情報に溺れることがありません。

これは人間の組織と同じです。プロジェクトマネージャーが全コードを一行ずつレビューするのではなく、専門のレビュアーに分担して、結果のサマリーだけを受け取る。効率的ですよね。

🎯 まとめ — 最小の高信号トークンセットを探せ

Anthropicの記事全体を貫く一つの原則があります。

「目的を達成するために必要な、最小の高信号トークンセットを見つけること」

これはシンプルに聞こえて、実践は難しい。でも、この原則に沿って考えることで、AIエージェントの設計は劇的に良くなります。

• システムプロンプトは十分に具体的で、十分にシンプルに
• ツールは最小限の重複ないセットに
• 例示は少数の多様な正準例に
• 情報取得はJIT（必要な時）と事前ロードのハイブリッドで
• 長時間タスクは圧縮・メモ・サブエージェントで対応

そして最後に重要な指摘があります。モデルが賢くなっても、コンテキスト設計の重要性は消えないという点です。どんなに優秀なモデルでも、間違った情報を渡せば間違った答えを出します。良い情報を適切に渡す設計は、モデルの進歩とは独立した価値があるのです。

Anthropicの締めくくりの言葉が胸に刺さります。

「最もシンプルで動くものを作れ。」

過剰に凝ったシステムを作る前に、まず最小限で動くものを作る。そこから失敗を観察し、必要な分だけ改良していく。このアプローチが、今のAIエージェント開発における最良の戦略だと言えます。

情報源: Effective context engineering for AI agents – Anthropic Engineering Blog (2025-09-29)