コンテキストウィンドウ（Context Window）とは？LLMのトークン上限・主要モデル比較・活用例を徹底解説

Context Window（コンテキストウィンドウ）とは

Context Window（コンテキストウィンドウ）とは、大規模言語モデル（LLM）が一度の推論で参照できるトークン数の上限を指す言葉である。日本語では「文脈窓」「コンテキスト長」と呼ばれることも多い。たとえば Claude Sonnet 4.6 の 1M（100 万）トークンや GPT-5 の 256K トークンといった数値がこれに該当し、モデルがユーザーのプロンプト・会話履歴・システム指示・外部資料などをまとめて理解できる情報量の枠として機能する。

身近な例えで言うと、コンテキストウィンドウは「机の広さ」に相当する。机が広ければ書類・書籍・メモを同時に広げて参照しながら作業できるのと同じように、コンテキストウィンドウが大きいモデルは長大なソースコードや大量の議事録をまるごと読ませて一貫した回答を得られる。これが重要なポイントで、コンテキストウィンドウはモデルの性能そのものではなく「一度に見られる範囲」である点を理解すると、Claude・GPT・Gemini などの差分が読み取りやすくなる。近年の LLM 競争は性能と同じくらい、この机の広さを拡張する競争になっている。

Context Windowの読み方

コンテキストウィンドウ

コンテクストウィンドウ

コンテキスト長

Context Windowの仕組み

LLM はテキストを「トークン」と呼ぶ最小単位に分割し、そのトークン列をまとめて数値ベクトルに変換してから Transformer に通す。コンテキストウィンドウはこの「まとめて入力できるトークン数」の上限を示す値で、入力プロンプトと出力生成の合計がこの枠を超えると古い部分から切り捨てられる。モデルによっては入力専用枠と出力専用枠を分けて提示するものもある。

主要モデルのコンテキスト長比較（2026年4月時点）

モデル	入力コンテキスト	出力
Claude Sonnet 4.6	最大1,000,000 tokens	64K
Claude Opus 4.6	200K tokens	32K
GPT-5	256K tokens	128K
Gemini 2.5 Pro	2M tokens	64K
Llama 4 Maverick	10M tokens（理論値）	可変

トークンと文字数の関係

日本語の場合、ざっくり「1文字 ≒ 1〜1.5トークン」が目安です。覚えておきたいのは、英語は「4文字 ≒ 1トークン」が目安で、日本語より効率が良い点。同じ100万トークンでも、英語なら約75万語、日本語なら約65〜80万文字程度と覚えておくと見積もりしやすい。

ウィンドウあふれの仕組み

コンテキストウィンドウ溢れ時の挙動

新プロンプト追加

→

枠超過検出

→

古い履歴切り捨て

→

要約・圧縮・エラー

Position Embeddingとコンテキスト拡張

コンテキスト長を伸ばすには、モデルのアーキテクチャ側でいくつかの技術が必要になる。具体的には、Transformer 本来の絶対位置エンコーディングでは長文の一般化が難しいため、Rotary Position Embedding（RoPE）や ALiBi、YaRN といった位置表現手法が使われる。Claude・GPT・Gemini・Llama 各モデルはそれぞれ独自の拡張をしており、数十万〜数百万トークンという公称値は、これらの拡張技術と長文学習データの組み合わせで実現されています。

覚えておきたいのは、コンテキスト長は「モデルが処理できる物理的上限」と「学習時に見た最長長」の二重構造になっている点。仮にアーキテクチャが 2M トークンまで処理できても、学習時に 200K までしか見ていないと、実際の精度は 200K を超えたあたりから急激に落ちます。ベンダーが公称する数値は学習済みコンテキストの範囲を示すものと理解しておくと、性能の読み違いを防げます。

Needle in a Haystackテスト

長文コンテキストの性能を測る定番ベンチマークに「Needle in a Haystack」がある。長いダミー文章の中に特定の文（Needle）を埋め込み、そこに言及するよう指示して取り出せるかを測る。実務では、このテスト結果を見てモデル選定することが多く、Claude Sonnet 4.6 は 1M トークン級でも安定してこのテストを通過することが公表されている。注意しておきたいのは、このテスト通過率と実タスクの精度は必ずしも一致しない点で、ベンチマーク数値だけでなく自社データでの評価が必須です。

