はじめに
Claude Code を長時間回していると、セッションの後半で次のような症状が増えてくる体感がありました。
- ツール呼び出しの失敗(引数の形式ミス、存在しないパラメータの指定)
- ツール結果に対するプロンプトインジェクションの誤検知と思われる防御的挙動
そこで「こまめに自動メモリへ書き出させて /clear し、コンテキスト長を 300K トークン以下ぐらいに抑える」という運用を試したところ、これらの症状が目に見えて減った感じがしています。
本記事では、この体感を出発点として、なぜ長コンテキストでこうした症状が出るのかを公開情報で裏を取りながら整理し、Claude Code のメモリ機構を前提としたコンテキスト管理のベストプラクティスを考えてみます。
なお、本記事には体感ベースの話が多く含まれます。筆者の環境で定量的な比較測定をしたわけではない点、また Claude Code はアップデートが速く挙動が変わりやすい点はご了承ください(2026年7月時点の情報です)。
筆者の環境
| 項目 | 内容 |
|---|---|
| Claude Code | Max プラン、WSL2 上の Ubuntu で利用 |
| コンテキストウィンドウ | 1M トークンのコンテキストに対応したモデルで運用 |
| MCP | 自作の spec-rag サーバー(IEEE 1800 / UVM 1800.2 / AMBA AXI などの規格文書を BM25 + ベクトルのハイブリッド検索) |
| 主な用途 | SystemVerilog / UVM / SystemC のコード生成、シミュレータ開発 (本業ではなく趣味) |
体感していた症状
症状1: ツール呼び出し失敗の増加
セッションが長くなるにつれ、MCP ツールの引数スキーマを間違える頻度が上がる感じがあります。存在しないパラメータを指定する、JSON の形式を崩す、といったものです。
厄介なのは、一度失敗すると同じ失敗を繰り返すループに入りやすいことです。失敗、リトライ、また失敗、と続き、そのたびにエラーメッセージがコンテキストに積まれていきます。
症状2: インジェクション疑いの増加
こちらはやや意外な症状でした。spec-rag が返す規格文書チャンクや、シミュレーションのビルドログといった、実際には無害なツール結果に対して、プロンプトインジェクションを疑うような防御的挙動(作業を止めて確認を求める、ツール結果の内容を不審がる)が出ることがあります。
どちらの症状も、/clear して仕切り直すとしばらくは収まる、という共通点がありました。
なぜ長コンテキストで壊れるのか
メカニズムとしては、次の 3 つが効いていると考えられます。
1. 注意の希釈
ツールスキーマやシステム指示はコンテキストの先頭側に置かれます。その上に数十万トークンのツール出力や会話が積もると、モデルの注意が希釈され、スキーマの細部への遵守率が下がると考えられます。
コンテキストの中間に置かれた情報の参照精度が落ちる現象は Lost in the Middle として知られています。
また、入力トークンが増えること自体が性能を劣化させる現象は context rot と呼ばれ、Chroma のテクニカルレポートで体系的に測定されています。
Anthropic 自身も、コンテキストは有限の資源であり、LLM には attention budget があるという前提でコンテキストエンジニアリングを論じています。
2. 失敗ループ
LLM は「文脈の続き」を生成するモデルです。コンテキスト内に自分の失敗したツール呼び出しが残っていると、その失敗パターン自体を続きとして模倣しやすくなると考えられます。いわゆる self-conditioning です。
/clear が効くのは、このループを物理的に切断するからだと考えられます。「こまめに」が重要なのも、失敗例が蓄積する前に切るほうが安く済むからでしょう。
3. 信頼できないテキストの蓄積
コンテキスト内の「信頼できないテキスト」、つまり RAG チャンク、Web 取得結果、ビルドログなどの総量は、実際のインジェクションリスクの面積であると同時に、誤検知の面積でもあります。
筆者の場合、spec-rag 経由で IEEE 1800 や AMBA AXI の仕様書チャンクを大量に流し込みますが、規格文書は shall を多用する命令調テキストの塊です。構造的に「指示のように見えるデータ」になりやすいコーパスと言えます。
コンテキストが短いうちは「これはツール結果として返ってきたデータである」という境界が保たれやすく、混み合ってくるとその区別が曖昧になっていく、と考えると体感と整合します。
公開データで裏を取る
体感だけでは心許ないので、公開されている評価や実践報告を確認します。
NoLiMa: 32K トークンで性能半減
字面一致に頼れないよう設計された long-context ベンチマーク NoLiMa では、128K 以上のコンテキストを謳う 12 モデルを評価したところ、32K トークンの時点で 10 モデルが短コンテキスト時のベースラインの 50% を割り込んだと報告されています。上位モデルの GPT-4o でも 99.3% から 69.7% への低下が観測されたとのことです。
名目上のコンテキスト上限(128K〜1M)のはるか手前から劣化が始まる、というのがポイントです。
1M をあえて 200K に絞る実践報告
Claude Code の 1M コンテキストをあえて 200K 相当に絞り、早めにコンパクションするほうが結果もコストも良かったという実践報告があります。同記事では、Aider 作者の Paul Gauthier 氏による「25〜30K トークンを超えるとどのモデルも混乱し始める」という観察や、古いツール出力をマスクするだけでコストを 52% 削減しつつ解決率を 2.6% 改善した JetBrains Research の実験も紹介されています。
公式ベストプラクティスも /clear を推奨
Claude Code の公式ドキュメントにも、長いセッションではコンテキストが無関係な会話・ファイル内容・コマンドで埋まり、性能低下やモデルの注意散漫の原因になるため、タスク間で /clear を頻繁に実行するよう明記されています。
こうして見ると、「300K 以下」という筆者の体感値はむしろ緩いくらいで、UVM や AXI のようにシグナル名ひとつの取り違えが致命的なプロトコル準拠コードでは、もう少し絞ってもよさそうです。300K という数字自体に強い根拠はなく、1M 運用における「名目の 3 割程度で切る」という経験的な目安と捉えてください。
前提知識: /clear で消えるもの・残るもの
/clear を恐れずに使うには、何が消えて何が残るのかを押さえておく必要があります。Claude Code には 2 系統のメモリ機構があり、どちらも /clear 後の新しいセッションで再ロードされます。
| CLAUDE.md | 自動メモリ | |
|---|---|---|
| 書く人 | 人間 | Claude 自身 |
| 内容 | 指示・ルール | 学習した知見・パターン |
| 保存場所 | プロジェクト / ユーザー / 組織 | ~/.claude/projects/<project>/memory/ |
| ロードのされ方 | 毎セッション全文 | MEMORY.md の先頭 200 行または 25KB |
自動メモリは MEMORY.md がインデックスとなり、詳細は debugging.md などのトピックファイルに分離されて、必要になったときにオンデマンドで読まれる構造です。同一 git リポジトリの worktree 間で共有され、マシンローカルに保存されます。
つまり、/clear で失われるのは会話履歴(とそこに含まれる暗黙の文脈)だけです。会話履歴のうち残したいものを /clear の前に自動メモリへ明示的に書き出しておけば、実質的な損失はかなり小さくできます。
ベストプラクティス案
以上を踏まえて、筆者が現在落ち着いている運用です。
1. /context で監視し、300K の手前で区切る
/context コマンドでコンテキスト使用量と内訳を確認できます。300K に近づいたら、キリの良いところで次項のハンドオフノートを書かせてから /clear します。オートコンパクトの発動に任せるのではなく、自分のタイミングで区切るのがポイントです。ちなみに以下の様なツールバーにして視覚的にもすぐに確認できるようにしています。
2. /clear の前にハンドオフノートを書かせる
/clear の直前に、次のような形式で自動メモリへ書き出させます。
以下をハンドオフノートとして自動メモリに保存してください。
- 現在のタスクとゴール
- 完了済みの項目
- 次の一手
- 未解決の問題と、試してダメだったこと
- 関連ファイルのパス
MEMORY.md の先頭 200 行が次セッションで自動ロードされるため、ここにインデックスを置いておくと再開の立ち上がりが速くなります。引き継ぎメモを書いてから退勤する、という感覚に近いです。「試してダメだったこと」を残すのは、次セッションで同じ袋小路に入るのを防ぐためです。
3. 調査はサブエージェントに委譲する
コードベースの探索やドキュメント調査をメインの会話でやると、読んだファイルがすべてコンテキストに積まれます。サブエージェントは別のコンテキストウィンドウで探索し、結果の要約だけを返してくれます。公式ドキュメントでも、コンテキストが根本的な制約である以上サブエージェントは最も強力なツールの一つ、という趣旨の位置付けがされています。
4. 履歴に残す必要のない確認は /btw
ちょっとした確認質問に /btw を使うと、回答がオーバーレイ表示になり、会話履歴には一切入りません。コンテキストを消費せずに疑問を解消できます。
5. 部分的に圧縮したいときは /rewind の要約機能
全消しと全維持の中間が欲しい場面では、Esc キー 2 回または /rewind でメッセージのチェックポイントを選び、「そこ以降を要約」「そこまでを要約」を選択できます。試行錯誤のログだけ潰して結論は残す、といった使い方ができます。
6. MCP サーバー側で供給量を絞る
コンテキストの最大の消費源はツール出力です。Anthropic のツール設計ガイドでも、大量のコンテキストを消費しうるツール応答にはページネーション・フィルタリング・truncation の実装が推奨されており、Claude Code 自体もツール応答をデフォルトで 25,000 トークンに制限しているとのことです。1 回の広い検索ではなく、小さく絞った検索を複数回行うようエージェントを誘導するのが良い、という指針も示されています。
筆者の spec-rag でも、top-k とチャンク長を絞り、クエリに関連する節だけを返すようにしています。MCP サーバーを自作している場合、供給側からコンテキスト消費を制御できるのは大きな利点です。
7. 確実に強制したいルールはフックで
CLAUDE.md の内容はシステムプロンプトではなくユーザーメッセージとして注入されるため、厳密な強制力はありません。長コンテキストで指示遵守が揺らぐことへの根本対策としても、確実にブロックしたい操作は PreToolUse フックで技術的に enforce するのが確実です。
8. オートコンパクトを併用する場合は保存指示を書いておく
/clear ではなくコンパクションを使う場合も、CLAUDE.md に「コンパクト時は変更ファイルの一覧とテストコマンドを必ず残すこと」のような保存指示を書いておくと、要約時に重要な情報が落ちにくくなるとされています。
まとめ
- 長時間セッションでのツール呼び出し失敗とインジェクション誤検知の増加は、注意の希釈、失敗ループ、信頼できないテキストの蓄積、の 3 つでおおむね説明できそうです
- NoLiMa では 32K トークン時点で 12 モデル中 10 モデルが性能半減と報告されており、名目上限のはるか手前から劣化が始まるようです。300K 上限はむしろ緩めの目安かもしれません
- Claude Code のメモリ機構(CLAUDE.md + 自動メモリ)は /clear 後も再ロードされる設計なので、こまめにメモリして /clear は理にかなった運用と考えられます
- ツール出力が最大のコンテキスト消費源なので、MCP サーバーを自作している場合は供給側からの制御も効きます
体感から始めた話ですが、調べてみると公式ドキュメントも研究報告もおおむね同じ方向を向いていました。同様の症状にお悩みの方の参考になれば幸いです。
参考