ArgoCDとは｜GitOpsの仕組み・使い方・Fluxとの違いと案件単価

ArgoCDとは何か（基本定義とGitOpsの位置づけ）

ArgoCDは、Gitを唯一の正（Single Source of Truth）としてKubernetesの状態を保つCDツールです。 一言でいうと、Gitに書いたKubernetesの設定をクラスタへ自動で反映し、ズレを継続的に戻すツールです。

Argo Projectの一部としてCNCFに寄贈され、2022年12月に「Graduated（卒業）」ステータスへ昇格しました。

Gitリポジトリに置かれたマニフェスト（YAML / Helm / Kustomize）を 「あるべき状態（Desired State）」 とみなし、クラスタの 実状態（Live State） との差分を検知して同期します。

公式ドキュメントは Argo CD - Declarative GitOps CD for Kubernetes を参照すると正確です。CNCFのプロジェクトページは CNCF Argo にあります。

GitOpsの基本思想

GitOpsは、Weaveworks社が2017年に提唱した運用パターンです。現在はCNCF配下のOpenGitOpsが、次の4原則として定義を公開しています（OpenGitOps）。

ArgoCDは、このうち特に後半2つ（自動取得と継続的な調整）を強く担う実行役です。前半2つは、Git運用やレビュー設計と組み合わせて成立します。

ArgoCDが解決する課題

• kubectl applyの手作業オペレーションで、クラスタごとの差異が生まれる

• JenkinsからCLIでデプロイすると、誰が・いつ・何を変えたかがJenkins側のログに散る

• マニフェストのリポジトリと実環境がズレても気づきにくい

• ロールバック時に、過去のマニフェストをどこまで戻すかが曖昧になる

バージョンとサポート期間（2026年9月時点）

ArgoCDのマイナー版は年4回（2・5・8・11月）出ます。パッチが提供されるのは直近3つのマイナー版だけです（リリースとサポート方針）。

つまり、1つのマイナー版を使える期間はおよそ9か月です。2026年9月時点では、最新安定版は3.5系で、3.6のリリース候補が公開されています。最新の状況はGitHubのリリース一覧で確認してください。

2025年に出た3.0では、既定の挙動がいくつか変わりました。2系の記事や社内手順書を参考にするときは、次の点に注意してください（2.14から3.0へのアップグレードガイド）。

• リソースの追跡方法の既定が、ラベルからアノテーションに変わった

• Applicationへのupdate / delete権限が、配下のリソースに自動では及ばなくなった

• ログの閲覧に明示的な権限が必要になった

• argocd-cmでのリポジトリ設定が廃止され、Secretでの登録に一本化された

ミニFAQ：

• Q. GitOps＝ArgoCDですか？ GitOpsは運用パターンの名前で、実装ツールはArgoCDのほかにFluxなどがあります。違いは後述の「ArgoCDとFluxの違い」で整理しています。

• Q. ArgoCD単体でCIまでこなせますか？ いいえ。ArgoCDはCD側に特化しているため、ビルド・テストはGitHub ActionsやJenkinsと組み合わせるのが基本構成です。

ArgoCDのアーキテクチャと主要コンポーネント

ArgoCDは複数のコントローラとサーバが疎結合に動く構成です。ApplicationなどのCRD（カスタムリソース）を中心に、各コンポーネントはDeployment / StatefulSetとしてKubernetes上で稼働します。標準のインストールマニフェストには、次のコンポーネントが含まれます。

以前は別プロジェクトだったApplicationSetとNotificationsも、現在は標準インストールに同梱されています。

Applicationリソースという中心概念

ArgoCDのオペレーションは、Application というCRDを軸に進みます。Applicationには「どのGitリポジトリ・どのパス・どのリビジョン」を「どのクラスタ・どのNamespace」に同期するかを宣言します。

Application自体もマニフェストで管理できます。そのため、「ApplicationそのものをGitで管理する」 という再帰的な構成（いわゆるApp of Apps）が組めます。これがArgoCDの拡張性の核です。

同期（Sync）の流れ

1. Application ControllerがGitとクラスタを定期的に（あるいはWebhookで即時）比較する

2. 差分があるとOutOfSyncと判定される

3. 自動同期が有効ならその場で適用、手動同期なら差分を表示して待つ

4. 適用後に再度差分を確認し、Syncedになれば完了

