GitHub repository rulesetsでPRレビュー却下権限を制限する方法と移行時の注意点

GitHub repository rulesetsで、プルリクエストのレビューを手動で却下できるユーザーを限定できるようになりました。GitHub公式Changelogの公開日は2026年7月7日で、本機能はプレビューではなく一般提供です。Require a pull request before mergingルールの中で、レビューを却下できるユーザー、チーム、GitHub Appsを指定できます。UIだけでなく、REST APIとGraphQLにも対応しています。(The GitHub Blog)

結論として、repository rulesetsにプルリクエスト保護を集約している組織は、レビュー却下権限の見直しを推奨します。特に、変更要求を誰でも解除できる状態を避けたい場合や、従来のbranch protection ruleからrulesetsへ移行中の場合は対応優先度が高くなります。

一方、既存のrulesetに対して制限が自動適用されるわけではありません。設定を有効にしなければ従来の運用が続くため、直ちにプルリクエストが停止する種類の変更ではありません。ただし、APIやIaCでrulesetを管理している場合は、新しいプロパティへの対応状況を確認しておく必要があります。

GitHub repository rulesetsのレビュー却下制限で何が変わるのか

今回追加されたのは、プルリクエストのレビューを却下できる主体をruleset内で指定する機能です。

設定場所は独立したルールではなく、ブランチrulesetのRequire a pull request before mergingに含まれるレビュー設定です。対象ブランチに対して機能を有効にし、許可するユーザー、チーム、GitHub Appsを選択します。(The GitHub Blog)

主な変更点は次のとおりです。

項目	更新後の内容
制御対象	プルリクエストレビューの手動却下
許可できる主体	ユーザー、チーム、GitHub Apps
設定場所	ブランチrulesetの`Require a pull request before merging`
設定方法	GitHub UI、REST API、GraphQL
提供状態	一般提供
提供先	github.com上のrepository rulesets

これまでも従来型のbranch protection ruleでは、レビューを却下できるユーザーを制限できました。今回の更新によって、同様のガバナンスをrepository rulesetsだけで構成しやすくなったことが大きなポイントです。(GitHub)

実務上の効果

レビューの却下は、レビュー担当者が不在になった場合や、古い変更要求を解除する場合に必要です。しかし、write権限を持つ多数のメンバーが自由に却下できる状態では、承認プロセスを形骸化させる可能性があります。

今回の機能を利用すると、例えば次のような運用に変更できます。

セキュリティレビューの却下はSecurity Teamだけに許可する
外部委託先のレビューを解除できるのは社内リポジトリ管理者だけにする
通常の開発者には却下を許可せず、Engineering Managerチームに限定する
承認済みの自動レビューを解除する処理を、指定したGitHub Appだけに許可する

重要なのは、単に「管理者だけ」に限定するのではなく、レビューを解除する業務上の責任者を明示できることです。

「レビューの却下」と「古い承認の自動解除」は別の機能

今回の変更を理解する際は、「レビューの却下」と「古い承認の自動解除」を混同しないようにする必要があります。

GitHubでレビューを却下すると、レビューそのものが完全に削除されるわけではありません。レビューの状態がレビューコメントへ変更され、却下した理由がプルリクエストの会話に記録されます。レビューを却下する際は理由の入力も必要です。(GitHub Docs)

操作	実行されるタイミング	今回の制限対象
レビューの手動却下	ユーザーやアプリが`Dismiss review`を実行したとき	対象
古い承認の自動解除	新しいコミットにより差分が変化したとき	対象外
再レビュー	レビュー担当者が再度ApproveまたはRequest changesを行うとき	対象外
レビューコメントの解決	ConversationをResolveするとき	対象外

Dismiss stale pull request approvals when new commits are pushedを有効にしている場合、差分を変更するコミットが追加されると、既存の承認は自動的に古いものとして解除されます。この自動処理は、今回追加された手動却下の許可リストとは別に設定されます。(GitHub Docs)

つまり、「特定のユーザーだけが手動で承認を解除できるようにしたいが、新しいコミットが追加されたときは自動的に再承認を求めたい」という組み合わせも可能です。

従来のbranch protection ruleとの仕様差分

従来のbranch protection ruleにも、レビュー却下権限を限定する設定があります。今回の機能は、まったく新しい権限概念を追加したというより、rulesetsで不足していた制御を補完するものと考えると分かりやすいでしょう。

ただし、設定形式やAPIのデータ構造には違いがあります。

