GitHub merge queue とは、PR を列に並べ、前の PR と重ねて試験してから入れる仕組みです。

  • merge queue の設定の項目（同時に組む数・組の大きさ・待ち時間）と、Actions を merge_group で動かす書き方
  • AI の席が PR を量産する当社で、列 37 本のうち先頭が 20 分動かなかった時の数字
  • 同時に組む数を 6 から 12 に上げても main に入る本数が増えなかった理由と、揺れる試験 1 本が無関係な PR を列から落とした記録

AI に開発の仕事を任せる考え方は AIエージェント の頁に、席を並べて動かす手順は Claude Code の並列実行 の頁にまとめています。この頁は、並べた席の PR が main に入る手前の列だけを扱います。

merge queue の設定の項目と、当社が触った所

merge queue は、列に入った PR を前から順に main と重ねた一時の枝（gh-readonly-queue/ で始まる枝）に組み、必須の試験が通った物から統合します。組んだ物の試験が落ちると、その PR は列から外され、後ろの組は外した PR を抜いて組み直されます（Managing a merge queue・2026-10-30 に開いて確かめた）。

設定の画面の名前ruleset の項目何を決めるか幅当社の記録
Build concurrencymax_entries_to_build同時に試験と workflow の run を求める PR の数0〜100（画面は 1〜100）6。12 に上げて効かず、6 に戻した（下の節）
Minimum / Maximum group sizemin_entries_to_merge・max_entries_to_merge一度に統合する PR の数の下と上0〜100（画面は 1〜100）触っていない
Wait timemin_entries_to_merge_wait_minutes最初の PR が入ってから、組の下限が揃うのを待つ時間0〜360 分触っていない
Status check timeoutcheck_response_timeout_minutes必須の試験の答えを待つ上限。過ぎると落ちた扱い1〜360 分触っていない
Merge methodmerge_methodmerge・squash・rebase のどれで入れるか3 つから 1 つ触っていない

出典: Managing a merge queue・REST API endpoints for rules（どちらも 2026-10-30 に開いて確かめた）。当社の記録の列は 出典: 社の実測 2026-10-21（当社の CI の記録）。

GitHub Actions で必須の試験を回しているなら、workflow の起動の条件に merge_group を足します。足さないと、列に入った PR の試験が始まらず、必須の試験の答えが返らないまま統合が落ちます。merge_group は pull_request や push とは別のイベントです（Events that trigger workflows・2026-10-30 に開いて確かめた）。

on:
  pull_request:
    branches: [main]
  merge_group:
    types: [checks_requested]
    branches: [main]

出典: Events that trigger workflows の merge_group の例（2026-10-30 に開いて確かめた）。

AI の席に PR を列へ入れさせた時、本当に列に入ったかをどこで確かめるかは GitHub MCP の頁に書いています。この頁はその先、列に入った後の話です。

当社の記録: 列 37 本、先頭が 20 分動かない

2026-10-21、列には 37 本の PR が並んでいました。組まれていたのは前の 6 本だけで（max_entries_to_build が 6）、先頭が 20 分動きませんでした。AI の席の手は止まっておらず、PR は書かれ続けているのに、main に入る仕事が進まない形です（出典: 社の実測 2026-10-21（当社の CI の記録））。

人が書く PR なら、1 日に列へ入る本数は限られます。AI の席を並べると、書く速さが列の進む速さを超えます。列の詰まりは、席の数を増やしても解けません。そこで、1 組が何に時間を使っているかを数えました。

数えた物値
1 組（merge_group）の所要中央 19.8 分・最大 31.1 分
1 組が始まりに求める job約 12 本を一度に
1 組に同時に要る作業員（runner）平均 3.3〜3.5・最大 6〜8
赤（試験が落ちた）の組完了 50 組のうち 16 組（32%）
赤の出どころ赤の 6 本のうち 5 本は、同じ結合試験 1 本

出典: 社の実測 2026-10-21（当社の CI の記録・直近 3 時間に完了した 50 組）。

1 組に 20 分前後かかり、3 組に 1 組は赤で落ちる。落ちれば、その組の後ろは組み直しになります。赤の大半は、同じ結合試験 1 本から出ていました。

同時に組む数を 6 から 12 に上げても、入る本数は増えなかった

