필사 모드: CI/CDプラットフォーム 2026 完全ガイド — GitHub Actions・GitLab CI・CircleCI・Buildkite・Dagger・Earthly・Drone・Argo CD・Flux 深掘り

プロローグ — CI/CDは再び政治である

2026年のどのチームでもよく見かける光景がある。プラットフォームチームが「全社標準はGitHub Actions」と発表すれば、データチームが「うちのモノレポはBuildkiteの方が速い」と反論し、SREチームが「でもデプロイはArgo CDで」と割り込む。結局、ビルドはGitHub Actions、エージェントはセルフホストランナー、キャッシュはTurborepo Remote Cache、デプロイはArgo CD、段階的ロールアウトはFlaggerという多層構成に落ち着く。

これが2026年のCI/CDの現実だ。**「ひとつのツールで全部やる」という幻想は崩れ**、代わりに我々は「どの組み合わせがうちのチームに合うか」を毎回決めることになる。そしてその決定は単なる技術選定ではなく、**コスト・セキュリティ・速度・プラットフォーム政治の関数**である。

この記事は2026年現在のCI/CDプラットフォーム全体マップを描く。SaaSビッグ4(GitHub Actions・GitLab CI・CircleCI・Buildkite)、コンテナネイティブの新世代(Dagger・Earthly・Drone・Harness)、GitOps(Argo CD・Flux・Flagger)、K8sネイティブ(Tekton・OpenShift Pipelines)、Terraform CI/CD(Spacelift・Atlantis・Pulumi Deployments)まで — 各ツールの位置とコストと損益分岐点まで。

第1章 · CI/CDプラットフォーム全体マップ — 2026年の分類学

まず全体像。「CI/CD」という用語1つが多くを含みすぎている。2026年基準のよくある分類はこうだ。

| レイヤ | 役割 | 代表ツール |

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

| SaaS CI ビッグ4 | Git pushからビルド/テスト | GitHub Actions, GitLab CI, CircleCI, Buildkite |

| コンテナネイティブCI | 全ステップをコンテナで表現 | Dagger, Earthly, Drone, Harness CI, Codefresh |

| K8sネイティブCI | K8sの中でパイプライン | Tekton, OpenShift Pipelines, Argo Workflows |

| CD / GitOps | Gitを真実の源としてK8s同期 | Argo CD, Flux, Flagger |

| Terraform CI/CD | インフラ変更の安全な適用 | Spacelift, Atlantis, Terragrunt, env0 |

| クラウドマネージド | クラウド依存の統合パッケージ | AWS CodePipeline, Azure Pipelines, Google Cloud Build/Deploy |

| エンタープライズ伝統 | オンプレ・複雑性・プラグイン | Jenkins, TeamCity, Bamboo, GoCD |

| 実行インフラ | runnerとキャッシュ | BuildJet, Depot, Blacksmith, Turborepo Cache |

核心の洞察: **レイヤが異なれば競合ではなく組み合わせ**だ。GitHub ActionsとArgo CDは競合ではない。DaggerとTektonは同じ枠を争う。比較は同じレイヤ内でのみ意味がある。

第2章 · GitHub Actions — 事実上の標準となった理由

2026年の新規プロジェクトの70%以上がGitHub Actionsで始まる(JetBrains DevEcosystem 2025推定)。理由は単純 — コードがGitHubにあり、小さなワークフローはyaml一つで足り、マーケットプレイスには2万以上のアクションが積み上がっている。

2026年時点で固まった新しいパターン。

- **Larger runners** — 4・8・16・32・64 vCPUのrunnerをGitHubが直接提供。ARM64 runner(Cobalt 100ベース)とApple Silicon runner(M2・M3)も正式対応。

- **Reusable workflows + composite actions** — 社内標準パイプラインはreusable workflowに抽出、小さなステップ束はcomposite actionへ。

- **OIDC for cloud** — 長期資格情報の代わりにIDトークン交換でAWS/GCP/Azureへアクセス。2024年以降事実上のデフォルト。

- **Immutable releases / Artifact attestations** — `actions/attest-build-provenance`でSLSA Level 3までほぼ自動。

- **セルフホストランナー** — コスト・セキュリティ・ハードウェア要件で再びセルフホストが増えた。次章で別途。

陥りやすい罠もある。

- テンプレート表現式の中でユーザー入力をそのまま使うとコマンドインジェクション。`env:`で受けてから使うのが安全。

