/context で使用量を確認して、MCPサーバーを止めて、余計なメモリファイルを消しました。起動時点の使用量は、確かに下がりました。この手順は、こちらの記事が詳しいです。
それでも、作業を始めて30分もすると、また Compacting conversation... が出ます。
起動時に空けた席は、作業を始めた瞬間から埋まっていくからです。埋めているのは、読み込んだファイルの中身と、コマンドの実行結果と、会話そのもの。ここは /context の内訳には出てきません。作業のたびに増えるので、削り方も別になります。
自分がやっている減らし方を、手順として書いておきます。
1. ファイルを丸ごと読ませない
いちばん効きます。数千行のファイルを1本読ませると、それだけで数万トークンが載ります。
先に場所を特定してから、その周辺だけ読ませます。
# ❌ 「このファイルを見て直して」→ 全部載る
# ✅ まず該当箇所を探す
grep -rn "handle_submit" ./includes/
# 出た行番号の周辺だけを読ませる
sed -n '300,360p' includes/class-handler.php
Claude Code に頼むときも、範囲を指定します。
❌ includes/class-handler.php を読んで、バリデーションを直して
✅ includes/class-handler.php の 300 行目付近にある handle_submit の
バリデーション部分だけを見て直して。周辺 60 行程度で足ります
どこにあるか分からないときも、いきなり開かせません。先に検索させて、当たりをつけてから読ませます。
✅ まず grep で validate という語を含む箇所を探して、
候補の一覧（ファイル名と行番号）だけ出して。
中身を読むのは、どれを見るか決めてからにして
2. ツールの出力を、全部流さない
テストやビルドの出力は、成功部分が長いだけで、必要なのは失敗箇所だけです。
# ❌ 全部流す
composer test
# ✅ 失敗だけ取り出す
composer test 2>&1 | grep -A 10 -E "FAIL|Error|Exception"
# ✅ 件数だけ先に見て、必要なら詳細
composer test 2>&1 | tail -20
ログも同様に、範囲を絞ってから渡します。
# ❌ tail -f でログを全部
# ✅ 該当時刻の前後だけ
sed -n '/2026-07-27 14:2/,/2026-07-27 14:3/p' debug.log
git diff も、そのまま渡すと巨大になります。ファイルを絞るか、統計だけ先に見ます。
git diff --stat # まず全体像
git diff -- includes/class-handler.php # 見る場所を決めてから
3. 調査は、サブエージェントに投げる
調査は、過程が長くなります。あれを見て、違った、次を見て、の試行錯誤が全部メインの会話に積まれると、結論に着く頃には席が埋まっています。
サブエージェント（Task ツール）に任せると、途中で読んだ内容はメインに載りません。返ってくるのは結論だけです。
依頼するときの形を、置いておきます。
サブエージェントで調査してください。
【調べること】
このプラグインで、ユーザー入力を受け取ってDBに保存している箇所を
すべて洗い出す
【前提】
- 対象は includes/ 配下のみ。vendor/ は除外
- WordPress プラグイン、PHP 8.3
- $wpdb を直接使っている箇所と、WP の API 経由を区別したい
【返してほしい形】
- ファイル名 : 行番号 : 関数名 : 直接かAPI経由か
- 一覧だけ。コードの中身は貼らないでください
大事なのは、最後の「一覧だけ、中身は貼らない」です。これを書かないと、調査結果として大量のコードが返ってきて、結局メインに載ります。
もうひとつ、前提を書くこと。サブエージェントは、メインの会話を知りません。こちらが当然だと思っている条件を書かずに投げると、対象外のディレクトリまで調べた答えが返ってきます。自分はこれで一度、空振りしました。
4. 自分で区切る
圧縮に区切られると、何が残って何が落ちるかを選べません。自分で区切れば、必要な結論だけを持って次に行けます。
区切るタイミングは、作業の性質が変わるときにしています。調査が終わって実装に入るとき。実装が終わってレビューに入るとき。
（区切る前に、持ち越すものを書き出させる）
ここまでで分かったことを、次のセッションに渡す形でまとめて。
・確定した事実
・変更が必要なファイルと箇所
・まだ調べていないこと
コードは貼らず、箇条書きで
これを受け取って、新しいセッションの冒頭に貼ります。読んだファイルの中身は持ち越されず、結論だけが引き継がれます。
5. 常時見えるようにしておく
減らす作業をしても、見えないと続きません。ステータス行に残量を出しておくと、増え方の癖が分かります。
npx ccstatusline
自分の場合、これを見るようになってから、「この頼み方をすると一気に減る」というパターンが把握できました。だいたい、大きなファイルを読ませた直後です。
惜しむ場所を、桁で見る
節約を始めると、細かいところが気になってきます。ただ、桁を確かめないと、無駄な我慢をすることになります。
CLAUDE.md に毎回ルールを復唱させる手法があります。コンテキストがもったいない気がして、しばらく試しませんでした。実際に入れてみると、ほとんど気になりませんでした。ルール一式はせいぜい数百トークンで、ファイル1本の読み込みとは桁が違います。
逆に、MCPを削りすぎたときは、必要な機能が使えなくなって、手作業に戻る時間のほうが高くつきました。
減らす対象を選ぶときは、まず桁を見る。数百トークンの節約に手間をかけるより、数万トークンの読み込みを1回減らすほうが効きます。
早見でまとめ
-
/contextに出るのは起動時の固定分。作業中に積むぶんは別に減らす - ファイルは grep や行範囲で絞ってから読ませる。丸ごとが最も高い
- テスト・ログ・diff は、失敗箇所や対象ファイルに絞ってから渡す
- 調査はサブエージェントへ。「一覧だけ、中身は貼らない」と「前提」を必ず書く
- 圧縮される前に自分で区切る。持ち越しは箇条書きで書き出させる
-
npx ccstatuslineで残量を常時表示し、減り方の癖を掴む - 惜しむ対象は桁で判断する。数百トークンより、1回の大きな読み込み
起動時の掃除は一度で効きますが、天井があります。そこを削り切っても足りないときは、渡し方のほうを直すと、まだ余地があります。役に立ったらストックして、Compacting が増えてきたとき見返してください。
ふだんはraplsworks.comで、WordPressプラグイン開発やClaude Codeまわりのことを書いています。