필사 모드: CI/CD システム 2026 完全ガイド - GitHub Actions・Buildkite・CircleCI・GitLab・Jenkins・Argo・Tekton・Earthly・Dagger 徹底解説

はじめに — 2026年5月、CI/CD は「GitHub Actions が勝った」風景になった

2020年時点では CI/CD 市場は多極化していた。エンタープライズは Jenkins、スタートアップは CircleCI、OSS 標準は Travis CI、Buildkite は一部の高難度チームが使う選択肢だった。2026年5月現在、風景はほぼ一方向に収斂した。**GitHub Actions がネットワーク効果で事実上市場を取った。** GitHub にコードを置いていれば Actions を使わない理由を探すほうが難しい。Marketplace には 2 万を超えるアクションがあり、OIDC フェデレーションがあるため AWS/GCP/Azure に長期保管シークレットなしでデプロイできる。

ただしそれですべてが死んだわけではない。**Buildkite は大規模モノレポ + セルフホスト・エージェント市場で圧倒的**(Shopify、Airbnb、Lyft が標準)。**CircleCI は Apple Silicon、ARM、GPU ランナーで優位**を保つ。**GitLab CI/CD は GitLab ユーザーにとって相変わらず第一候補**。Kubernetes ネイティブ領域は **Tekton + Argo Workflows** が押さえ、**Dagger** は「プログラマブル CI」という新カテゴリを育てている最中だ。この記事は 2026年5月時点で誰がどこでどう使っているかを正直に追う。

2026年の CI/CD スタックを 5 つのレイヤーに分解する

CI/CD を単一のツールとして扱うと、比較が必ずズレる。次の 5 レイヤーに分けるのが正確だ。

1. **トリガーとワークフロー定義**: GitHub Actions、GitLab CI、CircleCI、Buildkite、Jenkins、Tekton

2. **実行環境(runner / agent / executor)**: GitHub-hosted、ARC、RunsOn、BuildJet、Namespace、Buildkite agents、K8s Jobs

3. **ビルドシステム**: Bazel、Buck2、Pants、Nx、Turborepo、Earthly、Mill、Make、Gradle

4. **キャッシュ・リモート実行**: Bazel Remote Cache、Turborepo Remote Cache、Nx Cloud、sccache、ccache

5. **配信・オーケストレーション**: Argo CD、Argo Rollouts、Spinnaker、Harness、Octopus、Flux、Vercel、Cloud Run、ECS Service

歴史的に 1 番のツールが 2〜5 をすべて吸収しようとし(Jenkins がまさにそうだった)、結果すべて一つの鍋で崩れていた。2026年のベスト・プラクティスは分離だ。**CI は GitHub Actions、CD は Argo CD、ビルド高速化は Bazel + RBE や Turborepo Remote Cache** という形でレイヤーごとに別ツールを選ぶ。

GitHub Actions — シェア 60% 超の新しい標準

GitHub Actions は 2019年の正式リリース以降、2026年現在 GitHub ユーザーの約 75%、CI/CD 市場全体の 60% 以上を占める(JetBrains DevEcosystem 2025 Survey)。最大の理由は単純で、**GitHub の中にある**ということだ。別 SaaS への登録が要らず、PR とワークフローが同じ画面で見え、Marketplace の 2 万アクションが `uses:` 一行で繋がる。

2026年5月時点での主要機能は次のとおり。

- **Reusable Workflows**: `workflow_call` トリガーでワークフロー全体をモジュール化。組織標準のパイプラインを 1 箇所に置き、100 リポジトリが呼ぶ。

- **Composite Actions**: 複数のステップをひとつのアクションに束ねる。JavaScript/Docker アクションより軽い。

- **OIDC フェデレーション**: クラウドの秘密鍵を持たず、GitHub OIDC トークンを AWS IAM、GCP Workload Identity、Azure Federated Credentials と交換する。

- **Large Runners**: 4、8、16、32、64 vCPU と GPU オプション、Windows/macOS 込み。macOS は M2 Pro ベース。

- **ARC (Actions Runner Controller)**: K8s 上にセルフホスト・ランナーを動的に立ち上げる公式コントローラ。

- **Workflow Templates**: 組織レベルで新規リポジトリに標準ワークフローを自動シード。

OIDC フェデレーション + マトリクス + Reusable Workflow を組み合わせた実戦的なワークフロー例。

name: deploy

on:

push:

branches: [main]

workflow_dispatch:

permissions:

