はじめに

2026年7月28日、パシフィコ横浜で ArgoCon Japan 2026 が開催されました。KubeCon + CloudNativeCon Japan 2026 の併設イベント（Co-located Event）で、日本での ArgoCon 開催は今回が初めてです。

メンテナー側とユーザー側の双方から、課題やその対応方法、設計意図などが語られ、OSS が積極的に改善されていくのがリアルに見えた会でした。

シングルトラックの半日開催で、当日のセッションは次の8つでした。

セッション 登壇者
Welcome + Opening Remarks + ArgoCon Project Updates Dan Garfield（Argo メンテナー／Octopus Deploy）
Configuring Argo CD is Messy: Here’s How We Can Fix It Michael Crenshaw（Argo CD lead メンテナー／Intuit）
Introducing OCI Webhook Support in Argo CD: From Polling to Real-Time Nitish Kumar（Akuity）、Surabhi Mishra（American Express）
Octopus Deploy: CI/CD is now AI/CD（Sponsored Keynote） Mike Nguyen（Octopus Deploy）
Argo メンテナーパネル（現地で追加された枠） Argo メンテナー3名
When GitOps Becomes the Bottleneck: Scaling Argo CD for High-Churn Platforms Sandeep Kanabar（Gen）、Vanshika Jain（Brudite Private Limited）
Migrating 1,300 Jenkins Jobs to Argo Workflows（LT） Kenichi Takano（リクルート）
10 Ways to Get Involved in Argo Project（LT） Joanna Wyganowska（Octopus Deploy）

会場の空気と当日の進行

Opening で登壇者から会場に挙手アンケートがありました。Argo CD を使っている人は多くいましたが、Argo Workflows と Rollouts はその半数以下、Argo Events はさらに少数という結果で、登壇者も「予想通り」とコメントしていました。Argo CD しか使っていない自分は場違いかもと思っていましたが、Argo CD から入って他はまだ、という参加者が多数派のようでした。

当日の進行は公式スケジュールから多少変更され、一部セッションの順番変更やスキップがあった代わりに、メンテナーパネルが追加されていました。

ユーザーサーベイと Argo CD 3.5

Opening で紹介されたユーザーサーベイの結果では、ApplicationSet の利用が App-of-Apps に次ぐ2番目のパターンまで伸びていること、AI/ML ワークロードを扱う組織の 80% が Argo CD でデプロイしていることが挙げられていました。課題の最大のものはスケールと性能で、Application が2000個を超える規模では半数がこれを上位3つに挙げたとあります。

あわせて Argo CD 3.5 の話もありました。CNCF の事前告知記事では “the biggest release since Argo CD 3.0” と表現され、特に ApplicationSet を第一級の機能として扱う方向と書かれています。その他に Opening で挙げられていたのは、mTLS 対応、Source Integrity、Helm 4 サポートといった機能です。なお 3.5 は本記事執筆時点でまだリリース候補（rc）段階で、rc3 が公開されたのは ArgoCon Japan の当日でした。

検証段階の設計をメンテナー本人が話す

「Configuring Argo CD is Messy」は、Argo CD の lead メンテナーによる設定 CRD のセッションでした。

Argo CD の設定は Application などの CRD と ConfigMap に分かれていて、ConfigMap 側のパラメータは260ほどあるとのことでした。そこから来る問題は次のようなものです。

  • 変更したときに再起動が必要なパラメータと不要なパラメータの区別がメンテナーでも難しい
  • パラメータの値に YAML が文字列として埋め込まれている場合があり、syntax error の原因になる
  • 一部のパラメータは環境変数から読まれ、ドキュメント化されていないものもある

解決策として提案されていたのが ArgoCDConfiguration という新しい CRD です。ConfigMap 方式に対する利点が4つの軸で示されていました。

図：The Solution: ArgoCDConfiguration CRD（「Configuring Argo CD is Messy: Here’s How We Can Fix It」のスライドより）

  1. Native Data Types — 文字列に詰め込むのではなく型で持つ
  2. Declarative Validation — CRD のスキーマで値を検証する
  3. Automated Docs — kubectl explain でドキュメントを引ける
  4. Hot-Reloading — 再起動なしで反映する

移行についても、フィールドをすべて nullable にして移行しなくても動くようにする、といった考慮が説明され、最後に ConfigMap から CRD に切り替えて Pod を起動するデモがありました。

この設計はまだ提案・検証の段階です。入るとしても Argo CD 3.6 か 3.7 になるかもしれない、という温度感でした。現時点では PR #28841 は Draft で、まだ検証中のようでした。

OCI レジストリを GitOps の取得元にする