比較項目	Branch protection rule	Repository rulesets
設定場所	Branch protectionのrequired pull request reviews	rulesetの`pull_request`ルール
UI上の設定	`Restrict who can dismiss pull request reviews`	同等の設定をruleset内で指定
REST APIのプロパティ	`dismissal_restrictions`	`dismissal_restriction`
ユーザー指定	login名の配列	IDとactor type
チーム指定	team slugの配列	IDと`Team`
GitHub App指定	app slugの配列	IDと`IntegrationInstallation`
複数ルールの扱い	基本的に1つのbranch protection ruleが適用	複数rulesetを重ねて適用可能

Branch protection APIでは、dismissal_restrictionsの中にusers、teams、appsを指定します。一方、ruleset APIでは、単数形のdismissal_restriction内にenabledとallowed_actorsを設定します。rulesetのactorはIDとtypeの組み合わせです。(GitHub Docs)

この違いがあるため、branch protection ruleのJSONをそのままrulesetへコピーすることはできません。

APIプロパティ名の違いに注意

特に間違えやすいのが、次の単数形と複数形の違いです。

Branch protection:
dismissal_restrictions

Repository rulesets:
dismissal_restriction

内部構造も異なります。

"dismissal_restriction": {
  "enabled": true,
  "allowed_actors": [
    {
      "id": 123456,
      "type": "Team"
    }
  ]
}

これはpull_requestルールのparametersに追加する断片です。完全なruleset更新リクエストではありません。

REST APIドキュメントでは、allowed_actors[].typeとして次の値が示されています。

User
Team
IntegrationInstallation
RepositoryRole

UIとChangelogでは主にユーザー、チーム、GitHub Appsとして説明されていますが、API実装ではactor typeを正確に指定する必要があります。(GitHub Docs)

Branch protection ruleとrulesetsを併用している場合の互換性

Repository rulesetsは、既存のbranch protection ruleと併用できます。rulesetを追加しても、branch protection ruleが自動的に置き換えられたり削除されたりするわけではありません。

同じブランチを複数のrulesetやbranch protection ruleが対象としている場合、それぞれのルールが集約され、同じ種類のルールに異なる設定がある場合は、より厳しい条件が適用されます。(GitHub Docs)

この仕組みは段階的な移行に利用できますが、レビュー却下の許可リストが複数箇所に存在すると、誰が実際に許可されるか分かりにくくなります。

安全に移行するには、次の順序が適しています。

現在のbranch protection ruleに設定されている許可ユーザー、チーム、アプリを確認する
同じ対象ブランチと許可主体をrepository rulesetに設定する
許可ユーザーと非許可ユーザーで実際の却下テストを行う
想定どおりに動作したことを確認する
不要になったbranch protection rule側の設定を解除する

移行中に異なる許可リストを設定すると、想定以上に厳しい制限となり、緊急時に誰もレビューを解除できなくなる可能性があります。公式ドキュメントではルールの重ね合わせが説明されていますが、異なるactorリストの具体的な合成結果まで詳細には説明されていません。そのため、本番ブランチへ適用する前の実機確認が必要です。

対象者と対応要否を判断する基準

すべてのGitHub利用者が直ちに設定を変更する必要はありません。次の表を基準に対応要否を判断できます。

現在の構成	対応優先度	判断理由
rulesetsでrequired reviewsを運用している	高	今回の機能を直接利用できる
branch protectionからrulesetsへ移行中	高	権限設定の移行漏れを防ぐ必要がある
write権限を持つ開発者が多数いる	高	レビュー却下可能者が広すぎる可能性がある
セキュリティや監査対象のリポジトリ	高	承認解除の責任者を明確化しやすい
required reviewsを利用していない	低	却下対象となる必須レビューがない
手動却下を日常的に使わない	中	緊急時の担当者だけ決めておく価値がある
GitHub Enterprise Serverを利用している	要確認	今回の発表はgithub.com上の一般提供を対象としている

特に、Request changesを誰が解除できるかを明文化していない組織では、設定前に運用ルールを決める必要があります。

単にリポジトリ管理者全員を登録するのではなく、次のような責任分担を検討するとよいでしょう。

通常の機能レビュー：開発リードチーム
セキュリティレビュー：セキュリティチーム
法務・ライセンス確認：コンプライアンス担当
緊急解除：2名以上のリポジトリ管理責任者
自動解除処理：専用GitHub App

利用できるプランと必要な権限

