Gitless GitOpsとは：OCIレジストリから配信する仕組みとFlux・Argo CDの設定

Gitless GitOpsは、KubernetesのマニフェストをOCIアーティファクトとしてコンテナレジストリに置き、Flux CDやArgo CDがGitではなくレジストリから取得して適用するGitOpsの構成です。開発者はこれまでどおりGitで設定を書いてレビューし、クラスターへ届ける経路だけをレジストリに替えます。本記事では2026年10月時点のFlux 2.10・Argo CD 3.5での設定、両ツールで挙動が違う点（メディアタイプと署名検証）、既存のGitRepository構成からの移行手順を扱います。なお、Gitを置き換えるバージョン管理ツール「Gitless」（gitless-vcs）とは別物です。

まとめ：Gitless GitOpsの要点

• 変わるのは配信経路だけ：Gitは人が書いてレビューする場所として残り、CIがマニフェストをレジストリへpushし、クラスター側のコントローラーはレジストリだけを読む。本番クラスターにGitの認証情報が要らなくなる。
• Fluxが本命：Fluxは2022年にOCIRepositoryで始め、2026-10-26のv2.10.0まで機能を積んできた。取得時にCosignまたはNotationで署名を検証できる。
• Argo CDはv3.1（2025-08-13）からBetaで対応：repoURL: oci://...で読めるが、受け付けるレイヤーのメディアタイプが限られ、Fluxが作ったアーティファクトは既定では読めない。ソースの署名検証もGitのGPGにしか対応していない。
• 失うものもある：レジストリにはGitの差分・blame・プルリクエストのレビューが無い。アーティファクトにGitのコミットSHAを刻み、ダイジェストで固定して追跡できるようにする。
• 見送ってよい条件：クラスターが1〜2個で、署名やSBOMを求める規制も無いなら、CIを作り込む手間に見合わない。

Gitless GitOpsの仕組み：Gitとレジストリの役割分担

Fluxの公式ドキュメント（Flux Core Concepts）は、Gitless GitOpsを「Fluxのコントローラーを完全にGitから切り離し、コンテナレジストリだけをクラスターの望ましい状態の情報源にするモデル」と説明しています。同じ箇所で、利用者から見ればGitは引き続き主要な入口であるとも書いています。起点は2022年7月8日にマージされたRFC-0003（Flux OCI support for Kubernetes manifests）です。

流れは3段です。

1. 開発者がGitにマニフェストの変更をpushし、プルリクエストでレビューする。
2. CIがKustomizeやHelmの出力を1つのOCIアーティファクトにまとめ、レジストリへpushして署名する。
3. クラスター内のFluxまたはArgo CDがレジストリを定期的に確認し、新しいダイジェストを見つけたら取得して適用する。

GitOpsそのものの4原則とPush型との違いはGitOpsとは：4原則とPush型との違い、Argo CD・Fluxの最小構成YAML【2026年10月】で扱っています。

Push型CI/CD・従来GitOpsとの運用比較

3つの方式を、クラスターが何に接続し、誰が鍵を持つかで並べると違いがはっきりします。

Gitless GitOpsはプル型のまま、クラスターから見た依存先をGitサーバーからレジストリへ移す方式です。アプリのイメージと同じレジストリに設定も置き、Gitへの参照を残さなければ、本番の依存先が1つ減ります。レジストリの選び方はコンテナレジストリとは？種類・選び方から企業の導入判断まで解説を参照してください。

Fluxで構成する：flux push artifactとOCIRepository

Fluxでは、CIでflux push artifactを実行し、クラスター側でOCIRepositoryとKustomizationを組み合わせます。Flux自体の構成要素はFlux CDとは？GitOps Toolkitの仕組みとArgo CDとの違いを実装者目線で解説で扱っています。

CIによるマニフェストのOCI化とキーレス署名

