はじめに

Kubernetes 上で動かすコンテナのイメージだけではなく、設定も OCI レジストリに置いて配る構成が広がりつつあります。Helm は 3.8 以降でチャートをレジストリに保存できるようになり、公式ドキュメントでもチャートの保存・共有には OCI 対応のレジストリを使うことが推奨されています。さらに Argo CD は、Helm チャートに限らず Kubernetes マニフェスト全般をレジストリから取得できるようになりました（公式ドキュメント）。

Argo CD が OCI レジストリから Helm チャートや Kubernetes マニフェストを取得するようになったとしても、最初に設定を書いて管理するのは引き続き Git です。変わるのは Argo CD が設定を読む先だけです。そうなると、Git を使い続けるのに、わざわざレジストリを挟むメリットは何があるのか、運用はどう変わるのかなどが気になるところです。

本記事では、2026年7月28日に開催された ArgoCon Japan 2026 と、7月29日から30日にかけて開催された KubeCon + CloudNativeCon Japan 2026 のセッションを元に、Git と OCI レジストリがそれぞれ何を担保するのか、Argo CD の対応が現在どこまで進んでいて何が課題として残っているのかを整理します。
結論から書くと、レジストリを挟むメリットは イメージのために運用している仕組みに設定も寄せられることと配布のしやすさにあり、代わりに、クラスタに適用された設定からその来歴（元のコミットやレビュー）へ辿るトレーサビリティ（追跡可能性）が保証されなくなる、というのが課題です。エアギャップ環境への配信など、レジストリを挟むメリットがある場面もある一方で、引き続き Git リポジトリを使う方が良い場面も多いと感じました。

扱う構成の全体像は次のとおりです。上段が設定の流れ、下段がコンテナイメージの流れです。

図：Where OCI is Already Winning（Michael Crenshaw、Robin Lieb「OCI is not Git: Rethinking the GitOps Source of Truth for a Kubernetes-Native World」のスライドより）

Good Old の吹き出しが付いているのは、Argo CD が Git から設定（Helm チャートや Kubernetes マニフェスト）を直接読む経路と、コンテナイメージがレジストリ経由でクラスタに届く経路です。右側に New という吹き出しがあるのが、Argo CD がレジストリから設定を読む経路です。

OCI とは

OCI は Open Container Initiative の略で、コンテナイメージとレジストリの仕様を策定している団体です。OCI レジストリは、元々は Docker イメージなどのコンテナイメージを保存・配布するものでしたが、現在はコンテナイメージ以外のファイルも同じ仕組みで格納できるようになっています。
コンテナイメージ以外では、Helm チャート、Kubernetes マニフェスト、SBOM、署名などに対応しており、まとめて OCI アーティファクトと呼ばれます。ダイジェストによって内容が一意に決まり、後から中身が変わらないことが特徴です。

Helm チャートを OCI レジストリに置く構成は、すでに一般的な選択肢です。主要なマネージドレジストリも対応しており、コンテナイメージと同じ場所にチャートを置く構成は珍しいものではなくなりました。この背景には、コンテナイメージのためにレジストリを運用しているのだから、そこに寄せたほうが効率的だという考え方があると思います。Helm 公式ブログ（2022年）では、OCI アーティファクトによってイメージ以外も保存できるようになったため、チャート・イメージ・その他のアーティファクトを単一のレジストリに置けると説明されています。更に、共通の保存形式を共有することで、セキュリティや ID・アクセス管理といった領域で周辺ツールとの相互運用性が高まるとされています。

配布先が社外に公開するユーザーであっても、自社やお客様の環境であっても、この構成のメリットは同じです。チャートリポジトリを別に維持しなくてよくなり、レジストリ側の認証・レプリケーション・脆弱性スキャンをそのまま使えます。本記事で扱う課題は、ここから一歩進んだ話です。

GitOps とは

GitOps は、システムの望ましい状態を宣言的に記述してバージョン管理し、クラスタ側のエージェントがそれを自動で取得して実際の状態を合わせ続ける運用モデルです。人が直接クラスタを操作するのではなく、記述を変更することで反映させます。

この記述の置き場として Git を使い、変更をレビューしてから反映する運用が一般的です。そのため「Git を唯一の信頼できる情報源とする」という説明がよく使われます。ただし後述するとおり、GitOps の原則そのものには、Git を使うことや唯一の情報源とすることは含まれていません。

