ArgoCDとは｜GitOpsの仕組み・Kubernetes運用と案件動向

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

ArgoCDは、Argo Projectの一部としてCNCFに寄贈され2022年に「Graduated（卒業）」ステータスへ昇格した、Kubernetes向けの宣言的GitOpsデリバリーツールです。Gitリポジトリに置かれたマニフェスト（YAML / Helm / Kustomize）を 「あるべき状態（Desired State）」 とみなし、クラスタの 実状態（Live State） との差分を検知して継続的に同期します。

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

GitOpsの基本思想

GitOpsは、Weaveworks社が2017年に提唱した運用パターンです。中核となる考え方は次の4点に集約されます。

• 宣言的：システム全体を宣言的なマニフェストで表現する

• バージョン管理：それらをGitで管理し、変更履歴とレビューを残す

• 自動化：マージされた状態が自動的にクラスタへ反映される

• 自己修復：実状態がドリフトしても、宣言された状態に戻す

ArgoCDは、この4点のうち自動化と自己修復を担うコンポーネントとして位置づけられます。

ArgoCDが解決する課題

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

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

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

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

ミニFAQ：

• Q. GitOps＝ArgoCDですか？ GitOpsはあくまで運用パターンの名前で、実装ツールはArgoCDのほかにFluxなどがあります。本記事ではArgoCDに絞って解説します。

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

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

ArgoCDは複数のコントローラとサーバが疎結合に動く構成で、すべてKubernetesのカスタムリソース（CRD）とDeploymentとして稼働します。

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となれば完了

Application Controllerが既定では一定間隔のポーリングで宣言状態と実状態を比較し、Webhookを併用するとより早く反映できます。Push型のCDツールと違い、デプロイ後も差分検知が継続する点が特徴です。

ミニFAQ：

• Q. WebhookでGitHubからイベントを受けないと反映が遅いですか？ 既定では一定間隔のポーリングで動作するため反映には待ち時間が乗ります。反映遅延を短くしたい現場では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、Azure ADなどとSSO連携できます。

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

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

ArgoCDの導入と初期セットアップ

導入は比較的シンプルで、Helmチャートまたはマニフェスト一括適用で検証環境であれば短時間で立ち上げられます。本番運用に乗せる場合はSSO・Ingress・Secret管理・権限設計を含めるため、別途設計工数を見込む必要があります。

最小構成での導入手順

具体的な流れは次のとおりです。

1. argocd Namespaceを作成する

2. 公式マニフェストまたは公式Helmチャートでargocd-server / argocd-application-controller / argocd-repo-server / argocd-dex-server / argocd-redis を一括デプロイする

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

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

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

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

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

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

• TLS終端をIngress / Service Mesh側で済ませる

• ArgoCDのインストールマニフェスト自体もGit管理する（ブートストラップ手順を文書化）

• バックアップとして、Argo CD Autopilotやargocd admin export を活用する

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

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

• WebhookがGitプロバイダからArgoCDのAPI Serverに届く経路になっているか（社内クラスタの場合はReverse Proxy経由で外に出す設計を検討）

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

ミニFAQ：

• Q. Webhookは必須ですか？ 動かすだけならポーリングで足ります。ただし本番では「マージから反映までの待ち時間」が許容されるかで判断します。許容できない現場ではWebhookを併用する構成を検討します。

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

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

役割の違い

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

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

• Jenkinsで既存のビルドパイプラインを継続利用し、デプロイ部分のみArgoCDへ寄せる

• CircleCIでテスト・ビルド・セキュリティスキャンを実行し、ArgoCD ImageUpdaterで自動的にマニフェストを更新

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

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

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

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

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

中小規模なら同居、複数チーム・複数サービスを跨ぐなら分離、という選び方が現実的です。

ミニFAQ：

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

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

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

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

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

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

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

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

本番／ステージング／開発／DR用と複数クラスタを束ねる構成です。1台の管理用ArgoCDから対象クラスタをまとめて見るパターンと、各クラスタにArgoCDを置いて中央リポジトリを共有するパターンがあります。後者は中央障害時のブラスト半径が小さくなる代わりに、運用台数が増えます。

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

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

ケース5：DRY-RUN・PR環境

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

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

