コンテキストエンジニアリングとは？プロンプトエンジニアリングとの違いをAIエージェント時代の前提から整理する

コンテキストエンジニアリングとは？プロンプトエンジニアリングとの違いをAIエージェント時代の前提から整理する

プロンプトの書き方はある程度分かってきたのに、AIエージェントに複数ステップのタスクを任せると、途中から的外れな判断をし始める——そんな経験はないでしょうか。指示文を練り直しても改善しないとき、見直すべきなのは「聞き方」ではなく、AIに渡し続けている情報そのものかもしれません。

この記事では、コンテキストエンジニアリングという考え方を一次情報から整理し、プロンプトエンジニアリングとの違い、そして「情報を増やすほど良い」とは限らない理由を扱います。

先に前提を置きます。この記事はAnthropicの公式エンジニアリングブログ「Effective context engineering for AI agents」（2025年9月29日公開、https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents）と、LangChainのブログ「Context Engineering for Agents」（2025年7月2日公開、https://www.langchain.com/blog/context-engineering-for-agents）の2つの一次情報にもとづいています。どちらも各社自身の技術ブログであり、中立的な学術文献ではなく、自社製品の設計思想を反映した文書である点は踏まえて読んでください。

なお、プロンプトエンジニアリング入門という記事が既にありますが、そちらは「1回の指示文をどう書くか」を扱っています。この記事はそれとは対象が異なり、「AIエージェントがタスクを処理する間、モデルに渡す情報環境全体をどう設計するか」を扱います。両者は矛盾する話ではなく、指示文の質と情報環境の設計は別のレイヤーの話だと考えると整理しやすくなります。

30秒で要点

• コンテキストエンジニアリングは、プロンプト（指示文）だけでなく、ツール・外部データ・会話履歴を含む「AIに渡す情報環境全体」の設計を指す
• 情報を渡すほど精度が上がるとは限らず、必要最小限の高シグナルな情報に絞ることが設計原則として挙げられている
• LangChainはコンテキスト管理の手法をWrite・Select・Compress・Isolateの4つに整理しているが、これは業界標準ではなく同社独自の分類
• 長時間動くエージェントほど、不要な情報の蓄積によってコンテキスト上限超過・コスト増加・性能劣化のリスクが高まる

プロンプトエンジニアリングとコンテキストエンジニアリングは、何が違うのか

Anthropicの整理では、プロンプトエンジニアリングは「効果的なプロンプト、特にシステムプロンプトの書き方」を指します。一方でコンテキストエンジニアリングは、システム指示・ツール・外部データ・会話履歴といった「コンテキスト状態全体の管理」を指すとされています。

この違いが実務でどう効いてくるかというと、プロンプトエンジニアリングは「1回のやり取りで、AIにどう聞くか」という質問なのに対し、コンテキストエンジニアリングは「タスクが何ステップも続く間、AIに何をどこまで見せ続けるか」という設計の問題になります。単発の質問に答えてもらう場面ではプロンプトの書き方が支配的ですが、AIエージェントが複数のツールを呼び出しながら長時間タスクを処理する場面では、渡す情報の取捨選択そのものが結果を左右します。

なぜ「情報を増やせば増やすほど良い」わけではないのか

ここで直感に反する点があります。AIエージェントの精度を上げたいとき、「関連しそうな情報をとりあえず全部渡しておく」という判断をしがちですが、Anthropicの記事はこれとは異なる原則を示しています。

Anthropicは、コンテキストを「限界収益が逓減する有限のリソースとして扱わなければならない」と述べています。原文では "Context, therefore, must be treated as a finite resource with diminishing marginal returns." と表現されており、あわせて「LLMには、大量のコンテキストを解釈する際に消費する『アテンション予算』がある」とも説明されています。アテンション予算という表現はあくまで比喩であり、厳密に計測できる単位として示されているわけではありませんが、「情報を渡せば渡すほど処理の質が上がる」という単純な関係ではないことを表す言葉として使われています。

その上でAnthropicが挙げている設計原則は、「望ましい結果が得られる可能性を最大化する、最小の高シグナルなトークン集合を見つけること」です。情報が多いほど安心できるという感覚は、実務でありがちな誤解ですが、この一次情報が示す方向性とは逆になります。

なぜこの誤解が起きやすいのか