Argo CD が OCI レジストリの更新を webhook で受け取れるようにする話です。このセッションについては、翌日以降の KubeCon 本編のセッションと合わせて別記事にまとめました。

【KubeCon + CloudNativeCon Japan 2026】GitOps における Git とコンテナレジストリ（OCI）の役割 — Argo CD の現状と課題
はじめにKubernetes 上で動かすコンテナのイメージだけではなく、設定も OCI レジストリに置いて配る構成が広がりつつあります。Helm は 3.8 以降でチャートをレジストリに保存できるようになり、公式ドキュメントでもチャートの保存・共有には OCI 対応のレジストリを使うことが推奨されています。さらに Argo CD は、Helm チャートに限らず Kubernetes マニフェスト全般をレジストリから取得できるようになりました（公式ドキュメント）。Argo CD が OCI レジストリから Helm チャートや Kubernetes マニフェストを取得するようにな...
iret.media

AI でコードが速くなった分、CD が律速になる

Octopus Deploy の「CI/CD is now AI/CD」セッションの問題提起は、AI が大量にコードを作るようになったのに、CD が追いついていないというものでした。コードをパッケージに入れるところまでは AI に任せていても、本番へのデプロイはまだ任せていない、という話です。

そして、AI に対する制約には soft（やるなと言っておく）と solid（そもそも権限を与えない）の2種類があり、どちらにするかは変更の影響範囲（blast radius）で決める、という整理がされていました。影響範囲が小さければ自動テストで担保して soft、大きければ人間の承認を挟んで solid、という線引きでした。

現地で追加されたメンテナーパネル

参加者からの質問にメンテナーが答える形式でした。複数のリソースを含む既存 Application をグループごとに分けるにはどうするか、マージする前に変更内容を確認するにはどうするか（diff にも複数のレイヤがある）といった、実運用の質問が出ていました。

セッションごとに Application を作ると破綻する

「When GitOps Becomes the Bottleneck」は、学生向け AI ラボ基盤の事例です。AI ラボ環境の利用セッションごとに Argo CD の Application を1つ作る構成が破綻した経験から、何を Git に置いて何を置かないかを整理し直した話でした。

この構成だと、学生が1回ラボを使うたびに Git の commit と Application が1つずつ増え、Argo CD はそれを全部同期し続けることになります。利用者が増えるほど Argo CD の仕事が際限なく増えていく、というのが破綻の理由でした。

「Git は intent（意図）を置く場所であって instance（実体）を置く場所ではない」という整理と、それによって監査証跡の置き場が commit 履歴からルール＋ラベル付きリソース＋イベントログへ移るという話もありました。

図：Git owns intent. Platform owns execution.（「When GitOps Becomes the Bottleneck: Scaling Argo CD for High-Churn Platforms」のスライドより）

国内ユーザー事例と実運用からのフィードバックによる改善

リクルートによる Jenkins から Argo Workflows への移行事例の紹介がありました。

規模は 1,306 ジョブ、期間は約1年、5つのフェーズに分けて進め、90% 以上をスクリプトで自動変換したとのことです。元の構成は Jenkins が別の Kubernetes ジョブを呼び出して動かすもので、デバッグとアップグレードがつらい状態だったと説明されていました。

移行の中で発生した問題は、2本の Pull Request として Argo Workflows にフィードバックしたとのことでした。

Argo Project への入口は10通りある

最後のセッションは、「10 Ways to Get Involved in Argo Project」でした。挙げられていた10個はこうです。

  1. 使い始める
  2. ドキュメントに貢献する
  3. バグを報告する
  4. 機能要望を出す
  5. Pull Request をレビューする
  6. コミュニティの質問に答える（Slack、GitHub Issues など）
  7. 本を書く（既刊として Argo CD Up & Running などが紹介されていました）
  8. 経験を共有する（イベントに登壇提案を出す）
  9. 職場で Lunch & Learn を開く（録画されたセッションをチームで見る）
  10. メンテナーになる

1〜3 のように、使い始めた段階でも出せるものが並んでいます。翌日以降の KubeCon 本編でも、contribution を歓迎する呼びかけが繰り返し出てきました。

おわりに

初開催の ArgoCon Japan では、検証段階の設計をメンテナー本人から聞けたり、国内や海外の Argo 利用事例や改善事例を聞くことができました。ドキュメントやリリースノートを読むだけでは分からない設計の経緯や判断の理由まで聞けて、温度感も垣間見えるのは、リアルイベントならではだと思います。使う側として何ができるかを考えるきっかけにもなりました。

Argo CD や Argo Project の他の機能も活用し、アップデートを追いかけるとともに、フィードバックできる機会があればぜひフィードバックしていきたいと思います。