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個

失敗パターン集。

secretをstdoutに流す — マスキングは万能ではない。set -xと併用しないこと。
pull_request_target + 外部コードチェックアウト — シークレット窃取の常套経路。
単一巨大ワークフロー — yaml 1000行。分岐・反復・マトリックスが全部1箇所。デバッグ地獄。
キャッシュキーが広すぎる — 1人の変更が他の人のビルドを壊す。
キャッシュキーが狭すぎる — キャッシュがほぼ当たらず意味がなくなる。
CIでprod資格情報を直接使う — OIDC + 一時資格情報に切り替える。
applyを誰でも押せる — Terraform/K8sデプロイに承認フローなし。
flaky testを再実行で誤魔化す — 根本原因を捕まえないと信頼度が0になる。
デプロイ後の検証なし — ヘルスチェック・smoke testなしにトラフィックを全切替。
ロールバックが手動 — 障害時の平均復旧時間が10倍になる。

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

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

Gitホスティングとの統合 — GitHubならActionsが99%正解。
K8s比重 — 高ければArgo CD/Flux + Tektonが候補。
モノレポ規模 — 大きいモノレポはBuildkite・Earthly・Bazel・Nx Cloudの組み合わせが強い。
規制要件 — self-managed/オンプレ必須ならGitLab self-managed・Jenkins・Drone。
クラウド依存度 — 1クラウド90%以上ならクラウドマネージドも合理。
チーム規模 — 小チームはSaaS、大チームはセルフホスト + 専任。
コストモデル — 分単価 + キャッシュ + 運用時間をすべて合算して見る。

選択の本質: 「どのツールが最高か」ではなく「うちの制約の中でどの組み合わせが合理的か」だ。そしてその組み合わせは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項目チェックリスト

PRシグナルが10分以内に戻ってくるか?
キャッシュヒット率を計測しているか?
セルフホスト vs SaaSのコストを計算したことがあるか?
OIDCでcloud資格情報を受け取っているか(長期キーなし)?
ビルドアーティファクトに署名をつけているか(Cosignなど)?
SBOMが毎ビルド生成されるか?
デプロイがGitOps(Argo/Flux)で宣言的か?
canary/blue-greenなどの段階デプロイがあるか?
失敗時に自動ロールバックが動くか?
flaky testを隔離する方針があるか?
secretを環境変数で受けてstdoutに流していないか?
ツール選択を1〜2年ごとに再評価する場があるか?

アンチパターン10個

1つのツールで全部やるという幻想 — 答えは常に組み合わせ。
分単価だけ見て決定 — キャッシュ・運用コストを抜かしている。
yaml 1000行ワークフロー — 分岐・反復はコードへ。
PR内でprodデプロイ — 承認フローと分離せよ。
secretを平文で出力 — set -x禁止。
flaky test再実行で誤魔化す — 根本原因を捕まえよ。
キャッシュinvalidationなしのビルド — 壊れたキャッシュが永遠に残る。
デプロイ後検証なし — smoke testは必須。
ロールバック手順がドキュメントだけ — 自動化せよ。
CI/CD評価を1度もやり直さない — 1〜2年ごとに再評価。

次回予告

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

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

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