AIがコードを量産する時代に、PRのレビューが詰まっている。AIコーディングでPRが154%大きくなるという問題は既に指摘されているが、レビュアーの数はそのままだ。
そこに「AIがPRを自動レビューする」という解答として登場したのがCodeRabbitだ。2026年2月時点で200万以上のリポジトリに接続され、GitHubで最も多くインストールされているAIアプリの位置にある。NVIDIAのCEO、Jensen HuangがNVIDIA全社で使っていると公言したことで一気に知名度が上がった。
この記事では、CodeRabbitが実際に何をしてくれるか、何を見落とすか、そして見落とした欠陥は何かを検証する。
CodeRabbitとは何か
CodeRabbitはGitHub・GitLab・Azure DevOps・Bitbucketに接続するPR自動レビューボットだ。インストールはGitHub Marketplaceから2クリックで完了する。インストール後は、新しいPRが作られるたびに自動でレビューコメントを投稿する。
公式サイトが公表している数字は以下のとおりだ（2026年2月時点）。
- 接続リポジトリ数：200万以上
- 発見した欠陥数：7500万件
- 導入企業数：10,000社以上
これらは自社発表の数字であり、独立した第三者検証ではない。ただし200万リポジトリという規模は、「試した結果、使い続けている」プロジェクトが相当数あることを示している。
何をしてくれるか
CodeRabbitがPRを受け取ると、次のことを自動で行う。
PR要約とウォークスルー：変更の概要、変更されたファイルの一覧、各ファイルの変更意図を自動生成する。大きなPRでも「どこから読めばいいか」が一目でわかるようになる。
コードレビューコメント：構文エラー、セキュリティ上の問題、コーディング規約違反、パフォーマンスの問題を検出してコメントする。40種類以上の静的解析ツール（SAST：コードを実行せずに脆弱性を自動検出するツールを含む）の結果をまとめて表示する機能もある。
コードグラフ分析：ファイル間の依存関係を分析し、変更が他の箇所に与える影響を把握する。
.coderabbit.yaml というファイルをリポジトリのルートに置くことで、レビューの挙動を細かく制御できる。
# ❌ デフォルトのまま（全ファイルにフル指摘）
# → ノイズが多く、重要なコメントが埋もれる
# ✅ チーム向けにカスタマイズ
reviews:
profile: "chill" # assertive（厳格）→ chill（ノイズ少なめ）
request_changes_workflow: false
path_instructions:
- path: "**/*.test.ts"
instructions: "テストコードは実装のカバレッジを優先してレビュー。スタイルの指摘は不要"
- path: "src/api/**"
instructions: "セキュリティとエラーハンドリングを最優先でレビュー"
auto_review:
enabled: true
drafts: false # ドラフトPRはレビューしない
デフォルトのまま使うと、些細なスタイルの指摘が大量に来て本質的なコメントが埋もれやすい。profile: "chill" に変えるだけでノイズが大幅に減る。
AIコードのほうが問題が多い——皮肉な研究結果
CodeRabbitは自社で「AIコードと人間コードの品質比較」を研究・公開している。
470件のオープンソースPRを分析した結果がこれだ（2026年2月時点）。
- 全体のバグ密度：AI生成コードは人間の約1.7倍（PR1件あたり10.83件 vs 6.45件）
- セキュリティ脆弱性：AI生成コードは最大2.74倍多い
- パフォーマンス問題：AI生成コードは約8倍多い（主に過剰なI/O処理）
- ロジックエラー：AI生成コードは75%多い
つまりCodeRabbitは、自社のツールが最も必要とされる原因（AIコードの品質問題）を自ら数値で示している。AIコーディングが普及するほど、AIレビューの需要も増えるという構図だ。
ベンチマーク評価——得意なことと苦手なこと
AIMultipleが2026年に実施したRevEval（309件のPR、10名の評価者、GPT-5を審査AIとして使用）では、CodeRabbitは4軸で評価されている。
| 評価軸 | スコア |
|---|---|
| 正確性（コメントが間違っていないか） | 4/5 |
| 実行可能性（修正方法が具体的か） | 4/5 |
| 完全性（問題を見落としていないか） | 1/5 |
| 深さ（設計意図まで踏み込んでいるか） | 2/5 |
309件中51%で「最も優秀なツール」と評価されており、GitHub Copilot・Greptile・Cursor BugBotを上回っている。
正確性と実行可能性は高い。コメントの内容は合っていて、修正方法も具体的だ。問題は完全性だ。「見つけたコメントは正確だが、見逃している問題が多い」という評価になる。
「校閲者」であって「編集者」ではない
CodeRabbitをどう使うかを理解するには、この比喩が役に立つ。
優秀な校閲者に原稿を渡したとする。誤字・脱字・文法ミスは確実に直してくれる。文体の揺れも、参考文献の漏れも指摘してくれる。でも「この章の論旨がおかしい」「読者がここで混乱する」という指摘はしない。それは編集者の仕事だ。
CodeRabbitは優秀な校閲者だ。しかし編集者ではない。
実際のコードで見ると、こういう差になる。
// ❌ AIが生成したコード（レビュー前）
async function getUserData(userId: string) {
const user = await db.users.findAll({ where: { id: userId } });
return user;
}
// ✅ CodeRabbitのコメントに対応した後
async function getUserData(userId: string) {
try {
const user = await db.users.findOne({ where: { id: userId } });
if (!user) throw new Error("User not found");
return user;
} catch (error) {
logger.error("getUserData failed", { userId, error });
throw error;
}
// ⚠️ 注意: 呼び出し元でuserIdの所有者チェックが必要（CodeRabbitは検出できない）
}
CodeRabbitが指摘するのは findAll → findOne（無駄なクエリ）とエラーハンドリングの欠如だ。これは正確で実用的な指摘だ。
しかし userId の所有者チェック——「このユーザーが他人のデータを取得していないか」という認可の問題——はCodeRabbitには見えない。コードの外側にある仕様やビジネスロジックの文脈が必要だからだ。
「CodeRabbitのレビューを通過した＝安全」ではない。構文エラーとスタイル違反は検出できる。ビジネスロジックの整合性と認可の問題は見落とす。
何を見落とすかのリストをまとめると：
- 意図のずれ（「何を作るか」の判断）
- クロスサービス依存（別サービスとの整合性）
- 認可の問題（誰がこのデータを取得していいか）
- パフォーマンスの意味論（なぜこの処理がここにある必要があるか）
これらはいずれも、コードの外側——要件定義、設計決定、ビジネスの文脈——を知っていないと判断できない。
2025年1月のセキュリティインシデント
CodeRabbitを扱う上で避けられない話題がある。
2025年1月、セキュリティ企業Kudelski Securityが、CodeRabbitに対するRCE（リモートコード実行）脆弱性を発見した。同年8月のBlack Hat USA 2025で公開されている。
攻撃の手口はシンプルだった。悪意ある .rubocop.yml をPRに含めるだけでよかった。RuboCopはRubyのコード解析ツールで、設定ファイルで任意のRubyコードをロードできる機能がある。CodeRabbitがRuboCopを実行したタイミングで、攻撃者のコードがCodeRabbitのサーバー上で動く。
この脆弱性で潜在的に漏洩するリスクがあった情報は以下だ。
- AnthropicのAPIキー
- OpenAIのAPIキー
- GitLab Personal Access Token
- Jiraの認証情報
- PostgreSQLの接続情報
- CodeRabbitのGitHub App秘密鍵
最後の項目が特に重い。当時CodeRabbitは約100万リポジトリにアクセスできる権限を持っていた。GitHub Appの秘密鍵が漏洩すれば、そのリポジトリ全体に対して読み書きが可能になる。
CodeRabbitの対応はこうだった。発見後数時間以内にRuboCopを無効化し、全クレデンシャルをローテーション、セキュリティ監査を実施した。公式の対応説明も公開している。
一方で批判もある。インシデントは2025年1月に発生したが、公開されたのは同年8月、Black Hat発表のタイミングだ。6ヶ月以上、ユーザーへの開示がなかった。
防犯カメラを設置したが、その防犯カメラ自体に穴があった、というのがこのインシデントの本質だ。ツールに権限を与えるということは、そのツール自体が攻撃対象になりうることを意味する。
CodeRabbitのようなAIレビューツールは、リポジトリへの読み書き権限を持つ。インストール時に「このアプリにどこまでのアクセスを許可するか」を確認する習慣をつけておくことが重要だ。
料金と向いているチーム
CodeRabbitの料金は2026年2月時点で以下のとおりだ。
| プラン | 料金 | 内容 |
|---|---|---|
| Free | $0 | パブリック・プライベートリポジトリ無制限、PR要約 |
| Pro | $24/ユーザー/月（年払い） または $30/月 | 無制限PRレビュー、静的解析ツール統合 |
| Enterprise | カスタム | セルフホスト可能、SLA対応 |
Freeプランは14日間のProトライアル付きで、クレジットカード不要だ。
コスト面で考えると、Proプランは1人月$24。レビュアーが週に数十件のPRをさばいている状況なら、手動レビューの時間をどれだけ削減できるかが判断軸になる。CodeRabbitのユーザー報告では手動レビュー工数が50%削減、レビューサイクルが80%短縮されたという声もある（公式サイト記載、自社調査）。
向いているケースは以下だ。
- 小規模スタートアップ（50人以下）でレビュアーが少ない
- OSSメンテナーで外部からのPRが多い
- AI生成コードのセキュリティ・スタイルチェックを自動化したい
向いていないケースもある。
- 設計レビューや要件の整合性確認を自動化したい
- 「AIレビューを通過すれば品質保証完了」という運用にしたい
AIがAIを審査する構造の現実
Claude CodeやCursorのようなAIコーディングツールでコードを書き、CodeRabbitでレビューする——このパイプラインはすでに多くのチームで実運用されている。
効率面では合理的だ。AIが書いた答案をAIが採点することで、人間の作業量は確実に減る。
ただし、「そもそもこの問題を解く必要があったのか」「この設計で本当によかったのか」という問いは誰も立てない。AIは与えられた文脈の中で最適化するが、文脈そのものを疑う判断は人間が持つ必要がある。
CodeRabbitの完全性スコアが1/5である事実は、この構造に直結している。AIレビューは「存在する問題の一部を検出する」ツールであり、「問題の全体を把握する」ツールではない。増え続けるAI生成コードに浅いAIレビューを重ねるほど、見落とされた問題が積み上がるリスクも増す。
まとめ
CodeRabbitは「優秀な校閲者」だ。誤字脱字とコーディング規約のチェックは確実で速い。200万リポジトリで使われているのは、その部分に確かな価値があるからだ。
しかし編集者ではない。ビジネスロジックの整合性、認可の問題、設計の判断は人間のレビュアーが担う必要がある。AIが書いたコードにAIレビューを組み合わせる運用は効率的だが、見落とした問題が蓄積するリスクを認識した上で使うべきだ。
2025年1月のRCEインシデントは別の視点も与えてくれる。レビューツールに与えたリポジトリの権限は、そのツール自体が攻撃対象になりうる。ツールを信頼することと、ツールのリスクを把握することは、分けて考える必要がある。
「AIレビューをパスした＝安全」ではない。でも「AIレビューを使わない」という選択も、手動レビューのコストを考えると現実的ではない。どこまでをツールに任せ、どこを人間が見るかの線引きを、チームで明示的に決めることが肝心だ。