はじめに

2022年ごろから、LLMの「内部知識」の限界を補うために外部データベースから情報を注入するRAG（検索拡張生成）や¹、推論と行動を反復させるAIエージェントの仕組みが広く実用化されてきた²。しかし、より複雑なビジネス実務への適用が進むにつれ、これら既存アプローチの構造的な限界が浮き彫りになりはじめた。

情報を細切れ（チャンク）にして部分的に検索・注入するRAGでは、ドキュメント全体にまたがる俯瞰的なトレンドの把握や、ストーリー・数式の前後関係（コヒーレンス）を維持した高度な推論が極めて難しい。また、自律的にタスクを繰り返すエージェントにおいても、思考ステップが長くなるにつれて過去の記憶や軌道修正の指示（コンテキスト）が破綻し、タスクの迷走やコストの無限増殖を招くという致命的な課題を抱えていた。

こうした既存アプローチの「コンテキストの分断・忘却」を解決すべく、2023年から2026年にかけて、LLMが一度に扱えるコンテキストウィンドウを数十万から数百万トークンへと劇的に大容量化する技術革新が起きた³。これにより、書籍一冊や大規模なソースコード、数時間の動画データを生のままモデルに丸ごと投入するアプローチが可能となった。

³

しかし、入力容量の拡大（ロングコンテキスト化）が生のデータをただ詰め込めばいいわけではないことが示される⁴などの新たな課題が認識された。そこでモデルが最も効率的かつ正確にコンテキスト（文脈）を理解・保持・処理できるように、入力空間そのものを動的に最適化・制御すべきだ」という思想に基づく「コンテキストエンジニアリング（Context Engineering）」というアプローチが注目されることとなる。
本記事では、コンテキストエンジニアリングに関する技術をまとめた。

コンテキストエンジニアリングの起源

LLMLingua

プロンプトや会話履歴、RAGのテキストには膨大な「冗長性（無駄）」があることに着目し、小さな別の言語モデル（GPT-2やLLaMAなど）のパープレキシティ（Perplexity）を利用して、ターゲットLLMの推論に影響を与えない不要なトークンを検知・削除し、最大20倍にプロンプトを「圧縮」する技術。APIコール直前に、システム側で不要なトークン（自然言語の無駄な修飾語など）をフックして物理的に削って引き算する手法に関する研究⁵。

システムの流れは下記の通り。

Distribution Alignment（分布アライメント / 事前準備）
- 小さなモデルとターゲットLLMの言語分布の乖離を埋めるための事前チューニング。
Budget Controller（予算コントローラー）
- プロンプトの各要素へ動的に圧縮率を割り当てる。
Iterative Token-level Prompt Compression（反復的トークンレベル圧縮）
- トークン単位で条件付き確率を計算し、不要なトークンを削る。
Compressed Prompt Execution（圧縮プロンプトの実行）
- 実際に圧縮されたプロンプトをターゲットLLMに投入して推論を行う。

⁵

MemGPT（MemoryGPT）

オペレーティングシステム（OS）の「仮想メモリ（Paging）」の概念をLLMに持ち込み、LLMのコンテキストウィンドウを「主記憶（物理メモリ）」、外部のベクトルDBやローカルログなどを「ディスク（外部ストレージ）」と見立てたアーキテクチャに関する研究⁶。
LLM自身に関数（ツール）を実行させて、今必要のない記憶をコンテキストから追い出し（Evict）、必要な時にだけストレージからロードする仕組みを構築し、コンテキストをただの「垂れ流しの履歴ログ」にするのではなく、システム側で綺麗に構造化して切り分け、動的に出し入れする。

主要な4つの制御コンポーネント（メカニズム）は下記の通り。