- `pull_request_target`トリガーはsecretにアクセスできるが、PRコードをそのままチェックアウトすると危険。ポリシーで防ぐ。

- 無料の分単位クォータはすぐ尽きる。プライベートリポでは分単価が早く累積するので、セルフホストの損益分岐点を事前に計算しておく。

第3章 · GitLab CI/CD 17.x — フルスタックDevSecOpsの一束

GitLab 17.x(2024年後半リリース)はCI/CDを単なるワークフロー実行器ではなく、**DevSecOpsフルスタックの一束**として位置付ける。

- `.gitlab-ci.yml`一つの中にビルド・テスト・SAST・DAST・コンテナスキャン・ライセンスチェック・デプロイを全部表現。

- GitLab Runner — Docker・Kubernetes・Shell・SSHなど多様なexecutor対応。

- **Auto DevOps** — 規約ベースの自動パイプライン。スタートアップでコスパが良い。

- **GitLab Duo** — AIベースのコードレビュー・テスト生成・脆弱性説明。2026年に入りDuo Workflowがベータからじゃ。

- **Continuous Vulnerability Scanning(CVS)** — mainブランチを定期的に再スキャンして、新たに公開されたCVEを捕捉。

- **Compute minutes** — SaaSプランでは分単位課金。セルフマネージドなら無制限だがインフラコストはかかる。

GitHub Actionsが「Git + ワークフローの単純さ」を武器にするなら、GitLab CIは「1つのベンダーで完結するフルスタックの統合」が武器だ。規制産業(金融・公共・ヘルスケア)でGitLab self-managedのシェアが依然高い理由。

第4章 · CircleCI 2.x — orbsと並列実行の強者

CircleCIはGitHub Actionsの登場後シェアを落としたが、依然として**モノレポ・多言語プロジェクトに強い**。

- **Orbs** — 再利用可能なyaml束。マーケットプレイスに3000以上。

- **Parallelism + Test Splitting** — 1つのjobをN個のコンテナへ自動分割し、テスト時間ベースで均等配分。

- **Matrix builds** — 言語・OS・DBの組み合わせを格子状に素早く表現。

- **CircleCI Sphere(TestGPT)** — 失敗テストの原因分析・修正提案AI機能。

- **セルフホストランナー** — セキュア環境用。GPU runnerも正式。

CircleCIを選ぶチームの理由は「**大規模テストスイートの並列実行が一番よく動く**」という評。欠点はGitHub Actionsに比べ、単純な小ワークフローには大げさに見える点。

第5章 · Buildkite — エージェントは自社インフラ上で

Buildkiteのモデルはニュアンスが違う。**コントロールプレーン(Web UI・パイプライン定義・ログ集約)はBuildkiteのSaaSで、agent(実際のビルド実行器)は自社インフラ上で**動く。BYO(Bring Your Own)コンピュートモデルだ。

なぜこれが重要か:

- ビルドが自社のVPC内で走る → 内部リソース(DB・内部レジストリ)へ安全にアクセス。

- 分単価がない — 自分たちが運用するagent分だけのコスト。

- 巨大モノレポで速い — キャッシュ・Dockerレイヤーが自社インフラに残る。

Shopify・Airbnb・Pinterestのような大規模モノレポチームで人気。欠点は**agent運用自体が仕事になる** — オートスケーラー・キャッシュ方針・ハード管理。

第6章 · Dagger — programmable CIという新カテゴリ

DaggerはDocker共同創業者Solomon Hykesが始めたプロジェクトで、2024〜2025年にかけて急速に地位を確立した。核心アイデアはシンプル — **CIパイプラインをyamlではなくコードで書く**。

- Go・TypeScript・Python・PHP・JavaのSDK提供。

- 全ステップが**コンテナ内で**実行 — ローカルマシンで回した結果がCIでも同じ。「動くのは僕のマシンだけ」の終わり。

- BuildKitベース — キャッシュ・並列化が速い。

- **Dagger Cloud** — SaaS trace・タイムライン・キャッシュヒット率の可視化。

- GitHub Actions・GitLab CI・Jenkinsの上でそのまま動く — 既存のCIを置き換えるのではなく内側から呼び出す。

Daggerの本当の魅力は「yaml地獄からの脱出」だ。複雑なif/elseやマトリックスの組み合わせをyamlで表現すると限界が来るが、Go/TypeScriptの関数で書けばIDE補完・型チェック・ユニットテストが可能になる。

