プロローグ — 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

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

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

- [GitHub Actions pricing](https://github.com/pricing)

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

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

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

- [Buildkite — Pipelines documentation](https://buildkite.com/docs/pipelines)

- [BuildJet — Faster GitHub Actions runners](https://buildjet.com/for-github-actions)

- [Depot — Faster Docker builds and GitHub Actions runners](https://depot.dev/)

- [Namespace — Kubernetes-native CI/CD platform](https://namespace.so/)

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

- [Earthly Cloud and Satellites](https://earthly.dev/earthly-cloud)

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

- [Drone CI — CNCF Sandbox project](https://www.drone.io/)

- [Argo Workflows documentation](https://argo-workflows.readthedocs.io/)

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

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

- [Spacelift — Infrastructure as Code automation](https://spacelift.io/)

- [Garnix CI — Nix-based CI](https://garnix.io/)

- [Cycloid — DevOps automation platform](https://www.cycloid.io/)

- [Bitrise — Mobile CI/CD](https://bitrise.io/)

- [Codemagic — Flutter CI/CD](https://codemagic.io/)

- [App Center retirement announcement (Microsoft, 2024)](https://learn.microsoft.com/en-us/appcenter/retirement)

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

- [Buildbarn — Open source Bazel Remote Execution](https://github.com/buildbarn)

- [BuildBuddy — Remote Build Execution for Bazel](https://www.buildbuddy.io/)

- [EngFlow — Remote build execution for Bazel, Buck2, Pants](https://www.engflow.com/)

- [Renovate documentation](https://docs.renovatebot.com/)

- [Dependabot documentation](https://docs.github.com/en/code-security/dependabot)

- [Mend — formerly WhiteSource](https://www.mend.io/)

- [Toss SLASH conference (Korean engineering tech talks)](https://toss.tech/slash)

- [Mercari Engineering Blog](https://engineering.mercari.com/en/blog/)

- [CyberAgent Developers Blog](https://developers.cyberagent.co.jp/blog/)