コンテキストウィンドウとは？トークン上限の数え方と有効長・溢れ対策を実装者向けに解説

コンテキストウィンドウは、LLMが1回の推論で参照できるトークンの総量です。入力した文章だけを数える枠ではなく、システムプロンプト、ツール定義、会話履歴、そしてモデルが返す出力と思考のトークンまで、すべてが同じ枠を分け合います。この記事では、何がどう計上されるのかという内訳、2026年8月時点の主要モデルの公称値と出力上限、公称値どおりには使えない理由、KVキャッシュと入力課金という2つのコスト、そして窓に収まらない入力をRAG・要約圧縮・分割のどれで捌くかの判断基準までを、実装者の視点で整理します。

まとめ：コンテキストウィンドウの定義と設計判断の結論

コンテキストウィンドウとは、モデルが応答を生成するときに参照できるテキストの全量を指します。学習済みの知識とは別物で、リクエストごとに作り直される作業記憶に近いもの。Anthropicの公式ドキュメントは、システムプロンプト、messages配列のすべて（ツール結果・画像・文書を含む）、ツール定義、そして生成される出力と思考トークンのすべてが窓を消費すると明記しています。

2026年8月3日時点で、Claude Opus 5・Sonnet 5・Fable 5 とGPT-5.6系は100万トークン級に到達しました。ただし出力は別枠の上限があり、100万トークンの窓を持つClaudeモデルでも1リクエストのmax_tokensは12.8万トークンまでです。

設計上の結論を先に書きます。窓を広く取れるモデルを選ぶことと、窓を埋めることは別の判断です。RULERの評価では、32Kトークン以上を公称するモデルのうち32Kで満足な性能を保てたのは半数にとどまりました。窓は「入る量」であって「精度を保てる量」ではありません。実装では、入る限り詰め込むのではなく、投入するものを選び切る設計に振ってください。

コンテキストウィンドウが数える対象｜入力・出力・思考トークンの内訳

「何トークンまで入るか」を見誤る原因は、たいてい数え漏れにあります。窓を消費するものを先に洗い出します。

システムプロンプトとツール定義まで窓を消費するという計上範囲の実体

リクエストに含まれるものはすべて窓に載ります。Anthropicの公式ドキュメントは、システムプロンプト、messages内の全メッセージ（ツール結果・画像・文書を含む）、ツール定義のすべてが計上対象だと記載しています。エージェント実装でツールを20個も30個も定義していれば、ユーザーが1文字も入力する前に数万トークンが消えている。プロンプトキャッシュを使っても消費量は変わりません。キャッシュが変えるのは課金の内訳だけで、cache_read_input_tokensもcache_creation_input_tokensも窓を占有します。実測にはレスポンスのusageフィールドを見るのが確実です。

出力と思考トークンが同じ窓を共有する構造とmax_tokensの上限関係

出力側も同じ窓を使います。生成されたテキストは次のターンでは入力の一部になり、履歴として積み上がっていく構造。拡張思考を有効にした場合、思考トークンもmax_tokensの内数として消費され、出力トークンとして課金されます。過去ターンの思考ブロックを残すかどうかはモデル世代で挙動が分かれ、Claude Opus 4.5以降のOpus系・Sonnet 4.6以降のSonnet系・Fable 5では既定で保持され、入力トークンとして再度カウントされる仕組みです。それ以前の世代とHaiku系では自動的に除去されます。長い会話でトークン消費が想定より早い場合、まずここを疑ってください。

日本語1文字あたりのトークン消費と投入前の実測でずれを潰す手順

日本語は英語よりトークン効率が悪く、同じ意味の文章でも消費量が増えます。この差がどこで生まれるのかはトークナイザーの仕組みと日本語での実装判断で語彙配分の側から整理しています。目安として1文字あたり0.6〜1.5トークン程度に振れ、漢字熟語が多い技術文書ほど分割されやすい傾向。この幅は設計値として使うには粗すぎます。実務では、代表的な文書サンプルを3〜5本用意し、事前見積もり用のトークンカウントAPIで実測してから上限設計に入るのが早い。Anthropicは送信前の見積もりにトークンカウントAPIを使うよう案内しており、OpenAI側もトークナイザで同様に測れます。文字数からの換算式を社内標準にすると、PDFやCSVを混ぜた時点でずれます。

