コンテキストエンジニアリングとは？プロンプトエンジニアリングとの違いと実践を解説
コンテキストエンジニアリング（context engineering）は、AI モデルに与える情報全体（指示・ツール定義・会話履歴・外部データ）を設計し、限られたコンテキストウィンドウを最適に使う技術です。この記事では、プロンプトエンジニアリングとの違い、注目される背景、代表的な技法、ソフトウェア開発の現場での実践方法を解説します。
コンテキストエンジニアリングとは
AI エージェントが期待どおりに動くかどうかは、モデルの性能だけでなく「モデルが何を知っている状態で推論するか」で大きく変わります。コンテキストエンジニアリングとは、この「モデルに与える情報の集合（コンテキスト）」を意図して設計・管理する取り組みのことです。Anthropic は「推論時に最適なトークンの集合をキュレーションし、維持するための戦略群」と定義しています。
用語が広まったのは 2025年6月です。Shopify CEO の Tobi Lütke 氏が「プロンプトエンジニアリングよりコンテキストエンジニアリングという呼び方のほうが好きだ」と投稿し、続いて Andrej Karpathy 氏が「コンテキストウィンドウを、次のステップに必要な情報でちょうどよく満たす繊細な技術であり科学」と賛同したことで一気に定着しました。2025年9月には Anthropic が公式エンジニアリングブログで体系化しています。
言葉は新しいものの、中身が突然生まれたわけではありません。AI エージェントが複数ターンにわたって長く動くようになり、「1 回の指示文の書き方」だけでは出力品質を制御できなくなったことが背景にあります。
プロンプトエンジニアリングとの違い
プロンプトエンジニアリングは「指示文（プロンプト）をどう書くか」の最適化です。コンテキストエンジニアリングはその外側にあり、「モデルが推論の瞬間に参照する情報全体をどう構成するか」を扱います。
| 観点 | プロンプトエンジニアリング | コンテキストエンジニアリング |
|---|---|---|
| 対象 | 指示文の書き方 | モデルに与える情報全体 |
| 含まれるもの | 指示・例示の言い回し | システムプロンプト、ツール定義、会話履歴、外部データ、メモリ |
| 主な場面 | 単発のタスク | 複数ターンで動く AI エージェント |
| 問いの立て方 | 「どう頼むか」 | 「何を知っている状態にするか」 |
プロンプトエンジニアリングが不要になったわけではありません。指示文はコンテキストの一部なので、プロンプトエンジニアリングはコンテキストエンジニアリングの部分集合として残ります。
なぜ重要か: コンテキストは有限の資源
コンテキストウィンドウは年々拡大していますが、「入るだけ入れれば良い」わけではないことが分かってきました。
Chroma が 2025年7月に公開したテクニカルレポートでは、主要 18 モデルを評価し、入力が長くなるほどモデルの性能が不均一に劣化する現象（context rot、コンテキスト劣化）を報告しています。Anthropic も、LLM には人間のワーキングメモリに似た「注意の予算（attention budget）」があり、トークンを追加するたびに消費されると説明しています。
コンテキストの使い方を誤ると、次のような失敗が起きます（Drew Breunig 氏の整理より）。
- 汚染（poisoning）: ハルシネーションがコンテキストに混入し、以後の推論で繰り返し参照される
- 散漫（distraction）: 履歴が長すぎて、モデルが学習済み知識より過去のやり取りに引きずられる
- 混乱（confusion）: 関係のない情報が応答の質を下げる
- 衝突（clash）: コンテキスト内の情報同士が矛盾する
だからこそ、Anthropic は「望む結果につながる可能性を最大化する、最小で高シグナルなトークンの集合を見つける」ことを指導原理に挙げています。多く与えることではなく、選び抜くことがコンテキストエンジニアリングの中心です。
代表的な技法
LangChain の整理では、技法は「書き出す・選択する・圧縮する・隔離する」の 4 戦略に分類されます。
| 戦略 | ねらい | 技法の例 |
|---|---|---|
| 書き出す（Write） | コンテキストの外に情報を退避して保持する | 作業メモ・TODO ファイルへの書き出し、セッションをまたぐメモリ |
| 選択する（Select） | 必要な情報だけを必要なときに取り込む | RAG、実行時のファイル探索、スキルの段階的読み込み |
| 圧縮する（Compress） | 履歴を要約して空きを作る | 会話のコンパクション（要約圧縮）、古いツール実行結果の削除 |
| 隔離する（Isolate） | 作業を分割して汚染を防ぐ | サブエージェントへの委譲、タスクごとのセッション分離 |
このほか、土台としてのシステムプロンプト設計（厳格すぎず曖昧すぎない「高度」で書き、セクションを構造化する）、ツール定義の整理（役割が重複するツールを置かない）、少数の質の高い例示を選ぶことも、Anthropic が挙げる基本技法です。
開発の現場で身近な実装例が、エージェント向けの指示ファイルです。AGENTS.md は「README は人間向け、AGENTS.md は AI エージェント向け」というコンセプトのオープンな標準で、6 万以上の OSS プロジェクトが採用しています。Claude Code の CLAUDE.md も同様に、毎セッション自動で読み込まれる永続コンテキストとして機能します。Claude Code の公式ベストプラクティスは、指示ファイルの各行について「これを消したら AI はミスをするか」を自問し、しないなら削ることを勧めています。肥大化した指示ファイルは、それ自体がコンテキスト劣化の原因になるからです。
開発現場での実践: 個人の工夫から組織の仕組みへ
コンテキストエンジニアリングは、AI コーディングエージェントを使う開発（AI駆動開発）の土台にあたります。AI の出力品質はインプットの品質で決まるため、「何をどう読ませるか」の設計がそのまま開発の品質に直結するからです。
gaipack では、この設計を個人のノウハウで終わらせず、プロジェクトの構造として組み込んでいます。
- 指示の一元化: AI への作業ルールを AGENTS.md に集約し、タスク別の手順は SKILL.md として整備する。AI は必要なスキルだけを読み込むため、コンテキストを圧迫しない
- ドキュメントの構造化: 要件・設計・デザインを Markdown で管理し、AI がそのまま参照できる形に保つ。デザインは DESIGN.md にトークンやコンポーネント仕様を一元定義し、AIDD デザインとして顧客案件にも提供している
- 全体文脈の注入: プロジェクトの設計意図・ドメイン定義・依存関係を AI が常に参照できる状態を作り、生成の段階で成果物間の整合を取る
制約と検証を組み込んだ実行環境（ハーネス）の作り方は「AIエージェントに「ルールを破らせない」仕組みをどう作ったか」で、仕様を AI への入力として整備する考え方は「仕様駆動開発（SDD）とは」で紹介しています。
よくある質問
プロンプトエンジニアリングはもう不要ですか？
不要にはなりません。指示文の書き方はコンテキスト設計の一部として引き続き効いてきます。変わったのは範囲で、指示文だけでなく、ツール定義・履歴・外部データを含む情報全体を設計対象にする必要が出てきた、というのが正確な理解です。
コンテキストは多く与えるほどよいのでは？
逆効果になることがあります。入力が長くなるほどモデルの性能が劣化する現象（コンテキスト劣化）が複数モデルで確認されており、関係の薄い情報はむしろ応答の質を下げます。「最小で高シグナル」に絞るのが原則です。
何から始めればよいですか？
リポジトリに AI エージェント向けの指示ファイル（AGENTS.md や CLAUDE.md）を 1 枚置き、推測できない前提（ビルドコマンド、コード規約、テスト手順）だけを書くところから始めるのが手軽です。効果を見ながら、ドキュメントの Markdown 化やスキル整備に広げていきます。
まとめ
- コンテキストエンジニアリングとは、AI に与える情報全体を設計・管理する技術。プロンプトエンジニアリングを部分集合として含む
- コンテキストは有限の資源であり、多く与えるほど良いわけではない。「最小で高シグナル」が原則
- 技法は「書き出す・選択する・圧縮する・隔離する」の 4 戦略で整理できる
- 開発現場では、指示ファイル・構造化ドキュメント・ハーネスとして組織の仕組みに落とし込むと効果が持続する
KDDIアイレットの gaipack は、コンテキスト設計を含む AI駆動開発のサービス群を提供しています。AI エージェントを開発チームで本格的に使う仕組みづくりは、お気軽に KDDIアイレットへお問い合わせください！