GitHub Actionsで、mainへのpushごとにアーティファクトを作り、キーレス署名してからproductionタグを付け替える例です。--revisionにブランチ名とコミットSHAを入れておくと、クラスター側のOCIRepositoryのステータスからGitの変更へ戻れます。ghcr.ioのリポジトリ名は小文字にする必要があります。GHCRに初めてpushしたパッケージは既定で非公開なので、クラスター側には読み取り用の認証（FluxはOCIRepositoryのspec.secretRef、Argo CDはリポジトリの認証情報）を別に用意します。CI側のdocker/login-actionの認証はクラスターへは引き継がれません。

name: publish-config
on:
  push:
    branches: [main]
permissions:
  contents: read
  packages: write
  id-token: write
jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: fluxcd/flux2/[email protected]
        with:
          version: 2.10.0
      - uses: sigstore/cosign-installer@v4
      - uses: docker/login-action@v4
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - name: Push, sign and promote
        run: |
          repo=oci://ghcr.io/your-org/config/app
          digest_url=$(flux push artifact ${repo}:${GITHUB_SHA::7} \
            --path=./deploy/production \
            --source="${{ github.server_url }}/${{ github.repository }}" \
            --revision="${GITHUB_REF_NAME}@sha1:${GITHUB_SHA}" \
            --output json | jq -r '.repository + "@" + .digest')
          cosign sign --yes "${digest_url}"
          flux tag artifact ${repo}:${GITHUB_SHA::7} --tag production

id-token: writeはキーレス署名でGitHubのOIDCトークンを使うための権限です。署名はタグでなくダイジェストに対して行います。flux push artifactとcosign signを組み合わせる形は、Flux CLI v2.10.0のヘルプに載っている例と同じです。鍵ペアで署名する手順はFlux OCI Artifactsのチートシートにあります。

OCIRepositoryによる取得・署名検証とKustomizationによる適用

クラスター側では、上のワークフローが署名したものだけを受け入れるよう、OIDCの発行者とサブジェクトを正規表現で縛ります。

apiVersion: source.toolkit.fluxcd.io/v1
kind: OCIRepository
metadata:
  name: app
  namespace: flux-system
spec:
  interval: 5m
  url: oci://ghcr.io/your-org/config/app
  ref:
    tag: production
  verify:
    provider: cosign
    matchOIDCIdentity:
      - issuer: "^https://token[.]actions[.]githubusercontent[.]com$"
        subject: "^https://github[.]com/your-org/your-repo/[.]github/workflows/publish-config[.]yaml@refs/heads/main$"
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: app
  namespace: flux-system
spec:
  interval: 10m
  sourceRef:
    kind: OCIRepository
    name: app
  path: ./
  prune: true

OCIRepositoryの仕様では、spec.verify.providerはcosignとnotationの2択です。Cosignの公開鍵で検証するときはmatchOIDCIdentityの代わりにsecretRefで拡張子.pubの鍵を入れたSecretを指します。matchOIDCIdentityは複数書くとどれか1つに一致すれば通ります。検証に通るとSourceVerified条件がTrueになり、通らなければ適用されません。

注意点が1つあります。仕様書には、公開Sigstoreの信頼ルート（Fulcio・Rekorの鍵）がローテーションしても検知しないと書かれています。信頼ルートを明示的に管理したい場合や、自前のSigstoreを使う場合はspec.verify.trustedRootSecretRefでtrusted_root.jsonを固定します（v2.9.0で追加）。

FluxInstanceによるクラスター設定のOCI同期

Flux Operatorを使う構成なら、ブートストラップの同期元そのものもOCIにできます。FluxInstanceの仕様で、spec.sync.kindはGitRepository・OCIRepository・Bucketから選べます。

apiVersion: fluxcd.controlplane.io/v1
kind: FluxInstance
metadata:
  name: flux
  namespace: flux-system
spec:
  distribution:
    version: "2.10.x"
    registry: "ghcr.io/fluxcd"
  sync:
    kind: OCIRepository
    url: "oci://ghcr.io/your-org/fleet"
    ref: "latest"
    path: "clusters/production"
    pullSecret: "oci-token-auth"

