Skip to content
Published on

CI/CD プラットフォーム 2026 — GitHub Actions / GitLab CI / CircleCI / Buildkite / BuildJet / Earthly / Dagger 徹底比較

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

プロローグ — 2026年になぜ再びCI/CDか

2022年ごろ、日本や韓国の開発チームに「どのCIを使ってますか」と聞けば、答えは比較的単純だった。スタートアップは GitHub Actions、中堅以上は Jenkins、モバイルは Bitrise、IaC は Atlantis か自前スクリプト。2026年の同じ質問に対する答えは長くなる。「GitHub Actions を使ってますが、ランナーは BuildJet に切り替えました。Docker ビルドは Depot に分離し、モノレポのビルドキャッシュは BuildBuddy に飛ばしてます」というふうに。大きな組織になると、「メインパイプラインは Buildkite、データパイプラインの一部は Argo Workflows、Terraform は Spacelift に分けてます」という答えになる。

この変化は偶然ではない。3つの流れが同時に起きた。

  1. ランナーがボトルネックになった。 AIによるコード生成で PR 数が2〜3倍になり、テストはどんどん重くなり、GitHub の標準ランナーではついていけない。BuildJet・Depot・Namespace のような「より速いランナー」市場が生まれた。
  2. ビルドパイプライン自体がコンテナとコードに移った。 YAMLマトリックス地獄からの脱出は、Earthly・Dagger で形になった。同じパイプラインがローカル・CI・別のCIで同じように動く。
  3. Kubernetes がデータ・ML ワークロードまで飲み込んだ。 Argo Workflows・Tekton がデータエンジニアリング領域までCIを広げた。CI とワークフローオーケストレーションの境界がぼやけた。

本稿は2026年5月時点で20以上のCI/CDツールを同じ軸で整理する。問いは「どれが良いか」ではなく、**「どの条件でどれが合うか」**だ。価格と機能の数字は急速に変わるため、構造的な違いに集中する。

モデルが収束すればハーネスが差をつくる — AIコーディングツールで言ったことが、CIにも同じく当てはまる。ランナーが収束すれば、ビルドキャッシュ・並列性・観測可能性が差をつくる。

第1章 · 2026年のCI/CDマップ — 4分類

20以上のツールを一度に比較することはできない。まず大きな4分類に分け、その中で詳しく見ていく。

A. マネージド SaaS CI(ホスト型ランナー込み) GitHub Actions、GitLab CI/CD、CircleCI、Travis CI(衰退)、Cirrus CI。SaaS ベンダーがランナー・コントロールプレーン・課金まですべて持つ。セットアップは速いが、コストカーブが急になる。このカテゴリの事実上の標準は GitHub Actions。

B. セルフホスト / ハイブリッド CI Buildkite、Jenkins、Drone、Cirrus(一部)。コントロールプレーンは SaaS かセルフホストだが、ランナーは自社インフラ(EC2、GKE、オンプレ)。セキュリティ・コスト・ハードウェア制御が必要なチームの選択肢。

C. k8s ネイティブ / パイプラインコンピュート Argo Workflows、Tekton、Namespace、Drone の一部。CI を Kubernetes 上で動かすことに一級対応。データ・ML・インフラワークフローとの境界が曖昧。

D. ドメイン特化 モバイル — Bitrise、Codemagic。IaC — Spacelift、Garnix、Cycloid。モノレポビルドキャッシュ — Bazel + Buildbarn / BuildBuddy / EngFlow。依存関係更新 — Renovate、Dependabot、Mend。

上記カテゴリを横断する 「加速レイヤー」 が別にある。BuildJet・Depot・Namespace は GitHub Actions と併用してランナーだけを差し替える。2024〜2026年の市場で最も顕著な変化はこれだ。

最後に、ビルドシステム vs CI システム の区別を忘れてはいけない。Bazel・Earthly・Dagger はビルドシステムに近く、GitHub Actions・Jenkins・Buildkite はオーケストレーター。2つのレイヤーは互いに置き換えない。共存する。Bazel ビルドを GitHub Actions がトリガーし、EngFlow がキャッシュする。

