コンテキストウィンドウとは？トークン上限と長文処理の落とし穴

コンテキストウィンドウとは、大規模言語モデル（LLM）が1回のリクエストで使えるトークンの総容量です。読み込む入力と、生成する出力の両方がここに収まります。1Mトークンのウィンドウなら、指示、文書、会話履歴に加え、回答にも同じ容量を割り当てる必要があります。推論を行うモデルでは、その思考も含まれます。ただし、容量いっぱいに情報を詰め込めることと、その細部まで正しく活用できることは別です。

AIのコンテキストウィンドウとは？

コンテキストウィンドウは、作業台にたとえるとわかりやすくなります。台の上には、資料や指示書、作業途中のものが並びます。台が大きければ、より多くの資料を広げられますが、作業するための空きも必要です。すべての文書を並べたからといって、必要な条項に必ず気づけるわけでもありません。

トークンは、モデルが情報を処理する単位です。単語全体ではなく、単語の一部に相当することもよくあります。テキストやコードなどの入力は、モデルごとの規則でトークンに変換されます。ページ数やファイルサイズから容量を推測するのではなく、実際のリクエストを数えてください。この違いは、Googleのトークンガイドで説明されています。

入力には、チャット欄に自分で打ち込んでいない情報も含まれます。

• アシスタントの振る舞いを定めるシステム指示。
• 今回のメッセージと、保持されている会話履歴。
• モデルが実行できる操作を記述したツール定義。
• ツールの実行結果、検索で取得した文章、画像、文書。

Anthropicは、コンテキストの算定方法で、これらも対象になると明記しています。ユーザーの質問が短くても、モデルに送られるリクエスト全体は非常に大きくなり得ます。

コンテキスト長と出力トークン上限はどう違う？

コンテキストウィンドウはリクエスト全体の容量を制限し、出力上限は生成される部分の容量を制限します。推論モデルでは、目に見える回答を出す前の思考にも、生成に使えるトークンの一部を割り当てる場合があります。OpenAIのドキュメントでも、入力・出力・推論が同じウィンドウを消費すると説明されています。

入力と出力でウィンドウを共有する場合、容量配分の基本は次のとおりです。

入力トークン数＋生成用に確保するトークン数を、コンテキストウィンドウ内に収めます。

モデルが推論も生成側に計上するなら、その分も確保してください。さらに、モデルごとに別途定められた最大出力も守る必要があります。出力上限を大きく設定しても、使える総容量は増えません。

AIツールのコンテキストウィンドウで何が決まる？

決まるのは、そのリクエストでモデルが同時に参照できる情報量です。情報をどれほど正確に使えるか、アプリがセッションをまたいで何を保存するか、保存した情報のどれを次回モデルに送るかまではわかりません。

サポート担当者にとって、この違いは実務に直結します。ヘルプデスクに問い合わせチケットが保存されていても、アシスタントの今回の入力に含まれているとは限りません。開発者にとっても、会話記録の保存と、次にモデルへ送るリクエストの組み立ては、別々に設計すべき処理です。

Claude・GPT-6・Gemini 4のコンテキストウィンドウを比較

以下の主要なAPIモデルは、おおむね100万トークン規模のウィンドウを備えています。ただし、出力の規則も、公称容量と同じくらい重要です。2026年10月16日に、各提供元の公開モデルページで確認しています。 各行のリンク先は提供元のページです。ここに示すのはAPIの仕様であり、一般向けチャットプランや各アプリ独自の上限を保証するものではありません。

Claudeの現行モデルページでは、表に挙げたモデルのウィンドウと出力上限はすべて同じです。そのため、これらのモデルを選ぶ際にウィンドウの大きさは有効な判断材料になりません。実際のタスクに対する回答を比較してください。

GPT-6 Astra、GPT-6.1 Sol、GPT-6 Lunaも、記載上の容量は共通です。それでも、情報抽出、計画、コーディングでは振る舞いに違いが出ることがあります。仕様からわかるのは収まる量であって、品質の順位ではありません。

Gemini 4 Argonのlong decodeで使える容量も、共有ウィンドウの内側にあります。Googleによると、APIは要求された出力量を、入力を差し引いた残り容量までに制限します。思考もその容量を消費します。入力で使い切ったウィンドウに、大きな出力設定の分を上乗せすることはできません。厳密な規則は、Geminiのトークン算定方法で確認できます。

