はじめに

近年のLLMは、コンテキストウィンドウの拡大が著しく進んでいます。Claude は200Kトークン、Geminiは100万トークンを超えるなど、一見すると「長い文章もまるごと処理できる時代」が到来したかのようです。

しかし、コンテキストウィンドウが広くなったからといって、その中の情報すべてを均一に活用できるわけではありません。 LLMにはアーキテクチャに起因する構造的な弱点が存在し、入力が長くなるほどその影響が顕著になります。

この記事では、代表的な2つの問題「Lost in the Middle」と「Context Rot（コンテキストロット）」を中心に、LLMがなぜ長文で"迷子"になるのかを解説します。あわせて、Anthropic公式ドキュメントなどの知見をもとに、実務で使える対策も紹介します。

Lost in the Middle とは

Lost in the Middle は、2024年にLiu et al.が発表した論文¹で明らかにされた現象です。

LLMに複数の文書を入力して質問応答タスクを行わせると、正解の情報がどこに配置されているかによって精度が大きく変わることが分かりました。具体的には、入力の先頭や末尾に正解情報があると精度が高く、中間に配置されると精度が大幅に低下します。

この性能カーブはU字型を描きます。

Liu et al.の実験では、20件の文書を入力して質問に答えさせるタスクで、正解文書が中間にある場合、先頭にある場合と比べて20%以上精度が低下するケースが観測されています。

典型的に問題が発生するシーン

この問題は、特にRAG（Retrieval-Augmented Generation）で深刻です。検索で取得した複数のドキュメントをLLMに渡すとき、関連度順に並べると重要な情報が中間に埋もれてしまい、モデルがそれを見落とす可能性があります。

なぜ中間の情報が失われるのか ― Attention Sinkの仕組み

Lost in the Middleの根本原因の一つは、TransformerアーキテクチャのAttention Sink（注意の吸い込み）という現象です²。

Transformerの自己注意機構では、Softmax関数によって注意スコアの合計が必ず1になるよう正規化されます。ここで問題が生じます。現在のトークンにとって、過去のトークンの中に特に関連性の高いものがない場合でも、注意スコアをどこかに割り振らなければなりません。その「受け皿」になるのが、ほぼすべてのトークンから参照可能な先頭トークンです。

Attention Sinkにおける先頭トークンは、意味的に重要だから注意を集めているのではありません。Softmaxの正規化制約によって、余った注意スコアの"ゴミ箱"として機能しているだけです。実際、先頭トークンのValue（値）ベクトルはほぼゼロに近い大きさであることが確認されています。

興味深いことに、Softmax以外のAttention機構（たとえばSigmoid Attention）を使うと、Attention Sinkは発生しないことが報告されています³。このことからも、これがTransformerの構造に起因する問題であることが分かります。

コンテキストロット（Context Rot）とは

Context Rot は、Chroma Researchが2025年に公開した研究⁴で体系的に示された現象です。18の主要なLLM（GPT-4.1、Claude、Gemini 2.5、Qwen3など）を評価した結果、すべてのモデルで、入力トークン数が増えるにつれて性能が低下することが確認されました。

コンテキストロットの原因は大きく3つに分類されています。

原因	概要
Lost in the Middle	中間の情報へのアクセス精度が低下する
Attention Dilution（注意の希薄化）	トークンが増えると、各トークンに割り当てられる注意が薄まる
Distractor Interference（妨害情報の干渉）	トピックが似ているが無関係な情報が、ハルシネーションを誘発する

Chroma Researchの調査では、関連情報が中間に位置する場合、性能が30%以上低下するケースが報告されています。さらに、意味的に類似した無関係な情報（ディストラクター）が含まれると、ハルシネーションの発生率が顕著に増加します。

実務への影響と対策

これらの構造的問題を理解した上で、実務ではどのように対処すべきでしょうか。Anthropicの公式ドキュメントやエンジニアリングブログで紹介されているベストプラクティスを中心にまとめます。

1. 重要な情報の配置を工夫する

Anthropicの公式ドキュメント「Long context prompting tips」⁵では、以下のテクニックが推奨されています。

長い文書は先頭に配置し、質問や指示は末尾に置く
- 20K以上のトークンを扱う場合、クエリを末尾に配置するだけで応答品質が最大30%向上したと報告されています
XMLタグで文書を構造化する
- 複数文書を扱うとき、<document>タグで各文書を明確に区切ることで、モデルが情報の境界を認識しやすくなります
回答前に関連箇所を引用させる
- 「まず関連する箇所を引用してから回答してください」と指示することで、長い文書の中から的確な情報を抽出する精度が向上します

2. コンテキストエンジニアリングを実践する

Anthropicのエンジニアリングブログ「Effective context engineering for AI agents」⁶では、コンテキストウィンドウを有限な「注意の予算（attention budget）」として捉え、戦略的に管理する重要性が説かれています。

主なテクニックは以下の通りです。

コンパクション（要約による圧縮）: 会話がコンテキストの上限に近づいたとき、内容を要約して新しいコンテキストで再開する手法です。重要な意思決定や未解決の問題を保持しつつ、冗長な情報を削ぎ落とします
Just-in-Time Context: 必要になった時点で初めて情報をロードする手法です。ファイルパスやURLなどの軽量な参照だけを保持しておき、実行時にツールを使って動的にデータを取得します
サブエージェントによる分離: 詳細な調査をサブエージェントに委任し、結果だけを1,000〜2,000トークンの要約で受け取ることで、メインのコンテキストを圧迫しない構成にします

3. RAGのチャンキング戦略を見直す

RAGパイプラインにおけるチャンクサイズの選択も、Lost in the Middleの影響を軽減する重要なポイントです⁷。

チャンクサイズ: 256〜512トークンが多くのケースでのスイートスポット
オーバーラップ: 10〜20%（512トークンなら50〜100トークン）
セマンティックチャンキング: 意味的なまとまりで分割することで、検索精度が大幅に向上する（ベンチマークで最大70%の精度向上が報告されている）

取得した情報をLLMに渡す際も、重要度の高いチャンクを先頭と末尾に配置するといった工夫が効果的です。

まとめ

LLMのコンテキストウィンドウは急速に拡大していますが、「長く入力できる」ことと「長い入力を正しく活用できる」ことは別問題です。

Lost in the Middleは入力中間部の情報が失われるU字型の性能劣化、Context Rotは入力長の増加に伴う全体的な性能低下を指します。これらはTransformerのAttentionメカニズムに根差した構造的な問題であり、モデルの進化だけで完全に解消されるものではありません。

だからこそ、プロンプトの設計やRAGパイプラインの構築において、情報の配置・圧縮・構造化を意識することが実務では不可欠です。「コンテキストウィンドウに入るから大丈夫」ではなく、**「限られた注意の予算をどう配分するか」**という視点で設計してみてください。

参考文献