Queue Manager
- LLMへの入力（ユーザー発言やシステム通知）を「イベント」としてキュー（行列）で管理し、LLMのコンテキストウィンドウへ順番に供給する制御機構。
- メッセージが溢れそうになると、古い対話イベントを自動的にコンテキストから押し出し（Evict）、後述のRecall Storageへ安全に退避させる。これにより、コンテキストの破綻を防ぎながら、常に最新のやり取りをLLMの「主記憶」に維持する。
Function Executor（関数エグゼキューター / 実行器）
- LLM自身が「今、記憶の出し入れや操作が必要だ」と判断した際に発行するコマンド（ツールコール）を検知し、実際にシステム側で処理を実行する。
- OSの「システムコール」に相当する。LLMは単に回答を生成するだけでなく、「edit_core_memory（記憶の上書き）」や「archival_memory_search（検索）」といった関数を自律的に呼び出す。Function Executorがこれを仲介・実行し、その結果を再びLLMのコンテキストにフィードバックする。
Archival Storage（アーカイブストレージ）
- 大規模なドキュメントや外部の知識ベースなど、読み込み専用（Read-only）の膨大なテキストデータを永続化して格納しておく外部ディスク。
- LLMがFunction Executorを介して「ベクトル検索」などのクエリを投げる対象となる領域。数万行に及ぶ取扱説明書や長大な論文などはここに配置され、LLMの要求に応じて必要な部分だけがピンポイントでコンテキストへロードされる。
Recall Storage（リコールストレージ）
- 過去にQueue Managerを通過したすべての会話履歴やイベントログを、時系列で一元管理・保存しておく外部ディスク。
- LLMが「さっき言っていたあの件だけど…」と過去の文脈を必要とした際に、Function Executorを介してキーワードや時間指定で検索をかける対象となる。コンテキスト（主記憶）から追い出された過去の記憶をいつでも呼び戻せるようにする、OSの「スワップ空間」としての役割を持つ。

⁶

Context Caching / Prompt Caching

LMのコンテキストウィンドウが数十万から200万トークンへと劇的に巨大化したことで、開発者はRAGで検索した大量のドキュメントや、長大な会話履歴、コードベース全体をそのままプロンプトに「含めすぎる」ことができるようになったが、
これにより「入力コストの爆発」と、巨大なプロンプトを毎回1から再計算することによる「レイテンシ（TTFT）の悪化」という新たなボトルネックが発生した。
この「長大コンテキストの利便性」と「コスト・速度」のトレードオフを解消し、巨大なコンテキスト窓のポテンシャルを活かすために、Google、OpenAI、Anthropicをはじめとし導入されたのがプロンプトキャッシングである。

各プロバイダは、長大コンテキストの処理という共通の課題に対し、開発者の実装スタイルやユースケースに応じた異なるアプローチを提示している⁷⁸⁹。

Google Gemini API (Context Caching)

200万トークンという業界最大級の context window を想定した設計
大量の動画・音声・PDF、あるいは大規模なコードベースをAPI経由で事前に明示的（Explicit）にキャッシュオブジェクト化し、それらを複数のリクエスト間で強固に固定・再利用することで入力コストを削減する仕組みを提供

OpenAI API (Prompt Caching)

コードの変更を一切必要としない「完全自動判定（インメモリ型）」を採用
1,024トークン以上のプロンプトに対し、先頭から最も長く一致するプレフィックスを128トークン刻みで自動検知し、インフラ側で透過的にキャッシュをヒットさせて自動的に50%のコスト割引を適用

Anthropic Claude API (Prompt Caching)

開発者が明示的にブレークポイントを指定、あるいは会話の進展にあわせて自動で追従させるハイブリッドな制御モデルを提供
RAGの文脈脱落を防ぐ「Contextual Retrieval」のように、各チャンクへの説明的文脈の付与前処理において、ベースとなる数万〜数十万トークンの親ドキュメントをキャッシュに固定して計算を効率化するアプローチを提唱しており、コストを最大90%、レイテンシを2倍以上改善

コンテキストエンジニアリング体系化