実際に詰まりやすいポイントを整理します。導入後の運用を見据えると最初から避けやすい論点です。

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

緊急対応でkubectl editした内容が次の同期で戻ってしまい、対応が振り出しに戻る事故が起きます。対策としては、prune（孤立リソースの削除）やselfHeal（手動変更の上書き）の有効化方針を、Application / AppProject設計の中で明示的に切り分けます。最初は手動同期＋自己修復オフから始めるのが安全です。

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

ArgoCDは公開鍵暗号でSecretを直接管理しません。Sealed Secrets / External Secrets Operator / SOPS などを併設して、Gitに平文Secretを置かない設計が必要です。導入前にどの方式で行くかを決めてからApplicationを切り始めます。

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

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

失敗4：ApplicationのGit URLにHTTPSとSSHが混在

HTTPSとSSHのURL（https形式とgit@github.com形式）が混在すると、認証情報の登録ミスやリダイレクトループが発生します。プロジェクト内で1方式に統一し、Repositoryリソースで先に登録しておきます。

失敗5：ApplicationSetのテンプレート修正でクラスタ全停止

Generatorのテンプレートを書き換えた瞬間、全Applicationが再生成され、結果として全リソースが一度OutOfSyncと判定される事故です。自動同期とPruneの設定（spec.syncPolicy.automated）を慎重に扱い、テンプレート修正は 「いったん自動同期をoffにして反映 → 差分確認 → onに戻す」 という手順を踏みます。

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

targetRevisionを「HEAD」のままにしておくと、外部チャートのアップデートを意図せず取り込んでしまい、ある日突然クラスタが壊れます。チャートバージョンは明示固定し、Renovate等で更新PRを通します。

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

主要フリーランスエージェントの公開案件を確認する限り、ArgoCDは案件名として正面に出ることは少なく、「Kubernetes運用 / SRE / DevOps / プラットフォームエンジニア」 系のスキル要件の中に登場するケースが目立ちます。

募集の出方の傾向（公開案件ベース）

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

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

• 「GitOps運用の設計・推進」をミッションとして掲げる案件も見られるようになった

• SRE / DevOps系のポジションで歓迎スキル扱いになる

単価感（目安）

2026年6月時点で確認した主要フリーランスエージェントの公開案件（週3〜5日・業務委託・首都圏中心）ベースの目安です。

注：上記はあくまで公開案件ベースの目安です。実単価は所属企業・契約形態・稼働時間・スキル深度で大きく動きます。月額の表記であっても、契約は時間単価ベース・精算幅ありの業務委託契約が一般的です。

求められる併用スキル

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

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

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

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

• IaC：Terraform / Pulumi / Crossplane

関連職種と相互リンク

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

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

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

ミニFAQ：

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

ArgoCD導入チェックリスト

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

まとめ

ArgoCDはKubernetesの宣言的デプロイを継続同期で実現するGitOpsツールで、kubectl中心の手作業運用やJenkins中心のPush型CDから一歩進めたい現場で価値を発揮します。Gitを真実のソース、ArgoCDを差分を埋める実行者として運用することで、変更履歴と実状態のズレを最小化できます。

要点の再整理：

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

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

• 設計の最初に決めるべきは「マニフェストリポジトリ構成」「Secret管理方式」「Webhook経路」「自動同期・自己修復のポリシー」

• 案件はKubernetes本体・Helm・IaCの実務経験とセットで評価され、SRE / DevOps / プラットフォームエンジニア系で募集される

• 単価感は首都圏中心の公開案件ベースで中級SREが月60万〜80万円前後、上級・リード層で月100万円超になるケースもある（2026年6月時点の目安）

次のアクションとして、まずは検証用クラスタを1つ用意し、公式マニフェストでArgoCDを立ち上げて、自分のサンプルアプリを1本Applicationとして宣言してみるところから始めるのが効率的です。Kubernetes本体やCI/CDツールの理解と並行して、Kubernetes・Docker・DevOpsエンジニア といった関連トピックも横断的に押さえておくと、案件応募時の説得力が増します。

参照元・関連リンク：

• Argo CD公式ドキュメント

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

• argoproj/argo-cd（GitHub）