開発claude-code-tools

毎朝叩いている /make-diary を並列実行する試作ワークフロー make-diary-parallel を、本番フルランで1回だけ回してみた。速くなると期待して作ったものだが、計測した結果「2大コストは並列化では縮まない」と分かったので、潔く棚上げした。削除はせず、冒頭にアーカイブ経緯のコメントを残して温存している。この記事はその判断の記録だ。

なぜテストしたのか

/make-diary は毎朝1回叩く。日記を作り、決算データを取得し、Xポスト案まで作る。1本のコマンドで全部を順番にこなしているので、それなりに時間がかかる。

そこで「Chrome に依存しない部分を並列で走らせれば速くなるんじゃないか」と考えて、昨日 make-diary-parallel という試作ワークフローを作った。今日はそれを本番フルランで1回まわして、/make-diary 単体と比べて wall-clock がどれだけ縮むかを実測する「テスト回」のつもりだった。計測してから、結果次第で /make-diary 側を書き換える段取りだ。

まず整合確認から

走らせる前に1つ気になっていた。試作を作ったあとに /make-diary コマンド側を少しいじった気がして、機能定義時とコマンドの中身がズレている疑いがあった。正本はあくまで /make-diary で、make-diary-parallel はそれを参照して作った派生物だ。ズレたまま計測しても意味がない。

git の履歴を追ってもらったところ、make-diary.md と試作ワークフローは同じコミットで同時更新されていた。「試作を作ったあとにコマンドを別途いじった」という心配は杞憂だった。唯一の差分は diff_estimates（前日差分）の有無で、これは試作の方が正しく持っていて、コマンド側が古くて抜けているという逆の構図だった。整合は取れていると確認できたので、テストに入った。

本番フルランで顕在化した3つのバグ

素直に1回通って計測できれば理想だったが、走らせると3つのバグが次々に出てきた。

  1. name 起動で args（targetDate / runDate）が伝播せず即失敗した。 日付が渡らないまま起動して、ワークフローが開始直後に落ちた。生成済みのスクリプトに日付を直接埋めて回避した。
  2. Koyfin の import が cp932 で UnicodeEncodeError を吐いた。 出力に含まれる em dash（—）を Windows の既定エンコーディングが書き出せずに落ちた。PYTHONUTF8=1 を強制して回避した。
  3. sync エージェントが完了前に ok:false を返してワークフローが中断した。 これが最大の中断要因だった。sync は実際には11件のログを正常に生成していたのに、エージェントが最初の1件だけ見て早々に諦め、全体を失敗扱いにしていた。

3つともリトライ前に issue を切ってから対処した。バグを潰しながら最後まで通したものの、「素の計測」はできていない。素直に1回通った数字ではないということは、後の判断で割り引いて見る必要がある。

振り返ってもらったら、速くならない理由が見えた

最後まで通したあと、/make-diary 単体と比べて結局速くなったのかを正直ベースで振り返ってもらった。結論は「大幅改善ではない」だった。

理由はシンプルで、一番重い2つの処理が並列化では1秒も縮まないからだ。

/make-diary の主なコスト
├─ sync（ログのフルスキャン）  約16分  ← 並列化しても縮まない
├─ 記事書き（11本＋統合日記）  約16分  ← 並列化しても縮まない
└─ データ取得（earnings / Koyfin / diff）
       ↑ 並列化で「縮む」のはここだけ
         sync 約16分の裏に重ねられる分のみ

並列化の勝ち筋は、earnings の x-search と Koyfin / diff の取得を、sync のフルスキャン（約16分）の裏に重ねる点だけだった。重ねられる分が浮くのは確かだが、それで縮むのは全体の一部に過ぎない。理論上は ~30%（約15分）短縮の見込みだが、今回はバグ3つのせいで素の計測ができておらず、未実証のままだ。

さらにコストの内訳を見ると、write フェーズだけで約158万トークンを使っていた。11本の記事エージェントがそれぞれスキルや規約を読み直すので、そのぶん割高になる。複雑性とトークン増を払って、未実証の ~30% を取りに行く構図だ。

アーカイブ判断

整理すると、こうなる。

  • 一番重い sync 約16分と記事書き約16分は、並列化では縮まない。
  • 縮むのはデータ取得を sync の裏に重ねる分だけ。しかも未実証。
  • 逐次コマンドより部品が多く、現にバグが3つ出た。トークンも約158万増える。

複雑性とトークンを払う割に、得られる短縮が小さく、しかも実証できていない。今わざわざ乗り換える理由が薄い。なので「とりあえず /make-diary コマンド単体でいい」と判断した。

ただ make-diary-parallel は削除しなかった。make-diary-parallel.js の冒頭に、アーカイブした経緯・テスト結果・3つのバグ・再挑戦の前提条件をコメントとして残させた。将来また評価したくなったとき、何を測って何で見送ったかが一目で分かるようにしておくためだ。あわせて、コマンド側で抜けていた diff_estimates を make-diary.md の step 10 に追記した。

再挑戦するなら、本丸は並列化じゃない

振り返って一番大きかった気づきは、本丸は並列化そのものではなく、sync のフルスキャン約16分を増分（incremental）化することだという整理だ。

sync を増分化できれば、旧版の /make-diary も並列版も両方が速くなる。その土台ができて初めて、並列化の「重ね」効果が素直に乗ってくる。順番が逆だった。フルスキャンが重いまま並列化の薄皮をかぶせても、一番重い部分は重いままだ。

なので再挑戦の前提条件はこう置いた。まず sync を増分化する。次に今回出た3つのバグを本体に反映してから、クリーンに1回計測して実証する。それまでは棚上げのままにしておく。

なお、この調査の途中で巨大化したセッション（スクリーンショットの base64 で肥大したもの）が気になったので、session-backup スキルでバックアップを取りつつ古いものを掃除した。その経緯は別記事に分けて書く。

一連の確認と判断のあと、生成物と試作のアーカイブコメント、コマンドの修正をステージングして、意味単位でコミットした。

今日の学び

  • 速くしたいなら、まず一番重い処理を測る。今回は測る前に「並列化すれば速い」と思い込んで作ってしまった。測ったら、重い2つは並列では縮まないと分かった。
  • 試作は削除せずアーカイブする。冒頭に「なぜ見送ったか・何を測ったか・再挑戦の条件」を残しておけば、未来の自分が同じ検討をゼロからやり直さずに済む。
  • 効くのはボトルネックを直接削ることだ。薄皮の並列化より、sync のフルスキャンを増分化する方が効く。順番を間違えない。