第2章 · GitHub Actions — 事実上の標準

サーフェスと強み GitHub リポジトリに .github/workflows/ci.yml を置けば終わり。2026年5月時点で OSS リポジトリの圧倒的多数がここで動く。マーケットプレースには数万のアクションがあり、事実上の標準ビルドアクション(actions/checkout、actions/setup-node、actions/upload-artifact)はよく固まっている。マトリックスビルド、再利用可能ワークフロー、Composite Actions、OIDC によるクラウド認証情報の発行まで、ほぼすべての中核機能が無料プランでも動く。

価格 パブリックリポジトリは無料。プライベートリポジトリは月2,000分まで無料、それ以降は分単位課金。2026年の標準価格は Linux ランナーが分0.008ドル、macOS が分0.08ドル、Windows が分0.016ドル。大きなランナー(16 vCPU 等)は比例して高くなる。本当に怖いのは macOS — モバイルビルドをホスト型 macOS ランナーで回すと、月額請求がすぐ4桁ドルに到達する。

弱み

  1. 標準ランナーが遅い。 ubuntu-latest は 2 vCPU、7 GB RAM。モノレポではつらい。だから BuildJet・Depot・Namespace のような加速ランナー市場が生まれた。
  2. YAML 地獄。 大きなパイプラインは再利用可能ワークフローでも解けない。${{ matrix.os }} のような式が並ぶとデバッグが苦痛になる — 式が間違っていてもビルド途中で初めて分かる。
  3. シークレット流出事故。 Composite Action を誤って使うと secrets.* がそのままログに出る事故が2024〜2025年に複数回報じられた。OIDC への移行が強く推奨されている。

セルフホストランナー GitHub ホスト型ランナーが足りなくなったら、ARC(Actions Runner Controller、Kubernetes 上で動く自動スケーリングランナー)を立てる。社内データセンター・VPC 内部資源へのアクセスが必要なチームの標準解。

一行まとめ

無料スタート・圧倒的エコシステム・OIDC — ほぼすべてのチームの出発点だが、ランナーがボトルネックになった瞬間に BuildJet/Depot/Namespace への切り替えを準備しておく必要がある。

第3章 · GitLab CI/CD — 統合 DevOps

サーフェスと強み GitLab は最初から「DevOps のための Single Application」を掲げてきた。SCM・課題・CI・CR・アーティファクトレジストリ・SAST・DAST・環境追跡が一つの画面に揃う。.gitlab-ci.yml に stages、jobs、rules を書けば終わり。DAG(有向非巡回グラフ)パイプライン、child pipelines、multi-project pipelines、dynamic child pipelines がよく定着している。大きなモノレポでは GitHub Actions より表現力が良い場面が多い。

価格 / 自社ホスティング SaaS は月400分無料から、Premium 29ドル/ユーザー/月、Ultimate 99ドル/ユーザー/月。ただし真の強みは オンプレ にある。GitLab Community Edition は無料、Enterprise Edition はライセンス。日本の保守的なエンタープライズ、韓国の金融セクターで GitLab CE/EE 比重は2026年でも依然強い。

弱み

  1. SaaS ホスト型ランナーの単価が GitHub より高い傾向。だからセルフホストランナーを併用するのが普通。
  2. UI が重い。Premium/Ultimate のセキュリティ機能(SAST 結果画面など)はよく作られているが、日常的な PR レビューフローは GitHub の方がきびきびしている。
  3. CI マーケットプレースが GitHub Actions ほど豊かではない。CI/CD Catalog が2024〜2025年に整備されたが、エコシステムの大きさは比較にならない。

いつ GitLab を選ぶか SCM・CI・セキュリティスキャン・アーティファクトレジストリを一つのベンダーで束ねたい時、そして オンプレ が強制条件の時。日本の保守的エンタープライズ、韓国金融圏で GitLab CE/EE 比重は依然高い。

第4章 · CircleCI — 古参の有料リーダー

