GitOpsとはの基本（考え方・用語・仕組み）

GitOpsとは：宣言的×自動同期×監査可能を満たす運用モデル

GitOpsは、システムが「どうあるべきか（望ましい状態）」をあらかじめ宣言的にファイルで表現し、それをGitで一元管理する運用方法です。そして、その宣言を監視するオペレーター（コントローラー）がクラスター内に常駐し、実際の環境を自動的に望ましい状態へ収束させます。

つまり人間は「何を実現したいか」をGitに書き込むだけで、環境を整える作業そのものはソフトウェアが行ってくれるのです。レビューやコミット履歴はすべてGitに残るため、いつ誰が何を変更したかが明確に追跡できます。

CNCF配下のOpenGitOpsプロジェクトでは、以下の4つをGitOpsの原則として整理しています。

• 宣言的な設定で状態を表現すること

• Gitを唯一の信頼できる情報源（SSOT）とすること

• 継続的な自動調整により状態を保つこと

• 監査可能性を担保し、いつでも正当性を説明できること

これらを満たすことで、運用の「誰が・いつ・何を・なぜ変更したか」をコードの履歴から直接説明できるようになります。これは従来の「人の記憶やExcelでの記録」に依存していた運用と比べて、大きな進歩といえます。

Push型とPull型（GitOpsの要点は“Pull”）

従来のCI/CDの多くは、CIシステムが外部から「kubectl apply」などを実行してクラスターに設定を流し込むPush型を取ってきました。この方法では外部のCIがKubernetesの管理権限を持つ必要があり、セキュリティや境界管理の点で課題が残ります。

一方、GitOpsが推奨するのはPull型です。これはクラスターの中にコントローラーを配置し、そのコントローラーがGitを監視して差分を取り込み、環境を自動的に収束させる方式です。外部に強い権限を渡さずに済み、境界が明確になり、運用もシンプルになります。

この整理を広めたのが、Weaveworksによる「CIはマージまで、CDはランタイムの仕事」という考え方です。CIはコードの品質確認とマージまでを担当し、そこから先はCDシステムが自動的に収束させる。この役割分担が、Pull型GitOpsの考え方を現場に浸透させました。実際、多くの実装比較記事でも「Pull型はより安全であり、GitOpsに適している」と紹介されています。

何をGitOps化するか：範囲の切り方

GitOpsを導入する際、いきなりすべてを対象にすると複雑になりすぎます。そのため、まずはKubernetes上のアプリケーションやプラットフォーム設定（DeploymentやService、Ingressなど）から始めるのが一般的です。

慣れてきたら、クラスタ構成、ネットワーク設定、RBAC（権限制御）、さらには監視・アラートの設定へと対象を広げます。ここで重要なのは「宣言的に表現できること」と「再現可能であること」です。Terraformなどの既存IaCツールと整合を取りながら、組織として「どこをSSOTにするか」を明確に決めておきましょう。

導入の進め方は、単一の環境からスタートし、その後ステージング環境、本番環境へと段階的に広げていくのが定石です。ブランチ戦略やディレクトリ構成も最初にルール化しておくと、メンバー間の迷いが減り、導入がスムーズになります。OpenGitOpsで定義された用語や基準を参照しておくと、社内合意も取りやすくなります。

出典：OpenGitOps（CNCF WG：GitOpsの原則と定義）
出典：Weaveworks「What is GitOps, really?」
出典：GitOps.tech「Push-based vs Pull-based」

GitOps導入の効果と前提（再現性・安全性・スピード）

再現性と監査性：Gitを中核に“差分で語る”

GitOpsでは、すべての設定ファイルとその変更履歴がGitに残ります。つまり「環境がどう変わったのか」をPull Request単位で説明できるのです。たとえば障害が起きたときも、「このコミットを戻す」といった明確な操作でロールバックが可能になります。

レビューと自動テストを適用する前提を組み込むことで、適用の品質を一定に保てます。Gitの履歴そのものが監査証跡となるため、変更の正当性を説明しやすい点も大きな魅力です。これは特定のツールに依存しない、GitOpsそのものの本質的なメリットといえます。

