AIのコンテキストとは？プロンプト・会話履歴・RAGとの違いを整理

AIツールを使っていると、よく「コンテキストが足りない」「コンテキストを渡す」「コンテキストウィンドウが大きい」といった言い方が出てきます。
何となく「前後関係」や「文脈」だとは分かっても、プロンプトと何が違うのか、会話履歴はどこまで覚えているのか、RAGとはどう関係するのかで混乱しやすい言葉です。

AI文脈のコンテキストは、ざっくり言えば、AIがその回答を作るために参照できる材料です。
この記事では、AnthropicのContext windowsドキュメントとGoogle Cloudの生成AI用語集、そして「Lost in the Middle」などの研究を確認しながら、AIが言うコンテキストを初心者向けに整理します。さらに、監査でつまずきやすい「重要条件が中盤に埋もれて見落とされる現象の再現と対処」「RAGで権限外文書が混ざる具体ケース」まで踏み込みます。

AIツールを使うときに、実際にどこを削るとセッションやトークンを節約しやすいかを見たい場合は、AIツールのセッションやトークンを節約する方法｜無駄な会話・長文入力・モデル選びを見直す もつながります。

AIのコンテキストとは

AIのコンテキストとは、LLMが次の出力を作るときに参照できる情報のまとまりです。
利用者が入力した質問だけでなく、会話履歴、システム側の指示、添付ファイル、検索で取ってきた文書、ツールの実行結果などが含まれます。

たとえば、次のような会話を考えます。

ユーザー: Laravelでログイン機能を作っています。
AI: どの認証方式を使っていますか？
ユーザー: Breezeです。ログイン後に管理画面へ飛ばしたいです。

最後の「管理画面へ飛ばしたいです」だけを見ると、何の話か分かりません。
でもAIは前の会話もコンテキストとして参照できるため、「Laravel」「Breeze」「ログイン後のリダイレクト」という前提を使って回答できます。

つまり、コンテキストはAIが今の発言を理解するための前提情報です。

コンテキストに含まれるもの

AIに渡されるコンテキストは、チャット画面に見えている文章だけとは限りません。
サービスや実装によって違いますが、実務では次のようなものがコンテキストになります。

ここで大事なのは、コンテキストは「AIが知っていること」そのものではないという点です。
モデルが事前学習で知っている一般知識と、いま渡されたコンテキストは分けて考えます。

プロンプトとの違い

プロンプトは、利用者がAIに渡す指示や質問です。
コンテキストは、それを含むもっと広い材料です。

たとえば、プロンプトが「原因を調べて」だけでも、直前にエラーログ、設定ファイル、実行環境が渡されていれば、AIはそれをコンテキストとして使えます。
逆に、プロンプトが丁寧でも、必要なログやコードがなければ、AIは推測で答えやすくなります。

ここが、プロンプトエンジニアリングだけでは足りない理由です。
良い指示を書くことも大事ですが、正しい材料を渡すことも同じくらい重要です。

コンテキストウィンドウとは

コンテキストウィンドウは、AIが一度に参照できる情報量の上限です。
Google Cloudの生成AI用語集でも、コンテキストウィンドウはモデルが与えられたプロンプトで処理できるトークン数として説明されています。

たとえば、長い仕様書や複数ファイルのコードを読み込ませたいとき、コンテキストウィンドウが小さいと全部を一度に渡せません。
一方で、大きいコンテキストウィンドウなら、大量の資料をまとめて渡せる可能性があります。

ただし、長ければ長いほど良いわけではありません。

• 不要な情報が多いと、重要な条件が埋もれる
• 古い仕様と新しい仕様が混ざると、判断がぶれる
• 入力トークンが増えると、APIコストや処理時間が増える
• 機密情報を余計に渡すリスクが増える
• モデルが長文の中の小さな条件を見落とすことがある

AnthropicのContext windowsドキュメントでも、コンテキストには入力、出力、ツール利用、思考関連の要素が含まれ、モデルごとに扱える上限があることが説明されています。
実務では「大きいから全部入れる」ではなく、「必要な情報を選んで入れる」と考える方が安定します。

ロストインミドルを自分で再現する

「長いコンテキストは見落としが増える」と言われても、実感が湧かないと思います。これは研究で繰り返し確認されている現象で、自分の手元でも簡単に再現できます。

