LLMの100万トークンはなぜ使いこなせない？長文性能とKVキャッシュの正体【2026年版】

---

100万トークン対応とは、100万トークンを正確に理解できるという意味ではない。

大きなコンテキストウィンドウは、大きな机を持っているというだけである。必要な資料を探し、矛盾を整理し、素早く答えを返せるかは別の性能で決まる。

資料を「まとめて全部入れればよい」と考えているなら、見直すべきなのはモデルだけではない。長文LLMを使いこなす鍵は、何を渡し、何を探させ、何を記憶させるかを設計する力である。

100万トークンの机に、300ページの資料を置いてみた

「入力できる」と「正確に使える」の間には、思った以上に大きな距離がある。

経営会議を控え、三浦ナオは300ページを超える市場調査、顧客ヒアリング、契約書、技術仕様書をLLMへ読み込ませました。使用したモデルは、100万トークン級の長いコンテキストに対応しています。

「これなら、全部まとめて扱える」――そう考えていたのです。

最初の回答は的確でした。市場分析も競合評価も、提案の方向性も大きく外していません。

ところが最終確認で、契約書の中央にあった重要な解約条件が、提案書から抜け落ちていることに気づきます。

追加で確認すると、今度は別の資料に書かれた古い条件を根拠として答えました。質問を重ねるほど回答開始までの待ち時間も長くなり、会話の前半で決めた前提まで揺らぎ始めます。

「100万トークンも入るのに、なぜ重要なことを見落とすのだろう」

あなたやあなたのチームでも、同じような違和感を覚えたことはないでしょうか。

GoogleのGemini API公式ガイドでは、100万トークン以上のコンテキストを扱えるモデルが案内されています。一方、長文中から一つの情報を探す課題と、複数情報を探して結びつける課題では難しさが異なります。また、入力が長いほど、最初のトークンが返るまでの時間も一般に長くなります。

コンテキストサイズは「処理できる上限」であって、長文理解力・正確性・応答速度の保証書ではありません。

「入る・探せる・考えられる・速く返せる」は別の性能

最大コンテキスト長だけを見ても、実際の長文性能や使い勝手は判断できない。

コンテキストウィンドウとは何か

コンテキストウィンドウとは、LLMが一回の処理で参照できる入力、指示、会話履歴、生成中の出力などが収まる作業領域です。

100万トークン対応であれば、形式上は非常に長い情報を入力できます。しかし、その全範囲から情報を同じ精度で見つけ、複数箇所を結びつけて判断できるとは限りません。

コンテキストウィンドウの大きさは作業机の広さです。資料を探す力、読み解く力、処理する速さまで同じ数字で表しているわけではありません。

長文中から一つの文字列を見つけられても、離れた場所にある複数の条件を組み合わせて判断できるとは限りません。

長文評価ベンチマークのRULERは、単純な情報検索だけでなく、複数情報の追跡や集約を評価します。LongBench v2も、複数文書、長い会話、コード、構造化データなど、現実に近い長文推論の難しさを扱います。

「100万トークン対応」と「100万トークンを使った複雑な判断が得意」は、同じ意味ではないのです。

長文で回答品質が落ちる5つの理由

長文の問題は単純な容量不足ではなく、情報の位置・量・関係・矛盾から生まれる。

中央の重要情報が埋もれる「Lost in the Middle」

長文LLMには、文章の冒頭と末尾の情報を使いやすく、中央付近の情報を見落としやすい傾向があります。関連情報の位置を変えただけで回答性能が変化する現象は「Lost in the Middle」と呼ばれます。

モデルは改善を続けていますが、重要条件を数百ページの中央へ一度だけ置き、そのまま正確に拾ってくれることを前提にするのは危険です。

不要な情報が重要情報を薄める

質問と関係のない資料が増えるほど、LLMは重要情報と周辺情報を区別しなければなりません。人間でも、10枚から条件を探す場合と1,000枚から探す場合では負担が違います。

入力できるからといって、入力した方がよいとは限りません。

