この記事で分かること
- AI導入後にPRレビューがボトルネック化する構造
- Claude Code GitHub Actions + Backlog MCPでレビューを分担する設計
- PRを3レベルに分けて「人間がどこまで読むか」を変える運用ルール
実装は速くなった。そしてレビューが詰まった
うちのチームは、もともと実装者7人にレビュアー3人。この体制のときレビューは普通に回っていました。
その後、体制が変わって実装者5人にレビュアー2人に。
人数比はほぼ同じです。7:3も5:2も、だいたい「実装2.5人にレビュアー1人」。
なのに、レビューが回らなくなりました。
犯人は人数ではありません。Claude Codeです。
実装者がAIを使うようになって、1人が出すPRの本数も、1本あたりの変更量も跳ね上がりました。実装のスループットだけが上がって、レビューのスループットは人力のまま。そりゃ詰まります。
「AIで開発速くなったわ〜」の裏で、レビュアーの画面にはレビュー待ちPRが積み上がっていく。同じ光景、あなたのチームでも起きてませんか?
レビュアーを増やす、以外の答え
「レビュアーを増やせばいいじゃん」
正論です。でもレビューできる人材って、そう簡単に増えないんですよね。仕様が分かってて、コードが読めて、マージに責任を持てる人。それが採れるならとっくに採ってます。
だから発想を変えました。
レビュアーを増やすんじゃなくて、「レビュー」という仕事を分解して、人間にしかできない部分だけを人間に残す。
レビュアーがやってることを分解すると、実はこの4つです。
- コードの品質チェック(規約、バグ、設計)
- 仕様の把握と、実装が仕様どおりかの確認
- 動作確認
- 「本当にマージしていいのか」という最終判断と、その責任
このうちAIに絶対渡せないのは4番だけ。マージボタンを押した結果に責任を負うのは、どこまでいっても人間です。
逆に言えば、1〜3は移せる。ここからが本題です。
設計:AIに一次レビューさせて、人間は「判断」だけする
3つの仕掛けを組み合わせます。全体の流れはこうです。
仕掛け1:Claude Code GitHub Actionsがコードを一次レビュー
Anthropic公式のGitHub Actionsを入れると、PRを出した瞬間にClaudeが差分をレビューして、インラインコメントを残してくれます。
しかも、リポジトリのルートに CLAUDE.md を置けば、チームのコーディング規約やレビュー基準をClaudeに叩き込めます。「うちではこう書く」レベルのローカルルール指摘まで自動化できるわけです。
導入手順は良記事がすでに山ほどあるので、この記事では割愛します(記事末尾にリンクを置いておきます)。
仕掛け2:Backlog MCPで「仕様と合ってるか」までAIに見せる
ここがこの記事の推しポイントです。
コードレビューって、実は「コードを読む」より「仕様を思い出して突き合わせる」のがしんどいんですよね。仕様書を開いて、課題チケットを読み返して、「あれ、この挙動って仕様どおりだっけ?」を頭の中でやる。ここに時間が溶けます。
うちは仕様書がBacklogにあります。そしてヌーラボはBacklog MCPサーバーを公式に公開しています。Claude Code GitHub ActionsはMCPサーバーの設定に対応しているので、レビュー時にBacklogの仕様書を読ませて、「実装が仕様と食い違っていないか」までチェックさせられるんです。
今までレビュアーの頭の中でやっていた仕様の突き合わせを、AIが一次チェックして結論を出す。人間は「AIの出した結論が妥当か」を見るだけ。
注意:Backlog MCPサーバーは自己責任での利用
MITライセンスでの提供で、ヌーラボのサポート窓口による公式サポートはありません。問題が出たらGitHub Issuesに報告するスタイルです。チーム導入時はここを共有しておきましょう。
仕掛け3:動作確認は「出した本人」がキャプチャを貼る
レビューで地味に一番時間を食うのが動作確認です。ブランチを切り替えて、ビルドして、画面を触って……これをレビュアー全員がやるのは無駄すぎる。
なので、実装者本人が動作キャプチャ(画面録画)をPRの説明に貼るのを必須ルールにします。
レビュアーはキャプチャを見るだけ。手元ビルドの工数がゼロになります。おまけに、実装者はキャプチャを撮る過程で自分のバグに気づきます。一石二鳥です。
本題:PRを3レベルに分ける
さて、ここまでの仕掛けを入れても、全PRを同じ深さでレビューしていたら意味がありません。
typo修正のPRと、課金処理のPRを、同じ真剣さで読むのがそもそもおかしい。
なのでPRをリスクで3レベルに分けて、レベルごとに「AIがどこまで見るか、人間がどこまで見るか」を変えます。この表が本記事の結論です。
| レベル1:軽微 | レベル2:通常 | レベル3:クリティカル | |
|---|---|---|---|
| 対象 | typo修正、文言変更、UIの余白や色の調整、コメント追加、依存パッケージのパッチ更新 | 画面追加、API追加、既存ロジックの変更、リファクタリング | 課金や決済、認証と認可、個人情報の取り扱い、データの削除やマイグレーション、外部公開API |
| AIレビュー | 実施(これで完結) | 実施(規約チェック + Backlog仕様との整合性チェック) | 実施(ただし参考情報の扱い) |
| 動作キャプチャ | 必須 | 必須 | 必須 |
| 人間のレビュー | しない(通知確認のみ) | 🔍 AIの指摘箇所と仕様整合の結論を重点確認。全行は読まない | 👀 全行レビュー + 手元での動作確認 |
| 人間の責任範囲 | マージボタンを押す判断のみ | AIの指摘の妥当性判断、設計方針の確認 | 従来どおりのフルレビュー |
レベル1:人間はコードを読まない
typo修正に人間のレビュー時間を1秒も使わない、という宣言です。
Claudeのレビューが通っていて、キャプチャが貼ってあれば、レビュアーはコードを読まずにApprove。人間の役割は「マージする」というボタンの責任だけです。
レベル2:人間は「AIの指摘箇所」だけ読む
通常の機能開発はここ。Claudeが規約と仕様の両面で一次レビューを済ませているので、人間はその指摘箇所と結論だけを確認します。
全行を読むのをやめる代わりに、「AIの指摘は妥当か?」「設計の方向性は正しいか?」という人間にしかできない判断に時間を全振りします。
レベル3:従来レビューをそのまま残す
課金、認証、個人情報。事故ったら終わる領域です。
ここではAIレビューを「見落とし防止の参考情報」に格下げして、人間が全行を読み、手元でも動かします。
効率化しないことが、この領域の正しい設計です。
レベル判定は「自己申告 + 迷ったら上」
PRテンプレートにレベルの自己申告欄を作って、実装者が申告 → レビュアーは妥当かを一目で判断。迷ったら上のレベルに倒す。これだけです。
PRテンプレートのイメージ:
## レビューレベル(自己申告)
- [ ] レベル1:軽微(typo、文言、UI微調整)
- [x] レベル2:通常(機能追加、ロジック変更)
- [ ] レベル3:クリティカル(課金、認証、個人情報)
## 動作キャプチャ
(ここに画面録画を添付)
## 関連するBacklog課題
PROJ-1234
GitHubのラベルでレベルを管理すれば、Actionsの挙動(レビューの深さやMCPを使うか)をレベルごとに出し分けることもできます。
それでも人間が絶対に譲らない2つのライン
ここまで読んで「AIに寄せすぎでは?」と思った方、正しいです。なので譲らないラインを明文化しておきます。
この2つだけは絶対に譲らない
- マージ承認は必ず人間がする
- セキュリティと課金まわりは必ず人間が全行読む
AIレビューは強力ですが、普通に間違えます。実際に運用した方の報告でも、指摘に偽陽性(問題ないコードへの誤指摘)が混ざった例が挙がっています。
だからこの設計は「AIを信じてレビューを省く」ではなく、 「AIの出力を、人間が判断するための材料にする」 という構造です。偽陽性がある前提でも、人間の注意を指摘箇所に集中させる価値は十分あります。
正直に言うと、まだ運用前です
期待させておいてすみません。この構成、まだ構想と検証の段階です。
Claude Code GitHub ActionsもBacklog MCPも技術的に実現可能なことは確認済みですが、チームでの本運用はこれから。運用して分かったこと(レベル分けの基準は現実的だったか、AIレビューの精度はどうだったか)は、続編で正直に書きます。失敗してたら失敗したと書きます。
あと、この設計でも解決しない問題が1つ残っています。 Backlogの仕様書が古いと、AIは古い仕様を「正」としてチェックしてしまう。 レビュー体制の再設計とセットで、仕様書を最新に保つ運用が必要です。これは逃げられません。
まとめ:速く読むな、読む場所を選べ
- AIで実装が速くなると、レビューだけが人力速度のまま残ってボトルネックになる
- レビュアーを増やすのではなく、レビューを「品質チェック / 仕様整合 / 動作確認 / マージ判断」に分解する
- 品質と仕様整合の一次チェックはClaude Code GitHub Actions + Backlog MCPへ、動作確認は実装者のキャプチャへ
- PRを3レベルに分けて、人間のレビューの深さをリスクに合わせる
- マージ判断と、セキュリティと課金の領域だけは人間が死守する
レビューが追いつかない問題の答えは「もっと速く読む」ことではなく、「読む場所を選ぶ」 ことだと思っています。
同じ課題で消耗しているチームの参考になれば嬉しいです。運用結果の続編もお楽しみに。