主要モデルの公称値比較｜2026年8月時点の上限と出力枠の別建て

公称値は横並びに近づきました。ただし出力上限は別建てで、ここを見落とすと長文生成の設計が崩れます。

100万トークン級が並んだ公称値と12.8万トークンという出力上限

2026年8月3日時点の公式ドキュメント記載値を並べます。

Claude側は100万トークンが既定で、ベータヘッダなしに使えて課金も標準単価です。画像やPDFを送る場合は別の上限があり、100万トークン系で1リクエスト600ページ、20万トークン系で100ページまで。GoogleのGemini 3系も100万トークン級の帯にいますが、上限値はモデルカードごとに更新されるため、採用前に該当モデルのページで確認してください。モデル選定そのものの考え方はLLMの仕組みと企業導入の判断基準に整理しています。

公称値だけで選ぶと外す理由とRULERが示した32Kでの性能低下

公称値は「エラーにならずに受け付けられる量」です。精度を保証する数値ではありません。2024年4月投稿のarXiv 2404.06654「RULER」は、32Kトークン以上を公称するモデルを評価し、32Kの長さで満足な性能を維持できたのは半数だけだったと報告しました。単純な検索タスクではほぼ満点でも、長さが伸びると大きく性能が落ちる傾向は、ほぼすべてのモデルに共通していたとの記載です。この乖離を、実装側では有効コンテキスト長と呼び分けます。公称100万トークンのモデルに90万トークンを投げる設計は、動くかどうかではなく、答えが合うかどうかで検証が要ります。

公称長と有効長の乖離｜位置依存の精度低下という実測結果への対処

長い入力で精度が落ちる現象には、再現性のある形があります。位置と量、2つの軸で見ます。

中央に置いた根拠情報の正答率が落ちるという2023年の実験結果

2023年7月6日投稿のarXiv 2307.03172「Lost in the Middle」は、根拠となる情報を入力のどこに置いたかで正答率が変わることを示しました。論文の要旨は、性能が最も高くなるのは関連情報が入力の先頭か末尾にあるときで、中央にあると顕著に劣化すると述べています。長文向けに設計されたモデルでも同じ傾向が出たという指摘も含まれます。実装への反映は単純です。検索で拾った根拠は先頭側か末尾側へ寄せ、指示文は末尾に置く。10件の候補文書を関連度順に並べたなら、上位2件は先頭、次点は末尾に配置すると安定します。

窓を埋めるほど精度が下がる現象と投入量ではなく取捨で決める設計

トークン数が増えるにつれて正確さと想起が落ちる現象は、コンテキストロットという名前で公式ドキュメントにも記載されています。窓の広さより、何を入れるかの取捨のほうが効くという話。ここは判断を言い切ります。会話履歴を無編集で積み続ける実装は、窓が100万トークンあっても採用しないでください。ツール結果の生ログ、失敗した試行、重複した検索結果は、次の推論で参照されないうえに正解を薄めます。逆に、根拠文書が5万トークン程度で構造が明確なら、分割せず丸ごと入れるほうが精度も実装コストも有利です。長さそのものを伸ばす技術の側はRoPEによる位置埋め込みとコンテキスト長の外挿で扱っています。

長い窓が持ち込むコストと遅延｜KVキャッシュと入力課金の内訳

窓を広く使うと、GPUメモリと請求額の両方が動きます。桁を把握しておくと設計判断が速くなります。

系列長に比例して膨らむKVキャッシュのGPUメモリ試算と限界

自前でモデルをホストする場合、系列長に正比例してKVキャッシュが膨らみます。試算式は、2（KとV）×層数×KVヘッド数×ヘッド次元×dtypeのバイト数×系列長×バッチ数。層数80・KVヘッド8・ヘッド次元128のGQA構成をbf16で動かすと、1トークンあたり約0.31MB。12.8万トークンを1本流すだけで約43GBに達します。80GBのGPU1枚では、モデル重みを載せた時点でバッチ1本すら怪しい水準。長い窓は推論基盤の台数見積もりを直撃します。内訳と削減手法はKVキャッシュの仕組みとメモリ削減の判断にまとめています。