この設定で変わるのはFluxの同期元です。配下のGitRepositoryやHelmの参照も合わせてOCIへ移せば、クラスターからGitへの接続は残りません。pullSecretはkubernetes.io/dockerconfigjson型のSecretです。AWS・Azure・GCPのレジストリならproviderを指定してWorkload Identityで認証でき、Secret自体が不要になります。

Flux 2.7〜2.10で増えたGitless向けの機能

1年余りで、OCIまわりの機能は次のように増えました。日付はGitHubのリリース公開日です。

実務で効くのはv2.9.0のプラグインです。flux plugin install mirrorで入るflux mirror syncは、公開Helmリポジトリのチャートを自社レジストリへ複製します。複製したうえでHelmReleaseの参照先を自社レジストリへ替えれば、そのチャートの取得は外部の配布元の障害に左右されなくなります。flux schema validateはpush前にマニフェストのスキーマ違反を見つけます。CIで検証が失敗したらpushまで進まないようにしておけば、スキーマ違反のマニフェストはレジストリに入りません。アプリの設定値の誤りまでは検出しない点は従来と同じです。

v2.10.0のリリースノートには破壊的変更があります。object identityが常時有効になり、既定のRBACからserviceaccounts/tokenのcreate権限が外れました。Workload Identityでレジストリへ認証している環境は、更新前に必要なClusterRoleを付与しておきます。対応するKubernetesは1.35.2以上・1.36.1以上・1.37.0以上の3系列です。

Argo CDで構成する：oci://のrepoURLとメディアタイプ

Argo CDはv3.1.0（2025-08-13）でOCIをアプリケーションのソースとして扱えるようになりました。リリースノートの表記はBetaです。Helmチャートを使う構成はArgoCDでHelm chartを使う方法：valueFiles・マルチソースの設定とargo-cd chartでのインストール【3.5系】を参照してください。

Application定義とoras pushでの作り方

Argo CDのOCIガイドは、アーティファクトの作成にORASを例示しています。マニフェストのあるディレクトリで次のように実行すると、1レイヤーにまとめてpushされます。

oras push ghcr.io/your-org/config/app:1.4.0 .

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: oci://ghcr.io/your-org/config/app
    targetRevision: 1.4.0
    path: .
  destination:
    server: https://kubernetes.default.svc
    namespace: app
  syncPolicy:
    automated: {}

ガイドでは、イメージが単一レイヤーであることを前提にしています。tarball をpushするときは、メディアタイプを手で指定する必要があります。

Fluxで作ったアーティファクトを既定で読めない理由

FluxとArgo CDを併用している組織が最初につまずく点です。flux push artifactが作るレイヤーのメディアタイプはapplication/vnd.cncf.flux.content.v1.tar+gzipです（fluxcd/pkgのoci/constants.go）。一方、Argo CD v3.5.6のrepo-serverが既定で受け付けるのは次の3種類だけです。

• application/vnd.oci.image.layer.v1.tar
• application/vnd.oci.image.layer.v1.tar+gzip
• application/vnd.cncf.helm.chart.content.v1.tar+gzip

同じアーティファクトをArgo CDでも読ませるなら、repo-serverの環境変数ARGOCD_REPO_SERVER_OCI_LAYER_MEDIA_TYPESにFluxのメディアタイプを足します。値はカンマ区切りで、指定すると既定値を置き換えるため、既定の3種類も一緒に書いておきます。Argo CDだけで運用するなら、最初からoras pushで作るほうが設定を増やさずに済みます。

Argo CDのOCIソースで署名を検証できない制約

Argo CD v3.5.6のsource integrityが対応する方式は、GitコミットのGnuPG署名検証だけです。FluxのようにOCIアーティファクトの署名を取得時に検証する仕組みはありません。Gitless GitOpsを選ぶ理由が「設定に署名を付けて改ざんを防ぎたい」なら、現時点ではFluxを選びます。Argo CDを使い続ける場合は、CIの昇格ジョブでcosign verifyを通したダイジェストだけにタグを付けるなど、検証をクラスターの外に置くことになります。Podのイメージ署名をアドミッションで強制する方法はKyvernoとは？Kubernetesのポリシー適用の仕組みとCEL移行を解説で扱っていますが、これはマニフェストのアーティファクトではなくコンテナイメージが対象です。

