Qovery、Kubernetes運用をAI agent時代のcontrol planeへ変えた設計

冒頭

Romaric Philogeneは、深夜の障害対応で「Smart engineers spending their best hours on undifferentiated infrastructure work」と問題意識を持った。出典

創業とKubernetes

2020年にRomaric PhilogeneとMorgan PerryがQoveryを創業し、Kubernetesを使うチームの運用負担をcontrol planeへ移した。出典

自社Cloudとpolicyを残す

Qoveryは管理の簡単さだけでなく、顧客のcluster、VPC、apps、databasesを顧客側に置けるBYOKを打ち出した。出典

AI agent時代への拡張

Terraform provider、CLI、MCP server、AI Skillを入口に、agentのintentを再現可能なoperationとしてKubernetesへ届ける方向へ広がった。出典

現在地

Qoveryの勝ち筋はKubernetesを消すことではなく、開発者の判断と組織のpolicyを残しながら、繰り返し作業を減らすことにある。

QoveryのPMFは、Kubernetesを使いたいがplatform engineeringの反復運用に人員を割けない開発チームにある。

自社Cloudとpolicyを保持しつつ、環境構築・preview・deployを抽象化するため、自由度と速度のトレードオフを調整できる。出典

AI agentのintentを同じoperationへ落とす設計は、agentが増える現在の運用課題に接続する。出典

Kubernetes、policy、BYOK、agent実行を一つのcontrol planeへ束ねた運用知識とintegration蓄積がmoatになる。

ネットワーク効果は弱い。

利用者同士の直接効果は小さいが、Terraform module、MCP skill、docsの蓄積が間接的に導入リスクを下げる。

自社CloudでKubernetesを運用するplatform team、複数環境を持つstartup、AI agentの実行基盤を整えたいengineering leader。

単純な静的siteには過剰。

第一にKubernetesを捨てずにcontrol plane化した。

第二にBYOKとpolicy governanceでenterpriseの制御要求を残した。出典

第三にTerraform、CLI、MCP、AI Skillを揃え既存workflowへ入れる。出典

Kubernetesの複雑さを完全には消せず、権限・network・cluster障害の責任分界が残る。出典

有料価格と大規模運用の制約は要確認で、agentの自動実行には承認設計も要る。

Free tierとdocsでdeveloperを獲得し、Ephemeral EnvironmentsとAI integrationsで利用頻度を上げ、enterprise policy・governanceへ拡張する。出典

OSSではなく管理面の信頼が成長の前提になる。

主要チャネル: content, documentation, github, developerCommunity, partners

開発者向け抽象化は、基盤を隠すほど強いのではなく、データ所有・policy・escape hatchを残したまま反復を消すとenterpriseにも届く。

日本では金融・医療・大企業のplatform team向けに、BYOK、国内リージョン、監査ログ、agent操作の承認を前面に出すべきだ。