100万トークン超の長文脈モデル、どう使うか
かつてLLMは「数ページまでしか一度に読めない」のが常識だった。だが今、コンテキスト窓が100万トークン、あるいは200万トークンを超えるモデルが実用段階にある。書籍数十冊分、数時間の映像、あるいは巨大なコードベースを「丸ごと一度に」読み込めるこの能力は、AIの使い方そのものを変えつつある。本稿では、長文脈モデルの仕組みと、具体的に何ができるようになったのかを整理する。
1. 長文脈モデルとは何か
LLMが一度に処理できる入力の長さは「コンテキスト窓（コンテキストウィンドウ）」と呼ばれる。これはモデルが「短期記憶」として保持できるトークンの上限だ。トークンはモデルが扱う最小の意味単位で、日本語では1文字から数文字が1トークンになることが多い。従来のモデルは数万トークン（論文数本やチャットの履歴程度）が限界だったが、2024年以降、100万トークン超を備えるモデルが相次いで登場した。100万トークンは、日本語の書籍にしておおよそ数十冊、あるいは数時間分の会議の書き起こしに相当する。
なぜ「長さ」が能力になるのか
コンテキストが長いということは、単に「たくさん読める」だけではない。モデルは窓の中のすべての情報を横断して参照できるため、冒頭の事実と末尾の記述を結びつけたり、数千行先のコードとの整合を取ったりできる。つまり「文脈の長さ」そのものが、モデルが扱える問題の複雑さを決める。
- 100万トークン：書籍数十冊、コード数万行、数時間の書き起こし
- 200万トークン：半日の映像、企業の全社則、巨大リポジトリ全体
- 1000万トークン級：限定的だが、手元のオープンモデルでも到達
「長さは、モデルにとって新しい種類の知能だ。」窓が広がるたび、これまで分割して扱っていた問題が一つのプロンプトで扱えるようになる。
2. 仕組み：どうやって長くするのか
コンテキストを長くするには、単にモデルを大きくするだけでは足りない。計算コストや、情報が遠くなるほど参照が疎かになる「なが距離忘却」の問題を乗り越える必要がある。主なアプローチを三つ挙げる。
効率化アテンションと位置符号化
Transformerの核心であるアテンションは、トークン数の二乗に比例して計算量が増える。これを抑えるため、スライディングウィンドウや線形近似といった「効率的アテンション」が使われる。同時に、入力位置をモデルに教える「位置符号化（RoPEなど）」を長い範囲まで拡張し、学習時には見たことのない長さにも対応できるようにする。ここが長文脈の要だ。
段階的拡張と「必要なときだけ注目」
学習済みのモデルに対し、短い文脈から徐々に長い文脈へと継続学習（ロングコンテキスト微調整）を行う手法が一般的だ。また、すべてのトークンを等しく見るのではなく、重要な箇所にだけ注意を集中させる「スパースアテンション」で、実用上の長さと速度を両立させている。
キャッシュと圧縮の現実解
実運用では、同じ長文を毎回再送するのを避ける「プロンプトキャッシュ」が鍵になる。一度読み込んだ文書をキャッシュとして保持し、以後の質問はそこへの参照だけで済ませる仕組みだ。これにより、初回こそ重いが継続利用のコストを大きく下げられる。一部モデルは自動で要約圧縮も行い、窓の限界ぎりぎりまで情報を詰め込む。
3. 何ができるようになったか
長文脈モデルが実用になると、従来は「分割して前処理」していた作業が一発で済むようになる。代表的な活用法を四つ挙げる。
文書・コードベースの丸ごと読み込み
企業の社内規定一式や、数万行のコードリポジトリをそのまま入力し、「この関数とあの仕様書の記述は矛盾していないか」と問うことができる。RAG（検索拡張）で拾い漏らしを気にする必要が減り、モデル自身が全文を俯瞰して答えを出す。
長時間メディアの一括要約
数時間の会議動画や、一日分の顧客対応ログを一つのプロンプトで処理し、「誰がどの懸念を何回口にしたか」を時系列で抽出する。映像・音声をまたいだ長期の文脈理解は、Gemini 2.5の100万〜200万トークン級や、Llama 4 Scoutの1000万トークン級が牽引している。
- 書籍全体からの一貫した要約・引用
- コードベース全体への横断的な質問
- 数時間の音声・映像の一括解析
- 法規・契約の網羅的な矛盾チェック
「前編を覚えておいて」と分割管理しなくて済む。長文脈こそが、AIとの対話から「丸ごと把握」への転換を意味する。
長期対話とエージェントの記憶
エージェントが長時間タスクをこなす際、これまでのやり取りを丸ごと窓に保持できるため、外部メモリへの逐次保存・検索の手間が減る。数日分の対話履歴を一度に参照し、方針のブレを防ぐ用途にも向く。
4. 限界と注意点
長くなったからといって、すべてが魔法のように解決するわけではない。押さえておくべき落とし穴が三つある。
「長いほど賢い」わけではない
実際には、窓の後半（入力の初めや終わり）ほど情報が正しく反映されやすく、真ん中の情報がおろそかになる「ロストインザミドル」現象が知られる。長文を入れても、肝心の箇所が埋もれることがある。
コストと速度
トークン数が増えると、処理にかかる計算量と料金、そして応答までの時間は確実に伸びる。100万トークンを毎回丸ごと投げるのは、小さな質問でも高くつく。使い分けが設計の鍵になる。
- ロストインザミドル：中ほどの情報が弱くなる
- 課金・遅延：長さに比例して増大する
- 精度のばらつき：長さが極端だとベンチが落ちる場合も
5. 実務での使い分け
長文脈モデルを活かすには、適材適所の選択が決め手になる。まずは「本当に全文が要るか」を問い、要るなら長文脈へ、部分的で済むならRAGや要約の前処理へ回す。クラウドの100万トークン級（Gemini 2.5など）と、手元で動くオープン長文脈（Llama 4 Scoutなど）を、機密性とコストで使い分けるのが2026年現在の定石だ。
「長く読める」は手段であって目的ではない。読ませたい情報を正しく届ける工夫こそが、長文脈活用の本質だ。
まとめ
100万トークン超の長文脈モデルは、書籍数十冊や数時間の映像、巨大なコードベースを「一度に丸ごと」扱えるようにした。その鍵は、窓を広げる拡張と、遠くの情報も正しく引ける効率化アテンションの両立にある。活用法は文書・コードの一括解析、長時間メディアの要約、エージェントの長期記憶へと広がる一方、ロストインザミドルやコスト増という限界も現実だ。長文脈は「何でも入れればいい」ではなく、本当に要る情報を正しく届ける設計が問われる。