サーフェスと強み CircleCI は GitHub Actions 登場前の SaaS CI の標準だった。2026年でも依然 有料 SaaS CI の強者。orbs(再利用可能コンポーネント)、強力なマトリックス、大きなマシンサイズ、GPU ランナー、テスト分割(test splitting) といった機能がよく熟している。ARM/x86、Docker/マシン/macOS ランナーの選択が自由。

価格 クレジットベース。Free は週6,000クレジット、Performance は月15ドル + 使用量、Scale は交渉。同じジョブで GitHub Actions より50〜100%高くなるが、ビルド時間が短ければトータルコストは同等か安くなる。速いマシン・テスト分割のおかげ。

弱み

  1. GitHub との統合が GitHub Actions に及ばない。 「PR コメントに結果表示」のような小さなフローで摩擦がある。
  2. OSS との親和度が低い。 無料プランはあるが GitHub Actions の「パブリックリポジトリ完全無料」と勝負できない。
  3. 障害履歴。 2023年1月のシークレット流出事故がトラウマとして残った。全ユーザーがトークンを再発行する必要があった。

いつ CircleCI を選ぶか すでに使っていて、テスト分割・orbs の資産が厚ければそのまま。新規導入では GitHub Actions・GitLab を先に検討し、理由があるときだけ。

第5章 · Buildkite — セルフホストランナーモデル

サーフェスと強み Buildkite の中核哲学は 「コントロールプレーンは SaaS、ランナーは自社インフラ」。.buildkite/pipeline.yml に step を定義し、SaaS コントロールプレーンがキューを管理、自分で立てたエージェントがジョブを取りに行く。AWS・GCP・オンプレ、どこに立てても同じ。

なぜ人々が使うか

  1. データを外部 SaaS に送らずマネージド UI を使える。 ビルドログは自社インフラに残り、メタデータだけが Buildkite に送られる。
  2. 重いビルドに最適。 大きなマシン、GPU、ARM、大きなディスク — 自社インフラで自由に立てる。
  3. シート課金。 使用量ではなくユーザー数に比例。重いビルドを多く回すチームでは GitHub Actions・CircleCI よりはるかに安くなる。

代表的なユーザー Shopify、Pinterest、Airbnb、Lyft といったモノレポ・中大規模エンジニアリング組織。日本ではメルカリが一部のバックエンドパイプラインに Buildkite を使うことが知られている。

弱み

  1. 自社インフラが必要。 AWS・GCP コスト・運用負担が加わる。
  2. マーケットプレースが GitHub Actions に及ばない。 プラグインはあるが、量は少ない。
  3. UI が地味。 派手なダッシュボードを求めるなら別の選択肢がある。

一行まとめ

自社インフラを上手く運用できる中大規模チームの最良の答え。「データはこっち、運用はそっち」モデル。

第6章 · BuildJet / Depot / Namespace — 速いランナー / 速いビルド

この3つは同じカテゴリの中で少し違う。共通点は 「GitHub Actions をそのままにして、より速いコンピュートだけ差し替える」 加速レイヤー。

BuildJet GitHub ホスト型 Linux/ARM ランナーを 2倍速い CPU、より多いメモリ、より大きなディスク に差し替える。runs-on: buildjet-4vcpu-ubuntu-2204 のようなラベルですぐ適用。価格は GitHub Actions の同等スペック比で約50%とマーケティング。Linux 中心で、macOS は限定的。シンプルな差し替えで効果を見たいときに最適。

Depot コンテナビルドに特化。docker build を depot build に変えるだけで、BuildKit + リモートキャッシュ + ARM/x86 同時ビルドが自動で動く。マルチアーキテクチャイメージをビルドするチームでビルド時間が5〜10倍短縮された事例がよくある。GitHub Actions ランナーも提供 — depot-ubuntu-22.04 のようにラベルを変えるだけ。2024〜2025年に「Docker ビルド分離」カテゴリで事実上の標準になった。