Context Windowの使い方・実例

API レベルでは、送信プロンプトのトークン数と出力トークン数を事前に見積もり、枠に収まるよう制御する必要がある。Anthropic SDK の例を示す。

# Python: Anthropic SDK でトークン数を事前計測
from anthropic import Anthropic

client = Anthropic()
tokens = client.messages.count_tokens(
    model="claude-sonnet-4-6",
    messages=[{"role": "user", "content": long_text}]
)
print("input tokens:", tokens.input_tokens)

長文コード解析の実例

100 万トークンの枠があれば、約 5 万行のソースコードをまとめて読ませて設計レビューを行うといった運用が可能になる。ここが重要なポイントです。コンテキストが大きいほど「検索で断片を渡す RAG」と「まるごと渡す long-context」の境界線がずれていく点に注意する必要がある。

# 長大なコードベースを一括でClaudeに渡す
with open("monorepo_dump.txt") as f:
    code = f.read()  # 50万トークン程度

msg = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=8000,
    messages=[{"role": "user", "content": f"以下のコードをレビューせよ:\n{code}"}]
)

コンテキスト圧縮・要約パターン

長文を効率的に扱うには、元のコンテキストを要約したり、重要度で絞り込んだりする「圧縮」が役立つ。Claude Code の /compact や Claude Desktop の Projects 機能は、会話履歴を自動で要約してコンテキスト枠を確保してくれる。実務では、対話型エージェントで 10 ターンごとに自動要約を挟む、といった設計パターンが定番です。

# Python: 会話履歴を要約してコンテキストに収めるパターン
def compact_history(messages, client, threshold_tokens=150000):
    tokens = client.messages.count_tokens(model="claude-sonnet-4-6", messages=messages)
    if tokens.input_tokens < threshold_tokens:
        return messages
    summary = client.messages.create(
        model="claude-haiku-4-5",
        max_tokens=2000,
        messages=messages + [{"role": "user", "content": "ここまでの会話を要約せよ"}]
    )
    return [{"role": "system", "content": summary.content[0].text}]

ここが重要なポイントです。大きなコンテキスト枠があるからといって何でも詰め込むのは、コスト・レイテンシ・精度いずれの観点からも得策ではありません。コンテキスト管理は「枠を広げる」のではなく「効率的に使う」視点で設計すると、費用対効果が劇的に改善します。

マルチモーダルとコンテキスト

最近の LLM は画像や音声もコンテキストに含められる。Claude Sonnet 4.6 や Gemini 2.5 は 100 枚単位の画像を一度のプロンプトに含めることが可能で、テキストとは別に「画像トークン換算」が行われる。覚えておきたいのは、画像は 1 枚あたり数百〜数千トークンを消費する点で、マルチモーダル利用時はテキスト専用時よりコスト見積もりが繊細になります。

Context Windowのメリット・デメリット

メリット

長大なドキュメントやコードを分割せずに一括処理できる
会話履歴を長く保てるため、プロジェクト単位の一貫性が保たれる
RAGのチャンク分割設計が不要になる場面が増える
エージェントが長期の自律実行を行ってもメモリが枯渇しにくい

デメリット

トークン単価が高くなるためコストが跳ね上がる
長文になるほどモデルが中盤の情報を見落とす「Lost in the Middle」現象が起きやすい
処理時間（レイテンシ）が伸びる
本当に必要な情報以外を大量に読ませると、かえって推論ノイズが増える

Context WindowとRAGの違い

観点	Context Window（長文入力）	RAG（検索拡張）
情報の渡し方	全量をプロンプトに含める	関連チャンクのみ検索して渡す
コスト	高（枠相当の料金）	低
精度	Lost in the Middle の影響	検索品質に依存
適する用途	単一ドキュメント精読・コードレビュー	社内ナレッジ検索・FAQ