Context Engineering 2026年4月12日

コンテキストエンジニアリング完全ガイド

LLMに渡すコンテキスト全体を設計・最適化する技術「コンテキストエンジニアリング」を体系的に解説。4つの基本戦略、Context Rot問題、エージェント時代の実践テクニックを網羅します。

#context-engineering #llm #rag #agent #context-rot #langchain

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

コンテキストエンジニアリングとは、LLMのコンテキストウィンドウに「次のステップに必要な適切な情報」を満たす技術です。Andrej Karpathy（元Tesla AI責任者）は2025年にこう定義しました。

“Context engineering is the delicate art and science of filling the context window with just the right information for the next step.”

LLMをオペレーティングシステムに例えると、コンテキストウィンドウはRAM（作業メモリ）に相当します。少なすぎればタスクを遂行できず、多すぎれば性能が低下する。その最適なバランスを設計するのがコンテキストエンジニアリングです。

プロンプトエンジニアリングとの違い

観点プロンプトエンジニアリングコンテキストエンジニアリング
スコープ1回のプロンプトの書き方コンテキストウィンドウ全体の設計
対象ユーザーの入力テキストシステムプロンプト + RAG + メモリ + ツール + 履歴
時間軸単発のやり取り複数ターン・複数セッションにまたがる
主な関心「何を聞くか」「何を渡し、何を渡さないか」

Karpathyが「prompt engineering」より「context engineering」を推奨する理由は、産業レベルのLLMアプリケーションでは「短いプロンプトをどう書くか」よりも「コンテキスト全体をどう構成するか」が圧倒的に重要だからです。

なぜ2025年に重要になったのか

AIエージェントの普及が最大の要因です。エージェントは長時間にわたって自律的にタスクを実行し、ツールを呼び出し、コンテキストを蓄積し続けます。その過程で「コンテキストが劣化する」問題が顕在化しました。Cognition社は「コンテキストエンジニアリングはAIエージェント構築エンジニアの最重要業務」と断言しています。

背景と登場経緯

Andrej Karpathyの提唱

2025年6月、KarpathyはX（旧Twitter）で「prompt engineering」よりも「context engineering」という用語を支持する投稿を行い、業界に大きな影響を与えました。彼の定義では、コンテキストエンジニアリングが扱う要素は以下の通りです。

  • タスクの説明と解説
  • Few-shot例
  • RAG（検索拡張生成）による関連データ
  • マルチモーダルデータ
  • ツール定義
  • 状態と履歴
  • コンパクション（圧縮）

Cognition AIの見解

Devin（AIソフトウェアエンジニア）を開発するCognition社は、実運用を通じて「エージェントが長時間動作すると、コンテキストの質がタスク成功率を決定する」ことを実感し、コンテキストエンジニアリングをエージェント構築の核心スキルと位置づけています。

プロンプトエンジニアリングからの進化

プロンプトエンジニアリングが「1回の質問をどう聞くか」を最適化する技術だったのに対し、コンテキストエンジニアリングは「LLMアプリケーション全体の情報フロー」を設計する工学分野へと進化しました。

コンテキストウィンドウの構成要素

LLMに渡されるコンテキストは、以下の5つの要素で構成されます。

システムプロンプト

LLMの振る舞いを規定する基盤指示です。ロール、制約、ガードレール、期待する出力形式をここで定義します。全てのやり取りに影響するため、最も慎重に設計すべき要素です。

ユーザープロンプト

ユーザーが入力する具体的な指示やクエリです。プロンプトエンジニアリングが主に扱う領域。

RAG（検索拡張生成）

外部の知識ベースから関連情報を検索し、コンテキストに注入するアーキテクチャパターンです。ベクトル検索とBM25のハイブリッド検索が主流で、LLMの学習データにない最新情報やドメイン固有知識を補完します。

メモリ

  • 短期メモリ: 現在の会話履歴。ターンが増えるほど蓄積される
  • 長期メモリ: 過去のセッション情報。ユーザーの好みや過去のやり取りを保持

ChatGPT、Cursor、Claude Codeなど主要ツールが自動メモリ機能を実装しています。

ツール定義

LLMが呼び出せる外部関数の説明です。ツール名、パラメータ、戻り値の型を定義することで、LLMがいつ・どのツールを使うかを判断します。RAGを用いたツール選択で精度が3倍向上するという研究結果もあります。

Context Rot（コンテキスト劣化）問題

研究の概要

2025年、Chroma社が18の主要LLM（GPT-4.1、Claude、Gemini等）を対象に行った研究で、全てのモデルが入力長の増加に伴い性能低下することが実証されました。これが「Context Rot」です。

コンテキストオーバーフローとの違い

Context Rotはコンテキストウィンドウの上限を超える「オーバーフロー」とは異なります。200Kトークンのウィンドウを持つモデルでも、50Kトークン程度で顕著な性能劣化が始まります。実効的なキャパシティは公称値の60〜70%程度です。

