フレームワーク活用ガイドひとことで言うと#
Gitリポジトリに格納された宣言的な設定ファイルを「唯一の信頼源（Single Source of Truth）」とし、リポジトリの状態と実環境を自動的に同期させることで、デプロイと運用を安全・効率的に行う手法。
押さえておきたい用語#
- 宣言的設定（Declarative Configuration）
- 「どうやるか」ではなく**「あるべき状態」を記述する**設定方式のこと。Kubernetesマニフェストやterraformファイルが代表例で、状態の差分を自動的に解消する。
- Pull型デプロイ（Pull-based Deployment）
- CI/CDパイプラインから環境にpushするのではなく、環境側のオペレーターがGitリポジトリの変更を検知して自動で引っ張るデプロイ方式のこと。GitOpsの特徴的な仕組み。
- ドリフト検知（Drift Detection）
- Gitリポジトリに定義された状態と実環境の状態が乖離していないかを監視する機能のこと。手動変更によるドリフトを検知してアラートまたは自動修復する。
- GitOpsオペレーター（GitOps Operator）
- Gitリポジトリを監視し、リポジトリの状態と実環境を自動的に同期させるツールのこと。Argo CDやFlux CDが代表例。
GitOpsの全体像#
こんな悩みに効く#
- 本番環境に誰がいつ何を変更したか追跡できない
- 手動デプロイによるミスや環境差異が頻発する
- ロールバックの手順が複雑で、障害からの復旧に時間がかかる
基本の使い方#
環境のあるべき状態をコードとして定義し、Gitリポジトリに格納する。
- Kubernetesマニフェスト、Helmチャート、Kustomizeなどで環境を宣言的に記述する
- アプリケーションコードのリポジトリと、環境設定のリポジトリを分離する（推奨）
- すべての変更はプルリクエスト経由で行い、レビュー・承認を必須にする
ポイント: 手動でkubectl applyやSSHログインをしない。すべてGit経由で変更する。
Gitリポジトリと実環境を自動同期するツールを導入する。
- Argo CD、Flux CDなどのGitOpsオペレーターを選定する
- オペレーターがGitリポジトリを定期的にポーリング（またはWebhookで検知）
- リポジトリの状態と実環境の差分を検知し、自動的に同期する
ポイント: Pull型デプロイ（オペレーターが環境側からGitを引っ張る）がGitOpsの特徴。CI/CDパイプラインからpushする方式とは異なる。
開発からデプロイまでの一連のフローを整備する。
- 開発者がアプリコードを変更 → CIでテスト・ビルド・イメージ作成
- CIがイメージタグを環境設定リポジトリのマニフェストに反映（PRを自動作成）
- PRがマージされると、GitOpsオペレーターが自動で環境に反映
ポイント: CI（ビルド・テスト）とCD（デプロイ）の責務を明確に分離する。
環境の状態がGitから逸脱していないかを常に監視する。
- オペレーターのドリフト検知機能を有効にし、手動変更をアラートで通知する
- ドリフトを検知したら自動的にGitの状態に戻す（自動修復）
- ロールバックはGitのrevertで実現。git revert → 自動同期 → 環境が前の状態に戻る
ポイント: ロールバックがgit revertだけで完了するのは、GitOpsの最大のメリットの一つ。
具体例#
状況: 30人のエンジニアが開発するSaaS。手動でkubectl applyしてデプロイしており、月に2〜3回の設定ミスによるデプロイ事故が発生。ロールバックに平均30分。
構成:
| コンポーネント | ツール |
|---|---|
| アプリリポジトリ | GitHub + GitHub Actions（CI） |
| 環境設定リポジトリ | Kustomizeベース（dev/staging/prod） |
| GitOpsオペレーター | Argo CD |
| シークレット管理 | Sealed Secrets |
デプロイフロー: PR マージ → CI がイメージビルド → 設定リポジトリにタグ更新PR自動作成 → レビュー後マージ → Argo CDが3分以内に反映
結果: デプロイ事故が月2〜3回→0回に。ロールバック時間が30分→3分（git revert 1コマンド）。「誰がいつ何をデプロイしたか」がGit履歴で完全追跡可能に。
状況: 金融サービスを提供する企業。PCI DSS準拠のため、本番環境の全変更に「誰が・いつ・何を・なぜ変更したか」の証跡が必要。手動での証跡記録に月60時間のコスト。年次監査の準備に2ヶ月。
GitOps導入:
- 全環境変更をGitのPR経由に統一（手動変更を完全禁止）
- PRテンプレートに「変更理由」「影響範囲」「承認者」を必須入力
- Argo CDのドリフト検知で手動変更をSlack即時通知＋自動修復
- Git履歴＝監査証跡として活用
結果: 手動での証跡記録コストが月60時間→0時間に。年次監査の準備が2ヶ月→2週間に短縮。「Gitの履歴を見ればすべてわかる」状態になり、監査法人からも高評価。
状況: 地方自治体のクラウド基盤を管理する3人のインフラチーム。担当者がSSHログインして手動設定しており、環境構築手順が個人のメモに依存。担当者の異動で再現不能な環境が発生。dev/staging/prodの設定差異が月10件。
GitOps導入:
- Kustomizeで環境ごとの差分をオーバーレイで管理（base + overlays/dev, staging, prod）
- Flux CDで3環境を自動同期
- 新環境の構築は「リポジトリをフォーク→環境名を変更→Flux CDに登録」の3ステップ
結果: 環境差異が月10件→0件。新環境の構築が2日→2時間に。担当者が異動しても「リポジトリを読めばすべてわかる」状態を実現。kubectl操作の属人化が完全に解消。
やりがちな失敗パターン#
- アプリコードと環境設定を同じリポジトリで管理する — アプリの変更のたびに環境設定のCIが走り、逆もまた然り。リポジトリを分離して責務を明確にする
- 手動変更を許容してしまう — 「緊急だから」とkubectl applyを許可すると、Gitとの乖離が常態化する。すべての変更はGit経由というルールを徹底する
- シークレットをそのままGitに入れる — 認証情報をGitにプレーンテキストで保存してしまう。Sealed Secrets、SOPS、External Secrets Operatorなどを使って暗号化管理する
- 環境ごとの設定差異が管理されない — dev/staging/prodの設定がバラバラのYAMLファイルに散在する。Kustomize overlaysやHelm valuesで環境差分を構造的に管理する
まとめ#
GitOpsは「Gitを唯一の信頼源とし、宣言的な設定を自動同期する」というシンプルな原則に基づく運用手法。変更の追跡性、ロールバックの容易さ、環境の一貫性という大きなメリットがある。Kubernetes環境では特に相性が良く、Argo CDやFlux CDと組み合わせることで、安全で効率的なデプロイ自動化を実現できる。