デフォルト運用のCodeRabbit、1年で何が変わったか / How CodeRabbit Changed Our Code Review in 1 Year

2026年5月18日 CodeRabbit User Group Sapporo #1 での登壇スライドです。
1年間CodeRabbitを運用してきた経験について、設定ファイル不要のデフォルト運用でも価値が出ること、人によるレビューが「深く」なったことを中心に、Before/Afterのデータを交えて発表しました。

Transcript

1. デフォルト運用のCodeRabbit 1年で何が変わったか okabeeeat 2026.5.18 / CodeRabbit User Group Sapporo #1
2. 岡部 恭平 @okabeeeat ソフトウェアエンジニア Smart Craft株式会社
3. プロダクト 3
4. 開発チーム 4名・全員フルスタック CTO + エンジニア2名 + 業務委託1名 技術スタック: Ruby on Rails / GraphQL / React / React Native / TypeScript / AWS 2週間スプリントのスクラム開発 4
5. 今日のゴール 1. デフォルト運用でも十分価値が出る 2. 速度ではなく、レビューの密度・深さが変わる 3. AI指摘との付き合い方はチームで合意するのが大事 5
6. 導入前の状況と背景 6
7. 導入前のチームの状況 4人全員が機能開発・レビュー・QAを担当 QAも担当制で順番に回している 2週間スプリントで平均20件の機能・改善プルリクエストをリリース レビューする時間が確保しきれない 7
8. 起きていたこと レビュー観点に個人差・抜けが出る 同じ箇所でも、誰が見るかで指摘されたり・されなかったり N+1、nilチェック、既存パターン整合など、漏れなくチェックしたい観点ほ ど抜けやすい 抜けた指摘が後からバグや手戻りとして表面化 8
9. 導入のきっかけ コードレビューを自動化できるサービスを探していて、CodeRabbitを見つけた 無料で試せたので、そのまま導入してみた 9
10. まずはトライアルで詳細レビューを試した 有料プランのトライアルで導入 全プルリクエストに自動で詳細レビューが入る状態を体験 返信のやり取りが人間っぽくて馴染みやすい 返信内容に誤りがあれば反論もしてくれる 多くは納得して肯定してくれる 「別プルリクエストで対応したい」と伝えるとIssueも作ってくれる 10
11. トライアル終了後、無料プランで数週間運用 詳細レビューは使えなくなり、要約機能（ @coderabbitai summary ）を主に活用 プルリクエスト本文を読み込まなくても変更の全体像が掴める プルリクエストテンプレートが不要になった（要約が代わりを果たす） でも、詳細レビューがないと指摘の網羅性が落ちる 11
12. 比較してみて、有料プランに移行 トライアル中（詳細レビューあり）と終了後（要約のみ）を比較 指摘の網羅性が明らかに違うことを実感 Linterのような機械的チェックは要約のみでは得られない → 有料プランに移行して、レビューがチームのルーチンに 12
13. 運用方法 .coderabbit.yaml は不使用 / 設定はデフォルトのまま プルリクエストをドラフトで作成 → GitHub上で @coderabbitai review でレビューを呼び出す → 指摘を反映してから人によるレビューに回す 人はより深い議論に集中できる 13
14. 1年で何が変わったか 14
15. 比較期間 期間 範囲 プルリクエスト数 Before 2025-02 〜 04 76 After 2026-02 〜 04 107 開発用ブランチへのマージプルリクエストが対象（リリース反映系は除外） CodeRabbit導入は2025年5月（=登壇日でちょうど1年） 比較期間中、チーム構成は変わっていない 15
16. 数字 ① マージ済みプルリクエスト数 76件 → 107件 (+41%) CodeRabbitだけが原因ではない ただしチームとしてさばける量は増えている 16
17. 数字 ② プルリクエスト回転日数 Before After 平均 約4.1日 約4.1日 CodeRabbitは「速さ」を直接上げるツールではない 17
18. 数字 ③ CodeRabbit関与率 0% → 約99% 1プルリクエストあたりCodeRabbitコメント数: 0件 → 約1.9件 全プルリクエストが必ずレビューを受ける状態に 18
19. 数字 ④ 人によるレビューのコメント分布 カテゴリ Before After 変化 修正不要でマージ 45% 26% -42% 1〜2コメント 36% 45% +25% 3〜5コメント 16% 22% +35% 6コメント以上 4% 7% +89% 平均コメント数 1.4 2.0 +49% 修正不要で通るプルリクエストが減り、議論のあるプルリクエストが増えた 19
20. 何が起きていたか CodeRabbitが基本指摘を片付け、人がより深い議論に集中できる → CodeRabbitは「人によるレビューの土台」 20
21. 数字 ⑤ どんな指摘がくるか 直近5プルリクエストから51件の指摘: Critical 4 / Major 15 / Minor 9 実際にあった指摘の例: Rubyの "1abc".to_i は 1 を返すという落とし穴 TypeScriptの foo?.bar.baz は bar が undefined だと TypeError Reactの useEffect 依存配列に ?? [] を入れると無限ループ N+1問題 APIスキーマで required 指定漏れ 設計よりも技術的な「網羅チェック」が強い 21
22. 運用しながら学んだこと 22
23. 学び ① 「学習する」をうまく使う CodeRabbit指摘 → 人間が理由を返信 → Learnings として記憶 会話を重ねるだけで、CodeRabbitがチームに馴染んでいく 23
24. 学び ② CodeRabbitが強い領域がある Claude Codeも併用しているが、CodeRabbitに任せたい領域は明確にある 言語/フレームワーク仕様の落とし穴 例: "1abc".to_i の挙動、 ?? [] の依存配列ループ データ整合性・並行処理 例: 自動採番の同時実行衝突 テストの網羅性 例: 異常系の検証、境界値の漏れ → Claudeに任せ切れない領域があるので、両方使うのが安全 24
25. 学び ② 補足: Web検索の活用 CodeRabbitは指摘時にWeb検索を組み合わせることがある 例: 「Ruby String#to_i の挙動」を Web で調べ、公式仕様を引用して指摘 → 言語仕様の根拠を引きながらレビューしてくる動きが、観点の幅に効いている 25
26. 学び ③ AI指摘を鵜呑みにしない 個人として意識している 4つの検証ポイント: 1. 既存パターンと照合する 2. 呼び出し元を確認する 3. トランザクションの範囲を確認する 4. 実務上のリスクを評価する 26
27. 学び ④ 却下する判断も大事 CodeRabbitは一般論として正しい指摘をしてくる ただしプロジェクト固有のパターンで揃えたいことも多い 「既存パターンに合わせる」という理由で却下するケースは普通にある CodeRabbit側もこれを受け入れて、Learningsで学習する 27
28. 学び ⑤ AIだけでは防げないこと CodeRabbitは強力だが、手戻り自体は防げない 仕様の認識ずれ スコープの認識ずれ 実装方針の判断 AIレビューと人間側の運用は両輪 28
29. まとめ 29
30. 1年やってみての総括 完全に開発フローに組み込まれた（関与率99%） 人によるレビューが置き換わるのではなく、深くなった（コメント数+49%） 全プルリクエストが必ずレビューされる状態に 30
31. これから始める人へ 1. まずデフォルトで入れる(設定ファイル不要) 2. 期待値: 速度ではなく密度・深さ 3. AI指摘は判断軸をチームで合意 4. 運用しながらLearningsで自然に馴染んでいく 31
32. ご清聴ありがとうございました