AIが書いたコードのレビューで人間が見るべき差分はどこか

AIエージェントを導入して開発が速くなると、次に詰まる場所はほぼ決まっています。レビューです。書く速度だけが上がり、確かめる速度が変わらなければ、全体の速度は確かめる側で頭打ちになります。

この章では、レビューで何が起きているのかを公開データで確認したうえで、機械に任せる部分と人間が持ち続ける部分をどう分けるかを整理します。

ボトルネックはレビューに移る

これは個人の実感にとどまる話ではありません。DORAが2026年に公開した ROI of AI-assisted Software Development は、開発から提供までの流れ全体を対象に、AIの利用がいつ実際の成果に変わるのかを検証しています。そこで指摘されているのが、コードの産出量だけが増えて検証の仕方が変わらないと、開発段階で得た速度の一部が検証段階で失われるという構図です。

DORAが2025年の調査から一貫して示している「AIは増幅器である」という命題の、具体的な現れ方のひとつがこれです。レビュー・テスト・セキュリティ検証・アーキテクチャ上の判断が新しい制約条件になります。

レビューを従来のままにしたAIの導入は、ボトルネックの位置を変えるだけで、全体の速度をほとんど変えません。

増えているのは量だけではない

もう一段掘ると、レビューの負荷は「差分が増えたから」だけで説明できません。見るべきものの種類が変わっています。

GitClearが2026年1月に公開した調査は、2023年から2026年にかけての6億2,300万件の変更を分析し、次の変化を報告しています。

方向は一貫しています。重複が増え、整理が減っている。新しく書く量は増えたが、既存を整理し直す活動が落ちている、という像です。

レビューへの意味は明快です。従来のレビューは「このコードは正しく動くか」を見るものでした。AIが書いた差分では、それに加えてこれは既にどこかにあるものではないか、この変更で全体の構造は劣化していないかを見る必要が出てきます。前者は差分だけを見れば分かりますが、後者は差分だけでは分かりません。

AIが書いた差分のレビューで難しいのは、差分の中ではなく、差分の外にある問題です。

人間のレビューには物理的な上限がある

「では人間がもっと頑張ってレビューすればよい」は成立しません。人間のレビューには測定された上限があるからです。

コードレビューの効果に関する古典的な調査として、SmartBearがCiscoの開発チームで行ったものが広く知られています。そこで示された目安が次の3つです。

• 1回のレビューで見る量は 400行未満
• 1時間あたり 500行以下 のペース
• 1回のレビューは 60分以内

これを超えると欠陥の検出率が急激に落ちる、という内容です。

注意すべきは、この調査はAI以前の時代のものだという点です。人間の集中力の限界を測ったものであり、AIの登場で緩和される性質のものではありません。むしろ逆で、エージェントが半日で生む差分は、この上限を簡単に超えます。

つまり、レビュー体制を人力で拡大する方向には答えがありません。上限のあるリソースを、上限のない量に当てようとしているからです。

機械の指摘で先に収束させる

現実的な解は、人間のレビューの前に機械のレビューを置き、指摘が出なくなるまで先に回しておくという順序です。

高く評価された実践報告に、この運用を「ハーネスエンジニアリング」として整理したものがあります。エージェントを取り巻く環境・制約・フィードバックループを設計するという考え方で、機能を4つに分けています。

この報告で紹介されている運用は、レビュー → 指摘の切り分け → 修正 → 修正内容の検証 → コミット、というループを指摘がゼロになるまで回すというものです。実際には2〜3周で収束すると述べられています。

同じ方向の報告は他にもあります。1年間コーディングエージェントを使った振り返りでは、PR上のAIレビューが初期段階の凡ミスを潰すことで、人間のレビューを設計と機能の判断に集中させられたと述べられています。

人間が見るべき4つ

機械に任せられる部分と、人間が持ち続ける部分を分けると、おおむね次のようになります。

