← Blog 一覧
Agile × AI #agile #ai #testing #code-review #mentorship

コードレビューはもう十分じゃない——AI時代、品質の砦は「テスト」に移る

AIが書くコード量が増えるほど、人間が一行ずつ読むレビューは追いつかなくなる。品質の主戦場がコードレビューからテストレビューへ移るとはどういうことか、そしてジュニアエンジニアの育成はどう変わるのかを考える。

読む量が増えるほど、読まなくなる

前々回の記事で、 AI時代に品質を担保する主戦場が「コードレビュー」から「テストレビュー」へ移る、 と一行だけ書きました。今回はその一行を、もう少し丁寧に開いてみます。

逆説的な話から始めます。 AIエージェントが書くコードの量は、人間が書いていた頃とは比較にならないほど増えました。 ところが、人間が一行ずつ読むべきコードの量は、むしろ減らすべきなのです。 読む速度は変わらないのに、書かれる量だけが増える——このまま「全部読む」を続ければ、 レビューはチーム最大のボトルネックになります。

コードレビューが担ってきた「二つの仕事」

この移行を理解するには、コードレビューがそもそも何のためにあったかを 分解しておく必要があります。実は二つの、性質の異なる仕事を兼ねていました。

  • 欠陥検出：バグ、設計上の問題、セキュリティホールを実装が本番に届く前に見つける
  • 知識伝達：Googleのエンジニアリングガイドは、知識伝達を欠陥検出と同格の主目的として明記しています。レビューはシニアからジュニアへの、業務を止めない形での指導の場でもありました

AIが実装の大半を書くようになると、この二つの仕事のうち、 後者が静かに崩れます。コードの「書き手」が、成長する人間ではないからです。 レビューコメントを返しても、次に同じ間違いをしないよう学習して育っていく ジュニアエンジニアが、そこにいません。

「読む量」の限界を超えた

もう一つの問題は、単純な物理量です。 AIエージェントが夜間に生成する差分をすべて人間が一行ずつ精読する、 というモデルは、量の面でそもそも持続可能ではありません。 前々回書いた 「実装コストがほぼゼロになった」という話は、 そのまま「レビュー対象の量がほぼ無限になった」という話でもあります。 ボトルネックは実装から検証に移りましたが、 検証もまた「全部読む」という同じやり方を続けていては、次のボトルネックになるだけです。

コードレビューに残るもの、テストレビューが引き受けるもの

だからといって、コードを一切読まなくていいわけではありません。 正しく切り分けると、こうなります。

コードレビューに残るもの テストレビューが引き受けるもの
問う内容 この抽象化は半年後も耐えるか、この設計は正しいか この仕様理解は正しいか、この境界値は網羅されているか
対象 アーキテクチャ、セキュリティに関わる箇所、可読性 正常系・異常系・境界値、受け入れ基準との一致
読む理由 将来この場所を読む「人間」のため この仕様が「本当に仕様通りか」を保証するため

ポイントは、コードは相変わらず人間が読むものだという点です。 AIが書いたとしても、半年後にそこを触るのは人間です。 だからアーキテクチャ判断と可読性は、引き続き人間の目が必要です。 一方で「仕様通りに動くかどうか」の保証は、 テストという形式化された基準に主戦場が移ります。

テストレビューは、実は簡単ではない

ここで安易にカバレッジ率を追いかけると、危険な罠にはまります。 カバレッジは「実行されたかどうか」を測るだけで、 「その実行が本当に意図を検証できているか」は測りません。 if 文を通過しても、その分岐の結果が正しくアサートされていなければ、 カバレッジ100%のまま、意味のないテストが量産されます。

この弱点を炙り出す手法がミューテーションテストです。 ソースコードに意図的に小さなバグ（ミュータント）を注入し、 既存のテストスイートがそれを検知して「殺せる」かどうかを機械的に検証します。 ミュータントを生き残らせてしまうテストは、 カバレッジ上は緑でも、実質的に何も守っていません。

AIが大量にテストを生成できる時代だからこそ、 「テストの数」や「カバレッジ率」ではなく、 「このテストは本当に壊れたコードを検知できるか」を 人間が問い続ける必要があります。それがテストレビューの核心です。

簡単な例で見てみます。割引計算のロジックです。

int applyDiscount(int price, boolean isMember) {
    if (isMember) {
        return price - 100;
    }
    return price;
}