第7章 · Earthly — モノレポに優しいBuildKit

Earthlyは別の角度から同じ問題を解く。**Earthfile**という単一ファイルにビルドステップを宣言的に書きつつ、内側はBuildKitでコンテナ単位の実行を行う。

- Dockerfile文法に近い — 学習コストが低い。

- キャッシュ・並列化・モノレポ親和性 — `+target`の形で依存を明示。

- ローカルとCIで同じコマンドを実行 — 再現性確保。

- Earthly Satellites — マネージドBuildKit runner(SaaS)。

DaggerとEarthlyは同領域で争うが哲学が違う。**Daggerは「コードで書く」**、**Earthlyは「Dockerfile風だがより強力に書く」**。チームの好みに合わせて選ぶ。

第8章 · Drone 2.xとHarness CI — Harness傘の下

Droneはコンテナネイティブ初期の強者で、2020年にHarnessに買収された。今は2つの形で生きている。

- **Drone 2.x(OSS)** — yamlベース、コンテナ単位実行、軽量。セルフホストに強い。

- **Harness CI(マネージド)** — Droneの上にAI機能(テスト回帰予測・失敗RCA・ドリフト検出)を載せたSaaS。

Harnessの武器は**AI Test Intelligence** — 変更コードと過去テスト結果を分析し、PR毎に走らせるテストを自動選別。大規模モノレポでテスト時間を30〜70%削減したという事例報告が多い。

第9章 · Argo CD — GitOps for Kubernetes

CIがビルドならCDはデプロイ。2026年のK8s上CDで事実上の標準は**Argo CD**だ。

- **GitOps原則** — Gitが真実の源。クラスタ状態はGitのmanifestに従う。

- **ApplicationSet** — 同じチャートを多数のクラスタ・環境へ自動伝播。

- **Argo CD Image Updater** — 新しいイメージタグを検知してGitを自動更新。

- **Argo Rollouts** — Canary・Blue-Green・段階デプロイ。

- **Argo Workflows** — K8s上workflowエンジン(CIの補助としても活用)。

長所は**全変更がGitコミットとして残る** → 監査・ロールバック・再現が容易。短所は**K8s依存** — VM・サーバーレスには直接合わない。

第10章 · Flux CDとFlagger — もうひとつのGitOps

FluxはArgo CDと似た仕事をするが哲学が違う。

- **Fluxはcontrollerの束** — Source・Kustomize・Helm・Notification・Image Automationがそれぞれのcontroller。

- **Argo CDはUI中心・アプリ中心**、**Fluxはcrd中心・プラットフォーム中心**。

- **Flagger** — Fluxの段階デプロイツール。Argo Rolloutsと同じ枠。

CNCF graduatedプロジェクトであること・SUSE/Microsoftの後援・composabilityの強さがFluxの魅力。Argo CDはGUIフレンドリー・アプリカタログフレンドリー、Fluxはプラットフォームビルダーフレンドリーだ。

第11章 · Jenkins 2.x・Jenkins X・Tekton — 伝統強者とK8sネイティブ

Jenkinsは死なない — 少なくともエンタープライズでは。

- **Jenkins 2.x** — 宣言的パイプライン、Blue Ocean UI、2万以上のプラグイン。

- **Jenkins X** — K8sネイティブJenkins。事実上別プロジェクト化。

- **AWS Jenkins on EKS** — マネージドJenkinsオプション。

Jenkinsの強みは**プラグインエコシステムの深さとオンプレの伝統**。弱みは**単一masterのSPOF、プラグインのセキュリティ負担、モダンUIの不在**。

**Tekton**はK8sネイティブCIの標準候補。CRDでTask・Pipeline・PipelineRunを定義し、Red Hat OpenShift PipelinesはTektonベースのエンタープライズパッケージだ。**すでにK8sを運用するチームには自然**。

第12章 · Spacelift・Atlantis・Pulumi Deployments — Terraform CI/CD

インフラコード(Terraform・OpenTofu・Pulumi)のCI/CDは別カテゴリだ。一般CIでも回せるが、state・plan・applyの安全な流れを作るのは難しい。

- **Atlantis(OSS)** — PR内の`atlantis plan`・`atlantis apply`コメントで動くワークフロー。セルフホスト。

- **Spacelift** — AtlantisのSaaS版 + policy as code。OPA統合。

- **env0** — マネージドTerraformクラウド + RBAC + コスト見積。

