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

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

プロンプトエンジニアリングは「AIへの指示文を工夫する」技術だ。質問の仕方、Few-shotの例示、Chain-of-Thoughtの指示。いずれも「何を聞くか」を最適化する。

コンテキストエンジニアリングはその一段上にある。AIが回答を生成する際に参照する全情報を設計する。システムプロンプト、ユーザーの質問、検索で取得したドキュメント、過去の会話履歴、ツールの出力結果、ルールファイル。これら全てを含めた入力全体を設計するのがコンテキストエンジニアリングだ。プロンプトはその中の一部にすぎない。

AIエージェントの普及が背景

AIエージェントの普及がこの概念を必要にした。エージェントは1回の指示で複数のツールを呼び出し、検索結果を取得し、過去の記憶を参照し、他のAIと連携する。この一連の処理で、コンテキストウィンドウに入る情報は数千から数万トークンに膨れ上がる。

ここで問題が起きる。情報を全部入れるとAIが重要な指示を見落とす。少なすぎると文脈が不足して的外れな回答をする。何を入れて、何を入れないか。その設計が、AIの回答品質を決定的に左右する。

構成要素

Andrej Karpathyの定義をベースに整理すると、6つの要素で構成される。

まずシステムプロンプト。AIの行動ルールや制約条件を定義する。次にユーザーの質問。今回のタスクで何を求められているかを伝える。そして検索拡張（RAG）。外部データベースやドキュメントから取得した関連情報を添える。

さらにツール出力。API呼び出しやコマンド実行の結果もコンテキストに入る。会話履歴は過去のやり取りの要約または全文。そしてメモリ。長期記憶システムから引き出した過去の教訓や判断。

これらを適切な量、適切な順序、適切なフォーマットでコンテキストウィンドウに配置する。配置の設計がコンテキストエンジニアリングの核心だ。

RAGとの違い

RAGは外部のデータベースやドキュメントから関連情報を検索して取得し、AIのコンテキストに追加する技術だ。コンテキストエンジニアリングの構成要素の一つにあたる。

両者の関係を整理すると、RAGは「何を取ってくるか」。コンテキストエンジニアリングは「取ってきた情報を、他の情報とどう組み合わせてAIに渡すか」。RAGで取得した検索結果をそのまま全部入れれば良いわけではない。システムプロンプト、過去の教訓、ユーザーの会話履歴、ツールの出力結果とあわせて、適切な量と順序でコンテキストウィンドウに配置する。その全体設計がコンテキストエンジニアリングだ。

たとえるなら、RAGは図書館から必要な本を探してくる司書。コンテキストエンジニアリングは、その本と手元のメモとルールブックをどの順番で机に並べるかを設計する仕事だ。