Claude Codeのコンテキスト消費をセッションログで実測し、make-diaryの最大工程をサブエージェントへ委譲した

朝の /make-diary を回し終えたとき、コンテキストの目盛りは10%から41%まで進んでいた。 毎朝回すコマンドなので、どこかに無駄や詰まりがあるなら直しておきたい。 どの工程で31ポイント増えたのかを、そのセッション自身のログから割り出してもらうことにした。

9/17 のログが0件だった朝

06:04 に /make-diary を起動した。 対象日は前日の9/17になるはずだったが、同期するセッションログが1件もなかった。 調べさせると、~/.claude/projects で9/17以降に更新された jsonl は今朝のセッション1件だけで、最後の作業は9/16の15:11で途切れていた。 2台運用なので、別の機体で作業した日はこちらにログが残らない。

コマンドはここで対象日をどうするかを質問してきて、返事をするまで3分34秒止まっていた。 対象日を9/16に遡らせて先へ進めた。

途中にもう一つ回り道があった。 コマンドの手順には、表示確認用にデバッグ用の Chrome を立ち上げる工程がある。 ところが Chrome DevTools MCP が繋がっていたのは、ふだん使いの Chrome（メールやスプレッドシートのタブが開いているほう）だった。 デバッグ用のほうはメモリを食うだけだと Claude Code が判断し、その場で落とした。 前日には、dev サーバーがメモリ不足で落ちていた。

あとは81銘柄の決算データを取り、記事と統合日記を書かせ、evals と表示確認を通した。

Codex レビューの利用枠切れ

終盤、記事の Codex レビューが走らなかった。 エラーは You've hit your usage limit で、枠が戻るのは9/20の5:41だった。 コマンドはレビューなしで先へ進み、d80a62fb（107ファイル）でコミットした。 コミット時の Codex ゲートのほうは、差分が22,863行あったので自動でスキップされた。

この失敗には「そうそう、レートリミットになってるんだよ、codex。」と返した。 返ってきた説明によると、モデル指定を変えても同じアカウントの枠なので、Codex CLI 経由は全滅だった。 日記本体は evals（error 0、warn 0）と目視の表示確認を通してあるので、レビュー抜きでも公開状態として問題はないという。 それを聞いて「OK、コミットプッシュしといて。」と頼んだ。

origin より2コミット先行していて、1つは別セッションが入れた韓国株の記事だった。 2つまとめて c3e1f0e7..c8462a65 で push された。

10%から41%までの内訳

07:33、朝のセッションの URL を貼って振り返りを頼んだ。 「もっと効率的に処理できる箇所とか、なんか詰まっているところがあるんだったら、それはコマンド側を修正してほしい」とも伝えた。

目盛りの10%と41%を、ログの usage（cache_read、cache_creation、input の合計）で測り直してもらうと、コマンド本文を読んだ直後が12.8万トークン、push 後が41.2万トークンだった。 増分は28.3万トークンになる。 工程ごとに引き算した上位5区間は、次のとおりだった。

最大の7.6万トークンは、保有銘柄のデイリーニュース（position-news）をメインのセッションで回していた分だった。 スキル本文の16,700字に、x-search の回答6本で41,500字、さらに記事本文の書き出しが積み重なる。 サブエージェントへ任せれば、メインの消費は往復5千トークンで済む見込みだという。

詰まりは2か所と報告された。 日付判定の質問で3分半止まったことと、Codex の利用枠切れである。

Step 9 前半の2.2万のうち約0.8万は、デバッグ用 Chrome を起動し、MCP がそちらに繋がっていないと気づいて落とすまでの往復だった。 Step 8 では window.scrollTo が効かず、スクショを1枚むだに撮っていた。

コマンド側で直した9か所

頼んでいたとおり、コマンド側にも手が入っていた。

