> [!abstract] 概要(abstract の日本語訳) > Infrastructure-as-code(IaC)はクラウドリソースの管理方法を作り変えつつある。IaC のユーザーは望むインフラを定義する高レベルプログラムを書き、基盤の IaC プラットフォームが構成要素のリソースをクラウドへ自動的にデプロイする。グリーンフィールドのデプロイ(ゼロからの新規クラウドデプロイ)の作成では強力さが証明されている一方、既存の IaC プラットフォームはブラウンフィールドのインフラ(既存の非 IaC デプロイを IaC プラットフォームへ移し替えること)の管理への支援が限られる。これはレガシーなクラウド管理手法から IaC ワークフローへの移行を妨げ、より広範な IaC 採用を阻む。ブラウンフィールドのデプロイを管理するには、低レベルのクラウドリソース状態を lift し、対応する IaC プログラムへ翻訳する技術——通常のデプロイ過程の逆——が必要だ。既存ツールはルールベースの逆エンジニアリングに大きく依存し、自動化の欠如・限られたリソースカバレッジ・誤りの多発に苦しむ。本研究では、IaC lifting を大規模な手作業から解放する新しいアプローチ Lilac のビジョンを描く。Lilac は両方の良さを併せ持つ——大規模言語モデルを活用して lifting ルール抽出を自動化し、symbolic 手法と組み合わせてクラウド環境を制御し正しさの保証を与える。我々は、Lilac が高カバレッジかつ高精度で、自動化され provider に依存しない lifting ツールの構築を可能にすると展望する。 ## 論文情報 - タイトル: Automated Lifting for Cloud Infrastructure-as-Code Programs - 著者・所属: [[Jingjia Peng]]・[[Yiming Qiu]]・[[Patrick Tser Jern Kon]]・Pinhan Zhao・Yibo Huang・Xinyu Wang・[[Ang Chen]]([[University of Michigan]])、Zheng Guo([[University of California, San Diego]]) - 媒体: 2025 IEEE/ACM International Workshop on Cloud Intelligence & AIOps(AIOps '25、ICSE 2025 併設ワークショップ)。Technical Paper(ビジョン論文) - コード: 研究プロトタイプ([[Lilac]]、`github.com/jingjia-peng/Lilac-v0`) ## 概要 Lilac は、既存の非 IaC デプロイ(ブラウンフィールド)を IaC プログラムへ逆生成する IaC lifting を、手作業のルールベース逆エンジニアリングから解放することを目指すニューロシンボリックなアプローチのビジョン論文。鍵となる洞察は「lifting ルール(逆方向)は IaC プログラムのデプロイ(順方向)を観測すれば学習できる」こと。LLM エージェントでルールを抽出し、incremental deployment と IaC ネイティブ検証という symbolic な guardrail で正しさを担保する。 ## 問題設定 - 入力: クラウドの低レベルリソース状態(ブラウンフィールドのデプロイ)。学習時には ground truth として IaC プログラム群(グリーンフィールドのデプロイテストに用いる)。 - 出力: クラウド状態と等価で、再デプロイ可能な高レベルの IaC プログラム(Terraform リソースブロック)。 - lifting ワークフロー(Figure 2)の 3 段: (1) discovery(provider バックエンドからクラウド状態を取得)、(2) mapping(クラウド状態を local state へ写像)、(3) synthesis(local state を IaC プログラムへ翻訳)。 - 要件(IaC ユーザー/開発者調査より): resource coverage(全構成リソースを provider 横断で漏れなく扱う)と correctness(コンパイル可能で、デプロイすれば元のクラウド状態を再現する。複数の IaC ネイティブ検証を通る)。 ## 提案手法 Lilac のワークフロー(Figure 3)は 3 フェーズ。 - **§3.1 Task Decomposition(タスク分解)**: 入力 IaC プログラムと候補クラウド API を、(1) プログラム内のリソースブロックを divide-and-conquer し、(2) 対象リソースに無関係な API 呼び出しを除外する、ことで分解する。 - **Incremental Resource Deployment(漸進的リソースデプロイ)**: IaC リソースブロックとクラウド状態の写像は高度に非対称・ケースバイケース(例: VM 追加は Azure で新 VM をプロビジョンするが、VM-data disk attachment ブロックは新リソースを作らず VM の `storageProfile` を更新するだけ)。各 Terraform プログラムを遷移ステップ列に変換し、依存に基づくトポロジカルソートで 1 リソースずつ追加して、IaC リソースデプロイとクラウド状態更新の正確な対応を見つける。 - **API Selection Agent**: 漸進デプロイされたリソースブロックに対し、関連するクラウド API グループを RAG で予測する(対象リソースを API ドキュメントの記述・使用例と照合)。各グループの API 数を LLM のコンテキスト窓内に保ち精度を上げる。IaC 型とクラウドサービス分類/API ファミリの間に明確な事前写像が無いため必須。 - **§3.2 Verifiable Exploration(検証付き探索)**: - **Cloud Query Agent**: IaC リソースと関連 API グループを入力に、各反復で 3 アクションの 1 つ——(1) API 列を呼んで関連クラウドリソースと子リソースを問い合わせる、(2) 情報が十分なら対象 IaC リソースブロックを生成する、(3) 適切な API が無ければ API Selection Agent に新 API ファミリを要求する。探索パスの全アクションを記録し次段の検証へ渡す。検証はエラーの位置と根本原因を返し、エージェントがクエリと lifting パスを継続的に精緻化する。 - **IaC-Native Verification(IaC ネイティブ検証)**: 3 種——Existence Check(retrieved ID で Terraform へ import を試み、エージェントが存在しないリソースを幻覚していないか確認)、Equivalence Check(lift した IaC を Terraform バックエンドで provider と同期し state drift を検出)、Redeployment Check(空の状態から lift プログラムが現クラウド状態を復元できるかデプロイベースで確認)。 - **§3.3 Knowledge Integration(知識統合)**: エージェントの非構造的な観測を、動的知識ベース内の一般化可能なルールへ統合する。query rule は 3 種——Cloud Discovery Rules(API Query Chain と Cloud-IaC Resource Inference)、Cloud Mapping Rules(Attribute-level Lifting Condition。例: OS disk は VM に nest、data disk は独立ブロック)、Dependency Restoration Rules(aws2tf のように生 ID をハードコードせず、chained API 呼び出しと nested 属性解析で階層トポロジを再構成し再デプロイ可能性を保つ)。ブラウンフィールド lifting 時は KB の query rule のみに依存する。 ## 新規性 - IaC lifting を「順方向デプロイの観測からルールを学習する」逆問題として定式化し、LLM でルール抽出を自動化する初の取り組み(従来は手作業のヒューリスティック)。 - ニューロシンボリック設計: LLM(知識検索・ルール抽出)と symbolic 手法(incremental deployment・IaC ネイティブ検証)を組み合わせ、安全クリティカルな lifting で LLM の幻覚・低再現性を guardrail で抑える。 - 既存ツールの 2 分類(cloud-agnostic な TerraCognita/Terraformer は約 10% の低カバレッジ、cloud-specific な aztfexport は約 95% だが単一 provider に限定)の両方の弱点を、provider 非依存かつ高カバレッジで克服するビジョン(Table 1)。 ## 実験設定 - 全評価項目で、まず Terraform でリソースをデプロイし、元プログラムを lifting の ground truth とする。プロトタイプは Azure・GCP のリソースを対象に複数のルール抽出を実装。 - 比較対象: cloud-agnostic ツール(TerraCognita)、cloud-specific ツール(Azure の aztfexport、Google の gcloud export)。 - アブレーション(Figure 5): Full Pipeline / No Incremental Test / No Verification / No Incremental Test + No Verification の 4 構成で、入力 IaC プログラムのサイズ(group size 1〜7)に対する lifting 成功率を測定。 ## 実験結果 - **RQ1(cloud-agnostic ツール超え)**: TerraCognita 等は約 10% のカバレッジで、リソース間の関係(network と security group、subnet と route table、VM と data disk の attachment 等)を無視して別々の IaC 記述を生成する。Lilac は association ブロックで依存を正しく復元。 - **RQ2(cloud-specific ツール同等)**(Table 2): 43 の Azure リソースでトポロジ再構成の誤り率を測定。Lilac は false positive(冗長)2.3%・false negative(見落とし)0%、aztfexport は 4.6%・7.0%。aztfexport は NAT の firewall rule collection 等を見落とす一方、Lilac は全ベースラインリソースを lift。Lilac の偽陽性は入力プログラム不足によるルールマイニング不完全で、データセット拡充で解消しうる。 - **RQ3(cloud-specific ツール未対応ルール)**(Table 3): Google の gcloud export が未対応の人気リソース型(ComputeNetwork の firewall policy 関連、ComputeRouter の router NAT 関連、NetworkPeering 等)を Lilac は lift でき、必要な association も捕捉する。 - **RQ4(symbolic 設計の効率)**(Figure 5): symbolic guardrail を外し純粋 LLM 駆動にすると、入力サイズ増大で精度が大きく低下。incremental deployment 除去は大規模リソース群で依存管理が難しくなり精度低下、correctness verification 除去は無関係リソースを問い合わせたエージェントが通過し将来の不良ルールを生む。純粋 LLM では IaC lifting に不十分と示す。 ## 考察 - 本論文は進行中の研究のビジョン論文で、初期的証拠としてプロトタイプを提示する段階。Azure/GCP/AWS 横断のエンドツーエンドな産業強度パイプラインへのロードマップを描く。 - lifting は「順方向デプロイの逆」であり、IaC フレームワークが順方向(プログラム→クラウド状態)に最適化されている一方、逆方向は研究が手薄(road less traveled)。verified lifting や bidirectional lens/transformation の系譜に対し、クラウド管理という文脈での補完的研究と位置づける。 ## 強み / 弱点・課題 - **強み**: lifting を「順方向の観測からの学習」へ転換した着眼が明快。ニューロシンボリックで LLM の幻覚を symbolic 検証(import/equivalence/redeployment)で抑える設計。cloud-agnostic と cloud-specific の両弱点を同時に狙う。プロトタイプが aztfexport と同等以上の誤り率を少ない手作業で達成。 - **弱点・課題**: ビジョン論文でありプロトタイプの評価は限定的(43 Azure リソース等)。Lilac の偽陽性は入力プログラム不足由来でデータセット依存。fine-grained ルールへの拡張や Azure/GCP/AWS 横断の完全実現は今後。