2026.09.04 10 人が閲覧（直近 30 日）開発

CodeRabbitの導入手順と.coderabbit.yaml設定・料金と分担の決め方

Q: CodeRabbitは日本語でレビューコメントを返せますか？

返せます。設定リファレンスの language キーの既定値は "en-US" なので、放置すると英語のコメントが付く状態です。 .coderabbit.yaml に language: "ja-JP" を書いてリポジトリのルートへ置けば日本語になります。 tone_instructions に指摘の書き方を日本語で指定しておくと語調と粒度も揃う。設定ファイルはレビュー対象ブランチのものが読まれるため、変更はPR内で試せます。

Q: 既存のESLintやRuffと重複した指摘は増えませんか？

設定しなければ増えます。YAMLテンプレートの reviews.tools 配下にはeslintやruffを含む50を超える解析エンジンが並び、CodeRabbit側でも同じ検査を回せる構成です。CIで同じリンタを実行しているなら、該当ツールを enabled: false で個別に切るのが現実的。切り分けの基準は「マージをブロックする検査はCI側、読み物として残す指摘はCodeRabbit側」に寄せると重複が減ります。

Q: マージをブロックする条件として組み込めますか？

組み込めますが、既定ではブロックしません。設定リファレンスの reviews.request_changes_workflow は既定false、 fail_commit_status も既定falseです。ブロックさせたい場合はこの2つを明示的に切り替えます。ただし導入初期にブロックまで有効化すると、誤検知でマージが止まる事故が起きる。まず数週間はコメントのみの運用で指摘の精度を見て、通したいルールが固まってから有効化する順序が無理がありません。

CodeRabbitの導入手順と.coderabbit.yaml設定・料金と分担の決め方

CodeRabbitはGitHub Appとしてリポジトリに接続するAIコードレビューで、公式のクイックスタートに書かれた手順はアカウント作成とリポジトリ追加の2ステップだけです。ワークフローファイルもコンテナも要りません。詰まるのはそのあとで、既定のままだと英語のコメントが全ファイルに付き、通知が荒れます。この記事では.coderabbit.yamlで指定するキーの実値、@coderabbitaiコマンドでの制御、Essentials/Team/Advancedの単価差と10人チームの年額、そして人のレビューに残す範囲を順に決めていきます。

まとめ：CodeRabbitを入れる条件と人のレビューに残す範囲

効くのは「レビュー待ちがボトルネックになっているチーム」と「レビュワーが1人に集中している受託案件」です。専任レビュワーが常駐して全差分を通しで読む体制なら、単価に見合う短縮は出にくく、導入は見送ってかまいません。

設定は3つ決めれば運用に乗ります。languageを日本語に変える。path_filtersで生成物とスナップショットを除外する。auto_review.draftsをfalseにして書きかけのPRを対象から外す。料金は開発者数に線形で乗り、年払いのEssentialsは1人あたり月24ドルなので10人で年間2,880ドル、Teamなら年間5,760ドルになります。公開リポジトリには永久無料の枠があるため、まずそこで挙動を見る順番が無駄がありません。

分担の線引きは1点だけ。既定のレビューは差分に対する増分レビューなので、設計の一貫性と既存構造との整合は人が見る側へ残ります。

CodeRabbitがPRで実行するレビューの中身と静的解析ツールの範囲

何が返るかを先に押さえます。CodeRabbit公式の設定リファレンスでは、PR全体の要約reviews.high_level_summary・変更ファイル一覧changed_files_summary・変更の流れを図にするsequence_diagramsがいずれも既定でtrue。一方request_changes_workflowとfail_commit_statusは既定falseで、指摘だけでPRがブロックされることはありません。マージ条件へ組み込むならこの2つを明示的に切り替えます。

reviews.toolsに並ぶ50超の静的解析エンジンとAI指摘の役割の違い