この誤解が起きやすい背景には、人間同士のコミュニケーションの感覚をそのままAIに当てはめてしまう傾向があります。人間相手であれば、背景情報を多く共有しておくほど、相手が状況を誤解しにくくなるという経験則は一定程度成り立ちます。だからこそ、AIエージェントに対しても「念のため関連資料を全部読み込ませておこう」という判断が自然に出てきます。

しかし、LLMはコンテキストウィンドウという有限の枠の中で、渡された情報すべてに同じように注意を払っているわけではありません。むしろ情報量が増えるほど、どこに重要な手がかりがあるかを見つけ出す負荷が上がります。人間なら「大事な部分だけ拾い読みする」ことができますが、AIエージェントの設計でそれを期待するなら、情報を絞り込む作業そのものを設計側が担う必要がある、というのがこの一次情報の示す論点です。

長時間動くエージェントほど、情報の蓄積がリスクになる

LangChainのブログは、この論点を別の角度から補強しています。長時間タスクにわたって動作するエージェントは、ツール呼び出しの結果というフィードバックを次々に蓄積していきます。LangChainは、この蓄積が進むと、コンテキスト上限を超えてしまう、コストとレイテンシが増える、そして性能そのものが劣化する、という3つのリスクにつながり得ると説明しています。ただし、これらのリスクがどの程度の割合で・どれだけ発生するかという定量的な数値は、参照した記事の範囲では示されていません。

この観点から、LangChainはコンテキスト管理の手法を4つに整理しています。Write（スクラッチパッドやメモリとして、コンテキストウィンドウの外に情報を書き出しておく）、Select（次のステップに必要な情報だけを取り込む）、Compress（要約やトリミングで、必要なトークンだけを残す）、Isolate（複数のエージェントや環境、状態に情報を分割する）の4つです。

ここで注意したいのは、この4分類はLangChainが自社のブログで示している整理であり、業界全体で確立された標準の分類ではないという点です。Anthropicの記事は「最小の高シグナルな情報を見つける」という原則を語っていますが、Write・Select・Compress・Isolateという枠組みそのものには言及していません。同じ「コンテキストエンジニアリング」という言葉を使っていても、Anthropicは「情報を選び、維持し続けるための戦略」という定義を、LangChainは「コンテキストウィンドウを必要な情報だけで満たす技芸と科学」という定義を、それぞれ独自の言い回しで示しています。

確かなことと、まだ確かではないこと

確かなこと：Anthropic・LangChainの両社が、AIエージェントの設計において「渡す情報の取捨選択」を独立した課題として扱っていること。情報を無制限に増やすことが精度向上に直結するとは、両社とも述べていないこと。

まだ確かではないこと：「コンテキストエンジニアリング」という呼び方や定義が、今後業界で統一されていくのか。LangChainのWrite・Select・Compress・Isolateという4分類が、他の企業・研究者の整理とどこまで一致するのか。これらは、参照した2つの一次情報の範囲では確認できていません。比較的新しい用語であり、各社の整理が併存している発展途上の段階だと捉えておくのが実務的です。

判断軸の提示

ここまでの整理から、AIエージェントを導入・運用する際の判断軸を1つ提案します。

AIエージェントの出力が的外れになったとき、「指示文が悪いのか」「渡している情報が多すぎる、または足りないのか」を切り分けて考えること。

指示文を練り直しても改善しない場合、それはプロンプトエンジニアリングの範囲を超えた問題である可能性があります。エージェントが参照しているツールの出力・過去の会話履歴・外部データのうち、そのタスクに本当に必要な情報はどれか、逆に不要なまま渡し続けている情報はないかを一度棚卸ししてみることが、コンテキストエンジニアリングという視点を実務に落とし込む第一歩になります。

自分でも試せる、最小の検証

自社で使っているAIエージェント、あるいは複数ターンにわたるチャットのやり取りを1つ選び、そのタスクの後半でエージェントが参照している情報を確認してみてください。タスクの序盤で得た情報のうち、既に不要になった、あるいは古くなったものを、エージェントがそのまま参照し続けていないかを見ます。

もし、タスクの前提が変わったにもかかわらず古い情報を引きずったまま判断している箇所が見つかれば、それは指示文の問題ではなく、コンテキストの管理——LangChainの言葉で言えば「不要になった情報をCompressまたはIsolateできていない」状態です。この切り分けができるようになるだけで、AIエージェントの改善対象を、指示文の書き直しから情報設計の見直しへと移せます。

この記事で扱ったような、AIエージェント導入時の情報設計を自社の状況に照らして整理したい場合は、無料診断ツールで状況を言語化するところから始めることができます。