“AIは下地、人は本質” CodeRabbit導入で見えてきた、コードレビューの現在地

投稿日時：2026/04/03 12:00

合同会社DMM.com

mitohato14

はじめに

DMM.comでDMMポイントクラブのAndroidアプリ開発を担当しているmitohato14です。

本記事では、DMMポイントクラブのAndroidアプリ開発におけるAIコードレビューの取り組みを紹介します。口頭レビュータイムやPRテンプレートといったプロセス面の工夫に加えて、AIコードレビューツールであるCodeRabbitを導入したことで、コードレビューの質と速度、そしてチームの開発体験がどのように変化したのかをお伝えします。

過去に執筆した以下の記事・レビューも併せてご覧ください。
・ CodeRabbitと過ごした1ヶ月 ─ AIコードレビュー導入で実感したチーム開発の進化（DMM Developers Blog）
・ CodeRabbit、実際どう？ ─ チームで使ってわかったAIコードレビューの効果とコツ（Findy Tools）

チームとレビュー体制

チーム構成

DMMポイントクラブのAndroidセクションでは、基本的に4名の開発メンバーでコードレビューを行っています。

役割	人数	主な役割
Android TechLead（筆者）	1名	全体のプロセス改善
Androidエンジニア	3名	施策開発

近年は様々なAIエージェントの登場により、Androidのコードに変更を加えるメンバーは他にもいますが、この4人が最終的な品質を担保する役割を担っています。

レビュー体制

Pull Request（以下PR）をオープンしたタイミングで4人全員がレビュアーとしてアサインされ、誰か1人以上のApproveでマージが可能となる体制をとっています。

DMMポイントクラブでは複数の施策が同時進行し、メンバーそれぞれが異なる施策のコードを開発していることが多いため、レビュアーは開発に直接関与していない機能の概要も把握した上でコードレビューを行う必要があります。

コードレビューで抱えていた課題

限られた人数で複数の施策を並行して進める体制のもと、コードレビューに関して以下のような課題が顕在化していました。

レビュアー側の課題

命名規則の揺れやtypoなど、細かい指摘に時間を取られがち
レビューの負荷が特定メンバーに偏り、他の作業を圧迫している
細かい修正の繰り返しにより、設計や実装の全体像に目が向きにくくなる

レビュイー側の課題

PR作成からレビュー完了までのリードタイムが長い
レビューと修正の繰り返しで対応が長期化してしまう

共通の課題

レビュー品質がレビュアーのスキルや経験に左右されやすく、ばらつきがある
テストシナリオとテストコードの間にずれが発生しやすい
コミュニケーション長期化による心理的な負担がある

人力プロセスの改善からスタート

こうした課題に対し、まず取り組んだのが 1日2回の口頭レビュータイム の設置です。
朝と夕方に各30分のレビュータイムを設け、作成したPRの説明や実装相談を行います。

口頭レビュータイムの導入により、以下のような効果がありました。

PRの背景や意図をレビュアーに直接伝えることで、テキストだけでは伝わりにくいコンテキストを共有できる
非同期コミュニケーションだけでは長引きがちなやり取りを、その場で解決できる
レビュー待ちの時間を減らし、開発のリズムを整えられる
Android領域に特化した相談や共有事項をスムーズに行える

また、PRテンプレートによるセルフレビューの促進にも取り組みました。ただし、チェック項目の増加による形骸化や心理的コストの問題が発生し、項目の厳選を経て最終的にはチェック項目自体を廃止しました。チェックリストで担保しようとしていた部分は、後述するAIコードレビューや口頭レビュータイムでカバーする形に切り替えています。

これらの取り組みによって、コミュニケーションのロスはある程度減らすことができました。ただ、依然としてレビューの細かい指摘に時間を取られることや、レビューの質のばらつきといった課題は残っていました。

AIコードレビューツールの導入

そうした中、社内全体でAIコードレビューの導入事例が増え始め、本格的に導入を検討するタイミングで社内整備も整った「CodeRabbit」を導入しました。

CodeRabbitを選んだ理由

社内ではCodeRabbit以外にもPR AgentやGitHub Copilot Reviewなども導入実績がありましたが、過去にPR Agentを導入した際には「プロジェクト特有のルール定義が難しい」「AIとの対話ができずフィードバックが一方向」「期待した精度のレビューが得られない」「従量課金でPR作成数を気にしてしまう」という課題がありました。CodeRabbitではこれらが解消できそうだったことが導入の決め手です。

特に魅力を感じたのは以下の点です。