CodeRabbitはAIの指摘だけを返すツールではありません。公式のYAMLテンプレートのreviews.tools配下には、eslint・ruff・golangci-lint・phpstan・rubocop・clippyといった言語別リンタから、gitleaks・trufflehog・semgrep・trivy・checkov・tflintのセキュリティ／IaC系、actionlintやzizmorのようなワークフロー専用のものまで、50を超えるエンジンが並びます。

役割は分かれます。リンタ系は規約違反と既知パターンを機械的に拾い、AI側はPRの意図と差分の整合を文章で指摘する側。CIで既にeslintやRuffを回しているなら、同じ指摘が二重に出ないようtoolsで個別にfalseを指定したほうが読みやすくなります。検査手法の役割分担はSASTとDAST・SCAの違いとCI/CDへの組み込みの区分がそのまま当てはまり、toolsのsemgrepやtrivyはSAST／SCAの層を担います。

GitHub Appのインストールから初回レビュー到達までの導入手順

導入そのものは短いので、判断すべき点だけを拾います。

Gitプラットフォーム連携からリポジトリ追加までの2段階の作業

公式のクイックスタートに示された手順は2つです。

GitHub・GitLab・Azure DevOps・Bitbucket Cloud・Bitbucket Data Centerのいずれかの既存アカウントでCodeRabbitアカウントを作る（クレジットカード不要）
レビュー対象のリポジトリを追加する（リポジトリ単位でアクセス権を制御できる）

ワークフローの記述が要らないのは、CodeRabbitが自社インフラ側でレビューを実行するアプリ型だから。Actionsでジョブを組む方式とは違い、GITHUB_TOKENの権限設計を自前で持ちません。Actions側で権限を絞る設計はGITHUB_TOKENの既定権限と最小権限の設計に整理してありますが、CodeRabbitではリポジトリ追加時の許可範囲が実質の権限境界になります。機能一覧そのものを先に把握したい場合はAI CodeRabbitとは？概要と特徴が入口です。

14日間トライアルとクレジットカード不要で試せる範囲の見極め

公式の料金ページには全プランで14日間の試用期間があり、クレジットカードは不要と記載されています。加えて公開リポジトリにはOSS向けの永久無料枠があり、追加設定なしでインストールするだけと書かれている。試す順番を間違えないほうがいいです。無料枠で.coderabbit.yamlの書き方と通知量の感覚を掴み、そのファイルを持ち込んだ状態でトライアルを始める。この順なら14日を自社コードでの指摘精度の評価だけに使えます。

.coderabbit.yamlに置く設定とレビュー範囲を絞るpath_filters

設定ファイルはリポジトリのルートに置きます。レビュー対象ブランチ側のファイルが検出されてそのレビューに使われるため、設定変更の検証もPRの中で回せます。

日本語化と指摘の厳しさを決めるlanguage・profileの指定

最初に変えるのはlanguageです。既定値は"en-US"なので、放置すると指摘コメントが英語で返ります。reviews.profileの既定値は"chill"で、指摘を絞った穏やかなモード。細かい規約違反まで拾わせたいならここを変更しますが、導入直後に厳しい側へ振ると通知量が跳ねます。

tone_instructionsは既定が空文字で、指摘の書き方を言葉で指定できる欄です。「根拠となる行を示す」「修正案を1つに絞る」といった指示を入れておくと、コメントの粒度が揃います。

path_filtersとpath_instructionsでレビュー範囲を絞る書き方

path_filtersとpath_instructionsはどちらも既定が空配列。初期状態ではビルド生成物やスナップショットも対象に入ります。ここを埋めるのが通知量を落とす最短の手です。

language: "ja-JP"
tone_instructions: "指摘は根拠となる行を示し、修正案を1つに絞る"
reviews:
  profile: "chill"
  request_changes_workflow: false
  high_level_summary: true
  sequence_diagrams: true
  poem: false
  path_filters:
    - "!**/*.min.js"
    - "!dist/**"
    - "!**/__snapshots__/**"
  path_instructions:
    - path: "src/**/*.ts"
      instructions: "any の新規追加と、戻り値の型注釈の欠落を指摘する"
  auto_review:
    enabled: true
    auto_incremental_review: true
    drafts: false
    ignore_title_keywords:
      - "WIP"
      - "release"
    base_branches:
      - "develop"
  tools:
    eslint:
      enabled: false
    gitleaks:
      enabled: true
    actionlint:
      enabled: true