Rulesetsは、パブリックリポジトリではGitHub FreeとGitHub Free for organizationsでも利用できます。プライベートリポジトリではGitHub Pro、GitHub Team、GitHub Enterprise Cloudが対象です。

リポジトリのrulesetを作成、編集、削除するには、リポジトリのadmin権限、またはedit repository rules権限を持つカスタムロールが必要です。read権限を持つユーザーは、リポジトリに設定されたrulesetを閲覧できます。(GitHub Docs)

導入条件は次のとおりです。

確認項目	条件
対象サービス	github.com
ruleset種別	Branch ruleset
必要なルール	`Require a pull request before merging`
設定権限	Adminまたは`edit repository rules`
許可主体	ユーザー、チーム、GitHub Apps
クライアント更新	公式発表では特別なGitクライアント更新は案内されていない

GitHub Enterprise Serverは、今回のChangelogで一般提供対象として明記されていません。GHESを利用している場合は、利用中バージョンのリリースノートと管理画面で別途確認してください。

GitHub UIから設定する手順

設定を変更できる権限を持つユーザーで、対象リポジトリを開きます。

リポジトリのSettingsを開く
左メニューのRulesを開く
Rulesetsを選択する
対象となるbranch rulesetを開く
対象ブランチが正しいことを確認する
Require a pull request before mergingを有効にする
レビュー設定内のRestrict who can dismiss reviewsを有効にする
レビューを却下できるユーザー、チーム、GitHub Appsを追加する
rulesetのenforcement statusを確認する
設定を保存する

GitHub公式の作成手順では、Settings、Rules、Rulesetsの順に進み、ブランチ保護ルールを選択する流れになっています。Activeで保存したrulesetは、作成または変更後すぐに適用されます。(GitHub Docs)

個人ユーザーよりチーム指定を優先する

継続運用では、個人ユーザーを多数登録するより、チームを指定する方が管理しやすくなります。

個人指定では、異動や退職のたびにrulesetを変更しなければなりません。チーム指定なら、Organizationのチームメンバーを変更するだけで対応できます。

ただし、チーム内の全員に却下権限を与えてよいかは別途確認が必要です。既存の開発チームが大きすぎる場合は、review-dismissersやrepository-governanceなど、用途を限定したチームを作成する方法が適しています。

Bypass listの代用にしない

Rulesetには、ルール全体を回避できるBypass listがあります。しかし、レビューの却下だけを許可したいユーザーをBypass listへ登録するのは適切ではありません。

Bypass権限は、レビュー却下だけではなく、ruleset内のほかの保護を回避できる可能性がある、より広い権限です。レビュー却下の許可リストとBypass listは、目的を分けて管理してください。RulesetのBypass listでは、ロール、チーム、アプリなどを指定し、常時またはプルリクエスト時のみの回避権限を設定できます。(GitHub Docs)

REST APIやIaCで管理する場合の対応

GitHub公式のREST APIでは、repository rulesetの作成と更新にpull_requestルールのdismissal_restrictionを指定できます。

本稿執筆時点のREST APIドキュメントでは、最新バージョンとして2026-03-10が表示されています。Repository rulesetの更新エンドポイントは次の形式です。

PUT /repos/{owner}/{repo}/rulesets/{ruleset_id}

作成または更新には、fine-grained personal access tokenやGitHub App tokenなどで、リポジトリのAdministration: write権限が必要です。(GitHub Docs)

既存rulesetを取得してから更新する

APIで設定する場合は、新しいプロパティだけを記述した断片を、そのまま完全な更新リクエストとして送信しないでください。

まず現在のrulesetを取得し、次の項目を保持した状態で更新します。

ruleset名
対象ブランチ条件
enforcement status
bypass actors
既存のrules配列
required review数
stale review設定
code owner review設定
conversation resolution設定
許可するmerge method

特に、社内ツールがruleset全体を再生成している場合、新しいdismissal_restrictionを認識しない古いスキーマが設定を削除する可能性があります。

UIから設定した後にIaCを適用する運用では、次の点を確認してください。

IaCのplanでdismissal_restrictionが削除対象になっていないか
使用中のSDKやProviderが新しいフィールドを保持できるか
JSONスキーマのadditionalProperties制限でエラーにならないか
GETした設定を再送信した際にactor情報が欠落しないか
GitHub Appをslugではなく、適切なactor IDとして処理しているか

Branch protection用の設定を使い回さない