YAMLによる柔軟なルール定義：「このディレクトリ配下ではテストコードの有無を必ずチェックする」「この拡張子ではログ出力の有無を確認する」といった粒度で、チーム固有のレビュー観点を反映できる
変更内容の要約・シーケンス図：複数施策が同時進行する中でも、PR全体の変更イメージを素早くつかめ、レビューの初動が早くなる
チャット形式での対話：指摘内容を深掘りする質問や対応方針の相談ができ、より良いコードを目指せる。対応したいがこのPRでは対応しない場合にはIssue作成を依頼することも可能
AIコーディングツールとの連携：レビューコメントにAIにそのまま渡せるプロンプトが用意されており、CursorなどのAIコーディングツールに渡すだけでレビュー対応が完結する

Sequence Diagram

導入時の運用フロー

Open / Draft状態に限らず、PRを作成した段階からCodeRabbitによるレビューが実施されるように設定しています。
CodeRabbitからのレビュー指摘に対応した上でPRをオープンにし、チームメンバーへレビューを依頼する流れを取っています。

また、コーディングルールは.coderabbit.yamlに直接記述するのではなく、専用のファイルに集約して管理しています。CodeRabbitはそのファイルの内容を踏まえてレビューを行う設定にしており、Cursorなど他のAIコーディングツールからも同じファイルを参照させることで、複数のAIツールが同一のルールに基づいて動作する環境を構築しています。

ルールの集約により、変更時の反映が1カ所で済むだけでなく、コーディングルールやAIの振る舞いを確認したい時の参照先が明確になるという利点もあります。

さらに、プロジェクト全体の技術スタックやモジュール構成、参考にすべきコードの書き方などをソフトウェアコンテキストとしてまとめたファイルも参照させています。このファイルはもともとAIコーディングツールにプロダクトの全体像を伝えるために作成したものですが、CodeRabbitのレビュー観点としても活用できると考え、参照先に加えています。これにより、コードの部分的な変更だけでなくプロダクト全体の文脈を踏まえたレビューが行いやすい環境を整えています。

AI導入のメリット

実際に運用してみて感じたのは、現状のCodeRabbitによるAIレビューはあくまで「人のレビューを置き換える」ものではなく、「人のレビューをサポートする」存在だということです。

CodeRabbit導入後、特に大きく変わったのはPR作成から初回レビューまでの速度です。
以前は人力レビューを待つ必要があり、レビュー開始までに長い時間がかかることもありましたが、CodeRabbit導入後はPRを作成した数秒後にはAIからフィードバックが届くようになりました。レビュー待ちの間に別の作業へ切り替える必要がなくなり、作業の流れを途切れさせずにコードのブラッシュアップに取りかかれるようになりました。その結果、コンテキストスイッチが減り、作業者の認知的な負荷も軽くなったと感じています。

コードレビュー例.png

一方で、PR作成からマージまでの時間については、多少短くなったものの劇的な変化とは言えません。これは、人力レビューにかかる時間は減少した一方で、CodeRabbitからの指摘に対応する時間が増加したためです。当初は修正を加えるたびに新たな指摘が発生し、トータルでのレビュー対応時間がむしろ増えてしまったため、現在は修正後の再レビューを都度行わない運用に切り替えています。

それでも、人が見落としやすい部分をAIがカバーし、コードやプロダクトの品質をより高い水準に引き上げられるようになったという実感は大きいです。

チームの開発体験の変化

速度面だけでなく、チームの開発体験にも大きな変化がありました。

人力レビューの質の向上：細かい指摘をCodeRabbitが担当することで、人力レビューではより広い視点での設計や実装改善に集中できるようになった
学びのきっかけの創出：AIの指摘内容から新たな議論が発生し、メンバーの気づきや学びにつながっている
事前の問題解決：人力レビュー前に細かい問題が解決されるため、レビュアーがレビューを開始する時点でコードが一定水準までブラッシュアップされている
見落としの防止：テストシナリオとテストコードの齟齬や、定型コードのコピー後の更新漏れなど、人の目では見落としやすいミスの検出が可能に
心理的負担の軽減：迅速なフィードバックにより安心感が生まれた。CodeRabbitが生成するポエムも、柔らかい気持ちにさせてくれる一面がある

ポエム例

プロダクト品質への寄与：コード品質だけでなく、アクセシビリティ対応（ボイスオーバー用文字列やcontentDescriptionの追加提案）やUIコンポーネントサイズの最適化など、プロダクト品質の向上につながる指摘も得られている
技術スタック固有の的確な指摘：Kotlin/Android・Jetpack Compose特有の書き方に対しても的確な指摘が行われる（例：複数のpadding設定の統合提案、非同期テストでのrunTest推奨、AndroidViewのfactoryとupdateの挙動の違いに基づく指摘など）

チームメンバーからの声

細かいレベルで精度の高いレビューを素早く実行してくれる
修正点が明確で、直し方もわかりやすい
気づけていなかった問題点を指摘してくれることで、学びにつながる
バグにつながるようなミスを事前に防げる

こうした声からもわかるように、AIによるレビューは「人の代わり」ではなく、「人のレビューを前提とした下地づくり」として機能していると感じています。

AI導入後の課題