id-token: write

contents: read

jobs:

test:

runs-on: ubuntu-latest-16-cores

strategy:

matrix:

node: [20, 22]

steps:

- uses: actions/checkout@v4

- uses: actions/setup-node@v4

with:

node-version: ${{ matrix.node }}

cache: 'pnpm'

- run: pnpm install --frozen-lockfile

- run: pnpm test

deploy:

needs: test

runs-on: ubuntu-latest

environment: production

steps:

- uses: actions/checkout@v4

- uses: aws-actions/configure-aws-credentials@v4

with:

role-to-assume: arn:aws:iam::123456789012:role/github-actions-deploy

aws-region: ap-northeast-2

- run: aws s3 sync ./dist s3://my-bucket --delete

- run: aws cloudfront create-invalidation --distribution-id $CF_ID --paths '/*'

核心は `permissions.id-token: write` の一行だ。これがあって初めて GitHub OIDC トークンが発行され、`configure-aws-credentials` がそれを AWS STS と交換する。**AWS Access Key はどこにもない。** このパターンが 2024年以降一気に標準となり、2026年では新規システムで PAT/Deploy Key ベースのデプロイはほぼ姿を消した。

GitHub Actions のセキュリティ — SHA ピン vs タグピン、そしてサプライチェーン攻撃

2024年9月の tj-actions/changed-files 事件は GitHub Actions セキュリティの転換点になった。人気アクションが侵害され、呼び出し側全員のシークレットが漏洩した。業界標準は以降次のように固まった。

- **バージョンタグ(`@v4`)ではなくコミット SHA でピン**: `uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1`

- **公式(`actions/*`)以外のアクションは Dependabot/Renovate で定期監査**

- **`permissions:` ブロックをワークフロー/ジョブ単位で明示的に最小化**(デフォルトはもはや `read-all` ではなく空)

- **シークレットは environment にまとめ、承認者付きの保護ルールを設定**

- **`pull_request_target` トリガーは非常に慎重に**(fork PR が main のシークレットに届く)

2026年現在、GitHub はアクションにも "trusted publishers" モデルを適用した。npm/PyPI における OIDC 検証済みパブリッシャー表示と同様に、アクションでも発行者認証と SBOM 添付が表示される。SLSA レベル 3 のアクションは Marketplace で優先表示される。

セルフホスト・ランナー — ARC、RunsOn、BuildJet、Namespace

GitHub-hosted ランナーは便利だが高い。Large 8 vCPU は分あたり約 0.064 USD、64 vCPU GPU は分あたり 0.50 USD 以上だ。月間ビルド時間が 1 万分を超えると、セルフホストで半額以下になる。2026年5月時点の選択肢は次のとおり。

- **ARC (Actions Runner Controller)**: GitHub 公式。K8s クラスタ上にランナー・プールを運用。AutoScaler がジョブキューを見て pod をスケール。エンタープライズ標準。

- **RunsOn.io**: AWS アカウントに EC2 spot プールを自動構成。60 秒以内にランナーが起動、GitHub ラベルでルーティング。GitHub-hosted の 1/8 程度の費用で急速にシェアを伸ばす。

- **BuildJet**: 外部 SaaS。GitHub-hosted と同じインターフェース、ベアメタル ARM/Intel、キャッシュ高速化込み。料金は GitHub の半分前後。

- **Namespace.so**: コンテナのビルド/テスト特化のクラウド。リージョン分散キャッシュで docker pull/push が速い。

ARC を K8s 上に立てる最小 Helm 設定の抜粋。

apiVersion: actions.github.com/v1alpha1

kind: AutoscalingRunnerSet

metadata:

name: linux-large

namespace: arc-runners

spec:

githubConfigUrl: https://github.com/my-org

githubConfigSecret: github-app-secret

minRunners: 2

maxRunners: 80

template:

spec:

containers:

- name: runner

image: ghcr.io/actions/actions-runner:latest

resources:

requests:

cpu: '4'

memory: 8Gi

limits:

cpu: '8'

memory: 16Gi

`maxRunners: 80` を入れておけばキューが詰まっても 80 個までしか立たず、コストが暴走しない。Toss、Woowa Brothers、LINE などは自社 K8s 上に ARC を載せ、月数十万分の CI を GitHub-hosted 比 60% 安く回している。

Buildkite — 大規模モノレポのハイエンド標準