• Step 1：ログが0件なら、質問せずに前日へ遡る（最大3日）
• Step 8-1：デバッグ用 Chrome の起動を削除する（MCP は --autoConnect でふだんの Chrome に繋がる）
• Step 8-3：window.scrollTo を、実際に効いたスクロール関数に差し替え、スクショ名を固定する
• Step 8.5：position-news をサブエージェント（opus）へ委譲する
• Step 10：決算ビートの洗い出しも、同じ委譲先が続けて実行する（x-search を1本のエージェントに寄せて直列を保つ）
• Step 11〜11.9：各節の7,150字を参照ファイルへ移す（本文は変えず、diff で一致を確認）
• Step 14：掃除の rm 対象を、実際に撮るスクショ名に合わせる
• Step 15：usage limit なら即スキップする
• 実行モデル：メインのモデルは切り替えられないので、既定と違っていたら1行報告して進む

Step 11〜11.9 の統計チェーンは、もともとサブエージェントに任せていた。 それでも手順の本文はコマンド本体に書いてあったので、メインが実行のたびに読み込んでいた。 委譲の説明で足した分を差し引いた正味で、コマンド本文は43,650字から39,700字になった。

見込みでは、増分28.3万のうち約11万トークンが減る（委譲の往復1万を差し引いた数字）。 統合日記をメインで書く工程（1.7万）は、メインがトピックを持っていて委譲しにくいので、そのまま残してある。

「はい、コミットプッシュしてみてください。」と頼み、bc68262f（5ファイル、+288／−150行）で push まで済ませた。 続けて、実行した内容を非公開の記事にまとめてもらった。 明日確認しやすくするためである。 ログから usage の推移と増分の大きいターンを出す計測スクリプトも、一緒に 77a5d2f6 で残した。

10時過ぎの dev サーバー

10時過ぎには、dev サーバーが落ちていないかを確かめた。 バックグラウンドタスクは停止扱いになっていたが、Nuxt 本体（6:11 起動）は生きていて、http://localhost:3000/ は HTTP 200 を返した。 メモリの空きは 4.49GB / 31.93GB で、圧迫の主因は chrome-devtools-mcp が3本で約2.3GB 常駐していることだった。 朝にデバッグ用 Chrome を落としたのも、同じメモリの事情からである。

2月に止まっていた参考書のコンテンツ化

14:38、eurekapu-nuxt4 で開いていたセッションから、まったく別の探し物を頼んだ。 会計の参考書を裁断して、論点をコンテンツにしようとしていた形跡である。 どこかにあると思っていたが、どのリポジトリでやったかは覚えていなかった。

最初に見つかったのは、記憶していた予備校のテキストのデータで、書籍ナレッジベースのリポジトリ（book-knowledge-base）に入っていた。 続けて、連結の論点を整理した形跡も合わせて横断検索した。 worktree の重複を除いて mdx-playground の本体ツリーを探すと、internal/ から書籍のスキャン画像と連結エンジンの設計書が出てきた。

本命は mdx-playground の連結精算表シミュレーター（2026年2月1日〜6日）だった。 ただし、スキャン元は記憶していた予備校ではなく、別の予備校のテキストだった。 記憶していたほうのテキストは別のリポジトリに取り込まれていたが、コンテンツ化に使った形跡は見つからなかった。

「だからmdx-playgroundのとこってことっすね」と返しているうちに、当時のことを思い出してきた。 今日はもう走りに行きたかったので、非公開のドキュメントにまとめてもらい、dev で表示を確かめたところで切り上げた。 読むのは明日にする。

振り返り

• 7.6万トークンの大半は、スキル本文と x-search の回答を読み込んだ分で、書き出しは7,500トークンだった。この工程の重さは、読み込む量で決まっていた
• 委譲してある工程でも、手順の本文がコマンド本体にあればメインが読む。委譲の有無と本文の置き場所は、別々に点検する
• 半年以上前の作業は、記憶していた予備校の名前からして違っていた。残っていたスキャン画像と設計書のほうが、記憶より正確だった

約11万トークン減るというのは、まだ見込みの数字である。 次の /make-diary を回したあとで、非公開のドキュメントに用意した比較表へ実測を書き込む。