AIコードレビューとは？仕組み・ツール比較・導入手順

コードレビューとは：目的と主な観点

コードレビューは、書いた本人以外がマージ前にコードを読み、問題がないかを確かめる工程です。目的は不具合の早期発見だけではありません。設計の妥当性の確認、チームの規約の統一、知識の共有も兼ねています。GitHubでは、プルリクエストの差分に行単位でコメントを付け、承認を得てからマージする流れが一般的です。

レビューで確認する観点は、チームによって表現は違っても、おおむね次のように整理できます。

• 正しさ：仕様どおりに動くか。条件分岐や境界値、エラー時の挙動に漏れはないか。
• 影響範囲：変更していない呼び出し元や、ほかの機能を壊していないか。
• セキュリティ：権限チェックの漏れ、秘密情報のログ出力、入力値の検証不足がないか。
• 保守性：命名、責務の分け方、重複したロジックは適切か。
• テスト：変更した振る舞いを確かめるテストがあるか。

ただ、実際のレビューコメントは不具合の指摘より改善提案に偏りがちです。Microsoft Researchの調査では、開発者がレビューに期待する一番の目的は不具合の発見だった一方、不具合に関するコメントは全体の14%にとどまりました。人のレビューが手薄になりやすいこの「不具合探し」こそ、AIが最も役立つ部分です。

AIコードレビューとは：人のレビューとの違い

AIコードレビューは、LLMを使ったレビュアーがプルリクエストを読み、問題点をコメントで返す仕組みです。従来の静的解析（リンター）は決められたパターンに一致するコードしか検出できませんでしたが、LLMは変更の意図や呼び出し関係を読み取り、「この変更で共有リンクから除外IPが漏れる」といった文脈に依存する問題も指摘できます。

現在よく使われている形は、大きく3つに分かれます。

• Git ホストに入れるレビュアー：GitHub アプリとしてリポジトリに入れ、PRが開かれるたびに自動でレビューします。HeyDeer、CodeRabbit、GitHub Copilot コードレビューなどです。
• コーディングエージェントのレビュー機能：Claude Code の /code-review や Codex の /review のように、手元の変更をプッシュ前にレビューします。
• 自作のレビュー：GitHub Actions からLLMのAPIを呼ぶ、プロンプトを用意してエージェントに読ませるなど、自分たちで組み立てる方法です。

AIコードレビューは人のレビューを不要にするものではなく、一次レビューを肩代わりするものです。AIはすべてのPRを数分で同じ基準で確認できますが、その機能が本当に必要か、設計が今後の拡張に耐えるかといった、リポジトリの外にある情報が必要な判断はできません。AIが不具合を拾い、人が判断を担う分担が現実的です。

AIコードレビューの仕組み

ツールによって細部は違いますが、PRをレビューする流れはほぼ共通しています。品質の差は、どれだけ広く文脈を読むかと、自分の指摘をどれだけ厳しく検証するかで生まれます。

1. 起動：PRが作成・更新されたとき、またはコメントでレビューを依頼されたときに動きます。
2. 文脈の収集：差分だけでなく、変更されたファイル全体、それを呼び出しているコード、REVIEW.md や AGENTS.md に書かれたチームのルールを読みます。
3. 候補の洗い出し：ロジックの誤り、エッジケースの漏れ、セキュリティ上の問題、呼び出し元との契約違反、ルール違反など、問題の可能性がある箇所を挙げます。
4. 検証：精度の高いレビュアーは、候補を投稿する前にコードと突き合わせて確かめます。HeyDeer では、潜在的な問題を別のモデルが一つひとつ検証し、裏付けが取れたものだけを投稿します。
5. 出力：該当行へのインラインコメント、全体のサマリー、マージ可否の判断に使えるステータスチェックを返します。修正PRまで作るツールもあります。

この中で品質を最も左右するのが検証の工程です。検証がなければ、レビュアーは疑わしい点をすべて報告します。検証があれば、コードで裏付けられることだけを報告します。HeyDeer が ReviewBench で 99.0% の適合率を出せているのは、この工程があるためです。

AIが得意な指摘と苦手な指摘

AIレビューが強いのは、答えがコードの中にある問題です。