コンセプト

LLMの処理能力が拡大し、マルチターン対話や知識集約型の複雑なタスクへの要求が高まる中、最適化されていない長文コンテキストでは、情報が中間に埋もれた際にモデルの精度が最大20%低下する問題が実証され、単なる入力文の工夫だけでは長大な会話履歴や外部データの統合に対応できず、システムの運用コストの爆発やレイテンシの悪化、事実誤認（ハルシネーション）を防げないというインフラ・実務上の限界を迎えたとし、コンテキストエンジニアリングが下記のように提案された¹⁰。

定義
- プロンプトエンジニアリングのような場当たり的な入力調整を超え、LLMがアクセスする情報環境の全体を包括的かつプロアクティブに管理・最適化するシステム設計フレームワーク
Key components
1. 入力の起点となるPrompts
2. 一貫性を維持するためのConversational History
3. External Resources（ドキュメントやDB起因のデータ。RAGを介する場合がある）
4. APIや計算機などのTool Integration
5. モデルのトークン制限に応じたContext Windows Optimization
プロンプトエンジニアリングとの違い
- プロンプトエンジニアリングが特定の応答を引き出すために「直近の入力文を試行錯誤（ハック）的にデザインする」限定的なアプローチであるのに対し、コンテキストエンジニアリングは外部データやツール、メモリ上限までを含めた「システム全体を構造的に設計する」アプローチ
- 規模の柔軟性と実務における再現性（スケーラビリティと適応性）において決定的な差

Anthropicブログ: Effective context engineering for AI agents

Claudeの開発元であるAnthropicが公開した技術ブログEffective context engineering for AI agentsは、プロンプトエンジニアリングの時代から「コンテキストエンジニアリング」への移行を示唆した。

In contrast to the discrete task of writing a prompt, context engineering is iterative and the curation phase happens each time we decide what to pass to the model.¹¹

自律型AIエージェントをループ処理で動作させる際、最大の問題となるのが「コンテキストの肥大化」とそれに伴うモデルの迷走現象である。Anthropicはこの現象を「Context Rot（文脈の腐敗）」と命名した。どれほどコンテキストウィンドウが拡大しようとも、トークン量が増えるほどモデルの注意力が分散し、情報の正確な想起や長距離推論の精度が低下する（いわゆるNeedle-in-a-haystack現象の悪化）。

この「有限な注意力予算（attention budget）」の制約下で、エージェントを24時間、あるいは数時間に及ぶ長期タスク（Long-horizon tasks）で安定稼働させるため、システム側が裏方として徹底すべき具体的なコンテキスト管理手法が明文化されている。

