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

何を設計するのか

LLMは、推論時にコンテキストウィンドウへ入っている情報を使って応答します。候補には、システム指示、ユーザーの依頼、会話履歴、利用できるツールの説明、検索した資料、ツールの実行結果、作業メモなどがあります。

コンテキストエンジニアリングは、この候補を全部詰め込む作業ではありません。今の判断に必要な情報を選び、不要になった情報を外し、モデルが関係を読み取りやすい順序と形で渡します。目標は「最も長いコンテキスト」ではなく、目的に対して信号の強い、必要十分なコンテキストです。

コンテキストに入るもの

毎ターンの基本サイクル

AIエージェントでは、ツールを使うたびに新しい結果が増えます。そのため、最初に一度だけコンテキストを作って終わりではありません。

1. 次の判断に必要になり得る情報を集める
2. 関連性、権限、鮮度を確認して選ぶ
3. LLMが使いやすい形と順序で渡す
4. 応答やツール結果を評価する
5. 必要な結果だけを残し、不要な結果を外す

この選択をターンごとに繰り返します。失敗したときは、言い回しだけでなく、足りない資料、余計な履歴、曖昧なツール説明、古い状態が混ざっていないかを調べます。

Context Managementとの違い

このページでは、Context Engineeringを「何を、なぜ、どの形でモデルへ渡すかを設計し、評価する広い活動」と整理します。Context Managementは、その設計を実行中に保つため、履歴の保存、トークン量の監視、古いツール結果の削除、要約による圧縮、外部メモリへの退避などを行う運用上の仕組みとして扱います。

たとえば「注文#731の配送先を変更するため、直近の注文状態と変更規約だけを渡す」と決めるのがContext Engineeringです。会話が長くなったときに、処理済みの検索結果を消し、注文番号と承認状態を残して再開できるようにするのがContext Managementです。

ただし、この境界に業界共通の厳密な定義はなく、製品や文書によってContext Managementを広い意味で使う場合もあります。別製品名のように切り離さず、設計目的と実行時の操作という観点で区別します。

Prompt Engineeringとの違い

Prompt Engineeringは、主に指示文や例の書き方、構造、表現を改善します。Context Engineeringはプロンプトを含みますが、それだけではありません。どのツール定義を見せるか、何を検索するか、どの履歴を残すか、結果をいつ圧縮するかまで扱います。

一つの依頼文を磨くのがPrompt Engineeringなら、LLMが判断する瞬間に見える情報環境全体を整えるのがContext Engineeringです。

RAGとの関係

RAGは、質問に関係する資料を検索し、生成前にLLMへ渡す仕組みです。これはContext Engineeringで使う重要な方法の一つです。

ただし、Context EngineeringはRAGより広い概念です。検索資料だけでなく、システム指示、ツール、会話履歴、状態、例、出力形式も設計対象に含みます。検索件数を増やすだけではなく、今回の判断に本当に必要な根拠を選ぶことが重要です。

AIエージェントで重要な理由

一回の質問応答では、入力時に必要な情報をまとめて渡せることがあります。AIエージェントは、観察、判断、ツール実行を繰り返すため、情報がターンごとに増え、重要度も変わります。

最初は必要だったファイル一覧が、修正後には不要になることがあります。反対に、テスト失敗の原因やユーザーの承認は、次のターンにも残す必要があります。コンテキストを有限の作業領域として扱い、次の判断に効く情報へ更新し続ける設計が必要です。

長時間タスクの工夫

長いタスクでは、古い会話を要約するcompaction、決定事項を外部へ残す構造化メモ、調査を別のコンテキストへ分けるsub-agentなどを組み合わせます。

ただし、短くすれば必ず良くなるわけではありません。圧縮で未解決の問題や制約を落とすと、後の判断がずれます。残す情報と捨てる情報を評価し、必要なら元の資料へ戻れる参照も保持します。

設計するときの確認点

覚え方

Prompt Engineeringが「指示をどう書くか」なら、Context Engineeringは「今、モデルに何を見せるか」を設計することです。