先に要点
- AIが言うコンテキストは、モデルが回答や判断に使う「その場で渡された前提情報」のことです。
- プロンプト本文だけでなく、会話履歴、システムメッセージ、添付ファイル、検索結果、ツール実行結果、RAGで取得した文書もコンテキストに含まれます。
- コンテキストウィンドウは、AIが一度に参照できる情報量の上限です。長ければ万能ではなく、不要な情報が多いとむしろ判断がぶれます。
- 実務では「何を入れるか」だけでなく、「何を入れないか」「どの順番で渡すか」「古い情報をどう捨てるか」が重要です。
AIツールを使っていると、よく「コンテキストが足りない」「コンテキストを渡す」「コンテキストウィンドウが大きい」といった言い方が出てきます。
何となく「前後関係」や「文脈」だとは分かっても、プロンプトと何が違うのか、会話履歴はどこまで覚えているのか、RAGとはどう関係するのかで混乱しやすい言葉です。
AI文脈のコンテキストは、ざっくり言えば、AIがその回答を作るために参照できる材料です。
この記事では、2026年4月19日時点で、AnthropicのContext windowsドキュメントとGoogle Cloudの生成AI用語集を確認しながら、AIが言うコンテキストを初心者向けに整理します。
AIのコンテキストとは
AIのコンテキストとは、LLMが次の出力を作るときに参照できる情報のまとまりです。
利用者が入力した質問だけでなく、会話履歴、システム側の指示、添付ファイル、検索で取ってきた文書、ツールの実行結果などが含まれます。
たとえば、次のような会話を考えます。
ユーザー: Laravelでログイン機能を作っています。
AI: どの認証方式を使っていますか？
ユーザー: Breezeです。ログイン後に管理画面へ飛ばしたいです。
最後の「管理画面へ飛ばしたいです」だけを見ると、何の話か分かりません。
でもAIは前の会話もコンテキストとして参照できるため、「Laravel」「Breeze」「ログイン後のリダイレクト」という前提を使って回答できます。
つまり、コンテキストは AIが今の発言を理解するための前提 です。
コンテキストに含まれるもの
AIに渡されるコンテキストは、チャット画面に見えている文章だけとは限りません。
サービスや実装によって違いますが、実務では次のようなものがコンテキストになります。
| 種類 | 例 | 注意点 |
|---|---|---|
| プロンプト | 利用者が入力した質問や指示 | 目的、制約、出力形式が曖昧だと回答もぶれやすい |
| 会話履歴 | 同じスレッド内の過去のやり取り | 古い前提が残ると、今の目的と混ざることがある |
| システムメッセージ | AIの役割、禁止事項、応答方針 | 利用者から見えない場合もある |
| 添付ファイル | PDF、仕様書、ログ、画像、CSV、ソースコード | 機密情報や古い資料を混ぜると危険 |
| 検索結果 | Web検索、社内文書検索、ナレッジベースの抜粋 | 根拠の新しさ、信頼性、権限を確認する必要がある |
| ツール実行結果 | コマンド結果、DB検索結果、APIレスポンス | 失敗結果や途中結果も判断材料になる |
ここで大事なのは、コンテキストは「AIが知っていること」そのものではないという点です。
モデルが事前学習で知っている一般知識と、いま渡されたコンテキストは分けて考えます。
プロンプトとの違い
プロンプトは、利用者がAIに渡す指示や質問です。
コンテキストは、それを含むもっと広い材料です。
| 言葉 | ざっくりした意味 | 例 |
|---|---|---|
| プロンプト | AIへの指示 | 「このエラーの原因を教えて」 |
| コンテキスト | AIが判断に使う前提情報全体 | エラーログ、コード、OS、直前の会話、実行したコマンド結果 |
| コンテキストウィンドウ | 一度に扱える情報量の上限 | モデルが参照できるトークン数の枠 |
たとえば、プロンプトが「原因を調べて」だけでも、直前にエラーログ、設定ファイル、実行環境が渡されていれば、AIはそれをコンテキストとして使えます。
逆に、プロンプトが丁寧でも、必要なログやコードがなければ、AIは推測で答えやすくなります。
ここが、プロンプトエンジニアリングだけでは足りない理由です。
良い指示を書くことも大事ですが、正しい材料を渡すことも同じくらい重要です。
コンテキストウィンドウとは
コンテキストウィンドウは、AIが一度に参照できる情報量の上限です。
Google Cloudの生成AI用語集でも、コンテキストウィンドウはモデルが与えられたプロンプトで処理できるトークン数として説明されています。
たとえば、長い仕様書や複数ファイルのコードを読み込ませたいとき、コンテキストウィンドウが小さいと全部を一度に渡せません。
一方で、大きいコンテキストウィンドウなら、大量の資料をまとめて渡せる可能性があります。
ただし、長ければ長いほど良いわけではありません。
- 不要な情報が多いと、重要な条件が埋もれる
- 古い仕様と新しい仕様が混ざると、判断がぶれる
- 入力トークンが増えると、APIコストや処理時間が増える
- 機密情報を余計に渡すリスクが増える
- モデルが長文の中の小さな条件を見落とすことがある
AnthropicのContext windowsドキュメントでも、コンテキストには入力、出力、ツール利用、思考関連の要素が含まれ、モデルごとに扱える上限があることが説明されています。
実務では「大きいから全部入れる」ではなく、「必要な情報を選んで入れる」と考える方が安定します。
RAGとの関係
RAGは、外部の文書やデータベースから関連情報を検索し、その結果をコンテキストとしてAIに渡す仕組みです。
社内FAQ、規程検索、仕様書検索、問い合わせ対応AIなどでよく使われます。
RAGの流れは、ざっくり言うとこうです。
- 利用者が質問する
- 質問に近い文書を検索する
- 関連する文書の一部を取り出す
- 取り出した文書をコンテキストとしてAIに渡す
- AIがその情報をもとに回答する
RAGは、AIにすべてを覚えさせる仕組みではありません。
回答のたびに必要そうな情報を探して、コンテキストへ差し込む仕組みです。
そのため、RAGで重要なのは「検索の質」と「渡す情報の質」です。
検索結果がズレていれば、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に渡す情報そのものです。
そのため、機密情報や個人情報を含める場合は注意が必要です。
たとえば、次のような情報をそのままコンテキストへ入れるのは危険です。
「AIに質問しているだけ」と見えても、実際には外部サービスへ情報を渡している場合があります。
クライアント情報や社内情報の扱いは、生成AIにクライアント情報を入力してよい？契約・機密情報・ログ管理でも整理しています。
実務では、必要な論点だけを抽象化する、固有名詞を伏せる、承認済みのAI環境を使う、ログ管理方針を決める、といった対策が必要です。
良いコンテキストの作り方
最後に、AIへ何かを頼むときの実務的なチェックリストです。
| 確認 | 見るポイント |
|---|---|
| 目的 | 何を判断してほしいのか、何を作ってほしいのかを明確にする |
| 前提 | 環境、対象読者、制約、利用技術を伝える |
| 材料 | ログ、コード、仕様、検索結果など、判断に必要なものだけ渡す |
| 除外 | 関係ない情報、古い情報、機密情報を混ぜない |
| 出力形式 | 箇条書き、表、手順、コード差分など期待する形を指定する |
| 根拠 | どの情報を根拠にしたか分かるようにさせる |
うまくいかないときは、「もっと賢いモデルを使う」前に、コンテキストを見直す価値があります。
必要な情報が足りないのか、余計な情報が多いのか、古い前提が残っているのかを切り分けると、かなり改善しやすいです。
まとめ
AIが言うコンテキストとは、モデルが回答や判断に使う前提情報のまとまりです。
プロンプトだけでなく、会話履歴、システムメッセージ、添付ファイル、検索結果、RAGで取得した文書、ツール実行結果まで含まれます。
コンテキストウィンドウが大きいモデルは便利ですが、何でも入れればよいわけではありません。
不要な情報、古い情報、機密情報が混ざると、回答の精度や安全性が下がります。
AIをうまく使うコツは、きれいな言い回しを探すことだけではありません。
AIが判断できる材料を、必要な分だけ、正しい順番で渡すことです。これが分かると、プロンプト、RAG、コンテキストウィンドウ、コンテキストエンジニアリングの関係がかなり見えやすくなります。