GitOpsを取り入れるかの判断 — Gitを真実の源とした構成管理の適用範囲

GitOpsの導入可否は「Gitを唯一の真実の源とする」という原則がチームのワークロードと運用体制に合致するかどうかの設計判断です。すべての構成変更をGit経由に統一することで変更履歴の追跡とドリフト検知が自動化できる一方、ステートフルなデータ管理やシークレット操作など、Gitに乗せるべきでない領域も存在します。この記事では、GitOpsが有効な場面と除外すべき場面の境界、ツール選定と同期方式の判断軸、そして見落とされがちな落とし穴を設計判断の観点から整理します。

GitOpsで解決できる問題と解決できない問題の整理

ドリフト検知と宣言型構成の自動修復

GitOpsが最も力を発揮するのは、クラスターや仮想マシン群の「あるべき状態」と「実際の状態」のずれを継続的に検知し、自動で修復するループを作りたい場面です。Kubernetesのようにリソース定義を宣言型YAMLで管理できる環境では、Gitリポジトリに格納されたマニフェストが単一の正典となり、誰かがkubectlで直接変更しても次の同期サイクルで元に戻ります。現場では10クラスター以上を横断的に運用するチームほど、この自動修復の恩恵が大きいという話をよく聞きます。変更の意図がコミットログに残るため、障害発生時の原因特定も格段に速くなります。

解決できない問題 — ステートフルデータとシークレット

一方でGitOpsが解決できない問題は明確です。データベースのデータ、Kubernetesシークレットの中身、証明書の秘密鍵などは原則としてGitにプレーンなまま格納できません。SealedSecretsやExternal Secrets Operatorを組み合わせて「シークレットの参照先情報だけ」をGitに置くアーキテクチャは存在しますが、それはGitOpsの補完技術であって、GitOps単体で解決できるものではありません。「GitOpsを入れたからシークレット管理も統一できる」という期待は設計の誤認であり、シークレット管理は別途の設計が必要です。

適用価値が薄い領域の見極め

デプロイ頻度が週1回以下のワークロードや、1台から3台程度の小規模な構成では、GitOpsの仕組みを維持するコストが得られる価値を上回る場合があります。ツールのインストール、RBAC設計、Git操作の標準化、監視設定といった初期コストを正直に見積もった上で、適用するワークロードを絞り込む判断が重要です。「全部GitOpsに移行する」という方針より「まず5つのマイクロサービスに限定して導入する」という段階的な適用が現場では機能しやすく、後から範囲を広げる余地も保てます。

Argo CD vs Flux — ツール選定の判断軸比較

判断軸	Argo CD	Flux
UI	標準WebUI搭載	CLI・通知のみ
マルチテナント	Project + RBAC	Kustomization + SA分離
エコシステム	Argoファミリー統合	コントローラー独立構成
大規模展開	ApplicationSet対応	Kustomize/Helm Controller
学習コスト	UIで状態確認しやすい	YAML・CLIスキル前提
ロックイン	Argoエコシステム依存	特定ベンダー依存なし

UIとオペレーションモデルの違い

Argo CDはWebUIを標準で提供しており、チームにKubernetesリソースの状態を視覚的に確認する手段を与えます。デプロイ状況をダッシュボードで共有したい場合や、Kubernetesに不慣れなメンバーも状態確認に関わる場合、Argo CDのUIは運用の摩擦を減らす設計判断になります。一方でFluxはUIを持たず、kubectl pluginやNotification Controllerによるアラートで状態を把握する設計です。「UI不要、GitとCLIだけで完結したい」という方針のチームには、Fluxの方が余計な依存を増やさずに済みます。

マルチテナントとRBAC設計の違い

複数チームが1つのクラスターを共有するマルチテナント環境では、Argo CDのProject概念による名前空間レベルの権限分離が有効に機能します。ApplicationSetと組み合わせると、50を超えるアプリケーションを1つの設定ファイルでテンプレート展開する運用も現実的です。Fluxの場合はKustomizationリソースとサービスアカウントの組み合わせで権限分離を設計しますが、Kubernetes RBACの深い理解が前提となるため、チームのスキルセットを確認してから選定すべきです。

エコシステムへの依存と拡張性の判断

Argo CDはArgo WorkflowsやArgo Rolloutsとの統合でカナリアリリースや段階的ロールアウトを組み込める一方、Argoエコシステムへの依存が深まります。Fluxは特定のベンダーエコシステムに縛られず、Helm ControllerやImage Automation Controllerといった独立したコントローラーの組み合わせで機能を追加します。「特定エコシステムへのロックインを避けたい」という設計方針があるならFluxの構成原則に親和性があります。どちらを選んでも、選定理由をADR（Architecture Decision Record）として残しておくことで、後からの方針変更を追跡しやすくなります。