Buildkite はシェアでは GitHub Actions の 1/10 にも満たないが、**大規模エンジニアリング組織では圧倒的優位**だ。Shopify(エンジニア 6,000 人以上)、Airbnb、Lyft、Pinterest が標準にしている。差別化点は次のとおり。

- **エージェントがユーザー側のインフラで動く**(SaaS はメタデータと UI のみ)。コードが Buildkite サーバーに上がることはない。

- **パイプラインを動的に生成**できる。静的な YAML ではなく、`buildkite-agent pipeline upload` でビルド中に新しいステップを発行できる。

- **モノレポと巨大シャーディング実行に最適化**。変更されたパッケージだけビルド/テスト。

- **リトライとフレイク方針をステージ単位で細かく設定**できる。

典型的なパイプライン定義は次のとおり。

steps:

- label: ':go: lint'

command: make lint

agents:

queue: 'linux-amd64'

- wait

- label: ':go: test ({{matrix.shard}}/8)'

command: make test SHARD={{matrix.shard}}

parallelism: 8

matrix:

setup:

shard: [0, 1, 2, 3, 4, 5, 6, 7]

agents:

queue: 'linux-amd64-large'

- wait

- block: 'Deploy to production?'

branches: 'main'

- label: ':rocket: deploy'

command: ./deploy.sh

concurrency: 1

concurrency_group: 'deploy-prod'

`parallelism: 8` は同じコマンドを 8 シャードに分割実行する。`block` は人がボタンを押すまで先に進まない。Shopify は PR ごとに平均 200 ステップ、マトリクス分割後に 6,000 ジョブほどを Buildkite で回している。同じ規模の実行を GitHub Actions で行うのはコスト・キューイング両面で重い。

CircleCI — Apple Silicon・ARM・GPU の強者

CircleCI は 2010年代前半〜中盤の CI/CD 事実上の標準で、2026年には一般市場を GitHub Actions に譲ったが、**特殊ランナーでは依然として第一候補**だ。

- **Apple Silicon (M2 Pro / M3) macOS ランナー**: iOS/macOS ビルドの標準。GitHub-hosted の macOS より安定して速いという評価。

- **ARM Graviton ランナー**: AWS Graviton と同じ ISA でビルド → そのまま ECS Fargate ARM にデプロイ。

- **GPU ランナー**: A100/H100。ML 学習・検証パイプラインを CircleCI に丸ごと載せる。

- **Docker Layer Cache**: 自前のキャッシュレイヤーで docker pull/build を高速化。

config.yml の構造はマトリクス・orb(再利用単位)・共有 executor で GitHub Actions と近いが、**macOS・ARM・GPU プールがより安定**というのが 2026年の市場評価だ。

GitLab CI/CD — GitLab を使うなら第一選択

GitLab CI/CD は別ツールではなく GitLab の一部だ。**`.gitlab-ci.yml` 一枚でビルド、テスト、デプロイ、セキュリティスキャンまで揃う。** GitHub Actions との最大の違いは次のとおり。

- **DAG が明示的**: `needs:` キーワードでジョブ依存をグラフ表現する。

- **Auto DevOps**: 標準パイプラインを自動適用(SAST、DAST、コンテナスキャン、ライセンススキャン)。

- **GitLab Runner**: 一次提供のエージェントが Docker/K8s/Shell/SSH 全てに対応。社内に直接置ける。

- **Pipeline Editor**: Web UI でジョブ依存を視覚的に確認できる。

GitLab Premium/Ultimate ライセンスを持つ組織は、外部 CI を入れる動機がほぼない。だから GitLab CI/CD はシェアで GitHub Actions に劣っても、**GitLab ユーザーの中では 90% 以上を占める**。

Jenkins + JCasC — まだ生きている、ただし新規導入は減った

Jenkins は 2004年に Hudson として始まり、2026年現在も世界の CI インスタンス数では一位だ。ただし **新規導入はほぼない**。既存のインスタンスが「もう抜けないほど深く埋まっている」ため運用されているケースが大半である。

2026年のベストプラクティスは次のとおり。

- **Pipeline as Code (Jenkinsfile)**: UI クリックでジョブを作るのはやめる。Git に `Jenkinsfile` を置く。

- **JCasC (Jenkins Configuration as Code)**: インスタンス自体の設定も YAML に。UI クリック設定はディザスタリカバリの敵。

- **Kubernetes Plugin + Pod templates**: エージェントを静的 VM ではなく動的 K8s pod にする。

