こんにちは、インフラエンジニアのryuです。
本番サーバーにSSHでログインして、ドキドキしながらデプロイのコマンドを打つ。うまくいったかどうかは、あとから画面を見て確認する。もし壊れていたら、慌てて元に戻す手順を思い出す。
こういう運用、心当たりはないでしょうか。
私も昔はそうでした。手順書を片手に、深夜のリリース作業で手が震えたことを今でも覚えています。
いま、その「手作業のデプロイ」を根っこから変えようとしている考え方があります。それが GitOps です。
2026年のいま、GitOps はもう一部の先進企業だけのものではありません。Kubernetes を使う現場では、むしろ「入れていて当たり前」の基礎技術になりつつあります。
今日は、この GitOps とは何なのか、なぜここまで広がったのか、そして自分の現場でどう始めればいいのかを、できるだけ身近な言葉でお話しします。
GitOpsって、そもそも何なのでしょうか？¶
GitOps を一言でいうと、インフラやアプリの「あるべき状態」をすべてGitに書いておき、その通りに現物を自動でそろえ続ける運用のやり方です。
言葉だけだと難しく聞こえますね。身近なたとえで考えてみましょう。
引っ越しをするとき、あなたは「この部屋はこう配置したい」という間取り図を先に描くのではないでしょうか。GitOpsでいうGitは、この間取り図にあたります。
そして、間取り図を見ながら家具を動かしてくれる几帳面な業者さんがいると想像してください。誰かが勝手にソファをずらしても、業者さんは図面と見比べて、そっと元の位置に戻してくれる。
この「図面と現物をいつも見比べて、ズレていたら図面通りに直す係」こそが、GitOpsの心臓部です。人間ではなく、ソフトウェアがこれを24時間やってくれます。
「Gitが唯一の正」という発想¶
これまでのインフラ運用では、「本当の状態」はサーバーの中にありました。誰かが手で変えれば、それがそのまま現実になる。だから「今どうなっているか」は、実際に入って見ないと分かりませんでした。
GitOpsはここを逆転させます。本当の正しい状態はGitに書いてあるものだ、と決めるのです。これを「シングル・ソース・オブ・トゥルース（唯一の信頼できる情報源）」と呼びます。
こうすると、うれしいことがいくつも起きます。
変更したいときは、コードを直してGitに「マージ」するだけ。あとは自動で反映されます。デプロイという特別な作業が、日々のコードレビューの延長になるわけです。
元に戻したいときは、そのコミットを「revert（打ち消し）」するだけ。手順書を探す必要はありません。
そして「いつ・誰が・何を変えたか」は、Gitの履歴がそのまま監査ログになります。台帳を別に付ける必要がないのです。
GitOpsの4原則（OpenGitOps）¶
「GitOpsっぽいこと」は人によって解釈がバラバラでした。そこでCNCF（クラウドネイティブ技術の標準化団体）の下にある OpenGitOps というプロジェクトが、2021年にバージョン1.0として4つの原則にまとめました。
言葉は堅いのですが、中身はここまで話してきたことそのものです。
| 原則 | ざっくり言うと |
|---|---|
| 宣言的（Declarative） | 「どうやるか」ではなく「どうあってほしいか」を書く |
| バージョン管理と不変性 | 状態はGitに履歴付きで残し、後から書き換えない |
| 自動的にプルされる | エージェントがGitから設定を自分で取りに行く |
| 継続的に調整される | 現物とGitのズレを見張り、いつも図面通りに直す |
この4つが揃ってはじめて「GitOpsをやっている」と胸を張れる、というわけです。
GitOpsは新しいツールの名前ではなく、「Gitを中心に据えた運用の作法」です。だからArgo CDでもFluxでも、この4原則を満たしていればどれもGitOpsと呼べます。
インフラを「コードとして書く」考え方そのものに興味が出てきた方は、OpenTofuとTerraform、IaCの現在地の記事もあわせて読むと、GitOpsとの違いがすっきり分かると思います。
なぜ2026年に、GitOpsが「当たり前」になったのか¶
数年前まで、GitOpsは「意識の高いチームの試み」という位置づけでした。それが2026年のいま、大きく変わっています。
背景には、Kubernetes（コンテナをたくさん束ねて動かす仕組み）の普及があります。管理する対象が増えるほど、手作業のデプロイは限界を迎えるからです。
プッシュ型とプル型、何が違うのでしょうか¶
従来のデプロイは「プッシュ型」でした。CI/CDツールが外から本番環境に向けて設定を押し込む形です。
これには弱点がありました。押し込むために、外部のツールに本番環境への強い権限（鍵）を渡す必要があったのです。鍵を持つ場所が増えるほど、セキュリティのリスクは上がります。
もうひとつの弱点は、「押し込んだあと」を誰も見張っていないことでした。デプロイが終わった瞬間は正しくても、その後に誰かが手で設定をいじれば、現物はどんどん図面からズレていきます。いわゆる「設定のドリフト（じわじわズレ）」です。気づいたときには、どのサーバーが本当はどうなっているのか、誰も分からなくなっている。これが手作業運用のいちばん怖いところでした。
GitOpsは「プル型」です。本番環境の中にいるエージェントが、自分からGitを取りに行きます。そして取りに行くだけでなく、現物とGitを絶えず見比べ、ズレていれば黙って直します。だからドリフトが起きても、放っておけば元に戻る。この「勝手に直る」性質が、運用の安心感を大きく変えてくれます。
| 観点 | プッシュ型（従来） | プル型（GitOps） |
|---|---|---|
| 変更の流れ | 外から本番へ押し込む | 中から自分で取りに行く |
| 本番の鍵の置き場 | 外部ツールに渡す | クラスタ内に閉じる |
| ズレの自動修正 | 基本なし | 常に監視して直す |
| 元に戻す操作 | 手順が必要なことが多い | Gitをrevertするだけ |
方向がひとつ変わるだけで、安全性と分かりやすさが大きく変わる。ここがGitOpsの効いているところです。
数字で見る広がり¶
CNCFが2025年に公開した Argo CD の利用者調査では、回答者の97%が本番環境でArgo CDを使っているという結果が出ました。さらに、調査対象となったKubernetesクラスタのおよそ6割がArgo CDで管理されているといいます。
これはもう、実験ではなく本番の当たり前になった、ということを示す数字です。ほんの数年前まで「試しに入れてみた」段階だった技術が、これだけ短い間に主役の座に着いた。この速さこそ、GitOpsが解いている悩みがそれだけ多くの現場に共通していた証拠だと私は思います。
裏を返せば、いま学んでおくと「周りがこれから当たり前に使う技術を、一歩先に触れている」状態になれる、ということでもあります。
こうした「壊れにくく、素早く戻せる」運用は、信頼性を専門に扱う考え方とも相性が良いものです。あわせてSRE（サイト信頼性エンジニアリング）とは？を読むと、GitOpsが「速さと安定の両立」にどう効くのかが見えてきます。
Argo CDとFlux、どちらを選べばいいのでしょうか¶
GitOpsを実現するツールとして、いま二強と呼べるのが Argo CD と Flux です。どちらもCNCFの「Graduated（卒業）」という最上位のお墨付きを得た、成熟したプロジェクトです。
どちらもGitOpsの4原則を満たしているので、「どっちが正しい」という話ではありません。チームの好みと状況で選ぶものです。料理でいえば、材料も作る料理も同じで、使う道具が違うだけ、というイメージに近いでしょうか。
大づかみの違いを表にしてみます。
| 観点 | Argo CD | Flux |
|---|---|---|
| 性格 | 全部入りのプラットフォーム | 部品を組み合わせる道具箱 |
| 画面（UI） | 見やすいWeb画面が標準で付く | UIは基本なし（別ツールで補う） |
| 向いている人 | 状態を画面で見たいチーム | 細かく自作・自動化したいチーム |
| 学びやすさ | 最初のとっつきが良い | 慣れると柔軟だが玄人向け |
迷ったらどう決める？¶
正直にいうと、最初の一歩ならArgo CDが分かりやすいです。デプロイの状態が色付きの画面で見えるので、「今どうなっているか」が直感的に掴めます。初心者や、チームに説明する場面ではこの分かりやすさが効きます。
一方で、すでにコマンドラインでの自動化に慣れていて、必要な部品だけを軽く組み合わせたいなら、Fluxの身軽さが心地よいはずです。余計な画面がない分、動きが素直で、既存の自動化に溶け込ませやすいという声もよく聞きます。
チームの人数や、インフラを触るメンバーのスキルによっても答えは変わります。運用を複数人で分担していて「今の状態をみんなで眺めたい」なら画面のあるArgo CD、少人数で細かく作り込みたいならFlux、というように、自分たちの働き方に合わせて選ぶのがいちばんです。
どちらを選んでも、後から他方へ移ることはできます。大事なのはツール選びより、「Gitを唯一の正にする」という運用の型に慣れることです。
GitOpsを、小さく始めてみよう¶
概念だけでは腹落ちしませんね。ここでは雰囲気だけでも掴めるよう、Argo CDで「アプリのあるべき姿」を宣言する設定を見てみましょう。
下は「このGitリポジトリのこのフォルダの通りに、このクラスタを保ってね」とお願いする定義の例です。
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: sample-app
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/example/my-infra.git
targetRevision: main
path: apps/sample
destination:
server: https://kubernetes.default.svc
namespace: sample
syncPolicy:
automated:
prune: true # Gitから消したものは本番からも消す
selfHeal: true # 手で変えられても図面通りに戻す
注目してほしいのは selfHeal: true の一行です。これが「勝手に変えられても図面通りに戻す係」のスイッチにあたります。
一度これを効かせておけば、あとはGitにプルリクエストを出してマージするだけ。反映も、ズレの修正も、自動でついてきます。
いきなり本番に入れない¶
とはいえ、いきなり本番へ、はおすすめしません。順番はこうです。
まずは自分のパソコンやクラウドの検証環境に、小さなKubernetesを立てます。手元でコンテナに触れておきたい方は、DockerをLinuxにインストールする方法から始めると地続きで進めます。
次に、アプリを1つだけArgo CDに載せて、Gitを書き換えると本当に反映されるか、手で壊すと本当に戻るかを、自分の目で確かめます。この「おっ、勝手に直った」という体験が、GitOpsを腹落ちさせてくれます。
そのうえで、監視の目も一緒に育てておくと安心です。反映が正しく効いているかを確かめる意味で、オブザーバビリティ（可観測性）とは？の考え方も早めに触れておくとよいでしょう。
なお、こうした「コンテナ・Kubernetes・自動化」を体系立てて学びたい方に向けて、InfraAcademyでは手を動かしながら進める講座を用意しています。まずは全体像から掴みたい方は、AWSの学習ロードマップをのぞいてみてください。クラウド上で小さな環境を作って試す流れが、GitOpsの練習台にちょうどよいはずです。
Kubernetesそのものがまだピンと来ていない方は、kubernetesとは？を先に読んでおくと、この記事の内容がぐっと入りやすくなります。GitOpsは、あくまでKubernetesを上手に運用するための「作法」だからです。
まとめ¶
今日は、2026年に当たり前になりつつある GitOps についてお話ししました。
GitOpsとは、インフラやアプリのあるべき状態をGitに書いておき、ソフトウェアがその通りに現物を自動でそろえ続ける運用のやり方でした。ポイントを振り返ります。
Gitが「唯一の正」になるので、変更はマージ、切り戻しはrevert、監査はGitの履歴、とすべてがシンプルになります。
OpenGitOps の4原則（宣言的・バージョン管理と不変性・自動プル・継続的な調整）が、その土台にあります。
ツールはArgo CDとFluxの二強で、どちらもCNCFのGraduatedプロジェクト。迷ったら画面の分かりやすいArgo CDから、が私のおすすめです。
そして何より、いきなり本番ではなく、小さな検証環境で「勝手に直る」体験をしてみること。ここがいちばんの近道です。
最初は「Gitをいじるだけで本番が変わるなんて怖い」と感じるかもしれません。私も最初はそうでした。けれど一度この型に慣れると、むしろ手作業のほうが怖くなります。何が起きているかが常にGitに残り、いつでも巻き戻せるからです。
深夜のデプロイに手が震えていたあの頃の自分に、この仕組みを教えてあげたい。そう思えるくらい、GitOpsは運用を穏やかにしてくれます。あなたの現場でも、まずは一つのアプリから試してみませんか。
