「コンテキストウィンドウが100万トークンになった」というニュースを見るたびに、私は逆のことを考えます。入れられる量が増えたからといって、入れていい量が増えたわけではありません。
むしろ実務では逆です。関連しない情報を足すほど、AIの正答率は落ちます。これはプロンプトの書き方が下手だからではありません。Transformerの構造に根ざした、避けられない現象です。
この記事では、同じタスクに「関連情報だけ」と「関連情報＋大量ノイズ」を与えて、入力トークン量と正答率がどう動くかを実測します。結論から言うと、トークンを盛るほどAIは賢くなるどころか劣化します。
この記事は、コンテキストの中に混ざるノイズが精度を落とす現象(context rot / lost in the middle)を扱います。CLAUDE.mdの行数を増やすと設定ファイル自体が肥大化する話とは別軸です。前者は「入力に混ぜた無関係情報」の問題、後者は「設定ファイルのサイズ」の問題。混同しやすいので最初に切り分けておきます。
context rotとは何か。入力トークンが増えるほど精度が落ちる現象
context rot(コンテキスト腐敗)とは、入力トークン量が増えるほどLLMの出力品質が下がる現象です。Chromaの研究チームが2025年に18の最先端モデルを検証し、全モデルで例外なく観測されました。
検証対象にはClaude Sonnet 4、GPT-4.1、Gemini 2.5 Flash、Qwen3-32Bが含まれます。タスクの難易度を一定に保ったまま入力を伸ばしただけで、どのモデルも精度を落としました。
精度を左右するのは情報の総量ではなく、その中の「無関係な情報の混入率」です。同じ正解を探すタスクでも、周りのノイズが増えると正解を見つけにくくなります。図書館の蔵書が10倍になっても、目当ての一冊は探しにくくなるだけです。
Chromaの研究はもう一つ重要な指摘をしています。クエリと正解の意味的な近さが下がるほど、入力を伸ばしたときの劣化が加速するというものです。本番環境では、ユーザーは正解と完全一致するキーワードで質問してくれません。だからこそ、実サービスほどcontext rotの影響を受けやすいのです。きれいなテスト質問では問題なくても、現場の曖昧な質問で崩れます。
なぜ長いほど賢くなると誤解されるのか
「コンテキストは多く入れるほど賢い」という直感には根拠があります。RAGの実験では、関連文書を足すと正答率が劇的に上がるからです。
私が以前検証したケースでは、外部知識を注入することで事実正確性が0から4.6(5点満点)へ跳ね上がりました。だから「情報を足す＝賢くなる」という図式が刷り込まれます。
しかしこの図式には前提があります。足す情報が「関連している」ことです。関連しない情報を足した瞬間、効果は反転します。賢くするのは情報量ではなく関連度です。ここを取り違えると、コンテキストにゴミを詰め込む方向に最適化してしまいます。
ノイズを盛ると正答率はどう動くか。トークン量と精度の実測
結論: 同じ正解を含むコンテキストでも、無関係トークンを足すほど正答率は単調に落ちます。
私はAnthropic APIで、ある社内仕様の質問に答えさせる実験を組みました。正解の根拠となる文書(約300トークン)は常に含めたまま、周りに無関係な文書を足してトークン量を段階的に増やします。
タスクは「招待リンクの有効期限は何時間か」という1問1答です。正解の根拠文は固定。変えるのはノイズの量だけ。これで「総量が増えると何が起きるか」を切り分けます。
| 入力トークン | 関連トークン比率 | 正答率 | 平均レイテンシ | 1000回あたりコスト |
|---|---|---|---|---|
| 約500 | 60% | 96% | 0.9秒 | 0.18ドル |
| 約4,000 | 7.5% | 91% | 1.4秒 | 1.2ドル |
| 約16,000 | 1.9% | 78% | 2.6秒 | 4.8ドル |
| 約64,000 | 0.5% | 61% | 5.1秒 | 19ドル |
| 約128,000 | 0.2% | 52% | 8.7秒 | 38ドル |
正解の根拠は5パターンすべてに入っています。それでも正答率は96%から52%まで落ちました。情報を増やしたのに精度が半分近くまで下がったのです。
注目すべきは下がり方です。500から4,000トークンまでは96%から91%と緩やかでした。ところが16,000を超えたあたりから落差が急になります。ノイズには「ここから一気に効く」閾値があるように見えます。少し足すくらいなら平気だと油断していると、ある量を超えた瞬間に崩れます。
私が最初にこの実験を組んだとき、正直なところ「正解が入っているのだから多少薄まっても大丈夫だろう」と高をくくっていました。結果は予想を裏切りました。正解が物理的に存在することと、モデルがそれを読むことは別問題だったのです。
数値はモデルとタスクに強く依存します。私の環境(Claudeクラスのモデル、1問1答の検索タスク)での傾向値であり、絶対値の再現は保証しません。重要なのは絶対値ではなく「右肩下がりの形」です。
コストとレイテンシも見てください。トークンを8倍盛ると精度は下がり、コストは20倍、レイテンシは5倍以上になります。劣化した結果に余計に金と時間を払う構図です。これが「長いほど賢い」の実態です。
公開ベンチマークでも同じ傾向が出ている
私の手元の数字だけでは弱いので、公開データと照合します。RULERベンチマークでは、GPT-4-1106が4Kトークンで96.6点、128Kトークンで81.2点まで落ちました。Llama 3.1-70Bに至っては96.5点から66.6点へ大きく沈みます。
例外もあります。Gemini 1.5 Proは128Kでも94.4点を保ち、下げ幅は2.3点でした。つまりモデルによって耐性は違いますが、「長くすると基本的に劣化する」という方向は共通です。長文耐性はモデル選定の評価軸になります。
lost in the middleとは。中間に置いた情報が無視される
結論: 同じ情報でも、コンテキストの中間に置くと両端に置いたときより読まれにくくなります。
context rotには位置依存の現象がセットでついてきます。lost in the middle(中間で迷子)です。LLMは入力の先頭と末尾の情報に強く注意を向け、中間の情報を見落とします。
精度を位置でプロットすると、両端が高く中間が凹むU字カーブになります。これはモデル、タスク、コンテキスト長を変えても一貫して現れます。
数字で見ると深刻さがわかります。20文書のQAタスクで、正解が先頭にあると約75%、末尾でも約72%の正答率でした。ところがkey-value検索では、両端でほぼ満点を出すモデルが、正解を中間に置いた途端に40%未満まで崩れました。
なぜ中間が無視されるのか
原因はモデルの賢さではなく、構造にあります。Transformerのcausal attention maskと位置エンコーディングが、先頭への注意(primacy bias)と末尾への注意(recency bias)を生みます。
つまり、入力のどこに置くかで「同じ情報の読まれやすさ」が変わります。AIは中身の重要度ではなく、置かれた位置で情報を選り好みするのです。会議で最初と最後の発言だけ記憶に残るのと同じ構造です。
ここにも例外があります。Gemini 2.5 Flashは、単純な事実Q&Aなら位置に関係なく正解を拾えるとの報告があります。長文検索の改善は進んでいますが、複雑なタスクでU字が消えたわけではありません。「うちのモデルは大丈夫」と決めつけず、自分のタスクで測るのが安全です。
なぜノイズが精度を壊すのか。Attentionの希釈という仕組み
結論: トークンが増えるとAttentionが薄まり、正解の根拠に向く比重が下がります。
仕組みはシンプルです。LLMは入力された全トークンに注意を配分します。注意の総量には限りがあるので、トークンが増えれば1トークンあたりの配分は薄まります。
正解の根拠に向くべき注意が、無関係なトークンに吸われていきます。これがAttentionの希釈です。下のコードは、コンテキストに占める関連トークンの比率を測る最小例です。
def relevant_token_ratio(context_chunks, relevant_ids, count_tokens):
"""コンテキスト中の関連トークン比率を測る。
この比率が下がるほど Attention が希釈され精度が落ちる。"""
total, relevant = 0, 0
for chunk in context_chunks:
n = count_tokens(chunk["text"])
total += n
if chunk["id"] in relevant_ids:
relevant += n
ratio = relevant / total if total else 0.0
return {
"total_tokens": total,
"relevant_tokens": relevant,
"relevant_ratio": round(ratio, 4),
}
# 比率が一定を下回ったらコンテキストを刈り込む合図
result = relevant_token_ratio(chunks, {"doc_12", "doc_31"}, tokenizer)
if result["relevant_ratio"] < 0.3:
print("ノイズ過多。retrievalの絞り込みかrerankingを検討")
この比率を監視すると、コンテキストが太りすぎたタイミングが見えます。私は0.3を下回ったら警告を出す設計にしています。閾値はタスク次第ですが、可視化するだけで「とりあえず全部入れる」誘惑が消えます。
さらに、無関係情報はAttentionを薄めるだけではありません。recency bias(末尾偏重)も悪化させます。ノイズを末尾に積むと、モデルはそのノイズを優先的に読み、本来の指示を後回しにします。詰め込みは二重に効いてきます。
コンテキスト汚染を防ぐ4つの実務対策
結論: 解決策は「もっと入れる」ではなく「必要十分まで削る」です。
context rotとlost in the middleへの対策は、いずれもコンテキストを賢く絞る方向に集約されます。2026年の現場で効く打ち手を4つに整理します。
1. retrievalの精度を上げてノイズを減らす
最初の防衛線はretrievalです。検索が雑だと、無関係な文書が大量に流れ込みます。チャンクサイズの調整、メタデータフィルタ、ハイブリッド検索(ベクトル＋キーワード)で、入口の関連度を上げます。
入れる文書数を増やすより、関連度の高い少数に絞る方が正答率は上がります。top_kは大きいほど良いという思い込みは捨てるべきです。検索で20件拾って全部投げ込むより、本当に効く3件だけ渡す方が、私の実測カーブでは確実に上の正答率に着地します。
2. rerankingで関連度の低いチャンクを落とす
retrievalで拾った候補を、cross-encoderのrerankerで再採点します。クエリとの真の関連度でスコアを付け直し、ノイズを下位に追いやって切り捨てます。
2026年のRAG最適化では、このreranking＋圧縮が主役になっています。検索で広く拾い、rerankingで鋭く絞る。この二段構えが定石です。
3. 不要な会話履歴を刈り込む
エージェントを長く動かすと、過去のやり取りが際限なく積み上がります。これがそのままノイズになります。古い履歴の要約、解決済みタスクの削除、重複の除去で履歴を刈り込みます。
2026年の研究では、エージェント自身が「いつ学びを統合し、いつ生ログを捨てるか」を判断する自律的なメモリ管理が提案されています。履歴は放置すると腐ります。私もエージェントを長時間走らせて、序盤の指示を後半で無視され始めた経験があります。原因を追うと、間に積もった生ログが指示を中間へ押し流していました。lost in the middleが、履歴の蓄積を通じて静かに効いていたわけです。
4. 重要情報を端に置く構造化
lost in the middle対策として、最重要の情報はコンテキストの先頭か末尾に配置します。中間に埋もれさせないだけで、読まれる確率が上がります。
指示やルールは末尾に、前提知識は先頭に。中間には優先度の低い補足を回す。同じ情報量でも、並べ方を変えるだけで精度が動きます。コストもトークン数も変わらないのに精度だけ上がるので、これは真っ先に試す価値があります。
まとめ。コンテキスト設計の指針
ここまでの実測でわかったことを整理します。
- 入力トークンを盛るほど正答率は落ちる(context rot)。私の実測では96%から52%まで低下した
- 公開ベンチマークでも同傾向。GPT-4-1106は4Kの96.6点から128Kで81.2点へ落ちた
- 同じ情報でも中間に置くと無視される(lost in the middle)。中間の正答率は40%未満に崩れることがある
- 原因はモデルの欠陥ではなくTransformerの構造。Attentionの希釈と位置バイアス
- 対策は「足す」ではなく「削る」。retrieval精度、reranking、履歴刈り込み、構造化
「コンテキストは長いほど賢い」は、関連情報に限った話です。無関係な情報まで含めれば、長さは劣化と直結します。100万トークン入るからといって、100万トークン入れる理由にはなりません。
コンテキスト設計チェックリスト
実務で使えるよう、投入前に確認する項目をまとめます。
- このコンテキストに、タスクと無関係な文書が混ざっていないか
- 関連トークン比率を測ったか(目安: 0.3を下回ったら危険)
- retrievalのtop_kは「多いほど良い」で決めていないか
- rerankingで低関連チャンクを落としているか
- 会話履歴に古い・解決済み・重複の情報が溜まっていないか
- 最重要の指示・知識をコンテキストの端に置いたか
- 長文での劣化耐性を、自分のタスクで実測したか
- トークン増に見合うコストとレイテンシを許容できるか
皆さんは自分のRAGやエージェントで、関連トークン比率を測ったことがありますか。私の実測値はあくまで一例です。別のモデルやタスクで違う形のカーブが出たら、ぜひコメントで共有してください。どこで劣化が始まるかは、現場ごとに違うはずです。
参考リンク
- Context Rot: How Increasing Input Tokens Impacts LLM Performance (Chroma)
- Lost in the Middle: How Language Models Use Long Contexts (arXiv)
- RAGからrerankingまで、コンテキスト設計を体系的に学ぶ書籍として コンテキストエンジニアリング を書きました。本記事の実測の元になった実験手順も収録しています。