• エラー処理の漏れ、空の入力やリクエスト失敗といったエッジケースの見落とし
• 権限フィルタのないクエリ、URLに含まれた秘密情報などのセキュリティ上の問題
• 変更していない別ファイルの呼び出し元を壊す変更
• 計算したのに使われていない値、決して真にならない条件
• 「金額は整数の銭（セント）単位で保存する」のような、チームが書き残したルールへの違反

反対に、答えがリポジトリの外にある問題は苦手です。

• その機能が本当に必要か、ユーザーの期待どおりに動くかという仕様の判断
• 抽象化が今後の成長に耐えるか、変更を置く場所が適切かという設計の方向性
• 他チームとの取り決め、本番データの実態、過去の障害の経緯など、人の頭の中にある文脈

また、どのレビュアーもすべての不具合を見つけられるわけではありません。HeyDeer の ReviewBench での再現率（ラベル付きの問題のうち見つけた割合）は 51.4%で、およそ半分です。AIレビューを通ったことは「重大な問題が見つからなかった」という意味であり、テストや人の確認の代わりにはなりません。

誤検知（偽陽性）がチームの負担になる理由

以前なら、的外れなレビューコメントは人が1分で読み飛ばせば済みました。今はコーディングエージェントがレビューコメントを受けて自動で修正します。研究では、エージェントは指摘が誤っていると判断できる場合でも修正依頼に従う傾向があると報告されています（Jaiswal et al.、2026年）。誤検知が一つあるたびに、誰かがレビューしなければならない変更が一つ増え、本当のバグがノイズに埋もれます。

開発者はすでにこの問題を感じています。2025年の Stack Overflow 開発者調査では、84% がAIツールを使っている、または使う予定と答えた一方で、AIの正確さを信頼する人（33%）より信頼しない人（46%）のほうが多く、最も多い不満は「ほぼ正しいが、完全ではない」出力（66%）でした。誤検知の多いレビュアーは、この不満をさらに増やします。

そのため、レビュアーは2つの数字で判断します。報告した指摘のうち本当に問題だった割合である適合率（precision）と、実在する問題のうち見つけられた割合である再現率（recall）です。両者はトレードオフの関係にあり、何でも報告するレビュアーは多くを見つける代わりに間違いも増えます。私たちが自社のPRで行った 6,000回以上のレビュー実行の分析 でも、このバランスはモデルだけでなくレビューの進め方で大きく変わりました。

主なAIコードレビューツールの比較

代表的なツールを、提供形態と料金体系で並べました。料金は各社が公開している米ドルの定価で、ReviewBench の数値は標準表示（重大度の高い指摘）の適合率です。ReviewBench で計測されていないツールは「—」としています。

選び方の目安は、誰がコードを書いているかです。Claude Code や Codex を使っているなら、まず付属のレビュー機能を試すのが手軽です。使い方は Claude Code でコードレビューする方法 と Codex でコードレビューする方法 で説明しています。複数のエージェントと人が同じリポジトリで書いているなら、どのPRも同じ基準で見る独立したレビュアーが向いています。開発者が増えるほど、席単位の課金とワークスペース単位の課金の差は大きくなります。

9つのツールの料金とベンチマークを詳しく比べた 適合率で選ぶAIコードレビューツールの比較 や、Claude Code Review との料金比較（HeyDeer vs Claude Code Review）もあわせて参考にしてください。

チームへの導入手順

1. 対象を絞って始める：まず1〜2個のリポジトリで自動レビューを有効にします。変更の多いリポジトリを選ぶと、短期間で効果を判断できます。
2. レビュー観点を文書にする：チームの観点表やレビューで繰り返し指摘している内容を、REVIEW.md（レビュー専用のルール）や AGENTS.md（コーディング規約）に書きます。書き方は次の節で紹介します。
3. コメントの言語をそろえる：日本語のチームなら、指摘も日本語で読めるほうが確認が速く進みます。HeyDeer は レビューの言語 で日本語を選ぶと、指摘事項やチェックの結果をすべて日本語で投稿します（コードとファイルパスはそのままです）。
4. PRを小さく保つ：Google では、変更の中央値は24行で、レビューにかかる時間の中央値は4時間未満でした。小さなPRは、人にとってもモデルにとってもレビューしやすくなります。
5. 指摘は「主張」として扱う：AIの指摘をそのまま直すのではなく、根拠となる行を確かめてから対応します。エージェントに修正させる場合も、指摘を検証してから直すよう指示します。
6. 人の役割を決め直す：AIが一次レビューを担う前提で、人は設計・仕様・保守性を見ると決めておくと、二重チェックの無駄が減ります。

