【Claude Code】回答精度が落ちる理由「Context Rot」を理解してコンテキストを整える｜ブログ

はじめに Claude Codeを使っていると、トークンの消費が異常に激しかったり、思ったような回答が返ってこなかったりすることがあります。振り返ってみると、そういうときは決まって指示が長くなっていたり、会話が延々と続いていたりすることが多いのではないでしょうか。 とはいえ、なぜこれほどまでにトークン消費が激しくなるのか、また多くのファイルを読ませたり会話を長く続けたりするとよくないとよく聞くものの、その理由まではよく分かっていませんでした。そこで色々と調べると、精度をおとさないように「コンテキスト」を整える重要性に気が付きました。 精度が落ちていく仕組みとコンテキスト まず、コンテキストとは コンテキストとは、LLMに渡す「システムプロンプト・会話履歴・ツールの定義・参照ファイルの中身」など、モデルが応答を生成する際に参照するトークン集合全体のことです。 精度が落ちる仕組みについて LLMに情報を詰め込めば詰め込むほど、実は必要な情報を正確に参照する精度は落ちていきます。この背景にあるのが、ベクトルDB企業Chromaのリサーチャーらが提唱する「Context Rot（コンテキストの腐敗）」という現象です。 これには、LLMの基盤技術である「Transformer」の構造が大きく関係しています。 原因は、Transformerの「Self-Attention（自己注意）」という仕組み ChatGPTやClaudeのようなLLMは「Transformer」という設計図で作られていて、その心臓部にあるのが「Self-Attention」という仕組みです。 Self-Attentionは何をしているのか 簡単に言うと、文章中の単語（トークン）一つひとつが、他のすべての単語を見渡して「自分と関係が深いのはどれか」をチェックする作業です。関係が深い単語の情報を強く取り込み、自分の意味を更新していきます。 例えば「猫がボールを追いかけて、それを咥えた」という文なら、「それ」という単語は、他の単語との関連度を計算した結果、学習を通じて「ボール」を強く意識するようになります。こうしてモデルは「それ＝ボール」という文脈上のつながりを扱えるようになるわけです。 問題① 計算コストが急増する このチェック作業は「全単語 × 全単語」の組み合わせで行う必要があります。つまり単語数（n）が2倍になると、チェックすべきペアの数は4倍（n²）に膨れ上がります。クラス全員が互いに挨拶する場面を想像してください。人数が2倍になれば、挨拶の組み合わせは4倍になりますよね。これと同じで、文章が長くなるほど計算量とメモリ使用量が急激に増えていきます。 問題② 注意が薄まる もう一つ、計算コストとは別の問題があります。モデルが持てる「注目する力」の総量は限られているため、単語数が増えるほど、一つひとつの単語に配れる注意の割合は小さくなっていきます。 大人数の会議で発言時間が限られているのと同じイメージです。参加者が10人なら一人あたりの発言時間は長く取れますが、100人になると一人ひとりの持ち時間はごくわずかになります。 その結果、文章が長くなればなるほど、本当に重要な情報が大量のトークンの中に埋もれやすくなり、モデルが見落としてしまうリスクが高まるのです。 「効き」は上限に達する前から落ちている ここで注意したいのは、この「注意の薄まり」は、コンテキストウィンドウの上限に達してから急に起こるわけではないという点です。上限にはまだ余裕があっても、トークン数が増えていくにつれて、1トークンあたりの影響力(効き)はじわじわと低下し始めます。 先ほどの会議の例で言えば、「定員オーバーになった瞬間に発言時間がゼロになる」わけではありませんよね。参加者が10人から30人、50人と増えていく過程で、少しずつ一人あたりの持ち時間が削られていくはずです。Self-Attentionの「効き」も同じで、上限という壁にぶつかる前から、水面下で少しずつ薄まっていくのです。 その結果、会話や文章が長くなるほど、モデルは「今この指示に本当に必要な情報はどれか」を見つけ出すのが難しくなっていきます。まだ余力があるように見えても、実際にはすでに注意力の希釈が進行している、というのがポイントです。 精度を落とさないようにするには では、精度を落とさないためにどうすればよいのでしょうか。基本の考え方はシンプルで、「モデルに渡すトークンをなるべく増やさないよう、コンテキストを整理する」ことです。 とはいえ、これは単純に情報を減らせばよいという話ではありません。情報が不足するとClaudeが意図を汲み取れず、確認のやり取りや質問が増えて、結果的にトークン消費もコンテキストも膨らんでしまいます。かといって、関連しそうな情報をとにかく全部渡すのも、Context Rotを招くという点で得策ではありません。 つまり大切なのは、情報の「量」を単純に増減させることではなく、望む挙動を引き出せるだけの、必要十分な情報を見極めて渡すことです。以下に、良い例・悪い例を挙げて具体的に見ていきます。 ❌ 悪い例A（丸投げ）： 「検索機能をつけて」 └─ 全文検索なのか部分一致なのか、対象テーブルも不明。モデルが仮定で実装し、 後から「そうじゃない」の指摘が続いてトークンを消費 ❌ 悪い例B（過剰入力）： 「DB設計書、API仕様書、フロントの全コンポーネント、過去の検索関連PR10件を読み込んで検索機能を実装して」 └─ Context Rotにより、直近の要件よりも古いPRの実装方針を優先してしまうなど、優先順位を誤る ⭕ 良い例： 「productsテーブルのname列を対象に、部分一致検索を実装して。ページネーションは20件区切り。 検索UIを実装する場合は既に実装している「src/components/SearchBar.tsx」を参照して」 └─ 対象・条件・参照先を最小限指定し、UIの詳細は必要時に該当ファイルだけ読ませる 上記はあくまで典型例です。既存コードやCLAUDE.mdなど十分な文脈がすでにある場合は「丸投げ」に見えても実質は最適な指示になる場合や、逆に大規模リファクタリングなど網羅性が求められるタスクでは、意図的に情報量を増やす選択が正解になることもあります。大切なのは「タスクの複雑さと情報量のバランス」を都度見極めることです。 具体的な対策 ・CLIを使っている場合は、1つの要件・タスクが終わるごとに/clearをして、会話を次の作業に持ち越さないようにする 会話が長くなるほどコンテキストウィンドウ内に無関係な過去のやり取りが蓄積し、モデルが古い文脈を引きずって誤った前提で回答したり、関係のないコードやファイルの内容を参照してしまうことがあります。/clearでリセットすることで、常に今のタスクに集中した状態を保つことができます。 ・Plan Modeで要件の相談をし、プランだけ考えてもらい実装を別セッションで進める 要件定義や設計の議論には試行錯誤がつきものです。その過程で発生した無駄なやり取りや修正履歴がそのままコンテキストに残ると、実装フェーズでのコード生成品質が落ちる可能性があります。プランニングと実装を分けることで、実装セッションは余分な情報が無い状態から始められ、プランで決めた内容だけを正確に反映させることができます。 ・思ったような回答が返ってこなかったときは、Escキーを2回押して一つ前の回答に戻り、プロンプトを書き直す 一度不適切な回答や誤ったアプローチが会話履歴に残ってしまうと、モデルはその誤った文脈を参照し続けてしまい、以降の回答も同じ間違いを引きずりやすくなります。巻き戻して質問自体を修正することで、誤った文脈を履歴に残さないようにやり直します。 ・会話が長くなりそうなら「ここまで次のセッション用に要約して」と頼む → 出てきた要約を持って次のセッションへ 会話が長くなるほどコンテキストウィンドウを圧迫し、古いやり取りが切り捨てられたり、モデルが重要な情報を見失ったりするリスクが高まります。また、やり取りが積み重なるほど本質的でない部分にモデルが引っ張られ、回答の精度が落ちることもあります。 そこで、話が長引きそうだと感じた時点で「ここまでを次のセッション用に要約して」とお願いし、出てきた要約だけを持って新しいセッションを開始します。こうすることで、無駄なコンテキストを持ち越さず、要点だけを引き継いだ軽量な状態から再開でき、精度・応答速度の両方を保ちやすくなります。 ・サブエージェントを使う 調査やコード検索、大量のログ確認といった「情報を大量に読むが結論だけ分かればいい」作業をメインの会話で行うと、その過程で読み込んだ大量のテキストがそのままコンテキストに残ってしまい、圧迫の原因になります。サブエージェントに切り出すことで、重い調査はサブエージェント側のコンテキストで完結させ、メインの会話には要約された結果だけを返せるため、メインの会話に余計なコンテキストを増やさずに会話を進めることができます。 渡す情報・指示の設計で意識すること ・システムプロンプト・指示は「具体的すぎず、曖昧すぎず」 あらゆる分岐を書き尽くしたif-elseのような指示は、想定していないケースに弱くなります。逆に抽象的すぎる指示は解釈にブレが生じます。「役割・制約・期待する出力形式」は明確に区切りつつ、判断の余地は残す、というバランスを意識します。 ・ツールは絞る・曖昧さをなくす 持たせるツールが増えるほど、ツール定義（名前・説明・パラメータなど）自体がコンテキストを消費します。機能が重複するツールは削り、パラメータ名は曖昧な表記を避けて具体的なものにします。 例えば、「ユーザー」のようにIDなのか名前なのか解釈が分かれる名前ではなく、「ユーザーID」「ユーザー名」のように具体的な名前にします。ツールの説明文は「新しく入ったメンバーに説明するつもりで書く」のが指針です。 ・先に全部渡さない 関連しそうな情報を最初からすべて詰め込むのではなく、ファイルパスやIDのような軽量な参照だけを持たせておき、実際に必要になったタイミングで取得しに行く設計にします。 Claude Code自体がこれを採用していて、コードベースの中身を丸ごと記憶するのではなく、grepで該当箇所を検索したりheadで先頭だけ読んだりして、必要な範囲だけをその都度読みに行きます。人間が本を丸暗記せず、必要な箇所だけ調べて参照するのと同じ考え方です。 ・NOTES.mdなどに記憶させておく コンテキストウィンドウの外にNOTES.mdやTODOリストとして進捗・重要な決定を書き残し、後から読み直せるようにします。コンテキストがリセットされても作業を継続できるのが利点です。ただし、このファイルを読み込ませる行為自体もトークンを消費するので、書き残す内容は要点だけに絞るのがコツです。 コンテキスト管理に使えるコマンド・操作一覧 | やりたいこと | 使うもの | ひとこと | | --- | --- | --- | | 別タスクに切り替える | /clear | \CLAUDE.md\などのプロジェクト設定は保持されるので前提知識は失われない | | 思ったような回答が来なかった | Escキー2回 | 1個前の回答に戻ってプロンプトを書き直せる | | 同じタスクが長引いてきた | /compact | 会話は継続したまま要約・圧縮する。※会話の内容は消えてしまうため注意 \/compact \ \で要約の重点を指定できる | | 過去のセッションを見に行く | /resume（claude -c / claude -r "名前"） | \/clear\した会話も消えているわけではなく、後から追える | | 今のコンテキストの中身を見る | /context | 何が重くなっているか可視化。ツール出力が肥大化していないかのチェックに使える | | 今のセッションのコストを見る | /usage（/cost） | 現状のセッション使用量などを確認できる | | 複雑な変更の前に方針を固める | Plan Mode（Shift+Tab / /plan） | システムレベルで編集がロックされ、計画がファイルに自動保存される。複数ファイルに影響する変更や未知のコードベースで特に効果的。 | おわりに 意識的にコンテキストを気にするようになってから、はじめにプロンプトを書く時にどのくらいの情報を渡すべきなのか、どのくらいの会話になったら切り替えるべきなのかを考えるようになりました。 面倒に思うときもありますが、色々と考えながら、Claude Codeを使うのが結構楽しくなり始めています。 今後も知識を深めつつClaude Codeとうまく付き合っていけたらと思います。