coderabbit

CodeRabbit CLI と設定

ローカル優先の AI コードレビュー：問題が PR に届く前に検出します。 CodeRabbit CLI（coderabbit、別名 cr）は、作業ツリーまたはブランチの変更をローカルでレビューするため、PR 側のレビューは反復ではなく確認になります。これにより、課金対象の PR レビューラウンド（CodeRabbit 自体のクォータと Copilot クレジットの両方）を節約できます。CLI の機能全般（ローカルレビューと、ベータ版のクラウド Coding Agent コマンドを含む）および .coderabbit.yaml の調整を扱います。PR 側の仕組み（スレッド、再リクエスト、ボットのループ）については、git-pr スキルを参照してください。

CodeRabbit CLI v0.9.1 に対して検証済み（2026-10-22）：公式ビルドのすべてのサブコマンドについて、非表示のサブコマンドも含めて --help を v0.9.0 と比較し、非表示および削除済みのレビュー用フラグをクリーンなツリーで実行しました。また、まだ v0.9.1 の記載がない CLI changelog と、agent-mode、cloud-task、review-command の各ページも確認しました。フラグには導入されたバージョンを記載しています。課金およびプッシュを行う coderabbit code コマンドは実行していません。これらの扱いはドキュメントに基づいており、v0.9.1 で追加されたものの、まだドキュメントに記載されていない項目（code archive、code goal、new --goal／--private／--access、resume --interactive）については --help のみを参照しています。coderabbit --version でこれより新しいバージョンが報告された場合は、各サブコマンドの --help をこの一覧と比較し、ここに記載されたフラグの詳細を頼りにする前に、v0.9.1 以降の変更履歴を確認してください。

使用する場面

• ローカルの変更をレビューする -- 「自分の変更をレビューして」「coderabbit を実行して」、コミット前／プッシュ前／PR 前のチェック
• レビューと修正のループを進める -- レビューを実行し、有効な指摘を修正して、再実行で確認する
• CodeRabbit を設定する -- .coderabbit.yaml を作成または調整し、レビューのノイズを減らし、重複するリンターを無効にする
• 制限を確認する -- プランごとのレート制限、レビューの予算管理
• CLI をセットアップする -- インストール、認証、アップデート、ヘッドレス／CI での使用
• クラウド Coding Agent のタスクを実行する -- coderabbit code new／resume／push を使用し、ローカルセッションをクラウドに引き継ぐ（ベータ版、v0.9.0）

重要なルール

1. レビューでは、コードが CodeRabbit のサービスにアップロードされます。 レビューを実行すると、差分とコンテキストが CodeRabbit に送信されます。機密情報や未公開コードを含むリポジトリでは、初回実行の前に、ユーザーがその送信を了承していることを確認してください。
2. レビューでは、1時間あたりの利用枠を消費します（Free：CLI レビューは1時間あたり3回）。--committed／--uncommitted や --base を使って対象範囲を慎重に指定し、レビュー枠を消費せずに最後の結果を再表示するには coderabbit review findings を使用してください。
3. 修正をプログラムから実行する場合は、--agent の出力を使用してください。 デフォルトのプレーンテキストモードは人間向けです。--plain は絶対に渡さないでください。 --help に記載されておらず、動作はバイナリによって異なります。v0.7 ではこのオプションが削除されました。エラーと使用方法のテキストが表示されるものの、終了コードは 0 だったため、パイプやテールを使った実行では問題なく完了したように見えても、レビューは行われていませんでした。v0.8 と v0.9.0 では終了コード 1 で拒否され（v0.9.0 では Remove --plain のヒントが追加されています）、v0.9.1 では再び隠れた無操作オプションとして受け付けられます。フラグを推測しないでください。インストール済みバイナリでの coderabbit review --help がサポートされるインターフェースです。記載されていない古いエイリアスも引き続き解析され、--type <all|committed|uncommitted> と --light はどちらも実際のレビューを開始し、v0.9.1 では削除された --prompt-only が --agent として処理されます。
4. 修正する前に、指摘内容を検証してください。 PR レビューと同じルールに従い、各指摘を妥当性に基づいて判断してください。ツールを黙らせるために、やみくもに修正してはいけません。
5. CodeRabbit の利用は任意です。まず Code Review Policy を確認してください。 推奨されるレビュアーと確認ポイントについて、リポジトリの AGENTS.md／CLAUDE.md を確認してください。見つからない場合は、ユーザーのグローバルエージェント指示を確認します（git-pr スキルを参照）。ポリシーまたはユーザーが利用を許可していないプロジェクトには、インストール、認証、実行を絶対に行わないでください。
6. coderabbit code は費用が発生し、コードをプッシュします。 new、ask、および resume 経由で送信されるもの（-m、--steer、--answer、または --interactive セッション）は、課金対象のエージェント作業を開始します。push と Autofix（旧 Autopilot）はリポジトリに書き込みを行い、完了済みの code goal を編集すると作業が再開されます。これらはユーザーから明示的に依頼された場合に限り実行してください。また、コミット地点がすでに報告されたものは再実行しないでください。課金対象の作業が重複します（references/cloud-tasks.md）。

セットアップ

curl -fsSL https://cli.coderabbit.ai/install.sh | sh   # also links `cr`; or: brew install coderabbit (no `cr`)
coderabbit auth login        # browser OAuth; --agent emits JSON for agent-driven login
coderabbit auth status       # verify
coderabbit doctor            # diagnose runtime/auth/git/connectivity; exits 1 when any check fails

auth login では、--api-key "<key>"（OAuth の代わりにキーを保存）、--region us|eu、--self-hosted、--no-browser（localhost コールバックにアクセスできるブラウザー用の URL を表示）も指定できます。auth org はアクティブな組織を対話形式で切り替えます。v0.9.0 以降、auth org --agent は組織を JSON 形式で一覧表示するだけなので、エージェントは切り替えられません。切り替えるには、ユーザーが coderabbit auth org を実行します。すべての auth サブコマンドで、JSON 出力用に --agent を指定できます。