- **Shared Libraries**: Groovy ライブラリを別リポジトリに置き、複数ジョブで import。

典型的な宣言的 Jenkinsfile は次のとおり。

pipeline {

agent {

kubernetes {

yaml '''

spec:

containers:

- name: node

image: node:22

command: ["sleep", "infinity"]

'''

}

}

stages {

stage('Install') {

steps { container('node') { sh 'npm ci' } }

}

stage('Test') {

steps { container('node') { sh 'npm test' } }

}

stage('Deploy') {

when { branch 'main' }

steps { sh './deploy.sh' }

}

}

}

銀行、通信、大企業 IT 子会社は 2026年でも Jenkins を運用する。ただし新規チームは GitHub Actions か Argo Workflows で始める。

Tekton — Kubernetes ネイティブ CI/CD 標準

Tekton は K8s 上で CI/CD を一級市民にしたプロジェクトだ。**すべてが K8s CRD(Custom Resource)になっている。** Task、Pipeline、PipelineRun、TaskRun が K8s リソースとして定義され、コントローラが pod で実行する。

2026年における Tekton の立ち位置は明確だ。**ユーザーが直接 Tekton YAML を書くことは稀**で、代わりに Tekton をバックエンドにする上位ツールが標準になった。Jenkins X、Red Hat OpenShift Pipelines、Google Cloud Build、JetBrains Space が内部で Tekton を使う。つまり Tekton は **CI/CD の K8s ランタイム標準**である。

Argo Workflows + Events + Rollouts — Argo エコシステム

Argo は K8s ネイティブ領域で最大のエコシステムを持つ。2026年5月現在、コア・プロジェクトは 4 つある。

- **Argo CD**: GitOps デプロイ(Git → K8s クラスタの reconciliation)。

- **Argo Workflows**: K8s 上のワークフローエンジン(DAG、ステップシーケンス、ML パイプライン)。

- **Argo Events**: イベント → ワークフロー・トリガー(S3、Kafka、GitHub webhook、calendar)。

- **Argo Rollouts**: カナリー・ブルーグリーン・プログレッシブ配信のコントローラ。

Argo Workflows の DAG テンプレート例。

apiVersion: argoproj.io/v1alpha1

kind: Workflow

metadata:

generateName: build-test-deploy-

spec:

entrypoint: main

templates:

- name: main

dag:

tasks:

- name: build

template: run-script

arguments:

parameters: [{name: script, value: 'make build'}]

- name: test

template: run-script

dependencies: [build]

arguments:

parameters: [{name: script, value: 'make test'}]

- name: deploy

template: run-script

dependencies: [test]

arguments:

parameters: [{name: script, value: 'make deploy'}]

- name: run-script

inputs:

parameters:

- name: script

container:

image: alpine:3.20

command: [sh, -c]

args: ['{{inputs.parameters.script}}']

各 task は別 pod として隔離される。GPU ノードや高メモリノードを task ごとに別スケジューリングできる。ML 学習パイプライン、データ ETL、夜間バッチが Argo Workflows の主用途だ。

Argo Rollouts は K8s Deployment の代替としてカナリー配信を YAML で定義する。5% トラフィック → メトリクス検証 → 25% → 50% → 100% を一枚の YAML に書く。Prometheus メトリクスが閾値を超えれば自動ロールバックする。

Earthly と Dagger — ビルドと CI を統合する新カテゴリ

従来の CI は YAML がビルドコマンドを呼び、ビルドコマンドは Makefile/Dockerfile が処理する構造だ。この分離が定番の痛みを生む。**ローカルと CI のビルドが食い違う。** ローカルは速いが CI だけ落ちる。ローカルだけキャッシュがヒットする。

Earthly は Dockerfile + Makefile + CI を `Earthfile` という単一フォーマットにまとめる。

VERSION 0.8

FROM golang:1.23-alpine

WORKDIR /app

deps:

COPY go.mod go.sum .

RUN go mod download

SAVE ARTIFACT /go/pkg/mod /pkg-cache

build:

FROM +deps

COPY . .

RUN go build -o app ./cmd/server

SAVE ARTIFACT app AS LOCAL ./build/app

test:

FROM +build

RUN go test ./...

docker:

FROM alpine:3.20

COPY +build/app /usr/local/bin/app

ENTRYPOINT ["/usr/local/bin/app"]

SAVE IMAGE myorg/app:latest