先頭の!が除外を表します。path_instructionsは対象パスごとに見るべき観点を文章で渡す欄で、上の例では型注釈の欠落だけをTypeScript配下へ限定しました。eslintをfalseにしたのは、CIで同じリンタを回している前提で二重指摘を避ける指定です。

auto_review配下のdraftsとラベルでレビュー対象を絞る設定

auto_review配下には、自動レビューの有効化enabled、プッシュごとの再レビューauto_incremental_review、レビュー済みコミット数での一時停止auto_pause_after_reviewed_commits、タイトルキーワードでのスキップignore_title_keywords、対象を絞るlabels、ドラフトPRを含めるかのdrafts、既定ブランチ以外を対象にするbase_branches、特定ユーザーのPRを飛ばすignore_usernamesが並びます。

実務で効くのは3つ。draftsをfalseにして書きかけのPRを外す、ignore_title_keywordsにWIPやreleaseを入れてレビュー不要なPRを弾く、ignore_usernamesにBotのアカウント名を入れて依存更新PRへの自動レビューを止める。base_branchesは既定ブランチ以外を使う運用のときだけ書けば足ります。

@coderabbitaiコマンドでレビューを止める・やり直す運用の設計

設定ファイルは全体方針を決める場所で、個別のPRでの調整はコメント欄のコマンドで行います。

review・full review・pauseで通知の量を制御する使い分け

公式のコマンド一覧では、@coderabbitai reviewが新しい変更のみの増分レビュー、@coderabbitai full reviewが全ファイルを最初から完全にレビュー、@coderabbitai pauseがそのPR上の自動レビューの一時停止、@coderabbitai resumeが再開と定義されています。ほかに全レビューコメントを解決済みにする@coderabbitai resolve、スレッドを解決してPRを承認する@coderabbitai approve、現在の設定を表示する@coderabbitai configuration、早見表を出す@coderabbitai help。

@coderabbitai pause
@coderabbitai review
@coderabbitai full review
@coderabbitai configuration
@coderabbitai resolve

大きなリファクタPRでは、まずpauseで自動レビューを止め、差分が固まってからfull reviewを1回だけ投げる。この運用にすれば、プッシュごとに増分レビューが走って通知が数十件へ膨らむ状態を避けられます。設定が意図どおり読まれているか怪しいときはconfigurationで現在値を出すのが確実です。

generate unit testsとautofixを限定して使う判断の基準

生成系も用意されています。ユニットテストを作る@coderabbitai generate unit tests、レビュー結果の修正を自動適用する@coderabbitai autofix、失敗したCI検査を調べて修正を当てる@coderabbitai fix-ci、ドキュメンテーション文字列を作る@coderabbitai generate docstrings。なお@coderabbitai ignoreと@coderabbitai summaryはコメント欄ではなくPR説明欄に書くコマンドとして区別されています。

使いどころは限定したほうがいい。autofixはフォーマットや命名のような機械的な指摘に当てる分には手数が減りますが、ロジックの修正提案をそのまま適用させるとレビューの責任所在が曖昧になります。ターミナルから同種の操作を回すならCodeRabbit CLIのインストールと使い方にコマンド運用をまとめてあります。

開発者単価で増える料金の実額とOSS無料枠が使える条件の切り分け

料金は開発者数への課金なので、人が増えるとそのまま乗ります。判断材料になるのは単価より増え方です。

Essentials・Team・Advancedの単価差と機能境界の比較

公式の料金ページに記載された2026年9月4日時点の単価が次のとおり。いずれも開発者1人あたりの月額です。