研究「Lost in the Middle: How Language Models Use Long Contexts」では、答えを含む文書を大量のダミー文書の中に置き、その位置だけを動かして正答率を測りました。結果は、文書列の先頭か末尾に答えがあるときは正答率が高く、ちょうど真ん中にあるときが最も低い、というU字カーブになりました。これはGPT-3.5系、GPT-4、Claude系など複数のモデルで再現されています。人間が一覧の最初と最後を覚えやすい記憶特性に似ています。

手元で再現する一番簡単な方法は、無関係な長文の中に「守ってほしい1つの条件」を埋め込んで、その位置を変えて同じ質問を投げることです。

再現させる入力例(中盤に条件を埋めて失敗させる)

次のように、長い前提テキストのちょうど中盤に重要条件を1行だけ置きます。

（前略：1000〜2000トークン分のプロジェクト説明・過去議事録・無関係なコード）
...
なお、本プロジェクトでは日付はすべて YYYY/MM/DD 形式で出力すること。  ← 重要条件をここ（中盤）に置く
...
（後略：さらに1000〜2000トークン分の補足・FAQ・用語集）

質問: 来月の請求日のリマインダー文面を作って。

この形だと、AIは中盤の「YYYY/MM/DD形式」という条件を無視して、2026年7月10日 や 7/10 のような別形式で出力してくることがあります。条件そのものはコンテキストに「入っている」のに、位置が悪いために使われないのが厄介な点です。短い入力では起きにくく、前後の文章量を増やすほど再現しやすくなります。

末尾へ移したら直った、という対処

同じ条件を、質問の直前(末尾)へ移すだけで挙動が変わります。

（前略：1000〜2000トークン分のプロジェクト説明・過去議事録・無関係なコード）
...
（後略：さらに1000〜2000トークン分の補足・FAQ・用語集）

【厳守する制約】
- 日付はすべて YYYY/MM/DD 形式で出力すること  ← 重要条件を末尾（質問の直前）へ移動

質問: 来月の請求日のリマインダー文面を作って。

末尾に置き直すと、先ほど無視されていた YYYY/MM/DD 形式が守られやすくなります。これは「モデルを賢いものに変えた」のではなく、「同じ情報の位置を変えただけ」で直った例です。実務での対処は次の通りです。

つまり、回答が言うことを聞かないとき、原因が「指示の弱さ」ではなく「指示の位置」であることは珍しくありません。長いコンテキストでは特に、まず位置を疑うと早く切り分けられます。

RAGとの関係

RAGは、外部の文書やデータベースから関連情報を検索し、その結果をコンテキストとしてAIに渡す仕組みです。
社内FAQ、規程検索、仕様書検索、問い合わせ対応AIなどでよく使われます。

RAGの流れは、ざっくり言うとこうです。

RAGは、AIにすべてを覚えさせる仕組みではありません。
回答のたびに必要そうな情報を探して、コンテキストへ差し込む仕組みです。

そのため、RAGで重要なのは「検索の質」と「渡す情報の質」、そして見落とされがちな「渡してよい相手かどうか」です。
検索結果がズレていれば、AIはズレたコンテキストをもとに自然な誤回答を出します。さらに、権限外の文書を渡してしまうと、もっと深刻なセキュリティ事故になります。

RAGで権限外文書が混入する具体ケース

RAGの事故で見落とされやすいのが、「本来その人に見せてはいけない文書が、検索で引っかかって回答に出てしまう」ケースです。なぜ起きるのか、具体的に追います。

根本原因はシンプルです。文書をベクトルに変換して文書ストアへ入れた時点で、元のファイルが持っていたアクセス権限の情報が一緒に保存されないことが多いからです。元の共有ドライブでは「役員のみ」だった文書も、ベクトル化された後はただの数値の塊になり、「誰が見てよいか」という属性が失われます。検索は意味の近さだけで文書を拾うため、質問者の権限を確認しないまま抜粋を返してしまいます。

典型的な混入の例を挙げます。

具体的なシナリオで考えてみます。給与レンジが書かれた人事資料が、他の社内規程と一緒に同じ文書ストアへ取り込まれているとします。新人が次のように聞いたとします。

評価制度について教えて。等級ごとの基準も知りたい。