AIレビューの観点を書く：REVIEW.md の例

AIレビューの質を上げる一番の近道は、プロンプトを工夫することより、リポジトリ固有の観点をファイルに書き残すことです。一般的なレビューの作法はモデルがすでに知っているので、書くのはそのリポジトリにしかない事情だけで十分です。

# Review instructions

## 必ず確認すること
- ログにメールアドレス、アカウントID、リクエスト本文を出力しない。
- src/api/public/ に追加したエンドポイントは openapi.yaml に載せる。

## 指摘しないこと
- フォーマットと lint の問題（CI で検出している）。
- tests/fixtures/ の、意図的に本番のルールを破っているコード。

## 深刻度
- 後方互換性のないマイグレーションは High。
- 命名やリファクタリングの提案は Low。

## 根拠
- 「この関数は null を返しうる」という指摘には、null を返す行を示す。

REVIEW.md は Claude Code Review も読むファイルなので、同じ内容を複数のレビュアーで共有できます。HeyDeer での書き方は REVIEW.md のドキュメント に、見落とすと影響の大きい要件を専任のレビュアーに確認させる方法は リポジトリのチェック にまとめています。

AIが書いたコードをレビューするときの注意点

AIが生成したコードには、人が書いたコードと同じかそれ以上の注意が必要です。Veracode の2025年の調査では、AIが生成したコードのサンプルの45%がセキュリティテストに失敗し、OWASP Top 10 に該当する脆弱性を含んでいました。スタンフォード大学の研究では、AIアシスタントを使った開発者はより安全性の低いコードを書きながら、そのコードを安全だと信じる傾向が強いことがわかっています。

コードを書いたモデル自身にレビューさせると、同じ思い込みで同じ箇所を見落としがちです。別のモデルで作られたレビュアーなら、書き手のモデルが見逃した問題に気づける可能性があります。モデルの多様性は盲点をあぶり出す手段であり、見落としがなくなる保証ではありませんが、エージェントが書くコードが増えるほど効果は大きくなります。

8つのコーディングエージェントが書いた16件のPRで HeyDeer と GitHub Copilot コードレビューを比べた ベンチマーク では、どのエージェントも問題のあるコードを出していました。エージェントの書いたPRをレビューする使い方は コーディングエージェントのPRレビュー で紹介しています。

AIコードレビューツールを評価する方法

公開ベンチマークは比較の出発点になりますが、自分たちのコードでどう働くかは試してみないとわかりません。おすすめは、最近マージしたPRを10〜20件選び、候補のツールに同じPRをレビューさせて比べる方法です。

• 役に立った指摘の数：実際に直すべきだった問題をいくつ見つけたか。
• 誤検知の数：確認した結果、問題ではなかった指摘はいくつあったか。
• 確認にかかった時間：指摘を読んで判断するまでに何分かかったか。
• 実際の月額：自分たちの開発者数とPR数で計算した料金。席単位か、レビュー単位か、ワークスペース単位かで大きく変わります。

採点用のワークシート付きの手順は、英語版の AIコードレビューを自分たちのPRで評価する方法（英語） にまとめています。

参考資料

1. ReviewBench
2. Stack Overflow Developer Survey 2025: AI
3. Veracode: 2025 GenAI Code Security Report
4. Perry et al. (Stanford): Do Users Write More Insecure Code with AI Assistants?
5. Bacchelli & Bird (Microsoft Research): Expectations, Outcomes, and Challenges of Modern Code Review
6. Sadowski et al. (Google): Modern Code Review: A Case Study at Google
7. Jaiswal et al.: coding agents and incorrect review feedback
8. GitHub Docs: Copilot plans
9. GitHub Docs: About Copilot code review
10. CodeRabbit: Pricing
11. Cursor: Bugbot pricing changes (May 2026)
12. Claude Code Docs: Code Review costs
13. OpenAI Codex docs: pricing