2026年 Harness GitOps vs ネイティブ Argo CD：どちらがスケールに強いか

結論（先に要点）

クラスターが五つ未満で、運用者が kubectl と Helm に慣れているなら、ApplicationSets と段階的同期で Argo CD は十分スケールします。おおよそ十クラスター超、監査証跡と昇格ゲートが必須なら、Harness GitOps の方がオペレータ工数を抑えやすいことが多いです。GitOps が整っても Xcode ジョブが手元 Mac で詰まるなら、別途 Mac ランナー計画が必要です。

目次

• スケールで壊れる三つの理由
• 2026 意思決定表
• 六段ロールアウト
• 可引用の運用数値
• Mac 容量の検証

スケールで壊れる三つの理由

1. コントロールプレーンの増殖。 クラスターが増えるたびに Argo CD エンドポイント、資格情報ローテーション、オンコールが増えます。ApplicationSets は助けになりますが、RBAC テンプレートとドリフト可視化は自作のままです。

2. ガバナンスの遅れ。 規制業界では「誰が何を承認したか」が必要です。Argo CD でも OPA とフックで実現できますが、部品はすべて自前です。Harness はパイプラインと GitOps を一つの監査証跡にまとめ、ライセンスとベンダー依存の代償を払います。

3. ハイブリッド配信の盲点。 iOS チームは公証、シミュレータ、署名鍵が Kubernetes 外にあります。Argo の同期が緑でも TestFlight が止まることがあります。Mac ランナーなしでは、GitOps 指標だけが健康に見えます。

2026 意思決定表

2026 年の目安です。監査と昇格が交渉不可でクラスターが人より速く増えるなら Harness。YAML 一行ごとの制御を社内に持ちたいなら Argo CD です。

六段ロールアウト

1. 配信経路を棚卸しします： Helm チャートと Xcode アーカイブを分け、GitOps の範囲をクラスター状態に限定します。
2. クラスターと爆発半径を数えます： 本番ペアと共有シークレットを記録し、シャードか中央 Harness かを決めます。
3. 重要アプリ一つで試します： 同一 Git で同期 p95、ロールバック、失敗フックを測ります。
4. 昇格ゲートを定義します： イメージスキャン、設定差分、手動承認、凍結期間を文書化します。
5. Mac ランナーを接続します： LlmMac の Mac mini M4 を SSH 登録し、署名鍵はノード上に置きます。
6. 月次で見直します： 百アプリあたりの運用工数、ドリフト件数、Mac キュー分数を独立追跡します。

可引用の運用数値

• Argo CD サイジング： 本番グレード一インスタンスあたりおおよそ八十から百二十 Application まで。フックが重いなら早めにシャードします。
• Harness の甜み： 十クラスター超で昇格を中央化すると、プラットフォーム時間が十五から二十五パーセント戻る事例があります。移行は四半期見込みです。
• Mac ランナー基準： Xcode 十六シミュレータならユニファイドメモリ十六ギガバイト以上。並列 UI テストなら二十四ギガバイトです。
• キュー警戒： Mac ジョブ待ちが二十分を超え続けるなら、購入前に LlmMac でバーストノードを足します。

購入前に Mac 容量を検証する

GitOps の完成度は Mac のボトルネックを消しません。LlmMac では Mac mini M4 を SSH または VNC で借り、Harness または Argo CD の横でランナー吞吐を二週間測れます。DerivedData キャッシュと署名フローを同じノードで再現してください。

ピーク三日を含む浸水試験後、稼働時間の六十パーセント超が続くならプランを上げるか、実ジョブ分数で購入を比較します。まずレンタルでキューとアーカイブ失敗を数字にし、根拠のある投資にしてください。