Argo CD とは

Argo CD は Kubernetes 向けの宣言的な継続的デリバリーツールです。CNCF の Graduated プロジェクトで、公式ドキュメントでは “Argo CD follows the GitOps pattern of using Git repositories as the source of truth for defining the desired application state” と説明されています。この「取得元」を OCI レジストリにするとどうなるか、というのがこの記事で扱う話題です。

本記事で取り上げるセッション

本記事では、ArgoCon Japan 2026 と KubeCon + CloudNativeCon Japan 2026 の中から、Argo CD と OCI に関わる以下セッションを取り上げます。

セッション 登壇者
OCI is not Git: Rethinking the GitOps Source of Truth for a Kubernetes-Native World（KubeCon + CloudNativeCon Japan） Michael Crenshaw（Senior Staff Software Engineer, Intuit／Argo CD lead maintainer）／Robin Lieb（Software Engineer, Independent）
Introducing OCI Webhook Support in Argo CD: From Polling to Real-Time（ArgoCon Japan） Nitish Kumar（Software Engineer, Argo CD Maintainer, Akuity）／Surabhi Mishra（Data Engineer, American Express）
Welcome + Opening Remarks + ArgoCon Project Updates（ArgoCon Japan） Dan Garfield（Argo Maintainer, VP OSS, Octopus Deploy）

以降、それぞれを 「OCI is not Git」セッション、「OCI webhook」セッション、「Opening」 と呼びます。

GitOps の原則

GitOps の原則は OpenGitOps が定めています。CNCF の GitOps Working Group が運営していて、GitOps の標準・ベストプラクティスをまとめることを目的としたプロジェクトです。v1.0.0 で示されている原則は次の4つです。

原則 内容
Declarative 望ましい状態を宣言的に記述する
Versioned and Immutable バージョン管理され、後から変わらない形で保存する
Pulled Automatically エージェントが自動で望ましい状態をソースから取得する
Continuously Reconciled 実際の状態を継続的に望ましい状態へ合わせる

4つの原則の本文は、「機械が同じ状態を再現できること」を中心に書かれています。Git を使うことや、唯一の情報源とすることは要件に入っていません。 原則2の保存先である State Store（望ましい状態の置き場）については、Git は代表例として挙げられているだけで、条件を満たせば他のシステムでもよいとされています。

ただし State Store の定義には、「変更に対するアクセス制御と監査を提供すべき」とも書かれています。Git を使う場合は、コミット履歴とレビュー記録がこれを担っていました。取得元をレジストリに変えるなら、この部分を何が担保するのかが論点になります。

「OCI is not Git」セッションでは、まず Git がこの4つを満たすことを確認したうえで、同じ4つを OCI レジストリに当てはめ、こちらでも満たせると説明されていました。そのうえで、「変更点を差分として確認し、その行を誰がいつ変更したのかを辿る」という性質は OCI にはもともと備わっていない、と付け加えられていました。

GitOps で Git を使っていれば、「プルリクエストでレビューし、後から履歴を追える」という監査の要件も自然に満たせていました。取得元をレジストリに変えると、この担保が自動的には付いてきません。

ここで「履歴」という言葉の意味を分けておきたいところです。原則の2番目は、不変であること・バージョン管理されること・完全なバージョン履歴を保持することを求めています。OCI レジストリでも、ダイジェストで指定すれば内容は固定され、push したアーティファクトはレジストリに残ります。

一方で、OCI Distribution Spec を見ると、タグの一覧を返す API の順序は辞書順と定められていて時系列ではありません。マニフェスト同士に親子関係を持たせる仕組みもなく、タグを上書き・削除できないという保証も仕様上はないため、内容を固定したいならタグではなくダイジェストで指定する必要があります。

つまり 機械が同じ状態を再現するための履歴は満たせるが、git log のように順序や変更者を人が辿れる履歴にはなっていない、ということです。

マニフェストを OCI レジストリから取得する構成

Argo CD の取得元を OCI レジストリにすると、流れは次のようになります。

  1. 人が config を Git に書き、プルリクエストでレビューしてマージする
  2. CI がその内容から OCI アーティファクト（Helm チャートやマニフェスト）を作り、レジストリに push する
  3. Argo CD がレジストリからアーティファクトを取得し、必要ならレンダリングしてクラスタに適用する