有料プランは不要です：無料アカウントで coderabbit auth login を実行すると、Free プランでも CLI レビュー（1 時間あたり 3 回）を利用できます。有料プランでは、組織のコンテキスト、学習内容、より高い上限が追加されます。ヘッドレス環境／CI では、ユーザーがシートを持つ組織の Agentic API キー（ユーザー API キーは拒否されます）を、実行ごとに --api-key "$CODERABBIT_API_KEY" で渡すか、coderabbit auth login --api-key "$CODERABBIT_API_KEY" で一度保存します。CLI は API キーの環境変数を読み取りません。CODERABBIT_API_KEY は慣例的なシークレット名にすぎません。レビューではまずそのユーザーのプラン利用枠が使われ、従量課金アドオンが有効な場合にのみ使用クレジットが使われます。

更新：coderabbit update はインストールスクリプトによるインストールを更新します。Homebrew によるインストールは brew upgrade coderabbit でのみ更新できます（v0.9.0 の update --help。doctor では Update policy: Managed by Homebrew と表示されます）。Homebrew 以外では CLI も自動更新されます。CODERABBIT_CLI_DISABLE_AUTO_UPDATE=true を設定するとインストール済みのバージョンが維持され、インストールスクリプトで CODERABBIT_VERSION=X.Y.Z を指定するとバージョンが固定されます。v0.9.0 の --help に記載されているその他のスイッチは、CR_CLI_TELEMETRY_DISABLED=true と、ログを ~/.coderabbit/logs ではなく stderr に送るための CODERABBIT_LOG_LEVEL=debug と CODERABBIT_LOG_TRANSPORT=console です。v0.9.0 の coderabbit completion bash|zsh|fish|powershell は、両方のコマンド名に対応した補完スクリプトを出力します。

ローカルレビューは git worktree 内で実行する必要があります（--dir で worktree を指定できます）。--remote によるレビューと pullrequest <full URL> は、どこからでも実行できます。cr はインストールスクリプトが作成するシンボリックリンク（~/.local/bin/cr）です。Homebrew の cask がリンクするのは coderabbit だけです。コマンド、スクリプト、許可リストのパターンには、完全な名前を記述してください。

レビュー範囲とチェックポイント

チェックポイント	コマンド	レビュー対象
コミット前	coderabbit review --uncommitted	ステージ済みおよび未ステージの追跡対象の変更
プッシュ前	coderabbit review --committed	ベースブランチに含まれないローカルコミット
PR 前（ブランチ全体）	coderabbit review --base main	ベースと比較した作業ツリーおよびブランチのコミット
サブディレクトリのみ	coderabbit review --dir packages/api	指定パス以下の変更
特定のコミットとの比較	coderabbit review --committed --base-commit {sha}	指定したコミット以降の変更
未追跡ファイルを含める	coderabbit review --include-untracked	git にまだ追加されていないファイルも対象

デフォルト（CLI v0.8 以降）：すべての追跡対象の変更、ベースはリポジトリのデフォルトブランチ、プレーンテキスト出力、ローカルレビューのポリシーです。--include-untracked は --uncommitted と併用できますが、--committed とは併用できません。また、矛盾するスコープを指定すると、レビュー開始前に拒否されます。v0.7 で --plain は削除されました（v0.9.0 までは error: unknown option、v0.9.1 では再び何もせずに無視されます）。プレーンテキストがデフォルトです。--type <all|committed|uncommitted> は削除されたことはありません。--help には表示されませんが、レビューは実行され、--committed／--uncommitted と併用するとエラーになります（cannot be used with option '-t, --type <type>'）。代わりに、一覧に記載されたフラグでスコープを指定してください。 ローカルレビューではチェックポイントが保持されます（v0.7.7以降）。 各レビューでは、そのスコープ（レビュー対象ディレクトリ、ブランチ、ベース）のコンテキストが保存され、同じスコープで後から実行する際に再利用されます。--dir src での実行とリポジトリ全体での実行では別々のチェックポイントが保持され、ベースを変更するとチェックポイントがリセットされます。また、レビューに失敗した場合は最後に成功したチェックポイントが保持されます。ドキュメントではこれを増分レビューと呼んでいますが、報告対象が絞られるわけではありません。このリポジトリでの観測（2026-09-30）では、同じブランチで2回目に実行した --committed --base main が、1回目で問題なしと判定されたコミットから6件の指摘を報告しました。各実行はスコープ全体のレビューとして扱い、問題なしという結果は証明ではなく1つのサンプルと見なしてください。--fresh（v0.8.2）を指定するとチェックポイントが破棄され、保存済みのコンテキストなしでスコープがレビューされます。

レビューの深さ（v0.8）：--deep を指定すると、完全なプルリクエストレビューのポリシーに基づいてローカルで実行されます。CLI で、PR 側のレビュー内容に最も近い結果が得られます。CLI 独自の制限と課金の範囲内で実行されますが、オープン中のPRには接続せず、PRの説明や議論も読み取らないため、指摘内容はPR側のレビューと異なる場合があります。CLI だけがレビュー手段となるリポジトリ（PR側の自動レビューがない場合）で、PR作成前の最終確認に使ってください。反復と修正のサイクルではデフォルトのポリシーを使用してください。--deep "<focus>"（フォーカステキスト）は早期アクセス専用です。--light は --help から削除されていますが、デフォルトレビューの旧式エイリアスとして引き続き受け付けられます。以前のように軽量化されることはないため、スクリプトから削除してください。--deep には対応サーバーが必要です。拒否された場合は、デフォルトレビューに黙って切り替えるのではなく、CLI の更新が必要であることを報告してください。

その他のレビューオプション：

