# GitHub Actions vs Argo Workflows: CI vs K8s エンジン

> GitHub Actions と Argo Workflows をユースケース、ホスティング、設定、スケーリングで比較。Argo は Kubernetes ネイティブのワークフローエンジン。CI とどう異なるかを解説します。

Source: https://latchkey.dev/ja/learn/tool-comparisons/github-actions-vs-argo-workflows  
Updated: 2026-06-26

これらは異なる問題を解決します。Argo Workflows は Kubernetes ネイティブの DAG エンジンで、GitHub Actions は git イベント駆動のCIです。

Argo Workflows はコンテナベースの DAG を Kubernetes 上で実行し、データ/ML パイプラインによく使われます。GitHub Actions はリポジトリイベントで起動する CI/CD です。両者はときに比較されるため、それぞれがどこに合うかを示します。

## Comparison

|  | GitHub Actions | Argo Workflows |
| --- | --- | --- |
| 主な用途 | git イベントでの CI/CD | K8s 上のコンテナ DAG / バッチ |
| 設定 | .github/workflows/*.yml | Workflow の CRD (YAML) |
| ホスティングモデル | GitHubホスト型またはセルフホスト | 自前の Kubernetes クラスタで実行 |
| トリガーモデル | Push、PR、schedule、dispatch | API、イベント、schedule、sensors |
| エコシステム | Actions Marketplace | Argo エコシステム (Events、CD) |
| メンテナンス | 低 (マネージドランナー) | K8s 上で自分で運用 |

## 異なる仕事

Kubernetes に属する重い並列コンテナ DAG (ML トレーニング、ETL) には Argo Workflows を使いましょう。コード変更で起動する build/test/deploy には GitHub Actions を使いましょう。多くのチームは両方を動かします。

## 設定と運用

Argo は Kubernetes ネイティブで、fan-out/fan-in のバッチ処理に強力ですが、クラスタとコントローラーは自分で運用します。Actions はマネージドで git 中心、大規模なマーケットプレイスを持ちます。

## マネージドランナーが合う場面

CI が GitHub Actions で、バッチジョブだけが Argo を必要とするなら、CI は Actions のままにし、そのコストをマネージドランナー (例: Latchkey) で削減しましょう。GitHubホスト型より約70%低く、ウォームプールと自己修復リトライを備えます。

## Migrating between CI platforms: what actually costs time

- Pipeline syntax is the easy part and the part every comparison focuses on. Budget for it, then expect it to be the smallest line item.
- Secrets, OIDC trust relationships, and deploy credentials have to be recreated and re-approved, usually by a different team.
- Caching semantics differ enough that a naive port produces a pipeline that is correct and much slower.
- Required status checks and branch protection reference check names. Renaming them mid-migration blocks merges until the rules are updated.
- Run both in parallel on the same commits until the new one has been green for a full sprint. Cutting over on a green first run is how migrations get rolled back.

## 結論

Kubernetes ネイティブなバッチ/DAG 処理には Argo Workflows を、コード起動の CI/CD には GitHub Actions を選びましょう。両者は競合するより補完し合います。マネージドランナーは Actions 側を安価に保ちます。

## FAQ

### GitHub Actions vs Argo Workflows: CI vs K8s Engine?

Argo Workflows runs container-based DAGs on Kubernetes, often for data/ML pipelines; GitHub Actions is CI/CD triggered by repository events. Teams sometimes compare them, so here is where each fits.

### Different jobs?

Use Argo Workflows for heavy, parallel container DAGs (ML training, ETL) that belong on Kubernetes. Use GitHub Actions for build/test/deploy triggered by code changes. Many teams run both.

### Config and ops?

Argo is Kubernetes-native and powerful for fan-out/fan-in batch work but you operate the cluster and controllers. Actions is managed and git-centric with a large marketplace.

### Where managed runners fit?

If your CI is GitHub Actions and only your batch jobs need Argo, keep CI on Actions and cut its cost with managed runners (e.g. Latchkey): $0.0025/min at 2 vCPU vs $0.006 GitHub-hosted, warm pools, and self-healing retries.

### Which should I choose?

Pick Argo Workflows for Kubernetes-native batch/DAG processing and GitHub Actions for code-triggered CI/CD. They complement more than compete; managed runners keep the Actions side cheap.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt