Claude 200K、GPT 128K、Gemini 2M──モデル選びはコンテキスト窓で決まる
主要LLMのコンテキストウィンドウを横並びで比較。窓の大きさが何を意味するのか、Lost in the Middle問題、RAGとロングコンテキストの使い分けまで、設計判断に直結する観点を整理します。
「この長文PDF、ChatGPTで読ませたい」「社内ドキュメント全部Claudeに食わせたい」── LLM を業務で使い始めると、まず最初にぶつかるのが 「どのモデルがどれだけ長文を読めるか」 という問題です。
主要LLMの公称コンテキスト窓は、
- Claude 4 系（Opus/Sonnet/Haiku）：200K（約15万単語 / 約20万字日本語）
- GPT-4o：128K（約9.6万単語）
- OpenAI o系（推論モデル）：200K
- Gemini 2.5 Pro：2M（約150万単語 / Claude 4の10倍）
- Gemini 2.5 Flash：1M
- Llama 4 (Scout)：10M（公称、実効は条件次第）
数字だけ並べると Gemini や Llama 4 の圧勝ですが、「窓が大きい＝そのモデルが優位」とは限らないのが実態です。
この記事では、コンテキスト窓の意味、Lost in the Middle 問題、RAGとロングコンテキストの使い分けまで、エンジニアが知っておくべき設計観点を整理します。
コンテキスト窓とは
LLMが一度に処理できる入力＋出力の最大トークン数のこと。「200K トークン」というのは、英語で約15万単語、日本語で約20万字を一気に読ませられる量です。
サイズ感のイメージ：
| サイズ | 何に相当するか |
|---|---|
| 100 tok | ツイート1本 |
| 1.5K tok | ブログ記事1本 |
| 5K tok | A4 PDF 5-10ページ |
| 60K tok | ペーパーバック1冊 |
| 200K tok | 長編小説1冊（指輪物語 第1部 約18万語） |
| 750K tok | 聖書（旧+新約） |
| 2M tok | ハリポタ全7巻（英語原書合計） |
| 10M tok | 大百科事典クラス |
つまり Claude/GPT の 200K は「書籍1冊まるごと」、Gemini の 2M は「ハリポタ全巻」、Llama 4 の 10M は「百科事典クラス」。
Lost in the Middle 問題
「窓が大きければ大きいほど良い」と思いきや、現実はもう少し複雑です。LLM には Lost in the Middle（中盤の情報が抜けやすい）と呼ばれる傾向があります。
長いコンテキストの 前半（冒頭） と 後半（末尾） に書いた情報には強く反応する一方、中盤 に埋めた情報はモデルが見落としやすい。
スタンフォード／プリンストン／UCバークレーらの研究（Liu et al., 2023）で実証されており、本質的に注意機構（attention）が均等に分散しないことが原因です。
つまり：
- 20K の文脈で「中盤の情報」を質問 → 高精度で答える
- 200K の文脈で「中盤の情報」を質問 → 精度が落ちる
- 2M の文脈で「中盤の情報」を質問 → 大幅に落ちる
「Gemini 2M なら社内ドキュメント全部食わせれば良い」が必ずしも正解にならないのは、この性質のためです。
RAG vs ロングコンテキスト、どっち？
ここから設計判断の話です。長文を扱う2つのアプローチ：
A. ロングコンテキスト型
全文をモデルに渡し、その中から関連箇所を探させる。
- 利点：実装が単純、コードが短い
- 難点：トークン代が高い、Lost in the Middle、推論時間が長い
- 向く用途：1度きりの読解（契約書チェック、論文要約、PDF Q&A）
B. RAG（Retrieval-Augmented Generation）型
埋め込みベクトルで関連箇所だけ検索し、必要な部分だけモデルに渡す。
- 利点：トークン代が安い、精度が高い、文書が増えても伸びる
- 難点：埋め込みインデックスの構築・保守が必要
- 向く用途：何度も繰り返し参照する大量文書（社内Wiki、製品マニュアル、コードベース）
判断のフレームワーク
| 質問 | YES なら |
|---|---|
| 同じドキュメントに何度もアクセスする？ | RAG |
| ドキュメントが10MB以上ある？ | RAG |
| 全文を一度に把握させたい？（要約・翻訳・整合性確認） | ロングコンテキスト |
| 1回の利用で完結する？（その場限りの読解） | ロングコンテキスト |
| 検索の精度が業務クリティカル？ | RAG |
| プロトタイプ・実験段階？ | まずロングコンテキスト |
実務では「最初はロングコンテキストで動かして、需要が見えたらRAGに移行」というロードマップが現実的です。
モデル別の使い分け
Claude 4 シリーズ（200K）
- 文書理解・コーディング・推論で総合力が高い
- 200K は「書籍1冊・PRレビュー1回」にちょうどよい
- Opus は最上位、Sonnet が日常用途、Haiku は速く安い
GPT-4o（128K）
- マルチモーダル（画像・音声）が強み
- 128K でカバーできない長文は分割が必要
- API は安価・速い
OpenAI o1 / o3（200K）
- 推論モデル：考えるステップを内部で展開
- 数学・コード・複雑な多段推論で強い
- 出力トークン上限が大きい（10万）ので、長い回答が出せる
Gemini 2.5 Pro / Flash（1-2M）
- 超ロング窓が最大の差別化
- 動画・画像との同時処理が強い
- Flash は速くて安いので、要約・分類タスク向き
Llama 4 (Scout)（10M）
- オープンウェイト
- 公称10Mだが、推論プロバイダ・量子化・GPU構成で実効値は変動
- セルフホスト前提なら強力
出力トークンも忘れないで
コンテキスト窓は 入力＋出力の合計 が上限です。例えば、
- Claude Sonnet 4.6：入力 200K + 出力最大 64K（合わせて200K）
- GPT-4o：入力 128K + 出力最大 16K
- o1：入力 200K + 出力最大 100K（推論モデルなので回答が長い）
「200K 全部を入力に使うと、出力できない」ので、実務では入力 195K + 出力 5K ぐらいの配分で設計します。長い回答を期待するなら o1/o3 系、要約や分類なら Claude/GPT で十分。
トークン数の実測と最適化
「自分の文書は何トークンか？」を実測するには：
- トークンを整える ─ GPT/Claude/Gemini の各 tokenizer で計測
- プロンプトを整える ─ ゼロ幅スペース・連続空白を除去してトークン節約
- コンテキスト窓を整える ─ 各モデルの窓に入るか視覚比較
- 埋め込みサイズを整える ─ RAG設計時のベクトル容量見積もり
これらを順に使うと、**「自分の用途にどのモデルで十分か」「RAG が必要か」**が30分で判断できます。
まとめ
- 主要LLMのコンテキスト窓：Claude/o系 200K、GPT-4o 128K、Gemini 1-2M、Llama 4 10M
- 「窓が大きい＝優位」ではない。Lost in the Middle で中盤が抜ける
- RAG vs ロングコンテキスト は「同じ文書に何度もアクセスするか」で判断
- 出力トークン上限も合算で上限になる
- ツールチェイン：トークン → プロンプト整形 → コンテキスト比較 → 埋め込み
LLM の選定は「窓のサイズ」よりも「自分のユースケースが Lost in the Middle に弱いか / RAG にすべきか」で先に決めると、最初の判断が早く、後戻りが少なくなります。
