LLMのコンテキスト長が限界を超えると性能が崖のように落ちる話

はじめに

「チャットが長くなってきたら新しいチャットで始めよう」という経験則、皆さんもありませんか？

実はこれ、ちゃんとした根拠があったことが2026年1月に公開された論文で明らかになりました。LLM（大規模言語モデル）には「コンテキスト長の崖」が存在し、ある閾値を超えると性能が急激に低下するというのです。

この記事では、その論文の内容を要約し、実際の開発にどう活かせるかを考えてみます。

要約した論文

タイトル: Intelligence Degradation in Long-Context LLMs: Critical Threshold Determination via Natural Length Distribution Analysis

著者: Weiwei Wang, Jiyong Min, Weijie Zou

公開日: 2026年1月7日

論文リンク: https://arxiv.org/abs/2601.15300

論文の要点

1. 「崖」のような性能低下が存在する

この論文の最も衝撃的な発見は、LLMの性能が少しずつ劣化するのではなく、ある地点で突然ガクンと落ちるという点です。

論文では、Qwen2.5-7Bを用いた実験で以下の結果が報告されています。

• 閾値: 最大コンテキスト長の 40〜50% 付近
• 性能低下: F1スコア（正確性を示す指標）が0.55〜0.56から0.3へ低下
• 低下率: 約 45.5% の性能劣化

つまり、128,000トークンが最大のモデルなら、約51,000〜64,000トークンあたりで急激にパフォーマンスが落ちるということです。

2. 「浅い適応（Shallow Adaptation）」という現象

論文ではこれを"shallow long-context adaptation"と呼んでいます。

これは何かというと、モデルが中程度の長さ（最大長の半分くらい）までは問題なく処理できているように見えても、実際には本当の意味で長文を理解・処理する能力を獲得しているわけではないという意味です。

表面的には適応できているように見えても、限界を超えた途端に処理しきれなくなる、ということですね。

3. 情報の関連性は関係ない

さらに重要なのは、入力されている情報がタスクにどれだけ関連していても、単に「長さ」のせいで性能が低下するという点です。

つまり、「無関係な情報が混ざっているから精度が落ちる」のではなく、「長いから精度が落ちる」のです。これは構造的な限界を示唆しています。

4. 「30%以上の性能低下」を知能劣化と定義

論文では、タスク性能が30%以上低下することを"intelligence degradation（知能劣化）"と定義しています。この基準を超えると、実用上の問題が発生すると考えられます。

思ったこと

論文を読んで感じたことをいくつか挙げます。

• 「新しいチャットで始める」の根拠が分かった: 今まで経験則として何となく実践していたことに、科学的な裏付けができた
• 「どれくらい」が明確になった: 最大コンテキスト長の40〜50%という具体的な目安ができた（ただしQwen2.5-7Bの場合）
• 情報の質より量: 関連性の高い情報を入れても、長さだけで性能が落ちるというのは驚き。構造的な限界なんだと実感した
• 確認方法がない: チャット形式のAI（ClaudeやChatGPT）で、現在のコンテキスト使用量を確認する簡単な方法がないのが残念
• 他のモデルでも同じ？: この研究はQwen2.5-7Bが対象だが、ClaudeやChatGPTでも似たような傾向があるのか気になる

崖を迎えないためにできそうなこと

論文の知見を、実際の開発やAI利用にどう活かせるか考えてみました。

1. 長くなったら要約して引き継ぐ

会話が長くなってきたら、途中でこれまでのやりとりを要約させて、新しいチャットに引き継ぐのが有効です。

【例】
1. 長いチャットで作業を進める
2. コンテキストが膨らんできたら、「これまでの内容を要約して」と依頼
3. 要約を新しいチャットに貼り付けて続行

要約することで、元の会話の数万トークンが数百〜数千トークンに圧縮され、コンテキストの「崖」を回避できます。

2. 資料作成時の分割戦略

