AIコードレビュー導入ガイド｜主要6ツール比較と人間レビューの分担

AIコードレビューとは｜Lint・静的解析との違い

結論として、AIコードレビューは「ルールを事前に書き下せない指摘」を担当します。Lintや静的解析が担うのは、期待値をルールとして定義できる領域です。両者は競合せず、守備範囲が違います。

Lintが見るもの、AIが見るもの

Lintの代表格であるESLintは、コードを抽象構文木（AST）に変換し、あらかじめ定義されたルールに適合するかを判定します。ESLintの公式ドキュメントでも、ルールが中核的な構成要素であり、コードが一定の期待を満たすかを検証するものだと説明されています。

裏を返すと、ルールとして書けないものはLintでは検出できません。「この変更は仕様の意図とずれている」「この関数名は既存の命名規約と矛盾している」といった指摘は、ルール化の対象外です。

AIレビューはここを埋めます。差分の前後関係と自然言語の文脈を読み、ルール化されていない違和感を指摘できる。ただし決定的ではありません。同じコードに対して毎回同じ指摘が返る保証はない点は、Lintとの根本的な違いです。

静的解析ツールとの棲み分け

SonarQubeのような静的解析プラットフォームは、より広い範囲を見ます。SonarSourceの公式ドキュメントによれば、SonarQubeはバグ・セキュリティ脆弱性・セキュリティホットスポット・コードスメル・アーキテクチャ上の問題を、マージやリリース前に継続的に検出する製品で、40以上の言語に対応します。

セキュリティ領域の自動検査をどう組むかは、SAST・DAST・SCAの違い｜Semgrep／Snykで始めるセキュア開発で整理しています。AIレビューはSASTの置き換えにはなりません。

実務での並べ方はシンプルです。

この順に通すと、人のレビューに届く時点でフォーマットと既知パターンは落ちています。多くのチームでは、AIレビューを入れる前にLintとフォーマッタをCIに組んでおくほうが投資対効果は高くなります。CIの組み方はGitHub Actionsとは？CI/CDの仕組み・基本ワークフロー・案件単価をフリーランス視点で解説を参照してください。

ミニFAQ：Lintが整っていないチームでも、先にAIレビューを入れる価値はありますか？

あります。ただし効果は限定的です。インデントや未使用変数のような指摘がAIコメントに混ざり、読む側がノイズとして扱うようになります。先にフォーマッタをCIで強制し、そのうえでAIレビューを足す順序を推奨します。

AIに任せる範囲と人間が見る範囲

結論は「構文・スタイル・典型バグはAIと機械、設計・要件・経緯は人」です。この線引きの根拠として参照しやすいのが、Googleが公開しているコードレビューガイドです。

Googleのガイドが挙げる「人が見る10観点」

Google Code Review Developer GuideのWhat to look for in a code reviewでは、レビュアーが確認すべき観点として Design、Functionality、Complexity、Tests、Naming、Comments、Style、Consistency、Documentation、Every line の10項目が挙げられています。

この10観点を機械化の難易度で並べ替えると、分担の輪郭が出ます。

• StyleとConsistency：ルール化できる。Lintとフォーマッタに渡す

• NamingとComments：ルール化しきれないが、良し悪しの判断基準は言語化しやすい。AIの一次指摘が効く

• ComplexityとTests：AIが指摘の糸口を出せる。ただし「このテストで十分か」の判断は人

• DesignとFunctionality：人が持つ。変更が本当にユーザーの課題を解くか、既存アーキテクチャと整合するかは、コード差分の外側にある情報で決まる

同ガイドのレビュー基準では、完璧でなくてもシステム全体のコード健全性を確実に改善する状態になったら承認を優先すべきだと述べられています。AIレビューの指摘を全件潰そうとすると、この原則から外れてマージが止まります。

レイヤー別の分担表

公開されている分担モデルと、実務での運用を踏まえて整理した目安が以下です。比率は厳密な計測値ではなく、どちらが主担当かを示す設計指針として読んでください。

テスト生成の自動化をどこまで任せられるかは、AIテスト自動化の実務｜生成AIで単体・E2Eテストを作る手順と限界で詳しく扱っています。

AIが構造的に苦手な3領域

ツールの性能差ではなく、仕組み上届きにくい領域があります。

1. 経緯。「この実装が不格好なのは、3か月前の障害対応で暫定的に入れたから」という文脈は差分に現れません

2. 組織の制約。レビュー対象のコードが、他チームとの合意や契約上の制約で縛られているケース

3. 本番の運用実態。データ量の偏り、特定顧客だけが踏むパス、深夜バッチとの競合