プラン	年払い	月払い	境界
Essentials	24ドル	30ドル	全PRのレビュー
Team	48ドル	60ドル	Triageと独自チェック
Advanced	72ドル	記載なし	継続的な監視
Enterprise	カスタム	記載なし	複数組織の管理
オープンソース	無料	無料	公開リポジトリ

EssentialsとTeamの差は倍です。Teamで足されるのはTriageとカスタムチェックで、レビュー自体はEssentialsでも全PRに走ります。マージ前の独自チェックをルール化する段階に来ていないなら、Essentialsで始めて足りないと分かってから上げる順序でかまいません。

10人チームでの年額試算と増員したときの費用の伸び方の見積り

単価から素直に計算します。年払いのEssentialsは1人あたり月24ドルなので、10人で月240ドル、年間2,880ドル。Teamなら月480ドルで年間5,760ドル、Advancedは月720ドルで年間8,640ドルです。月払いに切り替えるとEssentialsは1人あたり月30ドルになり、10人で年間3,600ドル、年払いとの差が720ドル生じます。

増員時の伸びも同じ計算。年払いのEssentialsで1人増えるごとに年間288ドル、Teamなら576ドルの増加です。20人規模だとTeamは年間11,520ドルになり、レビュワー1人分の工数削減に見合うかという議論になる。見るべきは単価の絶対額ではなく人数の増加見込みのほうです。AIレビューを既存フローへ組み込む設計や自社規約に合わせた検査ルールの実装まで含めて相談したい場合は、生成AI開発・AI受託開発で要件定義から運用まで引き受けています。

人のレビューに残す指摘とCodeRabbitに任せない場面の判断基準

ここは言い切ります。CodeRabbitを入れても人のレビューは減りません。減るのは指摘を書く手間だけです。

差分しか見ないため設計の一貫性は人が受け持つという分担の線引き

根拠は仕様側にあります。既定のレビューはauto_incremental_reviewによる増分レビューで、リポジトリ全体を読み直すのは@coderabbitai full reviewを明示したときだけ。「この変更が既存の設計方針とずれていないか」「同じ処理が別モジュールに既にないか」という判断は、既定の動作では構造的に射程外です。

人が見る側に残すのは3つ。既存構造との整合、ドメインルールの正しさ、変更の必要性そのもの。逆にCodeRabbitへ寄せるのは命名・規約違反・null安全・エラーハンドリングの漏れ・依存の追加といった、差分だけで判定できる指摘です。この分け方の前提になる観点の体系はコードレビューの目的・観点・進め方に整理してあります。

専任レビュワーが常駐する案件で導入を見送る条件と代わりの手順

見送る条件をはっきり書きます。次の3つが揃っている案件では、Essentialsの年間2,880ドル（10人）を払っても短縮幅が出にくく、導入しない判断が妥当です。

専任のレビュワーがいて、全PRの差分を通しで読む運用が回っている
PRが小さく分割されており、レビュー待ちが半日以上滞留していない
CIでリンタと静的解析が既に走り、規約違反はマージ前に落ちている

この条件下では、CodeRabbitが拾う指摘の大半はCIと人のレビューで既に潰れています。残るのは要約とシーケンス図の便益だけで、そのために開発者単位の課金を通すのは筋が悪い。代わりに公開リポジトリの無料枠で要約機能だけを見て、レビュー待ちが伸びた時点で有料枠を再検討する。他社ツールと並べて比べたい場合はGreptileの機能・料金・導入手順が同じ観点で整理してあります。

レビューが走らない・指摘が薄いときに確認する設定と原因の切り分け

導入後に一番多いのは「入れたのにレビューが来ない」です。原因はほぼ設定側にあります。

draft・タイトルキーワード・path_filtersによる除外の確認順

上から順に見ます。