検索は「等級」「評価」という意味に近い文書を探します。このとき、役員限定の「等級別給与レンジ表」が意味的にヒットしてしまうと、その抜粋がコンテキストへ差し込まれ、AIは何の疑いもなく給与額を含めて回答してしまいます。AIは「この新人にこの数字を見せてよいか」を判断しません。判断するのは検索する側の責任です。

この事故を防ぐ基本は、検索前に権限で絞り込むこと(プリ・リトリーバル認可)です。

実装上のポイントは、ベクトル検索の段階で文書のメタデータ(部署、役職、テナントID、公開範囲など)を一緒に持たせ、検索クエリに必ず権限フィルタを付けることです。「とりあえず全文書を入れて、後でAIに気を付けさせる」という設計は破綻します。AIに権限判断を任せてはいけません。実際に、メール経由で隠し指示を仕込みエンタープライズRAGから機密を引き出させる手口(EchoLeakとして報告された事例)のように、AI側の振る舞いに頼った防御は突破され得ます。

クライアント情報や社内情報の扱いの考え方は、生成AIにクライアント情報を入力してよい？契約・機密情報・ログ管理でも整理しています。

実務で困りやすいコンテキスト不足

AIの回答が微妙なとき、モデル性能やプロンプトの書き方だけが原因とは限りません。
単純にコンテキストが足りないことも多いです。

たとえば、次のような依頼です。

このエラーを直して

これだけだと、AIは何の環境で、何をしたら、どのエラーが出たのか分かりません。
改善するなら、次のように材料を渡します。

Laravel 12 / PHP 8.4 / MySQL 8.4 の環境です。
ログイン後に /admin へリダイレクトしたいのですが、次のエラーが出ます。

エラーメッセージ:
...

関連ファイル:
- routes/web.php
- app/Http/Controllers/Auth/AuthenticatedSessionController.php

期待する状態:
一般ユーザーは /dashboard、管理者は /admin に飛ばしたいです。

このように、環境、エラー、関連ファイル、期待結果が入ると、AIはかなり判断しやすくなります。
これは文章を長くする話ではなく、判断に必要な材料をそろえる話です。

コンテキスト過多でも失敗する

反対に、何でも渡しすぎても失敗します。
長い資料、古い議事録、関係ないログ、別プロジェクトのコードまで入れると、AIは重要な情報を見落としたり、古い前提に引っ張られたりします。前章のロストインミドルは、まさにこの「過多」の典型的な失敗です。

よくある失敗は次の通りです。

• リポジトリ全体を雑に渡して、関係ない実装を参照する
• 古い仕様書と新しい仕様書を一緒に渡して、古い仕様で回答する
• 会話が長くなりすぎて、最初の条件に引っ張られる
• 添付資料に機密情報を入れすぎる
• RAGで関連度の低い文書を混ぜる

コンテキストは、多ければ多いほど賢くなる栄養ではありません。
必要な情報を、今の目的に合わせて選んだ状態が良いコンテキストです。

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

コンテキストエンジニアリングは、AIに渡す情報の範囲、順序、粒度を設計する考え方です。
プロンプトエンジニアリングが「どう指示するか」に寄るのに対し、コンテキストエンジニアリングは「何を材料として渡すか」に寄ります。

実務では、次のような設計がコンテキストエンジニアリングになります。

• 必要なファイルだけを選ぶ
• 古い情報を除外する
• 検索結果に更新日や権限を付ける
• 長い文書を要約してから渡す
• 重要な制約は中盤に埋めず、先頭か末尾に置く
• システムメッセージ、会話履歴、添付資料の優先順位を決める
• AIエージェントに渡すツール結果を短く整える

AIエージェントでは、コンテキストはさらに重要です。
エージェントは、ファイル検索、コマンド実行、API呼び出しなどを行うため、途中結果もコンテキストになります。古いエラーや失敗したコマンドが残っていると、次の判断に影響します。

AIコーディングツールに毎回読ませる前提情報をどう置くかは、AIコーディングで使うmdファイルとは？AGENTS.md・CLAUDE.md・指示書の役割を整理 で具体的に整理しています。AGENTS.mdやCLAUDE.mdは、コンテキストを安定させるための実務的な置き場として考えると分かりやすいです。

機密情報とコンテキスト

コンテキストは、AIに渡す情報そのものです。
そのため、機密情報や個人情報を含める場合は注意が必要です。