GitHubもCopilot code reviewの公式ドキュメントで、Copilotがプルリクエストのすべての問題を発見する保証はなく、ときに誤りを犯すこと、フィードバックは必ず検証し、人によるレビューで補うべきことを明記しています。ツール提供元が自ら人のレビューの必要性を書いている点は、導入提案の材料として使えます。

なお、指摘コメントそのものの書き方・受け方についてはコードレビューの作法｜指摘の書き方・受け方と信頼される進め方に分けてまとめています。本記事は「どの指摘を機械に出させるか」の設計に絞ります。

主要6ツール比較｜料金・セルフホスト可否

結論から言うと、選定軸は料金よりも「コードを外部に送れるか」と「人の工数をどこで減らしたいか」の2つです。以下の料金・仕様は2026年10月15日時点で各社の公式ページに記載されている内容を確認したものです。料金体系は改定が入りやすいため、検討時は必ず公式ページで最新の表示を確認してください。

料金・無料枠の条件・レート上限・セルフホストの提供条件は改定が入りやすい項目です。社内提案資料に転記する際は、検討時点で各社の公式ページの最新表示を必ず確認してください。

GitHub Copilot code review

GitHub上のプルリクエストに対し、差分をレビューして修正提案つきのコメントを残す機能です。公式の使い方ドキュメントによれば、既定ではCommentレビューとして投稿され、必須の承認にはカウントされません。指摘には深刻度ラベルが付きます。

すべてのPRに自動で走らせる設定は自動レビューの設定ドキュメントに手順があり、Copilot Pro／Pro+／Max、またはBusiness／Enterpriseのライセンスが必要です。プラン一覧ではFreeプランが0ドル、Proが月10ドル、Pro+が月39ドル、Businessが1席あたり月19ドル、Enterpriseが1席あたり月39ドルと記載されています。

すでにCopilotを契約しているチームなら追加費用ゼロで試せる点が実務上の利点です。Copilot本体の機能はGitHub Copilotの使い方｜エンジニアの開発効率と案件単価への影響を解説にまとめています。

CodeRabbit

PRの要約と行単位コメントに加え、差分の論理分割表示やセキュリティスキャンを持つPRボットです。料金ページでは、パブリックリポジトリにインストールした場合のレビューが無料と案内されています。有料はEssentialsが年払いで1人あたり月24ドル（月払い30ドル）、Teamが48ドル（月払い60ドル）、Advancedが72ドル。14日間のトライアルがあります。

見落としやすいのがレート上限です。Essentialsは開発者あたり1時間5レビュー・連携リポジトリ1件、Teamは1時間8レビュー・5リポジトリ、Advancedは1時間10レビュー・10リポジトリと記載されています。マージ頻度が高いチームは、席数より先にこの上限がボトルネックになりやすいです。

セルフホストは公式の説明でEnterprise顧客かつ500席以上が条件とされており、中小規模では現実的な選択肢になりません。

PR-Agent（OSS）／Qodo

qodo-ai/pr-agentはMITライセンスで公開されているOSSです。スラッシュコマンドでPRのレビュー・要約・改善提案を実行でき、GitHub、GitLab、Bitbucket、Azure DevOpsに対応します。Docker、CLI、GitHub Actionsのいずれでも動かせるため、LLMのAPIキーを自社管理下に置いたまま運用できる点が、他のクラウド型ツールと比べて大きな違いです。

リポジトリの説明では、このOSSプロジェクトが商用のQodo無料枠とは別物であることが明示されています。商用版はQodoの公式ドキュメントにありますが、料金体系は公開ページ上で確認できませんでした。導入検討時は直接問い合わせが必要です。

LLM利用料は従量で発生します。自前運用は「月額が安い」のではなく「送信先を選べる」ことに価値がある、と理解しておくほうが判断を誤りません。

Greptile

Greptileの公式サイトでは、コードベース全体のインデックスを構築したうえで、複数のエージェントがPRをレビューすると説明されています。差分だけでなくリポジトリ全体の文脈を踏まえる設計のため、既存実装との不整合を指摘しやすい方向に寄っています。

料金ページによると、Starterはアクティブ開発者1名・リポジトリ無制限・月50クレジットで無料、Proが1席あたり月30ドル、Enterpriseはカスタム。OSI承認ライセンスの非商用プロジェクトは無料枠の対象です。セルフホストはEnterpriseのみ。

Cursor Bugbot

Cursorの公式ドキュメントでは、新規PRやpushのたびに差分を解析し、バグやセキュリティ・品質上の問題を説明と修正案つきでコメントする機能として説明されています。GitHub、GitLab、Bitbucket、Azure DevOpsに対応。