右側に共通しているのは、差分だけを見ても判断できないという性質です。問題設定が正しいかは要求を知らないと分かりませんし、重複を生んでいないかはコードベース全体を知らないと分かりません。前節で見た「重複が増え、整理が減る」という傾向は、まさにこの右側で受け止めるべきものです。

逆に左側は、差分の中だけで完結します。だから機械に任せられます。

多くの場合、テストもエージェントが書いていることが手がかりになります。実装とテストを同じ前提から作れば、前提が間違っていてもテストは通ります。テストが通っていることは正しさの証拠ではなく、実装とテストが同じ前提を共有している証拠にすぎません。要求そのものと突き合わせられるのは、今のところ人間です。

差分を人間が読める大きさに保つ

人間が見る範囲を絞っても、1つの差分が2,000行あれば意味がありません。レビューしやすさは、レビューの工夫より前に、タスクの切り方で決まります。

導入から3か月後に社内アンケートを取った12名規模のチームの報告では、66.7%が生成コードの品質のばらつきを課題に挙げ、同じく66.7%が並列作業の増加による認知の負荷を挙げています。疲労の増加を挙げた人が42%、ストレスの増加が25%。生産性向上を実感した人が83%いる一方で、この負荷が同時に発生しています。

並列で走らせて量を増やすほど、レビューする人間の側に負荷が集中します。量を増やす判断は、レビュー体制とセットで行う必要があります。

よくあるハマりどころ

AIレビューを人間のレビューの後に置く。 順序が逆です。機械が拾えるものを人間が先に拾うと、時間の使い方として最も高くつきます。

全部を同じ密度で読もうとする。 400行の上限を思い出してください。すべてを均等に見るのではなく、外部への影響がある箇所と設計判断に関わる箇所に密度を寄せます。

自動修正のループが振動する。 指摘 → 修正 → 別の指摘 → 元に戻る、を繰り返して収束しないことがあります。前述の実践報告でも、指摘を切り分ける段階で振動のパターンを検出し、変更していない箇所を除外する処理が入っています。ループを回すなら、止める条件を先に決めておきます。

通ったテストを根拠にしてしまう。 実装とテストの作者が同じ場合、テストの通過は独立した検証になりません。

レビューの負荷を測っていない。 差分の量やPRの滞留時間は測れます。「速くなった」を主張する前に、検証側で失われている分を見ているかを確認します。

ちゃんと使うためのポイント

• 書く速度だけを上げると、ボトルネックはレビューに移る。DORAが検証段階での目減りとして指摘している
• 変化しているのは量だけでなく種類。重複の増加とリファクタリングの減少が公開データで報告されている
• 人間のレビューには測定された上限がある（目安は1回400行・60分・時速500行）。人力での拡大は筋が悪い
• 機械のレビューを人間の前に置き、指摘が出なくなるまで回してから人間に渡す
• 人間が持ち続けるのは、差分だけでは判断できないもの（問題設定・設計判断・外部への影響・動くが間違っている箇所）
• テストの通過は、実装とテストが同じ前提を共有している証拠にすぎない
• 並列で量を増やす判断は、レビュー体制とセットで行う

次の章では、ここで「機械に任せる」とした部分をどう継続的に保証するか——評価とリグレッションの仕組みを扱います。1回のレビューで通ったことと、次も通り続けることは別の問題です。

参考リンク

• ROI of AI-assisted Software Development（DORA） — 検証段階がボトルネックになるという指摘の出典
• The Maintainability Gap（GitClear, 2026-01） — 重複・コピペ・リファクタリング減少の数値
• Best Practices for Peer Code Review（SmartBear） — レビュー量と検出率に関する古典的な調査
• ハーネスエンジニアリングで人間のコードレビューをやめる（2026-03-24） — 機械レビューのループ運用の実践報告
• Claude Code導入3ヶ月後の社内アンケートから分かったこと（2025-10-23） — 12名規模のチームでの品質ばらつきと負荷の報告