Atsushi Nakatsugawa
March 13, 2026
|1 min read
March 13, 2026
1 min read
共有
Pre-Merge Checks: Built-in & custom PR rules enforcedの意訳です。
すべての開発チームは独自のPR基準を持っているでしょう。たとえば、その基準には「Docstringsの記述」「関連するIssueの参照」「機密情報をログに記録しない」などの要件が含まれることがよくあります。
こうした基準を定義することは簡単です。しかし、PRの数が増えるにつれて、それらを一貫して実施することは容易ではありません。
管理者やチームリーダーであれば、チームメンバーがチェックリストを覚えているときだけでなく、毎回PRをマージする前にベストプラクティスに従うことを望むでしょう。開発者であれば、何か失敗があれば即座に知り、迅速に修正してマージできるようにしたいはずです。
Pre-Merge Checksは、「完了の定義」を実施可能にします。CodeRabbitは、組み込みの検証と自然言語で記述されたカスタムルールを使用して、すべてのプルリクエストを自動的に評価します。基本的な期待事項はすぐに利用でき、チーム固有のガードレールは誰も覚えていなくても、すべてのPRで実行されます。
Pre-Merge Checksは、単にガイドラインを持つのと、実際にそれを実施することの間のギャップを埋めます。
Pre-Merge Checksは、プルリクエストが開かれたり更新されたりするたびに、自動的に評価を実行します。レビュアーがすべてのポリシーを頭の中で追跡することに頼るのではなく、CodeRabbitが構造化されたチェックを実行し、何が合格し、何が失敗し、何に注意が必要かを報告します。
チェックは、警告モードまたはエラーモードで実行できます。ガードレールをマージブロッカーに変えて開発者を遅らせる前に、段階的に導入できます。
Pre-Merge Checksには、ほとんどのチームがすでに期待している一般的なPR要件に対する組み込み検証が含まれています。
Docstringsのカバレッジ閾値：新規または変更されたコードに対して、設定可能な閾値（デフォルトは80%）に対する最小ドキュメントカバレッジを適用します
PRタイトルの検証：命令形の動詞、文字数制限、または特定のフォーマット規約を要求します
PR説明の検証：ロールアウトノートや破壊的変更などの必須セクションが存在することを確認します
リンクされた課題の検証：PRが承認された課題またはチケットを参照していることを確認します
課題との整合性評価：変更がリンクされた課題の範囲を超えている場合にフラグを立てます
これらのチェックにより、反復的なレビューコメントが削除され、コントリビューター全体で基準が一貫して保たれます。追加のツールや手動でのポリシー適用は必要ありません。
すべてのチームには、一般的なLinterには表示されないルールがあります。カスタムチェックを使用すると、自然言語でこれらの要件を定義し、自動的に実施できます。
例：
ログ内の機密データ：ログステートメントにパスワード、APIキー、トークン、社会保障番号、支払いデータが含まれている可能性がある場合、PRを失敗させます。
ハードコードされた認証情報：非テストファイルで、*SECRET、KEY、または*_PASSWORDのような実際のキーや変数を検出します。
データベースマイグレーションの保護：up()とdown()の両方のメソッドを要求し、ロールバックロジックなしの破壊的変更にフラグを立てます。
破壊的変更のドキュメント化：公開API、CLI、環境変数、またはスキーマの変更がPRでドキュメント化され、CHANGELOG.mdに反映されていることを確認します。
言語移行ポリシー：新しいファイルをブロックしながら既存のファイルの編集は許可することで、レガシー言語を段階的に廃止します。
ルールを一度定義すれば、CodeRabbitはすべてのプルリクエストでそれを評価します。これは、脆弱なCIスクリプトや正規表現のハックなしで、自動化されたガバナンスを実現します。カスタムチェックの効果的な指示の書き方の詳細については、ドキュメントをご覧ください。
Pre-Merge ChecksはCodeRabbitのWebインターフェイスで設定するか、.coderabbit.yamlファイルを使用してリポジトリにコミットできます。
つまり、PRポリシーはコードと一緒に存在し、コードとともに進化します。
例：
reviews:
pre_merge_checks:
docstrings:
mode: "error"
threshold: 85
title:
mode: "warning"
requirements: "命令形の動詞で始め、50文字以内に収めること"
description:
mode: "error"
issue_assessment:
mode: "warning"
custom_checks:
- name: "文書化されていない互換性のない変更"
mode: "warning"
instructions: "公開APIに対するすべての互換性のない変更は、プルリクエストとCHANGELOG.mdに文書化されなければなりません"
まず新しいガードレールを警告状態で導入し、チームが調整できるようにします。ルールが洗練され、チームの準備が整ったら、エラー状態に移行します。ガードレールは、突然実装されるのではなく、チームのプロセスとともに自然に進化すべきです。
プルリクエスト内でチェックを直接トリガーすることもできます。
設定されたすべてのチェックを実行：
@coderabbitai run pre-merge checks
保存する前にカスタムルールをテスト：
@coderabbitai evaluate custom pre-merge check --name <check_name> --instructions <text> --mode <error|warning>
必要に応じて失敗をオーバーライド：
@coderabbitai ignore pre-merge checks
自動適用がない場合：
レビュアーは予測可能な要件を再確認するのに時間を費やします
チーム間で基準が乱れます
保護機能は記憶に依存します
高シグナルのレビュー時間が衛生管理に浪費されます
Pre-Merge Checksを使用すると：
基準がすべてのPRに一貫して適用されます
リスクのあるパターンが自動的にフラグされます
破壊的変更がマージ前にドキュメント化されます
レビュアーはアーキテクチャ、トレードオフ、エッジケースに集中できます
Pre-Merge Checksは、コードがマージされる前に「このPRは基準を満たしているだろうか？」という質問に答えます。
満たしていない場合は、明確なフィードバックが得られます。満たしている場合は、自信を持ってマージできます。これにより、非公式なガイドラインが、組み込みでカスタマイズ可能、かつ完全に実施可能な自動ガードレールに変わります。
CodeRabbitでPre-Merge Checksを有効にし、Docstirngs、破壊的変更、マイグレーションの安全性、タイトル規約など、チームがすでに気にかけている1つのルールから始めてください。
警告モードで実行し、何がフラグされるかを確認してください。準備ができたら、実施に移行します。
基準を書くことは簡単です。実施こそが行動を変えるのです。
次のプルリクエストでCodeRabbitを試して、何が検出されるか確認してください。Pre-Merge ChecksはProプランユーザーが利用でき、組織ごとに最大5つのカスタムチェックを設定できます。