課金は2026年5月の価格改定で席単位から従量課金へ移行しており、旧来の1席40ドルはlegacy扱いと記載されています。まずプランに含まれるusageを消費し、超過分がprepaid creditまたはlegacyプランのon-demand spendから引かれる形です。1レビューあたりの単価は公式ドキュメント上に記載が見つかりませんでした。第三者サイトには具体額を挙げるものもありますが、一次情報で確認できないため本記事では採用していません。Cursorをエディタとして使っているチームなら導線が短いのが利点です。エディタ側の比較はAIコーディングエージェント比較｜Cursor・Claude Code・Clineの選び方にあります。

Codacy

静的解析を軸に、コード品質とセキュリティの自動レビューとIDE連携を提供します。料金ページでは、Developerプランが無料で、VS Code・JetBrains・Cursorのプラグインとローカルスキャンが使えると記載されています。Teamは年払いで1人あたり月18ドル（月払い21ドル、最大30名）、Businessはカスタム。オープンソースプロジェクトはTeamプランが永久無料です。

公式に100%クラウドベースと明記されており、セルフホストはできません。LLMベースの対話的な指摘よりも、決定的なルール検査を厚くしたいチーム向けです。

ミニFAQ：複数のAIレビューツールを併用する意味はありますか？

1つのPRに2つのボットを走らせるのは推奨しません。コメント総量が倍になり、人が読む気を失います。併用するなら「決定的な静的解析（SonarQubeやCodacy）＋確率的なAIレビュー（CodeRabbit等）」のように役割の違う層を重ねる形にしてください。

導入の進め方｜2週間で効果を判断する手順

結論として、いきなり全PRに自動レビューを掛けないことが形骸化を避ける最大のコツです。以下は参画先に提案する場合の進め方です。

STEP1：観測する指標を2つだけ決める（所要1日）

導入前に、何がどうなれば成功かを合意します。欲張らず2つに絞るのが続くコツです。

• レビュー待ち時間（PR作成から最初の人のコメントまでの中央値）

• 人のレビューコメントのうち、スタイル・命名に関するものの割合

後者は手集計でも構いません。導入前の1週間ぶんを数えておくと、比較の土台ができます。AIレビューが効いていれば、人のコメントが設計や要件寄りに移動します。

STEP2：ラベル運用から始める（1週目）

全PRではなく、特定ラベルを付けたPRだけをレビュー対象にします。主要ツールはいずれも対象の絞り込み設定を持っています。1週目は、レビュアーが付きにくい領域や、自分が担当するモジュールのPRに限定してください。

このとき、AIのレビューを承認条件にしない設定にします。Copilot code reviewが既定でCommentレビューとして投稿されるのは、この考え方に沿った仕様です。

STEP3：ノイズを削ってから範囲を広げる（2週目）

1週目で出た指摘を分類し、「毎回出るが直さない指摘」を設定ファイルで抑制します。CodeRabbitならリポジトリ直下のYAML設定、PR-Agentなら設定ファイルで、対象パスや指摘の種類を調整できます。生成物ディレクトリ、マイグレーションファイル、スナップショットテストは除外対象の定番です。

2週目の終わりに、STEP1で決めた指標を再計測します。改善が見えなければ、ツールを替えるのではなく対象範囲と設定を見直すほうが先です。

導入タイミングとブランチ運用は連動します。PRの粒度が大きすぎるとAIレビューの精度も落ちるため、Gitブランチ戦略の選び方｜GitHub Flow・trunk-basedの違いもあわせて検討してください。

ミニFAQ：既存のレビュー文化が弱いチームに入れるとどうなりますか？

レビューが形だけのチームにAIを入れると、「ボットが見たから大丈夫」という追認が増えます。先に人のレビューの最低ラインを決めるほうが順序として正しいです。参画直後に文化へ介入する進め方はフリーランス参画初月の立ち上がり方｜30日で信頼を得るオンボーディング型を参考にしてください。

客先・受託案件で導入するときの制約

料金より先に確認すべきは契約です。クラウド型のAIレビューツールは、差分とその周辺コードを外部サービスへ送信します。顧客のソースコードを第三者のサービスに送る行為が、契約上許されているとは限りません。

前提として、業務委託契約やNDAの条項解釈、第三者提供・再委託の可否判断は現場だけで完結させない領域です。最終的な可否は、顧客側の法務・情報システム部門を含めて確認してください。以下は、その確認を持ちかけるときに論点を整理するためのリストです。

確認すべき3点

1. 再委託・第三者提供の条項。業務委託契約やNDAに、顧客データの第三者提供を制限する条項がないか

2. 学習利用とデータの扱い。送信したコードがモデルの学習に使われない設定か、提供元の記載を確認する。あわせて契約プランごとの条件差と、ログの保存条件も見ておく

3. 承認を取る相手。現場リーダーの口頭了承では足りないケースがあります。情報システム部門や法務の承認ルートを先に確認する

