GitHub・プルリク・コードオーナー・2026年10月26日に確認

GitHub：プルリクがコードオーナーのレビューを待っている

ブランチの保護やルールセットは、コードオーナーのレビューを必須にできます。そうすると、リポジトリの CODEOWNERS ファイルでオーナーが決まっているファイルを変えるプルリクは、ほかに承認がいくつあっても、そのファイルのオーナーの誰かが承認するまで、保護されたブランチにマージできません（GitHub の説明「コードオーナーについて」と「保護されたブランチについて」）。それまでの間、GraphQL のプルリクの reviewDecision は REVIEW_REQUIRED（「A review is required before the pull request can be merged」＝マージの前にレビューが要る）、REST の mergeable_state は blocked です（2026年10月26日に確認）。

GET  /repos/OWNER/REPO/rules/branches/BRANCH         → 規則 "pull_request" の parameters.require_code_owner_review
GET  /repos/OWNER/REPO/codeowners/errors?ref=BRANCH  → errors[].line, kind, message, path
POST /graphql   pullRequest(number: N) { reviewDecision
                  reviewRequests(first: 100) { nodes { asCodeOwner requestedReviewer { ... on User { login } ... on Team { combinedSlug } } } } }

コードオーナーが誰になるか

どのファイルか：GitHub は CODEOWNERS を .github/、リポジトリのルート、docs/ の順に探し、最初に見つかった1つを使います。
ベースブランチ：CODEOWNERS は、置かれたブランチのオーナーを決めます。プルリクが使うのは、ベースブランチ（マージしたときに変わる側のブランチ）にあるファイルです。プルリクの中で CODEOWNERS を変えても、その版は使われません。
最後に合った行：パターンは gitignore のルールのほとんどに従い、最後に合ったパターンが優先されます。GitHub の例では、* @global-owner1 @global-owner2 の後に *.js @js-owner と書くと、JavaScript のファイルのオーナーは @js-owner だけになります。
オーナーが複数：1つのパターンのオーナーは、全員を同じ行に書きます。別の行に分けると、そのパターンに合うのは最後に書いたオーナーだけです。コードオーナーのレビューが必須のとき、1つのファイルのオーナーのうち誰か1人の承認で足ります。
オーナー無し：オーナーを書かないパターンは、そのパスをオーナー無しにします。そこへの変更は、書き込み権限のある誰の承認でも通ります。

オーナーに頼まれない・数に入らない理由

書き込み権限：コードオーナーには、リポジトリの書き込み権限が要ります。チームの場合は、チームが見える（visible）状態で、チーム自体に書き込み権限が要ります。メンバー全員が直接や組織や別のチームを通じて書き込み権限を持っていても同じです。存在しないユーザーやチーム、権限が足りないユーザーやチームは、コードオーナーになりません。
飛ばされる行：書き方の誤った行は飛ばされます。gitignore のうち3つは CODEOWNERS では効きません：# で始まるパターンを \ で逃がすこと、! による否定、[ ] による文字の範囲。パスは大文字と小文字を区別します。macOS のように区別しないシステムでも同じです。
大きすぎる：3 MB を超える CODEOWNERS は読み込まれません。コードオーナーは表示されず、誰にもレビューが頼まれません。
メールアドレス：オーナーは、そのアカウントに足したメールアドレスでも書けます。ただし managed user account はメールアドレスでは書けません。
下書き：下書き（draft）のプルリクには、コードオーナーへのレビューの依頼が自動では出ません。レビューの準備ができた（ready for review）にした時に知らされます（レビューの依頼が出ない理由）。
フォーク：フォークから元のリポジトリへのプルリクは、元のリポジトリのベースブランチの CODEOWNERS を使います。ベースブランチがフォークの中なら、フォークのファイルを使い、コードオーナーがフォークに書き込み権限を持つ時だけレビューを頼みます。

オーナーが承認したのに、まだブロックされている

