[{"data":1,"prerenderedAt":264},["ShallowReactive",2],{"content-/make-diary-parallel-archived":3,"all-pages-for-dir":262,"og-image-/make-diary-parallel-archived":263},{"id":4,"title":5,"body":6,"category":243,"description":244,"extension":245,"meta":246,"navigation":247,"ogImage":248,"path":249,"project_name":250,"published":251,"publishedAt":252,"seo":253,"stem":254,"tags":255,"todo":248,"unpublished":251,"updatedAt":248,"__hash__":261},"pages/2026-05/2026-05-30/make-diary-parallel-archived.md","/make-diary の並列化を本番テストして、潔く棚上げした判断",{"type":7,"value":8,"toc":233},"minimark",[9,22,26,31,43,46,58,69,72,75,117,120,124,130,137,147,150,153,156,159,171,177,193,197,204,210,213,216,219,222],[10,11,12,13,17,18,21],"p",{},"毎朝叩いている ",[14,15,16],"code",{},"/make-diary"," を並列実行する試作ワークフロー ",[14,19,20],{},"make-diary-parallel"," を、本番フルランで1回だけ回してみた。速くなると期待して作ったものだが、計測した結果「2大コストは並列化では縮まない」と分かったので、潔く棚上げした。削除はせず、冒頭にアーカイブ経緯のコメントを残して温存している。この記事はその判断の記録だ。",[23,24,25],"h2",{"id":25},"なぜテストしたのか",[10,27,28,30],{},[14,29,16],{}," は毎朝1回叩く。日記を作り、決算データを取得し、Xポスト案まで作る。1本のコマンドで全部を順番にこなしているので、それなりに時間がかかる。",[10,32,33,34,36,37,39,40,42],{},"そこで「Chrome に依存しない部分を並列で走らせれば速くなるんじゃないか」と考えて、昨日 ",[14,35,20],{}," という試作ワークフローを作った。今日はそれを本番フルランで1回まわして、",[14,38,16],{}," 単体と比べて wall-clock がどれだけ縮むかを実測する「テスト回」のつもりだった。計測してから、結果次第で ",[14,41,16],{}," 側を書き換える段取りだ。",[23,44,45],{"id":45},"まず整合確認から",[10,47,48,49,51,52,54,55,57],{},"走らせる前に1つ気になっていた。試作を作ったあとに ",[14,50,16],{}," コマンド側を少しいじった気がして、機能定義時とコマンドの中身がズレている疑いがあった。正本はあくまで ",[14,53,16],{}," で、",[14,56,20],{}," はそれを参照して作った派生物だ。ズレたまま計測しても意味がない。",[10,59,60,61,64,65,68],{},"git の履歴を追ってもらったところ、",[14,62,63],{},"make-diary.md"," と試作ワークフローは同じコミットで同時更新されていた。「試作を作ったあとにコマンドを別途いじった」という心配は杞憂だった。唯一の差分は ",[14,66,67],{},"diff_estimates","（前日差分）の有無で、これは試作の方が正しく持っていて、コマンド側が古くて抜けているという逆の構図だった。整合は取れていると確認できたので、テストに入った。",[23,70,71],{"id":71},"本番フルランで顕在化した3つのバグ",[10,73,74],{},"素直に1回通って計測できれば理想だったが、走らせると3つのバグが次々に出てきた。",[76,77,78,93,107],"ol",{},[79,80,81,92],"li",{},[82,83,84,87,88,91],"strong",{},[14,85,86],{},"name"," 起動で ",[14,89,90],{},"args","（targetDate / runDate）が伝播せず即失敗した。"," 日付が渡らないまま起動して、ワークフローが開始直後に落ちた。生成済みのスクリプトに日付を直接埋めて回避した。",[79,94,95,102,103,106],{},[82,96,97,98,101],{},"Koyfin の import が cp932 で ",[14,99,100],{},"UnicodeEncodeError"," を吐いた。"," 出力に含まれる em dash（—）を Windows の既定エンコーディングが書き出せずに落ちた。",[14,104,105],{},"PYTHONUTF8=1"," を強制して回避した。",[79,108,109,116],{},[82,110,111,112,115],{},"sync エージェントが完了前に ",[14,113,114],{},"ok:false"," を返してワークフローが中断した。"," これが最大の中断要因だった。sync は実際には11件のログを正常に生成していたのに、エージェントが最初の1件だけ見て早々に諦め、全体を失敗扱いにしていた。",[10,118,119],{},"3つともリトライ前に issue を切ってから対処した。バグを潰しながら最後まで通したものの、「素の計測」はできていない。素直に1回通った数字ではないということは、後の判断で割り引いて見る必要がある。",[23,121,123],{"id":122},"振り返ってもらったら速くならない理由が見えた","振り返ってもらったら、速くならない理由が見えた",[10,125,126,127,129],{},"最後まで通したあと、",[14,128,16],{}," 単体と比べて結局速くなったのかを正直ベースで振り返ってもらった。結論は「大幅改善ではない」だった。",[10,131,132,133,136],{},"理由はシンプルで、",[82,134,135],{},"一番重い2つの処理が並列化では1秒も縮まないから","だ。",[138,139,144],"pre",{"className":140,"code":142,"language":143},[141],"language-text","/make-diary の主なコスト\n├─ sync（ログのフルスキャン）  約16分  ← 並列化しても縮まない\n├─ 記事書き（11本＋統合日記）  約16分  ← 並列化しても縮まない\n└─ データ取得（earnings / Koyfin / diff）\n       ↑ 並列化で「縮む」のはここだけ\n         sync 約16分の裏に重ねられる分のみ\n","text",[14,145,142],{"__ignoreMap":146},"",[10,148,149],{},"並列化の勝ち筋は、earnings の x-search と Koyfin / diff の取得を、sync のフルスキャン（約16分）の裏に重ねる点だけだった。重ねられる分が浮くのは確かだが、それで縮むのは全体の一部に過ぎない。理論上は ~30%（約15分）短縮の見込みだが、今回はバグ3つのせいで素の計測ができておらず、未実証のままだ。",[10,151,152],{},"さらにコストの内訳を見ると、write フェーズだけで約158万トークンを使っていた。11本の記事エージェントがそれぞれスキルや規約を読み直すので、そのぶん割高になる。複雑性とトークン増を払って、未実証の ~30% を取りに行く構図だ。",[23,154,155],{"id":155},"アーカイブ判断",[10,157,158],{},"整理すると、こうなる。",[160,161,162,165,168],"ul",{},[79,163,164],{},"一番重い sync 約16分と記事書き約16分は、並列化では縮まない。",[79,166,167],{},"縮むのはデータ取得を sync の裏に重ねる分だけ。しかも未実証。",[79,169,170],{},"逐次コマンドより部品が多く、現にバグが3つ出た。トークンも約158万増える。",[10,172,173,174,176],{},"複雑性とトークンを払う割に、得られる短縮が小さく、しかも実証できていない。今わざわざ乗り換える理由が薄い。なので「とりあえず ",[14,175,16],{}," コマンド単体でいい」と判断した。",[10,178,179,180,182,183,186,187,189,190,192],{},"ただ ",[14,181,20],{}," は削除しなかった。",[14,184,185],{},"make-diary-parallel.js"," の冒頭に、アーカイブした経緯・テスト結果・3つのバグ・再挑戦の前提条件をコメントとして残させた。将来また評価したくなったとき、何を測って何で見送ったかが一目で分かるようにしておくためだ。あわせて、コマンド側で抜けていた ",[14,188,67],{}," を ",[14,191,63],{}," の step 10 に追記した。",[23,194,196],{"id":195},"再挑戦するなら本丸は並列化じゃない","再挑戦するなら、本丸は並列化じゃない",[10,198,199,200,203],{},"振り返って一番大きかった気づきは、",[82,201,202],{},"本丸は並列化そのものではなく、sync のフルスキャン約16分を増分（incremental）化することだ","という整理だ。",[10,205,206,207,209],{},"sync を増分化できれば、旧版の ",[14,208,16],{}," も並列版も両方が速くなる。その土台ができて初めて、並列化の「重ね」効果が素直に乗ってくる。順番が逆だった。フルスキャンが重いまま並列化の薄皮をかぶせても、一番重い部分は重いままだ。",[10,211,212],{},"なので再挑戦の前提条件はこう置いた。まず sync を増分化する。次に今回出た3つのバグを本体に反映してから、クリーンに1回計測して実証する。それまでは棚上げのままにしておく。",[10,214,215],{},"なお、この調査の途中で巨大化したセッション（スクリーンショットの base64 で肥大したもの）が気になったので、session-backup スキルでバックアップを取りつつ古いものを掃除した。その経緯は別記事に分けて書く。",[10,217,218],{},"一連の確認と判断のあと、生成物と試作のアーカイブコメント、コマンドの修正をステージングして、意味単位でコミットした。",[23,220,221],{"id":221},"今日の学び",[160,223,224,227,230],{},[79,225,226],{},"速くしたいなら、まず一番重い処理を測る。今回は測る前に「並列化すれば速い」と思い込んで作ってしまった。測ったら、重い2つは並列では縮まないと分かった。",[79,228,229],{},"試作は削除せずアーカイブする。冒頭に「なぜ見送ったか・何を測ったか・再挑戦の条件」を残しておけば、未来の自分が同じ検討をゼロからやり直さずに済む。",[79,231,232],{},"効くのはボトルネックを直接削ることだ。薄皮の並列化より、sync のフルスキャンを増分化する方が効く。順番を間違えない。",{"title":146,"searchDepth":234,"depth":234,"links":235},2,[236,237,238,239,240,241,242],{"id":25,"depth":234,"text":25},{"id":45,"depth":234,"text":45},{"id":71,"depth":234,"text":71},{"id":122,"depth":234,"text":123},{"id":155,"depth":234,"text":155},{"id":195,"depth":234,"text":196},{"id":221,"depth":234,"text":221},"dev","毎朝の /make-diary を並列実行する試作を本番フルランで1回テストした。計測したら2大コストは並列では縮まないと分かり、3つのバグも顕在化したので、削除せずアーカイブして単体運用を続けることにした。","md",{},true,null,"/make-diary-parallel-archived","claude-code-tools",false,"2026-05-30T00:00:00.000Z",{"title":5,"description":244},"2026-05/2026-05-30/make-diary-parallel-archived",[256,257,258,259,260],"Claude Code","ワークフロー","並列化","make-diary","費用対効果","_yixAbESUCcWV06nUnPl3laP6FneMtEJqLbYQ0EwgPk",[],"https://log.eurekapu.com/og/blog/make-diary-parallel-archived.png?v=2026-05-30T00%3A00%3A00.000Z&title=%2Fmake-diary%20%E3%81%AE%E4%B8%A6%E5%88%97%E5%8C%96%E3%82%92%E6%9C%AC%E7%95%AA%E3%83%86%E3%82%B9%E3%83%88%E3%81%97%E3%81%A6%E3%80%81%E6%BD%94%E3%81%8F%E6%A3%9A%E4%B8%8A%E3%81%92%E3%81%97%E3%81%9F%E5%88%A4%E6%96%AD&author=Kei%20Komatsu&sig=d8a5a15e9e9f7a3e",1782528845482]