「プロンプトを丁寧に書いたのに、AIが社内用語を取り違える」「資料を大量に渡したら、かえって答えが不安定になった」。AI活用を進めると、文章の指示だけでは解けない違和感にぶつかります。モデルが賢くなっても、自社の売上定義、利用可能なツール、直前の会話、守るべき権限を自動では知ってくれないからです。
そこで注目されているのがコンテキストエンジニアリングです。難しい名前ですが、結論はシンプルです。AIが次の一手を正しく選べるように、その時点で必要な情報と道具だけを、理解しやすい形で渡す設計です。長い指示文を作る技術ではありません。順番に、プロンプトとの違い、何を管理するのか、データ分析ではどう使うのかを見ていきます。
最初に結論
コンテキストエンジニアリングとは、AIの各推論時に、指示、業務知識、会話履歴、利用可能なツール、検索結果、出力形式などを選び、更新し、必要に応じて圧縮して渡す設計です。良いプロンプトはその一部ですが、実務では「何を入れるか」だけでなく「何を入れないか」「古い情報をいつ捨てるか」まで管理します。
この記事のポイント
- ・プロンプトは指示文、コンテキストはAIが判断に使える情報全体を指す
- ・情報量を増やすことではなく、次の判断に必要な高信号の情報を選ぶことが目的
- ・業務語彙、データ定義、権限、ツール説明、会話履歴を別々に管理すると更新しやすい
- ・導入は一つの質問パターンと失敗例から始め、評価しながら追加する
対象：AIエージェントを業務へ導入したい事業責任者、企画担当者、データ・AI担当者
コンテキストエンジニアリングを一文で定義する
AIにとってのコンテキストは、回答を作る瞬間に参照できる情報の集合です。利用者の質問だけではありません。システム上の役割、守るべきルール、過去の会話、検索で見つけた文書、呼び出せるツールの説明、ツールが返した結果、期待する回答形式まで含まれます。
コンテキストエンジニアリングは、この集合を毎回同じに固定するのではなく、仕事の段階に応じて組み替える考え方です。たとえば質問を解釈するときは業務用語集が重要ですが、SQLを実行する直前にはテーブル定義と権限情報が重要です。回答を書く段階では、実行結果と注意事項を残し、巨大なスキーマ一覧は外してよいかもしれません。
つまり中心にあるのは情報整理です。モデルへ何でも渡すのではなく、次の判断に必要な材料が見つけやすい状態を作ります。この発想は、人が会議へ参加するときに、全社の資料ではなく議題、最新数値、用語定義、意思決定事項をそろえることに近いものです。
プロンプトエンジニアリングとの違い
プロンプトエンジニアリングは今も重要です。ただし、主に「AIへどう指示を書くか」を扱います。コンテキストエンジニアリングは、その指示を含む実行環境全体を扱うため、範囲が広くなります。両者は置き換え関係ではなく、プロンプトがコンテキスト設計の一部になる関係です。
| 観点 | プロンプトエンジニアリング | コンテキストエンジニアリング |
|---|---|---|
| 主な対象 | 指示文、例、回答形式 | 指示、知識、履歴、ツール、状態、権限 |
| 更新の単位 | プロンプトを改善するとき | 推論や作業段階ごと |
| 代表的な問い | どう頼めば伝わるか | 今、このAIに何を見せるべきか |
| 失敗の例 | 指示が曖昧 | 古い定義、不要な履歴、似たツールが混在 |
実務で管理する6つの要素
最初から高度なメモリ機構を作る必要はありません。まず、混ざりやすい情報を六つに分けます。分けておけば、売上定義だけを更新したいときにシステム指示全体を書き換えずに済み、どの情報が誤答の原因だったかも追いやすくなります。
- 役割と方針：何をするAIか、禁止事項、確認が必要な操作
- 業務知識：売上、顧客、解約などの定義と判断ルール
- データ知識：テーブル、列、粒度、結合条件、更新時刻
- ツール：検索、SQL実行、グラフ作成などの用途と入力形式
- 短期状態：現在の質問、直前の結果、未解決の確認事項
- 長期記憶：承認済みの好みや継続利用する設定。保存根拠と期限も必要
売上分析エージェントで見る具体例
「先月、売上が落ちた理由を教えて」という質問を考えます。質問だけをLLMへ渡すと、売上が受注額か出荷額か、先月が暦月か締め期間か、返品をどう扱うかが分かりません。全テーブルを一度に渡すと、今度は候補が多すぎて誤った列や結合を選びやすくなります。
良い設計では、質問の解釈、データ取得、原因の分解、回答作成の各段階で必要な情報を切り替えます。AIに自由を与える部分と、会社として固定する定義を分けることがポイントです。
- 1. 質問を業務語彙へ置き換える：承認済み用語集から「売上」「先月」「減少」の定義を取り出し、曖昧なら利用者へ確認します。
- 2. 必要なデータだけを探す：売上マート、日付列、チャネル、商品、返品の関係を取得し、関係のない人事テーブルなどは渡しません。
- 3. 読み取り専用で集計する：期間比較と要因分解に必要なSQLを作り、許可されたデータセットだけで実行します。
- 4. 結果と根拠を残す：数値、実行SQL、参照した定義、データ更新時刻を次の推論へ渡します。巨大なスキーマ一覧はここで外せます。
- 5. 説明と不確実性を返す：確認できた要因と追加検証が必要な仮説を分け、利用者が追跡できる形で回答します。
よくある失敗は『足りない』だけではない
実務では、情報不足より情報過多が原因になることもあります。長い会話をそのまま残すと、途中で訂正された古い条件まで再利用されます。似た名前のツールが多数あると、モデルはどれを選ぶべきか判断しにくくなります。検索結果を無条件で信用すれば、権限外の情報や古い文書も混ざります。
対策は、コンテキストを追加するたびに目的を明記することです。「この情報がないと、どの判断ができないのか」に答えられなければ、常時投入せず、必要時に検索できる場所へ置きます。また、要約で圧縮した内容は原文への参照を残し、重要な数値や承認事項を要約だけに依存させないようにします。
- 古い会話と最新の指示が競合している
- 同じ意味のツールが複数あり、使い分けが説明されていない
- 取得した文書の更新日、所有者、信頼度が分からない
- 個人情報や権限外データが検索結果へ混ざる
- 失敗をプロンプト追加だけで直し、さらに情報量を増やしている
小さく始めるための実装順序
最初の対象は、頻度が高く正解を確認できる一つの質問にします。質問、期待する答え、正しいSQL、必要な用語、許可するテーブルを並べ、現在のAIがどこで間違うかを観察します。その失敗を直す情報だけを追加すれば、コンテキストが無制限に膨らみません。
次に、入力したコンテキスト、ツール呼び出し、最終結果を一つの記録として保存します。モデルを変更したときも同じ質問で再評価できる状態が重要です。業務語彙や権限は担当者を決め、更新日を持たせます。コンテキスト設計は一度完成させる文書ではなく、利用結果から保守するプロダクトだからです。
次に読む記事
参考文献
本記事は以下の公式文書、標準、論文、公開記事・投稿を確認し、初心者向けに論点を再構成しています。 仕様や制度は更新されるため、導入時はリンク先の最新版も確認してください。
- Effective context engineering for AI agents — Anthropic（2025-09-29）（最終確認：2026-08-07）：コンテキストを有限の資源として扱う考え方と実装上の論点を参照。
- Context engineering in agents — LangChain（最終確認：2026-08-07）：モデル、ツール、ライフサイクルのコンテキスト分類を参照。
- A practical guide to building AI agents — OpenAI（最終確認：2026-08-07）：ツール、指示、オーケストレーション、ガードレールの設計原則を参照。
- Context engineeringについての公開投稿 — Andrej Karpathy / X（2025-06-25）（最終確認：2026-08-07）：業界での用語定着を確認する補助資料。技術仕様の根拠には使用していません。
よくある質問
コンテキストエンジニアリングとプロンプトエンジニアリングは同じですか？
同じではありません。プロンプトエンジニアリングは主に指示文や例の書き方を扱います。コンテキストエンジニアリングは、それに加えて検索データ、会話履歴、ツール、権限、状態、出力形式をいつ何のために渡すかまで扱います。
コンテキストウィンドウが大きければ設計は不要ですか？
不要にはなりません。入る量が増えても、古い情報、矛盾する定義、無関係なツールが混ざれば判断は難しくなります。容量より、必要な情報を選び更新する仕組みが重要です。
RAGはコンテキストエンジニアリングの一部ですか？
はい。RAGは必要な外部情報を検索してコンテキストへ加える代表的な方法です。ただし、コンテキスト設計にはツール選択、履歴の圧縮、権限、業務定義などRAG以外の要素も含まれます。
まとめと次の一歩
コンテキスト設計の成否は情報量ではなく、判断段階ごとに用語・権限・ツール・履歴を選び、使った根拠を追跡できるかで決まります。情報を足す前に、その情報がどの判断に必要かを明らかにすることが重要です。