列の前で組まれる数が 6 に絞られているなら、上げれば流れる。そう考えて max_entries_to_build を 6 から 12 に上げ、上げる前の 1 時間と後の 1 時間を比べました。

数えた物6 の 1 時間12 の 1 時間
main に入った PR（同じ数え方）20 本13 本
赤の組の割合44%44%
作業員の待ち中央 1.0 分中央 2.3 分（最大 15.9 分）

出典: 社の実測 2026-10-21（当社の CI の記録）。

入る本数は増えず、作業員の待ちが延びました。理由は 2 つありました（出典: 社の実測 2026-10-21（当社の CI の記録））。

  1. 古い run が取り消されずに残る。赤の組で後ろが組み直される時、前の組で走っていた run が取り消されず、作業員を持ったまま残っていました。同じ PR の run が 2 本ずつ走っていました
  2. 作業員の数には上限がある。1 組が始まりに約 12 本の job を求めるので、組む数を倍にすると求める作業員も増え、上限に当たって待ちになります

同時に組む数は 6 に戻しました。列の進みを決めていたのは「同時に組む数」と「揺れる試験の赤で組み直しになること」で、作業員を足しても main に入る本数は増えませんでした（出典: 社の実測 2026-10-21（当社の CI の記録））。作業員を自前で持つ時の数え方は、同じ日に出した self-hosted runner の頁に渡します。

揺れる試験 1 本が、無関係な PR を列から落とす

赤の組は、その組の PR が悪いとは限りません。当社では、E2E 試験（Playwright の Electron）が遅い作業員で後片付けの時間切れ（Worker teardown timeout 180000ms）になり、retry で試験は全部緑なのに job が exit 1 で終わっていました。そのせいで、試験と関係の無い PR 2 本が計 3 回列から外れ、入れ直すたびに 20〜40 分ずつ失いました（出典: 社の実測 2026-10-10〜11（当社の CI の記録））。

根は、ログイン画面が成功の 1.5 秒後に自分で閉じる瞬間と、次の操作が重なる所でした。遅い台ほど重なります。直したのは次の 3 つです。retry の回数と、試験を飛ばす印（skip）には触っていません。

直した所中身
閉じる瞬間ログイン画面が閉じきるのを待ってから次の操作に進む
後片付け20 秒の上限を付ける
1 つの操作30 秒の上限を付ける

出典: 社の実測 2026-10-10〜11（当社の CI の記録）。

直した後、使い捨ての作業員で 22 本続けて緑でした（出典: 社の実測 2026-10-10〜11（当社の CI の記録））。retry を増やして赤を隠す道もありましたが、後片付けの時間切れは retry の外で起きていたので、隠せても列の赤は減りません。試験を書く席と見る席の分け方は AI テスト自動化 の頁に書いています。

作業員が消えて赤になった PR は、撃ち直しても列に戻らない

Spot の作業員（途中で回収されうる安い台）が回収されて job が赤になると、その run を撃ち直しても、列から落ちた PR は戻りませんでした。落ちて 1〜4 分後には、PR はもう列から外れていました（出典: 社の実測 2026-10-11（当社の CI の記録））。

公式の文書も、組の試験が落ちた時と、試験の答えが時間切れになった時は、PR を列から外すとしています（Managing a merge queue・2026-10-30 に開いて確かめた）。AI の席に「赤なら撃ち直す」とだけ渡すと、列から外れた PR を入れ直さないまま待ち続けます。撃ち直すより先に、PR がまだ列に居るかを見る形にしておきます。

次の手の候補（まだ効いたとは測っていない）

2026-10-21 の記録から出た次の手の候補は 2 つです。どちらも、この頁を書いた時点で効いたかを測っていません（出典: 社の記録 2026-10-21（当社の CI の記録））。

候補狙い今の状態
組み直しの時に、古い merge_group の run を取り消す（workflow の concurrency の cancel-in-progress を merge_group にも効かせる）作業員を持ったまま残る run を消し、同じ PR の run が 2 本走るのを止める未測定
赤の大半を出している揺れる試験を直す組み直しの回数そのものを減らす未測定

出典: 社の記録 2026-10-21（当社の CI の記録）。

