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と/compactの使い分け — 場面で決める

リセットの手段は複数あり、どれを選ぶかは「いま何が起きているか」で決まります。公式のベストプラクティスは、無関係な作業の合間と、同じ修正が2回失敗したあとを区切りとして挙げています。次の順に当てはめると判断が速くなります。

ログ調査や大量のファイル探索は、リセットより先にサブエージェントへ委譲して読み込みを別のコンテキストに隔離する手があります。圧縮の仕組みと要約後に何が残るかはcompactの発火条件の解説が詳しいです。

圧縮が走る位置を手前に動かす

自動圧縮の発火点は設定で動かせます。セッション中なら /autocompact 500k のように閾値を渡し、モデル既定に戻すときは /autocompact auto です。

/autocompact の値はユーザー設定(autoCompactWindow)に保存され、次のセッションにも効きます。起動フラグはその回だけの上書きで、環境変数 CLAUDE_CODE_AUTO_COMPACT_WINDOW が設定されていればそちらが最優先です。

起動時のフラグにも同じ項目があります。v2.1.287の claude --help で確認すると、次のように出ます。

claude --help | grep -A1 autocompact

  --autocompact <auto|tokens>           Auto-compact window size (auto, or
                                        100k–1M tokens)

指定できる範囲は100k〜1Mトークンです。1Mのウィンドウでも、手前で圧縮させて劣化の勾配が緩いうちに要約へ切り替える、という使い方ができます。

/clearしても戻れる範囲

/clear をためらう理由の多くは「消したら戻れない」ですが、会話は残ります。/clear は前の会話を /resume の一覧に残し、名前を付けておけば見分けも付きます(/clear 認証バグ調査 のように渡します)。

同じClaude Codeのプロセスの中なら、rewindコマンドのメニュー先頭に /resume <session-id> (previous session) の項目が出ます。選ぶと /clear 前の会話へ戻れます。

この項目は、Claude Codeを終了するか別のセッションを再開するまでの間だけ使えます。

脇道に逸れるときに履歴を汚さない

リセットの回数そのものを減らす道具もあります。いずれも「いまの会話に余計なものを足さない」ための使い分けです。

セッションに何を載せるかという入口の設計(除外設定・起動場所)は、コンテキスト管理の解説にあります。

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

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

圧縮後に再び読まれるファイルと呼び出し済みスキルには、上限があります。

スキルの本文は、先頭が残り末尾が切られます。大事な指示は SKILL.md の冒頭に置くのが公式の案内です。一方、スキルの一覧に出る1行説明は再注入されず、実際に呼び出したスキルだけが残ります。

圧縮をまたいでも必ず効かせたい規則は、paths: を外すか、プロジェクト直下のCLAUDE.mdへ移します。compact ソースに一致するSessionStartフックを置けば、圧縮のたびにその出力を足し直せます。残したい知識は履歴ではなくファイルに置く。これがcontext rot時代の基本姿勢になります。

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

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

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

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

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

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

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

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

よくある質問

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

消えるのは会話履歴で、プロジェクトのメモリは残ります。公式のコマンド一覧は、/clear を「プロジェクトのメモリを保ったまま新しいタスクを始める」操作と位置づけています。CLAUDE.mdや自動メモリは、新しい会話の開始時にディスクから読み込まれます。

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

Claude Developer Platformの一覧で、一般に選べるモデルのうち1Mトークンなのは次のとおりです。Fable・Mythosは5.1と5の計4モデルです。Opusは5.5・5・4.8・4.7・4.6、Sonnetは5.5・5・4.6が該当します。Sonnet 4.5は200kトークンです。

1Mのモデルは1Mが既定で、ベータヘッダーは要らず、長いコンテキストのリクエストも標準料金で課金されます。

まとめ

長い会話の精度低下は、Anthropicが自らcontext rotと呼ぶ実証済みの現象で、モデルを替えてもウィンドウを広げても消えません。

残したい決定や規則は、履歴ではなくCLAUDE.mdやファイルに置きます。会話は使い捨てる前提で区切れば、/clear で失うものはほぼなくなります。