これをローカルで `earthly +docker` として実行しても、GitHub Actions の一行で CI として実行しても結果が同じだ。キャッシュも BuildKit ベースで一貫する。ローカルと CI が一致するからデバッグが楽になる。

Dagger はさらに一歩進める。ビルド・パイプラインを YAML ではなく **TypeScript/Go/Python のコード** で書く。SDK が BuildKit の上でコンテナをグラフとして実行する。

export class Build {

async test(source: Directory): Promise<string> {

return dag

.container()

.from('node:22-alpine')

.withMountedDirectory('/app', source)

.withWorkdir('/app')

.withExec(['npm', 'ci'])

.withExec(['npm', 'test'])

.stdout()

}

}

CI YAML には `dagger call test --source=.` 一行を置くだけで、実際のパイプラインロジックはコードとして管理される。**CI がテスト可能になる。** 2026年初頭に Dagger はシリーズ B を調達し、Replit、Vercel、Anthropic などが評価導入したという事例が出ている。シェアはまだ小さいが流れは明確だ。

Bazel・Buck2・Pants・Mill — 大規模モノレポのビルドシステム

ビルドシステムのレイヤーは CI と独立だ。同じ GitHub Actions でも、ビルドを `make`、`npm`、`Bazel`、`Buck2` のどれで回すかでビルド時間が 10 倍違う。

- **Bazel**: Google 製のモノレポビルドシステム。BUILD ファイルに正確な入出力を宣言し、変更されたターゲットのみ再ビルド。Remote Build Execution (RBE) でビルドをクラスタ分散。学習コストは高い。

- **Buck2**: Meta 製の Bazel 代替。Rust で再実装し、Bazel 比で評価が 2〜5 倍速い。2023年に OSS 化、2026年にユーザーベースが急増。

- **Pants**: Twitter/Stripe 出身のチームが作った Python/JVM 親和の モノレポビルド。Python モノレポでは事実上の標準。

- **Mill**: Scala のビルドシステム。SBT 代替。よりシンプルなモデルでシェアを伸ばす。

Bazel の BUILD ファイル例(概念のみ)。

load("@rules_go//go:def.bzl", "go_library", "go_test")

go_library(

name = "server",

srcs = ["server.go"],

importpath = "example.com/server",

deps = ["//pkg/db"],

)

go_test(

name = "server_test",

srcs = ["server_test.go"],

embed = [":server"],

)

この宣言があれば Bazel はどのファイル変更がどのターゲットを無効化するかを正確に把握する。1 万ファイルのモノレポで 5 ファイルだけ変更すれば、そのファイルに依存するターゲットだけ再ビルドする。フルビルド 30 分のものが increment ビルドで 30 秒になる。

Nx・Turborepo・sccache — ビルドキャッシュ高速化

Bazel/Buck2 は強力だが学習コストが高い。多くの JS/TS モノレポは Nx か Turborepo を選ぶ。

- **Nx**: Angular CLI チームが作ったモノレポツール。JS/TS が中心で、Python/Java/Go のプラグインまで揃う。**Nx Cloud** がリモートキャッシュと分散実行を提供。

- **Turborepo**: Vercel が買収した Rust ベースのモノレポビルダー。Nx より単純なモデル、`turbo.json` にタスクグラフを定義。**Vercel Remote Cache** は無料。

- **Bazel Remote Cache**: Bazel のリモートキャッシュ。S3/GCS にセルフホストするか、BuildBuddy や EngFlow などの SaaS を使う。

- **sccache**: Mozilla 製の C/C++/Rust コンパイラキャッシュ。ccache の分散版。

- **Rust + sccache + S3**: Rust ビルドの事実上の標準組み合わせ。ビルド時間を 1/3 以下にする。

3 ツールの比較は次のとおり。

| ツール | 言語範囲 | リモートキャッシュ | 分散実行 | 学習コスト | モノレポ規模 |

|---|---|---|---|---|---|

| Bazel + RBE | 全言語 | 自前/SaaS | あり | 高い | 1 万+ ファイル |

| Buck2 | 全言語 | Bazel 互換 | あり | 高い | 1 万+ ファイル |

| Nx + Nx Cloud | JS/TS 中心 + プラグイン | SaaS | あり (Cloud) | 中 | 100〜5,000 ファイル |

| Turborepo + Vercel Cache | JS/TS | SaaS(無料) | 予定 | とても緩やか | 100〜3,000 ファイル |

| sccache | C/C++/Rust | S3/GCS | なし | とても緩やか | コンパイラキャッシュ |

