AIはコードを書きすぎている——コードレビューが開発の新ボトルネックになった

2025年、GitHubでマージされたPRは5億1870万件——前年より29%多い。その一方で、レビュアーの数は増えていない。

AIがコードを書くようになって、開発の速度が変わった。しかし速くなったのは「書く」工程だけだ。「読む」工程は人間が担ったまま、量だけが積み上がっている。

PRが爆増した

各種調査によると、2025年時点で書かれたコードの約41%がAI生成だ。GitHub Octoverse 2025によれば開発者の84%がAIツールをワークフローに組み込んでおり、51%が毎日使っている。コードを出す速度が上がったのは数字の通りだ。

問題はその先にある。Faros AIが10,000人以上の開発者・1,255チームを対象に分析したデータでは、AIツールを採用したチームではPRレビュー時間が91%増加した（詳しくはこちらの記事で解説している）。コードは速く出るが、レビューは詰まる——これが現在のソフトウェア開発の実態だ。

Logilicaの調査では、大企業エンジニアがPRをマージするまでの中央値は約13時間だ。開発者は時間の15〜20%をコードレビュー待ちに費やしている。87%の開発者が「AIで開発サイクルが速くなった」と回答しながら、組織全体の生産性向上は10〜15%にとどまるという矛盾が生じている。

工場の組み立てラインを想像してほしい。AIは原材料の加工を3倍速にした。でも次の工程——品質チェック——は同じ速度のままだ。製品は積み上がるだけで、出荷量は変わらない。

AIが書いたコードには「見落とされやすさ」がある

単にPRが多いだけなら、レビュアーを増やせばいい。しかし問題はそれだけではない。AIが生成したコードには、人間が書いたコードとは質的に異なる「見落とされやすさ」がある。

CodeRabbitが2025年12月に発表したレポート（470件のオープンソースPRを分析）によると、AI共著PRは人間のみのPRより1.7倍多くの問題を含む（AI: 10.83件/PR、人間: 6.45件/PR）。ロジック・正確性エラーに限ると、AIコードは人間コードより75%多い。数が多い上に、質も落ちる。なぜレビュアーはこれを見落とすのか。

「信頼バイアス」と「認知疲労」

Sonarの「State of Code Developer Survey 2026」（2026年1月）によると、96%の開発者がAI生成コードを完全には信頼していない。それにもかかわらず、コミット前に必ずチェックするのは48%のみだ。

「信頼はしていないが、確認しない」。矛盾したこの行動には理由がある。

AIが生成したコードは見た目が整っている。変数名は意味のある英語で、コメントも丁寧で、構造も読みやすい。人間が徹夜で書いたコードより、表面的には「良さそう」に見える。この「清潔感」が信頼バイアスを生む——中身を確認しなくても、なんとなく大丈夫そうという感覚だ。

さらに、AIコードはコードの名称や識別子が一貫していないことが多い（CodeRabbitレポート）。getUserDataとfetchUserとgetUserが同じ処理に対して混在する。レビュアーは「これは同じ関数を三回書いたのか、意図的に違う処理なのか」を判断するだけで認知コストを使う。1件なら些細なことだが、1000行のdiffの中では砂の中の針を探す作業になる。

人間が書いたコードとは「読み方」が変わる

機械翻訳は一瞬で文章を出す。でも校正には人間の目が必要で、時間は変わらない。AIコーディングも同じ構造だ。翻訳が速くなっても、校正のコストは変わらない。むしろ量が増えた分だけ増える。

人間が書いたコードをレビューするとき、レビュアーは「このコードは正しく動くか」を確認する。AIが書いたコードをレビューするときは、それに加えて「このコードは本当に必要か」を確認しなければならない。

// ❌ AIが生成する「守備的すぎる」コードの典型
// 1000行のdiffに埋もれると気づきにくい
function parseUserId(id: unknown): string {
  if (id === null) throw new Error("User ID cannot be null");
  if (id === undefined) throw new Error("User ID cannot be undefined");
  if (typeof id !== "string" && typeof id !== "number") {
    throw new Error(`User ID must be string or number, got ${typeof id}`);
  }
  const parsed = String(id).trim();
  if (parsed.length === 0) throw new Error("User ID cannot be empty");
  if (parsed.length > 100) throw new Error("User ID too long");
  return parsed;
}

// ✅ TypeScript環境での適切なコード
// 型システムで担保できる部分は型に任せる
function parseUserId(id: string): string {
  return id.trim();
}

