CORPORATE

技術情報

コードレビュー不要論 ーハーネスが人間の目を代替するとき

はじめに

こんにちは。GMOインターネットの平野です。

前回の記事では、AIコーディングエージェントの出力品質を「構造」で担保するハーネスエンジニアリングの考え方と、4段階エスカレーションラダー（L1〜L4）の実装について紹介しました。

このハーネスをしばらく運用してきて、自然と浮かんできた問いがあります。

「ここまで構造で品質を守れるなら、人間のコードレビューはどこまで必要なのか？」という問いです。

先に結論を言うと、コードレビューを全廃できるとは考えていません。ただし、レビューが拾っているものを分類してみると、その大部分はハーネスとAIで代替できる作業であり、人間が本当に見るべき領域はもっと狭い、ということがわかってきました。この記事では、その分類と、移行をどう判断するかについて整理します。

レビューがボトルネックになる構造

AIにコードを書かせると、コーディングの速度は確実に上がります。一方で、レビューの速度は人間の処理能力に縛られたままです。

開発スタイルコーディング速度レビュー速度ボトルネック
人間が書き、人間がレビュー1x1xなし（均衡）
AIが書き、人間がレビュー5~10x1xレビューが律速
AIが書き、ハーネス+AIがレビュー5~10x自動化解消

この構造を放置すると、「レビューを省略して速度を取るか、レビューを維持して品質を取るか」という二択に追い込まれます。どちらも望ましくありません。必要なのは、レビューの中身を分解して、自動化できるものとできないものを仕分けることです。

コードレビューが拾うものを分類する

コードレビューで指摘される内容を整理すると、大きく4つのカテゴリに分かれます。

カテゴリ内容自動化
Aハーネス違反の検出可能
B-1ハーネス自体の矛盾不可
B-2ハーネス不足不可
C要件・設計の妥当性スコープ外

カテゴリA: ハーネス違反の検出

命名規約やアーキテクチャ境界、実装パターンへの準拠など、既存のルールに対する違反を見つける作業です。「camelCaseになっていない」「レイヤーを越えたimportがある」「パターンファイルで定義した実装方針と違う」といった指摘がここに入ります。

カテゴリB-1: ハーネス自体の矛盾

ルール体系そのものに矛盾がある場合です。たとえば、あるルールは「すべてのスキーマに.strict()をつける」と言い、別のルールは「外部APIレスポンスには.passthrough()を許容する」と言っている。外部APIのレスポンスをバリデーションするスキーマはどちらに従うべきでしょうか。こうした矛盾は、ルールを個別に見るだけでは気づけません。特に、新しいルールを追加するとき、ルール体系をリファクタリングするときに発生しやすくなります。パターンファイルが推奨するディレクトリ構造と、別のパターンファイルが前提とするインポートパスが噛み合わなくなる、といった事態は、ルールが増えるほど起きやすくなります。

カテゴリB-2: ハーネス不足

ハーネスがまだカバーしていない領域の発見です。たとえば、新しいライブラリやフレームワークが追加されたのに、それに対するルールが整備されていないとき、また、既存ルールの粒度では捕捉できないクラスのバグが起きたとき、「ルールを足すべきだった」と事後的に気づくケースもあります。AIは「既存ルールに違反していない」ことは判定できますが、「ルールが足りない」ことは判定できません。「ルールが無いから通過」と「ルールが不要だから通過」の区別がつかないのです。

カテゴリC: 要件・設計の妥当性

そもそもこの実装が問題を正しく解決しているか、アーキテクチャ上の判断は妥当か、という問いです。これはコードレビューというより設計レビューであり、判断基準もタイミングも異なります。設計レビューは本来、実装に入る前に行うべきものです。コードレビューの場で「そもそもこの方針で合ってるのか」が議論になるのは、設計レビューとコードレビューが混同されている兆候であり、プロセス自体を見直すべきサインです。本稿ではカテゴリCをスコープ外とし、コードレビューの中で扱うべきA・B-1・B-2に焦点を当てます。

機械に任せられるもの、人間が見るべきもの

カテゴリA: ハーネス違反の検出

ハーネス違反は、決定論的なものと確率的なものに分類できます。リンター等による決定論的な検出は、見落としがなく、人間も疲れません。確率的な検出は現時点では人間と同等かやや劣る可能性がありますが、ここは後述する並行運用で検証できます。

カテゴリB-1: ハーネス自体の矛盾

一方、ハーネス自体の矛盾の検知を自動化できない理由は構造的なものです。ハーネス矛盾（B-1）について言えば、AIはルールを公理として受け取ります。公理は「従うもの」であり「疑うもの」ではありません。公理系の内部矛盾を検出するには、その系の外に立ち、ルール同士の関係を俯瞰する視点が必要です。これは本質的にメタレベルの作業であり、現状のAIにはこの自発的な「一歩引いた視点」が欠けています。

矛盾が特に発生しやすいのは、次のようなタイミングです。

  • 新ルールの追加時（既存ルールとの整合性チェックが漏れる）
  • ルールの昇格時（執行レベルの変更による副作用が見えにくい）
  • ルール体系のリファクタリング時（分割・統合で前提が崩れる）

だからこそ、ハーネス自体を変更するPRには、必ず人間のレビューを通す必要があります。ハーネス変更のレビューは省略してはいけません。

カテゴリB-2: ハーネス不足

