社内AIを導入して数か月。プロンプトの書き方を何度も変え、指示文を長くし、役割設定を足し、それでも「聞き方によって当たったり外れたりする」状態から抜け出せない。そんな段階でご相談をいただくことが増えました。

このとき問題はたいてい、聞き方ではなく AIに渡っている情報の側 にあります。2026年に入って定着した「コンテキストエンジニアリング」という言葉は、まさにこの部分を指しています。

この記事では、コンテキストエンジニアリングとは何か、プロンプトエンジニアリングやRAGと何が違うのかを整理したうえで、自社の社内ナレッジで今日から実践できる5ステップを紹介します。

この記事で分かること

コンテキストエンジニアリングの意味と、プロンプトエンジニアリングとの違い
RAGは不要になったのか、それともコンテキストエンジニアリングの一部なのか
社内AIの回答が安定しないときに疑うべき「4つの失敗モード」
自社のナレッジを点検する「コンテキスト棚卸し」の具体的な手順
情報の渡し方（アーキテクチャ）を選ぶときの判断材料

コンテキストエンジニアリングとは -- 「聞き方」ではなく「渡す情報全体」を設計すること

コンテキストエンジニアリング（Context Engineering）とは、AIが答えを出す瞬間に目にしている情報の一式を、目的に合わせて設計する取り組みのことです。

ここでいうコンテキストは、人間が入力した質問文だけではありません。AIが1回の回答を作るとき、実際には次のようなものがまとめて渡されています。

要素	中身	誰が決めているか
指示	役割・答え方のルール・禁止事項	サービス提供側または管理者
質問	利用者がその場で入力した文	利用者
社内情報	参照された社内文書の中身	ナレッジの整備状況と検索の仕組み
会話履歴	直前までのやり取り	自動
ツールの結果	検索・APIなどの実行結果	仕組み側
出力形式	箇条書き・出典の付け方など	設計者

利用者が触れるのは、このうち「質問」の1行だけです。残りの大半は設計者が決めているのに、多くの現場ではそこを触らないまま、質問文の書き方だけで精度を上げようとしています。プロンプトを工夫しても頭打ちになるのは、そのためです。

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

両者はよく混同されますが、扱っている範囲が違います。

	プロンプトエンジニアリング	コンテキストエンジニアリング
設計するもの	質問文・指示文の書き方	AIに渡る情報の一式と、その集め方
主な打ち手	役割設定、手順の明示、例示	情報の取捨選択、鮮度管理、構造化、権限制御
効く場面	単発の作業を上手にやらせたい	同じ業務を毎日安定して回したい
限界	元の情報が無ければどう書いても答えられない	情報整備の手間がかかる

プロンプトエンジニアリングが不要になったわけではありません。ただ、社内ナレッジの活用のように「元になる情報が社内にある」用途では、効くのは圧倒的にコンテキスト側です。就業規則がアップロードされていなければ、どれほど巧みに質問しても休職の条件は出てきません。

RAGとの関係 -- 対立ではなく包含

「コンテキストエンジニアリングが来たからRAGは終わった」という説明を見かけますが、これは正確ではありません。RAGは、コンテキストを組み立てる方法の一つです。

プロンプトエンジニアリング: 渡す文章の書き方を工夫する
RAG: 質問に関連しそうな文書を自動で探して、コンテキストに足す
コンテキストエンジニアリング: 何を・どれだけ・どんな順で・どんな形で渡すかを設計する（RAGを使うかどうかもこの判断に含まれる）

つまり関係は上下です。RAGは手段の一つで、コンテキストエンジニアリングはその上位にある設計の話です。「RAGは無駄だった」と言われる事例の多くは、RAGという技術そのものではなく、渡すものを設計せずに検索だけ足した結果として起きています。この論点は「RAG不要論」は本当か？社内ナレッジAIの判断軸6つで詳しく整理しています。

なぜプロンプトを工夫しても回答が安定しないのか -- 4つの失敗モード

社内AIの回答が不安定なとき、原因はほぼ次の4つに分類できます。それぞれ症状が似ているのに打ち手が正反対なので、まずどれなのかを切り分けてください。

失敗1: 不足 -- そもそも渡っていない

社内AIが「記載がありません」と答えるとき、多くは情報が渡っていません。文書自体が存在しない場合もあれば、担当者のPCやメールの中にあって取り込まれていない場合もあります。

暗黙のルール（「この申請は部長を通してから」など）は、そもそも文書になっていないことが大半です。これは検索の精度ではなく、ナレッジの在庫の問題です。

失敗2: 過多 -- 渡しすぎて薄まる

