AIが書いたコードを目視で追うのはやめよう──「工場の品質検査」から考えるこれからのコードレビュー

Claude Code や Codex などの生成AIツールが開発現場に導入され、コードの初稿を作成する時間は短縮されました。しかし、コードの生成速度が向上した一方で、プルリクエストのレビュー待ちが滞留し、テックリードや開発責任者が疲弊する現場が増えています。

AIコーディングが引き起こすレビューの滞留

たとえばCRUD処理や定型的なAPIクライアントの実装では、これまで半日を要していた作業が数分の指示で完了するようになりました。結果として、開発者1人が一日に提出するプルリクエストの件数や差分行数が跳ね上がる現場も珍しくありません。

しかし、提出される差分量が増加しても、レビュアーがコードを読んで正当性を検証する速度は変わりません。未レビューの差分が一覧に滞留し続けると、ブランチの競合が頻発し、再検証やマージ作業に工数を費やすことになり、開発速度が低下します。

この停滞を招く背景には、人間が書いたコードを前提とする従来のレビュー手法を、AIが生成したコードにもそのまま適用している点があります。同僚の思考プロセスを尊重しながら1行ずつ文脈を読み解くやり方は、AIが高速に出力した大量のコードを精査する手段としては適していません。

AI生成コードに対する目視レビューの限界

生成AIが出力するコードは、文法的に整っており一見すると問題なく動くように見えます。しかし、プロジェクト固有のアーキテクチャ規約や過去の設計判断、業務ドメイン固有の制約までは考慮していない事例が珍しくありません。

こうしたコードを目視で追おうとすると、レビュアーの注意は命名規則や細かな構文の違和感といった表層的なノイズに奪われがちになります。人間が1行ずつ粗探しを続ける作業は疲労を招きやすく、結果として、境界値の抜け漏れや潜在的な不具合といった設計上の欠陥を見落としやすくなります。

この問題の原因は、「AIが生成したコードの誤りを人間がすべて目視で拾い集める」という役割分担にあります。開発者がAIのチェッカーとして消耗する構図を断ち切るには、レビューという作業の位置づけそのものを受入検査として再定義する必要があります。

製造業の品質管理（QA/QC）に学ぶ工程設計

この課題を整理する枠組みとして、製造業における品質管理のアナロジーが役に立ちます。工場における品質管理では、現場作業者の注意力だけに頼って不良品の流出を防ぐ体制は採りません。作業ミスを物理的に防ぐ治具や、規格外の部材をラインから自動排除するセンサーといった機構（ポカヨケ）を工程内に配置し、不良品が次工程へ流れない構造を作ります。

この分担をソフトウェア開発に当てはめると、構文規則、フォーマット、型の不整合といった形式的な誤りは、エディタやコミットフック、CI（継続的インテグレーション）によってその場で遮断すべき「工程内の不良」に該当します。検査工程（コードレビュー）に持ち込まれる前に機械的な検査で不良品を弾くアプローチは、出力のばらつきが大きいAI生成コードを扱う現場ほど効果を発揮します。

形式的な静的チェックにとどまらず、実際の画面操作を伴う検証も機械化できます。たとえば、CI環境においてブラウザ自動テストツールを用いたE2E（End-to-End）テストを実行すれば、画面遷移や入力フォームの挙動といった動的な回帰もレビュー前の段階で機械的に検知できます。

さらに、製造業の受入検査では、納入された部品の分子構造や微細な加工手順を全量検査するのではなく、受入基準書に基づいて寸法や耐久性、要求仕様への合致を検査します。同様に、自動検査を通過したコードに対して人間が行うべき作業も、コード1行ずつの書き方の添削ではありません。形式的な正しさの確認が必要だとしても、それは前工程のツールによって保証されているからです。人間が担うべきなのは、システム全体の設計仕様を満たしているか、例外的な入力に対して安全に振る舞うかといった、外部から観測される機能と契約の検証です。

