# ArgoCD GitOps 完全ガイド 2026年版：Kubernetes 継続的デプロイメントと技術面接対策

> ArgoCD 3.4 と GitOps による Kubernetes 継続的デプロイメントを解説。Application CRD、Sync Wave、マルチクラスター管理、Flux 比較、面接質問を網羅。

- Published: 2026-06-05
- Updated: 2026-06-05
- Author: SharpSkill
- Tags: argocd, gitops, kubernetes, devops, interview
- Reading time: 12 min

---

Kubernetes におけるアプリケーションのデリバリー手法として、GitOps の採用率は年々上昇を続けています。2026年初頭の CNCF 調査によれば、エンタープライズ環境の 64% 以上が GitOps を主要なデプロイメント手段として運用しており、その中核を担うツールが ArgoCD です。2026年5月にリリースされた [ArgoCD 3.4](https://github.com/argoproj/argo-cd/releases) では、本番運用で求められる Day 2 オペレーション機能が大幅に強化されました。本記事では、GitOps の基本概念から ArgoCD の実践的な設定パターン、マルチクラスター戦略、Flux との比較、そして DevOps エンジニアやプラットフォームエンジニアの技術面接で頻出する質問と回答を体系的に解説します。

> **GitOpsとは？**
>
> GitOps とは、Git リポジトリをインフラストラクチャおよびアプリケーション構成の唯一の信頼できるソース（Single Source of Truth）として扱うデプロイメント手法です。クラスター内部で稼働するエージェントが、Git 上で宣言された望ましい状態と実際のクラスター状態を継続的に比較し、差分を検出すると自動的に修正を行います。従来の CI ツールがクラスターへ変更をプッシュする方式とは異なり、クラスター側が Git から変更をプルする設計であるため、クラスターの認証情報を外部に公開する必要がないという構造的なセキュリティ上の利点があります。

## ArgoCD のアーキテクチャと Application CRD

ArgoCD は Kubernetes クラスター上で動作する一連のマイクロサービスで構成されています。API サーバーは外部リクエストの受付と認証を担当し、リポサーバーは Git リポジトリからマニフェストの取得とレンダリングを行います。アプリケーションコントローラーは Git 上の望ましい状態とクラスターの Live 状態を比較して同期処理を制御し、Redis はキャッシュとセッション管理を提供します。

このアーキテクチャの根幹にあるのが Pull ベースの同期モデルです。Jenkins や GitHub Actions のような CI ツールが kubeconfig を保持してクラスターへ直接プッシュする従来型のデプロイでは、CI 環境にクラスターへのフルアクセス権が必要となり、CI 環境が侵害された場合のリスクが甚大です。ArgoCD ではクラスター自身が Git の変更を取得するため、認証情報がクラスター境界の外に出ることがありません。

ArgoCD の基本操作単位は Application カスタムリソース（CRD）です。以下の YAML は、Git リポジトリの特定パスにあるマニフェストを本番用 Namespace に同期する定義の例です。

```yaml
# argocd-application.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-web-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/acme/my-web-app-config
    targetRevision: main
    path: overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true        # Remove resources deleted from Git
      selfHeal: true     # Revert manual changes in the cluster
    syncOptions:
      - CreateNamespace=true
```

`source` ブロックには、マニフェストを格納する Git リポジトリの URL、対象ブランチ、ディレクトリパスを指定します。`destination` はデプロイ先のクラスターと Namespace を定義します。`prune: true` を設定すると、Git リポジトリから削除されたリソースはクラスター上からも自動的に除去され、不要なリソースの残留を防止できます。`selfHeal: true` は、運用者が kubectl で直接加えた変更を数秒以内に Git の宣言状態へ自動的に戻します。

`syncPolicy.automated` を省略した場合は手動同期モードとなり、UI、CLI、または API からの明示的な操作を待つ挙動になります。ステージング環境ではデプロイ前に diff を確認したいケースが多いため手動同期が適しており、本番環境では構成の一貫性を最優先として自動同期が一般的に採用されます。

## Sync Wave と Hook による順序制御付きデプロイ

実際の本番デプロイメントでは、複数のリソースが特定の順序で作成・更新されることが前提となります。データベースマイグレーションが完了する前にアプリケーション Pod が起動すれば、スキーマの不整合によりクラッシュが発生します。ConfigMap や Secret も、それらを参照する Deployment より先に存在している必要があります。

ArgoCD はこの順序制御の課題に対して、Sync Wave と Resource Hook の 2 つの仕組みを提供しています。Sync Wave はリソースに数値の優先度を割り当て、値の小さいものから順にデプロイを進めます。ある Wave のすべてのリソースが Healthy になるまで、次の Wave は開始されません。

```yaml
# migration-job.yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: db-migrate
  annotations:
    argocd.argoproj.io/sync-wave: "-1"   # Runs before wave 0
    argocd.argoproj.io/hook: PreSync      # Executes before main sync
    argocd.argoproj.io/hook-delete-policy: HookSucceeded
spec:
  template:
    spec:
      containers:
        - name: migrate
          image: acme/my-web-app:latest
          command: ["python", "manage.py", "migrate"]
      restartPolicy: Never
```

`PreSync` Hook を指定すると、ArgoCD がメインマニフェストの適用を開始する前にこの Job を実行します。Sync Wave の値が `-1` であるため、Wave 0 に属する通常のリソースよりも先に処理されます。`HookSucceeded` 削除ポリシーにより、Job が正常完了した後は自動的にクリーンアップされます。マイグレーションが失敗した場合は同期処理全体が中断され、旧バージョンのアプリケーションがそのまま稼働を続けます。

ArgoCD 3.3 で導入された PreDelete Hook も実務上重要な追加です。アプリケーション削除時にデータベースのバックアップ取得や外部サービスの登録解除といった事前処理が必要なケースで活用されます。ロールバックシナリオに備え、マイグレーションスクリプトは冪等（べきとう）な操作として設計することが推奨されます。

## ApplicationSet によるマルチクラスター管理

複数のクラスターに同一アプリケーションをデプロイする場合、Application マニフェストをクラスターごとに手作業で複製する方法は保守性に問題があります。[ApplicationSet](https://argo-cd.readthedocs.io/en/stable/user-guide/application-set/) は、テンプレートとジェネレーターの組み合わせにより、この課題を根本から解決します。

```yaml
# applicationset-clusters.yaml
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: my-web-app-all-clusters
  namespace: argocd
spec:
  generators:
    - clusters:
        selector:
          matchLabels:
            env: production
  template:
    metadata:
      name: 'my-web-app-{{name}}'
    spec:
      project: default
      source:
        repoURL: https://github.com/acme/my-web-app-config
        targetRevision: main
        path: 'overlays/{{metadata.labels.region}}'
      destination:
        server: '{{server}}'
        namespace: production
      syncPolicy:
        automated:
          prune: true
          selfHeal: true
```

この例ではクラスタージェネレーターを使用しています。ArgoCD に登録されたクラスターのうち `env: production` ラベルを持つものを走査し、各クラスターに対して 1 つの Application リソースを動的に生成します。`{{name}}`、`{{server}}`、`{{metadata.labels.region}}` はクラスターの登録情報から自動的に解決されるプレースホルダーです。新しい本番クラスターを ArgoCD に登録するだけで、追加のマニフェスト作成なしにアプリケーションのデプロイが開始されます。

ApplicationSet は、クラスタージェネレーター以外にも多様なジェネレーター種別を備えています。Git ディレクトリジェネレーターはモノレポ構成で各サービスディレクトリに対応する Application を生成し、リストジェネレーターは明示的に列挙した値から Application を作成します。マトリクスジェネレーターは複数のジェネレーターを組み合わせた直積パターンを生成でき、マルチテナント SaaS のような複雑な構成にも対応します。

## ArgoCD vs Flux：GitOps ツールの選定基準

ArgoCD と Flux の比較は、DevOps や SRE の技術面接で繰り返し出題される定番テーマです。両方とも CNCF Graduated プロジェクトとして GitOps の基本原則を実装していますが、設計思想が根本的に異なります。[DevOps面接トピック](/technologies/devops/interview-questions/kubernetes-basics)と合わせて準備することが推奨されます。

| Feature | ArgoCD 3.4 | Flux 2.8 |
|---------|-----------|----------|
| Architecture | Centralized server with UI | Distributed controllers per cluster |
| Web UI | Built-in, polished dashboard | No built-in UI (third-party options) |
| Helm support | Renders templates server-side | Native Helm SDK integration |
| Multi-cluster | Hub-and-spoke from single instance | Independent installation per cluster |
| RBAC | Application-level with SSO | Kubernetes-native RBAC only |
| Image automation | Separate Image Updater component | Built-in image reflector/automation |
| Progressive delivery | Argo Rollouts integration | Flagger integration |
| Resource footprint | Higher (API server, repo server, Redis) | Lower (only needed controllers) |

ArgoCD の強みは集中管理型の運用にあります。Web ダッシュボードで全クラスターのデプロイ状況を一覧でき、アプリケーション単位の RBAC と SSO の統合によりきめ細かなアクセス制御が可能です。開発チームとプラットフォームチームの責務が明確に分離された組織に適しています。

Flux は、各クラスターで独立して動作する分散型アーキテクチャを採用しています。管理クラスターという単一障害点が存在しないため、ある Flux インスタンスの障害が他クラスターに波及することはありません。エッジコンピューティングやリソース制約の厳しい環境にも適しており、Helm SDK とのネイティブ統合により Helm チャートのライフサイクル管理を GitOps の文脈で忠実に再現できます。

実務では両ツールを併用する組織も少なくありません。アプリケーションデプロイには ArgoCD の UI と RBAC を活用し、インフラコンポーネント（Prometheus、Istio、cert-manager など）の管理には Flux を採用するハイブリッド戦略です。面接では単純な優劣比較ではなく、組織の要件に基づいた合理的な選定理由を説明できるかが評価されます。

## 本番 GitOps のためのリポジトリ構成

GitOps 導入において最初に直面する設計判断の一つが、リポジトリの分離戦略です。アプリケーションのソースコードと Kubernetes マニフェストを同一リポジトリに格納する構成は、小規模プロジェクトでは手軽ですが、規模の拡大に伴い問題が顕在化します。アプリケーションの変更履歴とインフラ設定の変更履歴が混在し、レビューの独立性が失われ、CI トリガーの条件設定が複雑化します。

推奨されるのは、設定リポジトリ（config repo）をアプリケーションリポジトリ（app repo）から完全に分離する構成です。

```
# Recommended repository structure
my-web-app-config/
  base/
    deployment.yaml
    service.yaml
    kustomization.yaml
  overlays/
    staging/
      kustomization.yaml       # Patches for staging
      replica-count.yaml
    production/
      kustomization.yaml       # Patches for production
      replica-count.yaml
      hpa.yaml
```

`base` ディレクトリには全環境で共通のマニフェストを配置し、`overlays` 配下で環境ごとの差分を [Kustomize](https://kustomize.io/) のパッチとして管理します。デプロイの流れは次のとおりです。アプリケーションリポジトリへの Push により CI パイプラインが起動し、コンテナイメージのビルドとレジストリへのプッシュが行われます。続いて CI パイプラインが設定リポジトリ内のイメージタグを更新するコミットを作成し、ArgoCD がそのコミットを検出してクラスターへの同期を実行します。

この分離により、アプリケーション開発者とプラットフォームエンジニアの責務境界が明確になります。設定リポジトリへの変更権限を限定することで、意図しないインフラ変更のリスクを最小化できます。

> **Webhookベースのリコンシリエーション**
>
> GitHub、GitLab、Bitbucket の Webhook レシーバーを設定すると、Push イベント発生時に ArgoCD の照合処理を即座にトリガーできます。デフォルトの 3 分間ポーリングを待たずに、10 秒未満でのデプロイ検出が可能になります。ただし、Webhook の到達が一時的に失敗する可能性に備え、ポーリング間隔を 5〜10 分に設定するフォールバック構成が推奨されます。

## ArgoCD 3.4 の注目機能

2026年5月にリリースされた ArgoCD 3.4 には、運用現場からの要望に応える複数の新機能が含まれています。シニアレベルの DevOps 面接では、これらの機能の存在だけでなく、具体的なユースケースまで説明できることが求められます。

**Pause Reconciliation（照合一時停止）** は、特定のクラスターに対する ArgoCD の同期処理を一時的に凍結する機能です。本番インシデント発生時に、緊急対応として kubectl で直接適用したホットフィックスが selfHeal によって上書きされてしまう問題を防ぎます。

```yaml
# Pause reconciliation on a specific cluster
apiVersion: v1
kind: Secret
metadata:
  name: prod-cluster
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: cluster
  annotations:
    argocd.argoproj.io/pause-reconciliation: "true"
stringData:
  server: https://prod-cluster.example.com
  config: |
    { "tlsClientConfig": { "insecure": false } }
```

インシデント収束後にアノテーションを削除すれば、通常の照合サイクルが即座に再開されます。恒久的な修正を Git リポジトリにコミットしてから照合を再開するのが正しい運用手順です。この機能は selfHeal の信頼性と緊急時の柔軟性を両立させるものであり、運用チームから高い評価を受けています。

**Helm 値ファイルの Glob パターン対応** は、環境・リージョン・機密情報ごとに値ファイルを分割しているチームにとって待望の機能です。従来は全ファイルを `valueFiles` に明示的に列挙する必要がありましたが、Glob パターンにより新規ファイル追加時の Application マニフェスト修正が不要になります。

```yaml
# Before ArgoCD 3.4
source:
  helm:
    valueFiles:
      - values.yaml
      - values-production.yaml
      - values-production-eu.yaml
      - values-production-eu-secrets.yaml

# With ArgoCD 3.4 value globs
source:
  helm:
    valueFiles:
      - values.yaml
      - values-production*.yaml
```

マルチリージョン構成では `values-production-us.yaml`、`values-production-eu.yaml`、`values-production-ap.yaml` のように地域ごとのファイルが増加するため、Glob パターンによる保守コスト削減の効果は特に大きくなります。

## ArgoCD・GitOps の面接頻出質問と回答

以下の質問は、DevOps エンジニアおよびプラットフォームエンジニアリング職の技術面接で高い頻度で出題されています。問われているのは ArgoCD のコマンドや構文の暗記ではなく、GitOps の原則に対する理解と、本番環境での運用判断力です。[Kubernetes上級モジュール](/technologies/devops/interview-questions/kubernetes-advanced)も合わせて活用することで、より包括的な準備が可能です。

> **面接対策の深度**
>
> シニアレベルの面接では、機能の羅列だけでは高い評価を得られません。トレードオフ、障害モード、実際に遭遇した問題の説明が求められます。selfHeal がインシデント対応を妨げた事例、Sync Wave の設計ミスでデプロイが失敗した経験、マルチクラスター環境でのプログレッシブデリバリー戦略など、具体的なシナリオに基づいた回答を準備してください。

**「ArgoCD における自動同期と手動同期の違いを説明してください」**

自動同期では、ArgoCD が Git とクラスター間の差分を検出した時点で、人間の介在なしにクラスターへ変更が適用されます。手動同期では、UI、CLI、または API からの明示的なトリガーを待って初めて変更が反映されます。本番環境では `selfHeal: true` を有効化した自動同期が標準的な構成です。ドリフトが発生しても即座に Git の宣言状態へ修正されるため、構成の一貫性が担保されます。一方、ステージング環境ではデプロイ前に diff を確認してから適用したいケースが多く、手動同期が適切です。

**「ArgoCD がドリフトを検出した際の内部処理を説明してください」**

ArgoCD のアプリケーションコントローラーは、Git のマニフェストをレンダリング（Helm、Kustomize、またはプレーン YAML）した結果と、Kubernetes API サーバーから取得した Live 状態を比較します。selfHeal 付き自動同期が有効な場合、差分検出と同時にクラスターを Git の状態に戻します。selfHeal が無効の場合は Application のステータスが `OutOfSync` に変更され、手動操作を待機します。UI ではフィールド単位の diff が表示され、どの値がどのように乖離しているかを正確に特定できます。

**「GitOps ワークフローにおけるデータベースマイグレーションの扱い方を説明してください」**

データベースマイグレーションは PreSync Hook の Job として定義し、Sync Wave に負の値（例：`-1`）を割り当てます。これにより、Wave 0 に属する通常のアプリケーションマニフェストが適用される前にマイグレーション Job が実行されます。Job が失敗した場合は同期全体が中断され、クラスター上では旧バージョンのアプリケーションが継続稼働します。`HookSucceeded` 削除ポリシーにより、正常完了後の Job Pod は自動クリーンアップされます。ロールバックの可能性を考慮し、マイグレーションスクリプトは冪等な操作として設計することが不可欠です。

**「マルチクラスター本番環境で ArgoCD と Flux のどちらを選択しますか。その根拠を述べてください」**

ArgoCD は単一のコントロールプレーンから全クラスターを管理し、ダッシュボードによる集中的な可視性と統一された RBAC を提供します。少人数の運用チームで全クラスターの状況を一画面で把握したい場合に強みを発揮します。Flux はクラスターごとに独立動作するため、管理クラスターの障害が他クラスターに波及しません。100 を超えるクラスター規模では、ArgoCD の集中型モデルは管理クラスターの可用性がボトルネックとなり得ますが、Flux の分散型モデルはその単一障害点を排除できます。運用効率を優先するなら ArgoCD、障害分離を優先するなら Flux が適切です。デプロイパイプラインのセキュリティ観点については [CI/CDパイプラインセキュリティモジュール](/technologies/devops/interview-questions/cicd-pipeline-security) を参照してください。

**「ApplicationSet とは何か、具体的なユースケースを挙げて説明してください」**

ApplicationSet は、テンプレートとジェネレーターの組み合わせで ArgoCD の Application リソースを動的に生成するコントローラーです。ジェネレーターの種別には、クラスター、Git ディレクトリ、リスト、マトリクス、マージの 5 種類があります。代表的なユースケースとして、全本番クラスターへの同一アプリケーション展開（クラスタージェネレーター）、マルチテナント SaaS におけるテナント別 Application 生成（リストまたはマトリクスジェネレーター）、モノレポ内の各マイクロサービスディレクトリに対応する Application 作成（Git ディレクトリジェネレーター）が挙げられます。

## まとめ

- ArgoCD 3.4（2026年5月リリース）は Pause Reconciliation と Helm 値ファイル Glob パターンを追加し、本番 Kubernetes クラスターの Day 2 オペレーションに対応している
- Pull ベースの GitOps モデルにより、CI ツールへのクラスター認証情報の公開が不要となり、セキュリティリスクが構造的に低減される
- Sync Wave と Hook を活用することで、マイグレーション、ConfigMap、Deployment、クリーンアップの順序制御付きデプロイが実現する
- ApplicationSet はクラスターラベル、Git ディレクトリ、カスタムリストから Application リソースを動的に生成し、マルチクラスターデプロイメントを自動化する
- 設定リポジトリとアプリケーションリポジトリの分離により、Git 履歴の明瞭性、レビューの独立性、CI トリガー設計の簡潔さが確保される
- ArgoCD はダッシュボードと RBAC による集中管理型マルチクラスター運用に適し、Flux は分散型・低リソース・Helm ネイティブの環境に適している
- GitOps 関連の技術面接対策では、定義の暗記ではなく、ドリフト検出の仕組み、同期戦略、障害モード、本番環境での具体的な経験に基づく回答を準備することが重要である

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/ja/blog/devops/argocd-gitops-kubernetes-continuous-deployment-interview-questions