逆に、関連しそうな文書を大量に渡すと精度が落ちます。長い入力の中盤にある情報が拾われにくくなる現象は "Lost in the Middle" として知られており、「全部読ませれば正確になる」は成り立ちません。

コストの面でも同じです。質問のたびに大量の文書を送り続ける設計は、利用が増えるほど費用が膨らみます。この点はRAGはもう古い？長文コンテキスト時代のナレッジベース設計で数値とともに検討しています。

失敗3: 汚染 -- 古い版と新しい版が同居している

実務で一番やっかいなのがこれです。2024年版と2026年版の規程が両方入っていると、AIはどちらも「社内の正しい情報」として扱います。結果として、それらしいのに古い回答が返ります。

しかもこの誤りは、利用者から見て間違いだと気づきにくいのが厄介です。運用では「入れること」より「古いものを消すこと」のほうが精度に効きます。

失敗4: 形が悪い -- 書いてあるのに読み取れない

スキャンしただけの画像PDF、画像として貼られた表、複数のテーマが混ざった長大なファイル。これらは中身があってもAIが正しく取り出せません。

書き方の細部が回答精度をどう変えるかは、同じ内容で書き方だけ違う文書を実際に取り込んで検証したAIが答えられる社内文書の書き方にまとめています。結論だけ言えば、丁寧な日本語よりも「1ファイル1テーマ」「1行目に何の文書か書く」のほうがはるかに効きます。

実践編: コンテキスト棚卸しの5ステップ

ここからが本題です。コンテキストエンジニアリングは概念として理解しても意味がなく、自社の業務に当てはめて初めて効果が出ます。全社のナレッジを一度に整理しようとすると必ず頓挫するので、業務を1つに絞って進めてください。

ステップ1: AIに任せたい判断を1つだけ決める

「社内のことを何でも答えるAI」は目標として大きすぎます。質問の型が決まっている業務を1つ選んでください。

経費精算で「これは経費で落ちるか」を判断する
有給・慶弔・育休など休暇まわりの問い合わせに答える
見積依頼に対して標準価格と割引条件を答える
顧客からの製品仕様の質問に答える

選ぶ基準は「同じ質問が月に何度も来ている」ことです。頻度が高いほど、整備の効果がすぐ数字に出ます。

ステップ2: 人が判断するときに見ているものを全部書き出す

その業務のベテランが判断するとき、頭の中と手元にある情報を残らず列挙します。ここで重要なのは、文書になっていないものも書き出すことです。

例として、経費精算の可否判断ならこうなります。

経費規程（文書あり）
勘定科目の一覧（Excel）
過去に承認・却下された事例（担当者の記憶）
「5,000円を超えたら領収書の但し書きを確認する」という運用ルール（口伝）
部署ごとの例外（一部だけメールに残っている）

このリストが、その業務でAIに渡すべきコンテキストの設計図になります。

ステップ3: 一つずつ「AIに渡せる形か」を点検する

書き出した項目を、次の3列で点検します。表計算ソフトに写して埋めるだけで十分です。

判断材料	文書として存在するか	最新版が1つに定まるか	AIが読める形か
経費規程	ある	旧版がフォルダに残存	PDF（テキスト）
勘定科目一覧	ある	ある	Excelの表
過去の承認事例	ない（記憶）	--	--
但し書きの運用	ない（口伝）	--	--
部署ごとの例外	メールに散在	不明	不明

この表が埋まった時点で、なぜAIが安定しないのかはほぼ説明できます。上の例なら、判断材料5つのうち3つがそもそもAIに渡っていません。プロンプトをいくら工夫しても解決しない領域です。

ステップ4: 穴を埋める -- 完璧を目指さない

点検で見つかった穴を埋めます。順序は「よく聞かれるものから」です。

口伝は1枚にする: 完成度は求めず、箇条書きで十分です。「但し書きに品名が無い領収書は再提出を依頼する」の1行があるだけで、AIは答えられるようになります
旧版を消す: 参照させたくない文書は、置き場所から外すのが最も確実です
表はテキストで持つ: 画像として貼られた表は読み取り精度が落ちます
散在しているものを1か所に集める: メールやチャットに埋もれた例外は、見つかった分だけでも文書に移します

すべて埋める必要はありません。判断材料の8割が揃えば、実務では十分機能します。

ステップ5: 10問の質問で検証し、外れた質問から直す

最後に、その業務で実際に来ている質問を10問用意し、AIに投げて答え合わせをします。想定質問ではなく、問い合わせ履歴から実際の文面を持ってくるのが重要です。