Namespace 「Kubernetes ネイティブ CI」を掲げる。ビルド環境自体をコードで定義し(rules.toml / Devbox 等)、Namespace コントロールプレーンがクラウド内で隔離された VM またはコンテナを立てて実行する。GitHub Actions ランナーとしても使え、別の CLI でも動く。再現可能なビルド環境 — 昨日と今日のランナーが同じ動作をすること — がセリングポイント。

いつ加速レイヤーを導入するか

  • ビルドが平均10分以上で、PR あたりのコストが気になり始めた時
  • macOS ランナーの請求が怖くなった時(Depot の macOS、BuildJet の macOS)
  • ARM マルチアーキテクチャビルドが標準になった時

導入自体は5分。runs-on: 一行を変えるだけ。ROI 計算がきちんとできれば、ほぼ無条件で得になる市場になった。

第7章 · Earthly — Earthfile、コンテナベース

アイデア 「Dockerfile はビルドだけ、Makefile はワークフローだけ。両方が必要だ。」Earthly は Earthfile という文法を作り、ビルド + CI ワークフロー を一つのファイルに書く。すべての step がコンテナの中で動き、キャッシュは自動、出力はホストまたは別のコンテナに流れる。

中核価値 — 同じパイプラインがローカル・CIで同じく動く 開発者のノートパソコンで earthly +test を打てば、CI が動くのと同じ結果が出る。CI でだけ壊れるビルドの割合が劇的に減る。これがあらゆる評価で最も頻繁に言及される強み。

形

# Earthfile
VERSION 0.8
FROM golang:1.22
WORKDIR /app

deps:
    COPY go.mod go.sum ./
    RUN go mod download

build:
    FROM +deps
    COPY . .
    RUN go build -o /out/server ./cmd/server
    SAVE ARTIFACT /out/server AS LOCAL build/server

test:
    FROM +deps
    COPY . .
    RUN go test ./...

earthly +build が上記のターゲットをキャッシュフレンドリーな方法で実行する。キャッシュは BuildKit ベース。

Earthly Cloud / Satellites Earthly Cloud はホスト型ビルドキャッシュ・ランナーを提供する。Satellites というホスト型ビルドマシン上で動くキャッシュが、大きなモノレポで GitHub Actions より5〜10倍速いという報告がある。2025年に一部の価格ポリシーが変わったので、導入前に直接確認推奨。

弱み

  1. 新しい文法の学習コスト。 Dockerfile を既に知っていれば馴染みやすいが、チーム全体に強制するのは少し負担。
  2. すでに GitHub Actions が問題なく動いている小さなプロジェクトには導入理由が弱い。 モノレポ・複雑なビルドで ROI が大きい。

第8章 · Dagger — プログラマブルパイプライン(Solomon Hykes)

誰が作ったか Solomon Hykes — Docker の共同創業者。Docker を離れた後 Dagger を起業した。野望は明確だ。「CI パイプラインは YAML ではなく コード であるべきだ。」

アイデア パイプラインを Go・Python・TypeScript・Java で書く。SDK を呼び出すと Dagger エンジン(BuildKit ベース)がコンテナの中でステップを実行して結果を返す。同じコードがローカルでも、GitHub Actions でも、GitLab CI でも、Jenkins でも同じく動く。

// 例 — TypeScript SDK
import { connect } from "@dagger.io/dagger"

connect(async (client) => {
  const src = client.host().directory(".")
  const node = client.container().from("node:20").withDirectory("/app", src).withWorkdir("/app")
  await node.withExec(["npm", "ci"]).withExec(["npm", "test"]).sync()
})

なぜ人々はこれを好むか

  1. テスト可能なパイプライン。 ユニットテストをパイプラインコードに書く。
  2. CI ベンダー独立。 同じ関数を GitHub Actions でも、Jenkins でも、ローカルでも呼ぶ。ベンダーロックイン脱出。
  3. コンポーザブルなモジュール。 Dagger Cloud のモジュールシステムでビルドブロックを共有する。