これに対して、カバレッジ100%を達成する「弱いテスト」はこう書けてしまいます。

@Test
void discountIsApplied() {
    applyDiscount(1000, true);
    applyDiscount(1000, false);
    // どちらの分岐も実行はされている。しかしアサーションが一つもない。
}

このテストは、行カバレッジも分岐カバレッジも100%です。 しかしreturn price - 100;を return price - 1;に書き換えても、テストは気づかず通過します。 ミューテーションテストは、まさにこの「気づかない」状態を機械的に暴きます。 正しいテストは、こう書かれているべきです。 

@Test
void memberGets100YenDiscount() {
    assertEquals(900, applyDiscount(1000, true));
}

@Test
void nonMemberPaysFullPrice() {
    assertEquals(1000, applyDiscount(1000, false));
}

一行のコードに対して、これくらい単純な例でも「弱いテスト」は容易に生まれます。 AIエージェントが数百のテストを一晩で生成する状況では、 この種の「実行されているだけで何も検証していないテスト」が カバレッジの数字の裏に大量に紛れ込むリスクは、むしろ人間が書いていた頃より高くなります。

ジュニアエンジニアは、どこで育つのか

知識伝達という、コードレビューが失った機能はどこへ行くのでしょうか。 2026年に発表された研究 "From Junior to Senior: Allocating Agency and Navigating Professional Growth in Agentic AI-Mediated Software Engineering" は、この問いに正面から向き合っています。

この研究によれば、ジュニアエンジニアはAgentic AIの扱いにおいて 「過度な依存」と「慎重すぎる回避」の間で揺れていることが分かっています。 一方でシニアエンジニアは、AI以前に培った基礎的な勘所を使ってツールを制御し、 AI時代のキャリア形成におけるメンタリングについて、貴重な視点を持っているといいます。

ここから見えてくるのは、メンターシップの教材が変わるという話です。 かつては「なぜこの行をこう書いたのか」を問うのがレビューでした。 これからは「なぜこのテストをこう設計したのか」「このエッジケースになぜ気づけたのか」 「AIへの指示をどう組み立てたのか」を問う場に、指導の重心が移ります。 コードを読む力ではなく、仕様を分解し、検証すべき境界を見抜く力—— これが新しい時代の徒弟制度の教材です。

具体的な実践としては、ジュニアメンバーに 「AIが生成したこのコードに対して、ミュータントを生かしてしまう抜け穴を見つけてください」 という課題を与えるのが有効です。 コードを一から書かせるより、 既にあるテストの弱点を見抜かせる方が、 短時間で「検証すべき境界」を見抜く目を鍛えられます。 そしてこの営みは、Ownershipの記事で書いた 「検証の網への投資」そのものでもあります。

移行のためのチェックリスト

  • レビューのコメントの何割が「設計判断」で、何割が「フォーマットや些末な指摘」か——後者はすでにAIが担うべき仕事になっていないか
  • テストのカバレッジ率だけを見て「十分」と判断していないか。ミューテーションテストのような、テストの実効性を測る仕組みはあるか
  • ジュニアメンバーへのフィードバックは、コードの行単位ではなく、テスト設計やエージェントへの指示の出し方に向いているか
  • 「テストがある」ことと「テストが機能している」ことを、チームは区別できているか

おわりに

以前の記事で、 トヨタ生産方式の自働化・アンドンを引き合いに、 「品質を工程の最後ではなく、工程そのものに埋め込む」という話を書きました。 テストレビューへの移行は、この思想をレビュー工程そのものに適用する話でもあります。 検査を後工程に置くのではなく、 「何を検査すべきか」を定義する工程そのものを、品質保証の主戦場にする。

コードレビューが不要になるわけではありません。 ただし、その役割は縮小し、より少ない、しかしより重要な判断—— アーキテクチャと可読性——に集中していきます。 そして空いた場所には、これまで軽視されがちだった 「テストを正しく設計し、正しく評価する力」が主役として座ります。

品質の砦が移動したことに気づかず、 古いレビュー習慣のままカバレッジの数字だけを見ているチームは、 緑色のバッジに守られた砂上の楼閣を築いていることになります。

参考：Feng, D., Yun, B., & Wang, A. Y. (2026). "From Junior to Senior: Allocating Agency and Navigating Professional Growth in Agentic AI-Mediated Software Engineering." arXiv。 ミューテーションテストに関する一般的な解説を参照。

← Blog 一覧に戻る