Compaction（文脈の圧縮）
- メカニズム: メッセージ履歴がコンテキストウィンドウの限界に近づいた際、その全履歴を一度LLM自身に投入し、重要な意思決定や未解決のバグ、実装の詳細といった「高シグナルな情報」だけを高密度に要約・抽出させる。
- 制御手法: 抽出が完了した時点で、冗長なツールの生出力や過去のやり取り（生ログ）をコンテキストから完全に破棄し、生成された要約と直近の数メッセージだけで新しいコンテキストウィンドウをクリーンに再構成（リセッション）する。
Tool-result clearing（ツール結果の消去）
- メカニズム: エージェントが実行したツール（コード実行、データベースクエリなど）が返した、数万トークンに及ぶような「巨大な生のレスポンス」を処理するための最も軽量で安全なコンパクション手法である。
- 制御手法: ツール実行直後のターンでLLMが生の出力を読み、必要な分析を終えた段階で、システム側がメッセージ履歴をスキャンしてその巨大な未加工データをコンテキストから抹消する。「なぜエージェントが過去の生出力を何度も見直す必要があるのか？」という思想に基づき、生ログを数文字のプレースホルダー（「ツール実行成功」等の最小限の識別子）に置き換えることで、コンテキストの汚染を未然に防ぐ。
Structured note-taking（構造化ノートテイク / エージェントメモリ）
- メカニズム: コンテキストウィンドウの外側に独立した「外部メモリファイル（NOTES.mdやタスクリストなど）」をシステム側で永続化させておく手法。
- 制御手法: エージェントはタスクの進行状況や現在位置、獲得した変数の状態などをこの外部ファイルに定期的に書き出す。コンテキストの強制リセットやコンパクションが実行された後でも、エージェントはこの自己が残したノートのみを読み直すことで、数千ステップに及ぶ長期のタスクを迷走することなくシームレスに継続できる。
Sub-agent architectures（サブエージェント構造によるコンテキスト隔離）
- メカニズム: 1つのメインエージェントがすべての探索ログを抱え込むのではなく、特定の狭いタスクに特化した個別のサブエージェントを並列で走らせるアーキテクチャ。
- 制御手法: サブエージェント側が数万〜数十万トークンを消費して泥臭いデータ探索や技術的検証を行い、メインエージェントにはその結果を1,000〜2,000トークン程度に「蒸留・濃縮したサマリー」だけを返却する。これにより、詳細な探索プロセスに伴う膨大なゴミトークン（コンテキストの汚染）をサブエージェント側に完全に隔離し、統括側のクリーンな文脈環境を維持する。

コンテキスト自動化・最適化

コンテキストエンジニアリングの動きは加速し、「手動の工夫」から「システムによる自動制御・強化学習（RL）による最適化」へと劇的な進化している。

「エージェントを実行する巨大なLLM」とは別に、「文脈を掃除・管理するためだけの専用システムや別モデルを置く」という分離・共生型のアプローチが主流に

AIコンテキストファイル

プロンプトエンジニアリングは「タスクをモデルにどう説明するか（指示や出力形式など）」に焦点を当てていましたが、これは多くの場合、使い捨てのインシデント（一時的な成果物）として処理され、リポジトリに残らないという課題がある¹²。
これに対し、コンテキストエンジニアリングは「モデルにタスク関連情報をどう構造化して提供するか（規約、構成、コード断片など）」に焦点が当たっている。AIエージェントの自律性が高まる中、開発現場ではコンテキストを「コードと同様にバージョン管理・構造化して永続化する」という実務実装へと移行。このアプローチにより、開発チーム全体で一貫したAIの振る舞いを保証することが可能となる。

上記の流れに沿い、下記のようなAIエージェントにプロジェクトの文脈やルールを自律的に読ませるための専用マシンリーダブルなファイルが配置され始めた。

CLAUDE.md: Anthropic（Claude Codeのデフォルト探索ファイル）
copilot-instructions.md: GitHub Copilot
AGENTS.md: ツールに依存しないオープンな標準規約（Agentic AI Foundationプロジェクト）

¹²の調査で、特にオープンな共通規格である AGENTS.md のセクション構造を分析した結果、実務者がAIに読み込ませている記述カテゴリーの優先度は下記の通りだった。

CONVENTIONS（コーディング規約・ベストプラクティス）: AIが最も遵守すべき、コードの一貫性を保つためのルール。
CONTRIBUTION GUIDELINES（貢献のルール）: ブランチ戦略やCI（継続的インテグレーション）の要求事項、プルリクエスト作成手順。
ARCHITECTURE / STRUCTURE（アーキテクチャ・プロジェクト構造）: ディレクトリ構成、モジュール間の関係性の説明。
BUILD COMMANDS & TEST EXECUTION（ビルド・テスト実行コマンド）: ローカル環境やCI環境でプロジェクトを動かすための具体的なコマンドリスト。

現代のソフトウェア開発者は「人間のためのドキュメント（READMEなど）」だけでなく、「マシンのためのドキュメント」をも設計・維持する時代に突入していると言える。

ACE (Agentic Context Engineering)

