この記事は 「AIコードレビューサービスCodeRabbitを使った経験をシェアしよう！ by CodeRabbit Advent Calendar 2025」 向けの投稿です。
チーム開発・個人開発どちらでも “レビューの詰まり” を減らすために、導入直後に効く設定・コマンド・運用レシピ を、公式仕様に沿ってまとめます。
CodeRabbitは「レビューの代行」ではなく「レビュー体験の整備」ツール
CodeRabbitは、GitHub / GitLab など主要なGitプラットフォームのPR（MR）と連携して 自動でコードレビュー を行い、PR要約や指摘コメントを返してくれるサービスです。
さらに、VS Code（Cursor/Windsurf等を含むVS Code互換エディタ）向けの拡張や、CLI連携（Claude Code / Codex など）も提供されていて、PR作成前（ローカル）〜 PR上（Gitプラットフォーム）まで レビューのレイヤを広げられます。
ここで大事なのは、CodeRabbitを入れるだけで「勝手に品質が上がる」わけではないことです。
成果が出るチームほど、次の2点を最初に整えています。
- レビューの交通整理（いつ走らせる？ どこを見る？ 何を見ない？）
- 会話の型（困ったときのコマンド・依頼テンプレ・停止/再開の作法）
この記事は、その“型”を最短で作るための実践手順です。
最短の導入フロー
- まずは1本PRを作る
最初のPRは、設定をいじる前に 「CodeRabbitが何をコメントしてくるか」 を観察します。
この時点で大抵わかるのが、次のどちらが課題かです。
- 指摘が多すぎる（通知が荒れる・議論が散らかる）
- 指摘が薄い/ズレる（前提や期待値が伝わっていない）
どちらでも、次のステップで整えられます。
.coderabbit.yaml は最初に置くべき
CodeRabbitは .coderabbit.yaml によって挙動を細かくカスタマイズできます。
ポイントは 「リポジトリのルートに置く」 ことと、「レビュー対象（feature branch）にある設定が自動検出され、そのレビューに使われる」 ことです。
そして便利なのが、PR上で現在の設定をYAMLとして吐き出せるコマンドです。
まずは“現状の設定”をYAML化する
PRコメントでこれを実行します。
@coderabbitai configuration
表示された内容をそのまま .coderabbit.yaml としてリポジトリ直下に置けば、UIで触っていた設定も含めて “設定をコード化” できます。
（チームでの再現性・レビュー基準の共有が一気に楽になります）
コピペで使える .coderabbit.yaml
以下は「まずこれで回し、必要に応じて足す」ための出発点です。
※コメント1行目の schema を入れておくと、YAMLの補完/検証が効いて事故が減ります。
# yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json
language: "ja-JP"
# レビューの“口調”を揃える（短く・根拠と代替案）
tone_instructions: "丁寧語で、指摘は根拠→影響→代替案の順に簡潔に。推測は推測と明記してください。"
reviews:
# 最初はchill推奨（assertiveは“細かい指摘も増えやすい”）
profile: "chill"
# PR要約を有効に（チームの合意形成が速くなる）
high_level_summary: true
# “遊び”はまず切る（必要なら後でON）
poem: false
# PR内のコメントにAIエージェント向けの修正プロンプトを含める
enable_prompt_for_ai_agents: true
# 生成物・成果物・依存ロックなど「見てもノイズになりやすい」ものを除外
path_filters:
- "!dist/**"
- "!build/**"
- "!coverage/**"
- "!**/*.lock"
- "!**/*.min.*"
# ディレクトリ単位でレビュー観点を追加（例：フロント/バックで見るべき点が違う）
path_instructions:
- path: "frontend/**"
instructions: "React/TypeScriptは、状態管理の単純化・依存配列・例外系のUI崩れを重点的に確認してください。"
- path: "backend/**"
instructions: "境界条件、入力バリデーション、ログの粒度、例外の握りつぶしがないかを重点的に確認してください。"
auto_review:
enabled: true
drafts: false
# “WIP/作業中” は自動レビューしない（通知荒れの最大原因を潰す）
labels:
- "!wip"
- "!do-not-review"
# タイトルに特定キーワードが含まれる場合もスキップ
ignore_title_keywords:
- "WIP"
- "DO NOT MERGE"
- "DRAFT"
chat:
# PR上での対話を前提にするならON（不要ならfalseでもOK）
auto_reply: true
この設定で“最初に効く”もの
- WIP/DRAFTの自動レビュー抑制：通知・コメントの洪水が止まる
- 生成物の除外：レビューが“本質（手書きの差分）”に寄る
- 日本語レビュー + 口調統一：チームの心理的負担が下がる
- ディレクトリ別の観点：ズレた指摘が減って「使える」感が上がる
覚えておきたい @coderabbitai コマンド
CodeRabbitはPR上でメンションして操作できます。
最初に覚えるべきは レビューを増やす コマンドではなく、レビューを制御する コマンドです。
レビューを“制御”する（通知荒れ対策の要）
@coderabbitai pause
作業中に何度もpushする局面は、いったん止めるのが正解です。
@coderabbitai resume
実装が落ち着いたら再開。
必要なときだけ“もう一度見て”を頼む
@coderabbitai review
追加差分だけの増分レビュー。
@coderabbitai full review
最初から全体を見直してほしいとき。
PR要約・整理
@coderabbitai summary
PR要約の再生成。
@coderabbitai resolve
CodeRabbitのコメント整理（運用ポリシーに合わせて使う）
生成系（使いどころは限定して強い）
@coderabbitai generate unit tests
@coderabbitai generate docstrings
@coderabbitai generate sequence diagram
生成系は「そのまま採用」ではなく、たたき台としてレビューする 運用にすると事故が減ります。
“レビューが強くなる”PRの書き方テンプレ（コピペ用）
CodeRabbitの指摘精度は、PR本文の情報量に引っ張られます。
チームレビューでも同じですが、AIは特に 「前提」 と 「意図」 があると強いです。
PR本文にこのテンプレを置くだけで、会話の質が上がります。
## 目的 / 背景
- なぜこの変更が必要か（Issue/仕様/障害など）
## 変更内容（要点）
- 何をどう変えたか（箇条書きでOK）
## 重点的に見てほしい点
- 例：境界条件、並行性、権限、パフォーマンス、ログ、後方互換 など
## 動作確認
- ローカル/CI/手動検証の範囲
- スクショやログがあれば貼る
さらに、PRコメントでこう依頼すると「狙い撃ち」できます。
@coderabbitai full review
重点的に見てほしい点:
1) 例外処理の方針が一貫しているか
2) 破壊的変更になっていないか（互換性）
3) テストケースが不足していないか
運用フロー図
「レビューが走らない/薄い」時のチェックリスト
1) DRAFT扱いになっていないか
.coderabbit.yaml で drafts: false の場合、Draft PRはレビュー対象外です。
2) ラベル/タイトルで除外していないか
labels: ["!wip"] や ignore_title_keywords を入れた場合、条件に引っかかるとスキップされます。
“意図したスキップ” ならOK、“気づかないスキップ” ならルールを見直します。
3) path_filters で見たい差分まで除外していないか
除外パターンが強すぎると、肝心のコードまで消えます。
最初は「dist/build/coverage だけ」など、控えめが安全です。
4) PR本文が短すぎないか
「何を守りたい変更か」が書かれていないと、指摘が一般論に寄りやすいです。
テンプレを入れるだけで改善します。
まとめ
CodeRabbitで成果を出すポイントは 設定と運用の型化 です。
.coderabbit.yaml と @coderabbitai コマンドを整えるだけで、
レビューの質とスピードは劇的に改善します。
🎄 Advent Calendar 2025 参加リンク
https://qiita.com/advent-calendar/2025/coderabbit-01