開発eurekapu-nuxt4

case100で本版化したばかりの76件の深掘りノートを、ライフサイクル軸で52件に統合し直す計画を立てた。Claude Codeが76件を読み返してA型対比・B型分岐・C型並置の3パターンを発見し、Codex（gpt-5.5）に6回レビューを回して致命的指摘を6点→2点→0点まで削り、最後はα-εの5並列セッションで実装まで走らせた。1日のうちに「計画→レビュー→並列実装」がひとサイクル回った。

なぜ統合しなおすのか

午前中に本版化した76件は、1論点1ファイルで仕上げてあった。「給与振込」「源泉所得税の納付」「社会保険料控除」がそれぞれ独立したノートとして並ぶ。

ところが本版を読み返すと、「給与振込→源泉預り→源泉納付」の3件は単独で読むより1つのライフサイクルとして並べた方が頭に入る。給与のサイクル中で「いつ預かって」「いつ国に納めるか」を時系列で見せる。1件1件をバラバラに読ませると、読者は時系列の地図を頭の中で組み立てなおす。

基準になったのがderivatives.vueだった。金利スワップを含む3パターン（変動受取/固定受取/ヘッジ会計適用）を1ページで対比している既存ノートで、読み終えた瞬間に「この型は強い」と分かった。3つを並べるから差分が立ち上がる。

ライフサイクル型A/B/C の発見

76件を再精査して、統合可能な束に名前をつけた。

  • A型（対比）: 同じ取引で会計処理だけが分岐する束（例: 売掛金の貸倒処理3パターン、税務上の引当金処理）
  • B型（分岐）: 同じ起点から条件で分岐するライフサイクル（例: 仕入→検収OK/NG/値引、固定資産取得→使用/除却/売却）
  • C型（並置）: 独立した取引を同じテーマで並べる（例: 各種源泉徴収、各種引当金）

A/B/Cのどれにも当てはまらないものは単独ノートのまま残す。76件のうち統合候補は約30件、残った46件は単独で完結している。30件を約7束に圧縮して、22件削減。最終形は52件になる。

この分類自体、Claude Codeが76件のタイトルとサマリを並べて「似た構造が3つある」と発見した結果。人間側で「derivatives.vueみたいな型が他にもありそう」と投げただけで、A/B/Cの3パターン名まで含めて分類が返ってきた。

計画書を作って Codex レビューに投げる

計画書はmemo/2026-05-04/case100-note-consolidation-plan.mdにまとめた。中身は以下。

  • 統合候補テーブル（22件→7束、それぞれA/B/C型を明示）
  • 第III部1（販売・売上債権管理）と第III部2（購買・製造）の統合余地
  • 横断カテゴリメタデータの仕様（束をまたぐ検索のため）
  • 代表numberルール（束の中で代表として表示するnumberの決め方）
  • nuxt.config.tsのマージ順序（既存ノートと統合束の表示順）
  • α/β/γ/δ/εの5並列セッション分割計画＋事前準備セッションζ

これをcodex exec -m gpt-5.5に投げる。指示は毎回「瑣末な点へのクソリプはしないで。致命的な点だけ指摘して」を入れる。

Codex 6回のレビュー変遷

1回目: rate limit で失敗

最初の試行はrate limitで弾かれた。プロンプトが長すぎたわけではなく、codex execに対する単純なrate制限。少し待って再投入。

2回目: stdinが届かない問題

Get-Content plan.md | codex exec ...のようにパイプで渡そうとしたが、stdinの内容がCodexに届いていない。プロンプト末尾の指示文だけでレビューが返ってきて、計画書本体が読まれていない応答になった。

切り替え。プロンプトの中に計画書の中身を直接埋め込む形にした。

codex exec -m gpt-5.5 "以下の計画をレビューして。瑣末な点へのクソリプはしないで。致命的な点だけ指摘して: $(cat memo/2026-05-04/case100-note-consolidation-plan.md)"

これで計画書本体がプロンプトに乗る。stdinのフォールバックを期待せず、最初からプロンプトに埋め込むほうが事故が減る。

3回目: 致命的指摘 6点

中身が読まれたCodexから6点の致命的指摘が返ってきた。

  • 横断カテゴリメタデータが束のid衝突を考慮していない
  • 代表numberルールが既存の番号体系（CHAPTERSの連番）と矛盾する
  • α/β/γ/δ/εの分担が依存関係を見ていない（β束がα束のヘルパーに依存）
  • nuxt.config.tsのマージ順序を変えると既存ノートのpathが壊れる
  • ζ（事前準備）セッションをα-εと並列で起動すると、α-εがζの成果物を見ずに走る
  • ロールバック手順が書かれていない

6点とも本質的だった。計画書を修正して再レビュー。

4回目: 致命的指摘 2点

修正版を codex exec resume --lastで再投入。同じセッションを継続することで、最初のレビュー文脈を保ったままレビューが進む。resume --lastを忘れると、Codexは初見として最初から読み直すので指摘の精度が落ちる。