計算例：プロンプトは収まっても、回答が収まらない

100万トークンのプロンプトを送ると、回答に使える余裕は、モデルの最大出力から想像するより小さくなります。

GPT-6 Astraの公開上限を例に考えます。指示、ツール、履歴、参照文書を組み立てたリクエストが、入力1,000,000トークンになったとします。これは容量配分を説明するための例で、実測したワークロードではありません。ここで、モデルが認める生成128,000トークンを、上限いっぱいまで確保したいとします。

計算は次のようになります。

• ウィンドウ：1,050,000トークン。
• 入力後の残り容量：1,050,000 − 1,000,000 = 50,000トークン。
• 予定している入力と出力の合計：1,000,000 + 128,000 = 1,128,000トークン。
• 不足分：78,000トークン。

入力は収まりますが、予定した回答用の容量は確保できません。残った容量の中に、推論と目に見える回答の両方を収める必要があります。

最大出力をすべて確保するなら、入力は多くても922,000トークンに抑える必要があります。これは1,050,000 − 128,000で求めた値であり、ワークフローに必要な追加の余裕はまだ差し引いていません。すべてのタスクで最大出力分を確保する必要はありません。必要な出力量に応じて割り当ててください。

ウィンドウが大きくても、情報を正確に拾えるとは限らない

リクエストが容量内に収まっていても、中にある根拠を見落とした回答が返ることがあります。APIがプロンプトを受け付けたとしても、回答品質としては失敗です。

Anthropicは、コンテキストエンジニアリングのガイドで、コンテキストが長くなるにつれて情報を正しく取り出す能力が低下すると説明しています。こうした失敗は、明白な応答拒否として現れるとは限りません。例外規定を見落としたり、旧方針と改定後の方針を混同したり、近くにある一見関連しそうな記述をもとに答えたりすることもあります。

Nelson F. Liuらの論文「Lost in the Middle」では、文書に対する質問応答とキー・バリューの検索における性能が、関連情報の位置に左右されることが示されています。文書の中央にある根拠は、両端付近の根拠より活用しにくい場合がありました。これは過去の研究であり、上の表に掲載した現行モデルのベンチマークではありません。

長いコンテキストでの品質は、自分のワークロードで測定してください。 あらゆるモデルが突然信頼できなくなる、共通のトークン数があるわけではありません。

サポート用アシスタントなら、正解がわかっている例外規定をもとに、小規模な評価セットを作ります。該当する方針に絞ったリクエストと、無関係な方針も含めた長いリクエストを比較してください。判断の決め手となる記述を前方、中央、後方へ移動させ、正しい例外を適用し、適切な出典を示せるかを確認します。

コーディング用アシスタントなら、実装ファイルとその呼び出し元の両方を見ないと答えられない質問を用意します。まず関連情報だけで回答を確認し、その後に無関係なファイルを加えてください。長くしたことで回答が悪化しても、容量を増やすだけでは原因はわかりません。

特徴的な一文を見つけられたことは、情報を検索できた証拠にはなります。しかし、矛盾する文書を突き合わせて整合性を判断できることや、長いタスクの間ずっとすべての制約を守れることまでは証明しません。

「Context Too Long」で上限に達したときの対処法

開発者は、組み立て後のリクエスト全体を調べてください。運用担当者は、セッションを続ける前に現在のタスクの状態を保存してください。 どちらの場合も、入力そのものが拒否されたのか、回答生成中に容量を使い切って止まったのかを区別する必要があります。

現行のClaudeモデルについて、Anthropicは、入力だけでウィンドウを超えるとプロンプトが長すぎるというエラーになると説明しています。一方、入力が収まっていても生成中に境界へ達すると、model_context_window_exceededという理由で応答が停止する場合があります。古いメッセージが黙って捨てられたと思い込まず、実際のエラーや停止理由を確認してください。Claudeの容量超過時の挙動に詳細があります。

1. 1

   アプリが送る情報をすべて数える

   指示、会話メッセージ、ツール定義、検索で取得した文章、ツールの実行結果をまとめて確認します。リクエストの形式に対応していれば、提供元のトークン計数機能を使い、その見積もりを応答の使用量と比較してください。Anthropicのトークン計数エンドポイントは、構造化されたメッセージや多くの入力形式に対応していますが、サーバーツールや一部のファイルソースには制約があります。