弱み

  1. 学習曲線。 YAML パイプラインより学習コストが大きい。「ただのビルド一行」を書くのに SDK・言語決定・モジュール構造まで考える必要がある。
  2. エコシステムが GitHub Actions マーケットプレースほど大きくない。 Dagger モジュールが増えてはいるが、比較対象が難しい。
  3. ベンダー運営モデルの変化。 Dagger Cloud が有料 SaaS として定着しつつあり、OSS エンジン以外の部分のコスト構造が変化中。

誰に向いているか モノレポでパイプラインコードが1,000行を超えて YAML ではもう持たないチーム、マルチ CI(GitHub Actions + Jenkins)環境、「パイプラインもコード」の信念があるチーム。

第9章 · Drone / Argo Workflows / Tekton — k8s パイプライン

3つのツールは性格が違う。

Drone 元々 OSS CI として始まり → Harness が2020年に買収 → 2024年に CNCF に寄贈。コンテナベースパイプライン、.drone.yml で定義、ランナーは Docker・k8s・マシンモード。シンプルさ がセリングポイント。GitHub Actions 登場後シェアは減ったが、社内 GitOps + 軽量 CI の組み合わせでは依然使われる。

Argo Workflows CNCF Graduated。k8s 上で動く DAG/ステップワークフローエンジン。元々は ML/データワークフローツールだが CI 用途でもよく使われる。各ステップが k8s Pod として立ち上がり、Argo Events でトリガーされる。すべてのステップが k8s リソース であることは諸刃の剣 — 可視性・スケーラビリティは良いが、単純な CI には過剰。

Tekton 元々 Knative から分かれた CNCF プロジェクト。k8s CRD として Pipeline、Task、PipelineRun、TaskRun を定義する。CI ビルディングブロック に近い — Tekton の上に OpenShift Pipelines、Jenkins X のような親切な UI が乗る。Red Hat が OpenShift Pipelines で強く推している。

いつ k8s ネイティブ CI を選ぶか

  • すでに k8s をデータ/ML ワークロードで使っており、CI も同じクラスタで回したい時
  • ビルドが GPU・大きなメモリ・特殊ノードを必要とする時
  • マルチテナント隔離が重要なプラットフォームチーム

弱み 観測・デバッグ負担が大きい。kubectl logs で Pod を探して入っていく必要がよくある。一般の開発者が日常的に触るには重い — だから通常はプラットフォームチームが運用し、開発チームは GitHub Actions のような抽象化の上で見る。

第10章 · Jenkins — 依然生きている巨人

現実 GitHub Actions が標準になったからといって Jenkins は死んでいない。2026年でも Jenkins はエンタープライズ・金融セクター・半導体・自動車で巨大なシェアを維持している。CloudBees が商用サポートで生かしており、Jenkins X(k8s ネイティブ分派)も一部で使われる。

なぜ殺せないか

  1. すでに千個のパイプラインが動いている。 Jenkinsfile、フリースタイルジョブ、プラグイン依存が巨大。
  2. プラグインエコシステムが膨大。 1,800以上。「X ツールと統合するには」プラグインがほぼ常に存在。
  3. オンプレで動作が検証されている。 GitHub Actions の ARC も可能だが、Jenkins ほど慣れた運用チームは多くない。

痛み

  1. セキュリティ — プラグインの CVE が四半期ごとに出る。パッチ適用が遅い。
  2. UI — 2025年でもクラシック UI 比重が大きい。Blue Ocean は凍結された。
  3. 新規人材が入ってこない — 新入開発者が Jenkinsfile を学ぼうとしない。

戦略 「新規プロジェクトは GitHub Actions、既存 Jenkins は凍結したまま段階的に移す」が現実的なパターン。Jenkins → GitHub Actions マイグレーションガイド が GitHub の公式ドキュメントに入っているほどよくある道。

第11章 · Spacelift / Garnix / Cycloid — Terraform / IaC CI

なぜ別カテゴリか Terraform/OpenTofu/Pulumi/CDK のワークフローは一般 CI と違う。drift detection、policy-as-code、plan/apply の2段階フロー、マルチクラウド認証情報 といった要件は一般 CI にはない。だから IaC 専用 CI が別市場として定着した。

