クラウド基盤のコンテキストなしではAIエージェントが行き詰まる理由

AIエージェントにより強力なモデルを与えるだけでは、クラウド基盤を自律的に管理できるようにはならない。env zeroが後援する記事が指摘する問題は、Infrastructure as Code（IaC）ツールが記述する「存在すべき状態」と、クラウド内で実際に稼働しているものを結び付ける運用コンテキストが欠如していることだ。

エージェントがIaCファイルや単一の情報源だけを基に動作すると、アプリケーション、ガバナンスポリシー、セキュリティ要件、コスト要件との関係を知らないまま、単一のリソースを確認する可能性がある。その結果、エージェントは局所的には正しく見える変更を提案しても、違反を引き起こしたり、利用可能なコンテキストには現れない他のコンポーネントに影響を及ぼしたりする可能性がある。

APIのコスト

エージェントは現在の状態を検出するため、クラウドAPIに継続的に問い合わせる必要がある。しかし、この方式は記事が「APIのコスト」と呼ぶ問題をもたらす。レート制限、問い合わせチェーンの失敗、レイテンシーとコストの増加に加え、ツール同士が同じ容量を奪い合うことで、CI/CDパイプラインや自動スケーリングなどの重要な処理に影響を与える可能性がある。

エージェントの動作方法は人間のユーザーとは異なる。人間は具体的な質問をする傾向がある一方、エージェントは長い問い合わせの連鎖を調査することがある。記事は、同社CEOのSteve Corndellの話として、あるエージェントが90件の問い合わせを完了した後、91件目で失敗し、チェーン全体を最初からやり直さざるを得なくなった例を紹介している。この場合、損失は失敗した問い合わせだけにとどまらず、完了済みの作業をやり直すことでさらに拡大する。

この考え方は、ライブ問い合わせをなくすことを提案しているのではなく、インテリジェントに配分することを提案している。所有者情報のように比較的安定した情報は、適切な頻度で更新される同期コンテキストに保持し、現在の状態を知る必要がある質問にのみ直接問い合わせを限定できる。目的は、運用情報の正確性を維持しながら、重複したリクエストを減らすことだ。

表明された意図から運用上の現実へ

記事は、宣言されたインフラストラクチャーのデータと実際のリソースの検出結果を集約し、それらをアプリケーション、ポリシー、所有権、環境間の境界に結び付けるコンテキスト層について説明している。オントロジー層またはナレッジグラフは、通常、状態ファイル、タグ、スプレッドシート、管理画面から直接実施された変更、文書化されていない知識に分散している情報を統合するのに役立つと想定されている。

仮想的な事例では、Wizのようなツールが複数のインスタンスを必要とする高可用性ポリシーを適用する一方、IaCだけに依存するエージェントは単一のインスタンスしか確認できず、違反を認識できない可能性が示されている。これらのデータをアプリケーションとポリシーのコンテキストに結び付ければ、エージェントは修正を提案する前に影響を評価できる。

完全な制御ループ

env zeroは、宣言された意図の取得、実際の状態の検出、両者の照合、ポリシーの検査、レビューと実行のためのマージリクエスト形式での変更提案、そして最後に再検査を行い、ドリフトや問題が解消されたことを検証するモデルを提案している。データ層は、Terraform、OpenTofu、Pulumiなどの実行ツールに接続できる。

同社はEZ Controlを、宣言された状態と検出された状態を結び付け、ポリシーの管理下で修正を提案または実行し、その変更が成功したことを検証する自律制御ループとして説明している。製品は早期アクセス段階にあり、同社は2026年12月末までの一般提供を目標としている。そのため、説明されたループの一部は、env zeroが現在も構築中の機能である。

このモデルが重要な理由

この提案の実務的な価値は、問題を検出することだけではなく、解決を検証するところまでの経路を完了する点にある。アラートを出すだけで停止するツールは、最も難しい手順をエンジニアに残す。一方、記事は、対応を要する問題を特定してから、その変更によって問題が修正されたことを確認するまでの期間である修復時間によって成功を測定している。

ただし、この見解は後援企業の主張と製品の初期段階に結び付いており、顧客のパフォーマンスやコストおよびレイテンシーの削減量に関する独立した数値を情報源は示していない。また、コンテキスト層がレビューやポリシーの管理を不要にするわけではない。むしろ、実際のクラウド環境で変更を実行できる自動化において、それらを中心的な要素にするものである。