公式FAQによると、既定のポーリング間隔は約3分（120秒＋最大60秒のジッター）です（Argo CD FAQ）。Push型のCDツールと違い、デプロイ後も差分検知が続く点が特徴です。

ミニFAQ：

• Q. マージしてから反映まで何分かかりますか？ Webhookなしなら最大で約3分待つことがあります。数十秒以内に反映したい現場では、GitプロバイダからのWebhookを併用します。

ArgoCDの主要機能

ArgoCDが選ばれる理由は、UIと運用機能の作り込みにあります。代表的な機能を整理します。

差分の可視化

Webコンソールで、Git上のマニフェストと実状態のYAML差分を行単位で確認できます。「誰かが手で変えたフィールド」が一目で分かるため、ドリフト調査の手間が減ります。

自己修復（Self-Heal）

クラスタ上で手作業の変更が入ったとき、宣言状態へ自動で戻す機能です。kubectl editによる緊急対応がそのまま残り続ける、というよくある事故を防げます。

同期ウェーブ（Sync Waves）と同期フェーズ（Hooks）

リソースの適用順序を制御する機能です。PreSync / Sync / PostSyncのフェーズに分け、たとえば「DBマイグレーションのJobを先に流してからDeploymentを更新する」といった順序制御ができます。

マルチクラスタ管理

1つのArgoCDから複数クラスタをまとめて管理できます。本番・ステージング・開発の同期状況を1画面で把握できるので、SREの確認作業がまとまります。

RBACとSSO

プロジェクト（AppProject）単位で、誰がどのアプリを操作できるかを制御します。Dexを介して、Google Workspace・GitHub・Okta・Microsoft Entra IDなどとSSO連携できます。

Helm / Kustomize / 生マニフェストの対応

ArgoCDは描画エンジンを内蔵しており、以下の形式をそのまま読み込めます。

Helmについては注意点が1つあります。ArgoCDはhelm installではなくhelm templateで描画したマニフェストを適用するため、helm listなどのHelmコマンドではリリースとして見えません（Argo CD FAQ）。Helmのリリース履歴を前提にした運用手順がある現場では、移行前に確認が必要です。

ArgoCDの使い方（導入と初期セットアップ）

導入は比較的シンプルです。公式マニフェストか公式Helmチャートで、検証環境なら短時間で立ち上げられます。本番運用に乗せる場合は、SSO・Ingress・Secret管理・権限設計の設計工数を別に見込みます。

最小構成での導入手順

実際のコマンドは公式のGetting Startedに沿って進めるのが確実です。流れは次のとおりです。

1. argocd Namespaceを作成する

2. 公式マニフェスト（install.yaml）または公式Helmチャートで、前述のコンポーネント一式をデプロイする

3. argocd CLIをローカルにインストールする

4. 初期管理者パスワードをargocd-initial-admin-secretから取得する

5. argocd loginでCLIから接続し、最初のApplicationを宣言する

本番運用前にやるべき設定

• 初期パスワードを変更し、adminでの直接ログインを無効化する

• DexまたはAPI Serverに直接OIDC / SAMLを設定する

• TLS終端をIngressやサービスメッシュ側で済ませる

• ArgoCDのインストールマニフェスト自体もGit管理する（ブートストラップ手順を文書化する。初期構築の自動化にはArgo CD Autopilotという補助ツールもある）

• 設定のバックアップとして、argocd admin export / importの手順を用意する

• アップグレードの頻度を決める（サポートは約9か月なので、少なくとも半年に1回はマイナー版を上げる計画が現実的）

ネットワーク経路で詰まりやすい点

• Gitプロバイダ（GitHub / GitLab / Bitbucket）へのアウトバウンド通信が通っているか

• WebhookがGitプロバイダからArgoCDのAPI Serverに届く経路になっているか（社内クラスタの場合はリバースプロキシ経由で受ける設計を検討）

• プライベートリポジトリ用のクレデンシャルを、Sealed SecretsやExternal Secrets Operatorで管理しているか

ArgoCDとCI/CDツールの違いと組み合わせ

ArgoCDを単独で評価するより、CI側のツールとどう繋ぐかを整理したほうが実務のイメージがつかみやすくなります。

役割の違い

よくある組み合わせパターン

• GitHub ActionsでビルドとコンテナイメージのPushを行い、マニフェストリポジトリのタグをBotで書き換える。ArgoCDがその差分を検知して同期する