2. 2

   生成に使う容量を先に確保する

   モデルのウィンドウ、出力上限、必要な出力のために確保する量を記録します。該当する場合は思考も含めてください。その分だけ入力に使える容量を減らし、空いているトークンをすべて追加文書のために使わないようにします。

3. 3

   増え続けている情報を見つける

   繰り返し現れる検索結果、ログ全体、重複文書、途中で打ち切った会話の分岐を探します。コーディングエージェントには、失敗したテストと関連する関数が必要かもしれません。一方、過去に成功したすべてのコマンドの出力全文を、毎ターン持たせる必要はほとんどありません。次の操作を検証するための根拠を残してください。

4. 4

   作業を再開するためのメモを残す

   再起動やコンパクションの前に、目的、確定した判断、未解決の問題、関連する参照元の場所、次の操作を保存します。顧客対応中の担当者なら、現在の依頼内容と適用される方針の例外を残してください。正確な文言が重要な場面では、元の資料を開き直します。

5. 5

   変更後も正しく答えられるか確認する

   小さくしたリクエストで、失敗したタスクをもう一度実行します。必要な根拠が含まれ、回答が正しいことを確認してください。プロンプトが収まるようになっても決定的な情報を見落とすなら、やみくもに削り続けず、情報の選び方と取り出し方を調べます。

短く安定したワークフローですでに正しく答えられ、上限にも収まっているなら、モデルを変える必要はありません。公称ウィンドウが大きいという理由だけで移行するのは早計です。

検索・要約・コンパクション・キャッシュをどう使い分ける？

何が容量を占めているのかを見て、対策を選んでください。それぞれが解決する問題は異なり、組み合わせて使うこともできます。

資料全体の量が、質問への回答に必要な根拠の量を大きく上回るなら、検索を使います。 検索拡張生成（RAG）は、モデルが回答する前に、選び出した参照資料を渡す方法です。サポート用アシスタントなら、ナレッジベース全体を読むのではなく、該当する返品規定と注文記録を取得します。最初に得た根拠では不十分なとき、エージェントが再検索する方法は、エージェント型RAGのガイドで説明しています。

制約になるのは、情報の選び方です。検索で決定的な例外を取り逃がせば、モデルはそれを使えません。タスク全体を通して文書の細部を比較する必要があるなら、対象を絞ったうえで文書全文をコンテキストに保持し、さらに絞り込むと必要な根拠が抜け落ちないかを評価してください。

過去の細かなやり取りを、引き継ぐべきタスクの状態に置き換えられるなら、要約を使います。 要約には、決まったこと、まだ不確かなこと、根拠となる資料の場所を残します。コード変更なら、採用した方針、現在の不具合の挙動、関連するファイルパスなどが該当します。次の判断が文言に左右される場合は、契約の条項やエラーメッセージを大まかな言い換えで置き換えないでください。

会話そのものが容量の大半を占めるようになったら、コンパクションを使います。 コンパクションは、蓄積した履歴を、作業継続に必要な小さなコンテキストへ置き換える処理です。Anthropicは、圧縮しすぎると重要な詳細が失われる可能性があると注意しています。圧縮後の会話を完全な保存記録と考えず、何が残ったかを確認してください。このトレードオフは、Anthropicによるコンパクションの解説で扱われています。

エージェントの作業全体を通して、こうした情報をどう選び、維持するかは、コンテキストエンジニアリングのガイドで詳しく説明しています。

有用な入力を繰り返し使うなら、プロンプトキャッシュを使います。 リクエスト冒頭の変わらない部分、つまり一致するプロンプトのプレフィックスに対する処理を再利用します。固定の指示や共通資料を、変化する内容より前に置き、モデルごとのキャッシュ規則に従ってください。OpenAIの現行ガイドには、明示的なブレークポイントの挙動が記載されています。一方、Gemini 4 Argonのモデルページに記載されているのは、暗黙的なキャッシュのみです。OpenAIのキャッシュガイド、Geminiのキャッシュ対応を参照してください。

プロンプトが長くなれば、課金対象の入力トークンも増えます。キャッシュにヒットすると、キャッシュ書き込みの規則に応じて、繰り返す入力の料金を減らせる場合があります。ただし、そのトークンは引き続きウィンドウを占有します。キャッシュの仕組みは、別の記事で解説しています。

