AIとの長い会話の途中で、最初のほうに伝えた内容を忘れられてしまった。大きなファイルを渡そうとしたら「上限を超えています」と断られた——生成AIを使い込むほど出会うこうした現象の背景にあるのが、コンテキストウィンドウ という仕組みです。
AIモデルの新製品発表では「100万トークンのコンテキストウィンドウ」のように性能指標として必ず登場し、料金や使い勝手にも直結する基本概念です。この記事では、AnthropicとGoogleの公式ドキュメントをもとに、コンテキストウィンドウとは何か、なぜ「大きいほど良い」とは限らないのか、上限とどう付き合うべきかを整理します。
コンテキストウィンドウとは何か
Anthropicの公式ドキュメントは、コンテキストウィンドウを「言語モデルが応答を生成する際に参照できるすべてのテキスト。生成する応答自体も含む（all the text a language model can reference when generating a response, including the response itself）」と定義しています1。
重要なのは、これがモデルの学習に使われた膨大なデータとは別物だという点です。同ドキュメントは、コンテキストウィンドウは学習データと異なり「モデルにとっての『作業記憶（working memory）』にあたる」と説明しています1。Googleのドキュメントも、コンテキストウィンドウを「短期記憶」にたとえ、「生成モデルに渡される情報量には制限がある」としています3。
人間にたとえると、学習データは「これまでの人生で身につけた知識」、コンテキストウィンドウは「いま机の上に広げられる資料の量」です。机に載らない資料は、どれだけ重要でも参照できません。会話が続くと、過去のやり取りが机の上に積み上がっていきます。Anthropicのドキュメントが説明するとおり、「会話がターンを重ねるごとに、ユーザーの発言とアシスタントの応答がコンテキストウィンドウ内に蓄積していきます」1。長い会話で上限に達すると、何かを削らない限り新しい情報が入らなくなる——冒頭の「忘れられた」現象の正体はこれです。
トークンという単位：100万トークンでどれくらい？
コンテキストウィンドウの大きさは「トークン」という単位で測られます。トークンはAIがテキストを処理する際の最小単位で、おおまかには単語や文字のかたまりです。
実感をつかむには、Googleが示す目安が分かりやすいでしょう。同社のドキュメントによると、100万トークンに収まる情報量は「50,000行のコード（標準的な1行80文字）」「過去5年間に送信したすべてのテキストメッセージ」「平均的な英語の小説8冊分」「平均的な長さのポッドキャストエピソード200以上のトランスクリプト」に相当します3。
2026年6月時点で、主要なフラッグシップモデルのコンテキストウィンドウは100万トークン級に達しています。GoogleはGeminiについて100万トークン以上のコンテキストウィンドウを搭載するとし、かつては8,000トークンや128,000トークンが上限だったと説明しています3。Anthropicも、Claude Fable 5とClaude Mythos 5、およびClaude Opus 4.8・4.7・4.6とClaude Sonnet 4.6がClaude API上で100万トークンのコンテキストウィンドウを持つとしています（Claude Sonnet 4.5などそれ以前のモデルは20万トークン）1。なお、こうした数値はモデルの世代交代とともに変わるため、最新の値は各社のドキュメントで確認してください。
「大きいほど良い」とは限らない：context rotという現象
では、コンテキストウィンドウが大きいモデルを選び、資料を全部詰め込めばよいのでしょうか。実は、そう単純ではありません。
Anthropicのドキュメントは「コンテキストウィンドウが大きいほど複雑で長いプロンプトを扱えるが、コンテキストが多ければ自動的に良くなるわけではない」と明言しています。「トークン数が増えるにつれて精度と想起力は劣化する。これは context rot（コンテキストの劣化）として知られる現象」だからです1。同社のエンジニアリングブログはこの現象を「コンテキストウィンドウ内のトークン数が増えるほど、モデルがそのコンテキストから情報を正確に思い出す能力は低下する」と説明しています2。
なぜ劣化するのか。同ブログは「限られた作業記憶しか持たない人間と同じように、LLMも大量のコンテキストを読み解く際に使う『注意の予算（attention budget）』を持っている」と述べています2。机が大きくても、一度に注意を向けられる資料の量には限りがある、ということです。このためAnthropicは、「何をコンテキストに入れるかの厳選は、どれだけの容量があるかと同じくらい重要」だとしています1。
上限との付き合い方
実務では、コンテキストウィンドウの上限と品質劣化の両方を踏まえた工夫が使われています。
代表的なのは、関連する資料だけを検索して渡す RAG（検索拡張生成） です。全文書を詰め込む代わりに必要な部分だけをコンテキストに入れるこの手法は、上限の節約とcontext rot対策を兼ねています。仕組みはRAGの解説記事で詳しく説明しています。
もう一つは会話履歴の要約・圧縮です。Anthropicは長時間の会話に対して、「会話の前半部分を自動的に要約して圧縮し、コンテキスト上限を超えた長時間の会話を可能にする」サーバーサイドのコンパクション（compaction）機能を推奨しています1。また、Claude Sonnet 4.6などの一部モデルは、会話全体を通して残りのコンテキスト容量（トークン予算）を自分で把握する「context awareness」という能力を備えており、長時間のタスクで残り容量を踏まえた動作ができるとされています1。
こうした管理が特に重要になるのが、ツールを使いながら長時間動き続けるAIエージェントです。エージェントは作業のたびにツールの実行結果がコンテキストに積み上がるため、コンテキスト管理の巧拙が性能を左右します。エージェントの基本概念はAIエージェントの解説記事で整理していますので、あわせてどうぞ。
Sources
- Context windows - Anthropic公式ドキュメント
- Effective context engineering for AI agents - Anthropic公式エンジニアリングブログ（2025年9月29日公開）
- ロングコンテキスト - Google公式ドキュメント（Gemini API）