Claudeの長い会話は精度が落ちる — context rotの根拠と/clearの目安

落ちます。気のせいではありません。コンテキストウィンドウ内のトークンが増えるほど、モデルがその中の情報を正確に取り出す能力は下がります。Anthropic自身がこの現象をcontext rot(コンテキストの劣化)と名付け、エンジニアリングブログで仕組みごと説明しています。ただし劣化は崖ではなく勾配で、対処のレバーもはっきりしています。この記事では、劣化が起きる根拠と理由、そして実務でいちばん効く判断——いつ /clear を打つか——の目安をまとめます。

context rotとは — 長い会話で情報の再現精度が下がる現象

context rotとは、コンテキストウィンドウ内のトークン数が増えるにつれて、モデルがそのコンテキストから情報を正確に思い出す能力が低下する現象です。長文の中に事実を1つ埋めて取り出させるneedle-in-a-haystack(干し草の山の針)型のベンチマーク研究で確認されてきました。

重要なのは、これが特定モデルの欠陥ではない点です。劣化の緩やかさに差はあっても、この特性はすべてのモデルに現れるとAnthropicのApplied AIチームは書いています。「コンテキストに入ってさえいれば、どこにあっても同じ精度で読める」という直感は、実測に反します。コンテキストは使うほど目減りする有限資源です。

なぜ起きるのか — attention budgetという考え方

原因はtransformerというアーキテクチャの性質にあります。transformerでは、すべてのトークンがコンテキスト内の他のすべてのトークンを参照します。トークン数nに対して参照関係はn²で増えるため、コンテキストが伸びるほど、1つひとつの関係に割ける注意は薄まります。人間の作業記憶に限りがあるのと同じように、モデルにも「attention budget(注意の予算)」があり、トークンを足すたびに残高が減っていく——Anthropicはそう説明しています。

学習データの偏りも効いています。訓練に使われる系列は短いものが多く、モデルはコンテキスト全体をまたぐ長距離の依存関係を扱った経験が相対的に少ないまま育ちます。長い系列は位置エンコーディングの補間で扱えるものの、トークン位置の理解には多少の劣化が伴います。

この積み重ねの結果は、性能の崖ではなく勾配になります。長いコンテキストでもモデルは高い能力を保ちますが、情報の取り出しと長距離の推論では、短いコンテキスト時より精度が下がる。これがcontext rotの実像です。

Claude Codeでは何が起きるか — 長い会話が不利になる3つの理由

Claude Codeのセッションに引き付けると、会話を伸ばし続けることの不利は3つに分けられます。

1つ目は上で見た劣化そのものです。序盤に読んだファイルの内容や決定事項が、終盤には正確に思い出されにくくなります。2つ目は場所の圧迫です。公式ドキュメントは「古い会話は、次に必要なファイルの居場所を奪う」と表現しています。無関係な履歴が残っているだけで、これから読むべきコードに割ける余地が減ります。3つ目はコストです。会話履歴は毎メッセージ入力トークンとして送られるため、長い会話は1往復ごとの料金とレイテンシにもそのまま乗ります。

劣化・圧迫・コストの3つは同じ原因から出ています。溜まった履歴は、それ自体が負債です。

/clearを打つ目安 — タスクの切れ目が基準

では、いつリセットするか。公式ドキュメントの指針はシンプルで、無関係な作業に移るときが /clear のタイミングです。状況別に並べると次のようになります。

/compact には /compact focus on the auth bug fix のように指示を添えられます。自動圧縮に任せると何を残すかはモデルの推測になるため、大事な文脈が決まっているなら指定するほうが確実です。発火点そのものを手前に動かしたい場合は /autocompact 500k のように閾値を設定できます。圧縮の仕組みと要約後に何が残るかはcompactの発火条件の解説が詳しいです。

/clear をためらう理由の多くは「消したら戻れない」ですが、これはrewindコマンドで解けます。/clear 前の会話には戻れるので、リセットは失うことではありません。

なお、そもそもセッションに何を載せるかという入口の設計(除外設定・起動場所)はコンテキスト管理の解説で扱っています。この記事の /clear 判断とは補完関係にあります。

圧縮しても消えないもの、消えるもの

/clear や圧縮をためらうもう1つの理由は「積み上げた指示まで消えそう」という不安です。実際には、読み込まれ方によって運命が分かれます。