安全性：最小特権と境界の明確化

Pull型では、外部CIがクラスターに管理者権限で直接アクセスする必要がありません。そのため、資格情報の扱いがシンプルになり、セキュリティリスクが大幅に下がります。

クラスター内部のコントローラーが常に「宣言（あるべき状態）」と「現実（今の状態）」を突き合わせ続けるため、どの範囲にどの権限があるかが可視化されやすく、境界が明確になります。この「最小特権の原則を自然に守れる」点は、GitOpsが企業で採用されやすい理由の一つです。

スピード：自動同期とドリフト検知で手戻りを減らす

GitOpsでは、コントローラーが常に環境を監視し、差分があれば即座に反映します。人手で適用する場合にありがちな「適用漏れ」や「適用したと思っていたけど違った」といったミスを防げます。

また「望ましい状態」と「現実の状態」のズレ（ドリフト）を自動的に検知できるため、問題を早期に発見できます。マルチ環境やマルチクラスターでも同じ方式を広げられるため、標準化が進むほど開発スピードと安定性が同時に向上します。

出典：OpenGitOps（原則：自動化された継続的な調整・遵守）
出典：GitOps.tech「Push vs Pull（セキュリティ観点）」

Argo CD or Flux 比較（アーキテクチャと機能差）

設計思想：Argo CDは“完成品のUI付き”、Fluxは“ツールキット型”

GitOpsを実現する代表的なツールは Argo CD と Flux ですが、両者の思想は大きく異なります。

Argo CD は「すぐに使える完成品」を意識した設計で、KubernetesのCRDである Application を中核としています。Web UI・CLIが標準で備わっており、同期状態や差分、リソースのヘルスをGUI上でわかりやすく確認できます。Sync処理の順序（WaveやHookの概念）もGUIから制御でき、複数クラスターへの配布は ApplicationSet を使ってテンプレート化できます。初めて導入する組織でも、可視化と操作性の面で安心感があります。

一方 Flux は「GitOps Toolkit」と呼ばれる複数のコントローラー群で構成されており、必要なものを組み合わせて運用を作り上げるツールキット型の設計です。標準UIは持たず、必要に応じて Weave GitOps UI を追加する形になります。構成要素が「source」「kustomize」「helm」「notification」「image」など細かく分かれているため、最小限から導入して徐々に拡張していけるのが特徴です。柔軟性は高いですが、設計や理解のハードルも若干上がります。

マルチテナンシーと権限管理：Argo CDのProject／FluxのNamespace分離

マルチテナンシー（複数チームや利用者を共存させる仕組み）に関しても両者はアプローチが異なります。

Argo CD では AppProject という仕組みを用意し、許可するリポジトリ・クラスター・Namespace をプロジェクト単位で束ねることができます。その上でSSO連携とRBACを組み合わせることで、チームごとに「どのアプリを操作できるか」「どこまで参照できるか」をGUIから細かく制御できます。つまり Argo CD は「強いUIを軸にした運用制御」が得意です。

Flux は Namespaceごとの分離とRBACを基本としています。ソースリポジトリごとに権限を切り分け、マルチテナンシーをガイドラインに沿って設計します。公式のマルチテナンシーガイドが公開されており、ベストプラクティスに沿った構成が取りやすいのが利点です。UIは限定的ですが、Namespaceをうまく使うことでシンプルな分掌が可能です。

Helm／Kustomizeとマルチクラスター：表現力と運用の違い

Argo CD と Flux のどちらも、Helm や Kustomize、そして生の YAML に対応していますが、表現力と使い勝手に違いがあります。

Argo CD は Kustomize と Helm を同じアプリケーション内で併用することが可能で、Sync Waves を使えばリソースの適用順序を細かく制御できます。またカスタムヘルスチェックを定義すれば、アプリケーションが正しくデプロイされたかを細かく把握できます。複数クラスターへの配布も ApplicationSet の Cluster Generator でテンプレート化でき、運用者はGUIを通じて全体を把握しやすいのが特徴です。