「OCI is not Git」セッションで示された構成図（冒頭に挙げた図）でも、設定を書く場所は Git のままでした。図のうち新しいと注記されていたのは 3 の経路、つまりレジストリから Argo CD が設定を読む部分だけで、それ以外は従来どおりと示されていました。

Kubernetes に適用するマニフェストは、Helm のチャートや Kustomize のオーバーレイとして書かれることが多く、そのままの形では適用できません。環境ごとの設定値を反映して最終的なマニフェストを組み立てる処理（レンダリング）が必要になります。

レンダリングが要る場合、取得元が Git であれば Argo CD が同期のたびに行います。取得元をレジストリにするなら、どこまで済ませたものを置くかで構成が分かれます。

  • レンダリング前のものをレジストリに置く場合：Helm チャートをそのまま置く。環境ごとの設定値は Git 側に残り、展開は Argo CD が行う
  • レンダリング済みのものを置く場合：CI が環境ごとの設定値でレンダリングした結果を置く。Argo CD はそれをそのまま適用する

後者では、レジストリ上のアーティファクトと同じものが Git 上に無い状態になります。元になったコミットはありますが、アーティファクトはそこから派生したもので、1対1では対応しません。後述するツールが履歴を独自に持とうとするのは、この形を取っているためです。

設定までレジストリに寄せる理由

「OCI is not Git」セッションの登壇者は、自身がもともと OCI に懐疑的だったと述べたうえで、それでも採用する理由を5つ挙げていました。

理由 内容
Immutability バージョンを固定でき、アーティファクトが後から変わらないため、環境間で設定がずれるのを防げる
Distribution 世界中に、また異なるセキュリティゾーン（エアギャップ環境を含む）へ配布・ミラーできる
SBOM + Sign Cosign と OCI ネイティブの署名レイヤによって、設定の出自を暗号的に検証できる
Standard アプリケーションのイメージ、Helm チャート、素の YAML を単一の標準仕様の下に統一できる
Ecosystem エンタープライズ向けレジストリの機能（リージョン間レプリケーション、ライフサイクルルール、アクセス制御）をそのまま使える

図：Why This Matters（Michael Crenshaw、Robin Lieb「OCI is not Git: Rethinking the GitOps Source of Truth for a Kubernetes-Native World」のスライドより）

図の左側でソースをビルド・バンドルし、そこから Bundle containing Images + Config（イメージと設定をまとめたもの）が作られ、レジストリに格納されます。レジストリから直接 pull する Edge Location、ローカルのレジストリを経由する Edge Location、そしてバンドルを transfer で持ち込む Air-Gapped Location などで利用されます。

適用されたものから、レビューしたコミットへ遡れるか

セッションでは、Git と OCI の性質を6項目で比較した表が示されていました。

図：OCI is Great – But it’s not Git（Michael Crenshaw、Robin Lieb「OCI is not Git: Rethinking the GitOps Source of Truth for a Kubernetes-Native World」のスライドより）

Git 側が優位なのは History & Blame、Reviews & Discussions、Visualization & Diffing の3項目で、いずれも人が変更を確認・追跡するための性質です。OCI 側が優位なのは Airgap & Edge Readiness で、Authn / Authz は両者とも満たしています。

この差が実際に効いてくるのが、クラスタに適用されたものから元をたどる場面です。前述のとおり、適用されるのは Git に置いたファイルそのままではなく、レンダリングした結果です。これは取得元が Git でも同じです。違うのは、その結果がどの Git コミットから来たのかを辿れるかどうかです。

Git を取得元にしていれば、コミットの差分・変更者・レビュー履歴に遡れます。一方、レンダリングして push した OCI アーティファクトには、元の Git ソースを指す情報が付いている保証がありません。Argo CD の OCI レジストリ対応の設計提案では、アーティファクトに元の Git ソースのメタデータを付けることが対象外（Non-Goals）として明記されており、設計として対象になっていません。

運用面で残っている課題

変更検知：レジストリからの通知は仕様に含まれていない

CI が push してから Argo CD が変更を検知するまでには、待ち時間が生じます。「OCI webhook」セッションでは、この時間が課題として示されていました。