古い情報と新しい情報が衝突する

旧価格と新価格、改訂前後の契約条件、検討案と正式決定が同時に入ると、LLMが古い情報を根拠にする可能性があります。文書の日付、版、優先順位を利用者側で明示する必要があります。

複数箇所を結びつける必要がある

解約条件を一つ探す質問より、解約条件、最低利用期間、海外拠点の例外を組み合わせて契約リスクを判断する質問の方が難しくなります。必要なのは検索だけでなく、長文をまたぐ推論能力です。

会話履歴そのものがノイズになる

長い会話には、否定済みの仮説、訂正前の数字、雑談、重複した説明も残ります。古い前提と新しい指示が競合すれば、現在の目的が埋もれます。

ここまでの原因は、どれも「AIが何を参照し、何を残しているか」に関係します。ところが、パラメータ、会話履歴、RAG、KVキャッシュは、同じ「記憶」と呼ばれていても役割が異なります。

LLMの「記憶」は一つではない

パラメータ、コンテキスト、RAG、KVキャッシュ、物理メモリは異なる役割を持つ。

利用者は、Attentionの数式や半導体回路まで覚える必要はありません。ただし、次の違いを知っていると、問題が起きた場所を判断しやすくなります。

パラメータはモデルが学習で身につけた能力であり、一度に読める量ではありません。パラメータ数が多くても、最新情報、長文理解、応答速度が自動的に優れるわけではありません。

RAGは外部文書から必要な部分を探し、LLMへ渡す仕組みです。コンテキストが「机に置ける量」なら、RAGは「書庫から資料を選ぶ仕組み」です。100万トークン対応でも、大量かつ更新頻度の高い文書にはRAGが有効です。詳しくはRAG完全ガイドをご覧ください。

HBMやSRAMは、重みや一時データを物理的に置く場所です。一般利用者が細かなメモリ階層を比較する必要はありませんが、長いコンテキストの性能が、記憶容量とデータを運ぶ速さにも左右されることは押さえておくべきです。半導体ごとの設計思想は、AI半導体とは？GPU・ASIC・FPGAの役割と選び方で整理しています。

なぜ長い資料を入れると反応が遅くなるのか

LLMは回答を書く前に入力を処理し、その後の生成で使う一時的な記憶を作る。

300ページの資料を渡すと、LLMは回答前に入力を処理し、内部表現とKVキャッシュを作ります。このPrefillは、入力が長いほど処理量も増えるため、短い質問より最初の回答まで時間がかかります。

KVキャッシュとは？AIが過去を読み直さないための一時メモ

KVキャッシュは過去の計算結果を保存し、次の一語を作るたびの再計算を減らす仕組みである。

KVキャッシュとは、前に計算したKeyとValueを、もう一度作り直さないための仕組みです。次の一語を生成するたびに過去トークンのKeyとValueを再計算せず、一度作った結果を再利用します。

机の比喩でいえば、KVキャッシュは、一度読んだページを毎回読み直さずに済むよう、要点を残しておく付箋です。

ただし、資料が長くなり、同時利用者が増えるほど付箋も増えます。その結果、GPUメモリ、メモリ帯域、同時に処理できるリクエスト数が圧迫されます。

関連用語は、記事後半の専門用語まとめでも確認できます。

KVキャッシュとPrompt Cachingの違い

KVキャッシュは、推論エンジン内部で使われる一時的な計算結果です。一方、Prompt CachingやContext Cachingは、同じ長い入力を複数のリクエストで再利用し、処理時間や入力コストを抑えるために提供される機能です。

両者は関連しますが、推論内部の仕組みと、利用者から見えるサービス機能という違いがあります。

症状から原因を見つける「長文LLM健康診断」

モデル変更の前に、問題がモデル・コンテキスト・インフラのどこで起きているかを切り分ける。

あなたが今使っているAIにも、次のどれかが当てはまっていないでしょうか。

一つの症状に、一つの原因しかないとは限りません。入力長、画像や表、高度な推論モード、サービスの混雑も影響します。

