GitHub・プルリク・ルールセット・2026年10月26日に確認

GitHub：マージがチームの承認を待っている（Required reviewers）

ルールセットのプルリクの規則は、プルリクが特定のファイルやディレクトリを変えるときに、決まったチームのレビューや承認を求められます。これが「Required reviewers」です。チームごとにメンバーから要る承認の数とファイルのパターンの一覧があり、そのファイルに触れるプルリクは、そのチームのメンバーの承認が足りるまで止まります。チームのメンバーの承認が数に入るのは、そのチームがリポジトリに書き込みの権限以上を持つときだけです（GitHub の説明「ルールセットで使える規則」・2026年10月26日に確認）。

"type": "pull_request",
"parameters": {
  "required_reviewers": [
    { "file_patterns": ["src/api/**"], "minimum_approvals": 2,
      "reviewer": { "id": 42, "type": "Team" } } ] }

規則の働き

チームと承認の数：ルールセットは最大15のチームを挙げられ、チームごとにメンバーからの承認を0〜10件求められます。0件にすると、チームは見えるようにプルリクに加わるだけで、承認しなくてかまいません。
ファイルのパターン：チームごとに、設定がどのファイルに効くかを決めるパターンの一覧があり、書き方は .gitignore と同じです。感嘆符（!）で始まるパターンは否定で、パターンは順に照らし合わされるので、否定のパターンは前のパターンに合ったファイルを外せます。
数に入る承認：そのチームのメンバーの承認で、チームがリポジトリに書き込みの権限以上を持つときだけです。
選べるチーム：組織全体のルールでは組織のチーム、リポジトリのルールではリポジトリを持つ組織のチームです。個人が持つリポジトリにはチームが無いので、この規則は使えません。
REST API では：pull_request の規則の parameters の required_reviewers で、それぞれに file_patterns（fnmatch の書き方）、minimum_approvals、reviewer（ID で示すチーム）があります（GitHub の説明「ルールの REST API」）。「Get rules for a branch」は、リポジトリと組織のどちらで決めたルールでも、ブランチに効く有効なルールを返します。評価だけのルールセットや、切ってあるルールセットのルールは返しません。

ほかのレビューの設定との関係

同じプルリクの規則：Required reviewers は、承認の数、コードオーナーのレビュー、最後のレビュー可能な push の承認、会話の解決と同じプルリクの規則にあり、そのどれもがマージを止めることがあります。
チームのレビューの自動割り当て：チームが自動割り当てを入れていると、チームにプルリクのレビューを頼むたびに、チームはレビュアーから外れ、代わりにメンバーの一部が割り当てられます。そのためプルリクには、チームでなくそのメンバーが出ることがあります（GitHub の説明「チームのコードレビューの設定」）。

直す所

規則を探す：リポジトリを読める人なら誰でも、有効なルールセットを見られます（GitHub の説明「ルールセットについて」）。プルリクの規則の Required reviewers に、チーム・承認の数・ファイルのパターンが並ぶので、プルリクが変えるファイルと見比べます。
チームに頼む：チームかそのメンバーにレビューを頼み、規則が求める数の承認を待ちます。
承認が数に入らない：メンバーが承認したのにまだ止まっているなら、チームがリポジトリに書き込みの権限以上を持っているかを見ます。リポジトリの権限を管理する人が、チームに権限を与えます。
チームがこのファイルまで覆うべきでない：ルールセットを管理する人がチームのファイルのパターンを狭める（否定のパターンでファイルを外せます）か、承認の数を0にして、チームが見えるように加わるだけにします。

IntelliJ IDEA は承認を数で数え、チームとは照らし合わせない

IntelliJ IDEA に入っている GitHub の機能が、チームの承認が要るルールをどう扱うか。ソース（2026年10月31日に確認・IntelliJ IDEA：pullRequestMergeability.graphql・refUpdateRule.graphql・GHPRMergeabilityStateBuilder.kt・GHPRReviewFlowViewModelImpl.kt・GraphQL のファイル・GithubApiRequests.kt）では：

ルールは読まない：78本の GraphQL のファイルのどれも、requiredReviewers（プルリクのルールにあるチーム・ファイルのパターン・最低の承認数）も、ルールセットも、チームのメンバーも頼まず、REST で送る物の一覧にもありません。
数だけ読む：マージ先（base）のブランチについて、必要な承認の数を1つだけ読みます。この数を使うのは、GitHub がマージをブロック中と返し、自分がそのブランチに push でき、必須のチェックがすべて成功している（または必須のチェックが無い）間だけで、それ以外は 0 として扱います。
自分で出すレビューの状態：承認したレビュアーの数がその数に届けば（0 なら承認が1つあれば）承認済みとし、届かなければ GitHub の reviewDecision に従います。承認が求められたチームから来たかは見ません。
チームへの依頼：チームは slug で依頼します（チームに頼んだレビューがメンバーに置き換わった）。

IntelliJ IDEA で GitHub のプルリクを見るなら

Lesstep の Pull Request Inbox for GitHub は、JetBrains IDE（2024.1 以降）のプラグインです。プルリクのレビュー・チェック・会話を差分の隣に出し、対象のブランチが許す方法でマージします。止まっているプルリクでは、マージの確認に、まだレビューが要ることと、レビューを頼まれたコードオーナーを出します。ブランチのルールセットがファイルごとにチームの承認を求めていれば、そのチームと、それぞれに要る承認の数・覆うファイルも出します（レビューを頼まれなくなったチームは ID で出します）。受信箱・差分・会話は無料、承認・コメント・解決・マージは Pro（月 US$1.50・30日間の無料試用つき）です。画面は日本語です。

GitHub は GitHub, Inc. の商標、IntelliJ IDEA は JetBrains s.r.o. の商標です。このページは GitHub, Inc.・JetBrains のいずれとも提携しておらず、承認も受けていません。