図：Problem Statement（Nitish Kumar、Surabhi Mishra「Introducing OCI Webhook Support in Argo CD: From Polling to Real-Time」のスライドより）

CI 自体は数秒で終わり、レジストリに新しいタグが公開された時点でパイプラインは成功します。しかしその後に Argo CD のポーリングのタイマーが発火してはじめて Refresh と Sync が走ります。解消手段として webhook 対応が説明されていました。

ただし OCI の仕様には、レジストリ側から通知を送る仕組みが含まれていません。そのため実装はレジストリごとの個別対応になります。この webhook 対応は Argo CD のリリース版にはまだ反映されておらず、対応済みのレジストリも一部にとどまります。セッションは開発中の機能を紹介するものだったので、使えるようになる時期は公式のリリース情報で確認してください。

認証方式もレジストリによって差があり、Argo CD 側がまだ対応していないレジストリもあります。取得元をレジストリに寄せる構成を検討する場合は、使用中のレジストリのサポート状況の確認が必要です。

ソース検証の対象は Git のみ

ArgoCon Japan 2026 の Opening では、次のバージョン（v3.5）の内容としてソース検証の強化が挙げられていました。これに当たる仕組みは Source Integrity で、実装した Pull Request は v3.5.0-rc1 のリリースノートに含まれています。現時点ではリリース候補の段階です。また、ドキュメントが対応している方式として挙げているのは、Git のコミットの GnuPG 署名検証だけです。

Helm リポジトリおよび Helm の OCI レジストリの provenance ファイルへ対象を広げる Pull Request は出ていますが、まだマージされていません。OCI アーティファクトの署名検証は Issue が起票された状態にとどまっています。

そのため現時点では、Argo CD の外側で検証を担保するのが現実的です。CI で push する前に署名を検証しておく、admission controller で署名のないアーティファクトを参照する Application を拒否する、といった構成が考えられます。上記 Issue の議論でも、Argo CD 本体に実装するのではなく既存のポリシー検査の仕組みに寄せる案が挙がっていました。

Git の性質を保とうとする試み

「OCI is not Git」セッションでは、Kokumi という実験的なツールが紹介されていました。Argo CD を置き換えるのではなく、CI がレジストリに置いたアーティファクトと Argo CD の間に入ります。取得したものを環境ごとにレンダリングし、別のアーティファクトとしてレジストリに push します。

図：How It Works（Michael Crenshaw、Robin Lieb「OCI is not Git: Rethinking the GitOps Source of Truth for a Kubernetes-Native World」のスライドより）

  • Order — レジストリから取得するアーティファクトと、環境ごとの設定値を書く
  • Preparation — Order から作られたレンダリング結果。レジストリに push される不変のアーティファクトで、1つ前のバージョンを親として持つ
  • Serving — どの Preparation をクラスタに適用するかを選ぶ
  • Application — Argo CD 側のリソース。Serving がこれを更新する

Preparation のアーティファクトに親のダイジェストと変更理由をアノテーションとして書くことで、更新の順序と意図を残せるようにしています。「OCI の仕様には親子関係がない」という欠落を、ここで埋めているわけです。

レンダリング結果の確認と Serving の適用実行は、Web UI から行えます。設定値の書き換えも UI 上でできる、というデモもありました。

Kokumi が掲げているのは内容が変わらない取得元であり、Git を含めた唯一の情報源だとは述べていません。Git の性質を捨てずにレジストリの利点を取る、という立場です。

おわりに

冒頭で挙げた「Git と OCI レジストリがそれぞれ何を担うのか」について、次のように整理できました。

  • GitOps の原則に、Git を使うことや唯一の情報源とすることは含まれていない。OCI レジストリでも4つの原則は満たせる。ただし置き場には「変更に対するアクセス制御と監査を提供すべき」という要件があり、そこは自動的には付いてこない
  • Argo CD の取得元を変更しても、人が config を書きレビューする場所としての Git の役割は残る
  • 課題は、適用されたアーティファクトからレビューしたコミットへ辿る経路が保証されないこと
  • Argo CD 側では変更検知・レジストリ対応・ソース検証がまだ揃っておらず、リリース版で使えるかは個別に確認する必要がある

配布先としての OCI レジストリはすでに選択肢に入りますが、Argo CD の取得元をレジストリに寄せるかどうかは、現時点で答えが1つに定まるものではないと感じました。