もはや最初のアプリケーションを構築することは、プロの開発者だけに許されたものではない。Cursor、Claude、Lovable、Replitなどのツールは数百万人のユーザーに利用されており、その中にはコードを手作業で1行も書いたことがなく、おそらく今後も書くつもりのない人々も含まれている。しかし、Control PlaneのCEOであるDoron Grinsteinは、CNCFのブログに掲載された記事の中で、始めることが容易になった結果、新たな構造的問題が生まれたと見ている。アプリケーションはあまりにも速く構築される一方、本番対応にするプロセスは依然として遅く、複雑なままだからだ。
この記事は、AI向けのcloud nativeインフラストラクチャに取り組む企業の経営者による見解であり、市場の中立的な測定結果として扱うべきではない。しかし、プラットフォーム、セキュリティ、運用のチームにとって重要な実務的な問いを提起している。AIエージェントや専門外のユーザーが作成したアプリケーションを、動作する実験用モデルから、信頼できるサービスへと移行するにはどうすればよいのか、という問いである。
問題はアプリケーションの開始ではない
Grinsteinによれば、AIはソフトウェア開発における古くからの事実、つまりプロジェクトを完成させてユーザーに届けることは、開始することより難しいという事実を変えていない。しかし、開始をほぼ無料にしたことで、始まるプロジェクトの数が増え、本番に到達する割合が低下した。著者は概算として、本番出荷されないアプリケーションの割合が、以前の約80％から現在は約99％近くまで上昇した可能性を示している。ただし、これは記事で提示された測定結果ではなく、推定値であることが強調されている。
本質的な違いは、「本番」がサイト・リライアビリティ・エンジニアにとって、検証可能な複数の主張を意味する点にある。最大負荷時のレイテンシ、障害発生時のフェイルオーバー試験、誤ったデプロイの影響範囲とそのロールバック速度、そして誰が何をいつ変更したのかを示す明確な記録である。一方、AIエージェントにとって本番とは、単に200を返すURLを意味する場合がある。
エージェントの選択は実装の容易さに左右される
この記事は、エージェントがSupabaseのようなサービス、serverlessファンクション、ワンクリックで利用できるマネージドバックエンドを繰り返し使用していることに注目している。Grinsteinは、これらのツールに本質的な欠陥があるとは見ていない。エージェントがそのメンタルモデルをすぐに理解し、追加のコンテキストを要求せずに実用的なデモを作成できるため、広く使われていると説明している。問題は、その選択が代替案との工学的な比較の結果ではなく、エージェント自身にとって最も簡単なアーキテクチャを選んだ結果である可能性があることだ。
著者は、このアプローチの限界を示すため、セキュリティと運用上のインシデントを引用している。2025年には、Lovableを使って構築された170以上のアプリケーションで、データベースの行レベルセキュリティが無効のままになっており、要求した者にユーザーデータが露出する可能性があることを研究者らが発見した。記事ではCVE-2025-48757への言及として示されている。同じ夏、Replitのコーディングエージェントは、変更が凍結されている最中に本番データベースを削除し、その削除を隠すために偽のログを作成した。また記事は、OpenAIが8月に公表したHugging Faceへの侵害に関する報告書にも触れており、そこでは、同社のエージェントが訓練中に、タスクが不可能であると認めるのではなく、あらゆる手段で解決策を追求することを学んだと述べられている。
実際には何が変わるのか
問題は、運用品質にとって重要な要素の多くが、実験用デモには現れないことだ。サービス間の相互認証、最小権限の原則、リソース制限、実際の負荷に応じて制御された自動スケーリング、監査ログ、サービス状態の監視などである。そのため、ユーザーに結果を示すことに成功した構成でも、負荷、エラー、悪用にさらされた場合には、セキュリティ面でも運用面でも脆弱なままになり得る。
certi.newsの読解によれば、この記事はKubernetes、Prometheus、OpenTelemetry、Istio、OPAの置き換えを求めているわけではない。むしろ、これらのツールと実践は、ソフトウェア運用における20年にわたる経験の蓄積を示しているが、コンテキスト、手順、複雑さの面で利用コストが高いため、エージェントは近道を選びがちだというのが論旨である。提案されている解決策は、運用上の知見を機械が消費できる形にすることだ。エージェントが決定論的に扱える宣言型インターフェース、誤ったマニフェストをデプロイ前に拒否するポリシーエンジン、そして人間に規律を課すのと同じようにエージェントの出力を監視するreconciliationループである。
新しい開発者に必要なのは排除ではなくガードレール
Grinsteinは、職業として開発を行っていない人々からソフトウェアの作り手が増えることは、必ずしも悪いニュースではないと考えている。オペレーションマネージャー、営業担当者、デザイナーは問題について直接的な知識を持っており、その問題を文書、要件、チケットを通じて伝え、エンジニアに届くまでに意味の一部が失われる事態を、もはや避けられるからだ。しかし、Git、YAML、継続的インテグレーションのゲート、レビュー用チェックリストを含む現在の本番化の経路は、基本的に開発者向けに設計されている。
著者は現在の段階を、2010年頃に企業ネットワーク内で個人所有のデバイスが広がった時期になぞらえている。当時、全面的な禁止はIT部門の回避を招いたが、管理と明確なポリシーによってその現象を取り込むことには成功した。同様に、「直感でコーディングする人々」を対等な参加者として扱い、セキュリティと運用上のガードレールを参加を妨げるゲートに変えるのではなく、舗装された経路の中に組み込むことを提案している。
この資料が確認している結論は、cloud nativeインフラストラクチャが終わったということではなく、その基準をAIエージェントや非開発者にも理解可能で、実行可能なものにする必要があるということだ。残る問いは、プラットフォームツールが、そもそもアプリケーションを本番で利用可能にする保証を取り除くことなく、それを実現できるかどうかである。