従来のbranch protection APIは、次のような構造です。

"dismissal_restrictions": {
  "users": ["octocat"],
  "teams": ["security-team"],
  "apps": ["review-governance-app"]
}

Rulesetでは、次のようにIDとtypeを使用します。

"dismissal_restriction": {
  "enabled": true,
  "allowed_actors": [
    {
      "id": 123456,
      "type": "Team"
    }
  ]
}

プロパティ名だけでなく、ユーザー名やteam slugをactor IDへ変換する処理が必要です。移行スクリプトを作る場合は、文字列の置換だけで対応しないようにしてください。(GitHub Docs)

既存実装への影響を確認するポイント

今回の追加はオプション機能であり、既存rulesetの動作を強制的に変更する更新ではありません。ただし、rulesetを自動管理している環境では間接的な影響が考えられます。

カスタムスキーマが新しいフィールドを拒否しないか

REST APIのレスポンスを厳密な型へ変換している場合、新しいdismissal_restrictionが追加されたことで、デシリアライズエラーが発生する可能性があります。

次の実装は確認が必要です。

OpenAPIから固定生成した古いクライアント
不明なJSONフィールドをエラーにする内部ツール
rulesetを独自データベースへ同期している処理
設定差分を毎日上書きする自動化
Organization内の複数リポジトリへrulesetを配布するスクリプト

不明なフィールドを無視できる読み取り処理であれば、影響は限定的です。一方、読み取った設定を再構築してPUTする処理は、新しいフィールドを欠落させやすいため注意してください。

GraphQLの固定型を確認する

公式Changelogでは、GraphQLによる設定にも対応すると案内されています。GraphQLを利用している場合は、利用中のmutation、input type、生成済みクライアントコードが最新スキーマに対応しているか確認します。(The GitHub Blog)

GraphQLの型を独自に複製している場合は、GitHubの現在のスキーマを基準に再生成する方が安全です。

親Organizationのrulesetを見落とさない

リポジトリ単位の設定だけを見ても、実際に適用されているルールを把握できないことがあります。Organizationレベルのrulesetが同じブランチを対象としている可能性があるためです。

REST APIのGet rules for a branchは、リポジトリレベルとOrganizationレベルを含め、指定ブランチに適用される有効なルールを返します。evaluateまたはdisabled状態のrulesetは、この結果には含まれません。(GitHub Docs)

GET /repos/{owner}/{repo}/rules/branches/{branch}

本番適用前には、少なくともデフォルトブランチとリリースブランチについて有効ルールを確認してください。

本番適用前に実施したいテスト

レビュー却下制限は、設定画面を見ただけでは十分に検証できません。許可された主体と許可されていない主体の両方で、実際にプルリクエストを操作する必要があります。

テスト用リポジトリ、または本番に影響しない一時ブランチを用意し、次のテストを行います。

テスト	確認内容
許可チームのメンバー	レビューを却下できること
許可されていないwriteユーザー	レビューを却下できないこと
許可リスト外の管理者	Bypass設定を含め、実際の結果を確認する
許可したGitHub App	API経由で却下できること
許可していないGitHub App	API経由の却下が拒否されること
対象外ブランチ	制限が誤って適用されていないこと
既存プルリクエスト	設定変更前に作成したPRでの動作
新規プルリクエスト	設定変更後に作成したPRでの動作
Request changes	変更要求レビューを却下できる主体
Approve	承認レビューを却下できる主体
新しいコミットのpush	stale reviewの自動解除との併用
Branch protectionとの併用	想定外に厳しい制限になっていないこと

許可リスト外の管理者も必ずテストする

管理者は多くのGitHub設定を変更できるため、「adminなら必ず却下できる」と思い込みやすい点に注意が必要です。

RulesetのBypass list、Organizationレベルruleset、branch protection ruleが組み合わさると、権限の結果が分かりにくくなります。緊急対応を担当する管理者アカウントについても、実際のプルリクエストで却下操作を確認してください。

GitHub Appは権限とインストール範囲も確認する

許可リストにGitHub Appを追加しただけで、アプリが自動的に必要なAPI権限を取得するわけではありません。

次の項目を確認します。

対象リポジトリにアプリがインストールされているか
プルリクエストレビューを操作する権限があるか
使用しているinstallation tokenが対象リポジトリを含むか
rulesetで選択したactorと実際のinstallationが一致しているか
アプリ停止時の代替担当者が存在するか

