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 の上でコンテナをグラフとして実行する。

import { dag, Container, Directory } from '@dagger.io/dagger'

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 ツールの比較は次のとおり。

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 は約 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

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

ツール選定は単一軸では終わらない。チーム規模、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
• Buildkite Docs: buildkite.com/docs
• CircleCI Docs: circleci.com/docs
• GitLab CI/CD Docs: docs.gitlab.com/ee/ci
• Jenkins Docs: jenkins.io/doc
• Tekton: tekton.dev
• Argo Project: argoproj.github.io
• Earthly: earthly.dev
• Dagger: dagger.io
• Nx: nx.dev
• Turborepo: turbo.build
• Bazel: bazel.build
• DORA: dora.dev
• Actions Runner Controller: github.com/actions/actions-runner-controller
• SLSA Framework: slsa.dev