GitHub “Repository Rules” 完全攻略：旧ブランチ保護を捨て、ガバナンスと開発速度を両立させる極限設定
こんにちは。大規模開発からスタートアップの基盤構築まで、数々の修羅場をくぐってきたテックリードの私だ。
日々のコードレビューやCI/CDパイプラインの運用で、こんなストレスを抱えていないか？
- 「誰かがうっかり `main` ブランチに force push して履歴を破壊した」
- 「環境ごとにブランチ保護のルールを変えたいのに、旧 `Branch Protection Rules` では柔軟なスコープ設定ができず、痒い所に手が届かない」
- 「ジュニアメンバーの未署名コミットが混ざり、監査で指摘された」
これらは、GitHubの旧「Branch Protection Rules」の限界に起因している。
GitHubが提供する「Repository Rules（リポジトリルール）」は、これらすべての課題を過去のものにする、まさに上位互換の次世代ガバナンス機能だ。
今回は、現場の生産性を一ミリも落とさず、むしろ「安心して爆速でコードを書ける環境」を手に入れるためのRepository Rulesの極限設定を叩き込む。
—
1. なぜ旧「Branch Protection Rules」を捨てるべきなのか？
従来のBranch Protection Rulesには、致命的な設計上の弱点があった。
1. ルールの継承・例外設定の不在：特定の一時ブランチ（例: ホットフィックス作業用）だけレビューを免除したい、といった細かいチューニングが困難だった。
2. 対象ブランチの指定の粗さ：ワイルドカード（`release/` など）の表現力が弱く、複雑なブランチ戦略に対応しきれない。
3. メタデータ制限の欠如：コミットメッセージのフォーマット強制や、ファイルパス単位での変更制限をネイティブで行うのが難しかった。
Repository Rulesは、これらを「ターゲット（対象）」と「ルール（制限）」の多次元マトリクスで完全に解決する。特定のバイパス権限（Bypass actors）をチームやアプリ単位で細かく制御できる点も、DevOpsエンジニアにとっては垂涎の仕様だ。
—
2. 現場の崩壊を防ぐ！絶対に有効化すべき「必須ルール」
まずは、どのプロダクションリポジトリでも最初に入れるべき鉄壁のルール構成を解説する。GitHub UI、あるいは後述するTerraform/API経由で設定を適用してほしい。
① 破壊的変更の完全阻止（Force Push & Deletion の禁止）
事故の温床となる `git push –force` とブランチの削除を厳格に禁止する。
- Restricted ref updates: 有効化
- Allow force pushes: チェックなし（禁止）
- Allow deletions: チェックなし（禁止）
② コミット署名（GPG / SSH / S/MIME）の強制
サプライチェーン攻撃や、誰が書いたか偽装されたコミットの混入を防ぐ。OSSや金融系に限らず、現代の開発チームの必須教養だ。
- Require signed commits: 有効化
- プロの知見: 開発者全員に環境構築スクリプト（dotfiles等）を配り、`git config –global commit.gpgsign true` を強制すること。最初は文句が出るが、1週間で慣れる。
③ マージ前の厳格なステータスチェック（Required status checks）
CI/CD（GitHub Actionsなど）が緑にならない限り、絶対にマージさせない。
- Require status checks to pass: 有効化
- Strict status checks: 有効化（ターゲットブランチの最新コミットに追従している状態でのテスト通過を強要し、マージ競合によるバグを防ぐ）
—
3. 生産性を加速させる「高度なメタデータ・パス制限」
ここからがRepository Rulesの真骨頂だ。開発スピードを落とさずにガバナンスを効かせるための実践テクニックを紹介する。
コミットメッセージのパターン強制（Conventional Commits）
リリースノートの自動生成（Semantic Releaseなど）を導入しているチームでは、コミットメッセージの規約違反は致命傷になる。
- Rule: `Commit message pattern`
- Operator: `regex`
- Pattern: `^(feat|fix|docs|style|refactor|perf|test|chore)(\(.+\))?: .{1,50}`
これで、規約に違反したコミットメッセージを含むPRはマージボタンが押せなくなる。無駄なSlackでの「メッセージ直してください」という指摘コストがゼロになる。
変更許可パスの制限（Path Restrictions）
モノレポや、インフラコード（Terraform）とアプリケーションコードが同居するリポジトリで猛威を振るう。
例えば、「セキュリティに関わる `.github/workflows/` 配下の変更は、特定の上級テックリードの承認がないとマージできない」といった制御が可能だ。
—
4. 【実用設定】TerraformによるRepository Rulesのコード化（GitOps）
UIポチポチによる設定は、スケーラビリティがない。リポジトリの設定すらもコードとして管理する（Settings as Code）のがプロの作法だ。
以下に、Terraform（`github` プロバイダー）を用いた実用的なRepository Rulesのベストプラクティス構成例を示す。
mainリポジトリに対する堅牢なRepository Rulesの設定
resource “github_repository_ruleset” “production_protection” {
repository = “core-api-service”
name = “Production Branch Protection”
target = “branch”
enforcement = “active” # “disabled”, “active”, “evaluate” (ドライラン用)
# 適用対象のブランチ指定 (Regex)
conditions {
ref_name {
include = [“~DEFAULT_BRANCH”, “release/”]
exclude = [“feature/”]
}
}
# 1. 破壊的変更の防止
rules {
creation = false
update = true
deletion = false
required_linear_history = true # 履歴をクリーンに保つためマージコミット禁止（Rebase/Squash強制）
# 2. コミット署名の強制
required_signatures = true
# 3. プルリクエストの要件
pull_request {
required_approving_review_count = 2
dismiss_stale_reviews_on_push = true # コードがプッシュされたらレビューをリセット
require_code_owner_reviews = true # CODEOWNERSの承認を必須化
}
# 4. ステータスチェックの強制
required_status_checks {
strict_required_status_checks_policy = true
required_check {
context = “ci / test-and-build”
}
required_check {
context = “security / snyk-scan”
}
}
}
# 例外的にバイパスできる権限（緊急時対応用のOpsチーム等）
bypass_actors {
actor_id = 1234567 # チームIDやアプリID
actor_type = “Team”
bypass_mode = “always”
}
}
この設定のポイントは `enforcement = “active”` の手前に、`evaluate`（評価モード）が存在する点だ。新しいルールを導入する際、既存の開発フローを壊さないかテストするために、まずは `evaluate` でログだけを監視し、影響範囲を計測してから `active` に昇格させるという高度な運用が可能になっている。
—
5. チームの生産性を極限まで高める「ハック」と周辺環境
ツールを導入するだけではエンジニアは動かない。開発体験（DX）を損なわずにガバナンスを通すためのハックを伝授する。
① GitHub CLI (`gh`) との連携による自動化
PR作成時にルール違反を事前に検知できるよう、ローカルのプレコミットフック（Huskyなど）とCIを連動させよ。特に `required_linear_history = true` にしている場合、ローカルでのこまめな `git pull –rebase` が必須になる。チーム全員の `.gitconfig` に以下を設定させること。
[pull]
rebase = true
[push]
autoSetupRemote = true
② 開発スピードを落とさない「バイパス戦略」
どれだけ厳格なルールを作っても、障害時（P1インシデント）のホットフィックスで「ルールが邪魔してデプロイできない」となれば本末転倒だ。
必ず 緊急対応用ロール（例: `Emergency-Responders` チーム） には `bypass_actors` を設定し、監査ログが残る状態で迂回できるルートを用意しておくこと。ガバナンスとは「縛ること」ではなく、「安全な速度を担保すること」なのだから。
—
プロフェッショナルからの総括
GitHubのRepository Rulesは、単なる「ミスを防ぐおもり」ではない。「チームが心理的安全性を持って、迷わず爆速でコードをデリバリーするためのインフラストラクチャ」だ。
旧ルールにしがみついている暇はない。今すぐリポジトリのセキュリティ設定を見直し、コードによる厳格なガバナンスと、エンジニアの爆速な開発体験を両立させてほしい。
君たちのパイプラインが、常に緑色であることを祈る。