concurrency は、同じ組の名前の run を一度に 1 本だけにする設定で、cancel-in-progress: true を付けると走っている物を取り消します。公式の頁はこの例を ${{ github.workflow }}-${{ github.ref }} の組の名前で示していますが、merge_group には触れていません（Control the concurrency of workflows and jobs・2026-10-30 に開いて確かめた）。merge_group の run でどう組の名前を付ければ古い組だけが消えるかは、当社でもまだ確かめていません。

AI の席を並べる前に、列で見ておく数

当社の記録を、列が詰まった時に見る順に並べ直すと次のとおりです。

症状見る数当社で試した事
席は動いているのに main に入らない列の本数・組まれている本数・先頭が動かない時間列 37 本・組まれていたのは 6 本・先頭 20 分（2026-10-21）
同時に組む数を上げたくなる赤の組の割合・作業員の待ち・同じ PR の run の本数6→12 で入る本数は増えず、6 に戻した（2026-10-21）
無関係な PR が列から落ちる赤の出どころが同じ試験か揺れる試験を直し、22 本続けて緑（2026-10-10〜11）
撃ち直しても進まないPR がまだ列に居るか落ちて 1〜4 分後には列から外れていた（2026-10-11）

出典: 社の実測 2026-10-10〜11・2026-10-11・2026-10-21（当社の CI の記録）。

よくある質問

GitHub merge queue を使うと、workflow に何を足せばよいですか？

必須の試験を GitHub Actions で回しているなら、起動の条件に merge_group を足します。足さないと列に入った PR の試験が始まらず、必須の試験の答えが返らないため統合が落ちます（Events that trigger workflows・2026-10-30 に開いて確かめた）。

merge queue の Build concurrency を上げれば、列は速く流れますか？

当社では流れませんでした。6 から 12 に上げた 1 時間は、main に入った PR が 20 本から 13 本に減り、赤の組の割合は 44% のまま、作業員の待ちは中央 1.0 分から 2.3 分に延びました。古い run が取り消されずに作業員を持ったまま残ったことと、作業員の数の上限が理由でした（出典: 社の実測 2026-10-21（当社の CI の記録））。

merge queue で、関係の無い PR が列から外れるのはなぜですか？

組の試験が落ちると、その組の PR は列から外されます。当社では、揺れる E2E 試験 1 本が後片付けの時間切れで job を赤にし、無関係な PR 2 本が計 3 回外れて、20〜40 分ずつ失いました（出典: 社の実測 2026-10-10〜11（当社の CI の記録））。

列から外れた PR は、試験を撃ち直せば戻りますか？

当社では戻りませんでした。作業員が回収されて赤になった run を撃ち直しても、PR は落ちて 1〜4 分後にはもう列から外れていました（出典: 社の実測 2026-10-11（当社の CI の記録））。列に入れ直す必要があります。

出典

  1. GitHub Docs「Managing a merge queue」 https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue（2026-10-30 に開いて確かめた・列の仕組み・merge_group が要る事・設定の項目と幅・組が落ちた時と時間切れの時に列から外す事）
  2. GitHub Docs「Events that trigger workflows」の merge_group https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows（2026-10-30 に開いて確かめた・checks_requested・足さないと試験が始まらない事・書き方の例）
  3. GitHub Docs「REST API endpoints for rules」 https://docs.github.com/en/rest/repos/rules（2026-10-30 に開いて確かめた・ruleset の merge queue の項目 max_entries_to_build ほかとその幅）
  4. GitHub Docs「Control the concurrency of workflows and jobs」 https://docs.github.com/en/actions/how-tos/write-workflows/choose-when-workflows-run/control-workflow-concurrency（2026-10-30 に開いて確かめた・cancel-in-progress・組の名前の例）
  5. 社の実測 2026-10-21（当社の CI の記録・列 37 本と先頭の停止・1 組の所要と job と作業員・赤の割合と出どころ・同時に組む数 6→12 の前後の 1 時間）
  6. 社の記録 2026-10-21（当社の CI の記録・次の手の候補 2 つ。効いたかは未測定）
  7. 社の実測 2026-10-10〜11（当社の CI の記録・揺れる E2E 試験が無関係な PR を列から落とした事・根と直し・直した後の 22 本）
  8. 社の実測 2026-10-11（当社の CI の記録・回収された作業員の赤を撃ち直しても PR が列に戻らない事）

書いた人: ブルーランプ編集部（株式会社命） ／ 公開 ／ 更新