make-diaryの削減は4.6万トークン止まり、基準にした前日の統合日記が軽すぎた

前日に入れた改良が効いたかどうかは、朝の1回を回せばわかるはずだった。

/make-diary はメインのコンテキストを使いすぎていた。 前日、一番大きかった position-news と earnings-beat-scan をサブエージェントへ移した。 保有銘柄のニュースまとめと、決算ビートの抽出である。 どちらも外から材料を集めてくる工程で、メインで回すと集めた材料がそのまま残る。 あわせて、途中で詰まっていた2か所も直してある。

見込みは、終了時の約41万トークンが30万前後まで減ること。 その差、11万トークン。

20項目のチェックリスト

数え方から先に固めさせた。 セッションログのどこをどう数えれば「終了時のコンテキスト」になるのか、前日のログで確かめてもらった。 そのうえで、今日確かめる20項目をチェックボックスにして、前日の非公開記事へ書き込ませた。 場所は「翌日の確認手順」の直後、節の名前は「2026-09-19 の確認チェックリスト」にした。 前日の記事には、翌日どう確かめるかまで書いてある。 その続きに、今日ぶんの20項目が並ぶ形になった。

朝の実行が終わったらしいので、「終わったみたいですよ」と声をかけて、残りのチェック項目を確かめさせた。

減ったのは4.6万トークン

終了時は37.4万トークンだった。 見込みの30万前後には届いていない。 増分で見ると28.4万から23.8万で、減ったのは4.6万にとどまる。

外へ出したのは、消費の一番大きい2工程だった。 それで4.6万なら、まず疑うのは改良の側になる。

ところが、疑う先は改良ではなかった。

基準にした数字の出どころ

委譲した2工程は、見込みどおり消えていた。 代わりに膨らんだのが Step 5（統合日記の作成）で、1.7万から7.1万へ増えている。

前日の実行は、日記の推敲手順を飛ばして軽く出ていた。 比較の基準にした41万トークンには、本来かかるはずの Step 5 が入っていなかったことになる。

Step 5 を除いて比べ直すと、前回26.7万に対して今回16.7万で、10.0万減。 見込みの11万とほぼ同じである。

改良は効いていた。 効いていないように見せていたのは、前日に自分で取った基準のほうである。

差し引きは、分子より先に分母を疑わないと読み違える。 今回の分母は、前と同じ条件で回したつもりの1回だった。 そのつもりが崩れていても、合計だけを見ているかぎり表には出てこない。

統合日記を誰が書くか

続けて、Step 5（統合日記の作成）の設計に手を入れた。

これまでメインは、詳細記事の全文を読んでから統合日記を書いていた。 そこを、記事エージェントに日記用のサマリーを返させる形に変えた。 記事エージェントが自分の記事から要約を作り、メインはそれだけで統合日記を書く。 メインは詳細記事の全文を読まない。 返ってきた要約を本文と突き合わせるレビューもしない。

統合日記の材料は、返ってきた報告文だけになる。 要約の精度は、記事を書いた本人に預けることになる。 メインが読む量は、そのぶん減る。

直したのは3ファイル。

• コマンドの Step 5（.claude/commands/make-diary.md）
• 記事エージェントへの指示文
• 残っていた実測値の更新

9c2b9f38 にまとめてコミットした。 入っているのはこの3ファイルだけである。

効果の数字は、次にコマンドを回すまで出ない。

学び

• 見込みと実測がずれたら、改良より先に基準を疑う。今回は分母にした1回が推敲手順を飛ばしていて、合計だけ見ているかぎり気づけなかった
• メインの消費を減らす手は、重い工程を外へ出すことだけではない。外から受け取るものを全文から要約に変えるのも同じ方向の手になる