- **Terragrunt** — Terraformコード自体のDRYツール、CIフローでも併用される。

- **Pulumi Deployments** — Pulumi専用マネージド実行器/スケジューラ。

**核心: 一般CIで`terraform apply`を回さないこと。** state lock・並行性・承認フロー・ドリフト検出を1つのツールが責任を持つ形にする。

第13章 · その他のマネージドCI — Codefresh・GoCD・Octopus・TeamCity・Bitbucket

状況別によりフィットするツール。

- **Codefresh** — K8s/GitOpsに特化したマネージド。Argo CDをSaaSで包んでくれる。

- **Octopus Deploy** — Windows/エンタープライズデプロイに強い。変数置換・環境管理の詳細さ。

- **GoCD(ThoughtWorks)** — value stream mapの可視化が強み。シェアは小さいが忠実度が高い。

- **TeamCity 2024.x(JetBrains)** — ビルドチェーン・メタランナーが強力。JetBrainsエコシステム親和。

- **Bitbucket Pipelines 2026(Atlassian)** — Bitbucket Cloud統合。Jira・Confluenceと一束。

- **Garden.io** — ローカル開発とCIの一貫性に集中したツール。マイクロサービス多環境に強い。

第14章 · クラウドマネージドCI — AWS・Azure・GCP

クラウド依存でも統合価値が大きければ合理的選択になる。

- **AWS CodePipeline + CodeBuild + CodeDeploy** — IAM・VPC・S3の深い統合。Lambda・ECS・EKSデプロイが楽。UIはシンプルだが進化が遅い。

- **Azure DevOps Pipelines / Azure Pipelines** — Microsoftエコシステムの強み。yaml + classicの2モード。無料分が比較的太っ腹。

- **Google Cloud Build / Cloud Deploy** — GCR/GAR・GKE・Cloud Run深い統合。Cloud DeployはArgo CDスタイルの段階デプロイ。

選択基準: **クラウド1か所に90%以上集約されている**ならマネージドCIが合理。**マルチクラウド/オンプレ混在**なら、GitHub ActionsやGitLabのようなクラウド中立CIが良い。

第15章 · セルフホストランナー — BuildJet・Namespace・Blacksmith・RunsOn・Depot・Ubicloud

2026年の新しい流れ。GitHub-hosted runnerの分単価が高くなったことで、**GitHub Actionsと互換性のある外部runner SaaS**が1カテゴリを成した。

- **BuildJet** — 価格対比で速いマシン。8 vCPU runnerがGitHubの半値水準。

- **Namespace** — instant runnerとKVMベースの分離。素早い起動が強み。

- **Blacksmith** — Hetznerベアメタル上で動かす。価格優位が大きい。

- **RunsOn** — 自社AWSアカウント内でrunnerを自動起動。EC2 spotも活用。

- **Depot** — BuildKitベースのコンテナビルド加速が強み。DockerビルドとGitHub Actionsの両方。

- **Ubicloud** — OSSクラウドインフラ上のrunner。Hetznerに近い価格帯。

損益分岐点感覚: GitHub-hosted Linux分単価0.008 USD基準で、月5万分以上なら外部runner SaaSが普通安い。自社AWSアカウント内でspotで回すRunsOnは分単価0.001〜0.003 USDまで落ちる。

第16章 · キャッシュインフラ — Turborepo・Nx Cloud・Bazel・sccache・Mise

CI速度の半分はキャッシュだ。2026年によく使われるツール。

- **Turborepo Remote Cache** — JS/TSモノレポの標準。Vercel SaaSまたはセルフホスト(open spec)。

- **Nx Cloud** — Nxモノレポ用。分散taskの実行・affected計算。

- **Bazel Remote Cache** — Google出身、大規模モノレポの頂点。学習曲線が急。

- **sccache** — Rust/C++のコンパイラキャッシュ。S3バックエンドでチーム単位共有。

- **Mise(rtx後継)** — runtimeバージョン管理 + toolキャッシュ。asdfの後継として定着。

- **GitHub Actions Cache(builtin)** — デフォルトだが10 GB/repoの制限にすぐ到達。

キャッシュがうまく機能するとPRビルド時間が30分→4分に縮む。キャッシュが壊れるとその逆 — だからキャッシュキー設計・invalidation方針は普段は見えないが決定的だ。

第17章 · コンテナレジストリ — Docker Hub・GHCR・ECR・GAR・Harbor・Zot