• --gate <severity>（v0.9.1） -- レビューで critical、major、minor、trivial、info のいずれか以上の重大度の指摘が見つかった場合、終了コード 2 を返します。この実行では、選択した差分も保存済みチェックポイントを使わずに新たにレビューされます。このオプションを指定しない場合、終了コードは指摘を無視します。そのため、CI やプッシュ前のゲートには次のように指定します：coderabbit review --committed --base main --agent --gate major。--help に記載されていますが、ここでは実際に試していません。
• --use-credits -- 含まれている利用枠を超えた場合、このレビューを従量制で課金することに同意します（アドオンの On demand モードでは、このオプションの指定が求められます）。料金が発生します。この実行についてユーザーから明示的な承認を得ずに、決して指定しないでください。 このオプションを指定しなければ、On demand モードで利用上限を超えても課金されません。--agent モードでは、action_required レコード（status: "awaiting_confirmation"、課金対象のファイル数、上限価格、正確な --use-credits コマンドを含む）で終了するため、その内容をユーザーに伝えてください。承認の対象はそのコンテンツに限られ、変更があれば改めて承認が必要です。
• --remote owner/repo --base main --source-branch <ref>（v0.7.7） -- ローカルにチェックアウトせず、GitHub リポジトリをサーバー側でレビューします。リポジトリはアクティブな組織にインストールされている必要があり、変更ファイル数は300未満でなければなりません。<ref> にはブランチまたは40文字の完全な SHA を指定でき、タグは指定できません。ローカル用セレクター（--dir、--committed、--uncommitted、--include-untracked、--base-commit）、--show-prompts、ローカルの --config ファイルは適用されず、review findings に保存されるものもありません。
• -c, --config <files...> -- 1回の実行で使用する追加の指示ファイル（例：CLAUDE.md）を指定します。これらのファイルはディスクから読み取られます。一方、--committed では、レビュー対象のコンテンツと検出された .coderabbit.yaml が Git のスナップショットから取得されます。そのため、変更した設定を --committed でテストする前に、設定の変更をコミットしてください。
• --api-key <key> --region us|eu -- キーを保存せずに1回の実行を認証します（ヘッドレス環境／CI 用。許可リストに関する注意事項を参照）。--region は --api-key と併せて指定した場合にのみ適用されます。

出力モード

• デフォルト（モードフラグなし） -- 修正案と最後の重大度サマリーを含む、詳細なプレーンテキストのフィードバックを非対話形式で表示します。エージェント環境が検出されると、--agent を提案する通知を表示しますが、プレーンテキストのままです。
• --agent -- 1 行につき 1 つのイベントを JSON Lines 形式で出力します（下記の「--agent 出力の読み方」を参照）。
• coderabbit review findings -- ローカルで直近に実行されたレビューのうち、指摘があったもののキャッシュ済み結果を再表示します（問題がなかったセッションは対象外）。新しい分析は行わず、クォータも消費しません（--dir <path> でスコープ指定されたレビューのキャッシュを読み込みます。スコープごとに最大 10 セッションが保持され、期限切れにはなりません）。修正の反復中に使用し、最後に確認する際だけ実際のレビューを再実行してください。--clear（v0.7.7）は、修正または却下した現在のスコープ（ディレクトリ＋ブランチ＋ベース）の保存済み指摘を非表示にし、以降の再表示で出なくなります。一部を非表示にできなかった場合は終了コード 1 となり、残りは非表示のままです。
• coderabbit review --show-prompts -- ローカルで直近に実行されたレビューの AI プロンプトを、新しいレビューを行わずに表示します。--agent とは併用できません。
• coderabbit stats -- ローカルのレビュー履歴の統計情報を表示します（--rebuild で履歴を再スキャンします）。
• coderabbit usage（1 つの JSON イベントを出力する --agent、coderabbit --usage、coderabbit review --usage はエイリアスです） -- v0.8 以降、現在のリポジトリで利用できるレビュー回数を表示します。ローリング 1 時間枠における残数と上限（includedReviews.remaining、.limit、.rollingWindowMs、および枠が再び満杯になるまでの時間を示す .fullCapacityInMs）です。また、請求期間（billingPeriod）も報告します。組織、従量課金（超過分）が有効かどうか（usageBillingStatus）、レビュー回数、現時点までの従量課金額（spendCents）、期間のリセット日が含まれます。各ブロックには state（サーバーから応答があった場合は available）が含まれます。v0.9.1 では、共有レビュー利用額上限（billingPeriod.reviewSpendingCap：scope、limitCents、isActive）とクレジット残高（reviewCredits.prepaid、.legacyCli）が追加されました。また、いずれかのブロックを読み取れない場合、イベントの status は partial になります。クレジット照会がどちらも unavailable（reason: "lookup_failed"）で、その他すべてが available のケースが確認されているため、各ブロックの state を個別に確認してください。ローカルで反復作業を始める前に確認してください。レビューを消費せずに利用できます。出力にはレーン名が含まれないため、PR 側の再試行枠を確認するには、下記の @coderabbitai rate limit の代わりにはなりません。
• coderabbit pullrequest <number|url> -- GitHub PR にある CodeRabbit の既存出力を読み取ります。レビューは実行されず、レビュー回数も消費しません。--show-threads または --show-prompts のいずれか一方のみを指定します。--show-threads --agent は、インラインスレッドのルートを JSON 形式で返します（スレッドとコメントの ID、path／line、isResolved、isOutdated、ヘッドコミット）。--show-prompts は、Outside diff comments: セクションも含む、統合された修正プロンプトを返します。このセクションは、スレッドだけを確認する手順では表示されません。github.com と、アクティブな組織にインストール済みのリポジトリが必要です。番号だけを指定した場合は、ローカルの origin からリポジトリを解決します。完全な URL を指定すれば、チェックアウト外でも動作します。スレッドの処理と解決には git-pr スキルを使用してください。
• @coderabbitai rate limit -- CLI コマンドではなく PR コメントであり、PR 側の利用枠をオンデマンドで確認できる唯一の方法です。残りの利用回数と、次のレビューが利用可能になる時刻を報告し、レビューを消費しません（エイリアス：rate-limit、limits、quota）。レート制限中でも数秒で応答し、「次のレビューは N 分後に利用可能になります」と表示します。要約コメントに編集で追記された通知は消えることがあるため、この枠の状況を確認できる唯一の確実な方法です。ループを開始する前と、トリガーを試して確認する代わりに、再度制限された後に投稿してください。レビューは消費しませんが、PR コメントの投稿、つまり書き込み操作であり、通常の承認が必要です。