まず同じ質問を短い資料と長い資料で比較し、入力長によって症状が変わるか確認してください。

LLM利用者が今日からできる8つの対策

最も効果の大きい改善は、GPUを変えることではなく、AIへ渡す情報を設計し直すことである。

全資料を最初から投入しない

「念のため全部入れる」は避けます。最初に目次、文書名、更新日、要約を渡し、質問に必要な章だけを追加します。

最重要条件を冒頭へ集約する

制約、判断基準、禁止事項は、資料の中央に埋めず、冒頭へ整理します。資料の後には、具体的な質問を置きます。

抽出・矛盾確認・結論の順に進める

複数資料を扱う場合は、各資料から条件を抽出し、出典と日付を表にし、矛盾を確認してから結論を作らせます。「全部読んで判断して」より、途中の誤りを発見しやすくなります。

根拠となる箇所を示させる

文書名、章、ページ、該当箇所を示し、根拠がない項目は推測しないよう指示します。契約、法務、財務などの重要事項は、示された引用を原文で再確認します。

長くなった会話を要約して切り替える

目的、決定事項、未解決事項、禁止事項、使用資料、出力形式だけを要約し、新しい会話へ移します。市場調査と契約審査など、目的が異なる仕事も会話を分けます。

長いコンテキストとRAGを使い分ける

一つの文書全体や文章の流れを読む場合は長いコンテキスト、大量かつ頻繁に更新される文書から必要箇所だけを探す場合はRAGが向きます。

実務では、RAGで候補を絞り、少し長めのコンテキストで情報を統合する構成が有効です。

同じ資料を繰り返すならキャッシュを確認する

同じPDFや共通指示を繰り返す場合は、Prompt CachingやContext Cachingを確認します。キャッシュは精度を自動改善するものではなく、同じ入力の再処理を減らす機能です。

自社資料で実効性能を測る

公開ベンチマークだけで決めず、日常業務の資料で精度、待ち時間、根拠、料金を比較します。モデルの変更前後で同じ課題を使うことが重要です。

LLMを選ぶとき、どの性能を見ればよいのか

最大トークン数ではなく、自分の資料と質問で得られる実効性能を比較することが重要である。

自分でできる4つの実用テスト

1. 位置テスト：同じ重要条件を冒頭、中央、末尾へ置き、回答の違いを見る
2. 複数条件テスト：条件を複数文書へ分散し、すべてを使えるか確認する
3. 矛盾テスト：旧版と新版を混ぜ、日付と優先順位を判断させる
4. 入力方式テスト：全文投入、段階処理、RAG、事前要約を比較する

正解率だけでなく、待ち時間、料金、根拠の追跡しやすさも記録してください。

カタログ上のコンテキストサイズではなく、自社資料で測った結果が、そのモデルの実効コンテキスト性能です。

AIインフラの舞台裏では何が起きているのか

長文LLMの競争は、計算力だけでなく、一時記憶をどこに置き、再利用し、運ぶかの競争である。

ここからはサービス提供側の舞台裏です。三浦ナオが感じた「回答が始まるまでの長さ」は、この設計にも左右されます。

利用者は実装を覚える必要はありませんが、対策を「詰める・再利用する・小さくする・外へ逃がす・別の場所へ運ぶ」と理解すると、全体像が見えます。

PagedAttention：詰める

KVキャッシュを小さなブロック単位で管理し、必要な分だけ割り当てます。メモリの断片化を抑え、同じGPUで処理できるリクエストを増やしやすくします。

Prefix Caching：再利用する

同じシステム指示や長文資料を繰り返す場合、共通する先頭部分のKVキャッシュを再利用します。vLLMのAutomatic Prefix Cachingは、同じ文書へ複数の質問をする処理に適しています。

KVキャッシュ量子化：小さくする

KeyとValueをFP8などの低精度形式で保持し、メモリ使用量を減らします。vLLMはFP8 KVキャッシュをサポートしていますが、品質や速度への影響は、モデル、校正方法、ハードウェアによって異なります。