• Jenkinsで既存のビルドパイプラインを使い続け、デプロイ部分だけをArgoCDへ寄せる

• CircleCIでテスト・ビルド・セキュリティスキャンを実行し、イメージタグの更新はArgo CD Image Updaterに任せる

• GitLab CIとGitLabリポジトリのまま完結させ、ArgoCDをデプロイ層に組み込む

マニフェストリポジトリは分けるか同居か

CIとCDの境界を切るうえで、よく議論になる論点です。

• 分ける派：アプリコードとマニフェストを別リポジトリにする。CIはイメージをビルドし、Botがマニフェストリポジトリのタグを更新する。権限分離と監査ログが綺麗になる

• 同居派：モノレポでアプリとマニフェストを同居させ、PR単位でアプリとインフラの変更を一緒にレビューする。学習コストは低い

中小規模では同居が選ばれやすく、複数チーム・複数サービスをまたぐ構成では分離が選ばれやすい傾向があります。権限分離の要件が強ければ、小規模でも分離を選ぶ価値があります。

ミニFAQ：

• Q. ArgoCDだけ導入すればCI/CDは完結しますか？ いいえ。ビルドとイメージのPushは別途必要です。「マニフェストはGitにある」状態を作るCI側の仕組みを必ず併設します。

ArgoCDとFluxの違い

ArgoCDとFluxは、どちらもCNCF卒業のGitOpsツールで、Gitの宣言をクラスタへ寄せ続けるという目的は同じです。 違いが出るのは、操作の入口とHelmの扱い、イメージ更新の仕組みです。

選び方の目安は次のとおりです。

• 開発チームにも同期状態を見せたい、承認や手動同期を画面で回したいならArgoCDが候補になりやすい

• Helmのリリース管理をそのまま生かしたい、Kubernetesの仕組みだけで軽く運用したいならFluxが候補になりやすい

Fluxの開発を主導したWeaveworks社は2024年に事業を終えましたが、FluxはCNCFのプロジェクトとして開発が続いています（Flux公式サイト）。案件の要件にはArgoCDとFluxが「いずれかの経験」と並記されることもあるため、片方を実務で使った経験があれば、もう片方も概念は流用できます。

Kubernetes運用でのケース別活用パターン

ArgoCDは、規模やチーム構成によって使われ方が変わります。実務でよく見るパターンを整理します。

ケース1：単一クラスタ・小規模Webサービス

ステージングと本番のNamespaceが同居している、または2クラスタ程度の構成です。App of Apps で1つの親Applicationから子Applicationをまとめてデプロイする運用が手早く立ち上がります。Helmチャート1本で完結するケースが多く、導入効果が見えやすい規模です。

ケース2：マイクロサービス×複数チーム

サービスごとにマニフェストのディレクトリやリポジトリを分け、AppProjectでチームの権限を切ります。ApplicationSet を使うと、リポジトリ単位・クラスタ単位でApplicationを動的に生成でき、新規サービスの追加が宣言的に行えます。

ケース3：マルチクラスタ・マルチリージョン

本番／ステージング／開発／DR用と、複数クラスタを束ねる構成です。管理用の1台のArgoCDから対象クラスタをまとめて見るパターンと、各クラスタにArgoCDを置いて中央リポジトリを共有するパターンがあります。

後者は中央の障害時に影響範囲が小さくなる代わりに、ArgoCD自体の運用台数が増えます。

ケース4：規制業界・金融系

PreSyncフックでセキュリティ検査を必須化し、Sync Wavesでデータベース・アプリ・Ingressの順序を厳密に制御する運用です。ロールバック手順をGit revertでクラスタ状態が戻る形に揃えられるので、変更履歴を監査に使いたい現場と相性が良いケースが多くなります。

ケース5：PRごとのプレビュー環境

ApplicationSetのPull Requestジェネレータで、PRごとにプレビュー環境を立ち上げる使い方です。「マージ前にレビュアーが実際に触れる」環境を用意できます。

ArgoCDの運用でよくある失敗と対策

導入後に詰まりやすいポイントです。最初から設計に入れておけば避けやすい論点が並びます。

失敗1：自動同期と自己修復を雑にONにする

緊急対応でkubectl editした内容が次の同期で戻ってしまい、対応が振り出しに戻る事故が起きます。prune（孤立リソースの削除）とselfHeal（手動変更の上書き）の有効化方針を、Application / AppProjectの設計の中で明示的に切り分けてください。