チャットで資料作成などをしていてやりとりが長くなりそうなときは、一旦ドラフト版で保存して新しいチャットに添付し、続きから始めるようにすると良さそうです。

3. タスクごとにチャットを分ける

画面実装、コードレビュー、リファクタリングなど、複数のタスクを一貫して同じチャットで指示するのではなく、それぞれ個別の新規チャットで行えばコンテキスト長を気にせず作業できます。

❌ 悪い例: 1つのチャットで全部やる
「画面を実装して」→「レビューして」→「リファクタリングして」
→ コンテキストがどんどん膨らむ

✅ 良い例: タスクごとに分ける
チャット1: 「画面を実装して」
チャット2: 「このコードをレビューして」
チャット3: 「リファクタリングして」
→ 各チャットのコンテキストは小さく保てる

4. エラーメッセージは必要箇所のみ抽出

エラー発生時には、エラーメッセージを全部貼り付けるのではなく、必要な箇所だけ洗い出して貼り付けるようにした方が良さそうです。

特にスタックトレースが長大な場合、本当に必要な部分だけを抽出することでコンテキスト消費を抑えられます。

コンテキスト長を確認する方法

どうしてもやりとりが長くなってしまうこともあると思うので、コンテキスト長を意識するために実際にどのくらいコンテキストを使っているかを確認できる方法をまとめました。(※ 自身が使っているモデルのみ)

ChatGPT

方法1: Chromeの拡張機能「ChatGPT Token Counter」を使う

注意点としては、更新が1年以上止まっていて、デベロッパーも個人のため、セキュリティ的に不安が残ります。

方法2: OpenAIのTokenizerツールで手動計算

https://platform.openai.com/tokenizer でチャット内容をコピーして貼り付け、トークン数を確認する方法です。

ただし、これは非常に手間がかかります。

Claude

現時点では、Claude（claude.ai）でコンテキスト長を確認する公式な方法はありません。

確認したい場合は、ChatGPTと同様にOpenAIのTokenizerツールでチャット内容をコピーして貼り付け、手動で計算するしかありません。

Codex

CLIにはないようですが、VS Codeの拡張機能であればチャット入力欄の右下に％の表示があります。これでコンテキスト使用率を確認できます。

Claude Code

コマンド/contextで確認できます。

コンテキスト長を常に表示することもできるみたいです。

参考: Claude Codeでコンテキスト使用率を常に表示する

GitHub Copilot

Chat Debug Viewを使います。

参考: Chat Debug で GitHub Copilot の動作を追いかけよう

ただし、1つの指示に対してのトークン数が見れるだけなので、累計は自分で計算する必要があります。

まとめ

• LLMには「コンテキスト長の崖」が存在する（最大長の40〜50%付近）
• 性能低下は突然訪れる（少しずつではなく急激に）
• 情報の関連性とは無関係（長いだけで性能が落ちる）
• 対策
  • 長くなったら要約して新規チャットへ引き継ぐ
  • タスクごとにチャットを分ける
  • 不要な情報は削ぎ落とす
  • コンテキスト使用率を意識する（確認できる場合）

この論文はQwen2.5-7Bを対象にしていますが、他のLLMでも似たような傾向がある可能性は高いです（推測）。今後、Claudeや ChatGPTでも同様の研究が出てくるかもしれませんね。

「長いチャットは新しく始める」という経験則に、科学的な裏付けができたことで、より意識的にコンテキスト管理ができるようになりそうです。

参考になったら いいね や ストック をお願いします！
同じような経験をされた方のコメントもお待ちしています。

参考

• Intelligence Degradation in Long-Context LLMs: Critical Threshold Determination via Natural Length Distribution Analysis

アウトプットで手当がもらえる会社 ONE WEDGE

株式会社ONE WEDGE では一緒に働く仲間を募集中！

技術記事を書くと手当がもらえる「IT系記事寄稿特別手当」という制度があります。

興味があればぜひカジュアルに話しましょう！

👉 採用サイト