Spacelift Terraform/OpenTofu/Pulumi/CloudFormation/Ansible/Kubernetes 統合。Stack と Run の概念、OPA ベースのポリシー、drift detection、セルフホスト worker pool、AWS/GCP/Azure 認証情報マネージャまで。韓国フィンテック・ゲーム会社の一部で導入したという報告がある。

Garnix Nix ベース CI。ビルド結果の 再現性 がセリングポイント。Nix ビルダーが結果をコンテンツアドレスでキャッシュし、同じ入力に対して同じ出力を保証する。NixOS・Nix エコシステムの中で堅固。一般チームが導入するには Nix 学習コストが大きいが、一度入れればビルド信頼性が別次元に上がる。

Cycloid 「DevOps 自動化プラットフォーム」ポジショニング。Terraform モジュールカタログ、環境プロビジョニング、コスト可視化、権限管理までを一つの UI に入れる。インハウスプラットフォームチームを小さな SaaS で代替したい中堅企業にアピール。

代替

  • Terraform Cloud / HCP Terraform — HashiCorp 公式。2024年のライセンス BUSL 転換以降、政治的負担を感じるチームは OpenTofu + Spacelift/Atlantis に移行中。
  • Atlantis — OSS、セルフホスト。最も軽量な選択肢。

第12章 · Bitrise / Codemagic — モバイル CI

なぜ別市場か モバイルビルドは macOS ランナーが必須(iOS)。ホスト型 macOS は高く、サインキー・プロビジョニングプロファイル・App Store Connect API・Firebase・社内配信・コードプッシュまでワークフローが一般 CI と性格が違う。だからモバイル専用 CI が生きている。

Bitrise 2014年ハンガリー・ブダペスト出発。iOS・Android 両方対応。Step Library が豊富で、Workflow Editor で視覚的にパイプラインを組む。Fastlane 統合、App Store Connect 統合、インアプリコードプッシュまで総合パッケージ。2024〜2025年には Bitrise CI for AI のような ML ビルドも推している。

Codemagic Flutter に特化した強み。Flutter ビルドの事実上の標準。iOS・Android 両方を一つのワークフローで作り、App Store/Play Store/Huawei/Amazon AppGallery まで一度にデプロイ。M2/M4 Mac Mini をランナーとして提供しビルド速度が速い。

App Center の死 Microsoft App Center は2025年3月31日に公式終了した。かつてモバイル CI の大きな一角だったが、Microsoft が Visual Studio App Center に吸収 → 結局終了。App Center を使っていたチームは2024〜2025年の間に Bitrise・Codemagic・GitHub Actions(macOS ランナー)・Firebase App Distribution に分かれた。

コストの現実

  • Bitrise: Hobby 無料、Velocity 月50ドルから、その上は使用量ベース。
  • Codemagic: 月500分無料、その後分単位課金。M2 macOS は約0.095ドル/分。

ホスト型 macOS はどこでも高い。自前の Mac mini Farm を運用する会社が増えた — MacStadium・Scaleway・Hetzner のようなホスティングオプションと組み合わせて。

第13章 · Bazel + Buildbarn / BuildBuddy / EngFlow — リモートビルドキャッシュ

なぜ別領域か Bazel・Buck2・Pants のような ビルドシステム はアクション単位でキャッシュする。同じ入力に同じ出力 — 入力ハッシュが同じならビルド結果をそのまま取ってくる。このキャッシュを 複数マシンで共有 すればビルド時間が劇的に短縮される。だから Remote Build Execution(RBE) + Remote Cache 市場が生まれた。

Buildbarn OSS。Google が作っていた buildfarm を代替する自由な実装。ContentAddressableStorage・ActionCache・ExecutionEngine をモジュラーに構成。大きなモノレポの OSS オプション。

BuildBuddy SaaS + セルフホストオプション。Bazel フレンドリーな UI、アクションログ、ビルドツリー、RBE まで。Y Combinator 出身チームで、2024〜2025年に急成長。Bazel 以外にも Go・Rust 用ビルド加速も作っている。

