朝イチの一斉バグスキャン運用——4プロジェクトを「洗い出しMD→修正→見送り記録」で回した一日

朝5時44分、最初のプロジェクトに「潜在的なバグを全部スキャンして、洗い出しをマークダウンにして、修正とリファクタリングまでやって」と投げた。5分後、同じ依頼文をほぼコピペで2つ目のプロジェクトにも投げた。この日は結局、夜までに4つのプロジェクトで同じ型のバグスキャンを回すことになった。

依頼の型は1つだけ

どのプロジェクトにも投げたのは、実質これだけ。

1. プロジェクト全体をスキャンして潜在バグを洗い出す
2. 洗い出しを memo/ のマークダウンに残す
3. 検証しながら修正する
4. 修正したもの・見送ったものを理由付きでマークダウンに記録する
5. テストを追加して、コミット＆プッシュ

ポイントは4の「見送りも記録させる」こと。スキャンの指摘は誤検知や意図的設計を含むので、「直した21件」だけでなく「直さなかった3件と、その理由」が残っていないと、次にスキャンしたとき同じ指摘を再検証する羽目になる。

1本目: mdx-playground（24件中21件修正）

スキャン結果は24件。memo/2026-06-10/bug-scan-findings.md に洗い出させてから、1件ずつ該当コードを読んで検証→修正という流れで進めてもらった。

見送り判断の例が面白かった。BlogCalendar の「SSR時はダミー値を返す」コードは一見バグに見えるが、コメントに過去の hydration 対応として設計意図が書いてあったため、意図的設計と判定してスキップ。コードコメントが半年後の誤修正を防いだ形になる。逆に隣の指摘は実バグで、そちらは修正された。

修正後にテストを回したら19件失敗した。ここで焦らず「自分の変更起因か、既存の失敗か」を切り分けさせたところ、追加した4テストはすべて pass で、失敗は既存のデータ整合性起因と判明。最終的にテスト16,188件 pass、回帰ゼロで着地した。

仕上げに /simplify で4つのクリーンアップエージェント（Reuse / Simplification / Efficiency / Altitude）を並列に走らせた。new Date( の直パースが291・292・315行に散らばって残っているのを拾って統一するなど、3件を修正。コミットは25ファイル、+503/-166。作業前から変更されていた _redirects や別作業の記事はステージから除外させた。

2本目: eurekapu-nuxt4（19件修正・5件誤検知、ついでに脆弱性72件）

こちらも24件検出。セキュリティ系5件から潰し始めて、クラッシュ系、計算ロジック系、サーバー系の順に検証してもらった。結果は19件修正・5件は誤検知として見送り。テスト全1,789件 pass、lint も型チェックもクリーンで、修正19件と見送り5件（理由付き）をマークダウンに記録してコミット・プッシュ。

このプロジェクトでは追加で依存パッケージの脆弱性対応も頼んだ。音声入力が「リズムパッケージの贅沢性」と文字化けした指示を「依存パッケージの脆弱性ですね」と読み替えて pnpm audit から始めてくれたのは助かった。脆弱性は72件（critical 2件含む）。更新したらビルドが落ちて、原因は better-auth 1.4→1.6 で getMigrations のエクスポート場所が better-auth/db/migration に移動していたこと。利用箇所を全部追わせて修正し、最終的に No known vulnerabilities found まで持っていった。

3本目: 連結シミュレーターの全パターンバグ

朝6時、mdx-playground の /consolidation-simulator に戻った。開始持分と目標持分を変えると連結修正仕訳がインタラクティブに切り替わるコンテンツなのだが、取得5パターン・売却6パターンの全部でどこかしら壊れていた。

既存テストを回すと16件失敗。原因を追わせたところ、連結精算表ビルダーに3系統のバグが集中していた。

• 勘定エイリアス漏れによる貸借不一致（連結除外系で16万、段階取得系で1,800のズレ）
• S社株式簿価の単価取り違え
• 持分法の売却仕訳が片側だけ生成されて画面から消える

プリセット全11パターンで貸借一致とあるべき残高を検証するテストを追加させ、370件全 pass で確定。

数値例の出典を忘れていた

修正が終わってから、ふと「この数値例、何の参考書を元に作ったんだっけ」と聞いてみた。自分でも完全に忘れていた。コード内コメント、当時の日記記事、Dropbox の蔵書スキャン、Turso の蔵書DBを突き合わせて調査してもらい、連結会計の参考書2冊に確定。専用の出典メモが残っていなかったので、今回 memo/2026-06-10/consolidation-example-sources.md として記録を残させた。

さらに「設例の支配獲得日の利益剰余金、書籍と微妙に数字が違うけど意図的だっけ？」と聞いたら、書籍のスキャン画像の該当ページまで実際に開いて突き合わせた上で「意図的」と回答が返ってきた。シミュレーターのデフォルト値は全11パターンを1つの前提セットで回すための簡略版として最初のコミットから別建てで設計されていて、書籍の正確な数値は精算表ビューアと整合性テストの側で保持されている。この役割分担も出典メモに追記させた。4ヶ月前の自分の設計判断を、AIに発掘してもらった格好だ。

4本目: mementomori と資格試験アプリ

午前中の残りで、小さいプロジェクトにも同じ型を適用した。

mementomori は Cloudflare Workers の小さなアプリ。バグ調査をドキュメントに残させてから修正、という同じ流れで、18件の問題を発見して14件を修正。テストが入っていなかったので vitest を導入して45件追加し、wrangler のバンドル確認まで通した。

不動産系資格の学習アプリでは、依頼に1つ条件を足した。「解いたか解いてないか、間違ったか間違ってないかの判定ロジックに集中的にバグがあると思う」と当たりをつけて、そこを重点レビューさせたのだ。結果はビンゴで、34件のバグ・脆弱性のうち、解答判定の致命バグ4件がまさにその周辺に集中していた。共有判定ロジックをモジュールに切り出してもらい、テスト52件（JS 39 + Python 13）を追加。

このプロジェクトでは途中、review-progress.js の差分が908行に膨らむ事件があった。sed が改行コードを CRLF から LF に変換してしまっていたのが原因で、元の CRLF に戻して差分を最小化。Windows 環境で sed を使った編集をさせるときの古典的な罠だった。コミット前には Chrome DevTools でブラウザを開かせて、×解答が解答済みとして正しくロックされるかまで表示確認してからコミットした。

学び

• 同じ依頼文を使い回せる。「スキャン→洗い出しMD→検証修正→見送り記録→テスト→コミット」の型は、Nuxt のモノレポでも Workers の小物でも素の HTML+Python のアプリでも、そのまま通った。プロジェクトごとに依頼を練り直す必要がなかった
• 見送りの記録が資産になる。誤検知5件・意図的設計3件を理由付きで残したことで、洗い出しMDが「指摘リスト」から「次回スキャンの照合台帳」に変わった
• 人間の仕事は当たりをつけること。資格試験アプリで「判定ロジックが怪しい」と一言添えただけで、致命バグ4件がその周辺から出てきた。スキャン自体は任せても、どこが事故りやすいかの土地勘は出す価値がある
• テスト失敗は切り分けてから騒ぐ。19件失敗の報告を見た瞬間は手が止まったが、「自分の変更起因か既存か」を切り分けさせたら新規分は全 pass だった。失敗件数の絶対値より、差分で見る

4プロジェクト合計で、修正88件、追加テスト100件超。朝の数時間でこれだけ回ったのは、依頼の型を1つに固定して、判断（見送り・当たりづけ・ステージ範囲）だけ自分が出す分担にしたからだと思う。