「AI が実装し、別の AI がレビューする」— 個人開発の二重 AI 体制を1年運用して

実装する AI と、レビューする AI を分ける

ここ1年、個人開発の体制はこう固まりました。実装は Claude Code、レビューは Codex。実装が意味のあるまとまりに達したらコミットし、別の AI にレビューさせ、指摘は 1 件ずつ個別コミットで潰す。全指摘を解消してからデプロイ。

なぜ分けるのか。実装した本人は自分のコードに甘いからです。これは人間でも AI でも変わりません。同じモデルに「自分の書いたコードをレビューして」と頼むより、別のモデルに新鮮な目で見せた方が、ロック順序の矛盾や境界条件の抜けを拾ってくれます。実際、直近のネイティブ層の改修では 4 ラウンドのレビューで重大指摘を全部潰してからリリースしました。

型1: 1セッション完結型 — 1.5時間で MVP

先日の新作アプリは、git ログを見返すと最初のコミットから 18 コミット目まで約 1.5 時間でした。その間にドメイン層のロジック（TDD でテストから）、DB、画面、ルーティング、デザイン適用まで到達し、レビュー 2 回（1 回目で重要指摘 4 件 → 修正 → 2 回目で GO）を経て実機確認まで。

コツはコミット粒度です。「テストを書く → 通す → コミット」のリズムを AI に守らせると、履歴がそのまま作業ログになり、レビューも差分単位で頼めます。

型2: フェーズ駆動型 — 5.5週間の長期戦

一方、位置情報とクラウド同期が絡むアプリは 5.5 週間・72 コミットをフェーズで刻みました。ローカル機能 → 位置情報 → 認証 → クラウド連携 → 仕上げ → リリース準備。各コミットに (Phase X) (Step N) のラベルを付けて、AI へのタスク分解指示がそのまま履歴に残る形にしています。

面白いのは、初日でフェーズ 1 の主要機能、2 日目でリリース準備の骨格まで到達していたこと。残りの 5 週間は権限フローや通知の磨き込みです。AI 時代の個人開発は「作る」より「仕上げる」に時間を使うようになりました。

体制を支えるのはドキュメント

どちらの型でも共通しているのが、AI に判断材料をドキュメントで持たせることです。

• 開発規約ファイルを AI ごとに用意（Claude 用と Codex 用の両方をリポジトリに置く）
• 設計判断は ADR（Architecture Decision Record）として残す。「なぜローカル DB を唯一の正とするか」のような方針レベルの決定も含めて
• セッション終了時に HANDOFF ドキュメントを生成し、次のセッションの AI が文脈を復元できるようにする
• 「端末データを消しかねないコマンドの禁止」「リリース操作は人間が最終実行」といったガードレールも規約に明記

人間の仕事は何か

実装もレビューも AI がやるなら人間は何をするのか。要件の決定、レビュー結果への裁定、そして最終責任です。二重 AI 体制は判断材料を増やしてくれますが、「この指摘は直す、これは見送る」を決めるのは今も人間の仕事。そこだけは自動化しないと決めています。

レビュー指摘を「1件ずつ個別コミット」にする理由

レビューで 4 件指摘されたとき、まとめて直して 1 コミットにしたくなりますが、あえて 1 件 = 1 コミットに分けています。理由は 3 つ。各修正が独立して revert できること。コミットメッセージ自体が「どの指摘にどう応えたか」の記録になること。そして後から git log を grep すれば、レビュー由来の修正だけを一覧できることです。AI が実装した変更と、AI レビューが直させた変更を履歴上で区別できるのは、後で「なぜこうなっているんだっけ」を調べるときに効きます。