自社のAI製品を企業顧客のVPC（仮想プライベートクラウド。顧客が専有する仮想ネットワーク環境）やエアギャップ環境（外部ネットワークから物理的・論理的に遮断された環境）に導入する案件を抱えているアーキテクトやSREの方に向けた内容です。SaaSとして自社クラウドで動かすだけなら問題にならない課題が、顧客環境に持ち込んだ瞬間に表面化します。
Kubernetesクラスタへのデプロイ手段として、多くのチームはHelm（Kubernetesアプリケーションのパッケージマネージャ）を使っています。Helmチャートを配布すれば導入は済む、と考えがちですが、顧客先への配布が本格化すると、ライセンス管理・リリースチャネル・イメージの安全な配送・導入前検証・稼働状況の可視化といった要件がHelm単体ではカバーできないことが分かってきます。これはパッケージングの問題ではなく、ソフトウェア配布（software distribution）という別のレイヤーの問題です。
なぜ顧客環境への配布が特別な課題になるのか
IDCが2025年に実施した「デジタル主権（Digital Sovereignty）」調査では、900以上のIT・ビジネスリーダーを対象に、55%の組織がハイブリッドまたはマルチクラウド戦略の一部としてソブリンクラウド（自国・自社管理下にとどまるクラウド）を見込んでいると回答しています。37%は主な導入環境としてオンプレミスを挙げており、特に規制対象ワークロードで顕著です。
この背景には技術的な好みではなく、データ主権・セキュリティ・プライバシー・規制対応という制約があります。金融・医療・政府機関向けのAI製品では、顧客データを自社SaaS基盤に置かせてもらえないケースが珍しくありません。結果として、ベンダー側は「自社のVPC内で完結するSaaS」ではなく「顧客のVPCやデータセンター、エアギャップクラスタの中で動くソフトウェア」を届ける必要に迫られます。
Helmチャート配布だけで運用していた場合に起きること
HelmチャートをGitHubで公開し、導入ドキュメントを渡すだけの配布モデルを想定してみます。顧客はHelmリポジトリを追加し、values（設定値）を書いてhelm installを実行する、という流れです。コンテナイメージはベンダーのプライベートレジストリから取得するか、顧客が自分のレジストリにミラーリングします。
初期の数社であればこれで十分機能します。しかし顧客数が増えるにつれ、次のような限界が顕在化します。
- プライベートイメージを顧客ごとに配布するための認証情報管理が煩雑になる
- 完全なエアギャップ環境へのインストールが手作業のワークフローに依存する
- どの顧客がどのバージョンを稼働させているか、ベンダー側に可視性がない
- ライセンス制御・リリースチャネル分け（ベータ/安定版など）・アップグレード手順の統制・導入前のプリフライトチェック（preflight check。前提条件を事前検証する仕組み）・デプロイ後のヘルスチェックが存在しない
これらは個別には小さな問題に見えますが、積み重なると「パッケージは正しく作れているのに、企業顧客に安心して届けられない」という状態を生みます。技術的負債という言葉は機能追加の後回しで語られがちですが、配布基盤の不在もまた非機能要件側の負債として蓄積していきます。
配布基盤として何を評価すべきか
この種の課題に対しては、Kubernetesネイティブな配布プラットフォームの採用が選択肢になります。代表的なものとしてReplicated（KOTSというKubernetes Off-The-Shelfの仕組みをベースにした配布基盤）と、Distrというツールが比較検討の対象になりました。
Replicatedが選ばれた理由は、既存のHelmベースのワークフローを変えずに、その上にエンタープライズ配布に必要な機能を重ねられる点です。具体的には次の機能が加わります。
- 顧客ごとのライセンス発行とアクセス制御
- 安定版・ベータ版などのリリースチャネル分離
- インストール前のプリフライトバリデーション（クラスタのリソースやバージョン要件を事前確認）
- コンテナイメージの安全な配送（顧客に直接レジストリ認証情報を渡さずに済む仕組み）
- 完全なエアギャップ環境へのサポート
導入後の流れは、顧客がライセンス付きリリースをプリフライトチェック済みで取得し、イメージも安全な経路で配送される形に変わります。ベンダー側は、どの顧客がどのバージョンをどこまで導入しているかを一元的に把握できるようになり、サポート対応やアップグレード計画に活用できます。
既存のCI/CDやレジストリ運用との比較で考える
ここで整理しておきたいのは、配布基盤の導入がCI/CDパイプラインやコンテナレジストリ運用を置き換えるものではない、という点です。GitHub ActionsやArgoCDなどで行っているビルド・テスト・デプロイの自動化はそのまま維持されます。配布基盤が担うのは「ビルド済みの成果物を、自社の管理が及ばない顧客環境にどう安全に届け、どう把握するか」という配布専用のレイヤーです。
たとえば社内向けマイクロサービスであれば、プライベートレジストリからPull可能な権限を持つCI/CDパイプラインが完結していれば十分です。しかしエアギャップクラスタでは外部レジストリへの疎通自体が存在しないため、イメージをバンドルして物理的・オフライン的に持ち込む仕組みが別途必要になります。この違いを認識せずにSaaS前提の運用をそのまま顧客環境に当てはめようとすると、導入フェーズで想定外の工数が発生しがちです。
今日確認できること
自社の製品がすでに顧客VPCやオンプレミス、エアギャップ環境への導入を想定している、あるいは今後想定される可能性があるなら、次の点を確認しておくと判断材料になります。
- 現在のHelmチャート配布で、顧客ごとのバージョン・稼働状況を把握できているか（サポートチケット発生時に「どのバージョンか」を即答できるか）
- コンテナイメージの配送方法が、顧客へのクラウド認証情報の直接共有に依存していないか（セキュリティ監査で指摘されやすいポイント）
- エアギャップ環境向けのインストール手順が、手作業のドキュメントだけに頼っていないか
- ライセンス制御やリリースチャネル分離が必要な契約形態（トライアル版・エンタープライズ版など）がすでに存在するか
該当する項目が複数あるなら、ReplicatedやDistrのような配布特化プラットフォームの評価を検討する価値があります。両者とも公式ドキュメントで無料枠やデモ環境を提供しているため、既存のHelmチャートをそのまま取り込めるか、プリフライトチェックの定義方法がどの程度柔軟かを実際に試してから判断するのが安全です。
まとめ
企業顧客向けAI製品の配布は、SaaS運用の延長では設計しきれません。Helmはパッケージングには優れていますが、ライセンス・可視性・エアギャップ対応といった配布ライフサイクル全体はカバーしないためです。
判断の起点として、自社の顧客導入でバージョン可視性・イメージ配送のセキュリティ・エアギャップ対応のいずれかに不安がないかを棚卸しすることをおすすめします。既存のHelmワークフローを捨てずに拡張できるかどうかも、移行コストを左右する重要な基準です。