GitHub・プルリク・マージキュー・2026年10月26日に確認

GitHub：ブランチがマージキューでマージする

リポジトリの管理者は、ブランチにマージキューを必須にできます。ブランチの保護なら「Require merge queue」、ルールセットなら規則 merge_queue（「Merges must be performed via a merge queue」）です。そうすると、そのブランチへのプルリクは直接にはマージされません。ブランチの保護の必須の確認をすべて通ったら、リポジトリの書き込み権限を持つ人がキューに入れます。キューは、対象のブランチの最新の版と、すでに並んでいるプルリクにそのプルリクの変更を重ねた結果で、必須のステータスチェックが通ることを確かめ、それから GitHub がキューに設定された方法でマージします（GitHub の説明「マージキューを管理する」と「マージキューでプルリクをマージする」）。プルリクのベースブランチにマージキューがあるかは GraphQL の isMergeQueueEnabled で、キューのどこにいるかは mergeQueueEntry で分かります（2026年10月26日に確認）。

POST /graphql   pullRequest(number: N) { isMergeQueueEnabled isInMergeQueue mergeQueueEntry { position state } }
POST /graphql   enqueuePullRequest(input: { pullRequestId: ID, expectedHeadOid: SHA }) { mergeQueueEntry { position } }
PUT  /repos/OWNER/REPO/pulls/N/merge-async   { "merge_action": "merge_queue", "sha": SHA }

直接マージされない理由

REST のマージ：「Merge a pull request」（PUT /repos/OWNER/REPO/pulls/N/merge）は、マージキューでのマージに対応していません。GitHub は代わりに非同期のマージの API を勧めています（GitHub の説明「プルリクの REST API」）。
非同期のマージ：PUT …/merge-async は、裏でマージするか、プルリクをマージキューに入れます。merge_action は、default なら対象のブランチにマージキューがあればそれを使い、merge_queue ならキューに入れ、direct_merge ならキューを通さずにマージします。202 は受け付けて裏で進めるという意味です。すでにマージ済みか、すでにキューにいるなら 200 がすぐに返り、「enqueued」はキューに入ったという意味で、マージされたという意味ではありません。400 はマージできない（閉じている・下書きのまま）という意味で、この段階ではプルリクの基本的な状態しか確かめず、ブランチの保護やリポジトリのルールは走りません。409 は、そのプルリクにほかのマージの依頼がもう待っているという意味です。コミットのタイトル・メッセージ・merge_method は、直接のマージにだけ効きます。
GraphQL：enqueuePullRequest は、すぐに入れられる時だけプルリクをキューに入れます。入れられない時は、理由を説明するエラーを返します。expectedHeadOid は想定している head、jump はキューの先頭に入れる指定です。dequeuePullRequest はキューから外します。
GitHub の画面で：「Merge when ready」がプルリクをキューに入れます。条件を全部満たす前に押すと自動マージが有効になり、条件を満たした時にキューに入ります（リポジトリで「Allow auto-merge」が無効でも）。管理者は、ブランチの保護の設定が許していれば「Merge without waiting for requirements to be met (bypass branch protections)」で直接マージできます。

キューがすること

マージグループ：キューは、プルリクの変更をベースブランチの最新の版と前に並んだプルリクと合わせて、決まった接頭辞の一時的なブランチに置き、種類 checks_requested の merge_group イベントを送り、ベースブランチが求めるチェックが通ったらマージします。マージは並んだ順（先に入った物から）です。
チェックはマージグループで走らせる：必須のチェックを報告する GitHub Actions のワークフローには、pull_request や push とは別に、merge_group のイベントが要ります。無いとチェックが報告されず、マージは失敗します（必須チェックが Expected のまま）。ほかの CI は、gh-readonly-queue/{base_branch} で始まるブランチへの push で走らせます。その SHA はプルリクの物と違います。
設定：マージの方法、同時に作るビルドの数（merge_group の webhook を1〜100）、失敗していないプルリクだけをマージするか（ルールセットの grouping_strategy：ALLGREEN はグループの各プルリクのマージコミットがすべて通る必要があり、HEADGREEN はグループの先頭だけ）、ステータスチェックの待ち時間（過ぎると報告の無いチェックは失敗とみなされます）、グループの最小・最大の数と待ち時間です。ブランチ名のパターンに * を使うブランチの保護では、マージキューを有効にできません。
今いる所：GraphQL は並びの position・state（QUEUED・AWAITING_CHECKS・MERGEABLE・UNMERGEABLE・LOCKED）・estimatedTimeToMerge を返します。GitHub の画面では、Branches のページと、プルリクのタイムラインの一番下の merge queue のリンクからキューを見られます。先頭へ割り込むと、進行中のプルリクがすべてビルドし直しになります。

キューから外れた理由

GitHub が挙げる理由：CI がマージグループのテストの失敗を報告した。CI の成功を待つうちに時間切れになった。だれかが API かマージキューの画面で外した。自動では解決できないブランチの保護の失敗があった。最新の対象のブランチと前の変更に重ねたら、必須のステータスチェックが失敗したか、ベースブランチと衝突した。
理由はタイムラインに：外された理由は、プルリクのタイムラインに出ます。後ろに並んでいたプルリクは、その変更を除いてまとめ直されます。

直す所

キューに入れる：直接のマージの API ではなく、GitHub の画面の Merge when ready、enqueuePullRequest、merge_action を merge_queue にした merge-async のどれかを使います。
先にブランチのルールを満たす：キューに入る前に満たす必要があります。承認のレビュー（コードオーナーのレビュー）、会話の解決（マージが会話の解決を待っている）、署名されたコミット（署名の無いコミット）、必須のチェックです。
チェックをマージグループで走らせる：必須のチェックを報告するワークフローに merge_group を足すか、CI を gh-readonly-queue/ のブランチで走らせます。
外されたら：タイムラインの理由を読んで直し、もう一度キューに入れます。

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

Lesstep の Pull Request Inbox for GitHub は、JetBrains IDE（2024.1 以降）のプラグインです。プルリクのレビュー・チェック・会話を差分の隣に出し、対象のブランチが許す方法でマージします。GitHub がプルリクを blocked と言うときは、マージの確認に読める物を名指しします（報告の無い必須チェック・まだ要るレビュー・ルールが止めている未解決の会話と署名の無いコミット）。対象のブランチがマージキューでマージするなら、「マージ」はプルリクをキューに入れ（GraphQL の enqueuePullRequest）、マージの確認には、キューでマージするブランチであることか、キューの何番目にいて、チェックを待っているのか・マージできるのか・できないのかを出します。受信箱・差分・会話は無料、承認・コメント・解決・マージは Pro（月 US$1.50・30日間の無料試用つき）です。画面は日本語です。

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