EngFlow Bazel 共同創業者が作った会社。エンタープライズターゲット、Bazel・Buck2・Pants すべて対応。大きなゲーム会社・金融セクター・自動車 OEM が主な顧客。価格は高く、交渉ベース。

いつ RBE を導入するか

  • ビルドがモノレポで毎分数十のアクションを回す
  • 同じアクションを複数の PR が並列でビルドする
  • ビルドマシンを増やしても時間が減らない(キャッシュミスがボトルネック)

導入後の効果は劇的 — モノレポで10倍短縮はよくある。コストはキャッシュストレージ・ネットワーク・実行マシン時間だが、開発者の待ち時間の方が高いというのが標準的な ROI 論理。

第14章 · Renovate vs Dependabot vs Mend — 依存関係更新

なぜ別カテゴリか 2026年には 依存関係更新 PR が CI トラフィックの大きな部分 を占める。自動化がなければ人間が追いつかない。CI はビルドだけでなく、その PR を作るボットまで責任を持つ。

Dependabot GitHub 一級市民。.github/dependabot.yml 一ファイルで終わり。Security Updates(脆弱依存関係の自動 PR)と Version Updates(定期更新 PR)の2モード。GitHub Advanced Security と連動。シンプルな設定・GitHub UI 統合が強み。

Renovate 設定の 表現力 が圧倒的。一つの PR に複数の依存関係をまとめる、自動マージルール、monorepo・workspace 認識、200以上のマネージャ(npm・pip・gradle・terraform・docker・helm・ansible-galaxy ...)、regex マネージャで任意のファイルまで更新。Mend が買収 したが OSS・セルフホストオプションは生きている。

Mend Renovate 買収後、よりエンタープライズ指向に拡張。SCA(Software Composition Analysis)・ライセンス検証・ポリシーベース更新・SBOM 管理まで。Renovate が「技術的に強い」なら Mend は「組織的・ポリシー的統制」。

選択ガイド

  • 小さなチーム・GitHub 中心 → Dependabot
  • 大きなチーム・複雑なモノレポ・Terraform/Helm まで → Renovate
  • コンプライアンス・SBOM・ライセンス追跡必須 → Mend

3つのツールすべてが CI をトリガーする。CI コストで依存関係ボット PR が占める比重を測定してみると、意外と大きい。

第15章 · 韓国 / 日本 — トス、カカオ、メルカリ、CyberAgent

韓国 — トス(Toss) トスの SLASH カンファレンス資料を見ると、トスは GitHub Enterprise + GitHub Actions + ARC(セルフホストランナー on k8s) の組み合わせを中心にしている。ビルドキャッシュは社内ソリューション、デプロイは ArgoCD。CI パイプラインを開発チームが自分の手で作り、プラットフォームチームが ARC とシークレット管理・OIDC を担当する。

韓国 — カカオ(Kakao) カカオは巨大な社内 GitLab 資産がある。CI は GitLab CI/CD がメイン、モバイルは社内 Mac ファーム + Bitrise。ML ワークロードは Argo Workflows を一部採用。音楽(Melon)・ゲーム・コマースごとに自律性があり、CI スタックも KakaoTalk・Daum・KakaoBank など子会社ごとに異なる。

日本 — メルカリ メルカリはマイクロサービスが1,000近い。CI スタックは GitHub Actions + Buildkite + Spinnaker の組み合わせ。Spinnaker でデプロイワークフローを管理し、CI は GitHub Actions が主力。モノレポの一部では Bazel + 社内 RBE を使うという報告。

日本 — CyberAgent ABEMA・ゲーム事業 — k8s ベース。CI は Argo Workflows + GitHub Actions の混合、ビルドキャッシュは BuildBuddy または社内。モバイルは Bitrise。発表資料で「PR 平均ビルド時間5分以下を維持」を KPI に置いているのが印象的。

共通パターン

  • 新規は GitHub Actions、既存は自社資産(Jenkins・GitLab・Bamboo)を維持
  • ランナーは徐々にセルフホスト on k8s(ARC)に移行
  • ビルドキャッシュ・RBE はモノレポが大きいほど導入 ROI が大きい
  • セキュリティ・シークレット管理は OIDC + Vault/AWS Secrets Manager の組み合わせが標準化