ハーネス不足（B-2）について言えば、AIは「ルールがないから通過」と「ルールが不要だから通過」の区別がつきません。ルールが存在しない領域では、AIは何もフラグを立てずに通過させます。

これはAIの欠陥ではなく、ルールベースなシステムの構造的な限界です。経験あるエンジニアがレビューで拾うのは、まさにこの「ルールがまだない領域」の問題であることが多い。「このパターン、うちのコードベースに入ったの初めてだけど、ルール化しなくて大丈夫？」「この新しいライブラリの使い方、パターンファイルに追加しておいたほうがよくないか？」といった問いかけは、ハーネスの外にいる人間にしかできません。こうした指摘は、ハーネスを育てる上で最も価値のあるフィードバックになります。

カテゴリC: 要件・設計の妥当性

カテゴリC（設計の妥当性）については、ハーネスの守備範囲外です。「このAPIの設計は利用者にとって使いやすいか」「この機能の責務配置は将来の拡張に耐えられるか」といった問いは、コードの正しさではなく設計の判断に関わるものです。こうした問いは実装に入る前の設計段階で扱うべきであり、コードレビューの場に持ち込むと、レビューの焦点がぼやけます。設計レビューとコードレビューを明確に分けることで、それぞれのプロセスが本来の役割に集中できるようになります。

カテゴリBとCを整理すると、人間がレビューで注力すべき領域がはっきりします。この構造は、自動テストの普及がQAの役割を変えた流れに似ています。手動テストが自動テストに置き換わったとき、QAは「テストを実行する人」から「テスト戦略を設計する人」になりました。同様に、コードレビュアーは「違反を検出する人」から「違反を検出する仕組みを設計する人」へと役割が変わっていくと考えています。

統計で判断する: 並行運用モデル

カテゴリAが自動化可能だとしても、「いつ人間レビューをやめるか」を感覚で決めるべきではありません。並行運用でデータを取り、統計的に判断するアプローチを考えています。

フェーズ1では、人間レビュアーとAIハーネスの両方がすべてのPRをレビューします。人間レビュアーはAIの結果を見ずに独立してレビューし、両者の指摘を記録して差分を分類します。そして、以下のメトリクスを計測します。

メトリクス定義目標
AIの見落とし数人間が検出したがAIが見逃した違反低下傾向
人間の見落とし数AIが検出したが人間が見逃した違反ベースライン
偽陽性率AIが指摘したが人間が却下したもの / AIの全指摘数閾値以下

ここで重要なのは、人間見落とし数を計測する点です。人間もまた見落とすことは多々あります。AIの見落とし数が人間の見落とし数を下回れば、AIに委譲する統計的な根拠が成立します。

フェーズ2においてAIの見落とし数が人間の見落とし数をN週連続で下回った時点で、カテゴリAの人間レビューを任意化します。ただし、まず低リスクなPR（小規模変更、既知パターンのみ）から人間レビューを省略し、段階的にスコープを広げます。異常があればフェーズ1に戻ります。セキュリティやデータ損失に関わる重大な違反については、統計的にAIが優勢でもサンプリングベースで人間レビューを継続することを想定しています。稀だが重大な問題は、統計の平均値だけでは捉えきれないからです。

条件閾値判定
AI見落とし数 < 人間見落とし数N週連続で達成カテゴリAの人間レビューを任意化
偽陽性率X%以下を維持レビュアーの信頼が維持される
重大違反の見落とし0件移行の前提条件

まとめ

コードレビュー不要論の核心は、「レビューをやめる」ことではなく、レビューの対象を再定義することです。今回の議論は、次の3つに整理できます。

1. レビューの分類が自動化の出発点

コードレビューが拾うものは一枚岩ではありません。ハーネス違反の検出、ハーネス自体の矛盾、ハーネスの不足、設計の妥当性。分類して初めて、何が自動化でき、何に人間の判断が必要かが見えてきます。

2. ハーネスの「中」は機械、「外」は人間

既知のルールに対する適合チェックは、レビューの最大ボリュームでありながら、構造的に自動化可能な作業です。一方、ルール体系自体の矛盾や不足は、ルールの外に立つ視点でしか見つけられません。人間のレビューは、この「外」を見ることに集中すべきです。

3. 移行はデータで判断する

「AIのほうが賢そうだから」は、移行の根拠になりません。並行運用で人間とAIの見落とし率を比較し、統計的にAIが人間と同等以上であることを確認してから移行する。このプロセスを踏むことで、感覚ではなくエビデンスに基づいた判断ができます。

コードレビューが不要になるのではなく、コードレビューの対象が「コード」から「ハーネス」に移行する。レビュアーの役割は消えるのではなく、より高いレイヤーへ移る。これが、ハーネスエンジニアリングを運用してきた先に見えてきた景色です。

ブログの著者欄

平野 空暉

システム本部

入社以来、ConoHa・お名前.comにおけるAI関連の企画・開発に従事。生成AI関連のサービスを複数手がけるほか、社内開発におけるAIネイティブな開発スタイルを提案・実践中。プロトタイプ開発やフロントエンドの UX 改善、パフォーマンスチューニングに特に関心を持つ。

採用情報

関連記事

No.1&STEAM人財採用 新卒年収710万プログラム

KEYWORD

CATEGORY

TAG

もっとタグを見る

PICKUP

採用情報

SNS FOLLOW

GMOインターネットグループのSNSをフォローして最新情報をチェック

CATEGORY