Claude Codeが遅いときに確かめる順番。33MBの記録を分解したら、38件で全体の4分の1だった

Claude Codeが遅くなる原因は、ほとんどの場合1つに絞られる。会話が長くなることだ。公式ドキュメントには、毎回の要求で会話の全体を送る、と書かれている。だから返事が遅いと感じたら、最初に見るのは回線でもモデルでもなく、いま抱えている文脈の大きさになる。

確かめる順番は、文脈の大きさ、大きい読み込みの有無、定期実行の有無。この3つで大半が片づく。

数字は2026年9月20日に、手元のセッションの記録を数えて出した。公式の記述はClaude Codeのドキュメントを同じ日に読んで確かめた。応答時間そのものは計測していない。

会話が長いほど遅くなる仕組み

やり取りのたびに、それまでの会話が丸ごと送られる。1行の質問でも、朝からの会話を全部抱えて飛ぶ。公式のドキュメントには「1日中開いたセッションでの1行の質問でも、会話全体ぶんの使用量になる」という趣旨が書かれている。

同じ内容を何度も送るのは無駄なので、プロンプトキャッシュが効く。前回と同じ前置きは読み直しの安い単価で済む。ただしキャッシュには寿命があり、公式には契約プランで1時間、使用クレジットを使っているときとAPIキーでは5分とされている。昼休みをはさむと、次の1回はキャッシュが切れて全部を読み直すことになる。

つまり遅さの正体は、送る量と、キャッシュが効いているかどうかの2つだ。

自分のセッションがどれだけ太ったかを測る

Claude Codeは、セッションの記録をファイルに残している。Windowsなら%USERPROFILE%\.claude\projects\の下に、プロジェクトごとのフォルダがあり、その中にセッションごとの.jsonlが並ぶ。

私がこの記事を書いているセッションの記録は、33.7MBだった。記録の件数は7,488件で、13種類に分かれている。同じプロジェクトの別のセッションは4.4MB、0.4MB、0.3MBだったので、突出している。