2026年5月時点のトレンドは明確だ。**新規 JS モノレポは Turborepo から**、規模が膨らめば Nx Cloud、それでも足りなければ Bazel に移行する。

Spinnaker・Harness・Octopus・Codefresh — エンタープライズ CD

Argo CD が GitOps の事実上の標準になったが、エンタープライズ CD は独立した市場として残っている。

- **Spinnaker**: Netflix 製のマルチクラウド CD。2014年リリース後一時は標準だったが運用複雑度が高く、2026年は新規導入が減った。既存ユーザー(Netflix、Salesforce、Google)は維持。

- **Harness**: 商用 CD プラットフォーム。ML ベースのカナリー検証、コストインサイト、フィーチャーフラグ、セキュリティテスト統合まで揃う。Drone CI を買収して CI まで吸収。

- **Octopus Deploy**: Windows/.NET 陣営の CD 強者。IIS、SQL Server、Active Directory 環境に親和的。

- **Codefresh**: Argo の上に商用 UI と運用機能を載せた SaaS。CNCF 親和。

新規 K8s ネイティブワークロードは Argo CD、Windows・ハイブリッドは Octopus、マルチクラウド + ポリシー中心は Harness が一般的選択だ。

Codeship・Travis CI・Drone — 消えた、または消えつつある

CI 市場は短期間でも大きく動く。2026年5月時点で次のツールは新規推奨対象から外れている。

- **Travis CI**: 2010年代の OSS 標準。2020年の利用ポリシー変更後シェアが急落。2026年にはほぼ見かけない。

- **Codeship**: CloudBees に買収後、2021年に実質サンセット。新規登録は不可。

- **Drone CI**: Harness 買収後、Drone 2.x は保守モード。後継の **Gitness**(Harness の OSS SCM + CI)が登場したがシェアは小さい。

これらにロックインされた既存ユーザーは、2026年は移行計画を立てるのが標準だ。

Bitrise・Codemagic — モバイル特化 CI

iOS/Android アプリビルドは一般の CI と異なる制約が多い。macOS ランナー必須、コード署名、App Store/Play Store アップロード、シミュレータやデバイスの多様なマトリクス。この領域ではモバイル特化 CI が圧倒的だ。

- **Bitrise**: 最大のモバイル CI。M2 macOS ランナー、署名管理、Firebase Test Lab 連携まで完備。

- **Codemagic**: Flutter 親和的。Flutter チームが公式に推奨。iOS/Android/Web/Desktop をひとつの YAML で。

一般バックエンドは GitHub Actions、モバイルアプリは Bitrise/Codemagic を併用する組織が多い。

TeamCity・Bamboo・Semaphore — ニッチの強者

JetBrains TeamCity は .NET/Java 中心エンタープライズに強く、IDE(IntelliJ)統合が最も滑らかだ。Atlassian Bamboo は Jira/Confluence と束ねたパッケージで一部組織が運用中だが、Atlassian は 2024年以降 Bitbucket Pipelines に重心を移している。Semaphore CI は Apple Silicon + 高速起動を売りにする SaaS。いずれも一般市場は GitHub Actions に譲ったが、特定文脈では生きている。

DORA メトリクス — 2026年の平均はどこか

DORA(DevOps Research and Assessment)の 4 指標は 2026年でも業界標準だ。

- **デプロイ頻度**: どれだけ頻繁にデプロイするか。

- **変更リードタイム**: マージから本番までの時間。

- **変更失敗率**: 事故を起こしたデプロイの割合。

- **MTTR (Mean Time to Restore)**: 事故時の復旧時間。

2025 State of DevOps Report のサマリー(2026年5月発表)は次のとおり。

| ティア | デプロイ頻度 | リードタイム | 失敗率 | 復旧時間 |

|---|---|---|---|---|

| Elite | 1 日に複数回 | 1 時間以内 | 0〜5% | 1 時間以内 |

| High | 週 1〜月数回 | 1 日〜1 週間 | 5〜10% | 1 日以内 |

| Medium | 月 1〜四半期 | 1 週間〜1 ヶ月 | 10〜15% | 1 日〜1 週間 |

| Low | 四半期以下 | 1〜6 ヶ月 | 15%+ | 1 週間以上 |

全回答者中 Elite は約 18%、High は 30%、Medium は 35%、Low は 17%。2024年比で Elite の比率は 4 ポイント増、最大の差は **テスト自動化のカバレッジと PR マージ自動化の深さ** だった。平均ビルド時間は 8〜15 分が最多帯で、Elite グループは 5 分未満が多い。