主要な知見

  • 不均一な低下: 性能は線形ではなく、モデルごとに「崖」のような急激な低下ポイントがある
  • セマンティック複雑性の影響: 完全一致タスクより意味的類似性タスクで低下が顕著
  • 位置バイアス: コンテキストの先頭と末尾が過度に注目され、中間部分が無視されがち
  • モデル固有のパターン: GPT-4.1はハルシネーション増加、Gemini 2.5は無関係な断片を追加する傾向
  • 構造のパラドックス: 論理的に構造化されたドキュメントは、ランダムに配置されたものより検索精度が低い（類似用語がdistractorになるため）

実務への影響

300トークンの焦点化されたコンテキストは、113,000トークンの散漫なコンテキストより優れます。 量より質が絶対原則です。

4つの基本戦略

LangChainの整理に基づく、コンテキストエンジニアリングの4つの基本戦略です。

Write（書き込み）

コンテキストウィンドウの外部に情報を保存し、必要時に参照できるようにする戦略です。

スクラッチパッド: エージェントが思考過程やタスク計画を外部メモリに記録します。Anthropicのマルチエージェントシステムでは、リードエージェントが計画を外部メモリに書き出します。200,000トークンを超えるとコンテキストが切り詰められ、計画が消失するためです。

長期メモリ: セッションをまたいで情報を保持する仕組みです。Claude Codeのmemory機能、ChatGPTのMemory機能がこれに該当します。

Select（選択）

必要な情報だけをコンテキストウィンドウに取り込む戦略です。

メモリ検索: 3種類のメモリから適切なものを選択します。

  • エピソード記憶: 過去の具体例（Few-shot用）
  • 手続き記憶: 規則・指示（System Prompt補完）
  • セマンティック記憶: 事実・知識（RAG）

ツール選択: ツールが多すぎるとコンテキストを圧迫します。RAGでツール説明を検索し、関連ツールのみを提供する「動的ツール選択」が効果的です。

コード検索: 正規表現検索、AST（抽象構文木）解析、セマンティック検索、知識グラフの組み合わせが最良の結果を生みます。

Compress（圧縮）

タスク実行に必要なトークンのみを保持する戦略です。

自動サマリー: Claude Codeの「auto-compact」機能は、コンテキスト使用量が95%を超えると自動的に要約を実行します。手法には再帰的サマリー、階層的サマリー、ターゲットサマリーがあります。

トリミング: 古いメッセージの削除、重要度の低いツール呼び出し結果の枝刈りなど、ヒューリスティクスに基づく削減です。

Key-Value蒸留: 長文を「事実」単位に分解し、QAペアとして保持する圧縮手法です。

Isolate（分離）

コンテキストを複数のエージェントやプロセスに分割する戦略です。

マルチエージェント: 各エージェントが独立したコンテキストで専門的なサブタスクを実行します。Anthropicの研究では「並列処理で異なる側面を同時探索」が有効と報告されています。

サンドボックス: コード実行結果を隔離された環境に保持し、LLMには結果のサマリーのみを返します。HuggingFaceのDeep Researcherがこの手法を採用しています。

状態スキーマ: LangGraphの状態オブジェクトのように、特定のフィールドのみをLLMに公開し、内部状態を選別的に隔離する設計です。

実践テクニック集

初級（1〜2時間で習得可能）

  1. システムプロンプトの構造化: XMLタグやMarkdown見出しで情報をセクション分けする
  2. コンテキスト予算の意識: 「このタスクに何トークン必要か」を事前に見積もる
  3. 不要情報の除外: 関係のない会話履歴やツール出力を手動で整理する
  4. プロンプトテンプレートの活用: 変数埋め込み型のテンプレートで一貫性を確保する

中級（実装経験必要）

  1. RAGパイプラインの構築: ベクトルDB + BM25ハイブリッド検索の実装
  2. メモリシステムの設計: 短期・長期メモリの分離と検索戦略
  3. 動的ツール選択: タスクに応じて提供するツールを動的に切り替え
  4. コンテキスト圧縮の自動化: サマリー生成と古い情報のトリミング

上級（エージェント設計レベル）

  1. マルチエージェントのコンテキスト分離設計: 各エージェントの責務とコンテキスト境界の定義
  2. Context Rot対策: トークン予算管理、位置バイアスの緩和、品質モニタリング
  3. メタラーニング: エージェントが自身のコンテキスト管理戦略を学習・改善する仕組み
  4. 評価パイプライン: LangSmith等でトークン使用量・精度・コストを継続的に計測

ツールとフレームワーク

ツール役割対応する戦略
LangGraphエージェントオーケストレーションWrite / Select / Isolate
LangSmithトレーシング・評価全戦略の計測
Elasticsearchハイブリッド検索（RAG）Select
Chroma / WeaviateベクトルDBSelect / Write
Redis高速メモリストアWrite / Compress
Claude Codeコーディングエージェント全戦略を内蔵（auto-compact, memory等）

参考リンク集