AIがコードを書く時代にコードレビューは不要
はい、どうもこんにちは佐藤です！
混沌とした第二の故郷 X に「コードレビューをするべきか？」って話が上がっていました。
これまで、銀行案件や金融案件をやってきた真面目な私の意見では……。
もちろん……。
不要です！
正直に言うと、昔の私はレビューを徹底的にやる人間でした。銀行案件で diff を 1 行ずつ追って、セキュリティチェックリストを埋めて……という仕事を長くしてきた人間です。そんな私が「不要」と言うからには、理由があります。時代が変わったのです。
その理由を書いていきますね！
なぜコードレビューは不要なのか
なぜかと言うと、コードレビューをしていると、低コスト化の競争で負けてしまうからです。
考えてみてください。対して性能差がない車があったとして、片方は 40万円、片方は 100万円 だとしたらどちらを選びますか？
もちろん 40 万円ですよね？
圧倒的なコスト差の前では、コードレビューによる負担は大きくなるのです。
ちょっと具体的に考えてみましょう。従来の開発サイクルはこんな感じでしたよね。
仕様を固める → 実装（数日）→ レビュー依頼 → 指摘 → 修正 → 再レビュー → マージ
短くても 1 週間、普通に 2 週間かかるサイクルです。でも AI 時代はどうでしょう。
月曜日に仕様を固めたとします。火曜日に AI に実装させたら水曜日には動くものができています。金曜日に仲間にレビューしてもらって……あ、来週かな？ 修正してまた来週……。想像するだけで辛くなりますよね。AI が作るスピードに人間のレビューが追いつかないのです。
しかも、AI が生成するコード量は人間が書くよりずっと多いです。1 回の実装で 500 行、1000 行が当たり前になってきています。その分だけレビュアーの認知負荷もどんどん上がっていきます。
レビューを重ねるごとに、ヘトヘトになりません？
それは創造的な「何を作るのか」の判断量を減らしているのです。
先ほどの車のコストの話でいうと、差額の 60 万円はレビュアーの人件費と、待ち時間のコストです。
競合が 1 週間でリリースしてくる時代に、レビューサイクルで 2 週間かけていたら負けるのは当然ですよね。しかも、新しい機能もつけられません。
でも品質が心配……そこでアーキテクチャとハーネス
でも……、品質に問題があると感じますよね？
そこで、アーキテクチャ と ハーネス の考えが必要になってくるわけです。
アーキテクチャの役割
アーキテクチャには、機能性はもちろん、以下のような様々なパラメータがあります。いくつか代表的なものを上げてみました。
- 拡張性：将来の変更に耐えられるか
- 可読性：人間（と AI）が理解しやすいか
- 移植性：環境を問わず動作するか
- セキュリティ：脆弱性を作り込まないか
その中で何を重視するかによって、コードレビューの重みを減らし、コードを読まないようにする努力 を行うことができます。
具体的にはどういうことでしょうか？
可読性 で言えば、Feature-based な構造が効きます。/features/payment/usePaymentForm.ts というファイル名を見るだけで、「決済フォームのロジックだな」とわかりますよね。ファイルツリーが仕様書になっている状態が理想です。コードを開かなくても、構造を見るだけで何が何なのかわかる設計にするのです。
拡張性 で言えば、依存関係を一方向に保つことが大切です。循環依存を作らない。AI が新機能を追加したとき、既存のテストが全部通れば「壊していない」と信頼できます。その信頼を作るのがアーキテクチャの仕事です。
セキュリティ で言えば、「危ないことができない」設計が一番強いですよね？ 認証・認可を必ず通るミドルウェア層を用意して、それを迂回できない構造にする。SQL インジェクション対策は ORM に任せる。入力値バリデーションは Zod などのスキーマで強制する。「レビュアーが気づかなかった」では済まない設計を最初から作るのです。
ハーネスの役割
ハーネスも、コードを読まないようにする努力の一つです。
古くは、フォーマッター や リンター を用いて、誰が書いても似たようなコードになる工夫をし、可読性を高めていました。
それと同じように、
- ファイルの置き場所
- 書き方のルール
- 逸脱してはいけないこと
を決めて、コードを読まないようにする工夫をすることが求められるのです。
代表的なのは次の 3 つのレイヤーでしょうか？
レイヤー1：書き方の強制
フォーマッターやリンターは昔からありました。今はそこに型チェック（TypeScript や mypy）が加わっています。
AI が型ミスを生成しても、コンパイル時に弾いてくれます。人間が 1 行ずつ型を確認する必要はありません。
レイヤー2：動作の検証
テストです。「テストが通れば信頼する」という思想に切り替えましょう。AI が書いたコードが意図通り動くかどうかは、人間の目ではなくテストが確認します。テストがドキュメントにもなるので、コードを読まなくても仕様がわかるようになりますよね？
なにより。残念ながら人間より優秀です……。 １０年コード書いてきた人が負けるとは悔しいのぉ
レイヤー3：リリースの安全網
そもそも、AIコーディングエージェントが、テストコードを流して、動くことを確認してから、持ってきてくれるようになります。
もっと、整備して、CI/CD パイプラインで上記すべてを自動で走らせますし、カナリアリリースやフィーチャーフラグを組み合わせると、問題が起きても素早く切り戻せます。「リリースのリスクを下げる仕組み」が、レビューに求めていた安全性の役割を代替してくれるのです。
型チェック・テスト・CI を組み合わせて、コードを読まなくても信頼できる状態を作る。これが現代のハーネスです。
でも、バグは？セキュリティは？
ここまで読んで「でも、バグが増えるんじゃないの？」と思いましたよね？
確かにバグは出ます。でも考えてみてください。コードレビューでバグをどれだけ防げているでしょうか？ レビュアーも人間です。疲れていたら見落としますし、集中できていないときは「なんとなく LGTM」になりますよね。
はい、疲れているとき。ものすごくやらかしています！ 後輩くんたちからメチャクチャ怒られています
それよりも、バグが出たらテストを追加して、同じバグが二度と出ない仕組みにする方が確実です。「バグゼロを目指す」より、「バグが出ても素早く直せる体制を作る」方が AI 時代には現実的。
「セキュリティホールが怖い」という声もよく聞きます。でも実はこれ、セキュリティこそ人間の目に頼るのが一番危ないんです。人間は見落とします。専門家だって完璧ではありません。
アーキテクチャで「危ないことができない」設計を作ることが一番の対策です。そこに静的解析ツール（Semgrep など）や、依存ライブラリの脆弱性スキャン（Dependabot など）を CI に組み込めば、専門ツールが自動でチェックしてくれます。汎用レビュアーの目よりずっと信頼できますよね。
「チームの知識共有はどうするの？」という話もあります。コードレビューを知識共有の場にしていたなら、それはドキュメントやペアプログラミング、ADR（アーキテクチャ決定記録）などで補えます。そもそも、コードレビューに品質保証と知識共有を両方やらせているのが問題なんです。役割を分けましょう。
まとめ
というわけで、AI 時代にコードを読んではだめだよ！って話でした！
あ。正確には、コードを読まない工夫をしよう って感じですねっ。
「コードを読まない」は「手を抜く」ではありません。むしろ逆です。コードを読まなくても信頼できる仕組みを作ることが、AI 時代の高度なエンジニアリングです。アーキテクチャとハーネスへの投資が、AI が生成したコードを信頼できる状態にしてくれます。
高速でプロダクトができてくる時代は楽しいです。ぜひみなさんもコードを読まない工夫をしてみてください！