韓国 — Toss、Coupang のエンジニアリング生産性

韓国ビッグテックの 2026年 CI 風景は次のとおり。

- **Toss**: GitHub Enterprise + GitHub Actions + ARC(セルフホスト)。モノレポは一部 Bazel/Turborepo の併用。K8s デプロイは Argo CD。社内には GitHub Actions の上に乗る「Toss CI」抽象レイヤーがある。

- **Coupang**: エンジニアリング生産性チームが社内 Buildkite ライクなシステムを運用(元 Jenkins → 自社システム)。ビルドキャッシュは Bazel RBE ベース。コンテナイメージのキャッシュノードをリージョン別に配置。

- **Kakao**: 社内 Krew CI と GitHub Actions の併用。新規は Actions 優先。

- **Naver**: GitHub Enterprise + Actions が標準。ML パイプラインに Argo Workflows を使うチームもある。

- **Woowa Brothers**: GitHub Actions + ARC。K8s は EKS + Argo CD。

- **Daangn(Karrot)**: GitHub Actions + Argo CD が標準コンボ。

共通点は **CI は GitHub Actions、CD は Argo CD、ビルド高速化はモノレポツール** という 3 軸構成だ。

日本 — Mercari、CyberAgent、Cookpad

日本も GitHub Actions に急速に収束しているが、ディテールは異なる。

- **Mercari**: GitHub Actions + ARC + Argo CD。モノレポは一部 Bazel。CI インフラチームが独立した組織として強い。

- **CyberAgent**: 社内で「CI culture」という表現を使うほど CI/CD を文化として強調。GitHub Actions + GKE + Argo CD。ゲーム事業部は別途 Jenkins + UnrealEngine ビルドジョブを維持。

- **Cookpad**: 2010年代は Jenkins 標準、2020年代に CircleCI、2024年から GitHub Actions + ARC に移行中。

- **DeNA、GREE、楽天**: Jenkins レガシーが厚いが、新規は Actions/GitLab CI。

- **LINE**: 社内標準 GitHub Enterprise + Actions + ARC。モノレポは一部 Buck2 を評価中。

日本は韓国より Jenkins レガシーが厚く、移行はより長期で進む。

GitHub Codespaces Prebuilds、Vercel Preview、Devbox、Garden — 隣接領域

CI/CD と隣接するツールは、2026年には CI/CD ワークフローと不可分なレベルで統合されている。

- **GitHub Codespaces Prebuilds**: PR 作成時にあらかじめビルドされた dev コンテナが立ち上がる。コードレビューが「環境構築 30 分待ち」から「30 秒で IDE に入る」に変わった。

- **Vercel Preview Deployments**: PR ごとに別 URL の本番同等環境が自動デプロイされる。デザイナーや PM がマージ前に確認する。Next.js 陣営の事実上の標準パターン。

- **Devbox (Jetpack.io)**: Nix ベースの再現可能な dev 環境ツール。CI でも同じ環境を保証。

- **Garden.io**: K8s 開発環境を PR 単位で自動生成。dev/preview/prod を一つのグラフで見る。

これらは単独 CI ではないが、CI/CD ワークフローの一部として組み込まれる。マージ前に人が見る環境と、マージ後に自動配信される環境が同じパイプラインで扱われる。

ベンダー比較表 — 一目でわかる 2026 年の CI/CD

全ツールを利用文脈別に比較すると次のようになる。

| ツール | カテゴリ | 主用途 | 料金 | セルフホスト |

|---|---|---|---|---|

| GitHub Actions | CI/CD | GitHub ユーザー全般 | 分課金 + 無料枠 | ARC で可能 |

| Buildkite | CI | 大規模モノレポ | ユーザー単位 SaaS | エージェントは設計上セルフホスト |

| CircleCI | CI/CD | macOS/ARM/GPU | クレジット制 | 一部可能 |

| GitLab CI/CD | CI/CD | GitLab ユーザー | GitLab ライセンス | 完全可能 |

| Jenkins | CI/CD | 既存エンタープライズ | OSS | 100% セルフホスト |

| TeamCity | CI/CD | JetBrains/.NET | ユーザー/エージェント | 100% セルフホスト |

| Tekton | CI/CD | K8s ネイティブ | OSS | K8s 上でセルフホスト |

