コンテキストエンジニアリングとは、推論の際に大規模言語モデルのコンテキストウィンドウを占める情報を選別し、動的に管理する実践である。このウィキの情報源のうち七つがこの用語に関わっており、いずれも自らの実践について書いている。以下で最初に扱う二つは、この用語を定義しようとしているものである。両者は問題の捉え方と、実質的な対比——静的に書かれたプロンプトと、動的に組み立てられるコンテキストとの対比——では一致しており、この用語がプロンプトエンジニアリングとどういう関係にあるか、そしてそれがどういう種類のものだと言うかについて、力点が異なる。
Anthropic は——クラウドベンダーではなくモデル提供者として書いており——これを、推論の際に利用可能なトークンの最適な集合を選別し維持するための戦略の集まりであり、任意の時点でモデルが利用できる状態の全体と、その状態がどのような振る舞いを生みうるかを考慮するものだと定義している。同社はこの実践を プロンプトエンジニアリング の自然な発展として位置づける。プロンプトエンジニアリングが効果的な指示をどう書くかを問うのに対し、コンテキストエンジニアリングは、コンテキスト全体——システム指示、ツール、外部データ、メッセージ履歴、そのほかそこに入ってくるあらゆるもの——のどのような構成が、モデルの望ましい振る舞いを最も生み出しやすいかを問う。その指導原理は、望ましい結果の可能性を最大化する、高シグナルなトークンの可能な限り小さな集合を見つけることである。
AWS は Agentic AI インフラ実践経験シリーズ（9）：コンテキストエンジニアリング において、業界が収束しつつある理解として提示する定義を紹介している。それは、モデルのコンテキストウィンドウに入る情報を動的に管理することで、モデルの推論と意思決定を最適化する技術フレームワークであり、ウィンドウを的確に満たすこととコストを削減することを掲げた目的としている。Anthropic が発展と言うところで、この説明は従来のプロンプトエンジニアリングとの根本的な違いを強調し、コンテキストエンジニアリングをその限界に対処するものとして提示する——静的な文字列では、リアルタイムデータや履歴状態、ツールインターフェースのような動的で複数ソースにわたる情報を運べないため、コンテキストは代わりに、明示的なメモリとモジュール式の構成によって管理される動的で構造化された構成要素の集まりとして扱われる。ただし、両者を無関係なものとして扱っているわけではない。同社自身のコンテキスト検索・生成コンポーネントは、その内部にある三つの技法の一つとしてプロンプトエンジニアリングを挙げている。
両者を隔てているのは、それぞれが引く対比よりも、それぞれがこの実践を何だと言っているかである。Anthropic のそれは戦略の集まりであり、AWS のそれは検索–処理–管理のライフサイクルを軸に組み立てられた技術フレームワークで、コスト削減を掲げた目的の一つに含むが、Anthropic の説明はそのような組み立て方をしていない。どちらの記事も相手の捉え方には触れていないが、AWS の記事は全体を通して Anthropic のモデルを前提に構築されている。
用法
この用語は、複数回の推論と、より長い時間軸にわたって動作するエージェントに当てはまる。Anthropic は、ループの中で動作するエージェントは次のターンに関係しうるデータをどんどん生み出していき、その情報は循環的に絞り込まれなければならないと述べ、コンテキストエンジニアリングを、絶えず変化し続けるその膨大な情報の中から、限られたコンテキストウィンドウに入れるものを選別することだと説明する。同社はこの分野を、一度きりのものではなく反復的なものだと述べ——選別のステップは、プロンプトを書くという一回限りの行為とは対照的に、何かがモデルに渡されるたびに繰り返される——その実践についての自らの説明を AI エージェントのための効果的なコンテキストエンジニアリング にまとめている。
コンテキストの構成要素全体を通じて、Anthropic の指針は、あらゆるものを有益でありながら引き締まったものに保つことである。
- システムプロンプトは、きわめて明確で、簡潔かつ直接的な言葉を使い、適切な高度でアイデアを提示するべきだとされる——振る舞いを効果的に導けるほど具体的でありながら、モデルに強力なヒューリスティクスを委ねられるほど柔軟であること。Anthropic は、プロンプトを XML タグや Markdown の見出しで区切られた別々のセクションに整理することを推奨しつつ、モデルの能力が上がるにつれて、正確な書式はおそらく重要性を失いつつあるとも述べている。
- ツールはエージェントとその情報・行動空間との間の契約を定めるものであり、そのためトークン効率のよい情報を返し、エージェントの効率的な振る舞いを促すべきだとされる。Anthropic は、よく設計されたツールを、自己完結しており、エラーに強く、意図された用途がきわめて明確で、入力パラメータが説明的かつ曖昧さのないものだと描いている。
- 例、すなわち few-shot プロンプティングは、エッジケースを網羅的に並べたものではなく、エージェントに期待される振る舞いを描き出す、多様で典型的な事例を厳選した集合であるべきだとされる。
AWS は同じ領域を、助言によってではなく構造的に分解する。同社はコンテキストを、入力（システム指示、外部知識の検索、ツール定義、グローバルな状態、ユーザー入力）、メモリ（長期と短期）、出力（ツールの実行結果と、モデルが生成した構造化コンテンツ）から成るものとして説明する。そして、反復的なループを形づくる三つの中核コンポーネント——コンテキストの検索と生成、コンテキストの処理、コンテキストの管理——を挙げ、最後のものをフロー全体にわたって情報を整理し、圧縮し、スケジュールする中枢として位置づけている。また、この作業を担う「コンテキストオプティマイザ」にも名前を与え、それは現時点では主にエンジニアリング上の実装であり、将来の発展の一つの可能性としてモデル駆動のオプティマイザがありうると述べている——現在のユーザー入力、タスクの目標、モデルの状態から、圧縮するかどうか、どの圧縮戦略を使うか、何を捨てるか、何をメモリとして保存するか、いつメモリを補填するかを判断するものである。
三つ目の説明は、同じ領域に、戦略からでもアーキテクチャからでもなく、チームが何を書き出さなければならないかという観点から迫る。エンジニア2人 × AI で回すプロダクト開発 — “開発プロセスの半分以上をAIが主導的に行う” 体制の実践 は、エージェントは書かれていることだけを信じ、それに忠実に従って行動する、という観察から出発する。そのため、チームが暗黙のうちに共有している知識——提携先のビジネスルール、既存コードに埋もれた制約、そのチームが良いコードとみなすもの——は、エージェントにとっては存在しないものとして扱われる。同記事が名指しする危険は具体的である。仕様の欠落は欠落のまま実装される。「ユーザーにポイントを付与する」と指示されたエージェントは、人間なら特定のある企業については上限が 500 だと思い出すところで、一般的なケースを書いてしまうからである。同記事は、確認のための質問を繰り返すループはせいぜい部分的な安全網にすぎないと指摘する。仕様にない情報については、質問することもできないからである。
同記事の対応は、暗黙知をコードベースの中に、エージェントが上から順にたどる五つの層として配置することである。プロダクトコンテキスト（ドメインのルールとビジネス上の制約）、コーディング規約（明示的な優先順位をもつ原則）、品質基準（ゴールデンファイル——良い出力がどのようなものかを示す実例）、リファレンス（モジュールごとに保持される実装とテストのパターン）、そしてワークフロー（それぞれがいつ適用されるかを決める Skill と SubAgent の定義）である。この配置について著者が述べる主張は、それを上から順にたどるエージェントは、新たに加わった人間のチームメンバーと同じようにその情報を取り込めるというものであり、著者が推奨するのは継続的なサイクル——日々の作業の中で AI が何かを知らないことに気づき、それを書き出すこと——であって、著者はこれをエージェントの有用性を高める最も確実な方法として挙げている。この五層の配置は一つのチーム独自の規約であり、それを測定したものは何も報告されておらず、ここで挙げた他の二つの説明が示す内容から導かれたものでもない。同記事はこれらのいずれについても「コンテキストエンジニアリング」という用語を使っていない——このページの主題との結びつけは、著者ではなくこのウィキによるものである。
四つ目の説明は、この用語をそれ自体の分野としてではなく、より大きなフレームワークの中の一層を指すものとして使う。エージェントプリミティブとコンテキストエンジニアリングで信頼性の高い AI ワークフローを構築する方法 は、コンテキストエンジニアリングを、AI エージェントが常に適切な情報に集中するようにすることと定義し、それが扱う問題を知識の観点ではなくアテンションの観点から述べている。すなわち、良いプロンプトやプリミティブであっても、無関係なコンテキストに直面したり、限られたモデルのアテンションを奪い合ったりすると失敗する、というものである。その理由として同記事は、モデルは人間と同様に有限の記憶しか持たず忘れっぽいことがあるため、何を与えるかについて戦略的であることがコンテキストウィンドウの空きを保ち、信頼性を高めるのだと述べる。上の説明群が戦略やアーキテクチャを示すのに対し、この説明はファイル規約を示す。同記事が挙げる五つの技法は、セッションの分割——計画、実装、テストのためにエージェントのセッションを分けるもので、複雑なタスクには新しいコンテキストウィンドウのほうがよいという理由による——、関連する指示だけが読み込まれるよう applyTo フロントマターのパターンでスコープを定めた .instructions.md ファイル、プロジェクトの知識と決定をセッションをまたいで引き継ぐ .memory.md ファイル、より速い検索のための .context.md ヘルパーファイル、そしてモデルのアテンションを一つのドメインにとどめ、ドメイン間の干渉を防ぐために使われる .chatmode.md ファイルである。これをここで挙げた他の説明から区別しているのは、選別の大部分が、各ターンで下される判断としてではなく、リポジトリ内のファイルとして表現されている点であり、そのため、この説明はどちらのベンダーの説明よりも、上の書き出された知識についての説明に近い——ただし、五つすべてがその種のものというわけではない。セッションの分割は実行ごとの選択であり、.memory.md は事前に確定されるのではなく作業中に蓄積されていく。同記事は評価を報告しておらず、それが依拠するファイルの種類は、同じ著者による エージェントプリミティブ の提案のものである。
五つ目の説明は、他の四つが暗黙のままにしている区別を持ち込み、それをほかのすべての前提として扱う。Jimmy Song のオンラインハンドブック『智能体构建指南』のある章は、Session（セッション）と Context（コンテキスト）を区別するところから始まる。Session はインタラクションの完全で永続化された記録であり、監査、再生、分析、メモリの抽出のために保持され、その目標は何も失わないことである。Context は各推論の前に動的に構築されるペイロード、すなわちモデルのワーキングセットであり、その目標は関連するものだけを運ぶことである。短い会話では両者は一致するが、長い会話、複数ターンのタスク、エージェントではすぐに分かれていく。
同書の主張によれば、両者を混同すると、エンジニアリング上の二つの帰結が直接生じる。性能と品質が劣化する。無関係な情報は背景ではなく、モデルの推論と選択を妨げるノイズだからである。そして、コストとスケーリングが制御できなくなる。Session は際限なく増えていく一方で、コンテキストウィンドウには厳しい上限があるため、履歴全体を投入するとシステムはスケールしなくなるからである。同書が引き出す結論は、Anthropic の説明が逆の方向からたどり着くのと同じものだが、助言としてではなくアーキテクチャ上の要件として述べられている。この実践の目的はモデルにより多くを渡すことではなく、選択し、圧縮し、並べ替え、検証する、制御可能なコンテキスト構築パイプライン（Context Construction Pipeline）を構築し、目の前のタスクに必要十分な最小限の情報の集合を生み出すことだ、というものである。この章がこの後で扱うすべてのもの——制御プレーンとしてのエージェント、クエリ拡張、検索、チャンキング、メモリの階層、Model Context Protocol を通じて到達するツール——は、別々の主題としてではなく、その一本のパイプラインの構成要素およびガバナンスの仕組みとして提示されている。
この用語がプロンプトエンジニアリングとどういう関係にあるかについての同書自身の説明は、Anthropic のものより AWS のものに近い。プロンプトエンジニアリングはモデルがどう考えるかを制御し、コンテキストエンジニアリングはモデルがどのような世界の中で考えるかを制御する。そうでなければモデルは、外部の世界について何も知らず、一時的なウィンドウにあるものしか覚えておらず、リアルタイムのデータや過去の経験にも到達できない、孤立した推論エンジンにすぎない、というのである。この章は草稿と明記されており、評価は報告していない。上の四つの説明と同様に、実践を測定しているのではなく、実践者が実践について書いているものである。
六つ目の説明は、エージェントフレームワークのベンダーによるものである。「コンテキストエンジニアリング」の台頭 において、LangChain の Harrison Chase はコンテキストエンジニアリングを「LLM がタスクをもっともらしく達成できるよう、適切な情報とツールを適切な形式で提供する動的なシステムを構築すること」と定義しており、この定義を自らの造語としてではなく、他者による最近の発言を踏まえたものとして提示している。Anthropic の説明が乏しいトークン予算を軸に組み立てられているのに対し、彼の説明は失敗の診断を軸に組み立てられている。エージェントのモデルが誤るのは、モデルが十分に優れていないか、適切なコンテキストが与えられていないかのどちらかであり、たいていの場合——とりわけモデルが改善するにつれて——それは後者、つまりコンテキストが欠けているか、書式がまずいかによるものだと彼は論じる。彼が提案するテスト、すなわち与えられたものでモデルがタスクをもっともらしく達成できたかどうかは、この二つの失敗モードを切り分けるためのものである。両者は修正の仕方が異なるからである。彼はツールを、情報と並んで提供されなければならないものの一部として扱い、書式はその両方にとって重要だとする——大きな JSON の塊よりも、短く説明的なエラーメッセージのほうがよい、というように。プロンプトエンジニアリングとの関係については、Anthropic の「発展」と AWS の「根本的な違い」に並ぶ第三の立場をとる。プロンプトエンジニアリングはコンテキストエンジニアリングの部分集合である。コンテキストをプロンプトへと組み立てることは依然として重要だが、その仕事は一つの固定された入力に対してプロンプトの言い回しを考えることではなく、動的なデータの集合を整形することだからである。彼は、この考え方自体は新しいものではない——エージェントの構築者たちは一、二年前からそれを行ってきた——こと、そして新しいのはそれを呼ぶ用語のほうだということを明言している。同記事は評価を報告しておらず、その締めくくりのセクションでは、LangChain 自社の製品がこの実践をどう支援するかが説明されている。
七つ目の説明、Cognition による マルチエージェントを構築するな は、コンテキストエンジニアリングを、長時間にわたって動作し、一貫した会話を保たなければならないエージェントにとっての信頼性の中核として扱う。同記事は「プロンプトエンジニアリング」を、LLM チャットボットにとって理想的な形式でタスクを書く取り組みとして示し、コンテキストエンジニアリングをその次の段階——それを動的なシステムの中で自動的に行うこと——として示したうえで、それを AI エージェントを構築するエンジニアにとって事実上の最重要の仕事だと呼んでいる。同記事が付け加えるのは、技法の一覧ではなく、一対の原則と、そこから導かれる設計上の結論である。すなわち、コンテキストを共有し、個々のメッセージではなくエージェントの完全なトレースを共有すること。そして、行動は暗黙の決定を伴うため、矛盾する決定は悪い結果をもたらすこと、である。同記事は、これらの原則に違反する価値がある場面はきわめてまれであるため、それを破るエージェントアーキテクチャはデフォルトで除外すべきであり、サブエージェントがタスクの一部を並行して処理するマルチエージェント設計はそれを破っていると論じる——各サブエージェントは他のエージェントからは見えない前提に基づいて行動し、組み合わされた結果は一貫性を欠く。同記事が推奨するデフォルトは、コンテキストが連続している、シングルスレッドで線形のエージェントであり、コンテキストウィンドウからあふれるほど長いタスクについては、行動と会話の履歴を重要な詳細、出来事、決定へと圧縮する別のモデルを併用する——同記事はこれを正しく行うのは難しいと述べている。他の説明と同様に評価は報告しておらず、その原則は、著者のチームが自社のエージェントを構築する中で何度も学び直しているものとして提示されている。
適用される場面
- エージェントが複数ターンにわたって動作し、プロンプト単体ではなくコンテキストの状態全体が振る舞いを決めるようになった時点で当てはまる。Anthropic は、LLM を使った開発の初期には、日常的なチャット以外のユースケースのほとんどが一回限りの分類やテキスト生成だったため、プロンプティングが作業の最大の構成要素だったと述べている。
- コンテキストを、限界収益が逓減する有限の資源とみなすことを前提とする。この実践は、特定のコンテキストウィンドウのサイズではなく、コンテキストロット と アテンション予算 という捉え方に立脚している。Anthropic は、より大きなウィンドウを待つことは代わりにならないと論じる。最高のエージェント性能が求められる場面では、あらゆるサイズのウィンドウが依然としてコンテキスト汚染と情報の関連性の問題を抱えるからである。AWS は収益の側ではなく、圧力を生む増加の側に数字を与えている。一つのエージェントタスクを十のサブタスクに分解し、それぞれが二回のツール呼び出しを要するとすると、新たに 41 件のコンテキスト記録が生じると数え、マルチエージェントシステムでは各エージェントがその負荷を負うため、合計はさらに何倍にも膨らむと指摘している。
- 誤用されるのは、エンジニアが複雑で脆いロジックをプロンプトにハードコードする場合、逆に共有されたコンテキストを誤って前提とする曖昧で高レベルな指針を与える場合、ツールセットが肥大化して、人間のエンジニアでもある状況でどのツールが当てはまるかを言えなくなる場合、あるいは典型的な例の代わりにエッジケースを洗いざらい並べたものをプロンプトに詰め込む場合である。Anthropic が述べる対処法は、利用可能な最良のモデルで最小限のプロンプトから始め、テストで見つかった失敗モードに応じて指示と例を追加していくことである。
- 七つの説明のいずれも独立した評価ではなく、それぞれが自らの実践を記述する当事者によって書かれている。Anthropic の説明は、エージェントを構築し、顧客とともに作業してきた経験から引き出されたものである。同社は、より賢いモデルほど規範的なエンジニアリングを必要としなくなると述べ、Claude 上でエージェントを構築するチームへの常なる助言として「うまくいく最も単純なことをせよ」を挙げている。AWS の説明は自社の製品スタックから引き出されたもので、その一部には実際に数字を添えている——具体的には Amazon Bedrock のプロンプトキャッシュについて、キャッシュされたトークンは標準の入力トークンより 90% 安く価格設定されていること、そして安定したエージェントワークフローではキャッシュヒット率が 90% を超えることもあり、全体の推論コストが 80% 下がることもあるという主張である。これらは一つの製品についてベンダーが報告した数字であり、達成可能なこととして述べられていて、方法論も直接比較のベースラインもなく、コンテキストエンジニアリング一般の測定ではない。三つ目の説明は、暗黙知の階層化そのものには数字を添えていない。それが挙げている数字——要件定義の作業が数時間からおよそ 10〜20 分に短縮されたこと、37 の Skill と 24 の SubAgent を構築したこと、二人のエンジニアで以前の六人チームと同等の成果を出したこと——は、そのチームのワークフロー全体について自己申告された結果であって、この実践の測定ではない。
- 書き出された知識という意味での用法は、欠落に気づいて書き出し続ける人がいることを前提とする。そのコストは一度きりではなく継続的なものである——それが描く実践は、日常の作業の中で、エージェントが何かを知らなかったことに気づくサイクルだからである。同説明が述べる失敗モードは、穴のある仕様を与えられたエージェントはその穴をそのまま実装する、というものである。つまりエージェントは一般的なケースを書き、その欠落はそのまま本番のコードにまで届いてしまう。
- ファイル規約という意味での用法は、エージェントがそもそもリポジトリから指示ファイルを読み込むこと、そしてスコープの仕組みが機能することを前提とする——その経済性全体が、指示ファイルを、それが属さないコンテキストから締め出しておく
applyToパターンに依存している。同説明が挙げる誤用は、あらゆる場面に適用される巨大な指示ファイル一つであり、同説明はそれを、モジュール化されたファイルが置き換えるために存在するものとして提示している。 - 共有コンテキストという意味での用法は、エージェントが取るあらゆる行動が、システムの他の場所で下された関連する決定を踏まえられることを前提とする。七つ目の説明は、限られたコンテキストウィンドウと実務上のトレードオフの中では、これが常に可能とは限らないことを認めており、その誤用として、互いの決定を見ることのできない並行するサブエージェントの間で作業を分割することを挙げている。