ビルドの結果は普通はイメージだ。どこに押すかも重要。

- **Docker Hub** — 2026年に入り無料pull制限がより厳しく。パブリックイメージのホストとしては依然標準。

- **GitHub Container Registry(GHCR)** — GitHub Actionsと完全統合。プライベートイメージの第一選択。

- **Amazon ECR / Public ECR** — AWSアカウント内の標準。EKS・ECS・Lambdaの深い統合。

- **Google Artifact Registry(GAR)** — GCRの後継。Docker・npm・Maven・Helmを1レジストリで。

- **Harbor** — CNCF graduated。オンプレ/社内レジストリの事実上の標準。

- **Zot** — OCIネイティブOSSレジストリ。Cosign・SBOMが一級市民。

第18章 · 署名・SBOM・SLSA — サプライチェーンセキュリティの3本柱

2024年以降、急速に標準化した領域。

- **Cosign(Sigstore)** — OIDCベースのkeyless署名。GitHub Actions OIDCと相性が良い。

- **Notary v2 / Notation** — OCIネイティブ署名。AWS Signerなどが採用。

- **SBOM** — Software Bill of Materials。**SPDX**(Linux財団)・**CycloneDX**(OWASP)が両大フォーマット。

- **SLSA Level 1〜4** — サプライチェーン整合性等級。Level 3+が2026年の事実上の推奨。

- **in-toto attestations** — ビルド出処の証明。

GitHub Actionsの`actions/attest-build-provenance`、GitLabのSLSA pipeline、GoogleのBinary Authorizationがこの束を1度に処理してくれる統合ツールだ。

第19章 · AI in CI — 2026年に新しく見えるもの

CIにAIが入る形。

- **CircleCI Sphere / TestGPT** — 失敗分析 + 修正提案。

- **GitLab Duo Workflow** — コードレビュー・テスト生成・脆弱性説明。

- **Harness AI Test Intelligence** — PRコード変更ベースのテスト選別。

- **Datadog Test Optimization** — flaky test検出・再実行ポリシー・テスト時間回帰。

- **Meta Predictive Test Selection** — 自社モデルで社内のみで運用(論文公開)。

- **GitHub Copilot Workspace + Actions** — PR自動作成・自動修正・自動レビュー。

AI in CIは一言で**「何を回さないかを決めるAI」**だ。全PRに全テストを回さず影響を受けたものだけ回すのがリソース節約の鍵で、それを人手で分類するのは難しい。

第20章 · 韓国ビッグテックCI/CD風景 — 2026年

韓国ビッグテックでよく見られるパターン。

- **Coupang** — GitHub Enterprise + GitHub Actions、セルフホストrunnerを社内K8sへ。EKSデプロイはArgo CD。モノレポはBazel。

- **NAVER Cloud DevOps** — 自社DevOpsプラットフォーム(NCP DevOps Pipeline)。社内標準だが一部チームはGitHub Enterprise。

- **Kakao Pages CI** — GitHub Actions + 自社K8s + Argo CD。SpinnakerからArgo CDへ移行した事例が多い。

- **LINE SREチーム** — DroneからGitHub Actionsへ移行。グローバルクロスリージョンデプロイは自社ツール。

- **Baemin / 配達の民族** — GitHub Actions + AWS CodeDeploy + Spinnaker。

- **Toss** — GitHub Enterprise + 自社PaaS(Toss Platform)。デプロイはArgo CD + 自社control plane。

共通パターン: **GitHub Enterprise + Actions + セルフホストrunner + Argo CD**が急速に標準化中。Jenkinsはレガシーシステムに残り、新規ではほぼ使われない。

第21章 · 日本ビッグテックCI/CD風景 — 2026年

日本ビッグテックは韓国よりツール多様性が大きい傾向だ。

- **Mercari** — GHE + Actionsがメイン。セルフホストrunnerをGKEへ。CDはArgo CD + Spinnaker併用。

- **CyberAgent** — 多様な子会社がそれぞれツール選定。Buildkite・CircleCI・GitHub Actionsが共存。

- **楽天 DevOps** — JenkinsからGitLab CIへ移行進行中。規制産業の子会社はGitLab self-managed。

- **DeNA** — GitHub Actions + AWS CodePipeline + 社内internal platform。

- **Pixiv** — GitHub Enterprise + Actions + セルフホストrunner。キャッシュは自社インフラ。

