# Infrastructure as Code ## 定義 Infrastructure as Code(IaC)は、クラウドインフラを低レベルの API コールでなく宣言的な設定プログラムとして記述・プロビジョニングする取り組み。[[Terraform]]・OpenTofu・Pulumi 等のフレームワークが、VM・NIC・サブネット・ゲートウェイといったクラウドリソースを「リソースブロック」とその依存関係の集合として抽象化し、フレームワークがクラウド API を呼んで実インフラを構築する。これにより利用者は API スクリプトの煩雑さから解放されるが、抽象化はクラウドレベルの複雑さを**隠すだけで除去しない**——プロビジョニングは最終的にクラウド API へ委譲されるため、同じ範囲のエラーに晒される。([[@2024__SOSP__Unearthing Semantic Checks for Cloud Infrastructure-as-Code Programs]]) 中心的な問題は **semantic gap**:構文的に正しく、コンパイルを通過した IaC プログラムであっても、クラウドレベルの規約に違反してデプロイ時に失敗しうる。これはテナント(利用者)とプロバイダ(Amazon・Microsoft 等)の分離に起因する構造的問題で、テナントはクラウドの挙動・規約に限られた可視性しか持たない。例として Azure は「VM とその NIC は同一リージョン」「サブネット CIDR は重複不可」を要求するが、これらは Terraform の構文チェックを通る。IaC は「設定の設定」(configuration of configurations)という階層構造を持ち、リソース内部の属性制約だけでなく**リソース間(inter-resource)の制約**——接続パターン・集約特性——が正しさを左右する点で、MySQL 等のフラットな単一ソフトウェア設定と異なる。([[@2024__SOSP__Unearthing Semantic Checks for Cloud Infrastructure-as-Code Programs]]) IaC のライフサイクルは「方向」で整理できる。**順方向**(IaC プログラム→クラウド状態)が通常のデプロイで、IaC フレームワークが最適化している経路。これに対し、ブラウンフィールド(既存の非 IaC デプロイ)を扱うには 2 つの「逆向き」のタスクが要る——**IaC lifting**(クラウド状態→IaC プログラムの逆生成。[[Lilac]])と、IaC・非 IaC が混在して生じた **infrastructure drift の reconciliation**(帯域外変更→既存 IaC へのパッチ。[[NSync]])。前者はゼロからの program synthesis、後者は既存コードへの program repair で、いずれも最近 LLM エージェント + symbolic 手法で攻められている。([[@2025__AIOps__Automated Lifting for Cloud Infrastructure-as-Code Programs]], [[@2025__arXiv__Automated Cloud Infrastructure-as-Code Reconciliation with AI Agents]]) ## 横断的知見 - **「デプロイ前に防ぐ」IaC 構成検証と、「本番で診断する」AIOps は、同じクラウド信頼性を時間軸の両端から攻める**: [[Zodiac]] はデプロイ時失敗の根本原因(構文を通る semantic violation)を**デプロイ前**に静的・準静的に潰す shift-left 型の取り組みで、その失敗カテゴリは [[@2026__ICSE__An Empirical Study of Production Incidents in Generative AI Cloud Services]] が本番インシデントの根本原因として数えた「設定(configuration)24.5%」「デプロイ失敗 35.7%」とまさに重なる。AIOps クラスタ([[インシデント管理]]・[[根本原因分析]])が「本番で起きた後にテレメトリから診断する」のに対し、IaC 構成検証は「コードのうちに正す」。両者は同一の障害源(設定ミス・デプロイ失敗)を予防と事後対応で挟む補完関係にある。(Source: [[@2024__SOSP__Unearthing Semantic Checks for Cloud Infrastructure-as-Code Programs]], [[@2026__ICSE__An Empirical Study of Production Incidents in Generative AI Cloud Services]]) - **「情報を絞ってから推論」骨格の IaC 版**: vault の AIOps 系([[特徴量削減]]/[[ログ解析]]/[[Bits AI SRE]])が「無関係なテレメトリを削ってから診断」という骨格を共有するのに対し、Zodiac は検証フェーズで MDC pruning(チェックに無関係なリソースを刈り、最小デプロイ可能構成だけ残す)で**テスト対象を絞ってから検証**する。対象がテレメトリでなく構成グラフに変わっても、「文脈に無関係なものを削ってから推論コストを払う」設計原理は同型(Source: [[@2024__SOSP__Unearthing Semantic Checks for Cloud Infrastructure-as-Code Programs]], [[@2024__IEEE Access__MetricSifter - Feature Reduction of Multivariate Time Series Data for Efficient Fault Localization in Cloud Applications]]) - **IaC の 3 取り組みは「ライフサイクルの方向」で住み分ける**: [[Zodiac]] は順方向(プログラム→クラウド)のデプロイ前検証(shift-left)、[[Lilac]] は逆方向(クラウド状態→プログラム)の lifting、[[NSync]] は混在運用で生じた drift の reconciliation(帯域外変更→既存 IaC へのパッチ)。同じ IaC を、デプロイの前・逆・修復という別の時点/方向から攻めており、3 者を束ねると IaC ライフサイクル全体の自動化地図になる。(Source: [[@2024__SOSP__Unearthing Semantic Checks for Cloud Infrastructure-as-Code Programs]], [[@2025__AIOps__Automated Lifting for Cloud Infrastructure-as-Code Programs]], [[@2025__arXiv__Automated Cloud Infrastructure-as-Code Reconciliation with AI Agents]]) - **lifting(合成)対 reconciliation(修復)——同一研究室が問題の難度で切り分ける**: [[Lilac]] と [[NSync]] はいずれも [[Ang Chen]]([[University of Michigan]])グループで、ブラウンフィールド問題を別アプローチで攻める。Lilac は非 IaC インフラを**ゼロから IaC へ起こす program synthesis**、NSync は**既存 IaC への的を絞った program repair**。NSync は明示的に「lifting はゼロからの合成ゆえ脆く低カバレッジで、生 ID を埋め込んだ平坦な構成を生む。reconciliation は問題を修復に縮約して脆弱性を避ける」と差別化する(§5)。一方 Lilac は dependency restoration ルールで「生 ID をハードコードせず再デプロイ可能にする」と、まさに NSync が突く lifting の弱点に正面から取り組む。逆生成と修復は競合でなく、ブラウンフィールド IaC 化の補完手段。(Source: [[@2025__AIOps__Automated Lifting for Cloud Infrastructure-as-Code Programs]], [[@2025__arXiv__Automated Cloud Infrastructure-as-Code Reconciliation with AI Agents]]) - **収束する設計骨格: LLM + symbolic guardrail + 蓄積する知識ベース**: [[NSync]] も [[Lilac]] も、LLM 単体では安全クリティカルなクラウド操作に不十分とみて symbolic な検証で囲う。NSync は「ニューロシンボリックな注釈」+ read-only ツール(drift_report・self_critique)で実行なしに静的評価、Lilac は「ニューロシンボリック」+ IaC ネイティブ検証(import/equivalence/redeployment)。さらに両者とも**動的に育つ知識ベース**(NSync はプロジェクト単位の継続学習 KB、Lilac はクラウドクエリ規則の KB)を持ち、観測から一般化規則を蓄積して再利用する。LLM の幻覚・低再現性を symbolic 検証で抑え、経験を KB に貯める設計が独立に収束している。(Source: [[@2025__arXiv__Automated Cloud Infrastructure-as-Code Reconciliation with AI Agents]], [[@2025__AIOps__Automated Lifting for Cloud Infrastructure-as-Code Programs]]) - **inter-resource 依存が方向を問わず核心**: [[Zodiac]] は順方向検証で「リソース間制約こそ semantic gap の核」と言い、[[Lilac]] は逆生成で「VM-data disk attachment の nest 判断・依存復元こそ難所」と言い、[[NSync]] は drift 統合でリソースをノード、attach/detach をエッジとして扱う。IaC の正しさを左右するのは個々のリソース属性でなくリソース間の依存・接続であり、これが順方向・逆方向・修復のいずれでも最難所になる。(Source: [[@2024__SOSP__Unearthing Semantic Checks for Cloud Infrastructure-as-Code Programs]], [[@2025__AIOps__Automated Lifting for Cloud Infrastructure-as-Code Programs]], [[@2025__arXiv__Automated Cloud Infrastructure-as-Code Reconciliation with AI Agents]]) - **クラウド API が共通の最下層**: [[NSync]] の鍵となる洞察は「IaC・コンソール・CLI・SDK の変更はすべて最終的にクラウド API へ帰着する」ことで、API 監査トレース([[AWS CloudTrail]])を drift 検知の観測点にする。[[Lilac]] も lifting でクラウド API を順に呼んで状態を discovery する。[[Zodiac]] も「IaC の抽象化は複雑さを隠すだけで、プロビジョニングは最終的に API へ委譲される」と言う。クラウド API という最下層が、検証・逆生成・修復いずれの共通基盤になっている。(Source: [[@2025__arXiv__Automated Cloud Infrastructure-as-Code Reconciliation with AI Agents]], [[@2025__AIOps__Automated Lifting for Cloud Infrastructure-as-Code Programs]], [[@2024__SOSP__Unearthing Semantic Checks for Cloud Infrastructure-as-Code Programs]]) - **IaC は「4 モダリティの 1 つ」として相対化される——強みと弱みが構造的に位置づく**: 同じ [[Ang Chen]] グループのビジョン論文 [[@2025__OSR__Cloud Infrastructure Management in the Age of AI Agents]] は、IaC を SDK・CLI・ClickOps と並ぶ 1 [[クラウド管理モダリティ]]として相対化し、AI エージェントの予備実験で得手不得手を測った。宣言的・state-centric ゆえ **再作成を伴う更新に最も強い**(standard→spot 変更は属性 1 つの変更で [[Terraform]] が teardown/recreate を自動処理。SDK/CLI/ClickOps は手順を辿り失敗しやすい)反面、**monitoring に最も弱く**(成功率 0.40、非 IaC 言語を吐く hallucination や deprecated メソッド)、state-centric 設計は構成を捉えるが runtime telemetry を取り出せず、context window 制約で全状態を渡せないため更新成功率も 0.33 にとどまる。Zodiac/NSync/Lilac が IaC「内部」のライフサイクル(検証・逆生成・修復)を深掘りするのと、このビジョン論文が IaC を「外から」他モダリティと比べるのは補完的で、後者は IaC の state-centric 設計が「再作成更新の強み」と「monitoring の弱み」の両方の根であることを浮かび上がらせる。(Source: [[@2025__OSR__Cloud Infrastructure Management in the Age of AI Agents]], [[@2024__SOSP__Unearthing Semantic Checks for Cloud Infrastructure-as-Code Programs]]) ## 未解決の問い - semantic gap を埋める正攻法は「IaC フレームワークのコンパイル段階にチェックを組み込む」ことだが、[[Terraform]] の core compiler は cloud-agnostic でプラグインは per-attribute 制約しか許さない。inter-resource なセマンティックチェックを表現・実行できるコンパイル時インターフェースはどう設計すべきか。 - imperative な IaC(Pulumi・AWS CDK)では、宣言的 Terraform のように設定へ直接エンコードされた intra/inter-resource 関係が見えにくい。imperative IaC のセマンティックチェックを取り出すプログラム解析手法は何か。 - region 固有(sku の地域差)・subscription 固有(クォータ)の制約は [[Zodiac]] の射程外。アカウント状態に依存する動的制約をどう静的検証に取り込むか。 - IaC のデプロイプラン(JSON)はフレームワーク間で似た形式を持つ。これを共通項にすれば AWS CDK・CDKTF 等へ手法を一般化できるか([[設定マイニング]]の移植性の問いと連動)。 - デプロイ前検証([[Zodiac]])・逆生成([[Lilac]])・drift 修復([[NSync]])は、いまは別々のツール/論文。これらを 1 つの IaC ライフサイクル管理エージェントへ統合できるか。例えば lift した IaC をそのまま semantic check に通し、以後の drift を継続 reconcile する、といった連結。 - [[NSync]] は検知した drift をすべて IaC に取り込む前提で、**意図的 drift(保持すべき)と巻き戻すべき drift の区別**を future work とする。何を IaC に反映し何を破棄するかの意図推定は、どの信号(運用文脈・チケット・変更頻度)で決められるか。 - lifting/reconciliation の評価はいずれも Terraform + 単一クラウド(NSync は AWS、Lilac は Azure/GCP)に限定。provider 横断・IaC フレームワーク横断(Pulumi・OpenTofu)へ一般化したとき、API 監査スキーマや local state 方式の差をどう吸収するか。 - IaC エージェントの monitoring 不利(state-centric ゆえ runtime telemetry を取れない・context window 制約で全状態を渡せない)は、長文脈モデルや IaC への telemetry 取得 API の追加でどこまで解消するか。逆に、IaC を monitoring/update に使うべきか、それとも [[クラウド管理モダリティ]]の agent-cloud interface で CLI/Web と組み合わせて IaC の弱点を補うべきか。([[@2025__OSR__Cloud Infrastructure Management in the Age of AI Agents]]) ## 関連 - ソース: [[@2024__SOSP__Unearthing Semantic Checks for Cloud Infrastructure-as-Code Programs]] / [[@2025__arXiv__Automated Cloud Infrastructure-as-Code Reconciliation with AI Agents]] / [[@2025__AIOps__Automated Lifting for Cloud Infrastructure-as-Code Programs]] - 概念: [[設定マイニング]] / [[障害注入]] / [[インシデント管理]] / [[根本原因分析]] / [[AIOps]] / [[クラウド管理モダリティ]] - エンティティ: [[Terraform]] / [[Microsoft Azure]] / [[Zodiac]] / [[Ryan Beckett]] / [[NSync]] / [[Lilac]] / [[Ang Chen]] / [[AWS CloudTrail]] / [[aztfexport]] / [[Azure Copilot]] - 関連 MOC: [[Software Engineering - MOC]] / [[Network - MOC]] / [[SRE - MOC]] / [[AI4SE - MOC]] ## 出典 - [[@2024__SOSP__Unearthing Semantic Checks for Cloud Infrastructure-as-Code Programs]](§1 Introduction, §2.1 Cloud IaC Programs, §2.2 Syntactic vs. Semantic Checks, 図 1 semantic gap の例) - [[@2025__arXiv__Automated Cloud Infrastructure-as-Code Reconciliation with AI Agents]](Abstract, §1–3 NSync 設計, §5 lifting との対比) - [[@2025__AIOps__Automated Lifting for Cloud Infrastructure-as-Code Programs]](Abstract, §2 Motivation, §3 Solution Sketch, §4 Preliminary Validation) - [[@2026__ICSE__An Empirical Study of Production Incidents in Generative AI Cloud Services]](本番根本原因の設定 24.5%・デプロイ失敗 35.7%) - [[@2025__OSR__Cloud Infrastructure Management in the Age of AI Agents]](§2.1 IaC modality, §2.3 case study Table 1, Obs #2/#3 で IaC の update 強み・monitoring 弱み)