2026.07.22 インフラ

ArgoCDとは？GitOpsによるKubernetes継続的デリバリーの仕組みと導入判断を実装者目線で解説

ArgoCD（Argo CD）は、Gitリポジトリを「信頼できる唯一の情報源」として、Kubernetesクラスターの状態をマニフェストどおりに保ち続ける宣言的なGitOps継続的デリバリーツールです。この記事では、クラスター内のArgoCDがGitを定期的に読みに行って差分を埋めるプル型同期の仕組み、Application・Sync・Self-healといったコア概念、App of AppsやApplicationSetで多数のアプリを束ねる方法を一次情報で整理します。さらに、CI/CDパイプラインやFlux CDとの役割分担、ArgoCDを採用すべき条件と見送るべき場面まで、Kubernetes運用の設計で迷う論点を実装者目線で示します。

まとめ：ArgoCDの仕組みとGitOps運用・採用判断の要点

ArgoCDは、Kubernetesへ何をデプロイするかをGit上のマニフェストで宣言し、クラスター内のArgoCDがそのGitを定期的に読みに行って、実際のクラスター状態を宣言状態へ継続的に近づけるプル型のGitOpsツールです。CIがコンテナイメージをビルドしてレジストリへ押し込むところまでを担い、ArgoCDはその先の「クラスターへ届ける」CDフェーズを引き受ける、と役割を分けると全体像が整理できます。

ArgoCDはArgoプロジェクトの一部としてCNCF Graduated（Argoは2022年12月にGraduated到達）に位置づけられ、本番Kubernetesのアプリ配信で広く使われています。安定版はv3.4系（2026年7月時点）で、ApplicationSetを中核に据えたv3.5が準備段階です。導入の是非は、Kubernetesを常時運用しておりデプロイの監査性・再現性を高めたいか、という条件で見極めます。本記事後半の採用条件と見送り条件を自社の運用体制に当てはめて判断してください。

ArgoCDの仕組み：GitOpsとプル型同期でクラスターを保つ基本構造

ArgoCDを設計に落とすには、GitOpsという運用モデルと、ArgoCDがクラスター側から動く「プル型」であることを最初に押さえます。デプロイ先であるコンテナオーケストレーション（Kubernetes）の役割を前提に、Gitとクラスターの関係を捉えると構造が見通せます。

GitOpsという運用モデルとArgoCDが担う継続的な反映役割

GitOpsは、インフラやアプリの望ましい状態をすべてGitに宣言的マニフェストとして記述し、そのGitを唯一の情報源とする運用スタイルです。誰かがkubectlで直接クラスターをいじるのではなく、変更はGitへのコミットとして残し、そこから自動でクラスターへ反映させるのが基本です。これにより「今クラスターに何が入っているか」がGitの履歴とひも付き、変更の監査・レビュー・巻き戻しがコード管理の作法で回せるようになります。ArgoCDはこのGitOpsの反映役として、Gitの宣言状態とクラスターの実状態を突き合わせ、差分を埋める同期を担当します。

プル型（Pull）同期と従来のプッシュ型デプロイの構造的な違い

従来のCIツールからのデプロイは、パイプラインがクラスターの認証情報を握って外からkubectl applyを打つプッシュ型でした。ArgoCDはこれを反転させ、クラスター内で動くArgoCD自身がGitを定期的にポーリングして差分を取り込むプル型を採ります。プル型では、クラスターの強い認証情報を外部のCIへ渡さずに済むため権限の露出が減り、ネットワーク的にもクラスターから外向きにGitを読むだけで反映が完結します。CIとCDの責務が切り離され、CI基盤が停止していてもクラスターはGitの宣言状態を保ち続けられる点が実務上の違いです。

Application・同期（Sync）・自己修復（Self-heal）というコア概念