Flux は Helm Controller を持ち、HelmRelease リソースを宣言的に管理します。リリースの状態を監視し、ドリフトが発生すれば自動的に修復やロールバックを行います。複数クラスターへの展開はブートストラップ手順とGitレイアウトで実現し、マルチテナンシー設計と組み合わせるのが定石です。UIは標準ではありませんが、Weave GitOpsを追加すれば可視化が可能になります。

出典：Argo CD「Sync Phases and Waves／Health Checks」
出典：Argo CD「ApplicationSet（Generators）」
出典：Argo CD「Kustomizeサポート」
出典：Flux「GitOps Toolkit components」
出典：Flux「Multi-tenancy」
出典：Flux「HelmRelease／Helm Controller」
出典：Flux Blog「Weave GitOpsをFluxのUIに」

セキュリティと秘密情報（SOPS／Vault連携／ポリシー）

Flux：SOPSを“標準で”扱える（KMSやVaultと連携）

Flux は秘密情報の取り扱いで強みがあります。Mozillaが開発した SOPS（Secrets OPerationS）をネイティブにサポートしており、Gitには暗号化したSecretを置き、適用時に自動で復号する仕組みを組み込めます。

これにより「Gitに平文のシークレットを置かない」運用を追加のオペレーターなしで実現できます。さらに AWS KMS、GCP KMS、Azure Key Vault といった主要なクラウドKMSとも連携可能で、チームが使っている環境に合わせた鍵管理を取り込めます。

Argo CD：Vaultなどと連携（AVPやKSOPSのプラグイン方式）

Argo CD の場合、秘密情報を直接管理する機能は標準では持っていません。そのため Config Management Plugin として argocd-vault-plugin（AVP） や KustomizeのSOPSプラグインである KSOPS を組み合わせて利用します。

公式ドキュメントでも「マニフェスト生成時にシークレットを注入する方法」が紹介されており、運用上はAVPのサイドカーを導入する、あるいはKSOPSを組み込むといった方法が一般的です。つまりArgo CDでは「プラグインを前提に設計する」必要があると言えます。

ポリシーと権限：RBACとプロジェクトで“触れる範囲”を固定

セキュリティは秘密情報だけではなく、アクセス権限の設計も重要です。

Argo CD は、インスタンス全体のRBACとAppProject単位の制御を両方持っており、SSO連携と組み合わせることで「誰が・どのレポジトリ・どのクラスター・どのNamespaceにアクセスできるか」を詳細に制御できます。GUIから設定可能で、組織規模が大きくても細やかなコントロールが可能です。

Flux 側では、Namespace分離とRBACを組み合わせて「チームごとに分掌する」方式を取ります。マルチテナンシーガイドラインが整備されているため、シンプルながら実践的な分離運用を構築しやすいのが特徴です。どちらのツールを選んでも「誰がどこに何を適用できるか」を明文化することが、監査性と安全性の両立につながります。

出典：Flux「Manage Kubernetes secrets with SOPS」
出典：Flux（旧ドキュメント）「SOPSガイド
出典：Argo CD「Secret Management（AVPなど）」
出典：argocd-vault-plugin（公式）
出典：KSOPS（kustomize-sops）
出典：Argo CD「RBAC」「AppProject」
出典：Flux「Multi-tenancy」

導入手順（最小構成→選定→段階移行）

最小構成：単一クラスター・単一リポジトリで“収束”を体験

GitOpsを導入する際はいきなり大規模に始めるのではなく、まずはシンプルな最小構成から始めるのが成功のポイントです。 典型的には「1つのクラスター」「1つのリポジトリ」「1つの環境（例：ステージング環境）」を対象にし、そこでDeploymentやServiceといった基本的なリソースをGitで管理します。

Argo CDを使う場合は、UIを通じて差分や同期状態を確認し、Sync Wavesの仕組みを使ってリソース適用の順序（例：CRDを先に適用、その後にカスタムリソースを適用）を整理します。これにより「なぜ今このリソースが適用されたのか」が可視化され、チームで共通理解を得やすくなります。