オフロードとPrefill／Decode分離：逃がす・運ぶ

KVキャッシュをCPUメモリやストレージへ逃がせば容量を広げられますが、転送が遅ければ新たなボトルネックになります。

NVIDIA DynamoのようにPrefillとDecodeを別のワーカーへ分ける設計では、両者を個別に拡張できる一方、高速なKVキャッシュ転送経路が重要です。

Vera Rubin：高速な置き場所と通信を増やす

NVIDIA Rubin GPUは、最大288GBのHBM4と最大22TB/秒のメモリ帯域を掲げています。

容量は、大きなモデル、長いコンテキスト、KVキャッシュ、高い同時実行数を支えます。帯域は、Decodeでモデルの重みやKV状態を読み出す速度に関わります。

長文推論では、演算性能だけでなく、記憶を置き、読み、運ぶ能力が重要です。競合との比較はNVIDIA Rubinと競合AIハードウェアの戦略比較、市場全体はAIインフラの未来展望で解説しています。

まとめ――大きな机より、必要な資料を選ぶ力

長文LLMを使いこなす競争は、コンテキストの大きさではなく、情報と記憶の設計をめぐる競争である。

経営会議を終えた後、三浦ナオは、最初にLLMへ渡した資料を開き直しました。そこには、今回の判断に不要な議事録、重複した市場データ、改訂前の契約書、検討中のメモまで含まれていました。

問題はAIの机が狭かったことではありません。必要な資料と不要な資料を区別せず、机の上へ積み上げていたことでした。

ナオは不要な議事録を外し、旧版と最新版を分け、重要条件を冒頭へ書き出しました。

整理後の資料で同じ質問をすると、回答から余計な枝葉が減り、要点と根拠が明確になりました。どの条件を拾い、何を見落としているかも確認しやすくなっています。

100万トークンは強力ですが、「何でも全部入れてよい」という許可証ではありません。

パラメータはAIが身につけた能力、コンテキストは今回の机、RAGは資料を探す司書、KVキャッシュは推論中の付箋、HBMはそれらを置く高速な作業場所です。

ナオの机は、最初から十分に広かったのです。変わったのは、その上に置く資料でした。今では、判断に本当に必要な情報だけが残っています。

最大コンテキスト長を見るだけでは、LLMの実力は分からない。何を渡し、何を探させ、何を記憶させるかを設計して初めて、長いコンテキストは価値へ変わるのです。

専門用語まとめ

長文LLMを利用するうえで、最低限押さえておきたい用語を整理する。

コンテキストウィンドウ

一回の処理でLLMが参照できる入力、指示、履歴、出力の範囲。

KVキャッシュ

過去トークンのKeyとValueを保存し、生成時に再利用する一時データ。

Prefill

入力を処理し、内部表現とKVキャッシュを作る段階。

Decode

KVキャッシュを参照しながら出力トークンを生成する段階。

RAG

外部文書から関連情報を検索し、LLMへ渡す仕組み。

HBM

GPUの近くに配置され、モデルの重みやKVキャッシュを保持する高帯域メモリ。

補足Q&A

長文LLMとKVキャッシュについて、特に誤解されやすい疑問を補足する。

Q1. 100万トークン対応なら、資料を全部入れた方が精度は上がりますか？

必ずしも上がりません。不要情報、重複、旧版、矛盾した指示が増えるほど、重要情報を選ぶ課題が難しくなります。必要な資料を絞り、日付と優先順位を明示してください。

Q2. KVキャッシュを削除すると、LLMは会話を忘れますか？

会話履歴そのものを忘れるわけではありません。KVキャッシュは推論を高速化する一時データです。破棄すると、同じ文脈を再び処理するときに再計算が必要になります。

Q3. 100万トークンのモデルがあれば、RAGは不要ですか？

RAGは不要にはなりません。一つの文書全体には長いコンテキスト、大量かつ更新頻度の高い文書にはRAGが向きます。実務では両者を組み合わせる方法が有効です。