GitOpsとは？Gitリポジトリを唯一の信頼源とするインフラ運用モデル
GitOpsとは、Gitリポジトリをインフラストラクチャおよびアプリケーション構成の「唯一の信頼源（Single Source of Truth）」として扱い、Gitへのコミット・マージを起点にインフラの変更を自動的に反映する運用モデルです。DevOpsのベストプラクティスであるバージョン管理、コードレビュー、CI/CDをインフラ管理にも適用する考え方として、Weaveworks社が2017年に提唱しました。
従来のCI/CD（CIOps）がCIパイプラインからクラスタに直接デプロイする「Push型」であるのに対し、GitOpsはクラスタ側のエージェントがGitリポジトリの状態を監視し、差分を検出して自動的に反映する「Pull型」を基本とします。この違いにより、CIシステムにKubernetesの認証情報を持たせる必要がなく、セキュリティが大幅に向上します。
2026年現在、GitOpsはKubernetes環境のデファクトスタンダードな運用手法となり、CNCF（Cloud Native Computing Foundation）が推進するFluxプロジェクトを筆頭に、エコシステムが成熟しています。
GitOpsの基本原則：4つの柱
1. 宣言的な構成（Declarative）
システムの「あるべき状態（Desired State）」をYAMLやHelmチャートなどの宣言的な構成ファイルで記述します。手続き的なスクリプト（kubectl applyの羅列）ではなく、「何が動いているべきか」を定義することで、環境の一貫性と再現性を保証します。
2. バージョン管理と不変性（Versioned and Immutable）
すべての構成情報がGitリポジトリでバージョン管理されるため、いつ・誰が・何を変更したかの完全な監査証跡が自動的に記録されます。問題発生時にはgit revertで即座に前の状態に戻せます。
3. 自動プル（Pulled Automatically）
GitOpsエージェント（ArgoCD、Flux等）がGitリポジトリを定期的にポーリングし、リポジトリの定義とクラスタの実際の状態に差分があれば自動的に同期します。人手による手動デプロイが不要になります。
4. 継続的な調整（Continuously Reconciled）
誰かが手動でクラスタの状態を変更しても、GitOpsエージェントがGitリポジトリの定義に基づいて自動的に修復します。「ドリフト（構成のずれ）」を継続的に検知・修正するため、環境の一貫性が常に維持されます。
GitOpsツールの比較：ArgoCD vs Flux
GitOpsを実現する代表的なツールはArgoCDとFluxです。どちらもCNCFプロジェクトで、Pull型のGitOpsを実装しています。
| 観点 | ArgoCD | Flux |
|---|---|---|
| UI | リッチなWebUIを標準搭載 | CLIベース（Weave GitOps UIは別途） |
| マルチクラスタ | 中央管理型で複数クラスタを一元管理 | 各クラスタにFluxを配置する分散型 |
| カスタマイズ性 | Application CRDでの管理が中心 | Kustomization・HelmRelease等きめ細かい制御 |
| 学習コスト | UI直感的で入門しやすい | YAMLベースで概念理解が必要 |
| 通知連携 | Webhook・Slack等 | Notification Controllerで柔軟に設定 |
| イメージ自動更新 | Argo Image Updater（別コンポーネント） | Image Automation Controller標準搭載 |
小〜中規模でUI重視ならArgoCD、大規模・多クラスタで柔軟な制御が必要ならFluxが適しています。両者を組み合わせて使用するケースもあります。
GitOpsによるKubernetes運用自動化の実践
リポジトリ構成のベストプラクティス
GitOpsでは通常、アプリケーションコードとインフラ構成を別リポジトリで管理します。
- アプリリポジトリ：アプリケーションのソースコード、Dockerfile、CIパイプライン
- マニフェストリポジトリ：Kubernetesマニフェスト、Helmチャート、Kustomize構成
CIパイプラインがアプリリポジトリのコードをビルド→コンテナイメージをレジストリにプッシュ→マニフェストリポジトリのイメージタグを更新→GitOpsエージェントが変更を検知して自動デプロイ、というフローが標準的です。
環境管理（dev/staging/production）
Kustomizeのoverlays機能やHelmのvaluesファイルで環境ごとの差分を管理します。ディレクトリ構成例：
- base/ ... 共通のマニフェスト定義
- overlays/dev/ ... 開発環境固有の設定
- overlays/staging/ ... ステージング環境固有の設定
- overlays/production/ ... 本番環境固有の設定
各環境へのデプロイはGitブランチまたはディレクトリで制御し、本番環境へのデプロイにはPull Requestの承認プロセスを必須とすることで、変更の品質を担保します。
シークレット管理
機密情報（APIキー、パスワード等）をGitリポジトリに平文で保存してはなりません。Sealed Secrets、SOPS（Mozilla）、External Secrets Operator、HashiCorp Vaultなどのツールで暗号化・外部管理します。GitOpsの原則を維持しつつ、セキュリティを確保する工夫が必要です。
GitOpsとCI/CDの連携パターン
CIOps（従来型）との比較
CIOps（Push型）：CIパイプライン（GitHub Actions、Jenkins等）がビルド→テスト→デプロイを一貫して実行。CIシステムがクラスタの認証情報を保持するため、セキュリティリスクがある。
GitOps（Pull型）：CIパイプラインはビルド→テスト→マニフェスト更新まで。デプロイはクラスタ内のGitOpsエージェントが担当。CIシステムにクラスタ認証情報が不要。
Progressive Delivery
GitOpsと組み合わせて、カナリアリリースやブルーグリーンデプロイメントを自動化する手法です。Argo Rolloutsを使えば、新バージョンのトラフィック比率を段階的に増やしながら、メトリクスの異常を検知した場合に自動ロールバックする仕組みを構築できます。
GitOps導入のメリットと注意点
メリット
- 監査性：すべての変更がGitの履歴に記録され、完全な監査証跡を提供
- 再現性：環境の再構築がgit cloneから自動的に完了
- セキュリティ：CI/CDパイプラインにクラスタ認証情報を渡す必要がない
- 自動修復：手動変更による構成ドリフトを自動検知・修正
- 開発者体験：Git操作のみでインフラ変更が完結し、kubectlの直接操作が不要
注意点
- 学習コスト：Kubernetes、Helm/Kustomize、GitOpsツールの理解が必要
- シークレット管理：追加のツール導入と設計が必要
- リポジトリ肥大化：大規模環境ではマニフェストの管理が複雑化
- デバッグ：同期エラー発生時の原因特定に慣れが必要
よくある質問（FAQ）
Q1. GitOpsはKubernetes以外でも使えますか？
はい。GitOpsの原則はTerraformやAWS CloudFormationなど、Kubernetes以外のInfrastructure as Code（IaC）にも適用できます。ただし、GitOpsツール（ArgoCD、Flux）はKubernetesに特化しているため、非Kubernetes環境ではTerraform CloudやAtlantisなどの専用ツールが適しています。
Q2. GitOpsの導入に必要な前提条件は何ですか？
1）Kubernetesクラスタ（EKS、GKE、AKS等）が運用されていること、2）Gitリポジトリ（GitHub、GitLab等）が利用可能なこと、3）インフラ構成がコード化（YAML、Helm等）されていること、の3点が基本的な前提条件です。
Q3. ArgoCD とFlux、どちらを選ぶべきですか？
初めてGitOpsを導入する場合や、直感的なUIが欲しい場合はArgoCDがおすすめです。大規模・多クラスタ環境できめ細かい制御が必要な場合や、Terraform Controllerとの統合が必要な場合はFluxが適しています。
Q4. GitOpsで障害が発生した場合、ロールバックはどうしますか？
git revertで前のバージョンのマニフェストに戻すコミットを作成するだけで、GitOpsエージェントが自動的にクラスタを前の状態に戻します。Gitの履歴がすべて残っているため、任意の時点への巻き戻しが容易です。
Q5. GitOpsとDevOpsの違いは何ですか？
DevOpsは開発（Dev）と運用（Ops）の協業を促進する文化・プラクティスの総称で、GitOpsはDevOpsの中でも特に「Gitを中心としたインフラ運用自動化」に特化した手法です。GitOpsはDevOpsのサブセットであり、DevOpsの原則をインフラ管理に具体的に適用したものと位置づけられます。