Context Window

LLMに長い契約書を丸ごと渡して「リスク条項を洗い出して」と頼んだら、「入力が長すぎます」とエラーが返ってきた――こんな経験はないでしょうか。コンテキストウィンドウとは、LLMが一度の処理で扱える入力と出力を合わせたトークン数の上限のことで、モデルが「同時に見渡せる範囲」を決定します。

入力と出力の合計で消費される

コンテキストウィンドウは「入力トークン＋出力トークン」の合計で消費されます。128Kトークンのモデルに100Kトークンの文書を渡すと、回答に使えるのは残り28Kトークンです。長い入力を扱う際は、期待する出力の長さも計算に入れる必要があります。日本語は1文字が概ね1〜2トークンに相当するため、英語と比べてトークン効率がやや悪い点にも注意が必要です。APIの料金はトークン数に基づくため、コンテキストウィンドウの使い方はコストにも直結します。

2Kから100万トークンへの急拡大

コンテキストウィンドウの拡大は驚異的なペースで進みました。2020年のGPT-3はわずか2,048トークン（日本語で約1,000文字）でした。2023年にGPT-4が8K→32K→128Kと拡張され、同年AnthropicのClaudeが100Kトークンで話題になりました。2024年にはGoogleのGemini 1.5 Proが100万トークンを実現し、これは書籍約10冊分に相当します。2025年にはClaude 3.5が200Kトークン、Gemini 2.0が200万トークンまで拡張されました。この拡大を支えたのは、FlashAttentionなどの効率的なアテンション計算手法や、RoPE（Rotary Position Embedding）のスケーリング技術です。

Lost in the Middle問題

コンテキストが大きくなれば万事解決というわけではありません。2023年のStanfordの研究で、入力の先頭と末尾の情報はよく活用されるが、中間部分は見落とされやすいという「Lost in the Middle」問題が指摘されました。たとえば、20件の文書を入力してQ&Aを行うと、正解情報が10番目付近に位置するときに精度が最も低下します。この問題への対策として、重要な情報を先頭か末尾に配置する、チャンク分割して順番を工夫する、あるいは複数回に分けてクエリを投げるなどの実務的なテクニックが使われています。

実務での活用戦略

コンテキストウィンドウの大きさは、LLMの活用パターンを根本的に変えます。短いウィンドウの時代には、RAG（検索拡張生成）で関連文書だけを検索・挿入する手法が必須でした。100K以上のウィンドウが使える現在では、契約書の全文レビュー、コードベース全体の分析、複数論文の横断比較がワンショットで可能です。ただし、コンテキストが長いほど推論コストは増大し、応答速度も低下します。実務では「長いコンテキストにすべて詰め込む」方式と「RAGで必要部分だけ抽出する」方式を、タスクの特性・コスト・精度のバランスに応じて使い分けることが重要です。