第16章 · 誰が何を選ぶべきか — 決定ツリー

OSS プロジェクト

  • 最初の答え: GitHub Actions。パブリックリポジトリ無料、マーケットプレース圧倒的。
  • ビルドが重ければ: BuildJet ラベル変更で始める。
  • コンテナビルドなら: Depot。
  • パイプラインが複雑で YAML で持たないなら: Earthly または Dagger。

スタートアップ(10〜50人)

  • メイン CI: GitHub Actions。
  • モバイルがあるなら: Codemagic(Flutter)/Bitrise(ネイティブ)。
  • IaC が多いなら: Spacelift または Atlantis(OSS)。
  • 依存関係ボット: Dependabot で始め、複雑になれば Renovate。

中堅(50〜300人)

  • メイン CI: GitHub Actions または GitLab(オンプレなら後者)。
  • 加速レイヤー: BuildJet/Depot/Namespace — ビルド時間・コスト測定後に導入。
  • モノレポビルド: Bazel + BuildBuddy 検討開始。
  • 依存関係: Renovate。

エンタープライズ(300+、金融・通信・政府)

  • メイン CI: GitLab(オンプレ)または GitHub Enterprise + ARC。
  • Jenkins 資産は凍結したまま段階的にマイグレーション。
  • IaC: Spacelift / Terraform Cloud / OpenTofu + Atlantis。
  • RBE: EngFlow(商用・サポートが強い)。
  • 依存関係: Mend(コンプライアンス込み)。
  • モバイル: Bitrise + 自前 Mac ファーム。

モバイル専業チーム

  • Flutter: Codemagic。
  • iOS/Android ネイティブ: Bitrise。
  • ホスト型 macOS コストが負担なら MacStadium・Hetzner・Scaleway で自前 Mac ファーム。

データ / ML チーム

  • ワークフローオーケストレーション: Argo Workflows。
  • データパイプライン: Airflow または Dagster。
  • モデル学習 CI: 一般 CI + 別途 GPU ランナー(Lambda Labs・CoreWeave のようなところで)。

第17章 · 変わらない原則

ツールは毎年変わる。変わらない原則をいくつか挙げて締める。

  1. CI はコスト・時間の中核ボトルネックである。 ビルド5分が10分になれば、チーム平均の PR マージ時間が2倍になる。ツール選択はコスト問題であり認知負荷問題でもある。
  2. ランナー・ビルド・キャッシュは分離可能。 GitHub Actions をそのままにしてランナーを BuildJet に、ビルドを Earthly に、キャッシュを BuildBuddy に差し替えられる。一度にすべて変えず一レイヤーずつ。
  3. OIDC を有効にする。 シークレットを環境変数に埋め込む時代は終わった。OIDC トークン → STS → 短期認証情報が標準。
  4. CI コストを測定する。 GitHub Actions の請求ページ、GitLab Usage Reports、CircleCI クレジット — 月に一度は見る。加速レイヤー導入 ROI は測定から始まる。
  5. ベンダーロックインを意識する。 Dagger・Earthly のようなツールは同じパイプラインを複数の CI で回せるようにする。一つのベンダーに深く依存するほどマイグレーションコストが大きくなる。
  6. 依存関係ボット PR を自動マージする。 そうしないと人間が追いつかない。パッチバージョンはテスト通過時に自動マージ、マイナー/メジャーは手動レビュー — この2つのルールが標準。

CI は「一度決めたら終わり」の領域ではない。2〜3年に一度市場を再評価し、小さな加速レイヤーから差し替えながら学ぶ必要がある。大きなマイグレーションは普通失敗する。

次の記事では、本稿のツールの中から加速レイヤー(BuildJet・Depot・Namespace)とビルドシステム(Earthly・Dagger・Bazel)を 同じモノレポに同時適用してみた結果 を見る。同じコード、違うパイプライン、測定された時間・コスト・失敗モード。

参考 / References

Discuss on Twitter • View on GitHub