AIにコードを書かせていて、レビューが追いつかなくなっていませんか？
AIはPR（プルリクエスト）をどんどん出してくれます。でも、それを全部人が一行ずつ読んでいたら、結局人のところで渋滞してしまいます。少人数の会社だと、なおさらです。
ちょうど10/15に、AnthropicのClaude Codeチームが「自分たちはコードレビューをどうやっているか」をブログで公開していて、Xでも話題になっていました。今回はその記事も参考にしながら、自分たちがAIのPRをどう扱っているかをご紹介しようと思います！
AIが出すPR、多すぎる問題
Claude Codeチームの記事によると、Claude Codeのコードは約9割をClaude自身が書いているそうです。Anthropicのモノレポでは、1日に取り込まれる変更が5月の約2,500件から、9月には30,000件超まで増えたとのことです。
記事の中でも、この速さで出していると手作業で一行ずつ読むレビューはほぼ不可能だ、と書かれていました。
ここまでの規模ではなくても、AIエージェントにPRを出させるようになると、同じことは小さいチームでも起きます。AIがいくら速く書いてくれても、人が全部読むやり方のままだと、そこで止まってしまうんですよね。
PRが出たら「AIを信用する」が前提
そこで、AIからPRが出たときは「AIを信用する」ことを前提にしています。毎回すべての差分を一行ずつ読むことは、基本にしていません。
Claude Codeチームの記事にも、近い考え方が書かれていました。自分で訳すと、
「人がコードを読んだか？」は、「この変更で何が起こりうるか、それを捕まえるのに一番いいチェックは自動か人か？」の不正確な代わりでしかない
とのことです。
噛み砕くと、人が読んだかどうかより、壊れそうなところをちゃんと捕まえられているかの方が大事だよ、と言った感じです。
とはいえ、AIの「できました」をそのまま信じるのは危ないです。テストを流していなかったり、画面を一度も開いていなかったりしても、AIは悪気なく「終わりました」と言ってきます。なので、信用するなら信用できるだけの材料が必要になります。
どうすればAIを信用できるか
じゃあ何があれば信用できるのか、を仕組みにしておくことにしました。ここでもClaude Codeチームの記事がかなり参考になりました。
終わったと言わせずに、結果を見せてもらう
記事では、Claudeにテストやビルド、デザインと比べるためのスクリーンショットなど実行できるものを渡して、「終わった」と言う代わりにその出力を見せてもらうようにしているそうです。Claude Codeを作ったBoris Chernyさんも、AIに自分の作業を検証する手段を渡すことが、良い結果を出すためにおそらく一番大事だと言っているとのことでした。
人が見るところはリスクで決める
もう一つは、人の承認を変更のリスクで変えるやり方です。記事の内容をざっくりまとめると、
・ドキュメントや文言、フラグの裏に隠れた追加など、リスクが低いもの
自動レビューとセキュリティチェックが通れば、人の承認はいらない
・普通のプロダクト変更や、キャッシュ・自動アップデーターなど要注意な箇所
1人が承認する
・一番リスクが高いコードと、常に2人必要と決めたパス
2人が承認する
となっています。リスクは誰が書いたかでなく何を変えたかで決めること、AIに書かせたPRはAIに指示した人が責任を持つことも書かれていて、ここはそのまま使える考え方だなと思いました。
人に残る仕事としては、そもそも作るべきかの判断や、決済やCIのようなリスクの高いコードに加えて、テストの出力やスクリーンショットといった「証拠を読むこと」が挙げられていました。
Cursorに証拠付きでやらせる
ここからが具体的なやり方です。Cursorのクラウドエージェントに、実装ができたら必ず証拠付きで「できました」と言ってもらうようにしています。
Cursorのクラウドエージェントでできること
公式ドキュメントによると、Cursorのクラウドエージェントは1体ごとに独立したVM（仮想マシン）の上で、デスクトップ環境ごと動いています。マウスとキーボードでブラウザも操作できるので、開発サーバーを立ち上げて画面をクリックして、変更がちゃんと動くかをPRを出す前に確かめられます。
さらに、スクリーンショットや動画、ログを「アーティファクト」として作ってPRに添付してくれます。こちらはブランチを手元に落とさなくても、それを見れば確認できるのでとても便利です。
ここまでできるなら、確認した証拠も一緒に出してもらった方がいいよね、という考えです。画面の変更ならスクショや動画、ロジックの変更なら実行したテストの結果、という感じで、変更に合わせた証拠を付けてもらいます。認証や決済、DB、デプロイ設定のようにリスクの高い変更は、証拠があっても人がコードを見ます。
ルールとPRテンプレートの例
Cursorでは、リポジトリ直下の AGENTS.md や .cursor/rules に書いたルールをエージェントが読んでくれます。毎回プロンプトでお願いするより、ルールに書いておく方が確実です。たとえばこんな感じです。
<!-- AGENTS.md（例） -->
## 完了報告のルール
- 「できました」と言う前に、自分で動作を確認すること
- 完了報告には必ず証拠を付けること
- 画面の変更：変更後のスクリーンショット。操作が絡むなら動画
- ロジックの変更：実行したテストのコマンドと結果
- デプロイした場合：本番のURLと、本番で確認した結果
- 確認できなかったことは「確認できていない」と書くことPRテンプレートにも、証拠を貼る欄を作っておくと抜けにくくなります。
<!-- .github/pull_request_template.md（例） -->
## 何を変えたか
## 証拠
<!-- スクリーンショット・動画・テストのコマンドと結果 -->
## 確認できていないこと
## 戻し方「確認できていないこと」の欄があると、人がどこを見ればいいかがわかりやすくなるのでおすすめです！
写り込みには注意
一つ気をつけたいのが、スクショや動画への写り込みです。Cursorのドキュメントによると、アーティファクトをGitHubのPR説明に埋め込む設定はオプトインで、オンにすると推測されにくい長いURLで、ログインなしでも見られる形になるそうです。ツールの出力やアーティファクトにシークレットを含めないように、という注意も書かれています。お客さんのデータやトークンが写らないように、テスト用のデータで確認してもらうのが安心です。
まとめ
AIのPRとの付き合い方について書いてみましたが、いかがでしたでしょうか？
AIが書くコードはこれからも増えていくので、全部を人が読むやり方はどこかで限界がくると思います。「AIを信用する」を前提にしつつ、信用できるように証拠を出してもらう形で回しています。同じようにレビューで詰まっている方の参考になればうれしいです！