Gitless GitOpsとは？OCIレジストリ中心のGitOps新方式を仕組み・導入まで解説

Gitless GitOpsは、Kubernetesの設定ファイルをOCI（Open Container Initiative）アーティファクトとしてコンテナレジストリに格納し、CDツールがGitリポジトリを介さずにレジストリから直接取得してデプロイする運用方式です。Flux CDがv2.6（2025年5月）でこのモデルを正式版（GA）にしたことで実運用の選択肢に入りました。本記事では従来GitOpsとの違い、CI/CDのデータフロー、Flux・Argo CDの対応状況、Cosign署名によるサプライチェーン対策、そして導入手順と注意点までを整理します。

まとめ：Gitless GitOpsの要点

• 定義：マニフェストをOCIアーティファクトとしてレジストリに置き、CDツール（Flux等）がGitではなくレジストリを監視・取得してデプロイする方式。GitOpsの4原則（宣言的・バージョン管理・プル型・継続的リコンシリエーション）は維持される。
• Gitは捨てない：開発者が設定を記述する真のソースはGitのまま。変わるのはクラスターへの配信経路だけで、CDツールがGit認証情報とネットワーク経路を持たなくてよくなる。
• 最大の狙いはサプライチェーンセキュリティ：OCIアーティファクトにCosign署名・SBOM・脆弱性スキャンを適用でき、設定ファイルにもアプリと同等の真正性保証を付けられる。
• 対応状況：Flux v2.6でGA、Argo CDもv3.1（2025年8月）でネイティブOCI対応。導入の主役はCIパイプライン側に移る。
• 向き不向き：規制対応や大規模・マルチクラスターでは効果が大きい一方、小規模でCIが単純な環境では移行コストが利点を上回りやすい。

以下で仕組み・実装・セキュリティ・メリット/デメリット・導入手順を順に見ていきます。

Gitless GitOpsとは — 従来GitOpsとの違いと登場背景

GitOpsは、Kubernetesなどの実稼働状態をGitリポジトリ上の宣言的定義に常に同期させる運用手法です。OpenGitOpsの定義では、宣言的・バージョン管理（イミュータブル）・プル型・継続的リコンシリエーションの4原則を満たすものをGitOpsと呼びます。Gitless GitOpsはこの4原則を維持したまま、設定の配信先だけをGitからOCIレジストリへ置き換えるアーキテクチャです。Flux CDは2022年にOCI対応を導入し、v2.6でGitless GitOpsモデルを正式版にしました。ControlPlane社とFluxが公開した「D2（分散型デリバリ）参照アーキテクチャ」が、この構成をマルチテナント・大規模環境向けの設計として示しています。

従来GitOpsが抱えるGit運用の課題

従来型ではCI（継続的インテグレーション）がマニフェストをGitへプッシュし、Argo CDやFlux CDがGitを定期的にpullしてデプロイします。開発者に馴染みやすい反面、CDツールにGitサーバーへの読み書き権限・SSH鍵やPersonal Access Tokenの管理が必要になります。大規模環境ではリポジトリのサイズと更新頻度が増え、頻繁なgit pullのコストや権限管理が運用の負担になりやすい点が指摘されてきました。Git自体がアプリケーションコード向けの設計で、Kubernetesマニフェストの署名・スキャンといったサプライチェーン機能を標準では持たないことも背景にあります。

Gitless GitOpsの定義：OCIアーティファクトを配信のソースに

Gitless GitOpsでは、CIがKustomize・Helm・Jsonnetなどで生成したマニフェスト群を1つのOCIアーティファクトとしてパッケージ化し、コンテナレジストリへpushします。CDツールはGitではなくこのレジストリを監視対象にし、新しいバージョンのアーティファクトを検知するとクラスターへ適用します。従来の「git pull＋kubectl apply」が「registry pull＋apply」に置き換わる形です。OCIアーティファクトにはタグ・ダイジェストが付くためGitコミットと同様に変更履歴を追跡でき、アーティファクト自体はイミュータブルに扱われます。

「Gitレス」でもGitは残る — 役割の変化を整理