Argo CDの周辺では、GitリポジトリからOCIへの格納とArgo CDのApplication展開をつなぐKokumiも出てきました。最新は0.17.0（2026-10-11）ですが、READMEには本番での利用は注意するよう書かれた実験段階のプロジェクトです。

Flux・Argo CD・Kubernetesの対応状況

2026年10月31日時点の現行版と、Gitless GitOpsでの立ち位置です。

KubernetesのImageVolumeは、OCIのイメージやアーティファクトを読み取り専用ボリュームとしてPodに直接マウントする機能です。フィーチャーゲートの一覧では、v1.31でalpha、v1.33でbeta（既定は無効）、v1.35で既定有効、v1.36でstableになりました。設定ファイルやモデルをPodに配る用途で、GitOpsの配信経路とは別物です。Gitless GitOps自体はImageVolumeが無くても動きます。

サプライチェーン対策として効く範囲

アプリのイメージに使っている署名・スキャン・SBOMの仕組みを、マニフェストにもそのまま使えるのがこの構成の実利です。署名やSBOMは、OCI 1.1のsubjectで元のアーティファクトに関連付けて同じレジストリに置けます（referrers API）。

• 改ざんの防止：クラスターは、特定のCIワークフローが署名したダイジェストしか適用しない。Gitの書き込み権限を奪われても、CIを通らない変更は配信されない。
• 鍵の削減：クラスターからGitのデプロイキーやトークンが消える。クラウドのレジストリならWorkload Identityで読み取り鍵も消せる。
• SBOMは別ツール：Cosignは署名のツールで、SBOMを作らない。SyftやTrivyで作ったSBOMをcosign attestで添付する。Trivyの使い方はTrivy（トリヴィ）の使い方｜インストールからイメージ・IaCスキャン、CI設定まで【v0.76対応】にあります。

効かない範囲もはっきりしています。署名はCIの出力であることしか保証しません。Gitに悪意ある変更がマージされれば、CIはそれをそのまま署名します。レビューの必須化やブランチ保護は、引き続きGit側で必要です。開発工程全体の対策はソフトウェアサプライチェーンセキュリティとは？開発工程に組み込む防御と2026年規制対応の実装判断で整理しています。

採用を判断する条件：向くケースと見送るケース

向くのは次のような環境です。

• 規制や顧客要件で、デプロイした設定の真正性を証明する必要がある。
• 本番ネットワークからGitサーバーへ出られない（閉域・エアギャップ）が、レジストリのミラーは置ける。
• クラスターが多く、1つのモノリポジトリを全クラスターがcloneする負荷が問題になっている。

反対に、次に当てはまるなら見送ります。

• クラスターが1〜2個で、Gitへの接続に困っていない。CIを1段増やす保守のほうが重い。
• Argo CDで運用しており、署名検証が目的。前述のとおりArgo CD単体では取得時に検証できない。
• 「今どのコミットが本番か」をGitの画面だけで追う運用に慣れている。

最後の点は見落とされがちです。KokumiのREADMEも、GitOpsで得ていた履歴・blame・差分・プルリクエストのレビューはOCIへ移すと失われると問題提起しています。--revisionでコミットSHAを刻む、本番のOCIRepositoryはタグでなくダイジェスト（spec.ref.digest）で固定する、昇格と切り戻しはそのダイジェストをGit上で書き換えるプルリクエストで行う、という3点を最初に決めておきます。こうすると、本番に何がいつ出たかがGitの履歴に残ります。spec.ref.digestはタグ指定より優先されるため、ダイジェスト固定とタグの付け替えは併用できません。

移行するかの判断や、CIとGitOpsの設計を外部と一緒に詰めたい場合は、一創のDevOps・CI/CD導入支援で相談を受けています。