ArgoCDの操作単位はApplicationというカスタムリソースで、「どのGitリポジトリのどのパスを、どのクラスターのどの名前空間へ反映するか」を1つのApplicationとして定義します。ArgoCDはこのApplicationごとに、Gitの宣言状態とクラスターの実状態を比較し、ずれていればSync（同期）で宣言状態へ寄せる仕組みです。人がクラスターを手で書き換えて宣言からずれた状態はドリフトと呼ばれ、ArgoCDのUI上でOutOfSyncとして可視化されます。Self-heal（自己修復）を有効にすると、こうした手動変更を検知して自動でGitの状態へ巻き戻すため、クラスターが宣言から乖離し続けるのを防げます。

ArgoCDの主要機能と大規模運用へスケールさせるための仕組み

単一アプリの同期だけならApplication1つで足りますが、実運用では複数チーム・複数環境・複数クラスターへ広がります。ArgoCDはそこを束ねるための機能を備えており、規模に応じて使い分けます。

Syncポリシーによる自動同期・手動同期とドリフト検知の設計

同期をいつ走らせるかはSyncポリシーで決める設計です。Manualは差分が出てもUIやCLIから人が承認して初めて反映する方式で、本番のように反映タイミングを握りたい環境に向きます。Automaticはコミットを検知して自動反映する方式で、ここにprune（Gitから消したリソースをクラスターからも削除）とselfHeal（手動変更の自動巻き戻し）を組み合わせると、Gitが常にクラスターの正になります。開発環境はAutomatic＋selfHealで手離れさせ、本番はManualで承認を挟む、といった環境別のポリシー設計が定石です。

App of AppsパターンとApplicationSetによる大規模管理

アプリが増えるとApplicationを1つずつ手で作るのが重くなります。App of Appsパターンは、子Applicationを束ねる親Applicationを1つ置き、親を同期すれば配下のアプリ群がまとめて展開される構成です。さらにApplicationSetは、1つの定義からクラスター一覧やGitのディレクトリ構造をもとに複数のApplicationを自動生成する仕組みで、「同じアプリを10クラスターへ」「モノレポ配下の各サービスを一括で」といった横展開をテンプレート化できます。ApplicationSetは準備中のv3.5で中核機能として強化される方向で、マルチクラスター運用の起点になります。

Web UI・CLIとRBAC・SSOによるチーム単位の運用統制

ArgoCDはアプリの依存関係や同期状態をツリーで見せるWeb UIと、パイプラインへ組み込みやすいCLI（argocdコマンド）の両方を持ちます。どのアプリが同期済みか、どこがOutOfSyncかがひと目で分かるため、障害時の切り分けを速められるのが利点です。統制面では、SSO連携（OIDCなど）でシングルサインオンを効かせ、RBACでチームごとに触れるプロジェクトや操作を絞れます。宣言状態そのものはIaC（Infrastructure as Code）の考え方と地続きで、インフラもアプリもGit管理へ寄せると運用の一貫性が高まります。

ArgoCDを採用すべき条件とCI/CD・Fluxとの使い分け

ここでは判断を言い切ります。ArgoCDはGitOpsの反映を強力に自動化する一方、Kubernetesを常時運用する前提とGit中心の運用規律を要求します。自社のどこにArgoCDを差し込むかを、条件付きで見極めてください。

ArgoCDの採用が効くワークロードの条件と導入設計を始める起点

採用が効くのは、Kubernetesクラスターを継続運用しており、デプロイの監査性・再現性・巻き戻しやすさを底上げしたい、複数環境や複数クラスターへ同じ構成を横展開したい、手動オペレーションによる構成のずれを止めたい、という条件が重なるときです。こうしたKubernetes基盤の構築とGitOps運用を自社へ取り入れるなら、AWS・Google Cloudを含むクラウドインフラ構築の相談窓口で、クラスター設計やSyncポリシー方針、権限統制の妥当性を相談するとよいでしょう。ArgoCD自体を動かす基盤としては、マネージドKubernetesのAmazon EKSのようにコントロールプレーンを委ねられるサービスから入ると、立ち上げの負荷を抑えられます。

CI/CDパイプラインとの役割分担（ArgoCDはCIではない）

