コンテキストウィンドウとは、LLM（大規模言語モデル）が一度の処理で扱える情報量の上限です。 モデルに渡す指示、会話の履歴、読み込ませた文書、そしてモデルの出力まで、すべてがこの枠の中に収まっている必要があります。 「なぜ長い文書を丸ごと読ませられないのか」「なぜ長く使っているとAIが前の話を忘れるのか」という疑問への答えが、この仕組みにあります。
コンテキストウィンドウとは何か
LLMは、文章をトークンという単位に区切って処理します。 トークンは単語より少し細かい部品で、英語ならおよそ0.75単語が1トークンにあたる目安です（日本語の換算率はモデルのトークナイザーによって変わります）。 コンテキストウィンドウは、このトークンを一度に何個まで載せられるかという上限で、モデルごとに決まっています。
比喩でいえば、モデルの作業机の広さです。 机に載っている資料は参照できますが、載りきらない資料は、その回答を作る時点では存在しないのと同じです。 机に載るのは、「いま読ませた文書」だけではありません。 システムへの指示文、それまでの会話履歴、AIエージェントならツールの定義や実行結果まで、すべてが同じ机を奪い合います。 長い会話の序盤の内容をAIが「忘れる」のは、多くのチャットアプリが、あふれた古い履歴を要約するか切り捨てる作りになっているためです（実装によっては、上限超過はそのままエラーになります）。
なお、コンテキストウィンドウは学習データとは別物です。 モデルが学習で得た知識は机の外にある本棚のようなもので、ウィンドウを消費しません。 ウィンドウを消費するのは、その場で渡した情報だけです。
主要モデルの現在地
コンテキストウィンドウはこの数年で急拡大しました。 2023年頃は4千〜3万2千トークン級のモデルが中心でしたが、2026年7月時点では、Anthropic（Claude）、OpenAI（GPT）、Google（Gemini）の主力モデルがいずれも100万トークン級に到達しています。 100万トークンは英語で約75万語、標準的な長編小説にして8冊前後に相当し、大きめのコードベースや大量の契約書をまとめて渡せる規模です。
ただし、注意点が2つあります。
1つは、出力には別の上限があることです。 入力と出力の合計がウィンドウに収まる必要があるうえ、一度に書ける量自体も数万〜十数万トークン程度に制限されています。 「大量に読んで、要点を書く」用途には十分ですが、「大量に書かせる」処理は分割が前提になります。
もう1つは、公称の上限と実際に使える精度が別物だということです。 複数の研究で、入力が長くなると精度が下がる傾向が確認されています（程度はモデルと課題によって異なります）。 2025年に公開されたChromaの調査では、18の主要モデルを対象にした実験で、入力長の増加に伴う性能の劣化が観測されました。 背景の説明としては、モデルが注意を向けられる量は有限で、情報を詰め込むほど1つあたりの注意が薄まるという「注意の予算」の考え方が知られています。 「入る」ことと「正確に使いこなせる」ことは同じではない、というのが実務上の要点です。
実務での影響と付き合い方
コンテキストウィンドウは、AI活用の設計とコストに直接響きます。
- コストは入力量に応じて増える：LLMのAPI料金はトークン数に課金されるため、毎回大量の文書を丸ごと渡す設計は、高コストで応答も遅い設計になりがちです。ウィンドウに「入るから入れる」はコスト面でも悪手です
- 社内文書の扱いは「全部渡す」か「検索して渡すか」：文書量がウィンドウに収まり、かつ毎回全体を参照すべきなら丸ごと渡すのが単純です。文書が大量にある、または必要な箇所が毎回違うなら、関連部分だけを検索して渡すRAG（検索拡張生成）が定石です。ウィンドウの拡大でRAGが不要になるという見方もありましたが、精度とコストの両面から、用途に応じて使い分けるのが現実的です
- エージェントの長時間作業には管理が要る：AIエージェントは作業のたびにツールの実行結果が履歴に積み上がるため、長い作業ほどウィンドウを圧迫します。上限をまたぐ長時間の作業では、履歴を要約して枠を空けるコンパクションや、作業を別のエージェントに分けるサブエージェント構成など、ウィンドウを資源として管理する技法が前提になります
- 重要な情報は置き場所で効きが変わる：長い入力では、途中に埋もれた情報より、冒頭と末尾に置いた情報の方が反映されやすい傾向が報告されています。程度はモデルによりますが、指示や重要な前提は冒頭か末尾に置くのが無難です
「広くなった机」をどう使うか
コンテキストウィンドウの拡大は、AI活用の幅を確実に広げました。 以前なら分割やRAG基盤の構築が必要だった文書量でも、条件がそろえば全文を渡して試せるため、PoCの立ち上がりは軽くなっています。
一方で、上限の拡大は「何も考えずに詰め込んでよい」を意味しません。 精度は入力が長いほど落ち、コストは入力に比例して増えるため、成果を分けるのは「何を入れて、何を入れないか」の設計です。 この設計を体系化した技法はコンテキストエンジニアリングと呼ばれ、エージェント時代の中心的なスキルになりつつあります。 コンテキストウィンドウは上限の数字として覚えるより、管理すべき有限資源として捉えることが、実務での正しい出発点です。
関連して読める記事
コンテキストウィンドウは、コンテキストエンジニアリングやマルチエージェントの前提になる概念です。AI駆動開発の全体像とあわせて押さえると、AIに何をどう渡すかの設計が理解しやすくなります。
AI駆動開発（AIDD）とは？従来の開発との違いと導入の考え方
AI駆動開発（AIDD）とは、生成AIを開発工程の主役に置き、人間が方針決定と検証を担う開発スタイルです。コード補完との違い、開発工程がどう変わるか、導入の順序と注意点を解説します。
2026年7月25日
コンテキストエンジニアリングとは？プロンプトエンジニアリングとの違いと代表的な技法
コンテキストエンジニアリングとは、LLMに見せる情報全体を設計・管理する技術です。プロンプトエンジニアリングとの違い、コンパクションやサブエージェント分割など代表的な4つの技法を解説します。
2026年7月27日
マルチエージェントとは？サブエージェント構成の仕組みと使いどころ
マルチエージェントとは、1つの目標に対して複数のAIエージェントを役割分担で協調させる構成です。サブエージェントによるコンテキスト分離の仕組み、代表的な協調の型、コストと運用の注意点を解説します。
2026年7月27日