コンテキストエンジニアリングとは、生成AIが仕事をするために必要な前提情報を選び、整理し、適切な形で渡す技術です。OpenAI API のような生成AI APIでも、指示、会話履歴、ツール、入力データをどのように渡すかが出力品質に影響します。[1] プロンプトが「指示文の設計」だとすると、コンテキストエンジニアリングは「作業に必要な資料セットの設計」です。
コンテキストとは何か
Section titled “コンテキストとは何か”コンテキストとは、AIが回答を作るときに参照できる情報のまとまりです。
例:
- ユーザーの指示
- 会話履歴
- ドキュメント本文
- コードファイル
- エラーログ
- 設計方針
- 出力フォーマット
- 禁止事項や安全ルール
人間が仕事をするときも、依頼文だけでは足りません。過去の経緯、関連資料、現在の制約、完成物の条件が必要です。AIにも同じように、作業に必要な文脈を渡す必要があります。
プロンプトとコンテキストの違い
Section titled “プロンプトとコンテキストの違い”| 観点 | プロンプト | コンテキスト |
|---|---|---|
| 主な役割 | 何をしてほしいかを指示する | 判断材料を渡す |
| 例 | 「要約して」「比較して」 | 議事録、仕様書、過去ログ |
| 設計の焦点 | 指示の明確さ | 情報の選択と整理 |
| 失敗例 | 指示が曖昧 | 必要情報が不足、不要情報が多すぎる |
プロンプトが良くても、コンテキストが不足していればAIは推測で答えます。逆に、資料を大量に渡しても、重要箇所が埋もれると回答品質は下がります。
コンテキスト設計の基本
Section titled “コンテキスト設計の基本”1. 必要な情報だけを渡す
Section titled “1. 必要な情報だけを渡す”長い資料をすべて渡すより、タスクに関係する部分を選ぶ方がよい場合があります。AIのコンテキストウィンドウが大きくても、重要情報がノイズに埋もれると見落としが起きます。
2. 優先順位を付ける
Section titled “2. 優先順位を付ける”同じコンテキスト内でも、必ず守るルール、参考情報、過去の議論は重要度が違います。
優先順位:
1. セキュリティ要件
2. 現在の仕様
3. 既存コードの実装方針
4. 過去の議論メモこのように優先順位を明記すると、情報が衝突したときにAIが判断しやすくなります。
3. 情報の出所を明確にする
Section titled “3. 情報の出所を明確にする”AIに資料を渡すときは、どの情報がどのファイル、どの日付、どの発言に由来するかを残すと、検証しやすくなります。
参照資料:
- product-spec.md: 現在の正式仕様
- meeting-2026-05-01.md: 未確定の議論メモ
- error.log: 直近の失敗ログ4. 古い情報を混ぜない
Section titled “4. 古い情報を混ぜない”古い仕様、解決済みのバグ、過去の仮説が残っていると、AIが誤った前提で回答することがあります。長い作業では「現在有効な情報」と「履歴」を分けることが重要です。
よくある失敗
Section titled “よくある失敗”このエラーを直して。エラーメッセージ、実行コマンド、環境、関連コードがなければ、AIは一般論で答えるしかありません。
リポジトリ全体を読んで、いい感じに直して。範囲が広すぎると、重要な判断軸が曖昧になります。対象ファイル、再現手順、期待動作を絞る方が安定します。
矛盾した情報
Section titled “矛盾した情報”「Aを使う」と書かれた仕様と、「Aは禁止」と書かれたメモが同時に渡されている。矛盾がある場合は、どちらを優先するか明記する必要があります。
RAGとの関係
Section titled “RAGとの関係”RAG（Retrieval-Augmented Generation）は、外部データベースやドキュメントから関連情報を検索し、その結果をAIに渡して回答させる仕組みです。
RAGはコンテキストエンジニアリングの一部です。ただし、コンテキストエンジニアリングは検索だけではありません。検索結果の選び方、優先順位、要約、履歴管理、制約の渡し方まで含みます。
ハーネスエンジニアリングへの接続
Section titled “ハーネスエンジニアリングへの接続”コンテキストエンジニアリングは、AIに「何を見せるか」を設計します。一方、ハーネスエンジニアリングは、AIが「何を実行できるか」「どう検証するか」「失敗したらどう戻るか」まで設計します。
たとえばコード修正では、コンテキストとして仕様、関連ファイル、エラーログを渡します。さらにハーネスとして、テスト実行、差分確認、権限管理、レビュー手順を用意します。実務ではこの組み合わせが重要です。
- コンテキストエンジニアリングは、AIに渡す前提情報を設計する技術
- 指示文だけでなく、資料、履歴、制約、優先順位を整理する
- 情報不足、情報過多、矛盾した情報は回答品質を下げる
- RAGはコンテキストエンジニアリングの一部
- 次の段階では、ツール実行や検証まで含むハーネスエンジニアリングが重要になる
よくある質問
Section titled “よくある質問”Q: コンテキストウィンドウが大きいモデルなら整理は不要ですか?
A: 不要ではありません。Transformerは長い入力を扱える基盤になりましたが、重要情報が目立つ形で整理されていないと、見落としや誤解が起きます。[2]
Q: RAGを導入すればコンテキスト設計は完了ですか?
A: いいえ。RAGは関連情報を取ってくる仕組みですが、何を正とするか、どの情報を優先するか、回答をどう検証するかは別途設計が必要です。
Q: 会話履歴は全部残すべきですか?
A: 常に全部残す必要はありません。現在の作業に必要な決定事項、未解決事項、制約を要約して残す方が安定することがあります。
- OpenAI, OpenAI API documentation
- Ashish Vaswani et al., Attention Is All You Need, 2017年6月12日