push の前の承認：「Dismiss stale pull request approvals when new commits are pushed」（新しいコミットで古い承認を外す）があると、差分が変わった時点で承認は外れ、もう一度承認が要ります。「Require approval of the most recent reviewable push」（最後の push の承認）があると、最後に push した人は自分で承認できません（承認が数に入らない理由）。
同じコミットの別のプルリク：必須のレビュアーが全員承認しても、head のブランチが同じコミットを指す別の開いたプルリクに、保留中か却下のレビューがあると、コラボレーターはマージできません。書き込み権限のある人が、先にそちらのレビューを承認するか却下（dismiss）します。
別のルール：コードオーナーのレビューは、要件の1つにすぎません。必須のチェック（必須チェックが Expected のまま）、ブランチを最新にしておくこと、会話の解決も止める理由になります。

直す所

誤りを読む：GET /repos/OWNER/REPO/codeowners/errors は、CODEOWNERS の書き方の誤り（行・列・種類・メッセージ・直し方の案）を返します。ref で指したブランチの版、無ければ既定のブランチの版です（GitHub の REST の説明）。GitHub でファイルを開いても、誤りに印が付きます。
ファイルのオーナーを見る：ベースブランチでそのファイルを開き、盾のアイコンにマウスを載せると、オーナーと CODEOWNERS の行が出ます。
書き込み権限を渡す：ユーザーやチームを書き込み権限つきでリポジトリに足し、チームを見える状態にします。
ファイル自体を守る：GitHub は、.github/ に CODEOWNERS を置き、そのファイル自体のオーナーをリポジトリの持ち主にすること（/.github/CODEOWNERS @owner_username）を勧めています。持ち主のレビュー無しにルールが変わらなくなります。
ルールの場所：ルールセットなら、プルリクの規則の require_code_owner_review です（ルールセットで使える規則）。「Get rules for a branch」が、そのブランチに効いている規則の中に返します。ブランチの保護なら「Require review from Code Owners」です。
管理者：既定では、ブランチの保護の制限は、管理者の権限を持つ人や「bypass branch protections」の権限を持つロールには効きません。「Do not allow bypassing the above settings」をオンにすると効きます。

IntelliJ IDEA はコードオーナーを読まない

IntelliJ IDEA に入っている GitHub の機能が、コードオーナーのレビューをどう扱うか。ソース（2026年10月31日に確認・IntelliJ IDEA：pullRequestMergeability.graphql・refUpdateRule.graphql・pullRequestInfo.graphql・GraphQL のファイル・GithubApiRequests.kt）では：

ルールのこの項目は読まない：マージ先（base）のブランチのルールについて、必要な承認の数・必須のステータスチェック・署名・まっすぐな履歴・force push・削除・自分が push できるかを頼みますが、requiresCodeOwnerReviews は頼みません。
オーナーも読まない：78本の GraphQL のファイルのどれも、コードオーナーとしてのレビュー依頼かを示す asCodeOwner を頼まず、REST で送る物の一覧（GithubApiRequests.kt）にもコードオーナーの物は無いので、どのレビュアーがコードオーナーかを示す物を IDE は頼みません。
判定は読む：プルリクの reviewDecision（GitHub が出すレビューの状態＝承認済み・変更の依頼あり・レビューが必要）は頼みます。

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

Lesstep の Pull Request Inbox for GitHub は、JetBrains IDE（2024.1 以降）のプラグインです。レビューを頼まれた人と、それぞれのレビューの状態（承認・変更の依頼・依頼中・前のコミットでの判断）を一覧にします。GitHub がプルリクを blocked と言うときは、マージの確認に「対象のブランチのルールをまだ満たしていない（必須のレビューか、必須のチェック）」と出します。GitHub がまだレビューが要る（reviewDecision が REVIEW_REQUIRED）と言う時は、そこにそう出し、コードオーナーとして頼まれてまだレビューしていない人の名前を出します（GraphQL で読むのでトークンが要り、チームの名前には組織の読み取りの権限が要ります）。受信箱・差分・会話は無料、承認・コメント・マージは Pro（月 US$1.50・30日間の無料試用つき）です。画面は日本語です。

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