自動化だけを許可し、人間の緊急解除担当者を設定しない構成は避けた方が安全です。

テスト時に利用できるenforcement status

Rulesetには、主に次の状態があります。

active：ルールを実際に適用する
disabled：ルールを無効化する
evaluate：適用前の評価に利用する

REST APIドキュメントでは、evaluateはGitHub Enterpriseで利用でき、Rule Insightsから評価結果を確認できると説明されています。(GitHub Docs)

ただし、レビュー却下権限については、evaluateだけで実際の許可・拒否動作を完全に確認できるとは限りません。最終的には一時ブランチや検証用リポジトリでactiveにし、実際の却下操作を行う必要があります。

GitHub Enterprise以外では、次の方法が現実的です。

検証用ブランチを作成する
そのブランチだけを対象にするrulesetを作成する
rulesetをactiveにする
テスト用プルリクエストを作成する
許可ユーザーと非許可ユーザーで操作する
結果を記録する
問題がなければ本番対象へ切り替える

失敗しやすい設定と対策

レビュー担当チームと却下担当チームを同じにする

レビューを行うチーム全員が、レビューを却下できる必要があるとは限りません。

例えば、Security Teamの10人全員がレビューできても、却下権限は当番責任者2人だけに限定したい場合があります。レビュー権限と却下権限を別々に設計してください。

許可者を1人だけにする

却下担当者が休暇、退職、アカウント停止などで不在になると、変更要求を解除できなくなる可能性があります。

少なくとも次のどちらかを推奨します。

2人以上を含む専用チームを指定する
通常担当チームと緊急担当者を併用する

Bypass listを広げすぎる

レビュー却下を可能にするためだけに、write roleや管理者全体をBypass listへ入れると、ほかのruleset保護まで回避できる構成になりかねません。

レビュー却下はdismissal_restriction、ルール全体の例外はbypass_actorsとして分けてください。

IaCがUI設定を元に戻す

UIで新機能を有効にしても、古いIaC定義を適用すると無効へ戻る可能性があります。

設定後は、次の順番で確認します。

UIで設定する
REST APIで現在値を取得する
IaCのplanを実行する
削除や変更が発生しないことを確認する
IaC定義へ正式に取り込む
再度applyして設定が維持されることを確認する

Actorの名前だけを記録する

APIではactor IDを使用するため、表示名やユーザー名だけでは再現できない場合があります。

設定管理台帳には、次の情報を残しておくと安全です。

記録項目	例
actorの目的	セキュリティレビュー解除
actor type	`Team`
actor ID	`123456`
表示名・slug	`security-review-admins`
管理責任者	Security Engineering Manager
緊急時の代替	Repository Admin Team
見直し日	四半期ごと

変更履歴とロールバックの準備

GitHub REST APIには、repository rulesetの履歴と特定バージョンを取得するエンドポイントがあります。変更前後の状態を確認する際に利用できます。(GitHub Docs)

GET /repos/{owner}/{repo}/rulesets/{ruleset_id}/history

履歴の取得は、過去設定への自動ロールバックそのものではありません。変更前のJSONも別途保存し、必要になった場合に以前の設定を再適用できる状態にしておくと確実です。

本番変更前には、次の情報を保存します。

ruleset全体のJSON
ruleset ID
対象ブランチ条件
branch protection ruleの設定
Organizationレベルrulesetの有無
許可actorのIDとtype
テスト結果
変更担当者
変更日時

対応方針を決めるための最終チェック

GitHub repository rulesetsでrequired reviewsを利用している場合は、まず現在のレビュー却下権限を確認してください。

対応は次の順序で進めると安全です。

対象リポジトリと対象ブランチを洗い出す
branch protection ruleとrulesetsの両方を確認する
現在レビューを却下できるユーザーを把握する
業務上必要なユーザー、チーム、GitHub Appsを決める
APIやIaCの新プロパティ対応を確認する
検証用ブランチで許可・拒否テストを行う
本番rulesetへ設定する
不要なbranch protection側の重複設定を整理する
定期的にチームメンバーとactor IDを見直す

今回の更新は、日常的な開発操作を大きく変える機能ではありません。しかし、承認済みレビューや変更要求を誰が解除できるかは、コードレビューの信頼性に直結します。

特に、セキュリティ、決済、個人情報、インフラ、リリース承認などを扱うリポジトリでは、write権限の有無だけで却下可否を決めず、責任を持つチームへ明示的に限定することが重要です。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。