# マージキューとは？

> マージキューとは何か？プルリクエストのマージをどのようにシリアライズし、それぞれを最新の main に対してテストし、混雑したリポジトリを悩ませる main 破壊の競合を防ぐのかを学びましょう。

Source: https://latchkey.dev/ja/learn/ci-explained/what-is-a-git-merge-queue  
Updated: 2026-06-26

マージキューはプルリクエストのマージをシリアライズし、それぞれを最新の main に対してテストするため、main ブランチが同時マージによって壊れることはありません。

マージキューは、混雑したリポジトリにおける微妙な問題を解決します。2 つのプルリクエストはそれぞれ単独では CI をパスしても、互いに対してテストされていないため、両方がマージされると main を壊すことがあります。マージキューは、変更を最新の main に対して 1 つずつテストしてからランドさせることで、そのギャップを埋めます。

## 解決する問題

多くの PR が並列で CI をパスするとき、それぞれは古い main に対してテストされています。それらを立て続けにマージすると、どの pipeline も実行したことのない組み合わせが生じ、ブランチを壊すことがあります。この競合は、チームとそのマージレートがスケールするにつれて悪化します。

## マージキューの仕組み

直接マージする代わりに、承認された PR はキューに入ります。システムは各 PR を現在の main（およびその前に並んだ変更）の上に build し、CI を実行し、パスした場合のみマージします。失敗したエントリはブランチを壊せないよう排除されます。

## なぜ重要か

マージキューは、main にランドするものが、マージ先の正確な状態に対して実際にテストされたことを保証します。その結果、重い同時マージの下でも main ブランチはグリーンを保ち、単一の PR が原因ではない突然の破壊による火消し作業がなくなります。

## マージキューと CI/CD

マージキューは、並んだエントリを検証する際に多くの投機的な CI 実行をファンアウトできるため、runner に実際の負荷をかけます。遅い、あるいはキャパシティの限られた runner はキューをボトルネックに変えます。Latchkey のようなマネージドプラットフォームが提供する、十分で高速な runner キャパシティは、混雑したキューを流し続け、マージが停滞しないようにします。

## いつ導入すべきか

- 同時マージが main を壊し始めたら有用です。
- 必須の status check とブランチ保護と組み合わせます。
- 並んだエントリを迅速に検証するのに十分な CI キャパシティが必要です。
- 高速に動くチームのために main をグリーンに保ちます。

## Applying this to your pipeline

- Measure before changing. Most CI optimisation targets the wrong step because the slow one is assumed rather than timed.
- Cache what is expensive to produce and cheap to validate, and key the cache to the exact tool version.
- Fail fast: run the cheapest checks that can reject a change first, so an expensive job never starts on code that cannot pass.
- Prefer determinism over speed when they conflict. A fast pipeline nobody trusts gets re-run, which is slower than a slow one that is believed.

## FAQ

### What is What is a merge Queue??

A merge queue solves a subtle problem in busy repositories. Two pull requests can each pass CI on their own, yet break main when both merge, because neither was tested against the other. A merge queue closes that gap by testing changes against the up-to-date main, one at a time, before they land.

### The problem it solves?

When many PRs pass CI in parallel, each was tested against an older main. Merging them in quick succession can produce a combination no pipeline ever ran, breaking the branch. This race grows worse as a team and its merge rate scale up.

### How a merge queue works?

Instead of merging directly, approved PRs enter a queue. The system builds each one on top of the current main (and the queued changes ahead of it), runs CI, and merges only if it passes. Failing entries are kicked out so they cannot break the branch.

### Why it matters?

A merge queue guarantees that what lands on main was actually tested against the exact state it merges into. The result is a main branch that stays green even under heavy, concurrent merging, eliminating the firefighting that comes from a surprise breakage no single PR caused.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt