メインコンテンツまでスキップ

GitHub Actions コンピューティングリソースと並列実行

デフォルトランナーのスペック​

GitHub Actions では、GitHub ホステッドランナー（GitHub が管理するクラウド VM）がデフォルトで利用可能です。

標準ランナー（Standard Runners）​

ラベルOSvCPURAMストレージアーキテクチャ
ubuntu-latest / ubuntu-24.04Ubuntu 24.04 LTS416 GB14 GB SSDx86_64
ubuntu-22.04Ubuntu 22.04 LTS416 GB14 GB SSDx86_64
windows-latest / windows-2022Windows Server 2022416 GB14 GB SSDx86_64
macos-latest / macos-15macOS 1537 GB14 GB SSDARM64 (M1)
macos-13macOS 13414 GB14 GB SSDx86_64 (Intel)

注意: ubuntu-latest が最も高コスパで、CI/CDの主力として使われます。macOS ランナーは消費分数の倍率が高くなります（後述）。

分数消費の倍率​

GitHub Actions の無料枠・有料枠は 分数（minutes） を消費しますが、OS によって倍率が異なります。

OS倍率
Linux1×
Windows2×
macOS (Intel)10×
macOS (ARM64)5×

プランごとの並列実行上限​

同時実行ジョブ数（Concurrent Jobs）​

GitHub ホステッドランナーを使う場合、同時に実行できるジョブ数はプランによって決まります。

プランLinux/Windows 並列数macOS 並列数
Free205
Pro405
Team6050
Enterprise500（デフォルト。増加申請可）50
パブリックリポジトリ無制限（実質）無制限（実質）

パブリックリポジトリは GitHub によって無償提供されており、上限の制約がほぼありません。

セルフホステッドランナーの並列数​

セルフホステッドランナーを使う場合、同時実行数は 登録したランナーの台数 に依存します。プランによる上限はありません。

並列化の仕組み​

Matrix Strategy（マトリクス戦略）​

最も簡単な並列化手法です。変数の組み合わせごとにジョブを生成します。

jobs:
  test:
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest]
        node: [18, 20, 22]
      max-parallel: 4       # 同時実行数を制限（省略時は全組み合わせを並列実行）
      fail-fast: false      # 1つ失敗しても他を継続
    runs-on: ${{ matrix.os }}
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node }}
      - run: npm test
  • 最大 256 ジョブ まで 1 つのマトリクスで生成可能
  • include / exclude で特定の組み合わせを追加・除外できる

ジョブ間の並列実行​

同じワークフロー内の複数ジョブは、needs で依存関係を指定しない限り デフォルトで並列実行されます。

jobs:
  lint:
    runs-on: ubuntu-latest
    steps: [...]

  unit-test:
    runs-on: ubuntu-latest
    steps: [...]

  build:
    needs: [lint, unit-test]   # lint と unit-test が両方完了してから実行
    runs-on: ubuntu-latest
    steps: [...]

Concurrency（同時実行制御）​

同一ブランチやPRで複数のワークフローが走らないよう制御できます。

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true   # 新しい実行が来たら古いものをキャンセル

リソースを強化する方法​

1. ラージランナー（Large Runners）​

GitHub が提供するスペックアップ済みのホステッドランナーです。Team または Enterprise プランが必要です。

Linux ラージランナー​

vCPURAMストレージ
416 GB14 GB
832 GB300 GB
1664 GB300 GB
32128 GB2.9 TB
64256 GB2.9 TB

Windows ラージランナー​

Linux と同等スペックで提供（4〜64 vCPU）。

GPU ランナー​

NVIDIA Tesla T4 GPU を搭載したランナーも利用可能（Enterprise プラン）。

jobs:
  heavy-build:
    runs-on: ubuntu-latest-16-cores   # 16 vCPU ラージランナー
    steps:
      - uses: actions/checkout@v4
      - run: make build

ラージランナーのラベルは Organization の Settings > Actions > Runners から作成・管理します。

2. セルフホステッドランナー（Self-Hosted Runners）​

自社インフラや任意のクラウドVM上に GitHub Actions ランナーをインストールして使う方式です。

メリット

  • スペックを自由に設定できる（専用物理サーバーも可）
  • 社内ネットワークのリソース（データベース、プライベートレジストリ等）に直接アクセス可能
  • 長時間のビルドでも GitHub の分数制限を消費しない

デメリット

  • インフラの維持・管理コストが発生する
  • セキュリティ管理が必要（パブリックリポジトリへの使用は非推奨）
jobs:
  build:
    runs-on: self-hosted         # デフォルトのセルフホステッドランナー
    # または
    runs-on: [self-hosted, linux, x64, high-memory]   # ラベルで絞り込み

ACA Job を使ったエフェメラルセルフホステッドランナー​

Azure Container Apps Jobs を活用してジョブ実行時のみランナーを起動する手法については、ACA Job セルフホステッドランナーを参照してください。

3. Docker Build Cloud との組み合わせ​

ビルドの時間的ボトルネックがDockerイメージのビルドにある場合、Docker Build Cloud と組み合わせることで、ランナー側のスペックに依存せずビルドを高速化できます。

ベストプラクティス​

キャッシュの活用​

依存関係のダウンロード時間はキャッシュで大幅に短縮できます。

- uses: actions/cache@v4
  with:
    path: ~/.npm
    key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
    restore-keys: |
      ${{ runner.os }}-node-
エコシステムキャッシュパスキー候補
npm~/.npmpackage-lock.json のハッシュ
NuGet (.NET)~/.nuget/packages*.csproj のハッシュ
pip (Python)~/.cache/piprequirements.txt のハッシュ
Docker layers/tmp/.buildx-cacheDockerfile のハッシュ

ジョブの分割と並列化​

# 悪い例: 全部直列
lint → unit-test → integration-test → e2e-test → build → deploy

# 良い例: 独立したものは並列
lint ─┐
      ├→ build → deploy
unit-test ─┘
integration-test（別ジョブ、並列）

タイムアウトの設定​

デフォルトタイムアウトは 6 時間です。想定時間より少し長めに設定して暴走を防ぎます。

jobs:
  build:
    timeout-minutes: 30

ランナーの選択指針​

ケース推奨ランナー
通常の CI（テスト・Lint・ビルド）ubuntu-latest（安価・高速）
Windows アプリのビルド・テストwindows-latest
iOS/macOS アプリのビルドmacos-latest
大量メモリが必要（ML・大規模ビルド）ラージランナー（16〜64 core）
社内リソースへのアクセスが必要セルフホステッドランナー
Docker ビルド高速化Docker Build Cloud と組み合わせ

セキュリティ​

  • パブリックリポジトリにセルフホステッドランナーを使わない（フォークからの悪意あるコード実行リスク）
  • シークレットはリポジトリ・Organization・Environment の Secrets に保存する
  • permissions で GITHUB_TOKEN の権限を最小化する
permissions:
  contents: read
  pull-requests: write

Azure DevOps パイプラインとの比較​

GitHub Actions と Azure DevOps Pipelines は似た概念を持ちますが、コンピューティングリソースの設計思想に違いがあります。

Microsoft ホステッドエージェントのスペック​

項目GitHub Actions（標準）Azure DevOps（標準）
VM サイズStandard DS2_v2 相当（実質4 vCPU / 16 GB）Standard DS2_v2（2 vCPU / 7 GB RAM）
Linuxubuntu-latest: 4 vCPU / 16 GBubuntu-latest: 2 vCPU / 7 GB
Windows4 vCPU / 16 GB2 vCPU / 7 GB
macOS3〜4 vCPU / 7〜14 GB3 vCPU / 14 GB（追加料金）
ストレージ14 GB SSD10 GB SSD

GitHub Actions の方がデフォルトスペックが高い（4 vCPU / 16 GB vs 2 vCPU / 7 GB）。

並列実行の考え方​

項目GitHub ActionsAzure DevOps
並列単位ジョブ（Job）パイプライン実行（Pipeline Run）
並列数の管理プランに紐づく同時実行ジョブ数パラレルジョブ（Parallel Jobs） を別途購入
無料枠Free: 2,000 分/月 + 20 並列パブリック: 無制限、プライベート: 1 並列のみ（無料）
追加料金プランアップグレードまたはラージランナーパラレルジョブを $40/月/並列 で追加購入

Azure DevOps では「並列ジョブ数」が課金の主軸であり、チームの規模に合わせて明示的に購入する必要があります。GitHub Actions はプランに含まれる並列数が多く、スタートしやすい設計です。

エージェント・ランナーの管理​

項目GitHub ActionsAzure DevOps
ホステッドランナーの管理単位ランナーグループ（Organization または Enterprise）エージェントプール（Organization または Project）
セルフホステッドの追加リポジトリ / Organization / Enterprise に登録エージェントプールに登録
スケールアウトラージランナー or セルフホステッドを増設スケールセット エージェント（VMSS）で自動スケール
エフェメラル化ACA Job や ephemeral runner actions で実現VMSS エージェントでジョブ単位のインスタンス起動

YAML の比較​

# GitHub Actions
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: dotnet build
# Azure DevOps Pipelines
jobs:
  - job: Build
    pool:
      vmImage: ubuntu-latest
    steps:
      - checkout: self
      - script: dotnet build

構造は酷似していますが、GitHub Actions は uses（Action）、Azure DevOps は task（Task）でエコシステムが異なります。

どちらを選ぶか​

優先事項推奨
GitHub でコードを管理しているGitHub Actions（統合がシームレス）
Azure リソースとの連携が多いAzure DevOps（サービス接続・環境管理が充実）
無料の並列数を重視GitHub Actions（無料プランで20並列）
エンタープライズガバナンスAzure DevOps（プロジェクト・チーム・承認フローが細かく管理可能）
スペックの高いホステッドランナーGitHub Actions（デフォルトで4vCPU/16GB）

まとめ​

GitHub Actions コンピューティングリソース概要

デフォルト: ubuntu-latest = 4 vCPU / 16 GB RAM
並列上限:   Free=20, Pro=40, Team=60, Enterprise=500
並列化手段: マトリクス戦略 / ジョブ並列 / concurrency 制御
強化方法:   ラージランナー（4〜64 vCPU）/ セルフホステッドランナー
コスト削減: キャッシュ活用 / タイムアウト設定 / 適切なOSの選択

GitHub Actions は「すぐに使えて高スペック」な点が強みで、Azure DevOps は「プロジェクト管理と承認フローの細かい制御」が強みです。両者を組み合わせて使うこともでき、GitHub でコードを管理しながら Azure Pipelines でデプロイする構成も一般的です。