TL;DR
- AI実装速度向上でレビューがボトルネック化 → AI/人間の役割分離が急務
- AIチェック層（静的解析・パターン・セキュリティ）を自動化して人間負荷を削減
- 人間レビューは「設計判断・ドメイン知識・境界設計」に集中する
はじめに
こんにちは、みねです。
AIコーディング支援の普及でPRの生成速度は劇的に上がりました。ところが多くのチームで「実装は早くなったのに、リリースが全然遅い」という声が出ています。原因のほとんどはレビュー待ちです。
PRが詰まる構造的な背景はAIでコードは増えるのにプロダクト価値が伸びないのはなぜ？で整理しています。本記事ではその解決策として「AI/人間のレビュー役割分離」という運用設計を具体的に解説します。
なお、レビュー待ちは Cycle Time の一工程に過ぎません。Cycle Time 全体を 5 ステージに分けて境界を引き、ボトルネックを特定する手順はCycle Time をどう定義し改善するかで扱っています。本記事はそのうち Review ステージに特化した実装です。
AIレビューと人間レビューの分担表
レビューを詰まらせる最大の原因は「AIが生成したコードを人間が全部チェックしようとすること」です。AIが得意な領域を自動化し、人間は人間にしかできない判断に集中する。この分割が設計の核心です。
| チェック領域 | 担当 | 具体的な内容 |
|---|---|---|
| コードスタイル・フォーマット | AI自動 | ESLint / Prettier / Ruff による機械的統一 |
| 型安全性 | AI自動 | TypeScript / mypy によるコンパイル時検証 |
| セキュリティパターン | AI自動 | Semgrep / CodeQL によるパターンマッチ |
| テストカバレッジ | AI自動 | カバレッジ閾値のCI強制チェック |
| 依存関係の脆弱性 | AI自動 | Dependabot / Snyk による自動スキャン |
| 設計判断 | 人間 | モジュール境界・責務分離・将来拡張性 |
| ドメイン知識 | 人間 | ビジネスルール・エッジケース・業務文脈 |
| 境界設計 | 人間 | API契約・データモデル・チーム間インターフェース |
| アーキテクチャ整合性 | 人間 | 既存設計との整合・技術的負債の評価 |
| リスク判断 | 人間 | 本番影響・ロールバック可否・段階デプロイ要否 |
この表を見ると、機械的に答えが出るものはすべてAIへ、文脈・判断・責任が必要なものだけ人間へという原則が明確になります。
AIチェック層の実装
AIチェック層は「PRを出した瞬間に自動で走り、人間が見る前にフィードバックが完了している」状態が理想です。GitHub Actions を使った最小構成を示します。
# .github/workflows/ai-review-gate.yml
name: AI Review Gate
on:
pull_request:
types: [opened, synchronize]
jobs:
lint-and-type:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Node
uses: actions/setup-node@v4
with:
node-version: 20
- run: pnpm install --frozen-lockfile
- run: pnpm lint # ESLint
- run: pnpm typecheck # tsc --noEmit
security-scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run Semgrep
uses: semgrep/semgrep-action@v1
with:
config: "p/typescript p/secrets p/owasp-top-ten"
test-coverage:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: pnpm install --frozen-lockfile
- run: pnpm test --coverage
- name: Check coverage threshold
run: |
COVERAGE=$(cat coverage/coverage-summary.json | jq '.total.lines.pct')
if (( $(echo "$COVERAGE < 80" | bc -l) )); then
echo "Coverage $COVERAGE% is below threshold 80%"
exit 1
fi
この3つのジョブがすべてグリーンになるまで人間のレビューに進めない、というゲートを設けます。
ツール選定の指針
| 目的 | 推奨ツール | 備考 |
|---|---|---|
| JS/TS Lint | ESLint + typescript-eslint | @typescript-eslint/recommended-type-checked を採用 |
| Python Lint | Ruff | flake8/pylint の代替。高速 |
| セキュリティ静的解析 | Semgrep | ルールセットをチームで管理 |
| 依存脆弱性 | Dependabot | GitHub無料機能。週次で自動PR |
| コードカバレッジ | c8 / pytest-cov | CI上でのみ強制チェック |
ポイントは「ルールをコードベースで管理する」ことです。.eslintrc や semgrep.yml をリポジトリに置き、設定の変更もPRレビューの対象にします。
人間レビューが集中すべき3領域
AIチェック層を通過したPRに対して、人間は3つの領域に絞って判断します。
1. 設計判断
「この抽象化は正しいか」「この関数の責務は1つか」「将来この境界で拡張できるか」という問いは、コードの字面では判断できません。変更の背景・代替案の検討・将来のユースケースを踏まえた判断が必要です。
レビューコメントの例:
この Repository の抽象は今は適切ですが、マルチテナント対応が来た場合に
tenant_id の注入箇所がここだけになります。
その前提で UserRepository#findAll のシグネチャを設計しておきませんか？
2. ドメイン知識
「この条件分岐はビジネスルールと整合しているか」「このエッジケースは本番で実際に発生するか」という判断は、ビジネス文脈を知らないと下せません。AIはコードの文法は読めますが、「月末締めの受注は翌月扱い」というルールは知りません。
ドメインエキスパート（PdMや業務担当）をレビュアーに巻き込む箇所もここです。コード全体ではなく、ドメインルールが絡む1〜2ファイルに絞って確認を依頼します。
3. 境界設計
APIの契約、データモデルの変更、チーム間インターフェースの変更は、一度マージすると後戻りのコストが高い領域です。
チェックポイント:
- 後方互換性は維持されているか
- 破壊的変更（breaking change）の場合、バージョニングと周知はあるか
- 他チームが依存するエンドポイントへの影響は把握できているか
この3領域に絞ることで、レビュアーが「何を見ればいいか」が明確になり、レビューにかかる認知コストが下がります。
PR滞留を防ぐ運用ルール
技術的な仕組みに加え、チームの運用ルールがなければPRは詰まり続けます。明日から導入できる3つのルールを示します。
WIP制限
1人あたりのレビュー待ちPRを最大3件に制限します。4件目を出す前に既存PRのマージを優先します。Kanban の WIP Limit と同じ考え方です。GitHub Projects のフィルターで「自分がアサインされ open のPR」を常時可視化します。
レビュー期限
PRをオープンしてから2営業日以内に初回コメントを必須とします。期限を過ぎたPRはデイリースタンドアップで必ず取り上げます。LGTM まで不要で「初回コメント」で構いません。ファーストタッチが早いだけで滞留率は大幅に下がります。
担当ローテーション
レビュアーを特定のシニアに固定しないよう、週次で担当ローテーションを設定します。CODEOWNERS に複数名を並べ、GitHub の自動アサイン機能で分散させます。
# .github/CODEOWNERS
/src/domain/ @alice @bob @carol
/src/infra/ @dave @eve
/src/api/ @frank @alice
導入チェックリスト
以下のステップで段階的に導入します。全部一度に入れる必要はありません。順番に導入し、各ステップで効果を確認してから次へ進みます。
Week 1: AIチェック層の基盤構築
- ESLint + Prettier をCI必須にする（既存エラーは初回のみ
--fixで一括修正） - TypeScript strict モードを有効化（既存ファイルは段階的に対応）
- Semgrep をsecrets検出ルールセットで導入
Week 2: テストとカバレッジの強制
- CI でテストカバレッジ閾値を設定（まず60%から始めて段階的に引き上げ）
- PRテンプレートにテストの追加/修正を必須項目として記載
Week 3: 運用ルールの制定
- WIP制限（1人3件まで）をチームルールとして合意
- レビュー期限（2営業日）をドキュメント化
- CODEOWNERS を設定してレビュアー自動アサインを有効化
Week 4: 人間レビューの焦点化
- 「AIチェック通過後のみ人間レビュー開始」というフローを周知
- 設計判断・ドメイン知識・境界設計の3領域をPRレビューガイドラインに明記
- 月次でレビュー待ち時間の平均をモニタリングする仕組みを用意
FAQ
Q. AIチェックが厳しすぎてPRを出しにくくなりませんか？
A. Lint・型・セキュリティのルールは最初から全部有効にする必要はありません。--warn で警告止まりにして慣れてから --error に昇格させる段階導入が現実的です。Semgrep も最初は audit モード（ブロックしない）で始め、誤検知を確認してからゲートに昇格させます。重要なのは「ルールをコードベースで管理して、変更をレビューできる状態にする」ことです。
Q. レビュアーが少人数のチームでもローテーションは機能しますか？
A. 2人チームでも有効です。CODEOWNERS にお互いを登録しておくことで「担当が不明瞭」という状態を防げます。人数が少ない場合は、レビュー期限の運用（2営業日ルール）だけでも滞留の可視化に効果があります。スタンドアップで「レビュー待ちが2日を超えたPR」を議題に上げるだけで、チームの注意が向きます。
Q. AIレビューツール（GitHub Copilot for PRs、CodeRabbitなど）は既存のCIと競合しますか？
A. 競合しません。役割が違います。Copilot for PRs や CodeRabbit は「PRの意図を理解してコメントを生成する」役割で、ESLint や Semgrep のような「ルールベースのゲート」とは補完関係です。LLMベースのレビューコメントは参考情報として扱い、マージ判断はルールベースCIの通過と人間の承認を条件とするのが安全です。LLMのコメントを「LGTM代わり」にするのは避けてください。
まとめ
レビューボトルネックの解決策は「AIが担える機械的チェックをCI層に移し、人間は設計・ドメイン・境界に集中する」運用設計です。チェックリストの Week 1 から試してみてください。
レビュー文化は組織のナレッジ装置の一部でもあります。属人化を防ぐ4本柱の中でレビュー文化をどう位置づけるかは 暗黙知を減らす組織設計とナレッジ共有の仕組み で整理しました。
:::message チームのレビュー運用に課題を感じている場合は、現状の診断と改善設計のご相談を受け付けています。お気軽にお問い合わせください。 :::
なお、本記事のレビュー運用設計は、AI コーディングを Wave（全社配布）段階で安定化させる主要施策の1つです。組織全体の段階設計は AIコーディング組織展開の段階設計 で扱っています。
レビュー運用がボトルネックかどうかを定量的に判断したい場合は、開発生産性指標 比較：DORAとSPACEの選び方 で扱っている DORA の Change Lead Time / Change Fail Rate と SPACE の Efficiency and flow を組み合わせて測ると切り分けがしやすくなります。