Fluxを使う場合は、GitRepository と Kustomization（または HelmRelease）だけで最小限の同期ループを作り、Gitへの変更が自動で環境に反映される流れを体験します。ここでは「変更 → 収束 → 差分解消」という一連のプロセスを、チーム全員が肌で感じることが大切です。 導入初期から「人手でのkubectl適用は禁止」とルールを決めてしまうと、GitOpsの文化が早く根付きます。

どちらを選ぶ？判断軸（UI／拡張性／周辺機能）

導入が進むと「自分たちのチームに合うのはArgo CDか、Fluxか」という判断が必要になります。その際の判断基準はいくつかあります。

• UIや可視化が最優先なら、Argo CDが向いています。 ApplicationSetを使ったマルチクラスター展開、Sync制御の細やかさ、リソースヘルスの見える化など、運用を「見える形」にする機能が充実しています。加えて、イメージの自動更新には「Argo CD Image Updater」という公式ツールを追加することが多いです。

• 小さく始めて段階的に積み上げたい、あるいは秘密情報の取り扱いをSOPSで完結させたいなら、Fluxが向いています。Fluxは Image Automation 機能を持ち、コンテナレジストリの更新を検知してGitにPRを作成し、その差分を自動反映させることが可能です。つまり「イメージの更新も含めてGitOpsで完結させたい」場合に自然に馴染みます。

また、プログレッシブデリバリー（段階的なリリース）を重視する場合は、Argo CDなら Argo Rollouts、Fluxなら Flagger といった専用コンポーネントを追加することで、カナリアリリースやブルーグリーンデプロイも実現できます。どちらも実績豊富で、商用利用に耐えうる信頼性があります。

段階移行：ブートストラップ→マルチ環境→マルチクラスター

最小構成での成功体験を積んだら、次はスコープを広げていきます。

まずはステージング→本番のように、環境ごとの枝分かれを導入します。ブランチ戦略（例：mainを本番、developをステージング）やディレクトリ分離（environments/staging、environments/prod）を設計し、どの環境にどの変更を反映させるかを明確にしましょう。

その後、マルチクラスター展開に進みます。Argo CDでは ApplicationSet の Cluster Generator を使って複数クラスターに展開でき、Fluxでは各クラスターごとにブートストラップを繰り返し、マルチテナンシーのガイドに沿ってNamespaceや権限を整理します。

最終的には「誰が・どこに・どうやってデプロイできるか」をGitの構造で表現し、必ずレビューと自動テストを通す文化を作ることが重要です。ここまで到達すると、GitOpsが単なるツール導入ではなく「チーム全体の運用モデル」として定着します。

出典：Argo CD「Sync Waves／Health
出典：Flux「Helm Controller／Image Automation」
出典：Argo CD「ApplicationSet（Cluster Generator）」
出典：Argo Rollouts（プログレッシブ配信）
出典：Flagger（プログレッシブ配信）
出典：Argo CD Image Updater（イメージ自動更新）

まとめ：GitOpsは“運用の言語”、ツールはチームの強みで選ぶ

GitOpsは単なるツールの名前ではなく、「宣言的に状態を記述し、自動で収束させ、監査可能にする」という一連の思想であり、いわば“運用の言語”です。

Argo CD は、GUIを中心にした分かりやすさと表現力を武器に、組織が「すぐに効果を感じやすい」仕組みを提供します。ApplicationSetやSync制御の柔軟性により、複雑な環境にも対応できます。

Flux は、コントローラー群を積み重ねる構成により「最小から始めて大きく育てる」スタイルを実現できます。SOPSとのネイティブ連携やImage Automationの仕組みは、「すべてをGitに集約する」というGitOpsの原則に忠実な運用を可能にします。

どちらを選ぶにせよ、まずは単一環境でPull型の収束を体験し、「人手でのkubectl適用は禁止、すべてGit経由で管理する」という文化を定着させることが重要です。その後、段階的にステージング→本番→マルチクラスターと広げていけば、スピードと安全性を両立した運用体制を自然に築けます。

GitOpsは単なる流行語ではなく、開発から運用に至るまでのプロセスを「誰もが理解できる形で表現する」仕組みです。ツール選定はチームの規模や強みに合わせて行い、自分たちにとって現実的で持続可能なモデルを構築していくことが成功の鍵となります。