「社内AIを入れたが、たまに的外れな答えを返す」「同じことを聞いても、日によって回答がぶれる」——業務でAIを使い始めると、多くの企業がこの壁に当たります。プロンプトの言い回しをいくら直しても安定しない。その原因の多くは、指示文ではなく、AIに渡している“文脈”の設計不足にあります。ここで鍵になるのが コンテキストエンジニアリング です。結論から言うと、コンテキストエンジニアリングとは、AIが答えを出すために見る「文脈（コンテキスト）全体」——指示・社内データ・履歴・ツールの結果などを、必要十分に組み立てる設計で、プロンプトエンジニアリングの次の段階にあたります。
この記事では、コンテキストエンジニアリングの意味、プロンプトエンジニアリングとの違い、なぜ文脈が精度を左右するのか、業務で安定させる進め方を解説します（誤答を抑える全般はハルシネーション対策、自社データの参照はRAG・ファインチューニングの使い分けも参照）。
コンテキストエンジニアリングとは？——「文脈全体」を設計する
コンテキストエンジニアリングとは、AIが回答を生成するときに見る文脈の全体を、そのタスクに必要十分な形で組み立てることです。 プロンプト（指示文）は、その文脈の一部にすぎません。
AIは、渡された文脈の中にある情報だけをもとに答えます。その文脈は、実は複数の要素からできています。
| 文脈に含まれる要素 | 中身 |
|---|---|
| 指示（システムプロンプト） | 役割・ルール・してはいけないこと |
| 参照データ | 質問に関係する社内文書やデータ（RAGで取得） |
| 履歴・記憶 | これまでの会話や、過去のやりとりの要約 |
| ツールの結果 | 検索・計算・システム照会などの実行結果 |
| 出力の形式 | 回答の構造・長さ・書式の指定 |
コンテキストエンジニアリングは、この一式を「何を・どの順で・どれだけ」渡すかまで設計します。 指示文の言い回しを磨くのがプロンプトエンジニアリングなら、コンテキストエンジニアリングは、AIが見る情報の“組み立て”そのものを扱う、一段広い取り組みです。
プロンプトエンジニアリングとどう違う？
プロンプトエンジニアリングは「指示文の書き方」、コンテキストエンジニアリングは「渡す情報一式の設計」で、後者の中に前者が含まれます。
| 観点 | プロンプトエンジニアリング | コンテキストエンジニアリング |
|---|---|---|
| 主な対象 | 指示文の言い回し・型 | AIが見る文脈全体（指示＋データ＋履歴＋ツール結果） |
| 主な問い | どう書けば伝わるか | 何を・どれだけ・どの順で渡すか |
| 効く場面 | 単発の生成タスク | 業務で継続して使うAI・AIエージェント |
単発の文章生成なら、良い指示文（プロンプト）だけでも十分なことは多いです。しかし、社内データを参照し、複数ステップで動くAIエージェントを業務で安定させる段階になると、指示文だけでは足りません。「そのとき何の情報を持たせるか」を設計しないと、回答は揺らぎます。プロンプトエンジニアリングの先に、コンテキストエンジニアリングがある——そう捉えると位置づけが分かりやすくなります。
なぜ文脈の設計が精度を左右するのか？
AIは渡された文脈の中で答えるため、文脈が「不足」でも「過剰」でも精度が落ちるからです。 ここが最も重要な原理です。
- 不足：必要な情報が文脈に入っていないと、AIは足りない部分を推測で埋め、誤答（ハルシネーション）します。「知らないこと」を渡さなければ、AIは知りようがありません
- 過剰：無関係な情報を大量に詰め込むと、肝心な情報が埋もれ、AIがどれを重視すべきか分からなくなります。精度が落ちるうえ、トークンが増えてコストもかさみます（コストの観点はコスト最適化も参照）
- 順序・鮮度：重要な情報が後ろに埋もれていたり、古い情報が混ざっていたりすると、AIは誤った前提で答えます
つまり、目指すのは必要な情報を、必要なだけ、分かりやすい順で、新しい状態で渡すこと。この過不足のなさが、回答の正確さと、日によってぶれない安定性を生みます。良いプロンプトを書く前に、渡している文脈が適切かを見るべき理由がここにあります。
具体例：社内AIの回答がぶれる原因を文脈から直す
抽象的なので、ある社内AIの改善を例にします（状況はすべて説明用の仮の例です）。
ある企業が、社内規程に答えるAIを導入しましたが、「同じ質問でも答えがぶれる」「古い規程で回答することがある」という不満が出ていました。プロンプト文を何度も直しても改善しません。そこで、文脈の観点で原因を切り分けると、問題が見えてきます。
| 症状 | 文脈の原因 | 打ち手 |
|---|---|---|
| 回答がぶれる | 関連文書を大量に渡し、重要な条項が埋もれていた | RAGで関連箇所だけに絞って渡す |
| 古い規程で答える | 新旧の規程が両方文脈に入っていた | 最新版だけを参照するようデータを整理 |
| 質問の背景を無視 | 会話履歴を渡しておらず、文脈が毎回リセット | 直近の履歴や要約を文脈に含める |
| 答えの形式が不安定 | 出力フォーマットを指定していなかった | 回答の構造を指示に明示する |
これらは、どれもプロンプト文の言い回しの問題ではなく、「AIに何を渡しているか」の問題でした。渡す文脈を過不足なく整えるだけで、回答は安定し、古い情報による誤りも消えます。プロンプトをいじる前に文脈を疑う——この順番が、遠回りに見えて近道です。
業務でAIを安定させる進め方
成功の鍵は、プロンプト文ではなく「誤答の原因を文脈の観点で切り分ける」ことから始めることです。 進め方の勘所は3つです。
- 誤答を集めて原因を分類する：間違えた回答を集め、「情報の不足／過剰／古さ／順序」のどれが原因かを見る。多くは文脈側に原因がある
- 参照データと履歴を設計する：RAGで渡す情報を関連箇所に絞り、会話履歴は要約して持たせる。最新のデータだけを参照するよう整える
- 評価しながら改善する：文脈を変えたら、代表的な質問群で回答が改善したかを評価する。当てずっぽうで直さず、良し悪しを測りながら詰める（評価と運用は本番運用の監視・評価を参照）
難しいのは、適切な文脈は自社のデータと業務に強く依存する点です。どの文書を・どう検索し・どこまで渡すかは、その企業のデータ構造と業務の文脈を理解して初めて設計できます。汎用のツールやプロンプト集をなぞるだけでは、自社のAIは安定しません。
DeploAIのFDEはコンテキストエンジニアリングをどう支援するか
DeploAI の FDE（Forward Deployed Engineer）は、企業のAI・AIエージェントが安定して正しく答えるための文脈設計を、現場で実装・改善します。
AIの精度を業務レベルに引き上げる難所は、モデルやプロンプトそのものより「そのとき何の文脈を渡すか」の設計にあります。FDE は、誤答の原因を文脈の観点で切り分け、参照データの検索・絞り込み（RAG）、履歴や記憶の持たせ方、ツール結果の渡し方、トークン量とのバランスまでを設計し、評価と運用に組み込みます。 文脈は自社のデータと業務に強く依存するため、机上の設計で終わらせず、実装して精度を出し、社内で保守できる形に残すところまで伴走するのが特徴です。
まとめ
- コンテキストエンジニアリングとは、AIが見る文脈全体（指示・社内データ・履歴・ツール結果・形式）を、必要十分に組み立てる設計。プロンプトエンジニアリングの次の段階。
- 企業AIが「的外れ」「答えがぶれる」原因の多くは、指示文ではなく渡している文脈の不足・過剰・古さ・順序にある。
- 目指すのは、必要な情報を、必要なだけ、分かりやすい順で、新しい状態で渡すこと。過不足のなさが正確さと安定性を生む。
- 進め方は、誤答を集めて原因を分類→参照データと履歴を設計→評価しながら改善。プロンプトを直す前に文脈を疑う。
- 適切な文脈は自社のデータと業務に依存する。DeploAI の FDE が、文脈設計を実装・評価・運用まで伴走する。
企業AIの精度を安定させたい方は、プロンプトエンジニアリングで指示設計の基礎を、ハルシネーション対策で誤答の抑え方を確認してみてください。導入のご相談はお問い合わせから承っています。
関連記事：プロンプトエンジニアリング｜生成AIのハルシネーション対策｜自社データをAIに使わせる（RAG）｜生成AI・AIエージェントの本番運用
