コンテキストウィンドウ

この用語の意味

コンテキストウィンドウは、LLMが一回のリクエストで扱えるトークン範囲を指す。ユーザー入力、システム指示、会話履歴、参照文書、ツール結果、モデル出力がこの範囲を消費する。大きなウィンドウは長文資料や複数文書を扱いやすくするが、すべてを詰め込めばよいわけではない。重要度の低い情報が増えると、モデルが必要な根拠を見落としたり、コストと遅延が増えたりする。実務では、要約、チャンク化、検索、優先順位付け、履歴圧縮を組み合わせる。 大きいほど多くの情報を入れられるが、関連性の低い情報を詰め込むと重要な根拠が埋もれ、費用、速度、回答品質が悪化することもある。

計算の考え方

コンテキスト利用は、必要トークン、余裕、取得品質で見る。 利用率 | 使用トークン / 上限トークン | 上限に近いほど切り捨てやコストに注意する 根拠密度 | 有用な参照トークン / 参照トークン全体 | ノイズの多さを見る 圧縮効果 | 圧縮前トークン - 圧縮後トークン | 会話履歴や資料要約の効果を見る

含めるもの / 含めないもの

コンテキストウィンドウは記憶や知識ベースではなく、一回の処理で参照する作業領域である。 含める | 指示、会話履歴、参照文書、検索結果、ツール出力、生成中の出力 | 一回のリクエストで扱う情報 含めない | 恒久的な記憶、DB全体、アクセス権限、出典の保証 | 別の仕組みが必要 明示する | 何を優先して入れるか、何を要約するか、何を検索するか | 品質とコストを決める

何が数字を動かすか

成果はウィンドウの大きさだけでなく、入れる情報の選別と構造化で決まる。 優先順位 | 目的に近い根拠を先に入れると精度が上がりやすい チャンク化 | 長文を意味単位で分けると検索と引用が安定する 履歴圧縮 | 長い会話では要点を残してノイズを減らす コスト | 大きな入力は遅延と費用を増やす場合がある

こんな場面で役立つ

長い資料をそのまま入れるか、RAGで必要部分だけ渡すかを判断できる。 判断時は、入れる情報量ではなく、目的に必要な根拠をどの順番で入れるかを重視する。 会話履歴を保持するプロダクトで、いつ要約や圧縮を行うべきか決められる。 判断時は、入れる情報量ではなく、目的に必要な根拠をどの順番で入れるかを重視する。 コンテキスト不足による誤答と、コンテキスト過多によるノイズを分けて改善できる。 判断時は、入れる情報量ではなく、目的に必要な根拠をどの順番で入れるかを重視する。

• 長い資料をそのまま入れるか、RAGで必要部分だけ渡すかを判断できる。 判断時は、入れる情報量ではなく、目的に必要な根拠をどの順番で入れるかを重視する。
• 会話履歴を保持するプロダクトで、いつ要約や圧縮を行うべきか決められる。 判断時は、入れる情報量ではなく、目的に必要な根拠をどの順番で入れるかを重視する。
• コンテキスト不足による誤答と、コンテキスト過多によるノイズを分けて改善できる。 判断時は、入れる情報量ではなく、目的に必要な根拠をどの順番で入れるかを重視する。

実務での使い方

• コンテキストウィンドウは、モデルが一度に参照できる作業領域である。
• 長いウィンドウは便利だが、根拠選別と構造化が必要である。 コンテキストウィンドウは容量ではなく、根拠選別と順序設計の制約として見る。
• 会話履歴、参照文書、ツール結果、出力が同じ上限を消費する。 コンテキストウィンドウは容量ではなく、根拠選別と順序設計の制約として見る。
• RAG、要約、チャンク化、履歴圧縮で効率よく使う。 コンテキストウィンドウは容量ではなく、根拠選別と順序設計の制約として見る。
• 上限が大きくても、すべての情報を入れる設計は避ける。 コンテキストウィンドウは容量ではなく、根拠選別と順序設計の制約として見る。

判断するときの注意点

コンテキストを増やせば常に精度が上がるとは限らない。 根拠に関係ない資料を大量に入れると、重要情報が埋もれることがある。 長い会話では、古い条件と新しい条件が矛盾しないように整理する。 コンテキスト内に機密情報を入れる場合は、ログと保持条件を確認する。

• 根拠に関係ない資料を大量に入れると、重要情報が埋もれることがある。
• 長い会話では、古い条件と新しい条件が矛盾しないように整理する。
• コンテキスト内に機密情報を入れる場合は、ログと保持条件を確認する。

一緒に見る指標

コンテキストウィンドウは、RAG、プロンプト、LLMと一緒に理解する。 RAG | 必要な文書だけを検索して入れる | コンテキストの効率を上げる プロンプトエンジニアリング | 入力構造を設計する | 限られた枠を有効に使う 大規模言語モデル | コンテキストを処理する本体 | モデルごとに上限が異なる

具体例

社内規程100ページをAIに読ませて質問応答を作る。最初は全文を入れたが、回答が遅く、古い条文と新しい条文を混同した。チームは規程を章ごとにチャンク化し、質問に関連する数チャンクだけをRAGで取得する設計へ変えた。会話履歴は毎回全文を送らず、意思決定に必要な前提だけを要約して残す。これにより、入力トークンは減り、根拠箇所も示しやすくなった。大きなコンテキストより、必要な情報を選ぶ設計が重要だと分かった。 さらに、検索結果をそのまま全件入れるのではなく、定義、制約、最新変更、例外の順に短く圧縮した。関連性の低い過去ログは別ツールで参照できるように分けたため、入力量を減らしながら回答の根拠と速度を安定させられた。

似ている言葉との違い

コンテキストウィンドウ | 一度に扱える作業領域 | 入力と出力の範囲を決める メモリ | 長期的に保持する情報 | セッションや製品設計に依存する RAG | 外部情報を必要時に取得する | ウィンドウへ入れる情報を選ぶ

よくある勘違い

• 長ければ必ず良い、という誤解がある。ノイズが増えると品質が下がることがある。
• コンテキストウィンドウは記憶と同じ、という誤解がある。一回の処理範囲であり恒久保存ではない。
• 資料を全部入れれば引用も正確、という誤解がある。引用箇所の設計と検証が必要である。

よくある質問

参考・出典

関連トピック