名前に反して、Gitを完全に捨てるわけではありません。開発者が設定を記述・レビューする真のソース（Single Source of Truth）はGitのままで、変わるのはクラスターへの配信経路だけです。実運用では、CIがGitの変更を検知してOCIアーティファクトを生成する際に、対応するGitコミットSHAをアーティファクトのアノテーションとして埋め込み、トラブル時にGitとレジストリを相互参照できるようにするのが定石です。この住み分けを押さえておくと、後述の権限設計やロールバックの考え方が理解しやすくなります。

アーキテクチャと動作の仕組み — CIからOCI、そしてCDへ

Gitless GitOpsのアーキテクチャは、CI/CDパイプラインをOCIレジストリ中心に組み替えたものです。CIがアプリイメージのビルドと同時にマニフェストをOCIアーティファクト化してレジストリへpushし、CDツールはレジストリ認証情報だけを持ってそこから取得・適用します。ここではデータフローと具体的な設定例、主要ツールの対応状況を見ます。

マニフェスト配信のデータフロー

基本の流れは次の3ステップです。(1) CIパイプラインがアプリイメージをレジストリへpushすると同時に、そのバージョンのマニフェストをOCIアーティファクトとして生成しレジストリへpushする。(2) FluxのOCIRepositoryなどがレジストリを定期ポーリングし、新しいアーティファクトを検知する。(3) CDツールがアーティファクトを取得・展開してクラスターへ適用する。CDツールはGitへアクセスしないため、Gitリポジトリのサイズや同期コストを気にせず配信ロジックに集中できます。

FluxのOCIRepositoryによるGitless設定と署名検証

Flux CDでGitlessを構成する中心となるのがOCIRepositoryリソースです。ここにレジストリのURLと参照タグ、そしてspec.verifyで署名検証ポリシーを定義します。キーレス署名（Cosign／Sigstore）を使うと、GitHub ActionsのワークフローがビルドしたアーティファクトだけをデプロイするようOIDCの発行者・サブジェクトで縛れます。

apiVersion: source.toolkit.fluxcd.io/v1
kind: OCIRepository
metadata:
  name: app-manifests
  namespace: flux-system
spec:
  interval: 5m
  url: oci://ghcr.io/your-org/manifests
  ref:
    tag: v1.0.0
  verify:
    provider: cosign
    matchOIDCIdentity:
      - issuer: "https://token.actions.githubusercontent.com"
        subject: "https://github.com/your-org/your-repo/.github/workflows/push.yaml@refs/heads/main"

公開鍵方式ならmatchOIDCIdentityの代わりにsecretRefでCosign公開鍵を格納したSecretを指す形になります。適用するマニフェストの束はResourceSetやFluxInstance（Flux Operator）で指定します。なお旧来の解説にある「PackageBundle」というリソースは存在しないため、実在するのはOCIRepository・ResourceSet・FluxInstance・ImageUpdateAutomationである点に注意してください。

Flux・Argo CD・Kubernetesの対応状況

主要ツールのOCI／Gitless対応は次のとおりです。Flux CDが先行し、Argo CDも2025年に追随しました。設定をPodへ直接マウントするKubernetes側の機能も進んでいます。

Argo CDはv3.1でネイティブOCI対応が入り、repoURL: oci://…とtargetRevisionでアーティファクトを参照できます。ImageVolumeはalpha（v1.31・2024年）からbeta（v1.33・2025年4月）へ昇格しましたが、beta段階のためImageVolumeフィーチャーゲートの有効化と、containerd 2.1.0以上またはCRI-O 1.31以上のランタイムが前提です。Kubernetesのバージョンごとの機能提供状況を確認したうえで採用可否を判断してください。

サプライチェーンセキュリティ強化 — Gitlessが解く課題

Gitless GitOpsを採用する最大の動機は、ソフトウェアサプライチェーンのセキュリティ強化です。従来はKubernetes設定が「Git上のコード」として扱われ、署名や脆弱性管理の仕組みが標準では乏しいままでした。設定をアプリと同じレジストリエコシステムに載せることで、真正性の暗号的保証をそのまま適用できます。

Cosign署名・検証とSBOMによる真正性の担保

