コンテキストウィンドウとは？LLMユーザーが知っておくべきこと
- 公開日
- 最終更新日
コンテキストウィンドウとは、大規模言語モデル（LLM）が1回のリクエストで処理できる情報量です。トークンで測定され、プロンプト、会話履歴、システム指示、取得したドキュメント、ツールの結果、モデルが生成した応答を含めることができます。
コンテキストウィンドウが大きいほど、モデルは1回のリクエストでより多くの情報を扱えます。たとえば、バグを調査するコーディングエージェントは、各要素を個別に分析してリクエスト間で有用な文脈を失う代わりに、関連するソースファイル、ドキュメント、テスト結果、直近のコード変更を同時に扱えます。
ただし、コンテキストウィンドウが大きいことは完全な記憶と同じではありません。長いプロンプトにはより多くの計算が必要で、消費するトークンも増え、モデルが本当に重要な詳細を見極めにくくなることがあります。 Lost in the Middleの研究やNVIDIAの RULERベンチマークを含む長文コンテキストモデルの研究では、コンテキストが増えるほど、モデルが利用可能な情報を活用できなくなることが繰り返し示されています。特に、関連情報があまり役に立たない情報の中に埋もれている場合に顕著です。
この記事では、コンテキストウィンドウの仕組み、測定方法、上限に達したときに起こること、そしてデベロッパーが効果的に管理する方法を解説します。
概要
- コンテキストウィンドウは、LLMが1回のリクエストで使うトークンの総予算です。ユーザープロンプト、会話履歴、取得コンテンツ、出力が含まれます。
- コンテキストウィンドウが大きいほど、より長いドキュメント、コードベース、会話を扱えますが、そのすべてをモデルが適切に活用できるとは限りません。
- モデルが長いプロンプトから最も信頼性低く情報を取得するのは中央部分であり、この傾向はLost in the Middle研究とRULERベンチマークで実証されています。
- トークン送信数を単に最大化するよりも、効果的なコンテキスト管理（検索、要約、キャッシュ）の方が通常は優れています。
- 最適なコンテキスト戦略は、宣伝されている最大のコンテキストウィンドウを使うものではなく、実際のワークロードに合ったものです。
AIモデルにおけるコンテキストウィンドウとは？
コンテキストウィンドウは、モデルが応答を生成する前に、現在のリクエストに関連するすべての情報が集まるアクティブな作業領域です。
たとえば、 AIエージェントがカスタマーサポートの会話を要約し、解決策を提案するケースを考えてみましょう。これを適切に行うには、モデルは次を処理する必要があります。
- システムプロンプト
- 顧客のメッセージ
- 会話履歴
- 会社のポリシー
- ツールとAPIの結果
- 出力
ウィンドウの大きさにかかわらず、これらすべてが同じコンテキストウィンドウ内の容量を取り合います。
コンテキストウィンドウに学習データは含まれません。学習では情報がモデルのパラメータに恒久的に組み込まれ、一般的に何を「知っている」かが形作られます。一方、コンテキストウィンドウに保持されるのは、現在のタスクのために提供された情報だけです。
この違いは実務上重要です。アプリケーションで特定のポリシー、顧客記録、技術ドキュメントについてモデルに推論させるには、類似の資料で学習済みというだけでは不十分です。通常はプロンプトで直接、または検索・ツールシステムを通じてモデルの作業コンテキストにその情報を入れる必要があります。そうしないと、目の前の実際のドキュメントではなく一般知識に基づいて推論します。
トークン化とコンテキストウィンドウ：データの処理方法
LLMがテキストを処理する前に、トークナイザーがテキストをトークンと呼ばれる小さな単位に分割します。トークンは、単語全体、単語の一部、句読点、その他の短いテキスト片を表す場合があります。
英語では、1トークンはおよそ4文字、または単語の約4分の3と考えるのが目安です。この推定では、100トークンは約75語に相当します。ただし、これはあくまで概算です。「Context windows affect application performance.」という文を考えてみましょう。トークナイザーが必ずしも5つの完全な単語として表すわけではなく、トークナイザーによっては1つ以上の単語が複数のサブワードトークンに分割されることがあります。
トークン化は言語によっても大きく異なります。意味や見た目の長さが似た2つの文でも、言語やトークナイザーによって消費するトークン数は大きく異なる場合があります。トークナイザーの公平性に関する研究では、多言語対応用に構築されたトークナイザーでも、同等のテキストのトークン化後の長さが言語ペアによって最大15倍異なることが示されています。多言語アプリケーションを構築するデベロッパーは、単語数から推定するのではなく、対象モデルの実際のトークナイザーでトークン使用量を測定すべきです。
20万トークンのコンテキストウィンドウは非常に大きく聞こえるかもしれません。しかし、会話履歴、取得したドキュメント、ツールの応答、システム指示を継続的に追加するアプリケーションでは、想定より早くその上限に近づくことがあります。そのため、本番環境のアプリケーションでは、トークン使用量を監視し、要約、履歴の剪定、検索フィルタリング、プロンプト圧縮などで、最も関連性の高い情報をアクティブなコンテキスト内に収めることがよくあります。
言語モデルではコンテキストウィンドウはどのように機能する？
コンテキストウィンドウは、モデルが応答を生成する前に、入力内の各トークンが他のすべてのトークンとどう関係するかを計算する、Transformerアーキテクチャのアテンション機構によって機能します。
「顧客は充電できなくなったため、ノートパソコンを返品した。」という文を考えてみましょう。これを正しく解釈するには、モデルは顧客、ノートパソコン、返品、そして充電が互いにどう関係するかを理解する必要があります。シーケンスが長くなるほど、こうした関係の数は急速に増えます。
標準的な自己注意では、必要な計算量はシーケンス長のおよそ2乗に応じて増えます。たとえば、1万トークンのプロンプトでは約1億回のペアごとの比較が必要ですが、10万トークンのプロンプトでは約100億回必要です。現代のモデルは、このコストを実用上抑えるためにさまざまなアーキテクチャやインフラの最適化を使っていますが、根本的なスケーリングの問題はなくなりません。
長い会話には、もう1つの制約があります。それがキー・バリュー（KV）キャッシュです。生成中、モデルは新しいトークンごとに再計算する代わりに、以前のトークンの中間表現を保持するため、推論を大幅に高速化できます。ただし、キャッシュ自体がメモリを使用し、シーケンスが長くなるほど増大します。
AIモデルの最大コンテキスト長とその重要性
モデルの最大コンテキスト長は、1回のリクエストで受け入れて処理できる情報量を定義します。ただし、大きなコンテキストウィンドウをモデルが効果的に利用できるかどうかは別の問題です。
より長いコンテキストウィンドウにより、以前のLLMでは困難または非現実的だったユースケースが可能になります。デベロッパーは、数千トークンまで事前に削減しなくても、コードリポジトリ全体、長大な法的文書、研究論文、会議の文字起こし、大量の会話履歴をモデルに渡せます。
これは、元のコンテキストをより多く保持することで、質問への正確な回答、離れた情報間の関係の特定、ドキュメント全体に依存するタスクの実行といったモデルの能力を高められるためです。たとえば、コーディング支援ツールは関数の呼び出し方を理解するために複数ファイルを確認する必要があり、法務文書支援ツールはあるセクションの定義と、文書のかなり後方で説明される義務を比較する必要があるかもしれません。
ただし、コンテキストウィンドウを大きくしても、結果が自動的に改善されるわけではありません。非常に長い入力はコストとレイテンシーを増やす可能性があり、モデルは大きなコンテキストの中央に埋もれた情報への注意を弱めることがあります。したがってデベロッパーは、関連情報を選択的に含め、長い入力を明確に整理し、必要に応じて検索、要約、コンテキストの剪定といった手法を使うべきです。
モデル別コンテキストウィンドウサイズの比較
現在の主要モデルファミリーのコンテキストウィンドウは、数十万トークンから1,000万トークンまで大きく異なります。現行のフラッグシップモデルを比較すると、次のとおりです。
モデル | コンテキストウィンドウ | 注記 |
1,000万トークン | Metaのオープンウェイトモデル。執筆時点で公開されている最大のウィンドウ | |
105万トークン | コーディングとエージェント型推論向けのOpenAIの現行フラッグシップモデル | |
100万トークン | 長文ドキュメントと複数ファイルの分析向けのGoogleの現行Proティアモデル | |
100万トークン | Anthropicの現行Sonnetティアモデル。Claude API全体にデフォルトで適用されるウィンドウ |
プロバイダーが新モデルをリリースして上限を引き上げるため、公表される上限はすぐに変わります。このような表は恒久的なランキングではなく、スナップショットとして捉えてください。コンテキストサイズはモデル選択における要素の1つにすぎず、推論の品質、出力上限、レイテンシー、コストについては、それだけでは何もわかりません。
小規模と大規模のコンテキストウィンドウがもたらす影響
コンテキストウィンドウが小さい場合、デベロッパーは情報を選択する必要があります。長いドキュメントは分割され、古い会話履歴は要約され、外部知識は実際に必要なときだけ取得されます。
コンテキストウィンドウが大きければ、こうした制約の一部はなくなります。より多くの例を与えたり、より多くの会話履歴を保持したり、すべてを事前に分割せずにより多くのドキュメントを分析したりできます。
ただし、ウィンドウが大きくなると別の問題、すなわち注意の希薄化が生じます。プロンプトに大量の情報が含まれると、モデルは現在のリクエストに最も関連する詳細を特定しにくくなることがあります。重要な指示や証拠が関連性の低いコンテンツに埋もれ、不完全、一貫性に欠ける、または精度の低い応答のリスクが高まります。
モデルが中央で情報を見失う理由
モデルは、長いプロンプトの先頭または末尾にある情報を最もよく取得し、中央に埋もれた情報を最も取得しにくい傾向があります。影響力のある Lost in the Middle研究では、長いプロンプトの異なる位置に質問への回答を配置し、モデルがそれを見つける頻度を測定することで、この点を直接検証しました。精度は一貫してコンテキストの先頭と末尾で最も高く、中央で最も低くなりました。
つまり、モデルは技術的にはドキュメントを受け入れられても、そのすべての部分を確実に利用できるとは限りません。100件のサポートドキュメントのうち1件に顧客の質問への答えが含まれているため、LLMに100件すべてを送るとします。コンテキストウィンドウが大きければ100件すべてを収められるかもしれません。しかしモデルは依然として、99件の無関係な文書から関連する1つの箇所を見つけ出す必要があり、ウィンドウが長いからといって成功する保証はありません。
そのため、モデルが公表しているコンテキストウィンドウと、特定のワークロードにおける実効コンテキストウィンドウを区別する価値があります。RULERや LongBenchのようなベンチマークは、その差を測定しようとしています。RULERでは、単純な検索テストでほぼ完璧なスコアを出したモデルでも、コンテキスト長とタスクの複雑さが増すにつれて性能が低下することがわかりました。LongBenchは、ドキュメント質問応答、複数ドキュメントの推論、要約、Few-shot学習、コード補完など、より幅広いタスクを評価します。
長いコンテキストには依然として実際の価値があります。容量と理解力は単に異なる特性であり、特定のタスクに適したモデルを選ぶ際にはどちらも重要です。
コンテキスト上限の管理：デベロッパー向けベストプラクティス
優れたコンテキスト管理とは、すべてのリクエストでトークン数を最大化しようとするのではなく、関連する情報を関連するタイミングでモデルに届けるよう、モデルに到達する情報を制御することです。以下の実践により、不要なコンテキストを減らし、応答品質を改善し、コストとレイテンシーを抑えられます。
1. すべてを読み込むのではなく、関連情報を取得する
検索拡張生成（RAG）により、アプリケーションは外部のナレッジベースを検索し、関連する箇所だけをモデルのコンテキストに挿入できます。すべてのサポートリクエストに500ページのマニュアル全体を入れるのではなく、顧客の実際の質問に最も近い数か所を取得します。
これによりトークン使用量が減り、何が重要かをモデルにより明確に伝えられます。検索品質も重要です。本番のRAGシステムでは通常、ドキュメントを慎重にチャンク化し、複数の候補箇所を取得して再ランキングし、最終プロンプトを構築する前に無関係なものを除外することで結果を改善します。たとえばElevenLabsは、RAGパイプラインを再構築し、クエリの書き換えと並列モデル呼び出しを追加して、検索レイテンシーの中央値を半減させました。
2. 会話履歴を意図的に管理する
会話型アプリケーションでは、コンテキストがすぐに蓄積されます。過去のメッセージをすべて無期限に追加するとトークンを浪費し、その後のターンに無関係な詳細が入り込むことがあります。
アプリケーションでは、直近のターンを保持し、古い会話を要約し、永続的な事実を構造化メモリに抽出し、古い詳細は再び関連性が生じたときだけ取得することで対応します。これにより、モデルが直ちに必要とする短期的な会話コンテキストと、後から呼び戻せる長期的なアプリケーションメモリを有用に分けられます。
3. コンテキストが繰り返される場合はキャッシュを使う
多くのアプリケーションは、同じ大きな指示を繰り返し送信したり、すでに処理した質問と意味的に似た質問に回答したりします。キャッシュによりこのオーバーヘッドを削減できます。
プロンプトキャッシュやコンテキストキャッシュでは、繰り返される入力をより効率的に再利用できます。また、セマンティックキャッシュは、システムがすでに回答した質問と新しい質問がほぼ同じ意味かを認識することで、さらに一歩進みます。「返品ポリシーを教えてください」と「商品はいつまで返品できますか？」は異なる文字列ですが、セマンティックキャッシュでは同じ質問として扱えます。完全な生成呼び出しを省略し、レイテンシーとトークンコストの両方を削減できます。
4. 現実的なコンテキスト長でパフォーマンスを測定する
モデルプロバイダーが公表するトークン上限だけに基づいて、コンテキスト戦略を選ばないでください。代表的な本番ワークロードでテストし、コンテキスト長の増加に伴う応答品質、検索精度、レイテンシー、トークン使用量、コスト、失敗率を測定しましょう。
より多くのコンテキストを与える、取得する箇所を減らす、会話履歴を要約する、検索と要約を組み合わせるといった戦略を比較してください。100万トークンのコンテキストウィンドウを持つモデルは技術的にはアプリケーションをサポートできるかもしれませんが、より小さく慎重に検索されたプロンプトの方が、低コストで高速かつ正確な結果を出せる場合があります。
スケーラブルな言語ソリューションにはElevenAgentsを
コンテキスト管理が最も重要になるのは会話型エージェントです。会話を自然に感じられる速度で応答しながら、現在の発話、以前のターン、ビジネス上の指示、顧客情報、ナレッジベースのコンテンツ、ツールの結果を組み合わせる必要があります。
ElevenAgentsは、AI音声エージェントを構築・デプロイするために、これらの要素を1つのプラットフォームに集約します。そのオーケストレーションエンジンは、音声認識、LLM、テキスト読み上げを連携させ、デベロッパーはプロンプト、ナレッジベース、ツール、ワークフロー、基盤となる言語モデルを設定できます。エージェントが音声で感情的な文脈を伝える方法を含む表現豊かな話し方は、そもそもエージェントが何を話すかを形作るのと同じコンテキストに依存します。
ナレッジ管理については、ElevenAgentsはフルコンテキストドキュメントとRAGの両方をサポートしており、プラットフォーム上で直接設定できます。小さなドキュメントはエージェントのプロンプトに直接入るため、その内容は会話全体を通じて利用できます。大規模なナレッジベースは代わりにインデックス化され、すべてを一度にコンテキストウィンドウへ読み込むのではなく、RAGがクエリごとに関連する箇所を取得します。
ElevenAgentsに登録して今すぐ始めるか、チームに相談することで、デプロイの選択肢をご確認いただけます。