従来のプロンプト最適化手法が抱えていた、指示が汎用的かつ短くなりすぎる「簡潔さへのバイアス（Brevity Bias）」や、反復的な書き換えによって詳細な知識が失われる「コンテキスト崩壊（Context Collapse）」という2つの限界を解消するため、
コンテキスト（システムプロンプトやメモリなど）を自己進化させるための新しいコンテキスト最適化フレームワークであるACE (Agentic Context Engineering)が提案された¹³。

主な構成要素は3つの専門エージェントである。

Generator
- 与えられたコンテキスト（プレイブック）を参照しながら、タスクを実行するための推論ステップやコード（実行軌跡）を生成
Reflector
- Generatorの実行軌跡（成否、API利用ログ、エラーフィードバックなど）を精査・批判し、成功要因や具体的な失敗原因から「具体的な教訓やドメイン知識（洞察）」を抽出
Curator
- Reflectorが抽出した教訓を、構造化されたコンパクトな「デルタ（差分）コンテキスト項目」へと合成

¹³

ARC（Active and Reflection-driven Context）

履歴をそのまま蓄積する手法は、履歴の増大に伴いコンテキストが急膨張し、注意の希釈（Attention Dilution）や推論の劣化を引き起こす。
そして受動的な圧縮・要約を行う手法は、コンテキスト長を抑えるのには有効だが、静的な成果物として処理されるため、初期の誤りや古い仮定、不適切な強調が要約に残り続け、後から修正することが困難になる。
これらによるContext Rotを防ぐため、長期間の探索や深い調査（Deep Search）を行うLLMエージェント向けの能動的・リフレクション駆動型のコンテキスト管理フレームワークとしてARC（Active and Reflection-driven Context）が提案された¹⁴。

ARCは、下記の二部構成のエージェントアーキテクチャを採用している。

Actor
Context Manager

¹⁴

コンテキストエンジニアリングの限界

現状でも、すでに見えてきているコンテキストエンジニアリングがいくつか存在する。

コンテキスト崩壊・再帰的情報減衰

LLMにコンテキストの「維持・削除・要約」の判断を任せると、タスクのステップが進むごとに、本来ドメイン固有で保持すべき微細な制約や前提条件（ユーザーの細かなニュアンスやコーディング規約など）が「不要なノイズ」と誤判定され、抽象化の波に飲まれて削ぎ落とされてしまう。
最適化（動的圧縮）を回した結果、1万トークン以上のコンテキストがわずか100トークン強にまで過剰圧縮され、タスクの正解率がベースライン以下に急落する現象が確認されている¹³。
また、LLMが元の生データの直接的な解析よりも、CEによって生成された「親切にまとめられた要約層」に過剰に引っ張られて（over index）しまい、モデルは深い推論を放棄し、要約層のニュアンスに引きずられた浅い誤認を起こすといった現象も問題視されている¹⁵。

「1次元の限界」を1次元のCEでは突破できないというトポロジー的限界

汎用LLMは主に1次元のテキストストリーム（one-dimensional text streams）上で動作するという性質そのものが、多次元的な構造メタデータとコンフリクトを起こすという問題も指摘されている¹⁶。
システムアーキテクチャ、複雑なソースコードの依存グラフ、あるいは2次元のスプレッドシートやドキュメントのレイアウトなどは、本質的に「多次元のネットワーク/グラフ構造」を持っている。CE側でどれだけ「プロンプトの順序を入れ替える」「セクション区切りを明示する」「XML風のメタタグで囲む」といった線形的な整理・エンジニアリングを行っても、LLMの入力に変換する段階で「1次元の文字列」にフラット化（シリアライズ）せざるを得ない。このシリアライズの過程で、グラフのトポロジー（空間的配置や多方向の接続関係）が必ず破壊、あるいは著しく希釈されるため、モデルは複雑な構造トポロジーを正確に復元・推論できなくなる。

関連記事