# クラウド管理モダリティ ## 定義 クラウド管理モダリティとは、DevOps エンジニア(あるいは AI エージェント)がクラウドインフラを操作する際の高レベルインターフェースの種別を指す。[[@2025__OSR__Cloud Infrastructure Management in the Age of AI Agents]] は 4 つを挙げる——(i) **SDK**(命令型プログラミング。Azure Python SDK 等)、(ii) **CLI**(端末組み込みのコマンド。Azure cloud shell 等)、(iii) **IaC**(宣言的・state-centric な設定プログラム。[[Terraform]] 等)、(iv) **ClickOps**(Web ポータルのクリック操作、no-code/low-code)。いずれも低レベルの RESTful クラウド API(get/post/put/delete でリソースをデータオブジェクトとして操作)の上に立つ抽象化で、API がクラウド/ユーザ相互作用の「システムコール層」をなす——任意のタスクは最終的に何らかの API 呼び出しに帰着する。([[@2025__OSR__Cloud Infrastructure Management in the Age of AI Agents]]) モダリティはインフラライフサイクルの 3 段階——**provisioning**(リソース生成と相互接続)・**updates**(live 更新と再作成を伴う更新)・**monitoring**(実時間の状態/テレメトリ取得)——を横断して使われ、AI エージェントにとっての向き不向きは段階ごとに大きく変わる。本論文の予備実験(Azure VM 管理)は、この「段階 × モダリティ」のトレードオフを実証的に切り分けた最初期の体系化である。 各モダリティの観測された得手不得手(本論文の予備実験、レーダー軸: success rate / observability / interoperability / level of abstraction / efficiency): - **CLI**: provisioning で最効率(成功率 1.0・平均 1.6 step)。多くは 1 step で正しいコマンドを生成。interactive な one-off タスクに好適。 - **SDK**: 汎用的でバランス型(provisioning 0.67/4.5)。命令型でプログラム的制御が効く。 - **IaC**: 再作成を伴う更新に強い(standard→spot 変更で属性 1 つの変更だけで teardown/recreate を [[Terraform]] が自動処理)。一方 monitoring に弱い(0.40)——state-centric 設計は構成を捉えるが runtime telemetry を取り出せず、context window 制約で全状態をモデルに渡せない。 - **ClickOps**(Web): monitoring に強い(1.0)——クリック列が単純でポータルが可視化に最適化、Azure Service Health のように Web でしか得られない情報もある。一方リソース作成に遅く脆い(CLI の約 30×・46 step、複雑タスクで max step 到達)。 ## 横断的知見 - **「IaC」は単一研究対象でなく 4 モダリティの 1 つ**: 本 wiki の IaC クラスタ([[Zodiac]]/[[NSync]]/[[Lilac]]、[[Infrastructure as Code]] 参照)は IaC のライフサイクル(検証・逆生成・drift 修復)を深掘りするが、同じ [[Ang Chen]] グループのビジョン論文は IaC を「SDK・CLI・IaC・ClickOps」の 1 モダリティとして相対化する。IaC は宣言的・state-centric ゆえ大規模/再作成更新に強い反面、monitoring や context window で不利——モダリティ横断で見ると IaC の強みと弱みが構造的に位置づく。深掘り(IaC 内部)と俯瞰(4 モダリティ)は補完関係にある。(Source: [[@2025__OSR__Cloud Infrastructure Management in the Age of AI Agents]], [[@2024__SOSP__Unearthing Semantic Checks for Cloud Infrastructure-as-Code Programs]]) - **「agent-cloud interface」という層が独立に立ち上がる**: 本論文は提案アーキテクチャの中核に **agent-cloud interface**(モダリティ併用時の resource drift・race condition を統一クラウド状態 + 同期プリミティブで調停)を据える。[[AIOpsLab]] も同名の **Agent-Cloud Interface (ACI)**(固定アクション集合と観測の露出)を中核に持つ。評価基盤(AIOpsLab)と運用アーキテクチャ(OSR ビジョン)で同じ抽象層が独立に命名・設計され、エージェントとクラウドの境界面の標準化が課題として浮上している。(Source: [[@2025__OSR__Cloud Infrastructure Management in the Age of AI Agents]], [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]]) - **monitoring 段階は agentic SRE のオブザーバビリティ問題と地続き**: 本論文の monitoring 段階(実時間の状態/テレメトリ取得)で IaC が苦戦するのは「構成は持つがテレメトリを取れない」ためで、[[agentic SRE]] が積み上げる「テレメトリ選別が性能の鍵」「state-centric では runtime が見えない」という観察と同根。クラウド管理(provisioning/update 中心)と SRE(障害診断/緩和中心)は別ドメインだが、monitoring 段階で同じ「どのデータをどう取得・選別するか」の問題に収束する。(Source: [[@2025__OSR__Cloud Infrastructure Management in the Age of AI Agents]], [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]]) - **guardrail + human fallback + rollback という自律化の前提が産業・学術で収束**: 本論文の §3.3(自律度を co-pilot / semi-autonomous / fully-autonomous で段階化、formal spec によるポリシー検査・access control・audit trail、rollback・self-healing、human-in-the-loop fallback)は、[[SRE AI Autonomy Levels]](Google の L0–L4 + 安全制御)と同じ結論——「自律性は安全に巻き戻せる実行と人間の fallback とセットでのみ上げられる」——に独立に到達している。本論文が引く「fully autonomous AI agents should not be developed」([22])も同方向。(Source: [[@2025__OSR__Cloud Infrastructure Management in the Age of AI Agents]], [[@2026__GoogleSRE__AI in SRE - Engineering the Future of Reliable Operations]]) - **neural + symbolic + 蓄積知識という設計骨格が IaC からクラウド管理一般へ拡張**: 本論文は「単なる LLM プロンプティングを超えた guardrail と neural+symbolic の組み合わせ」を掲げ、探索を symbolic な metaprogram に articulate して型検査・検証する設計と、workflow learning(検証済みワークフローを memory にキャッシュして再利用)を提案する。これは [[Infrastructure as Code]] で観察された「LLM + symbolic guardrail + 動的に育つ知識ベース」([[NSync]]/[[Lilac]] の収束骨格)を、IaC 単体からクラウド管理全体へ一般化したものと読める。(Source: [[@2025__OSR__Cloud Infrastructure Management in the Age of AI Agents]], [[@2025__arXiv__Automated Cloud Infrastructure-as-Code Reconciliation with AI Agents]]) ## 未解決の問い - agent-cloud interface はモダリティ併用時の resource drift(ClickOps が IaC 管理リソースを変えても IaC のローカル状態を更新しない)と race condition(CLI と ClickOps が同一リソースを同時更新)をどう防ぐか。統一クラウド状態と同期プリミティブ(locking/transaction)の具体設計と、複数モダリティの行動を可換に調停する方法は未実装・未評価。 - multi-agent orchestration の **complexity measure**(リソース数・相互接続・single/multi-cloud・既存データ規模)はどう定義・較正すべきか。タスク難度に応じてどの専門 expert/モデルへルーティングするかの判断基準は。 - exploration を symbolic な metaprogram に articulate して検証する構想は、実クラウドのどの操作クラスで成立するか。型検査・プログラム検証で押さえられる安全性の範囲と、検証しきれない動的要素(課金・実時間状態)の切り分けは。 - **cloud gym**(リソース・機能・課金モデルの複雑さを再現するサンドボックス)を現実忠実に構築できるか。既存 gym(ゲームプレイ/合成タスク)との差を埋める忠実度の指標は何か。[[AIOpsLab]]/[[SREGym]] のような SRE 系 gym と、provisioning/update を含むクラウド管理 gym はどこまで共通化できるか。 - 予備実験は Azure・VM・少数タスク・8 試行・固定モデル([[Azure Copilot]]/GPT-4o)に限定。段階 × モダリティのトレードオフは他クラウド(AWS/GCP)・他資源・他モデル世代でも保たれるか。 - IaC の monitoring 不利は「context window が短い/runtime telemetry を取れない」に起因するとされる。長文脈モデルや IaC への telemetry 取得 API の追加で、この不利はどこまで解消するか。 ## 関連 - ソース: [[@2025__OSR__Cloud Infrastructure Management in the Age of AI Agents]] - 概念: [[Infrastructure as Code]] / [[agentic SRE]] / [[SRE AI Autonomy Levels]] / [[AIOps]] - エンティティ: [[Terraform]] / [[Microsoft Azure]] / [[Azure Copilot]] / [[WorkArena]] / [[Ang Chen]] / [[AIOpsLab]] - 関連 MOC: [[Software Engineering - MOC]] / [[SRE - MOC]] / [[Network - MOC]] / [[LLM4SRE - MOC]] ## 出典 - [[@2025__OSR__Cloud Infrastructure Management in the Age of AI Agents]](§2.1 management modalities, §2.2 management tasks, §2.3 case study と Table 1, Figure 2 レーダーチャート, §3 solution sketch)