運用に不慣れな段階では、手動同期＋自己修復オフから始めると事故を減らしやすくなります。

失敗2：Secret管理が後回しになる

ArgoCD自体には、Secretを暗号化してGitに置く仕組みがありません。Sealed Secrets / External Secrets Operator / SOPS などを併設し、Gitに平文のSecretを置かない設計が必要です。どの方式で行くかを決めてから、Applicationを切り始めます。

失敗3：Webhookの戻り経路を作っていない

GitHubからArgoCDへWebhookを送る経路を設計しておらず、結局ポーリング頼りで反映が遅い、というケースです。Cloudflare Tunnel・リバースプロキシ・公開Ingressなどを使い、Gitプロバイダ→ArgoCD API Serverのインバウンド経路を開通させます。

失敗4：リポジトリURLにHTTPSとSSHが混在

https形式とgit@github.com形式のURLが混在すると、認証情報の登録漏れや、同じリポジトリの二重登録が起きます。プロジェクト内で1方式に統一し、リポジトリの認証情報を先に登録しておきます。

失敗5：ApplicationSetのテンプレート修正が全Applicationに波及

Generatorのテンプレートを書き換えると、生成される全Applicationに変更が一斉に反映されます。テンプレートの誤りが、そのまま全サービスのOutOfSyncや意図しない削除につながる事故です。

ApplicationSetの同期ポリシー（applicationsSyncでcreate-onlyなどに制限する、preserveResourcesOnDeletionで削除時にリソースを残す）を先に決めておきます。テンプレート修正は、検証用のApplicationSetで差分を確認してから本番に反映する手順を踏みます。

失敗6：Helmチャートのバージョン固定漏れ

外部Helmチャートのバージョン指定（targetRevision）に「*」のような範囲指定を使うと、チャートの更新を意図せず取り込み、ある日突然挙動が変わります。チャートバージョンは明示的に固定し、Renovateなどで更新PRを通します。

失敗7：ArgoCD本体のアップグレードを放置する

パッチが出るのは直近3つのマイナー版だけなので、1年近く上げないとサポート外になります。3.0のように既定の挙動が変わる版もあるため、アップグレードは検証クラスタで試してから本番に入れる前提で、年2回以上の計画に組み込みます。

ArgoCDを活かせるフリーランス案件の動向と単価

公開案件を見る限り、ArgoCDは案件名の主役より、Kubernetes運用・SRE・DevOps・プラットフォームエンジニアの案件の要件欄に書かれることが多い技術です。 そのため単価は、ArgoCDではなく「Kubernetesを扱う案件」の母集団で見るのが実態に近くなります。

募集の出方の傾向

• 「Kubernetes（EKS / GKE / AKS）の運用経験」と並べて、ArgoCDが要件に書かれる

• Helm / Kustomize / Terraformと同列で記載される

• 「GitOps運用の設計・推進」をミッションに掲げる案件もある

• SRE / DevOps系のポジションでは、必須でなく歓迎スキルとして書かれることが多い

フリコンでもArgoCDは検索用のスキルタグになっていません。Kubernetes案件一覧の先頭50件（表示順であり無作為抽出ではありません）の案件名にも、ArgoCDの語は出てきませんでした。

フリコン掲載のKubernetes案件304件で見る単価分布

以下は、フリコンに掲載中の公開案件のうち、スキルにKubernetesが付いた304件の集計です（2026年9月25日取得）。帯の区分も平均も、各案件の募集単価レンジの上限値で集計した掲載単価で、成約単価ではありません。帯は上限値が「○万円以上○万円未満」に入るかで区分しています。比較用に全掲載64,434件の分布も並べています。

掲載分布を見ると、Kubernetes案件は全掲載より低単価帯が少なく（70万円未満の比率は3分の1以下）、高単価帯が多い（100万円以上の比率は約1.8倍）傾向があります。最多の帯は80万円以上〜90万円未満（86件）でした。

ただし、この差は「Kubernetesを学べば単価が上がる」ことを直接示すものではありません。Kubernetesが付く案件には、基盤設計やSRE・プラットフォームなど担当範囲の広い職種が多く含まれるため、職種構成の違いが単価差に出ている可能性があります。

