毎朝の /make-diary を並列ワークフロー化できるか調査して試作スクリプトを検証した

毎朝走らせている /make-diary を眺めていて、中身が「日記生成」「Xポスト案」「決算チェック」の3系統を順番に流しているだけだと気づいた。違うことを順次でやっているなら並列化で短くできるはず、と思って Workflow 化が今回のユースケースに合うか調査を依頼した。結論は「全部は無理。でも5分のログ同期の裏に決算系を隠すのが最大の勝ち筋」。試作スクリプトをサンドボックスで走らせて、13分・74万トークンという実測値まで掴んだところで翌朝の本番ランに持ち越した。

まず全体像を掴む

/make-diary の中身を Claude Code に読ませたら、11ステップの長い順次パイプラインだった。前半はログ同期と記事生成、後半が /check-earnings と earnings-beat-scan のチェーン。並列化の可否は「後半で外部リソースを奪い合うか」で決まると見て、チェーン先の依存関係まで追わせた。

ポイントになったのは Chrome を何個使うか。/check-earnings の Koyfin 取得も、ブラウザ表示確認も、同じリモートデバッグ Chrome（1個）を触る。一方で earnings-beat-scan は x-search（Grok 経由）だけでブラウザに触らない、と確認できた。ここが効いた。

全並列は不可、と判断した

調べた結果、3系統に並列化の余地はあるが全部は並列にできないと判断した。理由はシンプルで、後半でChrome 1個を奪い合うから。日記のブラウザ確認とKoyfin取得を同時に走らせると、同じデバッグChromeのタブを取り合って事故る。

そこで「独立3トラックを絞ったWF」に方針を固めた。一番おいしいのは、5分かかるログ同期（sync-once.sh）が回っている裏で、ブラウザに触らない決算系を先行実行すること。sync待ちの空き時間に前倒しできる作業を詰める発想。

[ メインループ ] sync-once.sh 実行中（〜5分）
       └─ その裏で Koyfin取得（Chrome）を先行 → Turso取込
[ WF ] 日記生成 / Xポスト案 / earnings-beat-scan を並列
[ メインループ ] WF完了後にブラウザ表示確認

設計の途中でドキュメントの食い違いを発見した

WF を組む前に、気になっていた earnings-beat-scan の運用変更を裏取りした。これは「コンソール出力のみ」だったはずが、最近「公開記事として保存」に変わっている感触があった。実物を探したら、今朝09:09作成の earnings-beats-2026-05-28.md が実在した。運用が変わっているのは事実。

ところが SKILL.md 側は今も「コンソール出力のみ・content/に書かない」と明記したままだった。ドキュメントが実運用に追いついていない。WF はドキュメントを正典として各エージェントに読ませる設計なので、これを直さないと WF が古い挙動を再現してしまう。実運用に合わせて、SKILL.md と make-diary.md Step11 のドキュメント不整合3箇所を修正した。Step9 のXポスト案は正当なコンソール専用なので触っていない。

計画を Codex に2回レビューさせた

実装前に計画を memo/2026-05-29/make-diary-workflow-plan.md に書いて、グローバルルールどおり Codex でレビューした。初回の指摘は3点、いずれも妥当だった。

• Koyfin取得は WF完了後ではなく、sync実行中のメインループで先行実行せよ（順序を見落としていた）
• diff_estimates はKoyfin取込後に動かす（前日差分はデータが入ってから）
• 短縮効果の表現は「3トラック並列で大幅短縮」ではなく「sync待ちに決算系を前倒しして2〜4分削る」が正確

全面的に取り込んで計画を直し、resume --last で前回の文脈を継いだまま再レビューさせた。再レビューは「致命的な点なし」。ここで計画が固まった。

ワークフロースクリプトを実装した

Phase 1 として、既存の /make-diary は温存したまま、単体起動して検証できる独立ファイルとしてWFスクリプトを実装させた。ルールの二重管理を避けるため、各エージェントには既存の正典ファイル（make-diary.md・各スキル）を読ませる方式にしたのが肝。WF側にルールを写経すると、いつか今日みたいなドキュメント不整合をまた生む。

実装中にひとつ詰まった。node --check で構文検証すると top-level の return で弾かれる。これは Workflow ランタイムが本体を async 関数で包む仕様で、ランタイム同等の文脈（async でラップ）に置き直したら正常にパースできた。node 単体で弾かれただけだった。

SRE観点で1点だけ自分で改善を入れた。詳細記事エージェントが失敗すると parallel が null を返し、そのカテゴリが黙って欠落する。欠落をログに出して気づける形にした（「No silent caps」の方針）。

サンドボックスでスモークテストした

本番の content/ を壊さずに機構を検証したかった。「ログはあるが content ディレクトリがまだ無い日付」に書かせれば衝突しないと考えたが、調べたら全ログ日付に既に content ディレクトリが存在していて安全な日付が無かった。

そこで出力先をサンドボックス（memo/2026-05-29/wf-test/）にリダイレクトしたスモークテスト版を作り、既存ログ（2026-05-27）を入力に走らせた。5分の再syncは省略（既存ログ流用）、PNG書込が content/ にハードコードされる timeline はスタブ化。本番 content には一切触れていない。

結果、WF機構は全項目パスした。

生成物の品質は高かった。frontmatter は正確、視点ルール（筆者が主語・AIは道具）も守られ、匿名化（「ある資格試験」「自炊した教科書」）も vivid-writing も効いていた。本番スクリプトに軽微なバグを1件見つけて直した（統合日記エージェントがスキーマ未指定でパスではなく散文を返していた）。

費用対効果は見立てより微妙だった

正直に言うと、実測の費用対効果は思ったより渋い。機構は完璧に動いて生成物も良いが、13分・74万トークンかかった。しかも5分のsyncを省いた状態で、だ。一方で短縮効果は2〜4分どまり。サブエージェントは今のセッションと同じ課金枠で動くので追加の金銭課金は出ないが、トークン消費の大きさは無視できない。

Phase 2 は見送り、翌朝の本番ランで判断する

make-diary.md 本体の書き換え（Phase 2）はやらないことにした。マークダウンの正典は触らず、明日 本番スクリプトを全工程で一度だけ通して採否を判断する方針。明日は新しいセッションなので、本番スクリプト＋Chrome後処理を正しくオーケストレーションできるよう、ランブックを memo/2026-05-29/make-diary-parallel-RUNBOOK.md に書いた。翌朝6時の実行予定を Google カレンダーに登録した（6:00ポップアップ通知付き）。

今日の学び

• 並列化の可否は「独立しているか」より「共有する外部リソース（Chrome 1個）を奪い合うか」で決まる。SaaS で言えば、同じ承認画面を複数バッチが同時に触れない構図と同じ
• 「全部並列で速くなる」は幻想で、待ち時間（sync 5分）に前倒しできる作業を詰める方が現実的な勝ち筋だった
• WF のルールはWF側に書かず、正典ファイルを読ませる。さもないとドキュメント不整合をまた量産する。今日その不整合を実際に踏んだ
• 機構が動くことと、費用対効果が見合うことは別問題。実測のトークン量を見るまで採否は決めない

明日やること

• ランブックに従って make-diary-parallel を全工程で一度走らせる
• 実測の所要時間・トークン量を、今日のスモーク（13分・74万）と比較する
• sync裏のKoyfin先行実行が実際に2〜4分を削れているか確認する
• 見合うと判断したら Phase 2（make-diary.md 本体の差し替え）に進むか決める

関連記事

• 2026年5月28日の開発日記