一方で、CodeRabbitを運用する中でいくつかの課題も見えてきました。

まず、指摘の粒度調整の難しさです。当初は見落としを減らすことを重視し、細かく指摘するよう設定していましたが、運用を続けるうちに細かすぎると感じる場面が増えてきました。そこで、個々のコード行よりも設計や大枠を見る方向に調整しましたが、ルール設定と期待する指摘粒度のバランスは引き続き試行錯誤が必要です。

また、レビュー結果の再現性にも課題があります。同じPRに対して再度レビューを依頼すると、前回とは異なる指摘が返ってくることがあり、1度のレビューでは指摘を網羅しきれないケースが見られます。

指摘内容の正確性についても注意が必要です。CodeRabbitの提案をそのまま受け入れるとビルドエラーになるケースがあり、suggest形式の修正提案はそのまま適用せず、内容を確認した上で反映する運用としています。また、不要な内容の提案や誤った指摘が含まれることもあるため、AIの指摘を鵜呑みにせず精査する姿勢が求められます。

加えて、プロンプト更新後の動作確認のしづらさも実運用上の課題です。.coderabbit.yamlやルールファイルを更新した際に、意図通りの指摘が行われるかどうかを事前に検証する手段が限られており、実際にPRを作成してみないと効果を確認しづらい状況です。

コスト面では、CodeRabbitは定額課金制のため従量課金のような不安はないものの、チームの状況的にPR作成が少ない時期にも一定のコストが発生する点は意識しておく必要があります。

こうした課題に対しては、.coderabbit.yamlの設定の見直しを必要に応じて実施するとともに、チーム内で運用ルールを整理しながら改善を続けています。

今後の展望

AIエージェントとの協働

CodeRabbitによるレビューの効果を実感する中で、「AIエージェントがPRを作成し、CodeRabbitがレビューし、エージェントが修正する」というAI同士の協働にも取り組み始めています。Claude Code ActionsやDevin、GitHub Copilot Agentなど様々なツールとの組み合わせを試しており、実際にDevinがCodeRabbitのレビュー指摘に対応して修正を進めている事例も確認できています。

また、AIエージェントの活用が進むにつれて、エージェントが作成したdraftのPRが滞留しやすいという新たな課題も出てきています。AI同士のレビューループを仕組み化して人の関与の度合いを最適化することが、今後の重要なテーマだと考えています。

口頭レビュータイムの進化

CodeRabbitが細かい指摘を担ってくれるようになったことで、口頭レビュータイムでは設計判断やアーキテクチャに関する深い議論に時間を割けるようになりました。今後はこの流れをさらに推し進め、CodeRabbitの指摘をきっかけにした技術的なディスカッションや知見の共有など、チーム全体のスキルアップの場としても活用していきたいと考えています。

CodeRabbitとの付き合い方

CodeRabbitの設定は頻繁にチューニングするのではなく、指摘内容に違和感を覚えたタイミングで都度調整しています。一方で、CodeRabbitが参照するコーディング規約やソフトウェアコンテキストのファイルは、他のAIツールと共有する形で少しずつ改善を続けており、規約の精度が上がることで結果的にCodeRabbitの指摘も改善されていくという循環が生まれつつあります。

また、CodeRabbitにはLearningsという機能があり、レビューコメントへの返信内容をAIが学習して次回以降のレビューに反映してくれます。この機能を活用するため、チームではなるべくレビュー指摘に対して返信するよう心がけています。「この指摘は不要」「この書き方はチームの方針として許容している」といったフィードバックを返すことで、チームに合ったレビューに少しずつ育てていくことができます。

まとめ

私たちのチームでは、口頭レビュータイムの設置、PRテンプレートの整備、そしてCodeRabbitの導入という複数のアプローチを組み合わせることで、コードレビューの質と速度の両立を目指してきました。

特にCodeRabbitの導入は大きな転換点となり、AIコードレビューの効果を実感するとともに、レビュー体制全体を見直すきっかけにもなりました。
AIが細かい指摘を担うことで、人間はより本質的な設計やロジックのレビューに集中でき、さらに口頭レビュータイムを通じて学びの機会も創出できるようになりました。

今後は口頭レビュータイムをさらに学習の場として進化させながら、AIと人の協働によるコードレビューの最適解を探っていきたいと考えています。
本記事が、AIレビュー導入やレビュー体制の見直しを検討しているチームの一助になれば幸いです。

最後に

DMMでは「 なんでもやれるDMM 」として採用活動も積極的に行っています。
多様な事業を展開し、それぞれの事業に適した技術選定・チーム構成を強みとするDMMなら、あなたにマッチするチームがきっと見つかるはずです。

本記事でのコードレビュー取り組みも一例に過ぎず、他のチームはまた異なるアプローチを取っている場合もあります。

DMMでのプロダクト開発に興味を持ちましたら、ぜひ採用ページもご覧ください。
あなたのご応募お待ちしています！