業務委託で生成AIを扱うときの一般的な注意点は業務委託で生成AIを使うときの契約・機密情報の注意点｜客先案件の実務に整理しています。

外部送信がNGなら選択肢は絞られる

契約上クラウド送信が難しい場合、現実的な候補はOSSのPR-Agentを自社インフラで動かし、LLMの接続先を顧客が管理するクラウド環境に向ける構成です。Greptileやその他のEnterpriseプランでも自己ホストの選択肢はありますが、席数や契約規模の条件が付きます。

判断の順序を間違えないでください。先に「送れるか」を確定させてから、ツールの比較に入る。逆順で進めると、比較検討に使った時間が丸ごと無駄になります。

よくある失敗と対策

失敗1：コメントが多すぎてPRが読めなくなる

導入初週に最も起きやすいパターンです。1PRあたり30件を超えるコメントが付くと、開発者は全部を閉じる作業に入り、指摘の中身を読まなくなります。

対策は設定ファイルでの抑制と、対象パスの除外。加えて、深刻度ラベルがあるツールでは低深刻度のコメントを非表示にする運用も有効です。

失敗2：AIが通したから人がざっと見で終わる

ボットが承認らしきコメントを出すと、人のレビューが形式化します。AIレビューを必須の承認者に設定しないこと、人のレビュアーには「設計と要件だけ見てほしい」と明示的に依頼することで、見る場所をずらします。

コードレビューの作法｜指摘の書き方・受け方と信頼される進め方で扱っている「指摘の優先度ラベル」を、AIコメントと人のコメントの区別にも流用すると運用しやすくなります。

失敗3：AIが書いたコードをAIがレビューする

同系統のモデルで生成したコードを同系統のモデルがレビューすると、同じ前提を共有しているぶん見落としが重なります。生成とレビューでツールを分ける、もしくはAI生成コードのPRには人のレビューを必ず付けるルールにしてください。

DORAが公開しているState of AI-assisted Software Development 2025（2025年版）では、AIの主な役割は増幅装置であり、組織が既に持つ強みと弱みの両方を拡大すると述べられています。レビュー体制が弱い組織にAIを入れると、弱さのほうが増幅されるという読み方ができます。AI投資の見返りに関する続編はROI of AI-assisted Software Developmentとして公開されており、刊行物の一覧はDORAのPublicationsページにまとまっています。

失敗4：指摘の全件対応を目指してマージが止まる

AIの指摘は提案であって要件ではありません。Googleのガイドが示すとおり、全体のコード健全性を改善する状態になったら承認する、という基準に戻してください。溜まった指摘を技術的負債として扱う考え方は技術的負債とは｜リファクタリング案件の合意形成と単価への影響が参考になります。

導入チェックリスト

提案から運用定着までに確認する項目をまとめました。このまま持ち込んで使えます。

10番を先に決めておくと、提案が通りやすくなります。導入の可否ではなく、試す期間と打ち切り条件をセットで出す進め方です。

まとめ

AIコードレビューの導入は、ツール選定ではなく役割分担の設計から始めるのが要点です。機械が見る層を下から積み上げ、人は設計と要件に集中する形に寄せると効果が出ます。

• AIレビューはLintの代替ではない。フォーマッタとLintをCIに組んでから足す

• 人が持ち続けるのはDesignとFunctionality。経緯・組織制約・運用実態はコード差分に現れない

• 選定の第一軸は契約。コードを外部送信できないなら、OSSのPR-Agent自前運用に候補が絞られる

• 無料で始める手段はある。パブリックリポジトリならCodeRabbit、開発者1名ならGreptile、静的解析寄りならCodacy

• 全PR一斉ではなくラベル運用から入り、2週間を目安に指標を再計測して判断する

• 最初の1本は条件で決める。既存のGitHub運用ならCopilot、外部送信の制約が強いならPR-Agent、静的解析を厚くしたいならCodacy系

• 撤退条件を先に決めた提案は通りやすい

次のステップとして、自分が参画しているプロジェクトで「直近1週間のレビューコメントのうち、スタイルと命名が何割か」を数えてみてください。その割合が高いほど、AIレビューで回収できる余地があります。

参照した一次情報は以下のとおりです。

• Google Code Review Developer Guide ／ What to look for in a code review ／ The Standard of Code Review

• GitHub Docs：Copilot code review ／ プラン一覧

• CodeRabbit 料金ページ ／ ドキュメント

• qodo-ai/pr-agent（GitHub）

• Greptile 料金ページ

• Cursor Bugbot ドキュメント

• Codacy 料金ページ

• DORA：State of AI-assisted Software Development 2025

• ESLint Core Concepts ／ SonarQube とは