- **SmartHR** — Buildkite + Argo CD。モノレポビルド加速にBuildkiteを積極活用。

興味深い点: 日本企業は**オンプレ比率が韓国より少し高く、GitLab self-managed比率も高め**。規制・セキュリティ要件がより保守的なケースが多い。

第22章 · コスト — 分単価とセルフホスト損益分岐点

2026年5月時点のおおよその分単価(USD/min, Linux基本spec)。

- GitHub-hosted Linux 2-core: 0.008

- GitHub-hosted Linux 8-core(Larger): 0.032

- GitHub-hosted Apple Silicon: 0.16

- GitLab.com saas-linux-medium: 0.01前後

- CircleCI medium: 0.005

- Buildkite: agent運用コストのみ(分単価なし)

- BuildJet 8-core: 0.012

- Blacksmith 8-core: 0.008

- RunsOn(自社AWS): 0.001〜0.003(spot活用)

組織規模別の推奨。

- **月1万分以下**: GitHub Actions hostedが最も合理的。セルフホストは運用コストが上回る。

- **月5万〜30万分**: 外部runner SaaS(BuildJet・Blacksmith)または自社AWSでRunsOnで50%以上削減。

- **月100万分以上**: 自社K8s runner + キャッシュ + レジストリ。ただし専任1〜2名が必要。

キャッシュまで含めた真のコスト = (分単価 × 分) + (キャッシュインフラ費) + (運用時間費)。分単価だけを見ると常に間違った決定になる。

第23章 · よくある罠10個

失敗パターン集。

1. **secretをstdoutに流す** — マスキングは万能ではない。`set -x`と併用しないこと。

2. **`pull_request_target` + 外部コードチェックアウト** — シークレット窃取の常套経路。

3. **単一巨大ワークフロー** — yaml 1000行。分岐・反復・マトリックスが全部1箇所。デバッグ地獄。

4. **キャッシュキーが広すぎる** — 1人の変更が他の人のビルドを壊す。

5. **キャッシュキーが狭すぎる** — キャッシュがほぼ当たらず意味がなくなる。

6. **CIでprod資格情報を直接使う** — OIDC + 一時資格情報に切り替える。

7. **`apply`を誰でも押せる** — Terraform/K8sデプロイに承認フローなし。

8. **flaky testを再実行で誤魔化す** — 根本原因を捕まえないと信頼度が0になる。

9. **デプロイ後の検証なし** — ヘルスチェック・smoke testなしにトラフィックを全切替。

10. **ロールバックが手動** — 障害時の平均復旧時間が10倍になる。

第24章 · ツールを選ぶ7つの基準

要約すると結局この7つを見る。

1. **Gitホスティングとの統合** — GitHubならActionsが99%正解。

2. **K8s比重** — 高ければArgo CD/Flux + Tektonが候補。

3. **モノレポ規模** — 大きいモノレポはBuildkite・Earthly・Bazel・Nx Cloudの組み合わせが強い。

4. **規制要件** — self-managed/オンプレ必須ならGitLab self-managed・Jenkins・Drone。

5. **クラウド依存度** — 1クラウド90%以上ならクラウドマネージドも合理。

6. **チーム規模** — 小チームはSaaS、大チームはセルフホスト + 専任。

7. **コストモデル** — 分単価 + キャッシュ + 運用時間をすべて合算して見る。

選択の本質: **「どのツールが最高か」ではなく「うちの制約の中でどの組み合わせが合理的か」**だ。そしてその組み合わせは1〜2年ごとに再評価すべきだ — 価格もツールも速く変わる。

エピローグ — CI/CDはプラットフォームの神経系だ

この記事の一行要約: **CI/CDはツール選択ではなくプラットフォームデザインだ。**

2026年のCI/CDはどのツールを使うかの問題ではなく、**ビルド → テスト → 署名 → デプロイ → 検証 → ロールバック**という流れをいかに信頼可能にするかの問題だ。GitHub ActionsでもGitLab CIでも、Argo CDでもFluxでも、1つのツールが答えではない。答えは**それらのツールが作る神経系がチームの意思決定速度を決める**という事実そのものにある。

PRがpushされて5分以内に信頼できるシグナルが戻ってくればチームの速度が違う。30分なら人々はコンテキストを失う。1時間なら人々はCIを迂回し始める。**だからCI/CDはツールではなく文化だ。**

