TL;DR
- Context Engineering とは、単なる指示(プロンプト)ではなく、LLM が参照する情報環境全体を設計・最適化する技術体系です。
- モデルの長文脈化(Long Context)が進む現代において、情報の「詰め込みすぎ」を防ぎ、必要な情報を・適切な形式で・適切なタイミングで渡す設計が精度向上の鍵です。
- XML タグによる構造化、情報の圧縮(Compaction)、動的取得(RAG)などのシステム設計視点が求められます。
Introduction
「プロンプトをどれだけ工夫しても、回答の精度が頭打ちになる」「コンテキストウィンドウが広いからといって大量のドキュメントを放り込んだら、逆に重要な指示を無視された」
もしあなたがこのような壁に直面しているなら、必要なのは「プロンプトエンジニアリング(Prompt Engineering)」の改善ではなく、「コンテキストエンジニアリング(Context Engineering)」 への視座の転換かもしれません。
2024年から2025年にかけて、Anthropic などの主要な AI ベンダーは、LLM 活用におけるこの新しいパラダイムを提唱し始めました。本記事では、単発の「命令」からシステム全体の「環境設計」へと進化する、Context Engineering の概念と具体的な実践手法を解説します。
Prerequisites
- LLM(Large Language Models)の基本的な仕組み(トークン、コンテキストウィンドウ)の理解
- プロンプトエンジニアリングの基礎知識(Few-shot, System Prompt 等)
- RAG(Retrieval-Augmented Generation)の概要理解
Context Engineering とは何か
プロンプトエンジニアリングとの決定的な違い
従来の Prompt Engineering が「LLM に何をさせるか(What)」という指示(Instruction) の最適化に焦点を当てていたのに対し、Context Engineering は「LLM が何を知っている状態でタスクを行うか(Where & How)」という文脈(Context) の設計に焦点を当てます。
| 項目 | Prompt Engineering | Context Engineering |
|---|---|---|
| 焦点 | 指示文の表現、命令の明確化 | 情報の構造、順序、選別、形式 |
| 対象 | 単一の入力(Prompt) | コンテキストウィンドウ全体(System) |
| 比喩 | 俳優への演技指導 | 舞台セット、脚本、小道具の全体設計 |
| 主な課題 | 表現の揺らぎ、ハルシネーション | 情報過多(Context Overload)、迷子(Lost in the Middle) |
Anthropic のエンジニアリングチームは、これを「コンテキストウィンドウを、次のステップのために最適な情報で埋める繊細なアートでありサイエンスである」と表現しています。
なぜ今、Context Engineering なのか?
Gemini 1.5 Pro の 200万トークン対応など、Long Context Window が当たり前になりました。しかし、"Needle in a Haystack"(干し草の中の針)問題が示すように、コンテキストが長くなるほど、モデルが重要な情報の断片を見落とすリスクは残ります。
「全部入れればいい」は間違いです。「ノイズを減らし、シグナルを最大化する」 設計こそが、エンジニアに求められる新たなスキルセットなのです。
実践テクニック 1:情報の構造化(Information Architecture)
LLM にとって読みやすいコンテキストとは、人間にとって読みやすいドキュメントと似ています。まずは情報の境界を明確にすることから始めます。
XML タグによるセクション分割
特に Claude シリーズなどで推奨されるのが、XML タグを用いた情報の構造化です。自然言語の見出しよりも、情報の境界をモデルが認識しやすくなります。
以下は参考資料です。
...(長いテキスト)...
ここからが指示です。
この資料に基づいて要約してください。
<documents>
<document index="1">
<title>2024年度事業報告書</title>
<content>...(テキスト)...</content>
</document>
<document index="2">
<title>2025年度計画案</title>
<content>...(テキスト)...</content>
</document>
</documents>
<instructions>
上記の <documents> 内の情報を元に、2025年度の注力領域を3点抽出してください。
</instructions>
コンテキストの「配置」最適化
LLM はコンテキストの冒頭と末尾にある情報に最も強い注意を払う傾向があります(Recency Bias / Primacy Effect)。
- System Prompt / Role: 最も重要な振る舞いの定義は冒頭に。
- Reference Data: 参照資料は中盤に配置。
- Task Instruction: 具体的な指示やユーザーの質問は、コンテキストの最後に配置することで、モデルの注意をタスクに向けさせます。
実践テクニック 2:情報の圧縮と選別(Compaction & Curation)
無限に近いトークンを使えるとしても、処理速度と精度の観点から情報の「ダイエット」は不可欠です。
Context Compaction(コンテキストの圧縮)
長い会話履歴を持つチャットボットやエージェントでは、過去のやり取りをそのまま維持するとすぐにコンテキストが溢れ、ノイズが増えます。
- Summarization: 古い会話を要約して置き換える。
- Distillation: 「解決済みのタスク」に関する詳細なやり取りを削除し、「決定事項(Artifacts)」だけを残す。
Dynamic Context Injection(動的なコンテキスト注入)
全ての知識をプロンプトに含めるのではなく、必要な時に必要な情報だけを注入します。これが RAG の本質ですが、Context Engineering の視点では、「いつ」「何を」引くかの判断ロジックまでを含みます。
- Dictionary Injection: ドメイン固有の専門用語が多い場合、用語集(Glossary)を定義して注入するだけで、精度が劇的に向上します。
- Tool Use as Context: 外部ツール(検索 API や DB クエリ)の結果をコンテキストの一部として扱う設計です。
実践テクニック 3:エージェントのための環境整備(Environment Design)
AI エージェント(自律的にタスクをこなす AI)を構築する場合、Context Engineering は「職場環境の整備」に等しくなります。
抽象度の調整(The "Right Altitude")
Anthropic のガイドラインでは、指示の抽象度を「Goldilocks zone(ちょうど良い塩梅)」に保つことが推奨されています。
- 具体的すぎる(Micro-managing): 「もしAならB、もしCならD...」と条件分岐を書きすぎると、想定外の事態に脆くなる。
- 抽象的すぎる(Vague): 「いい感じにやって」では、一貫性が失われる。
- 最適: 「あなたはシニアエンジニアとして振る舞い、コードの保守性を最優先して判断してください」といった、判断基準(Heuristics) を与える。
ツール定義の純化
エージェントに渡すツール(Function Calling の定義)もコンテキストの一部です。
- ツール記述(Description)は明確に。
- 重複する機能を持つツールを排除する(エージェントが迷うため)。
- パラメータの型や説明をリッチにする。
Conclusion
Context Engineering は、LLM アプリケーション開発における「システム設計」そのものです。
これまでは「魔法のプロンプト」を探す旅に出ていたかもしれません。しかしこれからは、LLM が最大限のパフォーマンスを発揮できる「舞台」を整えるエンジニアリング力が問われます。
- 構造化: XML タグなどで情報を整理する。
- 選別: ノイズを減らし、シグナルを高める。
- システム化: 静的なテキストではなく、動的な情報パイプラインとしてコンテキストを捉える。
この3点を意識し、あなたの AI アプリケーションの「コンテキスト」を見直してみてください。驚くほど挙動が変わるはずです。
References
- Anthropic: Effective context engineering for AI agents
- Prompt Engineering Guide: Context Engineering
- Google Cloud: Long context window strategies
⚠️ 本記事に関する注意
- 本記事は執筆時点(2025年12月)の情報に基づき作成しています。
- AI 技術は発展が速いため、各モデル(Claude, GPT, Gemini 等)の仕様や推奨プラクティスが変更される可能性があります。最新の公式ドキュメントも併せて参照してください。