auto_review.draftsがfalseで、対象PRがドラフト扱いになっていないか
ignore_title_keywordsに該当する語がPRタイトルに入っていないか（大文字小文字は区別されない）
labelsで対象を絞っている場合、そのラベルが付いているか
path_filtersの除外が広すぎて、見たい差分まで落ちていないか
base_branchesの指定とPRのベースブランチが一致しているか
auto_review.enabledそのものがfalseになっていないか

この順で確認すると、大半はこの6つのどれかに当たります。迷うときはPRのコメント欄で@coderabbitai configurationを実行し、実際に読まれている設定値を出すのが早い。設定ファイルはレビュー対象ブランチ側のものが使われるため、既定ブランチだけを直して反映されないという取り違えも起きます。

PR本文が薄いと指摘も薄くなる場合に足す情報と要約の指定方法

レビューは走っているのに指摘が浅いときは、渡している情報が足りていない場合があります。CodeRabbitはPRの説明とリンクされたIssueも読む設計で、設定側にもassess_linked_issuesとrelated_issuesが既定trueで用意されています。PR本文が1行だと、この経路が機能しません。

入れるべきは、変更の目的・触った範囲・意図的に変えなかった箇所の3点。path_instructionsで観点を渡していれば指摘の方向も揃います。要約の挿入位置を自分で決めたいなら、PR説明欄に@coderabbitai summaryを書いた位置に要約が入り、既定のプレースホルダも同じ文字列が設定値として登録済みです。レビューを止めたいPRでは、同じくPR説明欄へ@coderabbitai ignoreを書きます。

よくある質問

導入検討時に実際に検索されている質問を、公式ドキュメントの記載に沿って答えます。

CodeRabbitは日本語でレビューコメントを返せますか？

返せます。設定リファレンスのlanguageキーの既定値は"en-US"なので、放置すると英語のコメントが付く状態です。.coderabbit.yamlにlanguage: "ja-JP"を書いてリポジトリのルートへ置けば日本語になります。tone_instructionsに指摘の書き方を日本語で指定しておくと語調と粒度も揃う。設定ファイルはレビュー対象ブランチのものが読まれるため、変更はPR内で試せます。

無料で使い続けられるのはどんなリポジトリですか？

公式の料金ページには、公開リポジトリのレビューが永久に無料で、インストールするだけで追加の設定は不要と記載されています。プライベートリポジトリは対象外。全プラン共通の14日間トライアル（クレジットカード不要）で試したあと有料プランへ移る流れです。無料枠は挙動と通知量の確認に向いているので、設定ファイルを詰めてからトライアルを始めると期間を精度の評価に回せます。

既存のESLintやRuffと重複した指摘は増えませんか？

設定しなければ増えます。YAMLテンプレートのreviews.tools配下にはeslintやruffを含む50を超える解析エンジンが並び、CodeRabbit側でも同じ検査を回せる構成です。CIで同じリンタを実行しているなら、該当ツールをenabled: falseで個別に切るのが現実的。切り分けの基準は「マージをブロックする検査はCI側、読み物として残す指摘はCodeRabbit側」に寄せると重複が減ります。

マージをブロックする条件として組み込めますか？

組み込めますが、既定ではブロックしません。設定リファレンスのreviews.request_changes_workflowは既定false、fail_commit_statusも既定falseです。ブロックさせたい場合はこの2つを明示的に切り替えます。ただし導入初期にブロックまで有効化すると、誤検知でマージが止まる事故が起きる。まず数週間はコメントのみの運用で指摘の精度を見て、通したいルールが固まってから有効化する順序が無理がありません。

GitHub Actionsのワークフローを書く必要はありますか？

要りません。公式のクイックスタートに示された手順は、Gitプラットフォームのアカウントでサインアップし、レビュー対象のリポジトリを追加する2ステップだけです。CodeRabbit側のインフラでレビューが実行されるため、ワークフローファイルの追加もランナーの管理も発生しない。その代わり権限の境界はリポジトリ追加時の許可範囲になるので、対象リポジトリをどこまで含めるかは追加時に決めます。