このように工程内での自動排除と最終工程での仕様検査を切り分けることで、レビュアーごとの基準の揺らぎを抑えつつ、確認作業の範囲を絞り込めます。

リンターとルールで自動的に防ぐ実装例

人間が判断する必要のない形式的な規則は、静的解析ツールとリンターを用いて機械的に検証します。「違反があるコードはコミットできない、あるいはCIを通過しない」という自動化された制約を設けることで、AIが生成した粗いコードがレビューに持ち込まれる事態を防げます。

バックエンドで PHP を採用している場合、Laravel や Symfony のプロジェクトでは静的解析ツールの導入が基本となります。

# PHPStan の解析レベルを最大（level: max または 8以上）に設定して実行
./vendor/bin/phpstan analyse -c phpstan.neon

PHPStan や Psalm を厳格なレベルで運用すると、型推論の不整合、未定義プロパティへのアクセス、null安全性の違反を検出できます。また、PHP_CodeSniffer や PHP-CS-Fixer をコミットフック（Husky や Git Hooks）に組み込むことで、コーディングスタイルの不一致を自動で修正させ、人間がインデントや命名規則を指摘する時間を省きます。

フロントエンドの Next.js や Vue の開発環境でも同様の統制が可能です。Next.js のプロジェクトでは TypeScript の型チェック（tsc --noEmit）を必須とし、ESLint と Prettier を組み合わせてプロジェクト規約を強制します。Vue のプロジェクトにおいても、vue-tsc による型検査や eslint-plugin-vue を用いた構文検査を同様に組み込みます。

{
  "scripts": {
    "type-check": "tsc --noEmit",
    "lint": "next lint --strict",
    "format:check": "prettier --check \"src/**/*.{ts,tsx}\""
  }
}

構文や型だけでなく、アーキテクチャの規則についても同様の統制が行えます。モジュール間の依存関係を検証するツール（PHP における Deptrac や、JavaScript / TypeScript における eslint-plugin-boundaries など）を利用すれば、「ドメイン層がインフラ層に直接依存していないか」といったアーキテクチャ上の制約もCIで機械的に検出できます。

人間が担う受入検査の観点

機械による統制を徹底したあとに残るのが、人間にしか判断できないドメインレベルの検査です。レビュアーは構文の細部から解放され、システム全体に影響を及ぼす観点に集中できるようになります。

人間が確認すべき観点は、次の3点に集約されます。

• 要求仕様およびドメインモデルとの整合性

AIは指示文に沿ったコードを生成しますが、システムの背後にある業務文脈や暗黙のドメイン制約をすべて反映できるわけではありません。計算ロジックが業務ルールに合致しているか、例外的な状態遷移が正しく考慮されているかといった意図の確認は、人間の判断に依存します。

• システム全体に対する副作用の有無

単一のファイルや関数の中では問題がないように見えても、データベースのクエリ発行数（N+1問題）、トランザクションの分離レベル、外部APIの呼び出し制限など、システム全体への波及効果を評価する必要があります。下位互換性の破壊やセキュリティ要件への抵触がないかも人間が検証すべき対象です。

• テストコード自体の妥当性

AIにテストコードを生成させると、アサーション（検証）の強度が足りず、単に実行エラーが出ないだけのテストを出力することがあります。境界値条件を網羅しているか、モックの振る舞いが現実の仕様と乖離していないかを確認する作業は、実装コード自体の閲覧以上に重視すべき検査項目となります。

AI活用を支える開発基盤の設計

生成AIを開発フローに組み込む際、開発者のプロンプト作成スキルだけに頼っていては、コードの品質とレビュー速度の両立は困難です。AIが大量に出力する時代だからこそ、静的解析やCIパイプラインといったガードレールの構築に対する投資が開発全体の生産性を左右します。

パーティーハード株式会社では、機械による自動統制を前提とし、人間が要件検査と設計判断に専念できる開発体制の構築を支援しています。ツールによる制約と人間による検査の境界を明確に整理することが、レビュー待ちによるブランチの競合を減らし、安全なリリース頻度を保つ基盤となります。