レビューは「指摘」から「対話」へ。複数チームのHacobuがCodeRabbitで変えたこと

ツール導入前の課題

Hacobuでは、複数のチームでプロダクト開発を行っています。各チームがそれぞれの領域を担当しながら、プロダクト全体としての品質や開発スピードを維持していく必要があります。

特にコードレビューは、品質を担保するうえで重要な一方で、レビュー待ちによって開発が止まってしまうこともあり、チーム内のボトルネックになりやすい状況でした。細かいtypoやスタイルの指摘、既存実装との整合性確認など、人が毎回見るには負荷の高い確認も少なくありません。

以前に試したAIレビューのツールでは、誤った指摘や大量のコメントが出ることがあり、結果としてコメントが読まれずに流れてしまうケースもありました。

どのような状態を目指していたか

目指していたのは、typoやスタイルのような細かい指摘をAIに任せ、人間は設計やドメイン理解が必要な議論に集中できる状態です。AIが一次的な確認を担うことで、人間のレビュアーは要件や設計判断など、より重要な論点に時間を使えるようにしたいと考えていました。

また、レビューを単なる指摘で終わらせるのではなく、「なぜその実装にしたのか」を説明したり、必要に応じて聞き返したりできる、双方向のやり取りができる状態も重視していました。

• GitHub Copilotのレビュー
• Claude Codeのレビュー
• PR-Agent

比較する際に最も重視していたのは、レビューの精度を信頼できるかどうかです。AIレビューは、指摘の精度が低いとすぐに読まれなくなってしまいます。そのため、まずは「差分だけでなく、実装全体を見たうえで指摘している」と感じられることを重要視していました。

もう一つ重視していたのは、レビュー観点をチームごとに調整できることです。Hacobuでは、担当領域や開発スタイルがチームによって異なるため、一律のルールではなく、必要な観点を段階的に追加できることが重要でした。

決め手になったのは、デフォルトの設定でも、変更箇所だけでなく関連する既存実装まで踏まえて指摘してくれる点です。単に差分を見るだけではなく、周辺の実装や過去の書き方との関係を考慮したコメントがあり、指摘内容に納得感がありました。

また、やり取りを重ねることで、以降の指摘にチームの判断基準が反映されていく点も大きな理由でした。使い続けるほど、自分たちが大事にしている観点に沿った内容になっていく実感がありました。

改善したかった課題はどれくらい解決されたか

導入後は、細かい指摘や見落としの確認をCodeRabbitに任せることで、人間のレビュアーが設計や要件など、判断が必要な論点に集中しやすくなりました。これにより、レビューの時間をより本質的な確認に使えるようになったと感じています。

どのような成果が得られたか

最も大きな成果は、レビューの内容が変わったことです。これまでは細かい修正指示に時間を使いがちでしたが、導入後は設計や要件など、人が判断すべき論点にレビューの時間を使えるようになりました。

CodeRabbitがコードの内容をもとにMermaid記法でアーキテクチャ図を作成してくれるため、変更の全体像を把握しやすくなりました。レビューに入る前に変更の構造を把握できるため、コードの意図や影響範囲を理解しやすくなっています。

また、チームによっては、軽微な変更についてはCodeRabbitのApproveを確認できれば、人間の追加レビューを挟まずにマージする運用も行っています。

導入時に悩んだのは、どこまで設定を作り込むかという点です。

最初から細かいルールを多く設定すると、かえって運用が重くなってしまいます。そのため、まずはデフォルトの設定、もしくはレビュー対象の範囲を一部に絞る程度の軽い設定から始めました。

CodeRabbitが出した指摘と、それに対するチームの判断を見ながら、必要なルールや補足情報を少しずつ追加していきました。その結果、最初から設定を作り込みすぎずに運用できました。

まずはデフォルトの設定、もしくはレビュー対象の範囲を一部に絞る程度の軽い設定から始めるのがよいと思います。最初から細かくルールを作り込むよりも、CodeRabbitが出した指摘と、それに対するチームの判断を見ながら、必要なルールや補足情報を少しずつ追加していく方が運用しやすいです。

ただし、人間がCodeRabbitにどう返信するかによって以降の指摘内容が変わるため、何を反映させるかは意識して扱う必要があります。その場限りの判断やイレギュラーな対応まで残らないようにすることで、レビューの方向性がずれにくくなります。

現在はPull Request上のレビューを中心に活用していますが、今後は実装前の検討や、レビュー状況の可視化にも活用していきたいと考えています。たとえば、plan モードを使って実装方針を事前に整理したり、レポートやダッシュボードでレビューの傾向を把握したりすることで、個々のPull Requestだけでなく、チーム全体の開発プロセス改善にもつなげていきたいです。