GitOps

GitOps とは

GitOps は、Git リポジトリをシステムの「あるべき状態」の唯一の正 (Single Source of Truth) とし、リポジトリの変更をトリガーにインフラやアプリケーションを自動的に同期させる運用手法である。Weaveworks が自社の Kubernetes 運用実践から提唱した考え方で、原則の定義は現在 CNCF の OpenGitOps プロジェクトが GitOps Principles として管理している。

従来の運用では、本番環境に SSH で入って設定を変更したり、管理コンソールから手動操作したりすることが日常的だった。GitOps はこれを根本から否定し、「Git に書かれていない変更は存在しない」という原則を徹底する。

基本原則

CNCF の OpenGitOps が公開する GitOps Principles v1.0.0 は、GitOps で管理するシステムの「望ましい状態」が満たすべき性質を 4 つ挙げている。

1. 宣言的 (Declarative): 望ましい状態を YAML, HCL, CloudFormation テンプレートなどで宣言的に記述する
2. バージョン管理と不変性 (Versioned and Immutable): 状態定義を不変性とバージョン管理を強制する形で保管し、完全な変更履歴を残す
3. 自動的な取得 (Pulled Automatically): ソフトウェアエージェントが望ましい状態の定義をソースから自動で取得する
4. 継続的な調停 (Continuously Reconciled): エージェントが実際の状態を継続的に観測し、望ましい状態を適用しようとする

プルリクエスト経由のレビュー・承認はこの 4 原則には含まれない。2 のバージョン管理を実務で回すための定番の手順であり、誰が、いつ、なぜ変更したかを記録に残す手段として広く使われている。

Push 型と Pull 型の比較

GitOps の実装には 2 つのアプローチがある。

観点	Push 型	Pull 型
仕組み	CI パイプラインがデプロイコマンドを実行	クラスター内のエージェントが Git をポーリング
代表的なツール	GitHub Actions, GitLab CI, CodePipeline	Argo CD, Flux
クレデンシャル管理	CI 環境にデプロイ権限が必要	クラスター内で完結、外部に権限を渡さない
ドリフト検出	別途仕組みが必要	エージェントが常時観測 (自動修復は設定次第)
適するケース	サーバーレス、小規模チーム	Kubernetes、大規模マルチクラスター

Pull 型はセキュリティ面で優位だ。CI 環境にクラスターへのデプロイ権限を持たせる必要がなく、クラスター内のエージェントが自律的に Git と同期する。一方、Push 型はシンプルで導入コストが低い。

AWS サーバーレスでの GitOps

SAM テンプレートを Git で管理し、main へのマージをトリガーに GitHub Actions で sam deploy を実行する構成は、Push 型 GitOps の実践だ。

# .github/workflows/deploy.yml
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: aws-actions/setup-sam@v2
      - run: sam deploy --no-confirm-changeset

CloudFormation のドリフト検出で、手動変更による乖離を検出できる。ただし、ドリフト検出は自動修復まではしないため、Pull 型の Argo CD ほどの自律性はない。

GitOps と従来の CI/CD の違い

GitOps は CI/CD の上位概念ではなく、運用哲学の違いだ。

• 従来の CI/CD: 「コードをビルドしてデプロイする」パイプラインに焦点。デプロイ後の状態管理は範囲外
• GitOps: 「Git の状態とシステムの状態を常に一致させる」ことに焦点。デプロイ後のドリフト検出・自動修復まで含む

CI/CD は「変更を届ける仕組み」、GitOps は「あるべき状態を維持する仕組み」と捉えると違いが明確になる。

よくある落とし穴

• シークレット管理の課題: Git にパスワードや API キーを直接格納できない。Sealed Secrets、External Secrets Operator、AWS Secrets Manager との連携が必要になる
• 環境ごとの差異: dev/stg/prod で設定が異なる場合、ブランチ戦略かディレクトリ戦略かで悩む。Kustomize のオーバーレイや Helm の values ファイルで環境差分を管理するのが一般的
• 手動変更の誘惑: 障害対応で「とりあえず本番を直接変更」すると、Git との乖離が生じる。Pull 型でも自己修復を明示的に有効にしていなければ手動変更は残る。Argo CD の自動同期は既定では実クラスタ側の変更を同期の起点にせず、selfHeal を有効にして初めて Git の状態へ戻す。Push 型では乖離を見つける仕組み自体を別に用意する必要がある
• 大規模リポジトリの遅延: マニフェストが数千ファイルに膨れると、ポーリング間隔内に同期が完了しない場合がある

GitOps を始めるための判断基準

GitOps を始めるための判断基準を以下にまとめる。

条件	Push 型で十分	Pull 型を検討
インフラ	サーバーレス (Lambda, S3)	Kubernetes クラスター
チーム規模	1〜5 人	5 人以上、複数チーム
環境数	2〜3 環境	5 環境以上、マルチクラスター
ドリフト検出	手動確認で許容	自動検出・修復が必須

小規模なサーバーレスプロジェクトなら、GitHub Actions + SAM の Push 型で十分だ。Kubernetes を運用するなら、Argo CD の導入を検討する価値がある。

GitOps の原典は Weaveworks のブログ記事だが、2026 年 8 月時点で同社サイトの当該 URL は無関係な内容に置き換わっている。原則の定義は CNCF の OpenGitOps を、Kubernetes での実装は「GitOps and Kubernetes」(Billy Yuen ら著・Manning) を参照するとよい。

# Argo CD の Application 定義
apiVersion: argoproj.io/v1alpha1
kind: Application
spec:
  source:
    repoURL: https://github.com/myorg/k8s-manifests
    path: overlays/prod
  destination:
    server: https://kubernetes.default.svc
  syncPolicy:
    automated:
      prune: true
      selfHeal: true  # 有効にしないと手動変更は元に戻らない

体系的に学ぶなら関連書籍を参照してほしい。