AIが生成したコードをレビューせずにマージしていいだろうか。
多くのエンジニアは「ダメに決まっている」と答えるだろう。バグが混入するかもしれない。セキュリティホールが見逃されるかもしれない。既にある関数と同じものを新たに作ってしまっているかもしれない。技術的負債が積み上がるかもしれない。
しかし、少し考えてみてほしい。
コードレビューは、誰のためにあるのか。DRY原則は、何を守っているのか。可読性は、誰が読むことを想定しているのか。技術的負債は、誰が返済するのか。
これらはすべて、人間がコードを読み、人間が修正するという前提から生まれた概念である。
近い将来、AIがコードを書き、AIが直す時代が来たら、この前提はどうなるだろうか。
私が考えてみたいのは、人間がコードレビューもしなければ、きれいなコードを意識することもしない、最大限AIを活かすとしたらどうなるかという新しい原則である。
人間がコードをレビューする。人間が一貫性を保つ。人間が保守する。これらはすべて、人間の時間というスケールしないリソースを消費する。
人間をボトルネックにせず、AIによって一定水準のプロダクト提供を最大限スケールさせる。そのための原則を考えたい。
まずは現在「正しい」とされるバイブコーディングの原則を整理し、その前提を疑い、最後に新しい原則を考えてみる。
現在の「正しい」原則
2025年現在、バイブコーディングのベストプラクティスとして広く共有されているのは、以下のようなものである。
- 仕様書ファースト。 コードを書く前に、何を作るのかを明確にする。PRDやREADMEを最初に作成し、AIと人間の間で「完成像」を共有する。曖昧な指示は曖昧なコードを生む。
- テストファースト。 実装の前にテストを書く。AIが生成したコードの正しさを担保する唯一の方法がテストである。人間がコードを全行レビューするのは現実的ではない。
- Git管理の徹底。 すべての変更をコミットし、いつでも巻き戻せるようにする。AIが予期せぬ変更を加えたとき、直前の状態に戻せることが安全網になる。
- コードレビュー。 AIが生成したコードであっても、マージ前に人間がレビューする。「AIを信じすぎるな」が合言葉である。
- 一貫性・保守性・可読性。 コードベース全体で一貫したスタイルを保つ。同じことを複数の方法で実装しない（DRY原則）。将来の自分や他のエンジニアが読んで理解できるコードを維持する。
これらは従来のソフトウェア開発で培われた知恵をバイブコーディングに適用したものである。実際、これらを守ることで成功率は大幅に上がる。
しかし、本当にこれでいいのだろうか。
常識を疑う
先に挙げた原則のうち、コードレビュー、DRY、可読性、保守性。
これらはすべて**「人間がコードを読み、人間がコードを修正する」**という前提から生まれている。
AIがコードを書き、AIが直す時代には、この前提を問い直す必要があるのではないか。
コードレビューは誰のためか
コードレビューは主に以下の観点で行われる（知識共有や教育という側面もあるが、割愛）。
業務観点：設計書通りに動くか。設計書の考慮漏れはないか。エラーやワーニングが出ていないか。
非業務観点：命名規則に忠実か。スコープは最小限か。長すぎるロジックは分割されているか。共通ロジックは切り出されているか。
ここで区別したいのは、外部設計レベルと詳細設計以下である。
外部設計——APIの設計、インターフェース、モジュール間の依存関係。
これは人間が見るべきだと考える。アーキテクチャの妥当性は、まだ人間の判断が必要な領域である。
しかし、
詳細設計以下——関数の中身、ループの書き方、変数名、インデント。
ここに人間のリソースを割く必要があるだろうか。
「設計書通りに動くか」はテストが検証する。「考慮漏れ」はエッジケースのテストが担保する。「エラーやワーニング」はCIが検出する。非業務観点も、リンターやフォーマッターがチェックする。
実際、写真を入れたら犬か猫か正確に判定するAIがあるとして、中身がブラックボックスだからという理由で使われないことはないだろう。
テストが通っていて、致命的なバグや危険性がなければ問題はない。
AIを最大限活かすなら、人間のリソースはコードの細部のチェックではなく、それを担保する入出力のテストに振ったほうがいいのではないか。
DRY原則は何を守っているのか
DRY（Don’t Repeat Yourself）原則は、「同じロジックを複数の場所に書くな」という教えである。なぜか。同じロジックが3箇所にあると、修正時に3箇所すべてを直す必要があり、人間は漏れやすいからだ。
では、修正するのがAIならどうか。「この仕様変更に対応して」と言えば、AIは該当箇所を全部直してくれる。3箇所だろうが10箇所だろうが、全部直せばいいだけの話である。
「AIも見落とすのでは？」という反論があるかもしれない。しかし、仕様変更が入ったら、まずテストを修正し、テストが通るまでAIに修正を依頼すればよいのではないか。
もちろん、DRY原則を守ったコードが理想的ではある。しかし、AIを前提とすると、守っていないことのデメリットは以前より少なくなる。
ゆえに、DRY原則を徹底して守らせるより、テストの充足に力を割いたほうが良いように思える。
可読性は誰が読むことを想定しているのか
「可読性の高いコード」とは、人間が読んで理解しやすいコードである。変数名は意味のあるものに。関数は短く。コメントは適切に。
可読性自体は、AIにとっても重要である。AIも自然言語ベースでコードを解釈するため、意味のある命名やコメントは有効に働く。
ただし、「人間のための可読性」の優先度は下がる。たとえば、インデントが一切ないコードでも、AIは問題なく読める。フォーマットの美しさ、視覚的な整理——そういう「人間の目に優しい」配慮に時間をかける必要性は減っていく。
関数名も、短くて読みやすい <<< 長くても意味ある命名 になるだろう。
技術的負債は誰が返済するのか
技術的負債とは、「今は動くが、将来の修正を困難にするコード」のことである。返済コストは、人間が修正に苦労する時間として計上される。
AIがコードを修正する場合、事情は変わる。ちょっとしたリファクタリングは、頼めばすぐ終わる。古い言語で書かれたシステムを置き換えたいなら、目的とテストケースさえあれば、新たに作り直せばいい。
「壊れたら捨てて作り直す」がAIには低コストで可能である。
少なくとも、今までの技術的負債とこれからの技術的負債は、だいぶ意味合いが変わるように思える。
これからの原則
ここで、AIの発展を前提とした新しい原則を考えてみたい。
この原則の目的は明確である。人間をボトルネックにせず、AIによって一定水準のプロダクト提供を最大限スケールさせること。
人間がコードをレビューする。人間が一貫性を保つ。人間が保守する。これらはすべて、人間の時間というスケールしないリソースを消費する。AIに任せられる部分はAIに任せ、人間は「何を作るか」「何が正しいか」の定義に集中する。
原則1：入出力が正しければ、内部実装は問わない。 関数の「契約」だけを検証する。テストが通れば、詳細設計以下のコードレビューは不要である。
原則2：一貫性は不要、重複もOK。 同じロジックが3箇所で違う方法で実装されていてもいい。各関数が独立してテストを通るなら、統一する必要はない。
原則3：詳細設計以下はレビューしない、テストを厚くする。 外部設計（API、インターフェース、アーキテクチャ）は人間が見る。しかし関数の中身は見ない。テストが信頼の源泉になる。
原則4：保守しない、作り直す。 技術的負債を「返済」するのではなく、壊れた部分を「作り直す」。保守性を高める努力より、テストを整備して「いつでも作り直せる」状態を維持する。
成立条件
この原則が成立するには、いくつかの条件がある。
- テストファーストが絶対。 テストなしにこの原則を適用すると、ただの無法地帯になる。
- 関数の粒度が適切。 巨大な関数は入出力の検証が困難になる。テスト可能な単位に分割する。
- E2Eテストの整備。 個々の関数が正しくても、システム全体の動作は別途検証が必要である。
- モデルの継続的な発展。 2025年現在のAIではまだ難しいが、発展が続くことが前提である。
もちろん、安全性が重視されるプロジェクトでは、こうはいかない。銀行の勘定系や医療システムなど、従来のベストプラクティスをすべて適用すべき領域は当然ある。しかし、スタートアップや個人開発など、開発速度がより重要な現場では、この原則のような開発手法に次第になっていくのではないか。
まとめ
本稿では、現在「正しい」とされるバイブコーディングの原則を整理し、その前提を疑い、新しい原則を考えてみた。
コードレビュー、DRY、可読性、保守性——これらはすべて「人間がコードを読み、人間が修正する」という前提から生まれている。AIがコードを書き、AIが直す時代には、この前提を問い直す必要がある。
新しい原則の目的は、人間をボトルネックにせず、AIによって一定水準のプロダクト提供をスケールさせること。人間のリソースはコードの細部ではなく、入出力のテストに振る。
AIがもっと賢くなれば、コードレビューもDRYも可読性も技術的負債も、過去の遺物になるかもしれない。
確かなことは、今まで「正しい」とされてきた原則はすべて、人間の、人間による、人間のための原則だったということである。
これからは、人間のための、AIによる、人間への原則を考える必要があるのではないだろうか。
あとがき
タイトルのせいで、論文みたいな口調になってしまいました。
ここのところ、AIを使った開発をしていて、ずっとうっすら違和感を覚えていました。
最近になってそれが、「人間ではなくAIが開発するようになったのに、まだ人間のための手順や原則を守らせている」という違和感だと腹落ちしました。
そしてそれは、いずれやらなくてよくなる過渡期だけのテクニックかもしれない。それを踏まえて考えてみたのが今回の原則です。
調べてみましたが、AI開発においてコードレビューを不要とするような主張は、他に見つかりませんでした。
一番近いのはテスト駆動開発でしょうか。Anthropicも「テストが通るまでAIに修正させる」というワークフローを推奨しています。
ただ、そこから一歩踏み込んで「だから詳細設計以下のレビューは要らない」とまで言っている人は、まだいないようです。
このような原則が使われ始めるのはまだ先かもしれませんが、AIの進歩の速さは目覚ましく、来年にはもうこのような開発が行われていてもおかしくないな、と思います。