CIはマニフェストアーティファクトをレジストリへpushする際にCosignで署名し、署名をreferrerとして同じレジストリに格納します。CDツールは前述のspec.verifyで検証し、「CIパイプラインの正当な出力である」ことを保証します。なおCosignは署名（Sigstore）を担うツールで、SBOMそのものは生成しません。あわせてCIでSBOM（Software Bill of Materials）を生成してアーティファクトに添付すれば、設定が参照する依存関係を明文化し、Harborなどのレジストリ機能で脆弱性スキャンと組み合わせられます。SBOMの基礎はAmazon InspectorによるSBOMエクスポートの解説も参考になります。GitベースのGitOpsでは実現しづらかった、設定ファイル込みの一元的なセキュリティ管理が可能になる点が実質的な差別化要因です。

Workload Identityによるキーフリー認証

従来はGitサーバーへのSSH鍵やPATが必要でしたが、Gitlessでは代わりにKubernetes Workload Identity（OIDC連携）でOCIレジストリに認証するのが推奨です。GKEやAWS EKSでServiceAccountをクラウドのIDプロバイダーと連携させ、FluxがそのSA権限でレジストリへアクセスします。GitHub Container Registry・Amazon ECR・Google Artifact Registryなどが対応しており、長期クレデンシャルのローテーションが不要になるため、鍵漏えい時の影響範囲を抑えられます。

EO14028・EU CRAなど規制要件との対応

ソフトウェアサプライチェーンへの規制も採用の後押しになっています。米国大統領令EO14028（2021年発令）はコードの署名・検証やSBOM提供を求め、EUのサイバー・レジリエンス法（CRA、2024年発効・主要義務は段階的に適用）は製品のサプライチェーン証跡と脆弱性管理を企業に課します。設定ファイルにも署名・SBOM・スキャンを適用できるGitlessの仕組みは、こうした要件への「Config as Code」ガバナンスの一手段として、金融や政府系など規制の厳しい領域で導入が始まっています。

メリットとデメリット：従来GitOpsとの比較

Gitless GitOpsは万能ではなく、得られる利点と引き換えにCI側の負荷が増えるトレードオフがあります。効果が出る条件と落とし穴を整理します。

サプライチェーン強化と権限簡素化のメリット

最大の利点はサプライチェーンセキュリティの強化です。署名検証・SBOM・脆弱性スキャンを設定ファイルにも適用でき、改ざんされたマニフェストのデプロイを止められます。これがGitlessを採用する主目的にあたります。副次的な利点として、CDツールに与える認証情報がレジストリ用だけになり、SSH鍵やPATの管理から解放されて権限設計が単純になります。性能面でも、大量マニフェストのリポジトリを繰り返しクローン・プルせずに済むためGitベースの更新遅延が解消され、テンプレート処理をCIに寄せることでCDが適用するマニフェストは常に確定済みとなり、デプロイの安定性が高まります。

CI負荷増と二重運用のデメリット

一方で、CIパイプラインの構築・保守負荷は増します。CIがマニフェストのビルド・署名・pushまで担うため処理が複雑になり、その分の管理コストが発生します。Gitを完全には手放さないため、コードをGitで管理しつつCIで生成・検証環境を整える二重の運用も必要です。ロールバックはOCIタグ／ダイジェスト単位で行うため、前バージョンへ即座に戻す手順を事前に決めておく必要があります。OCIタグとGitコミットの不一致でFluxが更新を検知しない、といった運用ミスも起きやすいので、タグ付けルールの標準化が欠かせません。

採用すべきでない場面 — 移行が過剰になるケース

効果測定なしに全環境へ広げるべき方式ではありません。小規模チームで既にCI/CDが単純に回っている環境では、マニフェストの生成・署名・pushを組む移行コストが利点を上回りやすく、Gitlessにする実益は薄くなります。CIツールの運用リソースやスキルが不足している組織も、複雑なワークフローを維持しきれずかえって不安定になりがちです。逆に、マルチクラスター・マルチリージョンで設定配布のスケーラビリティが問題になっている、あるいは規制で署名・SBOMが要求される——この2条件のどちらかに当てはまるときに投資対効果が明確になります。まずはステージングで小さく実証し、そこで効果が見えてから本番へ広げる進め方が現実的です。

導入手順と移行時の注意点

実際の導入は、環境評価・CIパイプライン構築・権限見直し・検証の順で進めます。事前準備を飛ばすと移行時の手戻りが大きくなります。

事前準備とツール選定