| Argo Workflows | ワークフロー | ML/バッチ/CI | OSS | K8s 上でセルフホスト |

| Argo CD | CD | K8s GitOps | OSS | K8s 上でセルフホスト |

| Spinnaker | CD | マルチクラウド | OSS | 運用負荷大 |

| Harness | CD/CI | エンタープライズ統合 | SaaS | 一部可能 |

| Octopus | CD | Windows/.NET | ライセンス | セルフホスト可 |

| Bitrise | CI | モバイル | SaaS | 不可 |

| Codemagic | CI | Flutter/モバイル | SaaS | 不可 |

| Earthly | ビルド | ローカル CI 一致 | OSS + Cloud | OSS はセルフホスト |

| Dagger | ビルド/CI | プログラマブル CI | OSS + Cloud | OSS はセルフホスト |

ツール選定は単一軸では終わらない。**チーム規模、SCM の所在、モノレポか否か、K8s 浸透度、セルフホスト方針** の 5 軸が同時に決める。

マイグレーション戦略 — Jenkins/Travis から GitHub Actions へ

既存の Jenkins/Travis CI を GitHub Actions に移すときの 2026年のベストプラクティスは次のとおり。

1. **まず棚卸し**: 現状のジョブ一覧、トリガー、シークレット、自前スクリプトの所在を表にする。

2. **Reusable Workflow で抽象化**: 100 リポジトリが同一パターンなら、組織レベルの Reusable Workflow 1 本に圧縮する。

3. **OIDC でシークレットを廃止**: 新ワークフローは最初から OIDC フェデレーション。PAT/AccessKey を作らない。

4. **セルフホスト判断**: 月間ビルド時間 1 万分超なら ARC/RunsOn を検討。

5. **段階移行**: 一気に切らず、新規ジョブから Actions、既存は Jenkins に残しつつ徐々に。

6. **メトリクスで検証**: DORA 4 指標を移行前後で測る。「良くなった気がする」ではなく数字。

多くの組織がこの 6 ステップを 1〜2 年かけて進める。一度に全ジョブを切ると、ほぼ失敗する。

おわりに — 2026年の CI/CD 選択 3 原則

最後に大局を整理する。

1. **CI と CD を分離せよ。** 一つのツールで全部をやろうとすると両方が中途半端になる。CI は GitHub Actions(あるいは Buildkite/CircleCI)、CD は Argo CD/Harness/Spinnaker のように分ける。

2. **ビルドシステムに投資せよ。** CI をいくら速いツールに替えても、ビルド自体が 30 分なら 30 分のままだ。Bazel/Buck2/Nx/Turborepo + リモートキャッシュこそ本当の高速化。

3. **セキュリティは OIDC、ピンは SHA、権限は最小化。** 2024年の tj-actions 事件が示すように、CI はサプライチェーン攻撃の第一の標的だ。SHA ピンと OIDC と最小権限は 2026年新規システムのデフォルト。

GitHub Actions が事実上市場を取ったのは明白だが、「みんな GitHub Actions を使う」が正解ではない。Shopify は Buildkite、ML チームは Argo Workflows、モバイルチームは Bitrise、K8s ネイティブチームは Tekton のほうが合うかもしれない。要点は **レイヤーを分け、各レイヤーで最適なツールを選び、メトリクスで判断する** という原則だ。

References

- GitHub Actions Docs: [docs.github.com/actions](https://docs.github.com/en/actions)

- Buildkite Docs: [buildkite.com/docs](https://buildkite.com/docs)

- CircleCI Docs: [circleci.com/docs](https://circleci.com/docs)

- GitLab CI/CD Docs: [docs.gitlab.com/ee/ci](https://docs.gitlab.com/ee/ci/)

- Jenkins Docs: [jenkins.io/doc](https://www.jenkins.io/doc/)

- Tekton: [tekton.dev](https://tekton.dev/)

- Argo Project: [argoproj.github.io](https://argoproj.github.io/)

- Earthly: [earthly.dev](https://earthly.dev/)

- Dagger: [dagger.io](https://dagger.io/)

- Nx: [nx.dev](https://nx.dev/)

- Turborepo: [turbo.build](https://turbo.build/)

- Bazel: [bazel.build](https://bazel.build/)

- DORA: [dora.dev](https://dora.dev/)

- Actions Runner Controller: [github.com/actions/actions-runner-controller](https://github.com/actions/actions-runner-controller)

- SLSA Framework: [slsa.dev](https://slsa.dev/)