# 大きい順に並べる（Git Bash）
ls -laS ~/.claude/projects/*/*.jsonl | head

注意が要るのは、このファイルの大きさが、そのまま毎回送られる量ではないことだ。長くなると自動で要約が走り、古い部分は圧縮される。記録は圧縮前のものも残る。それでも、セッションがどれだけ太ったかの目安にはなる。

大きい記録38件で、全体の4分の1を占めていた

33.7MBの内訳を数えた。種類ごとに分けるとこうなる。

道具の結果が6割を占めている。返事の文章より、読み込んだファイルや取得したページのほうが重い。

もっと効くのは、大きい記録の偏りだ。100KBを超える記録は38件しかないのに、合計8.8MBで全体の26%を占めていた。いちばん大きい1件は1,012KB、1MBを超えている。上位10件だけで4.4MB、12.7%になる。

この38件が何かというと、大きなページの取得と、長いファイルの読み込みだ。1件で1MBのページを取り込むと、そのあとの会話はずっとそれを抱えて飛ぶ。遅くなったと感じる直前に、大きな読み込みをしていないかを思い出す。

対策は公式ドキュメントにも書かれていて、長い出力を伴う作業は下請けに投げて、要約だけを戻す形にする。ログの絞り込みなら、フックで先に必要な行だけにする例も載っている。

太った1件を見つける

どの読み込みが重かったかは、記録を1行ずつ測れば分かる。.jsonlは1行が1件なので、行の長さを見るだけでいい。

python -c "import sys;d=[(len(l.encode()),i) for i,l in enumerate(open(sys.argv[1],encoding='utf-8'),1)];d.sort(reverse=True);[print(f'{n//1024}KB 行{i}') for n,i in d[:10]]" セッションのjsonl

手元で回すと、上位10件が1,012KB、515KB、415KB、403KB、401KBと並んだ。行番号が分かれば、その行を開いて中身を見られる。私の場合はどれも、大きなページの取得と長いドキュメントの読み込みだった。

一度この並びを見ておくと、作業中に「いま重いものを入れた」と気づけるようになる。大きな資料を読ませる前に、必要な部分だけを抜き出して渡す。ページ全体ではなく、見たい節だけを指定する。この癖がつくと、セッションの太り方が変わる。

確かめる順番

私はこの順で見ている。

/contextで、いま何が場所を取っているかを見る。MCPの道具の定義、CLAUDE.md、会話の履歴が、それぞれどれだけ占めているかが出る。ここで会話の履歴が大半なら、話題が変わったところで/clearを打つ。関係のない作業に移るときは、続きから始めるより新しく始めるほうが速い。

次に/usageを見る。プランの使用状況と一緒に、キャッシュの効き具合が出る。要求のうち何割が読み直しで済んだか、直近で読み直しに失敗したのはいつかが分かる。ここで読み直しの失敗が多いなら、休憩をはさんだせいでキャッシュが切れている。

最後に/mcpで、つないでいるサーバーの一覧を見る。使っていないものを外す。公式ドキュメントによれば、MCPの道具の定義は既定で遅延読み込みになっていて、使うまでは名前だけが載る。それでもサーバーの数が多ければ、その名前と説明のぶんは常に載る。

手元の環境では、ユーザー全体にもプロジェクトにも、設定ファイルに書いたMCPサーバーは0件だった。それでもこの太り方になるので、原因はMCPではなく読み込みの量のほうだと分かる。

CLAUDE.mdは200行までにする

プロジェクトのCLAUDE.mdは、セッションの開始時に文脈へ読み込まれる。だから関係のない作業をしているときも、ずっと載り続ける。公式ドキュメントは、必要なものだけにして200行以内に収めることを勧めている。

手元の2つは22行ずつだった。この規模なら問題にならない。細かい手順を書きたくなったら、スキルに移す。スキルは呼ばれたときだけ読み込まれるので、常時の重さにならない。

定期実行を入れていると、待機中も文脈が飛ぶ

これが見落とされやすい。定期実行を仕掛けていると、その間隔ごとに処理が始まる。公式ドキュメントには、セッションが待機中でも定期実行はその間隔で動き、そのたびに文脈の全体を送る、と書かれている。

私はこのセッションで30分ごとの記事執筆を回している。1日回せば48回。そのたびに、そこまでの会話を抱えて飛ぶ。記録が33.7MBまで育った理由の一部はこれだ。

同じことは、別のセッションからのメッセージ受け取りや、目標の待機中の確認にも当てはまる。どれも「何もしていない時間」に動く。遅いと感じたときは、仕掛けたまま忘れている定期実行がないかを見る。要らなくなったら止める。

効かなかったこと

モデルを軽いものに変えても、文脈が大きいままなら効きが薄い。送る量は変わらないからだ。文脈を減らしてからモデルを選ぶ、の順番になる。料金の桁が変わる話は9月のモデルの料金を並べた記事に書いた。

再起動も効かなかった。セッションを開き直しても、続きから始めれば同じ会話を読み込む。効くのは/clearのほうで、こちらは新しく始めるので文脈が空になる。あとで戻りたいなら、先に/renameで名前を付けておく。

インストールをやり直すのも、遅さには関係がない。動かないときの切り分けはClaude CodeをWindowsに入れる記事に書いたが、遅さは別の原因だ。

確認していないこと

応答時間そのものは計測していない。ストップウォッチで測った数字は持っていない。書いたのは記録の大きさと、公式ドキュメントの記述だけだ。

環境変数で文脈の上限を変える方法や、MCPの接続を待たずに起動する設定を書いている記事もある。手元の環境ではその設定を使っていないので、効くかどうかは確認していない。

回線やマシンの性能が原因だったことは、私の環境では一度もなかった。ただし社内の代理サーバー越しに使っている場合は、そちらが原因のこともある。切り分けるなら、同じ質問を短い新規セッションで投げてみる。そこで速いなら、原因は文脈のほうだ。