正しく答えられた質問は、そのまま運用に乗せる
外れた質問は、ステップ3の表に戻ってどの材料が欠けていたかを特定する
「記載がありません」と正直に答えられているかも確認する（推測で答える状態のほうが危険です）

この10問は、文書を追加・改訂したあとに毎回流す回帰テストとして残しておいてください。ナレッジは足すたびに壊れる可能性があるので、確認の型を持っておくと運用が安定します。

「渡し方」をどう設計するか -- 3つのアプローチ

棚卸しで材料が揃ったら、次は「毎回どうやって集めて渡すか」の設計です。大きく3つの考え方があり、組織の文書量と権限要件によって適切な選択が変わります。

アプローチ	集め方	向いている状況	注意点
全部渡す（長文コンテキスト）	文書をまとめて毎回投入	文書が少なく、全員が同じものを見てよい	量が増えるとコストと精度の両方で破綻する
検索して足す（RAG）	質問に近い断片を検索して投入	文書量が多く、権限を分けたい	断片化により文書をまたぐ質問に弱い
たどって集める（ナビゲーション型）	目次構造から関連文書を辿って収集	文書に構造があり、根拠を示したい	文書の構造化が前提になる

どれが優れているという話ではなく、先ほどの棚卸しの結果によって答えが変わります。判断軸の詳細は「RAG不要論」は本当かを参照してください。

ものしりAIの設計 -- 目次をたどってコンテキストを組み立てる

ものしりAIは3つ目のナビゲーション型を採用しています。アップロードされた社内文書をあらかじめ階層的な構造（スキルツリー）に整理しておき、質問が来たらAIがその目次をたどって必要な文書だけを集め、根拠として提示します。

これは技術的な流行を追った選択ではなく、上で挙げた4つの失敗モードへの対処として設計したものです。

過多への対処: 関連しそうなものを全部渡すのではなく、たどり着いた文書だけを渡す
汚染への対処: どの文書を根拠にしたかを提示するため、古い版を参照していれば利用者が気づける
不足への対処: 該当する文書に行き着かなかった場合は、推測せず「記載がない」と答える

なぜ検索方式からこの方式に移行したのかは、実際の失敗例とともにRAGの限界とは？ハルシネーションを防ぐskillモードを実例で解説で書いています。整理された文書をそのままチャットウィジェットやLINEから聞ける形にできるので、棚卸しで整えたナレッジをそのまま業務の動線に乗せられます。

よくある質問

Q. コンテキストエンジニアリングは、専門のエンジニアがいないと無理ですか。

いいえ。この記事の5ステップに技術的な作業は含まれていません。業務を知っている人が判断材料を書き出す作業が中心で、むしろ現場の担当者のほうが適任です。ツールの設定は導入するサービス側が引き受ける部分です。

Q. 文書を整備してからAIを入れるべきですか。

逆をおすすめします。まず入れて、答えられなかった質問から直すほうが確実です。整備すべき箇所は机上では分からず、実際に外れた質問が教えてくれます。

Q. AIエージェントを作る場合も同じ考え方でよいですか。

同じです。むしろエージェントのほうが重要度は上がります。複数の手順を自動で回すぶん、各ステップで渡る情報が積み上がり、失敗2（過多）と失敗3（汚染）が起きやすくなるためです。1ステップごとに何を渡すかを決める設計が必要になります。

Q. プロンプトの工夫はもう意味がないのですか。

意味はあります。ただし順序が違います。コンテキストが正しく揃っている状態で初めて、プロンプトの工夫が効きます。材料が足りない料理は、レシピを直しても改善しません。

まとめ

コンテキストエンジニアリングは新しい技術ではなく、AIに何を渡すかを決めるという、当たり前だが省略されがちな設計作業です。要点を整理します。

コンテキストエンジニアリングとは、AIが回答時に見ている情報の一式を設計すること。質問文はその一部にすぎない
プロンプトエンジニアリングは「聞き方」、コンテキストエンジニアリングは「渡す情報全体」を扱う。社内ナレッジ用途では後者のほうが効果が大きい
RAGは対立概念ではなく、コンテキストを組み立てる手段の一つ。「RAGが無駄だった」事例の多くは、設計せずに検索だけを足したケース
回答が安定しない原因は、不足・過多・汚染・形の4つに分類できる。症状は似ているが打ち手は正反対
実践は業務を1つに絞り、判断材料を書き出し、渡せる形かを点検し、穴を埋め、10問で検証する

まずは、今いちばん問い合わせが多い業務を1つ選び、ベテランが何を見て判断しているかを書き出すところから始めてみてください。その紙一枚が、社内AIの精度を決めるいちばん大きな要素です。

コンテキストエンジニアリングとは？社内ナレッジで実践する5ステップ