コンテキスト長の拡大は万能ではありません。長文脈LLMには「入力できること」と「正確に使えること」の間にギャップがあり、実務ではRAGとの組み合わせが現実的な最適解となるケースが多々あります。本記事では、100万トークンに到達した長文脈LLMを支える要素技術、その実力を測るベンチマーク、RAGとの戦略的使い分け、そしてコスト対効果の観点から、長文脈を「手段」として賢く扱うための指針を解説します。
コンテキスト長の進化――4Kから100万トークンへ
LLMのコンテキスト長は、わずか数年で500倍以上に拡大しました。GPT-3の2Kトークンからスタートし、GPT-4で8K〜32K、Claude 2で100K、そしてGemini 1.5 Proが1Mトークン(研究用途では10Mまで)を実現しました。これは単なる定量的拡張ではなく、文書レビュー、コードベース理解、多段階推論といった新しいユースケースを切り拓くパラダイムシフトです。
| モデル | コンテキスト長 | 公開時期 | 備考 |
|---|---|---|---|
| GPT-3 | 2,048 | 2020年 | 初期Decoder-only |
| GPT-3.5 / GPT-4 | 4K〜32K | 2022-2023年 | 段階的拡張 |
| Claude 2 | 100,000 | 2023年 | 最初の大規模長文脈 |
| GPT-4 Turbo | 128,000 | 2023年11月 | 実用的な長文対応 |
| Claude 3 / 3.5 | 200,000 | 2024年 | Opus/Sonnet/Haiku |
| Gemini 1.5 Pro | 1,000,000〜10M | 2024年 | MoEとRing Attention |
| GPT-4o | 128,000 | 2024年 | マルチモーダル統合 |
注目すべきは、単純にAttention計算を大きくしたわけではなく、位置エンコーディング、アテンションの疎行列化、KVキャッシュの圧縮、分散実行など、複数のアルゴリズム的進化が組み合わさっている点です。
長文脈を実現する技術
Position Encodingの拡張(RoPE、ALiBi、YaRN)
長文脈の鍵は位置情報の扱いです。Su et al. (2021) のRoPE(Rotary Position Embedding)は、埋め込みを位置に応じて回転させることで相対位置情報を自然に導入します。ベースとなる回転行列は以下で与えられます。
$$R_{\theta, m} = \begin{pmatrix} \cos m\theta & -\sin m\theta \\ \sin m\theta & \cos m\theta \end{pmatrix}$$
ALiBiは学習可能な埋め込みを使わず、Attention Scoreに位置差に比例した線形バイアスを加えるシンプルな手法です。YaRN(Peng et al., 2023)はRoPEの周波数を動的にスケーリングし、学習時より長い文脈への外挿性能を向上させます。これらの手法により、学習時4Kだったモデルを追加学習で32K〜128Kへ拡張することが実現可能となりました。
Sparse Attention / Sliding Window Attention
Full Attentionの計算量は$O(N^2)$と系列長に対し二乗で増加します。Sparse Attentionは一部のトークンペアのみに注意を向け、計算量を線形〜準線形に削減します。Longformerのsliding windowやBigBirdの global+random attentionが代表例で、局所性と大域性のバランスを取る設計が工夫の焦点です。
KV Cacheの圧縮技術
推論時のボトルネックとなるKV Cacheは、長文脈ではGB単位のメモリを要します。GQA(Grouped Query Attention)やMQA(Multi-Query Attention)はキー・バリューを複数ヘッドで共有することでメモリを削減し、H2OやStreamingLLMはAttentionスコアに基づいて不要なトークンを退避(eviction)させます。
Ring Attention / Sequence Parallelism
Ring Attention(Liu et al., 2023)は系列を複数デバイスに分割し、リング状にKey/Valueを転送しながらAttentionを計算する分散技術です。メモリ制約を超えた長系列を単一モデルで扱えるため、Gemini 1.5の1Mトークンを支える基盤技術の一つとされています。
【Full Attention vs. Sparse Attention パターン】
Full Attention (O(N^2))
Q\K t0 t1 t2 t3 t4 t5 t6 t7
t0 [X X X X X X X X]
t1 [X X X X X X X X]
t2 [X X X X X X X X]
t3 [X X X X X X X X]
...
Sliding Window (w=2) + Global Token (t0)
Q\K t0 t1 t2 t3 t4 t5 t6 t7
t0 [X X X X X X X X] (global)
t1 [X X X . . . . .]
t2 [X X X X . . . .]
t3 [X . X X X . . .]
t4 [X . . X X X . .]
...
※ X = attends, . = masked
※ Sparse化により O(N*w) まで計算量削減「Needle in a Haystack」問題――長文脈の実力テスト
入力できるコンテキスト長と、実際に活用できるコンテキスト長は別物です。Needle in a Haystack（NIAH）は、長い文書の任意の位置に「針」となる短い情報を埋め込み、モデルがそれを正確に取り出せるかをテストするベンチマークです。Gemini 1.5 Proは1MトークンでもほぼNIAHを解けることが示されていますが、これは単一情報の位置検索に限られます。
より実践的な問題として、Liu et al. (2023)「Lost in the Middle」は、長文脈でも文書の中央付近の情報が大幅に見落とされる現象を報告しました。モデルは開始部と末尾を強く重視し、中間部の情報検索精度が明確に落ちます。したがって、長文脈LLMを使う際は、重要情報の位置を意識的に設計する必要があります。
| モデル | NIAH精度(32K) | NIAH精度(128K) | NIAH精度(1M) | Lost in the Middle影響度 |
|---|---|---|---|---|
| GPT-4 Turbo | 99% | 95% | N/A | 中 |
| Claude 3 Opus | 99% | 98% | N/A | 小 |
| Gemini 1.5 Pro | 99% | 99% | ~99% | 小 |
| Llama 3.1 70B | 97% | 90% | N/A | 中〜大 |
| 一般的なOSSモデル(8K拡張) | 85% | 60% | N/A | 大 |
import random
def build_niah_prompt(haystack_tokens, needle, depth=0.5):
"""NIAHテストの入力を構築"""
n = len(haystack_tokens)
insert_pos = int(n * depth)
prompt_tokens = (
haystack_tokens[:insert_pos]
+ needle.split()
+ haystack_tokens[insert_pos:]
)
question = "What is the secret number mentioned in the text?"
return " ".join(prompt_tokens) + "\n\n" + question
def run_niah(llm, haystack, needle, depths):
results = {}
for d in depths:
prompt = build_niah_prompt(haystack.split(), needle, depth=d)
answer = llm.generate(prompt)
results[d] = needle.split()[-1] in answer
return results実装上の注意点として、NIAHは単一針の検索に特化しているため、複数情報の同時追跡や長大な推論連鎖を要するタスクでの性能は別途評価する必要があります。近年はRULER、LongBench、InfiniteBenchなど、より複雑な長文脈タスクを含むベンチマークが整備されつつあります。
長文脈 vs. RAG――どちらを選ぶべきか
長文脈LLMとRAGは、しばしば二者択一の議論に陥りますが、本質的には補完的な関係にあります。長文脈は「全文を直接モデルに渡す」アプローチ、RAGは「関連部分を検索して渡す」アプローチです。両者はコスト、レイテンシ、精度特性が異なります。
| 項目 | 長文脈LLM | RAG |
|---|---|---|
| コスト構造 | 毎回全文入力で高コスト | 検索+限定入力で低コスト |
| 精度（局所情報） | 中（Lost in the Middle） | 高（関連部分にフォーカス） |
| 精度（全体理解） | 高（全体を見渡せる） | 中（検索精度に依存） |
| レイテンシ | 高（数秒〜数十秒） | 中（検索+生成） |
| 実装複雑度 | 低（API単体） | 中〜高（検索基盤必要） |
| データ更新への追従 | 都度全量再入力 | インデックス更新のみ |
| 適するユースケース | 文書横断分析・コードレビュー | FAQ・ナレッジ検索 |
使い分けのフレームワークとしては、(1) 文脈の依存構造が密で全体理解が必要か、(2) 情報が分散しておりピンポイント検索で足りるか、(3) データ更新頻度とコスト制約はどうか、の3点を軸に判断します。契約書の全文レビューは長文脈、社内ナレッジ検索はRAG、というのが基本形です。両者を組み合わせるハイブリッドアプローチ(RAGで絞り込んだ上で長文脈モデルに流し込む)も有効です。
実務での長文脈活用パターン
長文脈LLMが真価を発揮する代表的なユースケースを整理します。
1. 長文書レビュー：契約書、目論見書、論文全文など、部分抽出では文脈が失われる文書の分析に最適です。条項間の相互参照や前提条件の追跡が可能な点がRAGには真似できません。ただし重要情報は文書の先頭・末尾に置くか、システムプロンプトで明示的に参照させる工夫が必要です。
2. コードベース全体の理解と修正：モノレポや中規模リポジトリ全体を一括入力し、リファクタリング提案やバグ検出を行うケースです。依存関係の追跡が一貫するため、ファイル単位の部分コンテキストより高品質な結果が得られます。
3. 複数文書の横断的な比較分析：競合他社のIR資料や学術論文群を一括で入力し、論点比較や整合性チェックを行います。RAGでは個別検索になるため、横断的な「差分抽出」には長文脈が圧倒的に有利です。
4. コンテキスト内Few-shot学習：大量の例示をコンテキストに詰め込むmany-shot in-context learningは、ファインチューニング不要で精度を押し上げる手段として注目されています。数百〜数千サンプルを一度にロードできる長文脈モデルの強みが活きる領域です。
ビジネスへの示唆――長文脈のコスト対効果
長文脈は強力ですが、コストは直線的に増加します。入力トークン単価を$p$、入力トークン数を$T$とすると、1リクエストあたりのコストは$\text{Cost} = p \cdot T$で近似でき、100万トークンを毎回入力すると数ドル規模に達します。高頻度で同じ文書を参照するワークロードではプロンプトキャッシュが必須です。
コスト最適化戦略として、(1) 同一コンテキストへの反復クエリはプロンプトキャッシュで95%削減、(2) 一次検索をRAGで絞り込んでから長文脈に流す、(3) 文書をセクションごとに前処理してインデックス化、などが実務的です。「とりあえず全部入れる」アプローチは短期的なPoCでは許容できても、本番運用では必ずコストが破綻します。
経営観点では、長文脈を活用する業務の1件あたりコストと、それによって削減される人件費・リスクを天秤にかける視点が不可欠です。高単価な専門職（法務・M&A・研究）の時間短縮には十分合理的ですが、定型大量処理には不向きです。
まとめ――長文脈は「手段」であり「目的」ではない
- コンテキスト長は4Kから1Mへ、500倍以上拡大しましたが、使いこなしは別問題です
- RoPE・Sparse Attention・KV圧縮・Ring Attentionなど複数の要素技術の組み合わせで実現されています
- NIAHは解けてもLost in the Middleや複数情報追跡では依然課題があります
- 長文脈とRAGは補完的な関係で、文書構造とコスト制約に応じた使い分けが必要です
- プロンプトキャッシュやRAG併用なしの「全部入れる」戦略はコスト的に破綻します
DE-STKでは、長文脈LLMとRAGの戦略的使い分けを含む、日本企業向けのLLMアーキテクチャ選定とデータ基盤設計をご支援しています。PoC段階からのコスト設計、ベンチマーク実施、本番運用パターンまで、実務に根ざしたコンサルティングを提供しています。
よくある質問(FAQ)
Q. 長文脈LLMとRAGはどちらが良いですか?
A. 用途によります。全体の文脈理解が必要な場合は長文脈LLM、大量の文書から特定情報を検索する場合はRAGが適しています。コスト面ではRAGが有利なケースが多く、両者を組み合わせるハイブリッドアプローチも有効です。
Q. 100万トークンのコンテキストは本当に全部使えますか?
A. 入力は可能ですが、精度面では課題があります。「Lost in the Middle」問題により、文脈の中間部分の情報が見落とされやすい傾向があり、コンテキスト長全体を均一に活用できるわけではありません。NIAHのような単一情報取り出しは解けても、複雑な多段推論では性能低下が見られます。
Q. 長文脈LLMの利用コストはどのくらいですか?
A. 入力トークン数に比例するため、100万トークンを毎回入力すると1回あたり数ドルのコストが発生する場合があります。プロンプトキャッシュ等のコスト削減手段の活用や、必要に応じたRAGとの併用が重要です。