返ってきた残り指摘は2点。

  • α-εの5セッションが共通のnotes/index.tsに同時に追記する競合手順が、午前中の本版化（5並列セッションで番号予約パターンを使った）の経験を計画書に反映できていない
  • 統合束のテストデータ（貸借バランス）の事前計算が手作業前提になっている

午前中にやった5並列セッションの「番号予約→再読込→選択ステージング」の運用パターンを計画書にコピペで持ち込んだ。テストデータは事前計算スクリプトの呼び出し方をテンプレ化した。

5回目: 致命的指摘 0点

resume --lastで再投入。返事は「致命的な指摘なし。実装に進んで良い」。承認をもらった。

6回目: 念のため別観点で確認

念のため「実装後に発覚しそうな落とし穴を1点だけ挙げて」と聞いた。返ってきたのは「dev serverが新規ファイルを検出しない可能性。Nuxtのfile watcherは新規ファイル追加に弱い」という1点。記録に残して、実装中に詰まったらすぐ参照できるようにした。

ζを別セッションに切り出さなかった

計画段階では「事前準備セッションζをα-εと別タイミングで走らせる」と書いていた。が、Codexの指摘5（ζの成果物をα-εが見ない問題）への対応として「ζを最初に走らせて完了確認してからα-εを起動」と書き直したものの、実装直前に方針を変えた。

ζを別セッションに切り出さず、メインのClaude Codeセッションでそのまま実行した。ζの中身は「統合束のid体系の決定」「notes/index.tsの最初の追記場所のマーカー設置」「テストデータ生成スクリプトの動作確認」の3つだけ。重い作業ではない。別セッションを起動するオーバーヘッドのほうが大きい。

判断軸を残しておく。「セッションを分けるコストより並列化のリターンが小さい作業は分けない」。1セッションあたり起動・コンテキスト共有・終了確認で最低でも数分かかる。ζのような30分作業を別セッションにすると、起動と終了で5分使う。

α-εの5並列で22件→52件を完走

計画通りα-εの5セッションを順次起動して、22件の単独ノートを7束（52件相当の束ね方）に統合し直した。3時間で完走。午前中に本版化したばかりの76件を、午後には52件にまとめなおして表示できる状態になった。

途中で詰まったのは1点だけ。Codexが念押しで挙げた「dev serverの新規ファイル検出問題」がそのまま発生した。新しい束のVueコンポーネントを作っても、ブラウザに表示されない。dev serverを再起動するとちゃんと出る。Vite/Nitroのfile watcherが新規ファイル追加に対して、既存ファイル更新と同じレベルでは反応しない仕様らしい。dev serverを起動しなおす運用に切り替えて、それ以外は全束が一発で表示された。

「未了事項ドキュメント→計画書からリファレンス」の運用

5セッションそれぞれが、自分の担当範囲の中で「ここは判断保留」「次のセッションで触る」となった項目を、独立した未了事項ドキュメントに書き出した。

  • memo/2026-05-04/case100-consolidation-todo-alpha.md
  • memo/2026-05-04/case100-consolidation-todo-beta.md
  • ... (γ/δ/ε)

メインの計画書case100-note-consolidation-plan.mdからは、これらのファイルへのリンクだけ貼る。計画書本体に未了事項を書き込むと、5セッションが同じファイルを編集してマージコンフリクトが起きる。各セッションが自分専用のtodoファイルを持つことで衝突がゼロになる。

このパターン、午前中の本版化作業のときから定着し始めていた。今日1日で「計画書本体は中央集権・未了事項は分散ファイル」の運用が固まった。

AI協働の三段構成

今日の流れを整理すると、Claude Code・Codex・並列5セッションが3段で噛み合っている。

  1. Claude Codeが計画立案: 76件を読んでA/B/Cのライフサイクル型を発見、22件→7束への統合候補を抽出
  2. Codexがレビュー: gpt-5.5に6回投げて致命的指摘を6点→2点→0点まで削る
  3. 並列5セッションで実装: α-εが22件を52件相当に統合、3時間で完走

人間がやったのは「derivatives.vueを基準にしたい」「Codexに見てもらって」「並列で行こう」の3つの判断と、各セッションへの「このid番号レンジを使って」という指示だけ。設計・レビュー・実装の本体はAIに任せた。

税理士・会計士の業務に重ねると、顧問先別マニュアルを業種別ライフサイクル（製造業/サービス業/不動産賃貸業）に統合しなおす作業に同じ構図が使える。各顧問先のマニュアルを独立して持つよりも、業種ライフサイクル単位で束ねたほうが「同じ業種の他社で使ったロジック」を再利用しやすい。Claude Codeが業種パターンを発見し、Codexが整合性をレビューし、並列セッションで束ねなおす、という三段はそのまま転用できる。

明日やること

  • dev serverのfile watcher問題を、Vite側の設定（server.watch.ignoreInitial等）で回避できないか調べる
  • 統合束52件をchrome-devtools MCPで全件貸借チェックする（午前の76件と同じ手順）
  • Codexレビュー6回分の差分を1つのドキュメントにまとめて、次回の計画立案テンプレに反映する