次の10年のCI/CDはAIがますます多くの決定を引き受けていく — 何を回さないか、何が壊れたか、何を自動修正するか。しかしその決定の安全線を引くのは依然として人の仕事だ。だからCI/CDをうまく作るとは**自動化の量ではなく自動化の境界を上手に引くこと**だ。

12項目チェックリスト

1. PRシグナルが10分以内に戻ってくるか?

2. キャッシュヒット率を計測しているか?

3. セルフホスト vs SaaSのコストを計算したことがあるか?

4. OIDCでcloud資格情報を受け取っているか(長期キーなし)?

5. ビルドアーティファクトに署名をつけているか(Cosignなど)?

6. SBOMが毎ビルド生成されるか?

7. デプロイがGitOps(Argo/Flux)で宣言的か?

8. canary/blue-greenなどの段階デプロイがあるか?

9. 失敗時に自動ロールバックが動くか?

10. flaky testを隔離する方針があるか?

11. secretを環境変数で受けてstdoutに流していないか?

12. ツール選択を1〜2年ごとに再評価する場があるか?

アンチパターン10個

1. 1つのツールで全部やるという幻想 — 答えは常に組み合わせ。

2. 分単価だけ見て決定 — キャッシュ・運用コストを抜かしている。

3. yaml 1000行ワークフロー — 分岐・反復はコードへ。

4. PR内でprodデプロイ — 承認フローと分離せよ。

5. secretを平文で出力 — `set -x`禁止。

6. flaky test再実行で誤魔化す — 根本原因を捕まえよ。

7. キャッシュinvalidationなしのビルド — 壊れたキャッシュが永遠に残る。

8. デプロイ後検証なし — smoke testは必須。

9. ロールバック手順がドキュメントだけ — 自動化せよ。

10. CI/CD評価を1度もやり直さない — 1〜2年ごとに再評価。

次回予告

候補トピック: **GitOps深掘り — Argo CD vs Fluxの本当の違い**、**モノレポビルド加速 — Bazel・Buck2・Turborepo・Nx比較**、**サプライチェーンセキュリティ — Cosign・SBOM・SLSA実戦適用記**。

> "CI/CDはツールではなく神経系だ。神経系の速度が組織の速度を決める。"

— CI/CDプラットフォーム 2026、終わり。

参考 / References

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

- [GitHub Larger Runners](https://docs.github.com/en/actions/using-github-hosted-runners/about-larger-runners/about-larger-runners)

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

- [GitLab Duo](https://about.gitlab.com/gitlab-duo/)

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

- [CircleCI Sphere — TestGPT](https://circleci.com/blog/announcing-circleci-sphere/)

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

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

- [Dagger GitHub — dagger/dagger](https://github.com/dagger/dagger)

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

- [Drone CI](https://www.drone.io/)

- [Harness CI](https://www.harness.io/products/continuous-integration)

- [Argo CD](https://argo-cd.readthedocs.io/)

- [Flux CD](https://fluxcd.io/)

- [Flagger — progressive delivery](https://flagger.app/)

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

- [OpenShift Pipelines](https://docs.openshift.com/pipelines/)

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

- [Atlantis — Terraform PR automation](https://www.runatlantis.io/)

- [Spacelift](https://spacelift.io/)

- [Pulumi Deployments](https://www.pulumi.com/product/pulumi-deployments/)

- [AWS CodePipeline](https://aws.amazon.com/codepipeline/)

- [Azure Pipelines](https://azure.microsoft.com/en-us/products/devops/pipelines)

- [Google Cloud Build](https://cloud.google.com/build)

- [Google Cloud Deploy](https://cloud.google.com/deploy)

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

- [Namespace](https://namespace.so/)

- [Blacksmith](https://blacksmith.sh/)

- [RunsOn](https://runs-on.com/)

- [Depot](https://depot.dev/)

- [Ubicloud](https://www.ubicloud.com/)

- [Turborepo Remote Cache](https://turbo.build/repo/docs/core-concepts/remote-caching)

- [Nx Cloud](https://nx.app/)

- [Bazel Remote Cache](https://bazel.build/remote/caching)

- [sccache GitHub](https://github.com/mozilla/sccache)

- [Mise](https://mise.jdx.dev/)

- [Cosign / Sigstore](https://docs.sigstore.dev/cosign/overview/)

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

- [SPDX](https://spdx.dev/)

- [CycloneDX](https://cyclonedx.org/)

- [Harbor — CNCF](https://goharbor.io/)

- [Zot Registry](https://zotregistry.dev/)