--agent 出力の読み取り

行ごとに解析し、type に応じて処理します。v0.9.1 では、ストリームの前に coderabbit skills に関する Tip: 行も stderr に出力されます。そのため、stdout のみを読み取るか、シェルで2つのストリームを結合する場合は { で始まらない行をスキップしてください。

type	含まれる内容	用途
review_context	reviewType、currentBranch、baseBranch、workingDirectory、expectedDuration（v0.9.0。数値ではなく文）	待ち時間の目安にします。実際には「通常2～6分、最大15分かかる場合がある」と確認されています。コマンドを途中で停止するとレビューが破棄されるため、バックグラウンドで実行し、15分以上待ってください
status	phase、status	進行状況を追跡します。review_skipped は対象範囲に変更がないことを示します
heartbeat	生存確認のみ	アイドルタイマーをリセットします。それ以外の場合は無視してください
finding	severity（critical、major、minor、trivial、info、none）、fileName、codegenInstructions、suggestions、comment、title と startLine／endLine（v0.9.0）	コーディングエージェント向けに記述された codegenInstructions に従って修正し、なければ comment を使います。v0.9.0 より前は、codegenInstructions が空の場合にのみ comment が表示されていました
complete	status、findings、outcome（全体を実行した場合は completed）、message、reviewedFiles、該当する場合は unreviewedFileCount、reused、persistence	実行を完了とみなせるか判断します（以下のルールを参照）。reviewedFiles には実際にレビューされた対象が表示されます
error	errorType、recoverable、message、metadata	errorType に応じて分岐し、指摘件数では判断しないでください

1. 実行がクリーンとみなされるのは、終了コードが 0 で、complete イベントが status: "review_completed" を示し、outcome: "failed" がなく、unreviewedFileCount が正の値でない場合のみです。 v0.7.7 以降、失敗または未完了のレビューは、指摘を出力した後でも終了コード 1 になります。また、review_completed イベントが、失敗したファイルやスキップされたファイルのある実行を示すこともあります。未レビューのファイルがなければ、outcome: "completed_with_warnings" は問題ありません。status: "review_skipped"（findings: 0、終了コード 0）は、対象範囲に変更がなかったことを示します。--gate（v0.9.1）を指定した場合、終了コード 2 はゲート以上の指摘が見つかったレビューの完了を示すものであり、失敗ではありません。
2. 制限に達した場合は空のレビューではなく error になります。指摘がなく、終了コード 1 と {"type":"error","errorType":"rate_limit","recoverable":true,"metadata":{"waitTime":"7 minutes"}} が返されます。metadata.waitTime に1分加えた時間だけ待ってから、一度だけ再実行してください。待機時間内に再実行すると、ローカルで同じエラーと残りの待ち時間が返されます（ローカルでの待機時間は最大15分です）。そのため、ループで再試行しても意味がありません。--use-credits を指定するとローカルでの待機をスキップできますが、課金されます。
3. errorType: "interrupted"（v0.9.0、elapsedSeconds を含む）は、シグナルによって実行が停止したことを示します。すでにストリームに出力された指摘と、最後に成功したチェックポイントは保持されます。準備ができたら再実行してください。
4. complete の reused: true は、サーバーが既存のレビューを返したことを示します。新しいレビューが実行された証拠ではありません。
5. persistence.status: "failed"（v0.9.0、errorCode を含む）は、結果がローカルに保存されなかったことを示します。review findings では再表示されない場合があるため、このストリームからの指摘を保持し、ローカルストレージのアクセス許可と空き容量を確認してください。サーバー側のレビューは完了している場合があります。
6. ファイル数が多すぎる場合は error で失敗し、candidates（推定ファイル数を含む、より狭い --committed、--uncommitted、または --dir の対象範囲）と candidatesNote が含まれることがあります。CLI が候補を選んだり再試行したりすることはありません。候補を1つ選び、再実行してください。
7. セキュリティに関する指摘には、category、CWE、到達可能性、悪用可能性が追加されます。未検証の指摘は別に一覧表示され、件数も別に集計されます。また、修正用プロンプトは含まれません。確認したうえで、修正を自動適用しないでください。使用量ベースで課金されるレビューには usageCost が追加されます。

ローカルのレビューと修正のループ

1. coderabbit review --committed --base {base} --agent を実行します（コミット前なら --uncommitted）。バックグラウンドで実行してください。レビューには数分かかります（v0.9.0 の review_context.expectedDuration に範囲が記載されています）。コマンドを途中で終了すると、レビュー結果は破棄されます。
2. 指摘事項を解析し、severity でトリアージします。まず critical と major に対処してください。
3. コードベース（規約、実際の動作、プロジェクトのドキュメント）に照らして、各指摘を検証します。有効な指摘は codegenInstructions に従って修正してください。無効な指摘は、ユーザー向けに1行の根拠を添えて記録します。
4. 同じレビューコマンドを再実行して修正を検証します。レビューでは対象範囲全体が再確認されるため、未変更のコードで新たな指摘が出ても、リグレッションではなく通常のことです。クリーンな実行（Reading --agent Output、ルール1）で有効な critical／major の指摘がなくなるか、1時間あたりの利用枠を使い切るまで続けます（coderabbit usage で残りを確認できます。再試行すると待ち時間が表示されるため、待つか終了してください。決して連続で再試行しないでください）。
5. その後、プッシュ／PRを作成します。指摘を修正した時点ではなく、変更が完全に完了してから行ってください。PR側の自動レビューと auto_incremental_review が有効な場合（どちらもデフォルト）、プッシュがレビュー依頼になります。その時点でブランチに含まれる内容がレビューされるため、残りのタスク、テスト、ドキュメント、設定も同じプッシュに含めてください。そうしないと、残った項目ごとにPR側のウィンドウをもう1回使うことになります。その後、PR側のレビュー（実施される場合）は、指摘なし、またはごく少数の指摘で返ってくる状態が望ましいです。

修正は、きっかけとなった指摘ではなく、変更内容に基づいてコミットしてください。たとえば fix: validate empty page cursor とし、fix: coderabbit fixes や fix: review round 2 とはしません（git-commit スキルを参照）。コードがすでに示している内容を言い換えるだけのコードコメントを、修正で追加してはいけません。

通常は2回（レビュー、修正、検証）で完了します。3回を超える場合は、指摘をノイズとして扱っている可能性があります。有効性を再評価するか、設定を調整してください（references/configuration.md を参照）。

レート制限（開発者ごと、1時間あたり）

プラン	CLI レビュー	PR レビュー	チャット	レビューあたりのファイル数
Free	3	1（サマリーのみ）	--	150
OSS（パブリックリポジトリ）	3	1～10、リポジトリの人気度による	25	100～300、人気度による
Essentials（旧 Pro）	5	5	50	150
Team（旧 Pro+）	8	8	75	300
Advanced	10	10	100	300
Enterprise	12	12	100	300

プランの名称は2026年9月に変更されました。Essentials は Pro、Team は Pro+ で、Advanced は新設されました。実行設定ブロックには新しい名称が表示されます。旧 Pro+ の既存契約では、現在の表示が Team でも、1時間あたり10回のレビューが引き続き利用できます。また、旧 Pro／Pro+ の既存契約では、以前のスロットリング段階が適用されます。 1時間あたりの上限を超えると、従量制アドオンによりレビュー対象ファイル1件あたり $0.25 が請求されます（レート制限の通知に記載）。チャットは別枠です。CodeRabbit のレビュー スレッドへの返信ではチャット回答が得られます。これはレビューではないため、PR レビュー枠は消費しません（git-pr スキル、references/bot-review-loop.md、スレッド内で確認された修正を参照）。

表は上限値であり、実際の利用可能なレートではありません。公正利用によるスロットリングにより、PR側の実効利用枠は表の値より少なくなります。 補充レートは、開発者が過去24時間または過去7日間のいずれかのローリングウィンドウで実施したPRレビュー数に基づきます。プランの利用枠自体は変更されません。過去7日間のレビュー数に応じた、公開されている段階は次のとおりです。

プラン	通常レート	段階的に低下	1回ずつ1時間あたり1回まで低下
Essentials	0～29 -> 5/hr	30～39 -> 4、40～49 -> 3、50～59 -> 2	60+
Team	0～39 -> 8/hr	40～49 -> 6、50～59 -> 4、60～69 -> 2	70+
Advanced	0～49 -> 10/hr	50～59 -> 8、60～69 -> 4、70～79 -> 2	80+
Enterprise は、契約で適応型上限を有効にしていない限り、12/hr のままです。旧 Pro プランで、ループの途中でティアをまたいだケースを実環境で確認しました。1 ラウンド目は 4/hr、2 ラウンド後は 3/hr となり、その後は元に戻りました。Team では、7 日間に 23 回試行しても 8/hr のままでした。

影響は 2 つあります。レビューが集中する週の後は、次の週に制限がかかります。つまり、適用される期間は 1 時間ではなく数日で、1 時間ごとにリセットされるのではなく、古いレビューの期間が過ぎるにつれて処理容量が少しずつ戻ります。また、ブロック後の再試行は無料ですが、意味はありません。「ブロックされたプッシュはレビューを消費せず、次のレビューが利用可能になる時間も遅らせません」。容量はそれ以前に完了したレビューで決まりますが、拒否されたラウンドはキューに登録されないため、ウィンドウが閉じている間にトリガーを追加しても何も得られません。トリガーではなく @coderabbitai rate limit で確認してください（レビューは消費しません）。実環境での検証では、2 回ブロックされた後も、最後の完了したレビューから 54 分後に閉じるウィンドウが表示され、ブロックによる変化はありませんでした。（実行設定のフッターには「過去 7 日間のレビュー試行回数」とありますが、ドキュメントに記載された段階的な上限はレビュー数を数えています。フッターについては、名詞ではなく数値を事実として扱ってください。）

含まれる上限を超えた場合の動作は、従量制アドオンによって決まり、どの動作になるかは管理者が設定したモードによって決まります。Automatic はレビューを続け、超過分を請求します。On demand は、各レビューについてシート保有者が許可するまで一時停止します。Off は、含まれる利用枠がリセットされるまで停止します。リリース手段となるのは Automatic だけです。適正利用のための間隔調整は、これとは別の仕組みとして重ねて適用されます。

**どのプランの行が適用されるかは、誰かに教えてもらう必要があります。ただし、現在の利用枠は 2 か所で確認できます。**投稿された各レビュー内の「Run configuration」ブロックには、プランと現在の 1 時間あたりのレビュー数が表示されます（ループを計画する前に、最新のレビューで確認してください）。また、@coderabbitai rate limit を使うと、利用可能な残り枠と次回利用可能になる時刻を、枠を消費せずにその場で確認できます。これ以外では、プランについては分かりません。coderabbit usage では、リポジトリの含まれる利用枠と請求期間は分かりますが、ティアは分かりません。また、PR 側の API にも記載されていません。リポジトリの AGENTS.md/CLAUDE.md にある Code Review Policy（git-pr スキル）に CodeRabbit plan: team until 2026-10-20, then essentials と記載するか、すべてのリポジトリに対してグローバルに設定してください。プランは実際の動作を左右します。同時にドラフトではない状態にできる PR の数、予算に含めるラウンド数、CLI の作業レーンで行う反復の量が変わります。トライアルが終了したら計画を立て直してください。10 reviews/hour を前提に調整したキューは、5 では停滞します。プランが明示されていない場合は、最良のケースを想定せず、観測された動作（bot_bucket）を下限として見積もってください。

バウンスが現れる場所

バケットが枯渇していても、各レーン固有のシグナルを無視すると、すべてのレーンで正常な結果に見えます。 どのレーンでも報告はされますが、実行失敗として報告されることはなく、多くのチェックが確認するフィールドに示されることもありません。利用しているレーンの兆候を把握してください。

レーン	バウンスの見え方	兆候
CLI（--agent）	検出結果がゼロなのに終了コードは 1。終了ステータスだけを見ると失敗と同じで、「検出結果なし」は正常に見えます	{"type":"error","errorType":"rate_limit",...,"metadata":{"waitTime":"7 minutes"}} -- errorType に基づいて分岐し、検出結果の数では判断しないでください
CLI（デフォルト出力）	上限に関するメッセージが表示され、検出結果がないまま実行が終了します	メッセージを確認してください。結果が空だからといって、レビューに合格したものとして扱わないでください
PR 側	多くの場合、レビューもスレッドもコメントも何もありません。そのうえ、PR のチェック一覧では CodeRabbit のチェックが緑色になっています	そのチェックの description は Review rate limited です（完了した結果はすべて状態が SUCCESS です）。gh pr checks --json name,state,description を実行してください。レビュー済みの場合は Review completed、まだ実行中の場合は Review in progress（状態は PENDING）と表示されるため、再度トリガーせずに待ってください

最も誤解を招きやすいのは PR 側の行です。チェック一覧では、CI の合格ジョブの間に CodeRabbit のチェックマークが表示されるため、コードが一度も確認されていないのに、PR はレビュー済みで問題なしのように見えます。PR 側の処理（待機時間、再トリガー、ループ）については git-pr スキルを参照してください。

PR 側のラウンドを再試行できるタイミングを教えてくれるのは PR 自身だけです。@coderabbitai rate limit とコメントして問い合わせてください。 周辺には行き止まりが 3 つあります。誰も同じところで時間を無駄にしないよう、確認しておきましょう。

確認先	実際にわかること
coderabbit usage	リポジトリに含まれる利用枠（残量、ローリング 1 時間枠、全量回復までの時間）と請求期間です。レーンは示されず、PR 側の再試行可能時間もわかりません
チェックの背後にある CI ログ	何もありません。CodeRabbit が投稿するのは コミットステータス であり、Actions の実行ではありません（check-runs は空で、target_url は null です）。ログから診断できるハードリミットは Copilot の場合です
PR のクォータ通知	PR ごとの推定値です。次のサマリーコメントの編集で削除されることがあります。ある開発者の 2 つの PR では、48 分と 10 分という値が 104 秒違いで表示されましたが、その 8 分後には 3 つ目の PR のレビューが完了しました

答えがわかるのは、@coderabbitai rate limit へのコメント（残りの利用枠と次に利用可能になる時刻がわかり、レビュー枠は消費されません）と、すべてのオープン PR のうち最新の Review completed です。バケットは開発者ごとに割り当てられるためです（git-pr の references/bot-review-loop.md にある bot_bucket）。バウンス後に同じ開発者の別の PR がレビューされていれば、現在はバケットを利用できます。

設定

リポジトリのルートにある .coderabbit.yaml は、PR 側と CLI の両方のレビューを管理します（CLI では追加の指示ファイルとして -c <file> も指定できます。例：CLAUDE.md）。型付けされ、リンターが十分に整備されたプロジェクトでは、目標は高レベルの指摘だけに絞ることです。具体的には、profile、tone_instructions、CI と重複するリンターの無効化、生成ファイル用の path_filters を設定し、PR ごとの自動レビューは 1 回だけにします（auto_incremental_review: false）。後続のラウンドはレビューのスレッド内で完結させます。返信はレビューではなくチャットとして扱われます。編集をコミットする前に coderabbit config validate [file] で検証してください（現在の公式スキーマに照らしてチェックし、CI で使いやすい終了コードを返します）。v0.7.7 以降、coderabbit config では設定の生成と適用もできます（提案を作成するには --agent --generate --profile chill）。また、YAML が存在しない場合、CLI は .coderabbit.config.ts も検出します。

参考：スキーマの重要事項、設定の優先順位、型付けとリンターが整備されたプロジェクト向けの低ノイズなテンプレート、PR 側のコマンド（@coderabbitai review と full review の違い、一時停止と再開、設定のダンプ）については、references/configuration.md を参照してください。

クラウドコーディングエージェント（coderabbit code）

ベータ版、v0.9.0（code handoff と code skills import は v0.8.1 以降、v0.9.1 では Autopilot を Autofix に名称変更し、goal と archive を追加）。coderabbit code は、CodeRabbit のコーディングエージェントがクラウドで実行するタスクを開始して追跡します。各指示はターンとして実行されます。タスクではエージェントの利用時間が消費され、ウェブアプリのタスクと同様に課金されます。最初のタスクを開始すると、組織でコーディングエージェントのトライアルがまだ始まっていない場合、トライアルが開始されます。まず、ブラウザーからサインインし、coderabbit auth org で組織を選択する必要があります。API キー、自社ホスト、SSO ワークスペースでのログインは unsupported_auth エラーとなります。また、組織でコーディングエージェントが有効になっている必要があります。

コマンド	効果
code ls、code show <task>、code autofix status <task>	読み取り専用です。何度でも実行できます
code plan <task>	最新の確定済みプランを表示します。--approve はレビュアーの承認を記録します（自分が開始したタスクには使用できません。実装は開始されません）
code new "<prompt>"	origin 上のブランチから課金対象のタスクを開始します。プッシュされていないコミットと未コミットの変更は含まれません。--plan はコードを変更する前にプランを作成します。v0.9.1：--goal はプロンプトを目標として Goal モードで開始します（--goal-objective で目標を別途設定）。--private はタスクを組織内の他のユーザーから非表示にし、`--access manual
code goal <task>（v0.9.1）	目標を読み取ります。--set <objective>（1～4,000 文字）で目標を設定し、--clear で削除します。完了済みタスクの目標を編集すると、タスクが再開されます
code resume <task>	タスクを追跡します。--agent、-m、--steer、または --answer を付けるとタスクにメッセージを送信し、課金対象の作業を開始または延長します
code ask <task> "<question>"	課金対象の追加質問です。タスクは変更されません
code cancel <task>	実行中のターンを停止します。キュー内のメッセージは実行されません。キューの一時停止機能が展開済みの場合は一時停止されます（タスクページから再開できます）。自動化されたタスクでは破棄されます
code archive <task>（v0.9.1）	タスクを ls から非表示にし、読み取り専用にして、スケジュールを一時停止します。実行中、開始中、または停止中のターンは完了する必要があります。再度実行しても成功し、タスクのアーカイブを解除できます。キャンセルも削除もされません
code push <task>	タスクの変更を作業ブランチにコミットしてプッシュします。--stacked は代わりにプルリクエストを作成します
code autofix on <task>（または --pr <n>）	Autofix（旧称 Autopilot。v0.9.0 では code autopilot、以降はエイリアス）は、エージェントの完了時に変更を公開し、CodeRabbit の指摘、必須 CI の失敗、マージコンフリクトに対する修正を自動でプッシュします。off で停止し、resume で一時停止中のものを再開します
code handoff --summary <path>	セッションの要約、任意のプラン、検出された Codex または Claude Code のトランスクリプトを新しいタスクにアップロードします
code skills import [path]	ローカルのスキルをクラウドライブラリにアップロードします（--scope organization で組織内に共有します）

エージェントから操作する場合：

1. --agent はコマンド名の直後に渡してください（coderabbit code new --agent "<prompt>" のように、--plan より前に指定します）。エージェント環境が検出され、標準出力がパイプ接続されている場合、CLI はいずれにしても JSON を出力します（Claude Code で確認済み）が、引数エラーを JSON にするには明示的な --agent の指定が必要です。
2. 最後のレコードで判断します。その type、続いて status または action を基準に分岐してください。終了コードは照合に使います（0 は完了、1 はエラーまたはログイン／認証の操作、3 は回答が必要な質問、4 は resume の再実行、または ask の後にウェブアプリで回答を確認）。最初のレコードは必ず beta_notice ステータスです。
3. コミットポイントのレコード（task_submitted、creating_task、message_sent、steer_sent、answer_sent、question_sent）を書き込んだ後は、コマンドを再実行しないでください。再実行すると、課金対象のタスクまたは質問がもう1つ作成されます。代わりに coderabbit code resume --agent <task> でタスクを追跡し、--last は実行ごとに対象が変わる可能性があるため使わず、タスク ID を明示的に渡してください。
4. 次の操作を行う前に、ユーザーの承認を得てください：push、plan --approve、autofix on／resume、goal --set／--clear、archive、cancel、または失敗／キャンセルされたターンで残された変更のプッシュ。authorize_github の URL、ログインコマンド、機密性の高い質問はユーザーに渡してください。自分で開いたり、回答したりしてはいけません。PR 側の自動レビューが有効な場合、PR ブランチへの Autofix または push のコミットも PR レビューのリクエストになります（git-pr スキル）。

参考：レコードストリーム、コマンドごとの結果、安全な再実行、待機時間の上限については references/cloud-tasks.md を参照してください。

主な注意点

1. --committed にはコミットが必要で、--uncommitted には変更のある作業ツリーが必要です -- スコープを誤ると、何もレビューされずに終了します（review_skipped）。スコープをチェックポイントに合わせてください。
2. coderabbit review findings は再生するだけで、再レビューはしません -- 修正後もキャッシュされた指摘事項が表示されます。修正を検証できるのは、新しいレビューだけです。また、問題のないセッションはスキップします。検証実行で問題がなかった後でも、以前の指摘事項を再生しますが、これはリグレッションではありません。
3. クォータは日単位ではなく、時間単位です -- 「制限に達しました」というメッセージが出ても、その日は諦めるのではなく、ウィンドウが切り替わるまで待ってください。最終パスが枠内に収まるよう、検証実行を計画してください。--agent モードでは、終了コード 1 で rate_limit エラー行が出力されます。終了ステータスだけでは実際の失敗と区別できず、指摘件数のチェックでは問題なしと判定されてしまいます。errorType に基づいて分岐し、metadata.waitTime から待ち時間を取得してください。
4. CLI のレビューと PR のレビューは、別々の枠を使います -- ローカルで CLI のレビューを消費しても、PR 側の枠は減りません。これこそが、ローカル優先のフローの目的です。
5. 組織のコンテキストには、それに対応するアクセス権が必要です -- CodeRabbit の組織に紐付けられていないリポジトリでは、レビューは制限付きの無料モードで実行されます（学習内容／組織のコンテキストは利用されません）。そのため、同じコードでも PR 側のレビューとは結果が異なります。
6. --agent が出力するのは JSON Lines であり、JSON ドキュメントではありません -- 1 行ずつ解析してください。出力全体に対して JSON.parse を実行しないでください。
7. --plain の動作はバイナリによって異なります。--type と --light は隠しオプションにすぎません -- v0.7 から v0.9.0 では --plain は拒否され（error: unknown option。v0.8 以降は終了コード 1）、v0.9.1 では隠し no-op として再び受け付けられるため、これを含むスクリプトは、あるインストール環境では成功し、別の環境では失敗します。--type <all|committed|uncommitted> は --help に記載されていなくてもレビューを実行しますが、--committed／--uncommitted と併用すると失敗します。--light は v0.8 以降も引き続きデフォルトのレビューの別名として解析され、v0.9.1 では削除された --prompt-only が --agent として処理されます。--committed／--uncommitted を使い、デフォルトでプレーン出力になることを前提にして、実際に深度を切り替えるオプションとしては --deep を使ってください。
8. PR 側のレート制限は通知されず、チェックも成功扱いになります -- レビューもスレッドもなく、通常はコメントもありませんが、description が Review rate limited となっている CodeRabbit チェックは成功します。PR 上では何も問題がないように見えるため、未レビューの PR がレビュー済みとして報告されてしまいます。PR 側のレビューが何も返さなかったときは、何かを結論づける前に description を確認してください（「Where a Bounce Shows Up」）。
9. 表示された再試行時間は推定値であり、確定情報ではありません -- 要約コメントに追記されますが、後から編集すると消えることがあります。また、同じ時点でも PR によって表示される数値は大きく異なります。表示されたら記録し、所有する PR 全体で表示されている最短の時間を採用してください。そして、兄弟 PR の Review completed を、すべて完了したことを示す実際の合図として扱ってください（「Where a Bounce Shows Up」）。見つかった最大の時間が経過するまで待たないでください。
10. プッシュすると、PR 側のレビューがリクエストされます -- 自動レビューと auto_incremental_review が有効な場合、プッシュするたびに、ブランチ上にある内容の PR 側レビューが消費されます。枠は PR ごとではなく、開発者ごと です。変更全体をローカルで仕上げてから、一度だけプッシュしてください。反復作業には、別枠のローカル側を使います。増分レビューが無効な場合（references/configuration.md のテンプレート）、修正のプッシュでは枠を消費せず、スレッドへの返信で修正を検証できます。
11. レート制限された試行の後、コミットがレビュー済みに見えることがあります -- ウィンドウが再開した後、変更されていないコミットに対して通常の @coderabbitai review を実行すると、「すでにレビュー済みのコミットは再レビューしません」と返され、レビューが行われないままになることがあります。そのため、制限に達した後の復旧には @coderabbitai full review を使ってください。ただし、常に必要とは限りません。このリポジトリでは、制限に達した後の 次のプッシュ で、増分レビューの範囲が最後に完了したレビューから再開し、スキップされていた 2 つのコミットも指示なしでレビューされたことが確認されています。どちらかだと思い込まず、レビュー自身の「Commits」ブロックを確認し、実際にどの範囲が対象になったかを見てください。同じ強制実行形式は、動かなくなった 「Review queued」（2 時間以上停止した事例あり）にも有効です。待ち続けず、約 1 時間後に再実行してください。
12. ローカルでの問題なしの結果は 1 回分のサンプルであり、証明ではありません -- 実行結果は変わります。このリポジトリでは、変更されていない同じスコープを 2 回目に実行したところ、1 回目には問題なしとされたコードから 6 件の指摘事項が報告されました。その可能性も考慮して計画し、PR 側のレビューがある場合は、最終判断をそちらに委ねてください。--fresh（v0.8.2）は、保存されたチェックポイントのコンテキストを使わずにレビューします。
13. coderabbit code は課金対象のクラウド処理であり、レビューではありません（v0.9.0、ベータ版） -- new、ask、および resume 経由での送信はエージェントの利用時間を消費し、push と Autofix（旧 Autopilot）はリポジトリにプッシュし、handoff と skills import はローカルのデータをアップロードします。コミットポイントの記録後に再実行すると、課金対象の処理が重複します。v0.8.0 からのトップレベルの handoff は、code handoff の隠し別名としてのみ残っています。状態を変更する各実行を承認してください（references/allowlist.md）。
14. Homebrew でインストールした場合、cr コマンドも自動更新機能もありません -- cask がリンクするのは coderabbit のみで、coderabbit update は brew upgrade coderabbit に処理を委ねます（v0.9.0）。ドキュメントからコピーした cr ... の行は、そこで command not found で失敗します。フルネームを記述してください。
15. CODERABBIT_API_KEY をエクスポートしても、認証されません -- CLI は API キーの環境変数を読み取りません（v0.9.0 の --help）。そのため、これをエクスポートするだけの CI ステップでは、保存済みのログイン情報があればそれが使われ、なければ認証されません。--api-key "$CODERABBIT_API_KEY" を渡すか、同じ環境の前のステップで coderabbit auth login --api-key を使ってキーを保存してください。
16. status: "review_completed" は、レビューが完了した証拠ではありません -- 実行に失敗した場合や、ファイルがスキップされた場合でも、この値で終了することがあります。実行に問題がなかったと判断する前に、終了コード、outcome、unreviewedFileCount を確認してください（「Reading --agent Output」）。
17. Autofix には、異なる 2 つの意味があります -- CLI の code autofix（v0.9.1）は、旧称 Autopilot のループで、PR の準備が整うまで修正をプッシュし続けます。一方、PR 上の @coderabbitai autofix は、1 回限りの Fix comments 修正を指す旧式の別名であり、Autofix 自体は引き続き @coderabbitai autopilot で有効にします（references/configuration.md）。ユーザーに実行の承認を求める際は、機能名ではなく、具体的なコマンドを示してください。

リファレンス：.coderabbit.yaml の調整と PR コマンドについては、references/configuration.md を参照してください。 リファレンス：エージェントから coderabbit code のクラウドタスクを実行する方法については、references/cloud-tasks.md を参照してください。 リファレンス：自動承認のパターンについては、references/allowlist.md を参照してください。 リファレンス：PR 側のレビューループとスレッドの処理については、git-pr スキル（references/bot-review-loop.md）を参照してください。