レビューを省いてよいか迷っている方へ

AIがコードを書けるようになったのだから、レビューの手間も減るはずだ。そう考えて、確認工程を薄くしてよいか迷っている方に向けて書いています。

結論を先に言えば、減るのはレビューの量ではなく、レビューで探すものの種類です。

Stack Overflowが2025年に49,000人以上の開発者へ実施した調査では、AIツールを使う、または使う予定と答えた開発者は84%（前年76%）に達しました。一方で、AIの出力の正確性を「強く信頼している」と答えたのはわずか**3.1%**です。「ある程度信頼する」を足しても約33%で、「あまり信頼しない・まったく信頼しない」の約46%を下回ります（Stack Overflow Developer Survey 2025）。

使う人はほぼ全員になり、信じる人は少数派のままです。この差を埋めているのが、人によるレビューです。

いちばん多い不満は、間違いではありません

同じ調査で、AIに対する不満の1位は「ほぼ正しいが、少し違う」出力でした。66%が挙げています。2位は「AIが生成したコードのデバッグに時間がかかる」で45.2%です。

これはレビューの設計に直結します。明らかに動かないコードは、テストが落ちるので誰でも気づきます。厄介なのは、動くけれど仕様と少しずれているコードです。境界値の扱いが違う、エラーを握りつぶしている、既存の命名規則から外れている。どれも実行時には通ります。

だからAI生成コードのレビューは、「動くかどうか」を確認する作業から、「仕様と一致しているか」を確認する作業へ寄ります。

エージェントに範囲を広げると、懸念はさらに上がります。同調査では、回答者の87%が正確性を、81%がデータのセキュリティとプライバシーを懸念すると答えています。

レビューで見る観点

レビューでは、動くかどうかだけでなく、変更理由、影響範囲、テスト、運用手順を確認します。AIが生成したコードは、もっともらしく見えても、既存設計や運用ルールとずれることがあります。

特に既存システムの変更では、周辺機能への影響、例外処理、ログ、エラー時の動作を確認します。

AI生成コードのレビュー観点

  • 仕様との一致: 受入基準のどの項目を満たすか、コードから逆に説明できるか
  • 境界と例外: 空・ゼロ・上限値・タイムアウト・権限なしのとき、どう動くか
  • 影響範囲: 変更が触れる既存機能はどれか。触っていないことをどう確認したか
  • 戻せるか: 問題が出たとき、どの手順で元に戻すか
  • 次の人が読めるか: 半年後に別の担当者が変更できる状態か
  • 説明できるか: なぜこの実装にしたのかを、レビュー担当が自分の言葉で言えるか

Pull Requestのテンプレートへ項目として置き、埋まらない限りマージしない運用にできます

最後の項目が効きます。AIの提案をそのまま通したときは、たいてい自分の言葉で説明できません。

レビューは、上流ほど効きます

これはAI以前から分かっていることです。

IPAが公開データを分析した資料では、設計レビューの指摘密度が高いプロジェクトは、上流工程での不具合摘出比率が中央値で約1.6倍高いという傾向が示されています。同資料はこの比率の目標を、目安として85%程度に高めて設定することを挙げています（IPA 設計レビュー・要件定義強化のススメ）。

AIを使うと実装が速くなるぶん、上流の甘さが後工程へ流れ込む速度も上がります。確認を薄くする場所を探すなら、実装の下流ではなく設計段階を厚くするほうが順序として正しい、ということです。

コードだけでなく、説明文も確認する

AIはコードだけでなく、画面文言、ヘルプ文、提案書、コラム本文も作れます。文章でも、誇大表現、未確認の数値、会社名やサービス名の誤用、古い情報の混入を確認する必要があります。

数値は特に危険です。もっともらしい桁と単位で書かれた数字は、出典を当たらない限り正しく見えます。公開前に、その数字が出典のどこに書いてあるかを1つずつ確認します。公表された数字自体をどう読むかはAI開発の生産性200倍は何を測った数字かで扱っています。

公開サイトでは、AIらしい抽象表現よりも、実際の成果物、進め方、確認観点を明確に書く方が信頼につながります。

Pull Requestとテスト結果をセットで見る

AIが作った差分は、Pull Request、テスト結果、スクリーンショット、変更理由をセットで確認します。差分だけを見ると問題が分かりにくいため、実際にどう表示されるか、どの画面に影響するかを確認します。

フロントエンドでは、デスクトップとモバイルの両方で、文字のはみ出し、重なり、CTAの視認性、フォームの入力導線を確認します。

記録を残す

レビュー結果を残すことで、次回のAI開発や人による改善に再利用できます。チケット、Pull Request、テスト結果、変更記録を一体で残すことが大切です。

AI活用の効果は、速く作ることだけではありません。過去の判断が残ることで、次の変更を安全に進めやすくなります。

現場メモ

私たちのレビューでは、AIが書いた差分に対して「なぜこうしたのか」を提出側が書く運用にしています。AIの出力をそのまま貼るのではなく、採用した理由と、採用しなかった代案を1行ずつ添えてもらう形です。

この一手間を入れると、レビュー依頼を出す前に本人が差分を読み直すことになります。効いているのは、レビュー担当の指摘よりも、この再読のほうでした。提出前に本人が気づいて直すケースが増えています。

そのぶん、Pull Requestを出すまでの時間は延びます。AIで実装が速くなった時間の一部を、ここで使い戻している格好です。速さだけを見れば損に見えますが、私たちはこの配分を変えていません。

人が最後に見るべき判断

公開してよいか、顧客へ出してよいか、本番へ入れてよいかは、人が判断します。AIは材料を作れますが、責任の所在を代わることはできません。その判断を担う技術責任者が社内にいない場合は、外部の技術顧問がレビューと判断の記録を受け持つ形もあります。

先の調査では、開発者がAIではなく人に聞く理由の1位が「AIの答えを信頼できないとき」（75.3%）でした。信頼できるかどうかを判断できる状態を作っているのが、レビューです。

だからAI開発では、レビューの負荷をなくすのではなく、レビューしやすい成果物を残すことが重要です。レビュー体制そのものを相談したい場合は、お問い合わせからお知らせください。