コミット数2倍でもレビュー品質を維持！AI時代のコードレビューフロー再設計

WRITER: minhquang
このエントリーをはてなブックマークに追加

この記事は CyberAgent Developers Advent Calendar 2025 の17日目の記事です。

こんにちは！ハノイ開発センターに所属しているminhquangです。普段はAI事業本部の協業リテールメディアカンパニーで、小売企業様向けアプリ開発のバックエンド開発を担当しています。

CyberAgentではエンジニア一人あたり200ドルの開発AIエージェント費用サポートが全社展開されました。私のチームでも半年ほど前からCursorやClaude CodeやCodexなどのAIツールを導入しています。導入後、チーム全体のコミット数が導入前の約2倍になり、AIエージェントによる生産性向上の効果が数字としても表れています。

AIエージェント導入前後のコミット数推移

一方で、コード量が倍増したことにより、レビュー負荷も跳ね上がりました。それに対し、エンジニアのレビューに割く工数を2倍にするような対応はしづらいので、このままではコード品質の低下が避けられない状況です。

そこで本記事では、私のチームが「レビュー負荷軽減」と「品質担保」の2つのテーマにどう取り組んだのか共有したいと思います。

1. 従来のコードレビューのフローと課題

そもそもコードレビューは何のためにやっているのでしょうか。
コードレビューは、チームが解決したい課題に対して、「個人が書いたコード」を「チームのコード」に変えるための品質保証プロセスだと私は考えています。

私たちのチームでは、レビューイ(個人)とレビュアー(チーム)それぞれにおける責務を下記の通り明確にしています：

  • レビューイの責務
    • チームの解決したい課題に対して、適切なコードを実装すること
    • 自分が書いたコードをちゃんと説明できること
    • 自分が書いたコードの品質が担保できていること
  • レビュアーの責務
    • マージ可能なコード品質基準を満たしていることを保証すること
    • 「却下」または「承認」の判断を下すこと

この役割ごとの責務は、従来の開発プロセスでも、AI時代の今でも変わっていません。

従来のコードレビューフロー

ただ、AI時代になって、この従来のレビューフローでは品質保証における下記のような懸念ポイントが出てきています：

  • AIエージェントのおかげで実装速度が爆速になり、並列開発も当たり前 → レビュー待ちのPRが大量に積み上がる
  • AIが生成したコードは、まだまだ完璧とは言えない状態 → コード品質、一貫性、拡張性など、様々な観点でマージ可能性に懸念がある
  • AI生成コードの問題点を人間が見抜きにくいこと。レビューのハードルが一気に上がってしまう

つまり、レビュアーの負荷の問題は開発生産性を上げるための大きなボトルネックになってしまいます。

この課題を解決するために、フロー全体の見直しが必要だと判断して、レビューフロー自体を再設計することにしました。

2. AI時代のコードレビューフローを設計

前提として下記の二つの考え方をベースに持って設計しました。

  • レビュー待ちPRの品質を上げる → 人間のレビュー作業の「量」を減らし、重要な品質課題に集中
  • レビュー作業を効率化する → 人間のレビュー作業の「スピード」を上げる

AI時代のコードレビューフロー

このフローでは、レビューに到達する前に品質を高める仕組みと、レビュー作業自体を効率化する仕組みを組み合わせています。

次章からは、このレビューフローを実現するために工夫したポイントを1つずつ詳しく解説していきます。

3. 開発ガイドラインの強化: モノレポのガイドラインを統一

私のチームはモノレポで、バックエンド・ネイティブアプリ (モバイル)・フロント・インフラまで一緒に同じコードリポジトリで開発しています。なので、共通のガイドライン(docs/guidelines/)と領域専用のガイドライン({backend|frontend|native}/docs/guidelines/)を分けて定義しています。このガイドラインファイル群がコードベース全体の信頼できる唯一の情報源です。

モノレポのガイドライン構造

