GitHubの従来型Branch protectionは、リポジトリのSettings→Branchesに追加されたConvert to rulesetから、repository rulesetsへ移行できます。必須レビュー、Status Check、Push制限などを手作業で作り直す必要はありません。
ただし、「自動移行」という名称でも、GitHubがバックグラウンドで一括変換する機能ではなく、管理者がBranch protection ruleごとに実行する方式です。また、変換されたRulesetは作成直後からActiveになるため、対象ブランチ、Bypass権限、既存Rulesetとの重複を確認してから確定することが重要です。GitHubは2026年8月11日に、この変換機能を正式に案内しました。(The GitHub Blog)
Branch protectionからRulesetへ移行できるようになった
従来、Branch protectionからRulesetへ切り替えるには、ブランチ名のパターン、必須レビュー数、Status Check、Push可能なユーザーなどをRuleset側で再設定する必要がありました。
現在は、Branch protection rulesの一覧にあるConvert to rulesetを選択すると、既存設定を基に1つ以上のRulesetが生成されます。変換前には、作成されるRulesetと挙動の変化を画面上で確認できます。(GitHub Docs)
主に変換される設定は次のとおりです。
| Branch protectionの設定 | Rulesetで確認する主な項目 |
|---|---|
| Pull Requestを必須にする | Require a pull request before merging |
| 承認レビュー数 | Required approvals |
| CODEOWNERSのレビュー | Require review from Code Owners |
| 古い承認の取り消し | Dismiss stale pull request approvals |
| 最新Pushへの承認 | Require approval of the most recent reviewable push |
| 必須Status Check | Require status checks to pass before merging |
| ブランチを最新状態にする要件 | Require branches to be up to date before merging |
| Pushできるユーザーの制限 | Restrict updates、Bypass list |
| Force Pushの禁止 | Block force pushes |
| ブランチ削除の禁止 | Restrict deletions |
GitHubの案内では、必須レビュー、Status Check、Push制限を含む既存のBranch protection設定が、対応するRulesetのルールへ変換されます。(The GitHub Blog)
Branch protectionとRulesetの違い
RulesetはBranch protectionの単なる名称変更ではありません。特に大きな違いは、同じブランチに複数のルールを重ねられる点です。
| 比較項目 | Branch protection | Repository rulesets |
|---|---|---|
| 同じブランチへの適用 | 原則として1つのBranch protection ruleが適用される | 複数のRulesetを同時に適用できる |
| 重複時の扱い | 優先順位によって適用ルールが決まる | 各ルールを集約し、より厳しい条件が適用される |
| 閲覧権限 | 主に管理者が設定を確認 | Read権限を持つユーザーも有効なRulesetを確認可能 |
| 一時停止 | 設定変更または削除が必要 | Enforcement statusを変更できる |
| Bypass | Branch protection単位の例外設定 | ユーザー、チーム、ロール、GitHub Appsなどを細かく指定可能 |
| 組織的な標準化 | リポジトリごとの設定が中心 | プランに応じて組織やEnterpriseレベルでも管理可能 |
複数のRulesetが同じブランチを対象にすると、優先順位で一方が無視されるのではなく、設定が重ねて適用されます。同じ種類のルールが異なる条件で設定されている場合は、基本的に厳しい方が有効になります。Branch protectionとRulesetが併存している場合も同様です。(GitHub Docs)
例えば、既存のBranch protectionが「承認2件」を要求し、新しいRulesetが「承認3件」を要求している場合、必要な承認数は3件になります。
この違いを理解せずに移行すると、「変換後からPull Requestをマージできなくなった」という問題が起こりやすくなります。
Convert to rulesetを利用できる条件
変換を実行できるのは、次のいずれかの権限を持つユーザーです。
- リポジトリのAdmin権限
edit repository rules権限を含むカスタムリポジトリロール
また、変換機能はRulesetを利用できるリポジトリで使用できます。Ruleset自体は、パブリックリポジトリではGitHub Freeを含む対象プランで利用でき、プライベートリポジトリではGitHub Pro、GitHub Team、GitHub Enterprise Cloudなどが対象です。利用可否はリポジトリの所有形態と契約プランによって異なります。(GitHub Docs)
Convert to rulesetが表示されない場合は、最初に自分のリポジトリ権限と契約プランを確認してください。
Branch protectionをRulesetへ変換する手順
現在のBranch protection設定を記録する
変換前に、既存設定を確認できる状態にしておきます。
最低限、次の項目を記録してください。
- Branch name pattern
- 必須レビュー数
- CODEOWNERSレビューの有無
- 最新Pushに対する承認要件
- 必須Status Checkの名前
- Status Checkを実行するGitHub App
- Pushを許可しているユーザー、チーム、アプリ
- 管理者にも制限を適用しているか
- Force Pushとブランチ削除の扱い
設定画面のスクリーンショットを残しておくと、変換後の比較が容易になります。特にStatus Check名とPush許可対象は、見落とすとCI/CDや自動リリースが停止する可能性があります。
SettingsからBranchesを開く
対象リポジトリを開き、次の順序で移動します。
- リポジトリ上部の
Settingsを開く - 左側メニューの
Branchesを開く Branch protection rulesを確認する- 変換したいルールの
Convert to rulesetを選択する
変換はBranch protection ruleごとに実行します。複数のBranch protection ruleがある場合は、影響の小さいルールから順番に移行すると安全です。(GitHub Docs)
作成されるRulesetの名前を設定する
変換画面では、生成されるRulesetごとに名前を設定します。
GitHubは、1つのBranch protection ruleから1つ以上のRulesetを生成する場合があります。そのため、単にmain-ruleとするのではなく、対象と目的が分かる名前にしてください。(GitHub Docs)
例えば、次のような命名が考えられます。
main-branch-required-review
release-branch-protection
production-branch-governance組織内で多数のRulesetを管理する場合は、次の形式に統一すると探しやすくなります。
対象範囲-目的-管理単位具体例は次のとおりです。
main-pr-review-repository
release-ci-check-organizationNew behaviorを確認する
Rulesetを作成する前に、変換画面のNew behaviorを必ず確認します。
この欄には、Branch protectionからRulesetへ切り替えた際に挙動が変わる可能性のある項目が表示されます。名前や設定項目だけでなく、実際に誰がPushできるか、どのブランチが対象になるかという観点で確認してください。(GitHub Docs)
特に確認すべき項目は次のとおりです。
| 確認項目 | 確認内容 |
|---|---|
| Target branches | 想定したブランチだけが対象になっているか |
| Bypass list | 管理者、チーム、Bot、GitHub Appの権限が適切か |
| Required reviews | 承認数やCODEOWNERS要件が維持されているか |
| Required status checks | Check名、実行元App、最新化要件が維持されているか |
| Restrict updates | 直接Pushを許可する対象が広すぎないか |
| Force Push | 意図せず許可されていないか |
| Deletions | 対象ブランチを削除できる状態になっていないか |
元のBranch protection ruleを削除するか決める
変換画面には、移行完了時に元のBranch protection ruleを削除するDelete branch protection rule once migration is doneという選択肢があります。
この項目を選択しなければ、元のBranch protection ruleは残ります。ただし、作成されるRulesetは最初からActiveであり、元のルールと新しいRulesetの両方が適用されます。(GitHub Docs)
重要なリポジトリでは、いきなり元のルールを削除するよりも、次の流れが安全です。
- テスト用リポジトリで同等のBranch protectionを再現する
- テスト用リポジトリで変換を実行する
- Pull Request、CI、BotによるPushをテストする
- 本番リポジトリで変換する
- 動作確認後に元のBranch protectionを削除する
本番リポジトリで旧ルールを残したまま確認する場合は、Rulesetとの重複によって一時的に条件が厳しくなる可能性があります。マージ停止が許容されないリポジトリでは、メンテナンス時間帯に実施した方が安全です。
Rulesetを作成する
内容に問題がなければ、Create rulesetを選択します。
複数のRulesetが生成される場合、ボタンにはCreate 2 rulesetsのように作成数が表示されます。作成後は直ちにActiveとなり、対象ブランチへの操作に適用されます。(GitHub Docs)
変換後に必ず確認したいポイント
対象ブランチのパターン
最優先で確認すべきなのがTarget branchesです。
Rulesetでは、特定のブランチ、デフォルトブランチ、すべてのブランチ、fnmatch形式のパターンなどを対象にできます。IncludeとExcludeを組み合わせ、特定ブランチだけを除外することも可能です。(GitHub Docs)
例えば、次のパターンを設定したとします。
release/*このパターンは、次のブランチには一致します。
release/2026
release/hotfix一方、次のようにスラッシュが複数含まれるブランチには一致しません。
release/2026/hotfixGitHubのRulesetで使われるfnmatchでは、*は通常、ディレクトリ区切りに相当する/をまたいで一致しません。ネストされたブランチ名も対象にしたい場合は、次のようなパターンを検討します。(GitHub Docs)
release/**/*変換前のBranch protectionと同じ文字列が表示されていても、想定しているブランチ一覧と照合することが重要です。
Bypass権限
Rulesetでは、特定のロール、チーム、GitHub AppなどをBypass listに追加できます。また、常にBypassを許可するだけでなく、Pull Request経由に限定する設定も可能です。(GitHub Docs)
代表的な設定は次の2種類です。
| Bypass方法 | 想定する用途 |
|---|---|
| Always allow | 緊急対応用アカウント、リリースAppなど |
| For pull requests only | 直接Pushは許可せず、PR上でのみ例外操作を許可する場合 |
Bypass対象を広く設定すると、Rulesetを導入しても保護を回避できるユーザーが増えてしまいます。反対に厳しくしすぎると、Dependabot、リリースBot、デプロイ用GitHub Appなどが動作しなくなります。
次の基準で設定すると安全です。
- 個人ではなく、可能な限りチームやGitHub Appを指定する
Writeロール全体へのBypassは安易に付与しない- 直接Pushが不要なら
For pull requests onlyを選ぶ - 緊急用Bypassは通常運用の権限と分離する
- 使われていないBotや退職者の権限を移行時に整理する
必須Status Check
Status Checkでは、Check名が登録されているだけでなく、次の設定も確認します。
- 必須Checkの名前
- Check結果を送信するGitHub App
Require branches to be up to date before mergingの有無- ブランチ作成時にもCheckを求めるか
- 同名のJobが複数Workflowに存在しないか
Rulesetでは、必須Status Checkの結果を特定のGitHub Appからのみ受け付けるように設定できます。別のユーザーや連携サービスが同じCheck名を送信しても、期待するAppと一致しなければマージできません。(GitHub Docs)
例えば、GitHub ActionsのWorkflow名やJob名を変更した後も、古いCheck名がRulesetに残っていると、Pull Requestは永遠に待機状態になることがあります。
変換後は、実際にテスト用Pull Requestを作成し、次を確認してください。
- 必須Workflowが起動する
- Check名がRulesetの登録名と一致する
- 成功後にマージ可能になる
- 失敗時は正しくマージが阻止される
- DependabotなどのPull Requestでも同様に動作する
必須レビュー
必須レビューでは、単に承認数だけを見るのでは不十分です。
次の項目を確認してください。
- 必須承認数
- CODEOWNERSによる承認
- 新しいCommitが追加された際の承認取り消し
- 最新Pushを行った本人以外の承認
- レビューを却下できるユーザーやチーム
- 未解決Conversationの扱い
RulesetのRequire a pull request before mergingには、承認レビュー、CODEOWNERS、古い承認の無効化、Conversation resolutionなどの関連設定が含まれます。(GitHub Docs)
Conversation resolutionは個別に確認する
変換機能は原則としてBranch protectionの各種設定を対象にしていますが、Require conversation resolution before mergingには注意が必要です。
Branch protectionでは、この設定は独立した項目です。一方、RulesetではPull Requestルール内の設定として扱われ、Pull Requestルール自体が有効な場合にのみ適用されます。そのため、完全な1対1変換にはなりません。(GitHub Docs)
変換前にConversation resolutionだけを有効にしていた場合や、レビュー承認数を0件にして議論の解決だけを必須にしていた場合は、Ruleset側のPull Requestルールを開いて挙動を確認してください。
既存Rulesetや組織Rulesetとの重複を確認する
Repository rulesetだけを確認して移行を完了させると、組織レベルのRulesetを見落とすことがあります。
例えば、次の3つが同時にmainを対象としているケースです。
Organization Ruleset：承認2件
Repository Ruleset：承認1件
旧Branch protection：承認1件この場合、「リポジトリのRulesetは承認1件だから、1件でマージできる」とは限りません。複数のルールが集約され、より厳しい承認2件が必要になります。(GitHub Docs)
移行前後で、次の範囲を確認してください。
- Repository levelのRuleset
- Organization levelのRuleset
- Enterprise levelのRuleset
- 元のBranch protection rule
- 同じブランチパターンを対象にする別のRuleset
元のBranch protectionを削除するタイミング
変換時に元のBranch protectionを削除しなかった場合は、Settings→Branchesへ戻ります。
作成されたRulesetが元のルールを完全にカバーしているとGitHubが判定した場合、Branch protection ruleの一覧に「Rulesetによって完全にカバーされており、安全に削除できる」という趣旨のメッセージが表示され、Convert to rulesetの代わりにDeleteボタンが表示されます。(GitHub Docs)
ただし、この表示だけで判断せず、少なくとも次のテストを行ってから削除してください。
| テスト | 期待する結果 |
|---|---|
| 承認なしでマージを試す | マージが拒否される |
| 必須数のレビューを取得する | レビュー要件を満たす |
| CIを失敗させる | マージが拒否される |
| CIを成功させる | Status Check要件を満たす |
| 一般ユーザーが直接Pushする | Pushが拒否される |
| 許可したBotが更新する | 想定どおり成功する |
| Force Pushを試す | 設定どおり拒否される |
| 対象外ブランチを更新する | 不要な制限を受けない |
変換後に問題が起きた場合の確認方法
Pull Requestをマージできなくなった
最初に、次の項目を確認します。
- 元のBranch protectionが残っていないか
- 同じブランチを対象とするRulesetが複数ないか
- 組織Rulesetが追加で適用されていないか
- 承認数が意図せず増えていないか
- 必須Status Checkが古い名前になっていないか
- Checkの実行元Appが一致しているか
Rulesetは重複時にルールを集約するため、設定の競合を探すというより、「適用されているすべてのルールを洗い出す」ことが解決への近道です。
BotやGitHub AppがPushできなくなった
Bypass listに対象のGitHub Appが登録されているか確認します。
また、For pull requests onlyになっている場合、そのAppによる直接Pushは許可されません。リリースタグの作成、バージョン更新、生成ファイルのCommitなど、Botが実際に行っている操作も確認してください。
安全性を理由にすべてのAppへAlways allowを付けるのではなく、直接Pushが本当に必要なAppだけに限定します。
一部のブランチだけ保護されていない
ブランチ名に/が含まれている場合は、パターンを確認します。
feature/*この指定で保護できるのは、通常は次のような1階層のブランチです。
feature/login次のような多階層のブランチも対象にする場合は、パターンの再検討が必要です。
feature/account/loginブランチ命名規則を複雑にしているリポジトリでは、実在するブランチ名を一覧化してからIncludeとExcludeを設計してください。
何が拒否されたのか分からない
利用プランでRuleset Insightsを使用できる場合は、Settings→Rules→Insightsを確認します。
Rule Insightsでは、Rulesetの判定に成功した操作、失敗した操作、Bypassされた操作を確認できます。Ruleset、ブランチ、実行者、期間などで絞り込み、どのルールがPushやマージを阻止したのかを調査できます。(GitHub Docs)
移行後の数日間は、失敗件数とBypass利用状況を定期的に確認すると、見落としていたCIやBotを発見しやすくなります。
安全に移行するための実務的な進め方
複数のBranch protection ruleがある場合、一度にすべて変換する必要はありません。次の順番で進めると、問題が発生した際に原因を特定しやすくなります。
影響の小さいブランチから移行する
最初からmainや本番リリースブランチを移行せず、開発用ブランチや検証用リポジトリで手順を確認します。
単純なルールから変換する
最初は、次のような構成が単純なルールを選びます。
対象：develop
必須レビュー：1件
必須Check：build
直接Push：禁止複数のBot、Merge Queue、デプロイ承認などが関係するルールは後回しにします。
変換前後の設定表を作る
リポジトリ数が多い場合は、次のような管理表を用意します。
| リポジトリ | 対象ブランチ | 旧ルール | 新Ruleset | テスト | 旧ルール削除 |
|---|---|---|---|---|---|
| web-app | main | main-protection | main-governance | 完了 | 完了 |
| api | release/* | release-rule | release-governance | 確認中 | 未実施 |
| batch | develop | develop-rule | 未変換 | 未実施 | 未実施 |
変換した事実だけでなく、Pull Request、CI、Bot、直接Pushを検証したかまで記録してください。
Bypassを棚卸しする
移行は、古い例外権限を整理する機会でもあります。
特に次の権限は、そのまま移すのではなく必要性を確認します。
- 以前のリリース担当者
- 使用を終了したCIサービス
- 退職者が所有していたBot
- 一時対応のため追加したチーム
- 管理者全員への無条件Bypass
Rulesetでは例外を細かく設定できるため、「管理者だから常に回避可能」という運用から、用途ごとの最小権限へ移行しやすくなります。
Rulesetへの移行を優先したいケース
次のようなリポジトリでは、Rulesetへの移行効果が大きくなります。
main、develop、release/*へ共通ルールを適用したい- 複数の保護ルールを組み合わせたい
- 誰にBypassを許可するか細かく管理したい
- 開発者にも適用ルールを見えるようにしたい
- 組織内の複数リポジトリで保護方針を標準化したい
- Ruleset Insightsで失敗やBypassを追跡したい
一方、複数の外部CI、独自Bot、複雑なPush権限を利用している重要リポジトリでは、先にテスト環境で変換結果を検証すべきです。
まとめ
Branch protectionからRulesetへの移行は、Settings→Branches→Convert to rulesetから実行できます。必須レビュー、Status Check、Push制限などが対応するRulesetへ変換されるため、従来のように設定を一から作り直す必要はありません。
ただし、変換後のRulesetはすぐにActiveになります。次の4点は必ず確認してください。
- 対象ブランチと
fnmatchパターン - ユーザー、チーム、Bot、GitHub AppのBypass権限
- 必須Status Checkの名前と実行元
- 既存Rulesetや元のBranch protectionとの重複
まずは影響の小さいルールを1つ変換し、Pull Request、CI、Botによる更新をテストします。その結果を確認してから、元のBranch protectionを削除し、重要なmainやリリースブランチへ展開するのが安全です。
コメント