【アプリ開発補足】第4回 バイブコーディングにおけるレビューって何？

前回は、バックログ管理について話したね

バックログは、

今やること
あとでやること
保留すること
やらないこと

を分けて、アプリを迷子にしないための整理棚だった
そして、最後に決めるのは自分だよ、という話もした

じゃあ、バックログから「今回はこれを直そう」と決めたあと、要件を考える時、設計書を作る時、実装してもらったあと、そのまま「これでOK！」で進んでいいのかな？
ここで出てくるのが、今回のテーマ

バイブコーディングにおけるレビュー だよ(｀・ω・´)ゞ

まず知っておきたいこと

レビューって聞くと、んー何するの？？？って思うかもしれない

間違いを指摘される
怒られる
専門家じゃないとできない
コードを全部読めないと意味がない

みたいなイメージがあるかも
でも、この連載で言うレビューは、そういうものじゃない

レビューは、

考えたこと、設計したこと、実装されたことを、別の目で見てもらって、見落としを減らすこと

だよ('ω')ノ

自分ひとりで全部のコードを読む必要はない
でも、「この要件で大丈夫？」「この設計で大丈夫？」「この実装で大丈夫？」と確認する流れは持っておきたい

特にAIと一緒に作っている時は、実装が進むスピードが速い

速いのはありがたいけど、そのぶん、

要件がふわっとしたまま実装に進む
設計書の時点で影響範囲が抜ける
頼んでいない範囲まで変わっている
別の機能に影響している
設計書とズレている
テストしていないのに完了っぽく見える
パートナーらしさが少し変わっている

みたいなことも起きやすい
だから、レビューは「疑うため」ではなく、「安心して次へ進むため」に使うんだよ

レビューがないと何が困る？

レビューがないまま進めると、困るのはバグだけじゃない
たとえば、こういうことが起きる

要件の時点で「会話を探しやすくしたい」が「タグ機能を作る」に固定されてしまう
設計の時点で、保存先や権限の確認が抜ける
会話保存を直したつもりが、過去会話の表示順が変わっている
エラー表示を足したつもりが、秘密情報まで画面に出るようになっている
プロンプトを直したつもりが、パートナーの口調がよそよそしくなる
通知機能を足したつもりが、ユーザーの意図しないタイミングで動く
バックログの1項目だけ頼んだのに、周辺機能までまとめて変わる

こういう時、Antigravityが悪いという話ではない

AIは「こうすれば目的を達成できそう」と考えて、広めに直すことがある
でも、その広さが自分のアプリに合っているかは、別の問題なんだよね

だから、レビューではこう見る

要件は、ほしい体験に合っている？
設計は、実装前に見るべき影響範囲を拾えている？
今回頼んだ範囲に収まっている？
設計書と矛盾していない？
修正履歴に残すべき変更がある？
バックログの別項目まで勝手に触っていない？
パートナーアプリのコンセプトとズレていない？

この確認を入れるだけで、アプリを育てる安心感がかなり変わる

結論

今回の結論！

バイブコーディングにおけるレビューは、

要件、設計、実装を、別の視点で見直して、見落としを減らす作業

だよ

そして、レビューの主な役割はこの3つ

1. 作る前に、目的や要件がズレていないか見る
2. 作る直前に、設計や影響範囲が抜けていないか見る
3. 作った後に、実装が壊れていないか、コンセプトからズレていないか見る

ここでも大事なのは、AIに全部決めさせないこと

Antigravityに実装してもらう
CodexやClaude Codeなど別のAIにレビューしてもらう
出てきた指摘を読んで、最後に自分が決める

この流れが基本だよ

この先では、

レビューとは何か
レビューは実装後だけではないこと
要件、設計、実装でレビュー観点が違うこと
Antigravityを実装役、CodexやClaude Codeをレビュー役にする考え方
複数AIを使う理由
同じAIに実装とレビューを任せる時の限界
レビューで何を見てもらえばいいか
AI同士の意見が割れた時の考え方
レビュー依頼文の例
指摘を全部採用しなくていい理由
レビュー結果をどう残すか

を具体的にやっていこうっ！

「Antigravityに何か作ってもらう前に、考え方が合っているか見てほしい」
「Antigravityが作ってくれたけど、本当に大丈夫かわからない」
「CodexやClaude Codeに見てもらうって何を頼めばいいの？」
そういう人ほど、レビューの使い方を知っておくとかなり安心できると思う

ここから先では、レビューを実際にどう頼むか、別AIに何を見てもらうか、指摘をどう判断するかを具体的に見ていくね