「本当に必要か」を判断するには、そのコードが使われるコンテキスト全体を把握する必要がある。AIはそのコンテキストを持たないまま「完璧そうな」コードを生成する。レビュアーがそのコンテキストを補って判断するコストは、コードが増えるほど上がっていく。

Logilicaが指摘するとおり、開発者の時間の80%はコーディング以外（計画・ドキュメント・レビュー・保守）が占める。AIはその20%の部分だけを高速化した。残りの80%は変わっていない。

AIレビューツールで「全部解決」できない理由

「AIにコードを書かせるなら、レビューもAIにやらせればいい」という発想は自然だ。CodeRabbitやGitHub Copilot for PRなどのツールが登場し、実際に使われている。ただし、これらのツールが解決できる問題には限界がある。

現在のAIコードレビューツールの多くはdiff（差分）を分析する。変更されたコード自体の問題（バグ、セキュリティホール、スタイル違反）は検出できる。しかしコードベース全体との文脈の一貫性——「このAPIはすでに他の場所に存在するか」「このロジックは別のモジュールと重複していないか」——は、diffだけを見ていては判断できない。

AIコードレビューツールを導入した場合、マージリクエストの承認が30%速くなるというデータはある。ただし、これはレビューの質が上がったという話ではなく、速度が上がったという話だ。

AIツールはレビューのアシスタントとして機能する。レビューそのものを代替するものではない——少なくとも現時点では。

現実的な対応策

問題を理解した上で、今すぐできることを3つ挙げる。

PRを小さく保つ

1000行のdiffを1件のPRで出すのをやめる。これだけで、レビュアーの認知コストが大きく下がる。

❌ 悪い例: 1件のPRで全部出す
  feat: ユーザー認証システムの実装
  → DBスキーマ + API + フロントエンド = 1000行

✅ 良い例: スタックドPR（3分割）
  PR [1/3] feat: DBスキーマとマイグレーション（150行）
  PR [2/3] feat: 認証APIエンドポイント（200行）
  PR [3/3] feat: フロントエンドのログインUI（180行）

Awesome Code Reviewsのガイドによると、スタックドPR（200〜400行以下の小さなPRを積み重ねる手法）はAIレビューツールの精度を上げ、レビュアーの認知負荷も下げる。AIが書いたコードを小さい単位でレビューする習慣をつけると、問題を見落とす確率が下がる。

PRにAI使用状況を明示する

「AIが書いたコードがどこで、人間がどこをチェックしたか」をPRに書く。レビュアーがどこを重点的に見ればいいかを事前に伝えることで、認知コストが下がる。

## AI使用状況
- 使用ツール: Claude Code
- AI生成コード: src/auth/jwt.ts の全体
- レビュー重点箇所: トークン有効期限の設定、エラーハンドリング

## 自己レビュー済み事項
- [x] ハードコードされた秘密鍵がないことを確認
- [x] エッジケース（空トークン、期限切れ）を手動テスト済み
- [ ] パフォーマンス: 未検証

このテンプレートを使うだけで、レビュアーは「どこに時間をかけるべきか」を把握できる。PRの説明が「機能を追加した」だけでは、レビュアーはどこに問題が潜むかを自分で全部推測するしかない。

AIにセルフレビューを依頼してから提出する

GitHub Copilot codingエージェントは2026年初頭から、PR提出前に自分の変更を自己レビューするようになった。AIが書いたコードをAIがチェックしてから人間に渡す——という流れが現実になっている。

同じことをClaudeやCursorなどのツールでも手動で行える。コードを生成させた後、「このコードに問題があるか確認して」と同じセッションで依頼する。生成と検証を同じコンテキストで行うことで、AIは自分が書いたコードの前提を把握した上でチェックできる。

AIにコードを書かせ、そのまま提出するのが習慣化していると、いずれ事故につながる。「AIが出したから大丈夫」ではなく「AIが出したから重点的に確認する」という順序の逆転が必要だ。

レビューこそがエンジニアリングになった

67%の開発者がAI生成コードのデバッグに、自分で書いたコードより多くの時間を費やしたという調査がある。コードを「書く」より「読んで直す」方が時間がかかる——これが今の現実だ。

コーディングの速度が問題ではなくなってきた。どれだけ速くコードを生成しても、レビューと修正で詰まれば出荷は遅れる。「速く書ける」スキルより「正確にレビューできる」スキルの価値が上がっている。

レビューは長い間、開発の脇役だった。コードを書いた後に誰かがざっと目を通す、それが一般的なレビューの扱いだった。AIがコードを大量生成するようになった今、その扱いを変える必要がある。

レビューが仕事の本質になった。AIが書いたものを判断するのは、今のところ人間だけにできることだ。