開発eurekapu-nuxt4

case100 第III部の76論点を、Claude Codeのサブエージェント5並列で1日のうちに本版化した。叩き台のまま放置していた論点群が、夕方には全部CHAPTERSマスタに収まっていた。共通のindex.tsを5セッションで同時に触る運用も、ぶつからずに回った。

何をやったか

case100は、財務数値の読み解きを論点単位で深掘りしていくコンテンツ群で、第III部だけで76論点ある。各論点には「叩き台（要点だけ）」と「本版（深掘りノート＋仕訳＋BS/PL影響）」の2段階があり、これまで叩き台しか書いていなかった。

本版化はそれなりに重い。1論点あたり、

  • 設定（前提となる数値・取引内容）
  • 仕訳（複合仕訳含む）
  • BS/PLへの反映（残高試算表に反映して数字を動かす）
  • 解説テキスト

を書く必要がある。これを76論点、1人で順番に書いていたら何日かかるかわからない。

5セッション並列で分担した

Claude Codeのウィンドウを5枚開いて、各セッションに範囲を割り当てた。

  • セッションA: 人事・給与（17件、CHAPTERS 20-36）
  • セッションB: 設備投資（10件、CHAPTERS 37-46）
  • セッションC: 有価証券＋外貨建（8件、CHAPTERS 47-54）
  • セッションD: 資金調達・返済（18件、CHAPTERS 55-72）
  • セッションE: 税務7件＋突発3件（CHAPTERS 73-82）

各セッションには「自分の範囲のCHAPTERS番号と、参考にする叩き台のパス、本版のテンプレ」を最初に渡しただけ。あとは各セッションが自分のCHAPTERSを順に本版化していく。

人間（自分）の役割は、

  • 範囲分割と番号予約を最初に決める
  • 各セッションが詰まったら方針判断（複合仕訳の分け方、BS表示区分の選択など）
  • chrome-devtools MCPで貸借バランスの最終確認

だけ。実装本体はAIに任せきった。

共通index.tsで衝突しない運用が定石になった

5セッションが触るマスタは1ファイル。apps/web/app/data/notes/zaimu-suuchi-case100/index.tsにCHAPTERS配列が定義されていて、各セッションが自分の範囲のオブジェクトをここに追記する形になる。

最初は「絶対ぶつかる」と覚悟していた。git diffを取るたびにマージコンフリクトが出ると思っていた。しかし、以下の運用にしたらゼロ衝突で回った。

// apps/web/app/data/notes/zaimu-suuchi-case100/index.ts
export const CHAPTERS = [
  // ... 既存 ...
  // セッションA担当: 20-36
  { id: 20, ... },
  { id: 21, ... },
  // セッションB担当: 37-46
  { id: 37, ... },
  // ...
]

定石になったパターンは3つ。

1. 番号を最初に予約する

開始前に「Aは20-36、Bは37-46...」と番号レンジを固定で決め打ちする。各セッションは自分のレンジ外には触らない。これで配列上の挿入位置がぶつからない。

2. 編集前に必ずindex.tsを再読込する

セッション内でも、CHAPTERSを編集する直前に必ずReadでindex.tsを読み直す。他セッションが先にコミットしていた場合、ファイルの行数が変わっているので、Editのold_stringがズレて失敗する。「再読込→自分の番号範囲だけ挿入」を1セットにすると、何度繰り返してもぶつからない。

3. ステージングは選択ステージング

git add .は禁止。他セッションがまだコミットしていない差分を巻き込む。git add app/data/notes/zaimu-suuchi-case100/index.ts app/data/notes/zaimu-suuchi-case100/chapter-XX.tsのようにファイル名を明示的に指定する。これで「自分が今書いた論点だけ」のコミットになる。

このパターン、月次決算で複数クライアントを並行で進める運用にそのまま使える。各クライアントのファイルだけを触る・共通マスタは番号予約してから追記する・ステージングは選択する、の3点。

アニメーション衝突で仕訳プッシュが中間値で止まった

本版化の途中で、仕訳プッシュ時のカウントアップアニメーションがバグった。

複合仕訳を1秒以内に連続でプッシュすると、2つ目のアニメーションが1つ目の途中の値から始まり、結果として残高試算表の値が中間値で止まる。「現金 -2000」のはずが「-1247」で止まって動かなくなる。

最初は計算ロジックを疑った。buildTbViewModelを読み直し、加算順を見直した。が、原因は計算ではなく、アニメーション側だった。前のtweenがまだ走っている最中に次のtweenを始めると、前のtweenが残高をtargetに到達させる前に新しいstartValueで上書きされる。

修正は単純。仕訳プッシュ後に300ms待機を入れて、アニメーションが終わるのを待ってから次を受け付ける。連打防止のディレイを入れるだけで治った。

chrome-devtools MCPで全件貸借チェックした

76論点を全件、ブラウザで開いて貸借バランスを目視確認した。

- 残高試算表の左右合計が一致しているか
- 予告した数値（「現金が2000減ります」など）と実際の動きが一致しているか
- BSの「資産合計＝負債純資産合計」が成立しているか

chrome-devtools MCPのnew_pageでCHAPTERSページを開いて、evaluate_scriptで表内の数値を抽出して比較した。1論点あたり10秒くらいで判定できる。76論点を15分くらいで一周した。

3件、貸借が合わない論点が出た。いずれも複合仕訳の片側を書き忘れていた。Claude Codeが叩き台から本版化する過程で、叩き台の説明文に書かれていない暗黙の片側仕訳を落としていた。叩き台の精度が低い箇所が、本版化のミスとして顕在化した形。

人間が画面の違和感を拾う係、修正はAIが3件まとめて直す係。ここでも分担構図は同じ。

計画書のチェックボックスとセッションごとのコミット

進捗管理は計画書のmemo/2026-05-04/case100-honban-plan.mdのチェックボックスでやった。各セッションが論点を1つ本版化したら、対応するチェックボックスを[x]に更新してコミットする。

## セッションA: 人事・給与
- [x] CHAPTER 20: 給与振込
- [x] CHAPTER 21: 源泉所得税の納付
- [ ] CHAPTER 22: 社会保険料の控除

コミットメッセージはfeat(case100): セッションA Chapter 20-25 本版化のような単位。1セッション1論点1コミットだとログが膨れるので、5論点まとめて1コミットにした。

3時間で76論点が片付いた

朝10時に5セッションを起動して、昼過ぎには3セッションが完走、午後3時には残りも完走した。所要3時間。1人で順番にやっていたら、おそらく3日かかっていた。

並列の効きが体感できたポイントは2つ。

  • 各セッションが独立した範囲を持っていて、相互参照がない
  • 共通マスタへの追記パターンが「番号予約→再読込→選択ステージング」の3点で固定化された

逆に言うと、相互参照のある作業（チャプターをまたぐリンクや、共通composableの拡張）は並列化に向かない。1セッションが書き換えた共通関数のシグネチャが、他セッションのコードを壊す。今回はマスタへの追記オンリーだったから回った。

税理士・会計士の業務に重ねると、月次決算のように「クライアントごとに独立していて、共通マスタ（勘定科目体系など）には追記だけ」の構造はAIサブエージェント並列に向く。逆に税制改正対応のように「全クライアントの共通ロジックを書き換える」作業は1セッションで丁寧に回した方が安全、という線引きになる。

明日やること

  • CHAPTERS 83-100の叩き台を作る（第III部の残り18論点）
  • 本版化済み76論点に対して、Codexレビューを通す
  • アニメーション待機の300msが長く感じる箇所があるので、tween完了イベントを購読する方式に切り替える