Claude Codeに渡すコンテキストを足すのをやめた — ツール出力を間引いたら長時間タスクの精度が戻った
私はずっと、コンテキストは足すほど良いと思っていました。CLAUDE.mdを厚くして、関連しそうなファイルを全部読ませて、ツールの出力もそのまま残す。情報が多いほどClaudeは賢く動くはずだと。
その信念は、3時間かかる移行タスクの途中で崩れました。Claudeが序盤に決めた設計方針を、終盤になって自分で忘れていたのです。間違ったファイルを2回触り、私が前半で「触るな」と言ったディレクトリに勝手に手を入れました。原因はプロンプトではありませんでした。コンテキストが太りすぎて、肝心な指示が埋もれていたのです。
そこで逆をやりました。足すのをやめて、間引きました。結果、トークンが約4割減って、長時間タスクの精度がむしろ戻りました。今回はその話です。
「足すほど賢い」が嘘になる地点
コンテキストには、効く量の上限があります。
Claude Sonnetは20万トークンの窓を持つと謳っています。でもSourcegraphのGeoffrey Huntley氏は、実際には14万7000〜15万2000トークンあたりで品質が落ちると報告しました。窓の容量と、実際に使える容量は別物だということです。
この劣化は「context rot」と呼ばれます。トークンが増えるほど、再現性と正答率が静かに下がる現象です。30分を超えるセッション、20ファイル以上を触るタスク、複数フェーズにまたがる推論。こういう長時間タスクで、まったく違う失敗の仕方が出てきます。私が遭遇したのはまさにこれでした。
新人に例えるなら、こうです。資料を3枚渡せば即戦力になります。同じ新人の机に資料を300枚積んだら、どこに何が書いてあるか探すだけで一日が終わります。情報量と戦力は、どこかで反比例に転じます。
私が間引いた3分類
何を消すか。私が間引いた対象は3つに分かれました。
1. ツール出力の生データ
これが一番効きました。npm testの全ログ、grepの何百行、APIレスポンスの巨大なJSON。Claudeはこれを全部コンテキストに溜め込みます。でも本当に必要なのは「テストが3件落ちた、ファイルはこれ」という結論だけです。
Anthropic自身も、ツール結果のクリアリングとコンパクションを公式の対策として用意しました。context editingでツール出力を消し、長い会話はcompactionで要約する。私が手でやっていたことに、ちゃんと名前と機能がついていたわけです。
私の運用では、ツール出力をそのまま残すのをやめて、要点だけ手元のメモに書き出し、生ログはコンテキストから外しました。これだけでトークンの大半が消えました。
2. 無関係ファイル
「念のため読ませておこう」で開いたファイルです。移行タスクなのに、関係ないコンポーネントを5つ読ませていました。安心料のつもりが、ノイズの仕入れでした。
3. 古い会話の往復
序盤の試行錯誤です。「このアプローチで行こう」と決まった時点で、そこに至るまでの失敗した3案は、もう要りません。決定だけ残して、過程は捨てます。/compactにカスタム指示を渡せば、重要な決定を残しつつノイズだけ削れます。
間引き前後の数字
同じ移行タスクを、間引き前と後で比べました。
| 項目 | 間引き前 | 間引き後 |
|---|---|---|
| 使用トークン | 約14万 | 約8万4000 |
| 設計方針の保持 | 終盤で逸脱 | 最後まで保持 |
| 私の再指示回数 | 6回 | 1回 |
| 触った無関係ファイル | 2件 | 0件 |
トークンは約40%減りました。でも本当に効いたのは、Claudeが序盤の指示を最後まで覚えていたことです。再指示が6回から1回に減りました。劣化の谷である14万トークン台を、そもそも踏まなくなったからです。
ここで強調したいのは、私は新しいテクニックを足していないという点です。むしろ引きました。RAGの層を増やすのとは逆の方向です。賢さを足すのではなく、邪魔を引いたら、元の賢さが戻ってきた。それだけの話です。
「足す」より「入れない」が難しい理由
正直に言うと、間引きは足すより難しいです。
足すのは簡単です。不安なファイルを開けばいい。判断が要りません。でも間引くには「これは要らない」と決める判断が要ります。消した情報がもし必要だったら、という不安と戦うことになります。
私の判断基準はシンプルです。「この情報は、今の1ステップを進めるのに直接効くか」。効かないなら入れない。あとで必要になったら、その時に取りに行けばいい。Claudeは必要なら自分でファイルを読み直せます。先回りして全部積むのは、私の不安を鎮めるためであって、Claudeのためではなかったのです。
Anthropicの新しいモデルは、残りコンテキスト量を自分で把握する「context awareness」を持つようになりました。終盤まで息切れせずタスクを続けられます。でもそれは、窓に余裕がある前提の機能です。最初から窓を生ログで埋めてしまえば、その余裕は最初からありません。
まとめ
長時間タスクで精度が落ちたとき、私の最初の反応は「情報が足りないのでは」でした。逆でした。情報が多すぎて、肝心な指示が薄まっていたのです。
やったことは3つです。ツール出力の生データを要点に置き換える。無関係ファイルを開かない。決まった後の試行錯誤を捨てる。これでトークンが4割減り、context rotの谷を踏まなくなり、Claudeが最後まで方針を保ちました。
コンテキストエンジニアリングというと、何をどう足すかの話に聞こえます。でも長時間タスクで効くのは、何を入れないかの判断のほうでした。机に資料を積むのをやめて、3枚だけ残す。新人が即戦力に戻るのは、そのときです。
コンテキスト設計の全体像 — System Prompt、Few-shot、RAGの統合から、足し算が逆効果になる80-20の境界まで — は Context Engineering 実践ガイド にまとめています。この記事は、その「引き算」側を長時間タスクで試した実録です。
この記事は役に立ちましたか？