実際、フリコンのDocker案件762件を要件別に集計した際（2026年9月4日）は、Kubernetes併記の有無で単価の中央値に差はありませんでした。差が出たのは、マネジメント（＋10万円）とCI/CD（＋5万円）という担当範囲の側です。

Kubernetes案件の最新の掲載状況は、Kubernetesのフリーランス案件一覧で確認できます。

単価に効くのは「担当範囲の広がり」

ArgoCDの経験を単価につなげるには、触ったことがあるかより、どこまでを自分で決めたかを示すほうが評価されやすくなります。

スキルシートには「ArgoCD使用」だけでなく、「Application数」「管理クラスタ数」「同期ポリシーを決めたか」「アップグレードを担当したか」を数字で書くと、担当範囲が伝わります。

自分の経験でどのくらいの単価を狙えるかは、無料のフリーランスエンジニア単価診断で市場単価の目安を確認できます。単価を体系的に上げる考え方は『フリーランスエンジニアの単価相場と単価の上げ方』で、SRE・DevOps職の月額レンジは『SREフリーランスの単価相場』で整理しています。

求められる併用スキル

• Kubernetes本体：Pod / Service / Ingress / NetworkPolicyレベルでの設計と障害対応（Kubernetesとは）

• Helm / Kustomize：テンプレート設計、共通化、上書き戦略

• IaC：Terraform / Pulumi / Crossplane（Terraformとは）

• 可観測性：Prometheus / Grafana / Datadogでのメトリクス・ログ・トレース基盤（Prometheus & Grafanaとは）

• クラウドネイティブ系：AWS Lambda・Cloud Runなどサーバーレスとの使い分け判断

関連職種

• DevOpsエンジニアとしてプラットフォーム改善をリードする

• SREとしてSLO運用とリリースエンジニアリングを担う

• プラットフォームエンジニアとして、開発者向けの共通基盤にGitOpsを組み込む

• インフラエンジニア / クラウドエンジニアからのキャリアの発展先として位置づけられる

複数の案件で迷ったときは、単価だけでなく担当範囲や稼働条件も含めて比べると判断がぶれにくくなります。比べ方は『案件の選び方｜フリーランスエンジニアが単価・稼働・スキルで決める優先順位』にまとめています。

ミニFAQ：

• Q. ArgoCDだけ書ける状態で案件は取れますか？ 単体スキルのみの募集はほぼ見かけません。Kubernetes本体の運用経験とCI/CDツールの実装経験とセットで、初めて強みになります。

ArgoCD導入チェックリスト

導入前後で確認すべき論点を一覧にしました。社内提案や設計レビューの叩き台として使えます。

まとめ

ArgoCDは、GitにあるKubernetesマニフェストを継続的に同期し、実環境とのズレを検知・修復するGitOpsのCDツールです。案件ではArgoCD単体より、「Kubernetes運用をどこまで設計したか」が評価されやすくなります。

• ArgoCDはKubernetes専用・Pull型・宣言的なGitOpsのCDツール

• ビルド・テストはGitHub Actions / Jenkins / CircleCI / GitLab CIに任せ、デプロイ後の同期と自己修復をArgoCDが担う

• Fluxとの違いは、Web UIの有無、Helmの扱い（描画して適用かリリース管理か）、イメージ自動更新の仕組み

• 設計の最初に決めるのは「マニフェストリポジトリ構成」「Secret管理方式」「Webhook経路」「自動同期・自己修復の方針」「アップグレード計画」

• フリコン掲載のKubernetes案件304件では平均87万円、100万円以上が23.4%（2026年9月25日時点・掲載単価）。単価差は担当範囲の広さに出やすい

次の一歩としては、検証用クラスタを1つ用意して公式マニフェストでArgoCDを立ち上げ、自分のサンプルアプリを1本Applicationとして宣言してみるところから始めるのが効率的です。Kubernetes・Docker・DevOpsエンジニアの記事もあわせて読むと、案件応募時に経験を説明しやすくなります。今の経験で狙える単価の目安は、フリーランスエンジニア単価診断で確認できます。

参照元・関連リンク：

• Argo CD公式ドキュメント

• Argo CD FAQ（ポーリング間隔・Helmの扱い）

• Argo CD リリースとサポート方針

• CNCF Argoプロジェクトページ

• argoproj/argo-cd（GitHub）

• OpenGitOps（GitOpsの4原則）

• Flux公式サイト