--- title: "CodeRabbitの導入手順と.coderabbit.yaml設定・料金と分担の決め方" url: "https://www.issoh.co.jp/tech/details/17349/" published: 2026-09-04 updated: 2026-09-04 categories: ["開発"] publisher: "株式会社一創" --- # 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公式の設定リファレンス](https://docs.coderabbit.ai/reference/configuration)では、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テンプレート](https://docs.coderabbit.ai/reference/yaml-template)の`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への組み込み](https://www.issoh.co.jp/tech/details/15880/)の区分がそのまま当てはまり、`tools`のsemgrepやtrivyはSAST／SCAの層を担います。 ## GitHub Appのインストールから初回レビュー到達までの導入手順 導入そのものは短いので、判断すべき点だけを拾います。 ### Gitプラットフォーム連携からリポジトリ追加までの2段階の作業 [公式のクイックスタート](https://docs.coderabbit.ai/getting-started/quickstart)に示された手順は2つです。 1. GitHub・GitLab・Azure DevOps・Bitbucket Cloud・Bitbucket Data Centerのいずれかの既存アカウントでCodeRabbitアカウントを作る（クレジットカード不要） 2. レビュー対象のリポジトリを追加する（リポジトリ単位でアクセス権を制御できる） ワークフローの記述が要らないのは、CodeRabbitが自社インフラ側でレビューを実行するアプリ型だから。Actionsでジョブを組む方式とは違い、`GITHUB_TOKEN`の権限設計を自前で持ちません。Actions側で権限を絞る設計は[GITHUB\_TOKENの既定権限と最小権限の設計](https://www.issoh.co.jp/tech/details/16937/)に整理してありますが、CodeRabbitではリポジトリ追加時の許可範囲が実質の権限境界になります。機能一覧そのものを先に把握したい場合は[AI CodeRabbitとは？概要と特徴](https://www.issoh.co.jp/tech/details/5812/)が入口です。 ### 14日間トライアルとクレジットカード不要で試せる範囲の見極め [公式の料金ページ](https://www.coderabbit.ai/ja/pricing)には全プランで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で通知の量を制御する使い分け [公式のコマンド一覧](https://docs.coderabbit.ai/reference/review-commands)では、`@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のインストールと使い方](https://www.issoh.co.jp/tech/details/9028/)にコマンド運用をまとめてあります。 ## 開発者単価で増える料金の実額とOSS無料枠が使える条件の切り分け 料金は開発者数への課金なので、人が増えるとそのまま乗ります。判断材料になるのは単価より増え方です。 ### Essentials・Team・Advancedの単価差と機能境界の比較 [公式の料金ページ](https://www.coderabbit.ai/ja/pricing)に記載された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受託開発](https://www.issoh.co.jp/service/ai/development/)で要件定義から運用まで引き受けています。 ## 人のレビューに残す指摘とCodeRabbitに任せない場面の判断基準 ここは言い切ります。CodeRabbitを入れても人のレビューは減りません。減るのは指摘を書く手間だけです。 ### 差分しか見ないため設計の一貫性は人が受け持つという分担の線引き 根拠は仕様側にあります。既定のレビューは`auto_incremental_review`による増分レビューで、リポジトリ全体を読み直すのは`@coderabbitai full review`を明示したときだけ。「この変更が既存の設計方針とずれていないか」「同じ処理が別モジュールに既にないか」という判断は、既定の動作では構造的に射程外です。 人が見る側に残すのは3つ。既存構造との整合、ドメインルールの正しさ、変更の必要性そのもの。逆にCodeRabbitへ寄せるのは命名・規約違反・null安全・エラーハンドリングの漏れ・依存の追加といった、差分だけで判定できる指摘です。この分け方の前提になる観点の体系は[コードレビューの目的・観点・進め方](https://www.issoh.co.jp/tech/details/13384/)に整理してあります。 ### 専任レビュワーが常駐する案件で導入を見送る条件と代わりの手順 見送る条件をはっきり書きます。次の3つが揃っている案件では、Essentialsの年間2,880ドル（10人）を払っても短縮幅が出にくく、導入しない判断が妥当です。 - 専任のレビュワーがいて、全PRの差分を通しで読む運用が回っている - PRが小さく分割されており、レビュー待ちが半日以上滞留していない - CIでリンタと静的解析が既に走り、規約違反はマージ前に落ちている この条件下では、CodeRabbitが拾う指摘の大半はCIと人のレビューで既に潰れています。残るのは要約とシーケンス図の便益だけで、そのために開発者単位の課金を通すのは筋が悪い。代わりに公開リポジトリの無料枠で要約機能だけを見て、レビュー待ちが伸びた時点で有料枠を再検討する。他社ツールと並べて比べたい場合は[Greptileの機能・料金・導入手順](https://www.issoh.co.jp/tech/details/9024/)が同じ観点で整理してあります。 ## レビューが走らない・指摘が薄いときに確認する設定と原因の切り分け 導入後に一番多いのは「入れたのにレビューが来ない」です。原因はほぼ設定側にあります。 ### draft・タイトルキーワード・path\_filtersによる除外の確認順 上から順に見ます。 1. `auto_review.drafts`がfalseで、対象PRがドラフト扱いになっていないか 2. `ignore_title_keywords`に該当する語がPRタイトルに入っていないか（大文字小文字は区別されない） 3. `labels`で対象を絞っている場合、そのラベルが付いているか 4. `path_filters`の除外が広すぎて、見たい差分まで落ちていないか 5. `base_branches`の指定とPRのベースブランチが一致しているか 6. `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側のインフラでレビューが実行されるため、ワークフローファイルの追加もランナーの管理も発生しない。その代わり権限の境界はリポジトリ追加時の許可範囲になるので、対象リポジトリをどこまで含めるかは追加時に決めます。 ## 関連記事 - [AI CodeRabbitとは？概要と特徴を詳しく解説](https://www.issoh.co.jp/tech/details/5812/)：機能一覧とツールの位置づけを先に押さえたい場合の入口です - [CodeRabbit CLIとは何か？AIコードレビューCLIの概要と特長](https://www.issoh.co.jp/tech/details/9028/)：ターミナルからレビューを回す運用とコマンドの詳細です - [Greptileとは？AIコードレビューの機能・料金・導入手順を解説](https://www.issoh.co.jp/tech/details/9024/)：同種ツールを同じ観点で比較する際の対抗軸です - [コードレビューとは？目的・観点・進め方と実装現場の運用設計を解説](https://www.issoh.co.jp/tech/details/13384/)：人が見る側に残す観点の体系です - [SASTとは？DAST・SCAとの違いとCI/CDへの組み込み・導入判断を実装視点で解説](https://www.issoh.co.jp/tech/details/15880/)：toolsで有効化するセキュリティ検査の層の整理です --- 出典: [CodeRabbitの導入手順と.coderabbit.yaml設定・料金と分担の決め方]()（株式会社一創）