コンテキストエンジニアリングとは──プロンプトエンジニアリングとの違いを整理する

コンテキストエンジニアリングとは、AIに渡す情報全体を目的達成のために継続的に選び取る技術です。Anthropicが2025年9月29日に公開した技術ブログ「Effective context engineering for AI agents」をもとに、プロンプトエンジニアリングとの違いと、圧縮・構造化ノート取り・サブエージェント構成といった具体的な手法を整理します。

コンテキストエンジニアリング（Context Engineering）とは、AIモデルに渡す情報全体──指示文だけでなく、システムプロンプト、ツールの定義、外部データ、会話履歴まで含めた「モデルが参照できる情報の中身」を、目的達成のために継続的に選び取り、整理し続ける作業のことです。Anthropicは2025年9月29日に公開した技術ブログ「Effective context engineering for AI agents」で、この語を「プロンプトエンジニアリングの自然な延長」と位置づけています。背景にあるのは、AIの使われ方が一問一答の対話から、複数ターンにわたって自律的に作業を進めるAIエージェントへと広がったことです。

コンテキストエンジニアリングとは、Anthropicが2025年9月29日の技術ブログで定義した「LLM（大規模言語モデル）に渡すトークン（情報）全体を、目的達成のために継続的に選別する」戦略のこと

Anthropicはこれを「プロンプトエンジニアリングの自然な延長」と位置づけ、両者の違いは「一度書けば完結する指示文づくり」か「モデルに何を渡すか毎回選び直す反復作業」かにある

圧縮（compaction）・構造化ノート取り・サブエージェント構成といった手法が、Anthropic自身のClaude Codeや、ポケモンをプレイするClaudeの実例つきで紹介されている

コンテキストエンジニアリングとは何か

Anthropicは記事の中で、まず「コンテキスト」という言葉自体をこう定義しています。

Context refers to the set of tokens included when sampling from a large-language model (LLM). The engineering problem at hand is optimizing the utility of those tokens against the inherent constraints of LLMs in order to consistently achieve a desired outcome.

（訳: コンテキストとは、大規模言語モデル（LLM）から出力を得る際に含まれるトークンの集合を指す。ここでのエンジニアリングという課題は、LLMが持つ本質的な制約のもとで、望む結果を一貫して達成するために、それらのトークンの有用性を最適化することである。）

そのうえで「コンテキストエンジニアリング」自体はこう説明されています。

Context engineering refers to the set of strategies for curating and maintaining the optimal set of tokens (information) during LLM inference, including all the other information that may land there outside of the prompts.

（訳: コンテキストエンジニアリングとは、LLMの推論中に、最適なトークン（情報）の集合を選び取り、維持し続けるための一連の戦略を指す。プロンプト以外からコンテキストに入り込むあらゆる情報も含む。）

対象は「プロンプト」という一つの入力欄に留まりません。システム指示、ツール定義、Model Context Protocol（MCP、AIと外部ツールをつなぐ規格）、外部データ、会話履歴まで、モデルが参照するすべての情報が対象です。この情報量を数える単位がトークンで、一度に扱える上限が「コンテキストウィンドウ」です。仕組みの詳細は別記事に譲ります。

プロンプトエンジニアリングと何が違うのか

プロンプトエンジニアリングの技法そのもの（Zero-shot・Few-shot・Chain-of-Thoughtなど）はプロンプトエンジニアリング入門ガイドに譲り、ここではAnthropicが挙げる違いに絞ります。

違いは大きく二つです。一つは対象の広さで、プロンプトエンジニアリングは指示文（特にシステムプロンプト）の書き方が中心であるのに対し、コンテキストエンジニアリングはツール定義・外部データ・会話履歴まで含めた情報全体を扱います。もう一つは作業の性質で、Anthropicは「プロンプトを書くという一回限りの作業とは対照的に、コンテキストエンジニアリングは反復的であり、モデルに何を渡すかを決めるたびに選別のフェーズが発生する」と説明しています。単発タスク中心だった時期はプロンプトの書き方が最重要でしたが、複数ターン動き続けるAIエージェントが普及するにつれ、「コンテキスト状態全体」の管理が課題になった、とAnthropicは位置づけています。

なぜ今この課題が重要になっているのか

Anthropicはこの記事で、コンテキストが増えるほどモデルの性能が落ちていく現象に「コンテキスト・ロット（context rot）」という名前を付けています。

Studies on needle-in-a-haystack style benchmarking have uncovered the concept of context rot: as the number of tokens in the context window increases, the model's ability to accurately recall information from that context decreases.

（訳: 干し草の中から針を探す形式のベンチマーク研究によって、「コンテキスト・ロット」という概念が明らかになった。コンテキストウィンドウ内のトークン数が増えるほど、モデルがそのコンテキストから情報を正確に思い出す能力は低下する。）

この現象はモデルによって程度差はあるものの、すべてのモデルに共通して見られるとAnthropicは述べています。原因はLLMの土台であるTransformer（トランスフォーマー）というアーキテクチャの性質にあるとされ、Transformerはコンテキスト全体であらゆるトークンが他のあらゆるトークンを参照できる仕組みのため、n個のトークンに対してn²個のペア関係を生むと記事は説明しています。トークン数が増えるほどこの負荷は上がり、モデルが注意を向けられる範囲は薄く引き伸ばされます。

