GitHub Actionsのstep並列実行｜job分割せずCIを速くする判断基準¶

対象 / ポイント

対象: GitHub ActionsでCIを運用し、複数buildやテストの待ち時間を縮めたい開発者・基盤担当者。

ポイント:

step並列はrunner追加ではなく、同じjob内で独立処理を並べる構文である
job分割は分離、parallel / background はworkspace共有に向く
AI自動PRでは検証ループ短縮に効くが、入力・権限・secret設計とセットで扱う

frontend、backend、docsのbuildを1つのjobで順に待つCIは珍しくない。 3つが独立していても、従来のstepは基本的に前のstepが終わるまで次へ進めなかった。 2026年6月25日、GitHub Actionsはこの制約を緩め、job内のstep並列実行を正式に追加した。¹²

この記事の問いは1つだ。GitHub Actionsのstep並列は、job分割と何が違い、どのCIに入れるべきなのか。

何が変わったのか¶

変化の本質は、並列化の単位がjobだけではなくなった点にある。これまでもmatrixや複数jobで並列化はできた。ただし、別jobに分けるとcheckout、依存関係、workspace、ローカルcacheは分かれる。

たとえば、次のbuildは直列で待っていた。

- run: npm run build:frontend
- run: npm run build:backend
- run: npm run build:docs
- run: npm test

3つのbuildが互いに独立しているなら、今はこう書ける。

- parallel:
    - run: npm run build:frontend
    - run: npm run build:backend
    - run: npm run build:docs

- run: npm test

parallel は、各stepをbackground実行し、最後に待ち合わせる糖衣構文だ。今回増えたのは「jobを分けるほどではないが、直列で待つ必要もない処理」を、 Actionsの管理下で並べる手段である。

4つのキーワードは何をするのか¶

追加された構文は、シェルの & と wait の考え方をActionsのstepに持ち込んだものだ。違いは、ログ、終了状態、cleanupをActions側で扱える点にある。¹²³

キーワード	役割
`background: true`	stepを非同期で起動し、jobを次のstepへ進める
`wait` / `wait-all`	指定したbackground step、または全background stepの完了を待つ
`cancel`	長寿命のbackground stepを停止する
`parallel`	step群を並列実行し、全完了後に次へ進む

テスト用サーバーを横で起動する例は分かりやすい。

- name: Start app
  id: app
  run: npm start
  background: true

- run: ./scripts/wait-ready.sh
- run: npm run test:e2e

- name: Stop app
  cancel: app

注意点は、background: true が「プロセスを起動した」ことしか意味しないことだ。アプリケーションがreadyかどうかは別問題なので、health checkやwait-readyは残る。

また、同一job内で同時に走れるbackground stepは最大10個だ。大量の処理を無制限に詰め込む機能ではない。 runnerを過負荷にしない範囲でのstepオーケストレーションとして読む方がよい。²

jobで分けるか、stepで並べるか¶

判断軸は単純だ。分離したいならjob、共有したいならstep並列である。

並列の手段	向いているケース
別job / matrix	OS違い、言語バージョン違い、runner違い、権限分離、失敗影響の分離
同一job内 `parallel`	同じcheckout、依存関係、workspace、ローカルcacheを共有したい処理
`background`	サーバー、DB、mock、監視など、横で動かし続ける処理

別jobに分けると、artifactのupload/downloadや依存関係の再構築が必要になりやすい。だから、同じ依存関係を使う軽いbuildや静的解析はstep並列に向く。

逆に、権限を分けたいdeploy、OS別検証、大きなCPU負荷を食うテストはjob分割が自然だ。同じrunnerでCPUを奪い合う処理を並べても、wall-clock timeは縮まらない。

速くならないケース¶

step並列はrunnerを増やす機能ではない。同じrunnerのCPU、memory、disk I/Oを複数stepで共有するだけだ。

入れる前に見るべき指標は4つある。

wall-clock time: PRの待ち時間が実際に減ったか
CPU / memory / I/O: 同一runner内で詰まっていないか
p95 / p99: 平均ではなく遅いケースが悪化していないか
flaky test: 並列化で不安定化していないか

特に危ないのは、同じ dist/、build/、target/ に書く処理を並べることだ。workspaceを共有できる利点は、そのまま競合リスクにもなる。

構文の増加自体も保守コストを持つ。 2026年のGitHub Actions言語研究は、260K件のworkflowと49Kリポジトリを分析した。研究対象時点で197の言語構成要素を整理し、 workflowが複雑になるほど失敗率や保守負荷が上がる傾向も示している。⁴

parallel は便利だが、YAMLを小さな非同期プログラムに変える。依存関係、書き込み先、wait漏れ、cancel漏れをレビュー観点に入れる必要がある。

AIエージェント開発では何が効くのか¶

AIコーディングエージェントや自動PRが増えると、律速は「コードを書く時間」から「検証して戻す時間」へ移る。エージェントが修正を投げるたびに、 lint、typecheck、unit test、security scan、build、E2Eが走るからだ。

step並列は、この検証ループの待ち時間を縮める土台になる。同じ依存関係を使うtypecheck、lint、軽いbuildを同一job内で並べられれば、失敗ログを早く返せる。エージェントの再修正も、人間のレビューも前に進みやすくなる。

ただし、高速化だけを見てはいけない。 GitHubは2026年6月にAgentic Workflowsをpublic previewとして公開し、 Actions上でagentを動かす流れを強めている。⁵ 一方で、2026年のAgentic Workflow Injection研究は、 13,392件のagentic workflowから519件の潜在的脆弱性を見つけた。そのうち496件が攻撃可能、343件が未知のゼロデイだったと報告している。⁶

つまり、step並列で検証を速くするほど、agentに渡す入力、Actions tokenの権限、 secretの露出、後続stepへの出力伝播も同時に見直す必要がある。

まとめ¶

最初にやることは、YAMLを書き換えることではない。各stepが何を読むか、何を書くか、どの権限を使うかを表にすることだ。

小さく始めるなら、次の順が安全である。

lint、typecheck、docs buildなど、読み取り中心のstepを候補にする
書き込み先が重なる処理を除外する
before / afterでwall-clock timeとflaky testを測る
サーバー起動は background と cancel を必ず対にする
agentが生成した出力を実行するstepは、権限と入力検証を別に設計する

この機能の価値は、CIを魔法のように速くすることではない。job分割とstep直列の間に、共有状態を保ったまま並べる選択肢が増えたことにある。

AIエージェントがPRを増やすほど、CIは単なるゲートではなくなる。修正ループの速度を決めるフィードバック装置になる。 step並列はその装置を少し短くできる。ただし、短くしたパイプラインに何を流すかは、workflow設計者の責任として残る。