コンテキストウィンドウ（Context Window）¶
📁 docs/it-learning/artifact/20260309_1030_コンテキストウィンドウ.md
1. コンテキストウィンドウとは¶
コンテキストウィンドウとは、LLM（大規模言語モデル）が1回の処理で「見ることができる」テキストの最大量のこと。
- 単位は トークン（文字数ではなく意味のまとまり）
- ウィンドウの外に出た情報はAIから「見えなくなる」
- 人間でいえば「一度に頭に入れられる情報量の上限」に相当する
2. トークンとは¶
トークンとは、LLMがテキストを処理する際の最小単位。文字でも単語でもなく、その中間くらいのまとまり。
| テキスト例 | おおよそのトークン数 |
|---|---|
| 英単語1つ（"hello"） | 約1トークン |
| 日本語1文字 | 約1〜2トークン |
| 日本語の文章400字 | 約200〜400トークン |
| 英語の文章1,000語 | 約750トークン |
| 原稿用紙1枚（400字） | 約300〜500トークン |
目安: 日本語テキストでは「文字数 ÷ 1〜2」くらいがトークン数の概算。
なぜ「トークン」という単位なのか¶
LLMは文章を「Byte Pair Encoding（BPE）」などの手法で細かく分割して処理する。 例えば "unhappiness" → ["un", "happi", "ness"] のように分割される。 日本語でも「東京都」→「東京」「都」のように分割されることがある。
3. コンテキストウィンドウが重要な理由¶
制約として働く場面¶
- 長い会話: やりとりが増えるほどトークンを消費する。上限を超えると古い会話が「忘れられる」
- 大きなファイルの処理: ソースコード・長い文書を丸ごと渡せないことがある
- 複数ドキュメントの参照: 複数の資料を同時に参照したい場合に収まりきらないことがある
- エージェントの動作: ツールの実行ログや中間結果が積み重なり、コンテキストを圧迫する
具体的な問題¶
4. 主要モデルのコンテキストウィンドウ比較（2025年時点）¶
| モデル | コンテキストウィンドウ | 特記事項 |
|---|---|---|
| GPT-4o | 128,000トークン | OpenAI、マルチモーダル対応 |
| GPT-4 Turbo | 128,000トークン | OpenAI |
| Claude 3.5 Sonnet | 200,000トークン | Anthropic、現時点で最大級のひとつ |
| Claude 3 Opus | 200,000トークン | Anthropic |
| Gemini 1.5 Pro | 1,000,000トークン | Google、実験的機能では200万トークンも |
| Gemini 1.5 Flash | 1,000,000トークン | Google、高速・低コスト版 |
| Llama 3 (Meta) | 8,000〜128,000トークン | オープンソース、バリアントによって異なる |
| Mistral Large | 32,000トークン | Mistral AI |
参考: 200,000トークン ≒ 日本語で約10〜20万文字 ≒ 文庫本2〜4冊分
5. コンテキストウィンドウが大きいことのメリット・デメリット¶
メリット¶
- 長い文書をそのまま渡せる: 長い契約書、大きなソースコードファイルを一括処理できる
- 長い会話を維持できる: 複数ターンのやりとりでも文脈を失わない
- 複数資料を同時参照: 多くのドキュメントを一度に与えて横断的な分析ができる
- エージェント処理が安定: ツール呼び出しの履歴が多くなっても文脈が保たれる
デメリット¶
- コストが高くなる: 課金はトークン数に比例するため、長いコンテキストは費用がかさむ
- 処理速度が遅くなる: コンテキストが長いほど推論に時間がかかる
- "Lost in the Middle" 問題: コンテキストが長すぎると、中間部分の情報を見落としやすくなる傾向がある（重要な情報は先頭か末尾に置くとよい）
- 必ずしも精度が上がるわけではない: 関係のない情報が多すぎると回答の質が下がることもある
6. 実務での対処法¶
コンテキスト不足への対応¶
要約（Summarization）¶
- 古い会話を都度要約し、コンテキストを圧縮して継続する手法 - Claude Codeなどのエージェントツールでも採用されているRAG（Retrieval-Augmented Generation）¶
- ドキュメント全体をコンテキストに入れる代わりに、関連箇所だけを動的に抽出する手法 - 大規模なナレッジベースを扱う際の定番アプローチチャンク分割（Chunking）¶
- 長いソースコードや文書を分割して処理する手法 - 分割点の設計（意味的な境界で切る）が品質に影響するスライディングウィンドウ（Sliding Window）¶
- ウィンドウをずらしながら処理し、前後の文脈をある程度保持する手法 - 翻訳や校正など順序が重要なタスクに有効キャッシュ（Prompt Caching）¶
- AnthropicやOpenAIが提供する機能で、同じプロンプトプレフィックスを繰り返す場合にコストと速度を改善できる
- 大きなシステムプロンプトを毎回送信するコストを削減できる
7. コンテキストウィンドウの使われ方（構造）¶
実際のコンテキストウィンドウは以下のように構成される:
┌─────────────────────────────────────────┐
│ コンテキストウィンドウ全体 │
├─────────────────────────────────────────┤
│ システムプロンプト │
│ （AIの役割・指示・制約） │
├─────────────────────────────────────────┤
│ 参考資料・ドキュメント │
│ （RAGで取得した情報、コードファイル等） │
├─────────────────────────────────────────┤
│ 会話履歴 │
│ ユーザー: ○○してください │
│ AI: 了解です。〜 │
│ ユーザー: では次に〜 │
│ AI: 〜 │
├─────────────────────────────────────────┤
│ 現在の質問（最新のユーザー入力） │
└─────────────────────────────────────────┘
8. コンテキストウィンドウが「いっぱい」になったときの挙動¶
モデルやツールによって対応が異なる:
| 挙動 | 説明 | 採用例 |
|---|---|---|
| 古い会話を切り捨て | 先頭から削除してウィンドウを維持 | 多くのチャットUI |
| エラーを返す | 上限超過時にリクエスト自体を拒否 | API直接利用時 |
| 自動要約 | 古い部分を自動で要約して圧縮 | 一部のエージェントフレームワーク |
| ユーザーに警告 | 残りのトークン数を表示・警告 | Claude.ai等のUI |
9. 関連用語¶
| 用語 | 説明 |
|---|---|
| トークン（Token） | LLMがテキストを処理する最小単位 |
| プロンプト（Prompt） | LLMへの入力テキスト全体（指示・質問・文脈を含む） |
| システムプロンプト（System Prompt） | AIの振る舞いや役割を定義する特別なプロンプト |
| RAG（Retrieval-Augmented Generation） | 外部の知識ベースから関連情報を検索してコンテキストに注入する手法 |
| 埋め込み（Embedding） | テキストを数値ベクトルに変換したもの。RAGでの類似検索に使う |
| ベクトルDB（Vector Database） | Embeddingを格納・検索するためのデータベース。RAGの基盤 |
| Attention（注意機構） | Transformerの核心技術。コンテキスト内の各トークン間の関連度を計算する |
| KVキャッシュ（Key-Value Cache） | Attentionの中間計算結果をキャッシュする仕組み。コンテキストが長いほどメモリを消費 |
| インコンテキスト学習（In-Context Learning） | コンテキスト内に例示（Few-Shot）を含めてAIの振る舞いを誘導する手法 |
まとめ¶
コンテキストウィンドウ = LLMが一度に「見られる」テキストの上限
単位: トークン（文字数ではない）
規模: 数千〜100万トークン（モデルにより大幅に異なる）
上限を超えると:
→ 古い情報が「見えなくなる」
→ エラーになる
対処法:
要約 → 古い会話を圧縮して再利用
RAG → 必要な情報だけを動的に注入
チャンク分割 → 大きなデータを小さく分けて処理
大きいほど便利だが、コスト・速度・"Lost in the Middle"問題に注意
関連 issue: #88 コンテキストウィンドウ 作成日: 2026-03-09