プッシュ型とプル型の同期方式をどう選ぶか

プル型が前提とするクラスター内エージェントの意味

GitOpsの主流はプル型です。クラスター内に常駐するエージェントがGitリポジトリを定期的にポーリングまたはWebhookで監視し、差分があれば自動でapplyします。プル型の利点は、クラスターへの外部からの書き込み権限をCIサーバーに与えなくて済む点です。CIサーバーが侵害された場合でも、クラスター内への直接書き込み経路が遮断されるためセキュリティ境界を維持できます。ポーリング間隔は一般的に30秒から5分程度に設定されますが、変更検知の遅延とエージェント負荷のバランスを考慮して決定します。

プッシュ型を残す合理的な判断基準

プッシュ型を完全に排除できない場面も存在します。Helmfileによる複数クラスターへの一括デプロイや、Terraformによるクラウドリソースのプロビジョニングなど、クラスター内エージェントでは対処しにくい操作は引き続きCIパイプラインからのプッシュ型で管理するのが現実的です。プッシュ型を残す範囲を「クラスター外のリソース」に限定し、クラスター内のKubernetesリソースはプル型に統一するという境界の引き方が実務では機能しやすいです。

ハイブリッド構成における境界の明示

プル型とプッシュ型を混在させる場合、「どのリポジトリのどのパスがプル型の管理下か」をチームで明確に定義しないと、CIパイプラインとGitOpsエージェントの双方から同じリソースに書き込みが走るという二重管理が発生します。現場での失敗例として挙げられるのは、GitOps導入後も古いCDパイプラインを残したまま運用を続け、ドリフトの原因が特定できなくなるケースです。同期方式の境界を図として設計台帳に残す習慣が、後から参加したメンバーの混乱を防ぎます。

GitOpsが適さないワークロードをどこで除外するか

ステートフルワークロードの除外基準

データベース（MySQL、PostgreSQL）、メッセージキュー（Kafka、RabbitMQ）、分散ストレージ（Ceph）などのステートフルワークロードは、スキーマ変更やデータ移行を宣言型YAMLだけで表現できません。Helm chartでインストールは管理できますが、バージョンアップ時のデータ移行フローはGitOpsの同期ループの外で別途設計が必要です。「GitOpsでデプロイしているから構成変更も自動で安全」という誤認がトラブルの温床になるため、ステートフルワークロードのGitOps適用範囲は明示的に制限することが重要です。

高頻度・即時性が求められるワークロード

機械学習の推論エンドポイントやA/Bテストの設定変更のように、1日に数十回の更新が走り、かつ変更が数秒以内に反映されないと業務に支障が出るワークロードは、Gitコミット→同期ポーリング→applyのサイクルが摩擦になります。同期間隔を短く設定してもエージェントの負荷が増すだけで根本的な解決にならないため、この種のワークロードはGitOps管理から除外してAPIや専用のコントロールプレーンで管理する設計を検討すべきです。

除外ルールをチームで合意する設計フロー

除外するワークロードはドキュメントや設計台帳に明記しておくことが重要です。「このリソースはGitOpsの管理外」という情報がなければ、チームメンバーが後から誤ってGitOps配下に追加してしまうリスクがあります。新規ワークロードをオンボードする際の確認フローとして、以下の判断基準を組み込むと効果的です。

• 宣言型YAMLで完全に表現できるリソースか
• データや状態を持たないステートレスな処理か
• 変更頻度がGitOpsの同期サイクルに収まるか
• ロールバックをGit revertで安全に実施できるか
• チームが変更をPullRequestで管理する体制にあるか

ブランチ戦略と環境ごとの適用範囲の決め方

ブランチベースとディレクトリベースの選択

GitOpsにおける環境分離の設計パターンは大きく2つあります。dev/staging/productionをそれぞれ別ブランチで管理するブランチベースと、同一ブランチ内でenvs/dev、envs/productionのようにディレクトリを分けるディレクトリベースです。ブランチベースは環境ごとの差分が視覚的に分かりやすい反面、マージ漏れや複数ブランチ間の追従作業が増えます。ディレクトリベースはKustomizeのオーバーレイ構造と相性が良く、10環境以上を管理する場合にスケールしやすい傾向があります。

本番環境への自動同期の制限設計