Anthropicはこの限られた処理能力を人間の「作業記憶」になぞらえ、「アテンション・バジェット（attention budget、注意の予算）」と呼んでいます。だからこそ、渡す情報は多ければ良いわけではなく、「目的達成に必要な最小限で高シグナルなトークンの集合」を見つけることこそが良いコンテキストエンジニアリングだ、というのがAnthropicの一貫した主張です。

具体的に何をするのか──手法の一覧

Anthropicの記事で紹介されている手法を、表で整理します。

手法	何をするか	向いている場面
システムプロンプトの「高度」調整	細かすぎる分岐でも曖昧すぎる指示でもない、Anthropicが「ゴルディロックス・ゾーン」と呼ぶちょうどよい抽象度で書く	すべてのエージェント設計の土台
ツール設計	ツールの入出力をトークン効率よく・誤用しにくい形にする	ツールの数が増えるほど重要
Few-shot例の厳選	エッジケースの羅列でなく、期待する挙動を体現する少数の模範例を見せる	出力の型を明確に伝えたいとき
Just-in-time（都度取得）方式	データを事前に詰め込まず、ファイルパスやクエリなど軽量な参照だけを持たせ、必要な時に読みに行かせる	データ量が多く、事前に詰め込むと古くなる場面
圧縮（compaction）	コンテキストが上限に近づいたら要約し、新しいウィンドウに引き継ぐ	長い会話・長時間タスクの継続
構造化ノート取り（agentic memory）	コンテキスト外にメモを書き出し、必要な時に読み戻す	複数ターンにまたがる進捗管理
サブエージェント構成	複数のエージェントに作業を分担させ、要約だけを親に返す	複雑な調査や並列探索が効くタスク

とくに「圧縮」「構造化ノート取り」「サブエージェント構成」の3つは、長時間タスクを続けるための手法として記事内でひとまとめに扱われています。圧縮は、Claude Codeでは決定事項や未解決のバグを保持しつつ冗長なツール出力を捨てて会話履歴を要約し、これに「直近にアクセスした5つのファイル」を加えて作業を続ける実装だと記事は説明しています。どこまで要約し何を捨てるかの線引きが、圧縮という技術そのものです。

構造化ノート取りの実例として紹介されているのが、Claudeがポケモンをプレイする際の挙動です。Claudeが残すメモの一例として、記事はこう引用しています。

for the last 1,234 steps I've been training my Pokémon in Route 1, Pikachu has gained 8 levels toward the target of 10

（訳: 直近の1,234ステップの間、ルート1でポケモンを鍛えていた。ピカチュウは目標の10レベルに対して8レベルまで成長した。）

特別な指示がなくても、探索済み地域の地図や達成目標、戦闘作戦のノートを自発的に作るようになったとされます。これを支える機能として、AnthropicはSonnet 4.5の公開に合わせ、コンテキスト外にファイル形式で情報を保存・参照できる「memoryツール」をClaude Developer Platform上でパブリックベータ公開したとしています。

サブエージェント構成は、各サブエージェントが数万トークン規模を探索しても、親エージェントには1,000〜2,000トークン程度に凝縮した要約だけを返す設計です。調査の文脈はサブエージェント側に閉じ込め、親エージェントは統合・分析に専念します。記事は別記事「How we built our multi-agent research system」を引用し、単一エージェント方式より大きな改善が見られたと述べています（この引用元は未確認・末尾参照）。

どれか一つが正解ではなく、会話中心のタスクには圧縮、区切りの明確な作業には構造化ノート取り、並列探索が効く複雑な調査にはサブエージェント構成が向く、というのがAnthropicの整理です。

個人や小規模チームでも使える考え方

ここまでは開発者向けの話に見えますが、根っこの考え方はChatGPTやClaudeを日常的に使う個人や小規模チームにも応用できます。

**会話も資料も律儀に全部持ち越さない。**圧縮や構造化ノート取りと同じ発想で、長くなった会話は要点を自分の言葉でまとめ直して新しい会話に貼り直す、決定事項や進捗はNotionやテキストファイルなど会話の外側に書き出しておき必要な時だけ貼り戻す、という運用にすると、コンテキスト・ロットの影響を受けにくくなります。

**指示文は「ちょうどよい抽象度」を狙う。**例外ケースを箇条書きで詰め込みすぎるとかえって指示が脆くなる、とAnthropicは指摘しています。かといって曖昧すぎても伝わりません。具体的な模範例を2〜3個示すほうが機能しやすい、というのがAnthropicの立場です。

**資料は全部貼らず、必要な部分だけを渡す。**長大な資料をまるごと貼るより、該当箇所の抜粋か参照先のメモだけを渡すほうが、Just-in-time方式と同じ発想でコンテキストの無駄遣いを避けられます。

正直な但し書き

この記事の手法や数字は、すべてAnthropic自身の技術ブログ1本にもとづきます。自社のClaude Codeや自社モデルを例にした説明であり、他社のAIエージェント開発で同じ用語・実装とは限りません。
「コンテキストエンジニアリング」という語自体、Anthropicの記事も「プロンプトエンジニアリングに続いて表舞台に出てきた新しい用語」と位置づけており、業界全体で定義が統一されているわけではありません。
記事中でAnthropicが引用している別記事「How we built our multi-agent research system」は、この記事では原文を直接確認していません。サブエージェント構成の効果に関する記述は、今回読んだ記事内での言及にもとづくものです。
「1,000〜2,000トークン」「直近5ファイル」といった数字は、Claude Codeにおける実装例として書かれているものです。他のツールやモデルで同じ数字が当てはまるとは限りません。
効果を保証する記述ではありません。どの手法が有効かはタスクやモデル、扱うデータ量によって変わります。