誤解しやすいのは、ArgoCDがCIまで担うと考えてしまう点です。ArgoCDが引き受けるのはあくまでCD（クラスターへの反映）で、ソースのテストやコンテナイメージのビルドといったCIフェーズは別途GitHub ActionsやほかのCIツールが担います。全体像はCI/CDの仕組みと導入判断を押さえたうえで、CIがイメージをビルドしてマニフェスト用のGitを更新し、その先をArgoCDが同期する、という分業に落とすと役割が濁りません。CIとCDを分離することで、CI基盤の障害がクラスターの状態維持に波及しない構成になります。

Flux CDと比べたときの選び分けとArgoCDを見送るべき場面

GitOpsツールの代表格にはArgoCDとFlux CDがあり、どちらもCNCFのGitOps系プロジェクトです。ArgoCDは視認性の高いWeb UIと、Application中心のマルチテナント運用に強みがあり、開発チームが同期状態を目で追いたい現場に向きます。Fluxはコントローラー分割の軽量な構成でGit中心の自動化に寄っており、UIより宣言と自動化を優先する現場に向きます。一方で見送るべきなのは、そもそもKubernetesを使っていない、あるいはアプリが1本で環境も1つしかなく、GitOpsの規律とツール運用のコストに見合わないケースです。少数のアプリを手動デプロイで回せているうちは、ArgoCDの導入がかえって運用の重さを増やします。反映後の状態を継続的に見張るKubernetesの監視・モニタリングとセットで運用体制を組めるかも、採用可否の分かれ目です。

よくある質問

ArgoCDの導入検討で実装者から多く挙がる質問を、一次情報に基づいて簡潔に整理します。

ArgoCDとFlux CDはどちらを選ぶべきですか？

どちらもCNCFのGitOps継続的デリバリーツールで、Gitを情報源にクラスターを同期する目的は同じです。ArgoCDは同期状態を可視化するWeb UIとApplication中心のマルチテナント運用が強みで、チームで同期状態を目視したい現場に向きます。Fluxはコントローラー分割の軽量構成でGit中心の自動化に寄ります。UIとマルチテナント統制を重視するならArgoCD、軽量な自動化を重視するならFluxが起点の分岐です。

ArgoCDのプル型はプッシュ型のデプロイと何が違いますか？

プッシュ型はCIパイプラインがクラスターの認証情報を持って外から反映するのに対し、プル型はクラスター内のArgoCDがGitを読みに行って自ら反映します。プル型ではクラスターの強い認証情報を外部CIへ渡さずに済み、権限の露出を抑えられるのが利点です。またCIとCDが分離されるため、CI基盤が停止してもクラスターはGitの宣言状態を保ち続けられます。

ArgoCDのSelf-heal（自己修復）とは何ですか？

クラスターを人が手で書き換えてGitの宣言状態からずれた（ドリフトした）ときに、その変更を検知して自動でGitの状態へ巻き戻す機能です。Automatic Syncと合わせて有効にすると、Gitが常にクラスターの正となり、手動オペレーションによる構成の乖離が積み上がるのを防げます。本番など反映タイミングを握りたい環境では、あえて無効にして手動承認を挟む設計もとれます。

ApplicationSetとApp of Appsはどう使い分けますか？

App of Appsは親Applicationで子Applicationを束ね、親を同期すれば配下がまとめて展開される構成で、少数のアプリ群を階層でまとめたいときに向きます。ApplicationSetは1つの定義からクラスター一覧やディレクトリ構造をもとに複数のApplicationを自動生成する仕組みで、同じ構成を多数のクラスターや環境へテンプレート展開したいときに向きます。横展開の規模が大きいほどApplicationSetの効果が際立つでしょう。

ArgoCDはCI/CDのどこを担いますか？

ArgoCDが担うのはCD（クラスターへの反映）で、CI（テストやコンテナイメージのビルド）は別のCIツールが担当します。一般的な分業は、CIがイメージをビルドしてマニフェスト用のGitを更新し、その差分をArgoCDが同期する形です。ArgoCD単体ではビルドは行わないため、CIツールと組み合わせて初めてCI/CD全体が完成します。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る