本番環境のGitOps適用は「自動同期するか、手動承認後に同期するか」を明確に決める必要があります。自動同期はオペレーションコストを下げますが、Gitへの誤プッシュが即座に本番に反映されるリスクを持ちます。構築を担当したあるチームでは、staging環境は自動同期、production環境は夜間メンテナンス枠のみ自動同期を許可し、それ以外は手動トリガーに限定する設計を採用していました。本番への適用範囲を段階的に広げる方針は、GitOps移行期のリスクを下げる判断として有効です。

複数チームが関わるリポジトリの権限境界

チームAはフロントエンド、チームBはバックエンド、チームCはインフラという分業体制でGitリポジトリを共有する場合、Argo CDのApplicationSetやFluxのKustomizationでパスごとに管理範囲を分割し、それぞれのチームがownershipを持つ領域だけ変更できるよう権限設計が必要です。リポジトリ内のCODEOWNERSファイルとGitOpsツールのRBACを連動させることで、誤った変更が他チームの管轄領域に反映されることを防げます。

Gitへの直接書き込みと間接書き込みの境界設計

手動マニフェスト編集を許容する条件

GitOpsを導入してもすべてのGit書き込みをパイプライン経由にする必要はありません。インフラエンジニアが直接YAMLを編集してコミットする「手動書き込み」は、設定変更の頻度が低く、変更内容が複雑でレビューが必要な場面では合理的です。重要なのは「誰がいつどのパスに書いていいか」というルールを明確にし、全員がそれに従っている状態を維持することです。手動とパイプライン自動の書き込みが混在しても、Git履歴に残る限りは追跡可能です。

CIパイプラインからのGit書き込みの設計原則

アプリケーションのコンテナイメージタグを更新する処理は、多くの場合CIパイプラインがビルド完了後にGitリポジトリのYAMLを自動書き換えするという形で実装されます。この際、アプリコードのリポジトリとGitOps用のマニフェストリポジトリを分離する「2リポジトリ構成」が推奨されます。同じリポジトリにアプリコードとデプロイ設定を混在させると、CIのトリガー条件設計が複雑になり、ビルドが無限ループに陥るリスクがあります。

Image Update Automationの採用判断

FluxはImage Automation Controllerを使ってコンテナレジストリを監視し、新しいイメージタグが登録されると自動でYAMLを書き換えてGitにプッシュする仕組みを提供します。この機能はタグのセマンティクス（semverの範囲指定など）を正確に設計しないと、意図しないバージョンへの自動更新が走るリスクがあります。Production環境では自動更新の対象タグを厳密に制限するか、この機能を無効化してCIが明示的にタグを指定する設計の方が安全な場合が多いです。

導入で見落としやすい落とし穴と収束条件の設計

収束ループが収束しないアンチパターン

GitOpsの同期エージェントが「あるべき状態に収束させようとしても収束しない」状態は、設計ミスのサインです。代表的な原因はAdmissionWebhookがリソース適用時に自動でフィールドを書き換えるケースです。Gitには記述されていないフィールドが付加されると、次の同期サイクルでエージェントが「差分あり」と判断してまた上書きを試みるという無限ループに陥ります。これを防ぐには、GitリポジトリにWebhookが付加するフィールドを含めるか、ignoreDifferencesの設定で意図的に差分を無視する設計が必要です。構築時にAdmissionWebhookの動作を事前に確認しておくことが、後からの設計変更を防ぐ近道です。

Git履歴の肥大化と追跡コストの増大

Image Update AutomationやCIからの自動コミットが頻繁に走ると、Gitの履歴が短期間で数万コミットに膨れ上がるケースがあります。1日100回ビルドが走る環境では1ヶ月で約3000コミットがマニフェストリポジトリに積み重なり、git logでの追跡や差分確認が実質不可能になります。コミットのスカッシュポリシーや、マニフェストの変更を一定間隔でまとめてコミットするバッチ設計を最初から組み込んでおくことが、長期運用の品質を保つ上で重要です。

チームのGit操作習熟度とのギャップ

GitOpsは「GitをAPIとして扱う」思想であり、チーム全員がGitのブランチ操作、コンフリクト解消、PullRequestを通じた変更管理に習熟していることが前提です。しかし現場では、インフラエンジニアがIaCに慣れていても、GitのワークフローがGitHub Flowレベルまで統一されていないケースが少なくありません。GitOps導入の失敗要因として最も多く挙げられるのは技術的な問題ではなく、Gitへの直接プッシュや変更レビューの省略といった運用の形骸化です。導入前にGit操作の基準をチームで合意し、CIでPRチェックを強制するガードレールを設ける設計が不可欠です。手を動かす実装の詳細はセミナーや専門書に委ねつつ、この記事で整理した設計判断の軸を土台に適用範囲を決定することが、GitOps導入を成功させる第一歩です。