main への push が立て続けに発生したとき、後発パイプラインの deploy が先発の deploy を追い抜いて、リリース直後の環境が古いバージョンに書き戻される、という事故が起こります。deploy 単体であれば従来から serial-group で直列化できますが、deploy → release を1単位として割り込ませない、という指定は native にはできませんでした。

2026年4月に GA となった Job Groups は、この制約を埋めるための機能です。複数ジョブをグループとして定義し、グループ全体に serial-group を効かせます。本記事では設定の書き方と、運用上で気をつけるべき Rerun の挙動を整理します。

前提条件:
利用可能な環境は Cloud と Server v4.9 以降です。
（2026年4月時点、公式ドキュメント記載）。

Job Groupsを簡単に試してみる

手元で動きを簡単に試すためのサンプルを用意しました。

build と test を並列で走らせた後、deploy と release を deploy-and-release という1グループにまとめ、グループに serial-group を付けます。

version: 2.1

executors:
  base-small:
    docker:
      - image: cimg/base:current
    resource_class: small

jobs:
  build:
    executor: base-small
    steps:
      - checkout
      - run: echo "build 完了"
  test:
    executor: base-small
    steps:
      - checkout
      - run: echo "test OK"
  deploy:
    executor: base-small
    steps:
      - checkout
      - run: |
          echo "deploy 開始"
          sleep 30
          echo "deploy 完了"
  release:
    executor: base-small
    steps:
      - checkout
      - run: |
          echo "release 開始"
          sleep 30
          echo "release 完了"

job-groups:
  deploy-and-release:
    jobs:
      - deploy
      - release:
          requires:
            - deploy

workflows:
  job-groups-deploy-serial:
    jobs:
      - build
      - test
      - deploy-and-release:
          serial-group: << pipeline.project.slug >>/deploy-group
          requires:
            - build
            - test

ワークフローを実行すると、グループの前後に CircleCI が serial-start と serial-end という疑似ジョブを自動で挿入します。serial-start は鍵アイコンつきのブロックとして表示され、ここがロックの取得点になります。

完了状態のワークフローグラフでは、build / test の並列実行から serial-start を経由して deploy → release → serial-end が直列で流れる様子が確認できます。

後発パイプラインの割り込みをブロックする

2本のパイプラインを連続で起動して、先発がグループ内のジョブを処理している間に後発が割り込めないことを確認します。

後発の止まっているジョブを開くと、Serial Key・State: Queued・Queue Depth・Queue Position が表示され、どのキーで何番目に並んでいるかが分かります。

旧来の serial-group でも deploy 単体は直列化できましたが、その方式では deploy 完了直後・release 開始前の隙に他パイプラインの deploy が割り込めます。Job Groups で囲うと、serial-end がロックを解放するまでグループの境界が外から見えないため、deploy と release の間に環境状態が変わる余地がなくなります。

Rerun の注意点

deploy の Rerun ボタンを押すと、ドロップダウンに出るのは「Rerun workflow from start」と「Rerun job with SSH」だけで、「Rerun workflow from failed」「Rerun failed tests」はグレーアウトされます。

Changelog にも書かれている通り、グループ内のジョブを単独で Rerun する手段は UI から提供されていません。「Rerun job with SSH」を押すと、選んだジョブだけでなくグループ内の全ジョブが SSH 有効で再実行されます。

「Rerun workflow from start」を押すと build と test から再実行され、serial-start 以降は再度キューに並びます。先発パイプラインの完了済みワークフローと並んで、新しい実行が走り出します。

まとめ

serial-group は単体ジョブしか直列化できず、deploy → release のように「途中で割り込まれたくない一続きの処理」を丸ごと守ることはできませんでした。Job Groups はこの区間を1つのグループとして定義し、グループ全体に serial-group を効かせることで、リリース直後に古いバージョンへ書き戻されるような割り込み事故を防ぎます。ワークフローを分割したり Queue Orb を持ち込んだりせずに、native の設定だけで完結する点が扱いやすいところです。

ただし、グループ内のジョブを単独で Rerun できない、「Rerun job with SSH」がグループ内の全ジョブを SSH モードで再実行する、といった Rerun まわりの制約は後から回避しづらいものです。導入する際は、どのジョブをグループにまとめるか、失敗したときにどう再実行するかを設計段階で決めておくことをおすすめします。