入力トークン課金が効く場面とプロンプトキャッシュで変わらない部分

APIを使う場合、コストは入力トークンにほぼ比例します。Claude Opus 5の入力単価は100万トークンあたり5ドルなので、窓を満たす1リクエストで入力だけ5ドル。これを毎回のターンで繰り返す設計にすると、会話が10往復した時点で無視できない額になります。プロンプトキャッシュは、変わらない前置き部分の単価を下げる仕組みで、消費トークン量そのものは減りません。効くのは同じシステムプロンプトと同じ文書を何度も送る構成で、逆に毎回異なる長文を投げる用途では効果が出ない。ここを取り違えると、キャッシュを入れたのに請求が下がらない状態になります。

窓に収まらない入力の扱い方｜RAG・圧縮・分割の採否条件と失敗例

入力が窓を超えるとき、選択肢は3つです。どれを選ぶかは、文書の量と質問の形で決まります。

全文投入とRAGの分岐点｜検索で足りる条件と丸ごと入れる条件

分岐は「質問が文書のどこを見れば答えられるか」で判断します。局所的な事実を1〜2箇所から引くだけなら、検索で該当箇所だけ渡すRAGが有利。全文を入れても精度は上がらず、コストと遅延だけが増えます。逆に、文書全体の整合性を見る要約・矛盾検出・横断比較は、検索で切り出した断片では答えが出ません。目安として、根拠となる文書群が10万トークンを下回り、質問が全体を見渡す性質なら丸ごと投入を選びます。数百万トークンの社内文書から特定の規程を引くならRAG。この分岐を曖昧にしたまま両方を積むと、検索で外した断片が長文に埋もれて誤答の原因になります。RAG側の分割設計は意味の切れ目で分けるセマンティックチャンキングが参考になります。

要約圧縮とcompactionを使ってよい条件と壊れる処理の見分け方

会話が長期化するエージェントでは、古い履歴を要約して差し替えるcompactionが有効です。Anthropicはサーバー側compactionをClaude 4.6以降でベータ提供しており、ウィンドウ上限を超えて会話を継続できます。ツールの実装例としてはauto-compactによる自動コンテキスト圧縮が挙動を追いやすい。使ってよい条件は、圧縮対象が「済んだ作業の記録」であること。逆に、圧縮すると壊れる処理もはっきりしています。監査ログの厳密な引用、数値の逐次計算、法令原文の条番号照合のように、原文の一字一句が結論を左右する処理では要約を挟まないでください。要約は情報を落とす操作で、落とした部分は後から復元できません。

溢れたときのAPI挙動｜400エラーと打ち切り停止の分岐と実装対応

超過時の挙動は2つに分かれます。Anthropicのドキュメントによれば、入力だけで窓を超えている場合は全モデルで400番のinvalid_request_errorが返り、メッセージは「prompt is too long」。一方、入力とmax_tokensの合計が窓を超えるケースは、Claude 4.5以降ではリクエストが受理され、生成が上限に達した時点でstop_reasonがmodel_context_window_exceededになって止まります。実装側の対応も分かれます。前者はリトライしても同じ結果になるため、投入前にトークン数を測って弾く。後者は途中まで生成されているので、停止理由を判定して続きを要求するか、出力枠を切り下げて再実行する分岐を用意しておきます。停止理由を見ずに成功扱いすると、途中で切れた文章がそのまま後段へ流れます。

窓設計で先に決める項目｜実装体制と外注見積もりで確認する要件

ここまでの判断を、着手前に決める形へ落とします。要件定義に書ける粒度まで具体化しておくと、後戻りが減ります。

窓の使い道を先に決める4項目と要件定義へ落とすときの記述粒度

着手前に固定するのは次の4項目です。

1. 1リクエストあたりの入力トークン上限（実測サンプルから算出した値。文字数換算は使わない）
2. 履歴の保持方針（全保持・要約圧縮・件数打ち切りのどれか、切り替えの閾値まで）
3. 根拠文書の渡し方（全文投入かRAGか、両方使うなら切り替え条件）
4. 超過時の挙動（事前弾きか、停止理由を見た継続生成か）

4項目のうち優先度が高いのは1と4です。ここが決まっていないと、負荷試験で初めて上限に当たり、設計をやり直すことになります。2と3は運用開始後に調整が効く領域なので、初期値を決めて計測しながら動かす形で構いません。

長文処理を外注するとき見積書で確認する技術要件と受け入れ条件

長文処理を含むLLM実装を外部に委託する場合、見積書で確認したい項目は限られます。想定する入力トークン量の上限と、その根拠となる実測サンプル。超過時の挙動が仕様として書かれているか。有効長の検証方法（根拠情報を先頭・中央・末尾に置いた場合の正答率比較など）が受け入れ試験に含まれているか。自社ホスティングならKVキャッシュを含めたGPUメモリ試算が示されているか。この4点が書かれていない見積もりは、精度が出なかったときの責任範囲が曖昧になります。生成AI導入支援では、こうした窓設計と検証条件を含めて要件定義から実装まで請け負っています。

よくある質問

コンテキストウィンドウの検討で実際に問い合わせが多い論点を5つ挙げます。

コンテキストウィンドウとトークン数の違いは何ですか？

トークンはテキストを分割した最小単位で、コンテキストウィンドウはそのトークンを何個まで同時に扱えるかという上限値です。単位と容量の関係にあたります。混同しやすいのは「最大出力トークン数」との違いで、こちらは1回の応答で生成できる量の上限。100万トークンの窓を持つモデルでも、1回の出力は12.8万トークンまでという制約が別に掛かります。

コンテキストウィンドウが大きいモデルを選べば精度は上がりますか？

上がりません。RULERの評価では、32K以上を公称するモデルの半数が32Kで性能を保てず、長さが伸びるほど落ちる傾向が共通して観測されました。公式ドキュメントもコンテキストロットとして同じ現象に触れています。窓の大きさが効くのは「入り切らずに落ちる」問題の解消までで、そこから先の精度は、何を入れて何を捨てるかの設計で決まります。

日本語の文書は何文字くらいで100万トークンに届きますか？

正確な換算はトークナイザとモデル世代に依存するため、文字数からの逆算は目安にとどめてください。日本語は1文字あたり0.6〜1.5トークン程度の幅で振れるので、100万トークンは概ね数十万字から百万字規模に対応します。実務では代表サンプルを送信前のトークンカウントAPIで実測し、その値で上限設計を組むほうが安全です。PDFや表を含む文書では、同じ見た目の分量でも消費量が跳ねます。

コンテキストウィンドウを超えるとどうなりますか？

入力だけで超えている場合は、400番のエラー（prompt is too long）が返り、リクエストは処理されません。入力と最大出力の合計が超える場合、Claude 4.5以降では受理され、生成が上限に達した時点で停止理由が model_context_window_exceeded となって打ち切られます。前者は投入前の事前チェックで、後者は停止理由を見た継続生成またはリトライで対処します。

RAGとロングコンテキストはどちらを選ぶべきですか？

質問の性質で分かれます。特定の箇所を引く問い合わせはRAG、文書全体の整合性を見る要約や矛盾検出はロングコンテキストが向きます。根拠文書が10万トークンを下回り、質問が全体を見渡す形なら丸ごと投入を選ぶのが実装も簡単です。数百万トークン規模の文書群から探すなら、検索で絞ってから渡す構成以外に現実的な選択肢はありません。

関連記事

• メモリ・RAG・compactionでコンテキストロットを防ぐ実装解説：窓の中身を何で構成するかという設計側を扱っています
• エージェントメモリとは？短期記憶と長期記憶の設計・実装判断を実装者向けに解説【2026年版】：窓の外へ記憶を逃がす仕組みの選び方が分かります
• FlashAttentionとは？仕組みとFA2・3・4の違い・GPU世代別の実装判断を解説：長い系列でメモリ往復を削るカーネル側の手当てです
• スパースアテンションとは？疎なAttentionの仕組みとNSA・DSAの実装判断を解説：計算量そのものを落として長文を捌く近似手法です
• LLM推論とは？仕組みと高速化の手法・推論基盤の選び方を実装視点で解説【2026年】：推論基盤全体の中で長文処理をどう位置づけるかの整理です