はじめに
株式会社Linc’well フロントエンド基盤チームです。基盤チームでは現在、開発部全体での AI 活用促進にも取り組んでいます。
チームや個人単位ではAIの活用が進んでいるものの、全体での定着にはまだ至っていません。そこで今回、CodeRabbit のトライアル期間を利用し、初めて開発部全体で AI レビューを導入しました。
この記事では、導入時の設定内容に加えて、実際に運用してみて感じたことや課題についても紹介します。
現在の開発部はおよそ 40 名規模で、この人数でのトライアル事例となります
CodeRabbit について
CodeRabbit は AI コードレビューに特化したツールです。
コードレビュー専用の機能を持ち、比較的早い段階から提供されているメジャーなサービスのひとつです。
GitHub のコメント上でやり取りができ、レビューに対するフィードバックを送信すると、その内容を学習して精度を高めていく仕組みがあります。
CodeRabbit の選定理由
コードレビュー支援といえば GitHub Copilot などもありますが、今回は二週間の無料トライアルを活用でき、さらに試験運用後も削除しやすい点から CodeRabbit を選びました。
プライシングの詳細は公式ドキュメントを参照してください。
設定
導入方法
導入手順はシンプルです。
Org に参加しているアカウントで Web ページから進み、アプリケーションと連携します。
完了すると CodeRabbit の管理画面にアクセスでき、そこからレビュー機能の設定を行えます。
対象リポジトリを追加すれば準備は完了です。
CodeRabbit には 3 種類の設定方法があります。
- Org 単位の管理画面設定
- リポジトリ単位の管理画面設定
- リポジトリ単位の設定ファイル（.coderabbit.yaml）による管理
これらの設定はカスケードしません。下位の設定が有効な場合、上位の設定と「部分的に併用」されるのではなく、下位の設定がすべて反映され、上位の設定は無効になります。
そのため、Org単位で全体設定を行いつつ、個別でリポジトリ毎の設定を反映させることはできません。
③の設定ファイルには Git 管理できる利点があります。
ただし今回の試験運用では迅速さを優先するため、②のリポジトリ単位設定を利用しました
※ 最初に運用したときは ③の.coderabbit.yaml を使っていましたが、管理画面の設定が反映されず、調べた結果ファイルによって管理画面の設定が完全に上書きされていることに気づきました。
レビュー機能の全般的な設定
細かい調整は公式ドキュメントを参照してください。ここでは試験運用中に利用した主な設定を紹介します。
Review Language
主要言語を選択できます。弊社では日本語を第一言語として利用しているため Japanese を選びました。
Tone Instructions
レビューコメントのトーンを設定できます。
デフォルトはややラフすぎる印象があったため、
「あなたはテックリードです。明確かつ論理的に説明してください」
といった指示を与えました。
Request Changes Workflow
コメント解決時に CodeRabbit 自身が approved するかを設定できます。
弊社では承認人数を別途定めていたため、この機能はオフにしました。
Sequence Diagrams
PR サマリーにダイアグラムを出力する機能です。精度が十分でなく不要なケースが多かったためオフにしました。
Poem
レビュー時に「うさぎ」をテーマにしたポエムを書いてくれるユニークな機能です。
面白いと感じる人もいましたが、ノイズになるという意見もあり、試験運用ではオフにしました。
Path Filters
レビュー対象とするファイルパターンを glob で指定できます。
.env ファイルや GraphQL の生成ファイルなど、レビュー不要なファイルを除外しました。
Automatic Review
PR が作成された際に、自動で CodeRabbit をアサインしレビューを実行する設定です。
試験運用では積極的に利用してほしかったため ON にしました。
Automatic Incremental Review
追加のコミットや push があった際に、即座に CodeRabbit がインクリメンタルレビューを行う設定です。
リアルタイム性は高いですが通知が増えるため、運用次第ではオフの方が扱いやすいケースもあります。
Ignore Title Keywords
PR タイトルに特定のキーワードが含まれている場合、その PR をレビュー対象外にする設定です（大文字小文字は区別されません）。
弊社ではリリースブランチはレビュー不要のため、固定タイトルをキーに指定して除外しました。
また強制レビューを有効にしている場合でも、タイトルに ignore を付与することで回避できます。
Labels
特定のラベルが付与された PR をレビュー対象にする設定です。
! を付けると否定指定ができ、例えば ['!wip'] とすると WIP ラベルが付いている PR はレビュー対象外になります。
複数指定も可能で、柔軟にルールを作れます。
Drafts
ドラフト PR をレビュー対象にするかどうかを設定します。
Base Branches
レビュー対象とする base ブランチを指定します。
正規表現が使えるため、.* と設定すればすべてのブランチを対象にできます。
Tools 機能について
Pro プランでは lint のルールを考慮してレビューする機能があります。
弊社はバックエンドで Ruby を利用していますが、Rubocop のバージョン差により意図しない指摘が出たためオフにしました。（利用するパッケージのバージョンは指定できないようでした）
Knowledge Base
CodeRabbit にはコメントで応答したユーザーのフィードバックを学習する機能があります。
Code Guidelines
組織やリポジトリのコード規約ファイルを指定し、それをレビューの基準として利用する設定です。
instruction.md のように独自のガイドラインファイルを登録でき、複数ファイルにも対応しています。
デフォルトで .github/copilot-instructions.md や .cursorrules など、一般的なファイル名も自動で参照対象に含まれます。
Pull Requests
リポジトリを横断して Pull Request を参照できます。
弊社のトライアル時点では未確認でしたが、有用そうな機能です。
Learnings
この画像では実際の内容は伝わりませんが、学習済みの知識は一覧で確認でき、各項目ごとに「誰が」「どの PR で」「どのファイルを元に」学習させたかといったメタデータも表示されます。
知識が蓄積されることで、より精度の高いレビューが期待できます。
一方で、誤った情報や矛盾した内容を学習するリスクもありました。
そのため定期的にナレッジを棚卸しし、不要なものを編集・削除する仕組みが必要だと感じました。
コマンド操作
CodeRabbit は、PR コメントから直接コマンドを送ることでさまざまな操作が可能です。
PR の中だけで完結して制御できるのは大きな特徴のひとつです。
主なコマンドは以下の通りです。
-
@coderabbitai pause: レビューを一時停止する -
@coderabbitai resume: 一時停止したレビューを再開する -
@coderabbitai review: 増分レビューをトリガーする（自動レビューが無効な場合に便利） -
@coderabbitai full review: 最初から完全レビューを実行し、すべてのファイルを再チェックする -
@coderabbitai summary: PR のサマリーを再生成する -
@coderabbitai generate docstrings: PR 内のコードに docstrings を生成する -
@coderabbitai generate sequence diagram: PR の変更内容からシーケンス図を生成する -
@coderabbitai resolve: CodeRabbit のレビューコメントを一括で解決する -
@coderabbitai configuration: 現在の設定を表示する -
@coderabbitai help: ヘルプを表示する
また、PR 説明やタイトルに特定のキーワードを入れることで挙動を制御することも可能です。
-
@coderabbitai ignoreを説明文に入れる → この PR はレビュー対象外になる -
@coderabbitai summaryを説明文に入れる → サマリーを生成する - タイトルに
@coderabbitaiを入れる → タイトルが自動生成される
運用について
開発部では約二週間、CodeRabbit を強制的に有効化し運用しました。
以下は終了後のフィードバックです。
ポジティブな意見
- タイポやケアレスミスなど、人間では気づきにくい指摘があった
- 普段触らないリポジトリで修正漏れを拾ってくれた
- 軽微な指摘を丁寧にしてくれる
- コードを事前に読む作業が減った
- PR の変更内容を要約してくれるので把握が楽になった
- 「AI がコードを書き、CodeRabbit がレビューし、再度 AI が修正する」という流れができ、品質が向上した
ネガティブな意見
- Resolve の扱いに悩む
- AI の指摘をどこまで対応すべきか判断が難しい
- 軽微な指摘を無視しがちだが、無視してよいか不安
- 対応範囲の判断が難しい
- 一部では AI の指摘をすべて無視してしまい、逆にレビュアーの負担になった
- Cursor とほぼ同じレビュー内容に感じた
フィードバックを踏まえた改善の方向性
- レビュー対応の順序を各チームで整備する必要がある
- すべてのコメントを Resolve しないとマージできないなどルールが必要
- CodeRabbit のコメントはあくまで提案であり、どう対応するかは人間が判断する。という意識をもつ
おわりに
以上が、弊社で CodeRabbit を導入してみた二週間の経過です。
現在は無料期間が終了し、GitHub Copilot や他ツールの試験運用を進めています。ただし CodeRabbit が選択肢から外れたわけではありません、レビュー専用ツールとして細かい設定ができ、新機能にも期待できると感じています。
また今回のトライアルを通じて、開発部では「ネガティブな意見」を踏まえて、”AIレビューを運用するためのルール”を整備する必要性も見えてきました。
こうした運用ルールを取り入れることで初めて、日常のフローに無理なく組み込めると感じました。
今後も開発部に適したツールや運用を模索していきます。
弊社ではフロントエンドエンジニアを積極的に採用しています。
コードの負債解消に取り組んでおり、非常にやりがいのある時期です。
AI 活用や医療ドメインに興味のある方は、ぜひ採用ページもご覧ください。
ありがとうございました。
Discussion