たとえば、次のような情報をそのままコンテキストへ入れるのは危険です。

• 顧客名や個人情報
• 契約条件や見積金額
• 本番ログ
• APIキーや秘密鍵
• 未公開ソースコード
• 脆弱性診断結果
• 社内限定の設計資料

「AIに質問しているだけ」と見えても、実際には外部サービスへ情報を渡している場合があります。前章のRAG権限混入のように、自分が入れたつもりのない情報まで回答に出ることもあります。
実務では、必要な論点だけを抽象化する、固有名詞を伏せる、承認済みのAI環境を使う、ログ管理方針を決める、といった対策が必要です。

良いコンテキストの作り方

最後に、AIへ何かを頼むときの実務的なチェックリストです。

うまくいかないときは、「もっと賢いモデルを使う」前に、コンテキストを見直す価値があります。 必要な情報が足りないのか、余計な情報が多いのか、古い前提が残っているのか、重要な条件が中盤に埋もれていないかを切り分けると、かなり改善しやすいです。

AIのコンテキストに関するよくある質問

Q. コンテキストウィンドウとは何ですか？

A. AIが一度に処理できる、入力と出力を合わせたトークン数の上限のことです。近年のモデルは数十万から100万トークン規模まで扱えるものが増えていますが、上限まで詰め込めば賢くなるわけではありません。

Q. コンテキストが長いほど良いですか？

A. いいえ。長くなるほど、中盤の情報を見落とすロストインミドルが起きやすくなります。重要情報は先頭か末尾に置く、不要な情報は削る、構造化する、といった工夫が必要です。

Q. 指示を書いているのに無視されます。原因は？

A. 文言が弱いとは限りません。長文の中盤にその指示が埋まっていると、位置のせいで使われないことがあります。まず指示が「どこに書いてあるか」を確認し、質問の直前(末尾)へ移すと直ることがあります。

Q. RAGで他人の文書が出てきました。なぜですか？

A. 文書をベクトル化した時点で元のアクセス権限が一緒に保存されず、検索が意味の近さだけで文書を拾うためです。検索の前に質問者の権限でフィルタする(プリ・リトリーバル認可)のが基本的な対策です。

Q. RAGと長いコンテキスト、どちらを使うべきですか？

A. データが固定で量が多いならRAG(必要な部分だけ検索して渡す)、毎回データが変わる短い文書なら長コンテキストが向きます。両者を組み合わせるハイブリッド構成も増えています。

Q. プロンプトとコンテキストは違うものですか？

A. プロンプトは今回の指示文、コンテキストはその指示を実行するためにAIへ渡す前提情報全体(過去の会話、参照データ、ツール定義、メタ情報など)を含みます。プロンプトはコンテキストの一部です。

Q. メモリ機能とコンテキストは違いますか？

A. メモリは会話を超えて保持される情報、コンテキストはその時点の入力全体です。メモリの内容は毎回コンテキストに自動挿入されるため、メモリが多すぎると毎回コストが増えます。

Q. コンテキストを節約するコツは？

A. 関連性の低い履歴を削除する、要約に置き換える、必要な部分だけ取得する、フォーマット記号を最小化する、コードなら不要なコメントを削る、などです。長コンテキストは料金とレイテンシに直結するため、設計の腕の見せどころです。

まとめ

AIが言うコンテキストとは、モデルが回答や判断に使う前提情報のまとまりです。
プロンプトだけでなく、会話履歴、システムメッセージ、添付ファイル、検索結果、RAGで取得した文書、ツール実行結果まで含まれます。

コンテキストウィンドウが大きいモデルは便利ですが、何でも入れればよいわけではありません。
不要な情報、古い情報、機密情報が混ざると精度や安全性が下がり、重要条件が中盤に埋もれれば無視され、権限外文書が混ざれば情報漏えいにつながります。

AIをうまく使うコツは、きれいな言い回しを探すことだけではありません。
AIが判断できる材料を、必要な分だけ、正しい順番で、見てよい範囲だけ渡すことです。これが分かると、プロンプト、RAG、コンテキストウィンドウ、コンテキストエンジニアリングの関係がかなり見えやすくなります。

参考リンク

• Anthropic Docs: Context windows
• Google Cloud: Generative AI glossary
• 論文: Lost in the Middle: How Language Models Use Long Contexts
• Pinecone: RAG with Access Control