プロンプトの冒頭を圧縮したり書き換えたりすると、キャッシュを再利用しにくくなることがあります。固定のプレフィックスが役立つ間は維持し、無関係な履歴がリクエストの質を損なうなら取り除いてください。キャッシュヒット率の高さは、回答の良さを保証しません。

ロングコンテキストへの期待で、行き過ぎているのはどこ？

容量の数字だけで、本来その数字が測っていない能力まで判断されがちです。 完璧に情報を取り出せること、永続的な記憶を持つこと、あらゆる検索ワークフローを大きなプロンプトで置き換えられることは、容量からはわかりません。

大きなウィンドウが役立つ条件は具体的です。同時に必要な関連情報が多く、小さなリクエストでは重要な関係が失われ、大きなリクエストなら自分の評価で正しい結果が出ることです。この場合は、容量を使う理由があります。

ログや履歴、参照資料が回答用の容量を圧迫しているなら、対処が必要です。まず、リクエストに入れる情報を見直してください。それでも必要な情報が収まらない場合に、より大きなウィンドウを持つモデルを検討します。既存のワークフローが安定しており、仕様上の数字を大きくしたいだけなら、移行は急がなくてかまいません。

コンテキストウィンドウについてよくある質問

AI言語モデルのコンテキストウィンドウとは何ですか？

モデルが1回のリクエストで参照する入力と、生成する出力に使えるトークン容量です。推論モデルでは、提供元の規則に従って思考の分も計上します。

200Kのコンテキストウィンドウには、どれくらいの文章が入りますか？

200Kは200,000トークンを意味します。一定の単語数やページ数を示すものではありません。また、入力と出力で共有するウィンドウには、生成される出力も収める必要があります。使用するモデルのトークナイザーや、対応するトークン計数エンドポイントで資料を数えてください。

プログラミングでいう「コンテキスト」とは何ですか？

ある処理が利用できる、周囲の情報を指します。LLMアプリでは、今回モデルに送るリクエストのために組み立てた指示、メッセージ、参照資料が該当します。

コンテキストエンジニアリングには、どのような実例がありますか？

たとえば、サポート用アシスタントに、現在の問い合わせチケット、適用する方針、これまでの判断をまとめた簡潔な記録を渡す構成です。チケットの全履歴を渡すのではなく、必要に応じて追加の根拠を検索します。

コンテキストエンジニアの給与はどれくらいですか？

コンテキストウィンドウの仕様から給与は判断できません。採用では、業務が検索、アプリケーション開発、評価、インフラのどこまでを含むかを定め、同じ地域で業務範囲が一致する職種と比較してください。

コンテキストエンジニアリングはどう学べばよいですか？

小さなアプリが送るリクエストを、全体まで確認してください。指示、検索で取得する根拠、保持する履歴をそれぞれ個別に変え、正解がわかっている結果と回答を比較します。単にプロンプトが短くなった理由ではなく、変更によって正確さが向上した理由を説明できるようになることが大切です。

コンテキストエンジニアリングとプロンプトエンジニアリングはどう違いますか？

プロンプトエンジニアリングは、モデルに与える指示や例を中心に扱います。コンテキストエンジニアリングはそれに加え、根拠の選択、ツールの提供、作業が進む中で適切な状態を保持することも対象にします。

コンテキストエンジニアリングで押さえるべき実践方法は？

リクエスト全体の容量を見積もり、出力用の空きを確保し、必要な根拠を残します。要約するときは参照元の場所も保持してください。削除やコンパクションを行った後も、正しく答えられるか確認します。

コンテキストエンジニアリングで、エージェントにどんなスキルを持たせるとよいですか？

資料を探す、関連箇所を確認する、タスクの状態を保存するといった目的に絞った手段を用意してください。そのツールの結果が、リクエストを不要な情報であふれさせずに、次の判断に役立つかどうかで評価します。

まず、実際に失敗したリクエストを見直す

失敗した、または重要な情報を見落としたリクエストを選んでください。入力全体を数え、想定する出力のための容量を確保し、回答に役立っていない情報のうち最も大きな塊を見つけます。それを選別した根拠や引き継ぎメモに置き換え、正解がわかっているタスクを再実行してください。必要な根拠と結果を維持できた場合にだけ、小さくしたリクエストを採用します。

信頼できるAIワークフローを構築するための実践ガイドは、ニュースレターに登録してお受け取りください。