つまり、恒久的な規則はファイルに書いてあれば戻ってきます。危ういのはパス条件付きのルールと深い階層のCLAUDE.mdで、これらは会話履歴と一緒に要約へ畳まれ、該当ファイルを読み直すまで効きません。圧縮をまたいでも必ず効かせたい規則は、paths: を外すかプロジェクト直下のCLAUDE.mdへ移すのが公式ドキュメントの案内です。残したい知識は履歴ではなくファイルに置く。これがcontext rot時代の基本姿勢になります。

1Mコンテキストでも問題は消えない

「大きいウィンドウを待てばよいのでは」という発想に対して、Anthropicは明確に否定的です。予見できる将来にわたって、どのサイズのコンテキストウィンドウもコンテキスト汚染と情報関連性の問題から逃れられない——少なくとも最高性能を求める場面では、と書いています。

つまり1M対応モデルは「劣化への対策」ではなく「大きな入力を受ける器」です。巨大なコードベースや長い資料を扱うために1Mを選ぶのは合理的ですが、その中でもcontext rotの勾配は働きます。入る量とコスト設計の実務は1Mコンテキストの活用ガイドにまとまっています。

Anthropic自身の回避策 — 圧縮・メモ・分業

Anthropicは長時間タスク向けの技法として、compaction(圧縮)・structured note-taking(構造化メモ)・マルチエージェントの3つを挙げています。Claude Codeのcompactionでは、アーキテクチャ上の決定や未解決のバグを保ちつつ冗長なツール出力を捨て、圧縮後は直近にアクセスした5ファイルとともに会話を再開します。メモの例としては、エージェントがNOTES.mdのようなファイルに進捗を書き出し、コンテキストのリセット後に自分のメモを読んで数時間規模のタスクを続ける運用が示されています。

3つ目の分業では、サブエージェントが数万トークン規模の探索を自分のコンテキストで行い、親には1,000〜2,000トークンの要約だけを返します。詳細な検索の文脈をサブ側に隔離し、親は統合と判断に集中する分離です。これらの技法の全体像はAnthropicのContext Engineering論の解説で扱っています。

APIで自前のエージェントを組んでいる場合も、同じ道具が使えます。ツールの実行結果だけを履歴から落とすtool result clearingはClaude Developer Platformの機能として提供されており、Anthropicは「もっとも安全で軽い圧縮」と説明しています。履歴の深くにあるツールの生出力は、要約する以前にそもそも二度と参照されないことが多いためです。ファイルベースで知識を貯めるmemoryツールも、Sonnet 4.5のリリース時からDeveloper Platformで使えます。

道具立ては違っても、これらがやっていることは同じです。高信号なトークンだけをウィンドウに残す。/clear はその最小の実践と言えます。

よくある質問

劣化はどのくらいの長さから始まりますか

一律の閾値は公表されていません。劣化は連続的に進むため、「ここから急に落ちる」という境界がそもそもありません。長さの絶対値より、無関係な情報の割合を減らすことが対策になります。

/clearすると設定や記憶も消えますか

消えません。消えるのは会話履歴だけで、CLAUDE.mdや自動メモリはディスクから読み直されます。プロジェクトの規約やコマンドの知識はセッションをまたいで保持されます。

長い会話は料金にも影響しますか

します。会話履歴は毎メッセージ入力トークンとして課金対象になります。プロンプトキャッシュが効く部分は単価が下がりますが、履歴が長いほど1往復が重くなる関係は変わりません。

1Mコンテキストはどのモデルで使えますか

Fable 5・Sonnet 5・Opus 4.6以降・Sonnet 4.6が1Mトークンのコンテキストウィンドウに対応しています。Sonnet 5は標準で1Mのため、[1m] 付きモデルを選ぶ操作は不要です。

まとめ

長い会話でClaudeの精度が落ちるのは実証された現象で、Anthropic自身がcontext rotと呼んで対策を体系化しています。原因はattention budgetの有限性にあり、どのモデルでも、どのウィンドウサイズでも消えません。実務の結論は1つで、タスクの切れ目で /clear、続きものは指示付き /compact、探索はサブエージェントへ。履歴を溜めることは記憶を増やすことではなく、注意を薄めることです。