AIエージェントは種類も多いし、ガイドラインの参照方式もバラバラです。そこで、同じことを何度も再定義しないように、基本的にAIエージェントが使うガイドラインファイル(**/docs/**)から参照する形にしています。

AIはすでに一般的な知識を持っているので、標準的なことや一般的なことは書かなくて良いです。チーム独自のルールや知見、チームが選んだアプローチ、ビジネス固有の知識だけを追加で書いた方がいいです。

例：

### ガイドラインの具体例

❌ 一般的すぎる例（不要）
「エラーハンドリングを適切に行うこと」

✅ チーム固有の例（重要）
「DynamoDB操作では必ずConditionExpressionを使用し、
楽観的ロックを実装すること。」

✅ プロジェクト固有のパターン
「ユーザーIDの取得は必ずauth.GetUserID()を使用。
直接contextから取らないこと。」

4. SHIFT-LEFT: テストを超重要視する

AI時代では品質担保の要である自動テストを、私のチームにとって何よりも大事にするようになりました。「このPRで既存コードが壊れないか?」「他の部分に影響が出ないか?」といったことをレビューで確認するのは、コストも高いし認知負荷もかなり高いです。そこで、私たちのチームではテストは多ければ多いほど良いという考え方を導入しました。

ソフトウェア開発には「テストピラミッド」という考え方があります。

テストピラミッド図

テストピラミッド図

  • 単体テスト 70-80% : 実行速度も速いし保守コストも低いので、多めに書いてOK
  • 統合テスト 15-25% ：重要なエンドポイントをカバーしたらOK
  • E2Eテスト 5-15%：重要なユーザーシナリオのみをカバー。実行速度が遅いし保守コストも高いので、必要最低限でOK

テストの特性とコスト効率を考えながら、どの種類のテストをどう書くべきか、どのくらい書いたら良いか、品質と開発速度と保守性のバランスを考慮した戦略をとっています。ただ、超高い生産性が求められるAI時代では、同じ考え方で良いのか?と疑問に思いました。AI時代ではコード変更が激しく、パッケージアップデートや依存サービスの更新も頻繁に発生します。となると、単体テストだけじゃなく、統合テストもE2Eテストももっと書かないとダメじゃないかと思うようになりました。もちろん保守性や実行速度の課題はありますが、AI時代ではその課題の影響とコード品質とのバランスを取る方法があるのではないかと考えています。

テストコードの保守性については、AI共同開発でかなり解決できます。「このコードを修正したら、このテストも修正してね」みたいなルールをコードガイドラインに設定しておけば、大体AIが勝手にやってくれます。なので、コード変更時のテスト保守性は、この時代ではもう問題が薄くなります。

テストコードの実行速度については、さすがにAIでも解決できていません。ただ、テスト実行タイミングの調整と、どのコード修正に対してどのテストを実行するかの選定を工夫することで、開発速度への影響を最小限にできると考えています。私のチームでは、従来はPR作成時に全テスト(単体、統合、E2E)を実行していたため、重いE2Eテストの完了を待つ必要がありましたが、GitHub Merge Queueを活用してPR作成時は軽量なテストのみ実行し、重いE2Eテストはレビュー承認後に実行する形に変更したことで、mainにマージするコードの品質を確保しつつ、開発者の待ち時間を大幅に短縮できました。

開発速度と品質を両立させるために、「統合テストもE2Eテストも増やしていこう！」という「テストスカイスクレイパー」というテスト戦略をチームで導入しました。

テストスカイスクレイパー図

テストスカイスクレイパー図

全種類のテストがGOODです。どのレイヤーでも、必要なら多く書いてOK、という考え方にシフトしたわけです。

私のチームは、AIエージェント導入から6ヶ月以内に、エンドユーザーが使うAPIとバッチのE2E・統合テストを全部カバーできるように実装しました。さらに、コード変更したらE2E・統合テストの追加や保守も当たり前、という方針になっています。

例)バックエンドチームのテスト比率の推移(テスト行/コード行)

時点 テスト比率 (テスト行/コード行)
2025/06 78.6%
2025/09 95.2%
現在 (2025/12) 112.6%

5. 自動化の推進: レビュアー・レビューイの作業を自動化する

5.1 コードレビューの作業を自動化する

私のチームではClaudeとCursorを使っている開発者が多いので、自動化したい作業はコマンドとスキルの両方を用意しました。

※ 両方用意している理由は、この記事を書いた時点ではCursorにスキル機能がなかったためです。そのためコマンドも用意しました。

チームがよく利用しているスキルの例です。

スキル名 概要 トリガー例
creating-pull-requests 新規PRの作成（Draft） 「PRを作成して」
fixing-ci-failures CIエラーの診断・修正 「CIが落ちた」「CI直して」
handling-review-comments レビューコメントへの対応 「レビューコメントに対応して」
reviewing-pull-requests PRのコードレビュー 「PRをレビューして」

このスキルを使うことで、日々の作業を標準化できました。Claude CLIやCursorの環境だけで、PRの準備から対応まで全部できるようになっています。

例: ローカルのClaude CLIでPRを作成

> PR作成してください 

⏺ 現在のブランチ branch_hogehoge からPRを作成しますね。

  まず、変更内容を確認してから適切なPR説明を作成します。

⏺ Skill(creating-pull-requests)

⏺ PRを作成します。まず、現在のブランチの変更内容を確認してから、Draft状態でPRを作成しますね。

ローカルからCIの実行結果を見て対応して、コミットプッシュ

⏺ CI対応を行います。まず、現在のブランチのCI状況を確認してから修正していきます。

⏺ Skill(fixing-ci-failures)

⏺ CI対応を開始します。まず現在のPull RequestとCIステータスを確認しましょう。

⏺ Bash(gh pr status)
⏺ Bash(gh pr checks)

5.2 Claude CodeエージェントをGitHub PR上で稼働させる

私のチームは、日々GitHub PRの画面を見ながら、コメント確認・対応やCI課題の確認を行っています。「PR画面上でコードレビューまで進められたら、かなり効率化できるんじゃない?」と思って、PR上でClaude Code Actionを使って、Claude Code エージェントを稼働させることにしました。

コードレビューフローの色々な場面で、Claude Codeエージェントを活用しています。Claude Codeエージェントを使って、CIの課題を解決できます。

GitHub PRでのCI課題解決

GitHub PRでのCI課題解決

Claude Codeエージェントを使って、コメント確認から新しいPRを作成できます。

GitHub PRでコメント対応し、新規PR作成

GitHub PRでコメント対応し、新規PR作成

Claude Code Actionの活用シナリオは無限大で、生産性アップの強い武器だと考えています。この使い方だと並列開発しやすくなると思います。

チームでも大好評で、多くのメンバーが活用しています。

6. AIコードレビュー体制構築

現代のコードレビューフローでは、AIコードレビューが当たり前になったと思います。私のチームもCopilotを初め、GreptileやClaude Code Actionなど、色々なレビューツールを活用しています。

AIコードレビュー体制図

「3つもAIレビューツール使うの多くない?」という意見もあるかもしれませんが、AI進化の過渡期なので、あえて色々試したいという考えがあります。今後評価した上で使用するサービスを選定するかもしれないですが、一旦は異なるモデルで異なる視点から見てもらう体制にしたいと考えています。

6.1 各AIレビューツールの評価

各AIレビューツールを実際に運用してみて、下記のような所感があります。

項目 GitHub Copilot Greptile Claude Code Action
設定の難易度 シンプル シンプル ややこしい（権限周りに工夫が必要）
レビュー速度 最速 中程度 遅い
レビュー品質 中 高い（クリティカルに集中） 高い
ドメイン理解 中 良好 最も強い
特徴的な機能 • シンプルな統合
• 高速レビュー		 • PR上での対話機能
• 設計思想の議論が可能
• コメント・リアクションから学習
• カスタマイズルール自動作成		 • 深いコードベース理解
• 高品質なレビュー
カスタマイズ性 中 高い（自動学習機能あり） 無限大
注意点 – • ルールが全リポジトリに適用される
• リポジトリ専用の設定が難しい		 • レビュー速度が遅い
• Enterprise版でのAPIキー/個人トークン判断が難しい

私のチームメンバーのフィードバックを聞くと、GreptileとClaude Code Actionの方が品質が高くて、よく使われています。個人的に一番気に入ってるのはGreptileです。学習機能があって、人間のレビュアーみたいにレビューコメントの返信と相談もできます。さらに、レビューコメントから学習して、カスタマイズルールを自動生成してくれます。プロダクトと共にAIレビューツールも進化していくと感じています。

Greptileの学習機能

Greptileの学習機能

6.2 Claude Code Actionのレビューフロー作成

Claude Code Actionのレビューフローはカスタマイズの自由度がかなり高いです。私のチームでは、Claudeの公式例を参考にしながら、下記のフローを設計しました。

Claude Code Actionのレビューフロー

複数のサブエージェントに分けて、それぞれが特定のドメインを担当してレビューする設計にしました。

  • レビュー準備フェーズ: PRのメタデータを取得して、解決している課題、作成者、開発領域、その領域に該当する開発ガイドラインを収集。コンテキストを積み上げていく
  • レビューフェーズ: チームのガイドラインに沿って、観点別にレビュー用のサブエージェントを配置。
  • レビューコメントの重大度評価フェーズ: AIレビューコメントが妥当かどうか、嘘をついていないか、重大度はどうかを評価するサブエージェント。
  • レビュー投稿フェーズ: 重大度の高いコメントをPRにインラインでコメントしたり、サマリを送ったりします。すでに別のエージェントがコメントしている場合は、重複を避けてコメントしないようにした

このフローを試した結果、Claudeからのレビュー品質がかなり高くなりました。

単純にガイドラインを渡して「コード見てね」とお願いするより、チームのニーズに合わせてレビューフローをカスタマイズできるのが、非常によかったです。

6.3 AIを最終ゲートキーパーに

従来の運用では、レビュアーとレビューイが相談しながら、両方納得できる状態までコードを変更して、レビュアーがPRを承認していました。ただ、人間が挟むプロセスには、どうしても抜け漏れやオペミスが発生する可能性はあります。

この課題を解決するために、最終的なゲートキーパーを人間ではなく、AIに任せることにしました。

AIを最終ゲートキーパーにするフロー

人間のレビュアーがApproveした後、AIが次の観点で最終チェックして、結果をコメントしてくれます。

  • レビューコメントに対する対応が抜け漏れていないか
  • 変更差分に不具合がないか
  • 開発ガイドラインに違反している箇所がないか
  • PRマージ後の動作確認方法などの提案があるか

「マージOK」「マージに懸念あり」「マージ非推奨」といった判定と、その理由をコメントしてくれるので、人間のレビュアーとレビューイが確認できるようになっています。問題なければそのままマージしてOKですし、AIから懸念が上がった場合は、その課題に対応すべきか判断できます。

AIの最終評価で問題ない場合:

AIの最終評価（問題なし）

AIの最終評価で問題ある場合:

AIの最終評価（問題あり）

 

これで、レビュアーもレビューイも安心してPRをマージできて、品質を担保できるフローになりました。

7. サマリー

AI時代の到来で、エンジニアの生産性は間違いなく上がっています。この変化に合わせてコードレビューのあり方も見直す必要が出てきました。

私のチームでは、現在のレビューフローを振り返って、どこに改善の余地があるかを検討し、実際に施策を実行してきました。この取り組みを通じて実感したのは、AIは単なる支援ツールじゃなくて、信頼できるパートナーとして活用することで、大きな効果が得られました。

AI技術は日々進化していて、この波に乗り続けることが大事だと思っています。今回の改善で終わりじゃなくて、継続的に開発フローとコードレビューフローを見直しながら、時代の変化と一緒に進化していきたいです。

最後まで読んでいただき、ありがとうございました。

AWSでIPv6🎄クリスマスツリー🎄をつくろう
次の記事