まず現状のGit構成・CIツール・レジストリの有無を棚卸しします。OCI対応のコンテナレジストリ（GHCR・Amazon ECR・Harborなど）を選び、アーティファクトのリポジトリ構造を設計します。クラスター側はFluxを導入してOCIRepositoryのCRDを用意し、レジストリ認証をWorkload Identityで行う計画（GKEのWorkload Identity連携やEKSのIAMロール）を立てます。コンテナ技術の基礎とレジストリ運用の理解が前提になるため、担当範囲を早めに決めておくと移行がスムーズです。

CIパイプラインの構築（flux push artifact＋署名）

CIはマスターブランチへのマージなどをトリガーに、マニフェストをOCIアーティファクト化してレジストリへ送ります。Fluxを使う場合はflux push artifactでGitコミットのショートSHAをタグに付けてpushし、続けてCosignで署名します。

flux push artifact \
  oci://ghcr.io/your-org/manifests:$(git rev-parse --short HEAD) \
  --path=./manifests \
  --source="$(git config --get remote.origin.url)" \
  --revision="$(git rev-parse HEAD)"

cosign sign --yes \
  ghcr.io/your-org/manifests:$(git rev-parse --short HEAD)

レジストリ認証にはWorkload Identityや短期トークンを用い、長期のユーザー名／パスワードを避けます。各ステップにログとエラー通知を仕込み、CIが失敗するとCDに何も届かなくなるため早期検知できる体制にしておきます。

権限見直しと移行時によくあるトラブル

Gitless化により、CDツールに必要な権限はレジストリの読み取りだけになります。FluxのServiceAccountにはイメージをPullできる権限のみを付与し、Gitトークンは不要にします。移行時に多いのが認証エラーとタグ不一致で、OCIタグとFlux側マニフェストのタグ名がずれると更新が検知されません。CIでGitコミットIDと一致するタグを付け、CDと同じkubectl／kustomizeバージョンを使ってマニフェスト互換性の問題を避けます。本番前にステージングで、アーティファクト取得失敗・認証情報の更新漏れ・破損マニフェストのpushといった異常系を検証しておくと安全です。

よくある質問

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

いいえ。開発者が設定を記述・レビューする真のソースはGitのままです。Gitlessが指すのはクラスターへの配信経路で、CDツールがGitではなくOCIレジストリから設定を取得する点だけが変わります。多くの構成ではGitコミットSHAをアーティファクトに埋め込み、Gitとレジストリをひもづけてトレーサビリティを保ちます。

Argo CDでもGitless GitOpsはできますか？

できます。Argo CDはv3.1（2025年8月）でネイティブなOCI対応が入り、repoURLにoci://スキーム、targetRevisionにタグを指定してアーティファクトを取得できます。ただしGitless前提の署名検証や運用の作り込みは、より先行しているFlux CD（v2.6でGA）のエコシステムの方が現状は厚めです。

従来のGitOpsと比べてセキュリティはどう向上しますか？

設定マニフェストをOCIアーティファクトとして扱えるため、Cosignによるデジタル署名やSBOM、脆弱性スキャンをアプリと同じ仕組みで適用できます。CDツールに与える権限がレジストリ読み取りだけになり、SSH鍵やPATの管理も不要になるため、鍵漏えい時の影響範囲が狭まります。

Kubernetesのどのバージョンから使えますか？

Gitless GitOps自体はFlux v2.6やArgo CD v3.1が動く一般的なKubernetesで利用できます。設定をPodへ直接マウントするImageVolumeを併用する場合はv1.33のbeta機能となり、ImageVolumeフィーチャーゲートの有効化とcontainerd 2.1.0以上（またはCRI-O 1.31以上）が必要です。

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

限定的です。CIが単純に回っている小規模環境では、署名・SBOM・pushを組む移行コストが利点を上回りやすくなります。規制で署名やSBOMが求められる、またはマルチクラスターで配信のスケーラビリティが課題、という条件に当てはまる場合に投資対効果が明確になります。

関連記事

• Kubernetes（クーベネティス）とは？読み方・K8sの意味から仕組みまで初心者向けに解説
• Kubernetes 1.34の新機能・変更点とEOL｜DRA GA・再起動ルール・EKS対応を解説
• Amazon Inspector SBOM Exportの主要な機能と特長
• コンテナ技術とは何か：仮想化との違いや基本概念を解説