既存のGitRepository構成からの移行手順

Fluxで、配信を止めずにGitからOCIへ切り替える順序です。

1. CIで並行pushを始める：既存のGitの運用は変えず、上のワークフローでアーティファクトを作る。flux diff artifactで、アーティファクトの中身がGitのディレクトリと同じファイルであることを確認する。
2. OCIRepositoryを追加する：同じ名前空間にOCIRepositoryを作り、SourceVerifiedとReadyがTrueになるのを見る。
3. Kustomizationの参照先を替える：sourceRef.kindをGitRepositoryからOCIRepositoryへ変える。pathはアーティファクトの中の相対パスになるため、--pathで詰めたディレクトリに合わせて直す。
4. Gitの接続を外す：GitRepositoryとデプロイキーのSecretを消し、Gitホスティング側のデプロイキーも失効させる。
5. 切り戻しを確認する：タグ追従ならflux tag artifactで前の版へproductionを付け直し、ダイジェスト固定ならspec.ref.digestを前の値に戻す。flux reconcile kustomization app --with-sourceを実行し、flux get kustomizationsでKustomizationがReadyになり適用まで済んだことを確かめておく。

移行でよく起きる失敗は3つです。matchOIDCIdentityのサブジェクトをワークフローのファイル名やブランチと一致させておらず検証で止まる。pathを直し忘れて何も適用されない。prune: trueのまま参照先を替え、差分のあるリソースが消える。flux diff artifactが比べるのはローカルのファイルとアーティファクトの中身だけで、クラスター上で何が消えるかまでは分かりません。3つめを避けるには、切り替えの間だけprune: falseにし、flux get kustomizationsでReadyを確認してからtrueに戻します。KustomizeのbaseとoverlaysをどうOCIに詰めるかはKustomizeとは？base・overlaysの仕組みとHelmとの違い・導入判断を実装者目線で解説が参考になります。

よくある質問

Gitless GitOpsはGitを完全に使わないのですか？

使います。設定を書いてレビューするのはGitのままで、Gitを使わなくなるのはクラスター側のコントローラーだけです。Fluxの公式ドキュメントも、利用者から見ればGitが主要な入口だと説明しています。

バージョン管理ツールのGitlessとは関係がありますか？

関係ありません。gitless-vcsはGitの操作を簡単にする別のツールで、GitHub上の最終リリースはv0.8.8（2019年5月）です。Gitless GitOpsはKubernetesへの配信方式の名前です。

FluxとArgo CDのどちらで始めるべきですか？

署名検証まで含めて組むならFluxです。FluxはOCIRepositoryのspec.verifyで取得時にCosignかNotationの署名を検証できますが、Argo CD v3.5.6のsource integrityはGitのGPG署名にしか対応していません。すでにArgo CDで運用しており、Gitへの接続を減らすことだけが目的なら、Argo CDのOCIソースで足ります。

Kubernetesのどのバージョンが必要ですか？

Gitless GitOpsに特定のKubernetes機能は要りません。条件になるのはFluxやArgo CDの対応範囲で、Flux v2.10.0は1.35.2以上・1.36.1以上・1.37.0以上をサポートします。ImageVolumeを併用する場合はv1.36以降ならstableです。

小規模なチームでも導入するメリットはありますか？

署名やエアギャップの要件が無ければ、小さいと言えます。クラスターが1〜2個なら、Gitへの接続を残した従来のGitOpsのほうが保守は軽く済みます。要件が出てから、上の移行手順で切り替えても遅くありません。

関連記事

• GitOpsとは：4原則とPush型との違い、Argo CD・Fluxの最小構成YAML【2026年10月】
• Flux CDとは？GitOps Toolkitの仕組みとArgo CDとの違いを実装者目線で解説
• コンテナレジストリとは？種類・選び方から企業の導入判断まで解説
• ソフトウェアサプライチェーンセキュリティとは？開発工程に組み込む防御と2026年規制対応の実装判断