# 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]]) - **cfengine(1990年代)は、Terraform 世代の IaC が抱える「semantic gap」を、20年早く同じ構造で予告していた**: Zodiac が定式化する semantic gap(構文的に正しい IaC プログラムでも、クラウドレベルの規約——リソース間の暗黙の制約——に違反してデプロイ時に失敗する)は、「宣言的な標準手法が低レベルの詳細を隠すが除去しない」という一般的な設計原理の一事例である。*Principles of Network and System Administration* 第7章§7.2・§7.4は、この一般原理を Terraform 登場の約10年前、cfengine を題材に明示的に述べている——標準化されたメソッド(cfengine の宣言的アクション)への移行は予測可能性を高める(Principle 40: Standardized methods offer predictability)一方、「手法が正しく実装されていれば品質管理が向上するが、欠陥があれば単一障害点かつ単一の修復点を持つ系統的な誤りになる」と明記する。この「標準化は複雑さを隠すが除去しない」という論点は、Zodiac が2024年に「IaC の抽象化はクラウドレベルの複雑さを隠すだけで除去しない」と述べたのと同じ構造の指摘であり、宣言的インフラ記述という設計様式そのものに内在するトレードオフが、対象がホスト設定であれクラウドリソースであれ、20年間変わらず現れ続けていることを示す。(Source: [[@2004__Wiley__Principles of Network and System Administration - Chapter 7 Configuration and maintenance]] §7.2, §7.4, [[@2024__SOSP__Unearthing Semantic Checks for Cloud Infrastructure-as-Code Programs]]) - **cfengine は make・Prolog との対比によって、「宣言的」であることの中身を初期段階から3つの水準に切り分けていた**: 第7章§7.4は、cfengine を「最終状態だけを記述し、経路は言語自身の標準手法が評価する」という点で make とも区別する——make は依存関係を宣言するが、経路(コマンド)自体は利用者が命令的に書く点で「宣言的言語のホストフレームワーク」にとどまり、cfengine は経路の評価自体に専門知識(standard methods with special properties)を埋め込む点でより宣言性が高い、という区別を立てる。この区別は、現代の IaC 論争(imperative な Pulumi・AWS CDK と宣言的な Terraform の違い、[[Infrastructure as Code]]の未解決の問いが扱う「imperative IaC のセマンティックチェック抽出手法」)が今もなお整理しきれていない「宣言性の度合い」という軸を、cfengine の時点で make・Prolog という参照点を使って明確に切り分けていたことを示す。(Source: [[@2004__Wiley__Principles of Network and System Administration - Chapter 7 Configuration and maintenance]] §7.4) - **実務者コミュニティは、クラウド API 登場前(2011年)の時点で「インフラをサービスの合成として捉える」骨格を SOA(サービス指向アーキテクチャ)から輸入していた**: 本ページが扱う 2020年代の IaC 研究(Zodiac・Lilac・NSync)は Terraform 等の宣言的フレームワークによるクラウド API 呼び出しを前提とするが、[[@2011__OReillyJapan__ウェブオペレーション - Chapter 5 コードとしてのインフラ]](Adam Jacob, 2011)は Amazon EC2 が普及し始めた時期に、インフラを「再利用可能でネットワークアクセス可能なサービス」(ブートストラップ・コンフィギュレーション・バックアップ・DNS の4種)に分割し統合するという、SOA から輸入した骨格を提示していた。同章が導入する「モジュール化・協調性・組み立て可能」という3原則は、Zodiac・NSync が扱う「リソース間(inter-resource)の依存・接続こそ正しさの核心」という論点の前段、すなわち"そもそも何を独立したサービス/リソース単位に切り出すべきか"という設計判断に対応する。IaC 研究がこの設計判断を所与としてリソース記述の検証・逆生成・修復に注力するのに対し、ch5 はその設計判断自体を主題にしている点で、両者は IaC の異なる層(何を単位に切り出すか/切り出した単位をどう検証・管理するか)を扱う。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 5 コードとしてのインフラ]] §5.1, [[@2024__SOSP__Unearthing Semantic Checks for Cloud Infrastructure-as-Code Programs]]) - **宣言的・べき等・収束的という3性質は、cfengine(1993)→Web運用実務(2011)→クラウド IaC 研究(2020年代)の3世代にわたって同一の中核として反復される**: [[cfengine]] 概念・[[Mark Burgess]] 概念が記録するとおり、*Principles of Network and System Administration* 第7章(2004)は cfengine を宣言的言語として理論的に位置づけるが、ch5(2011)は同じ3性質(宣言的・抽象化・べき等性・収束化)を Web オペレーション実務者向けに Cfengine 2 の `packages: sudo / action=installed` という具体的な構文例で再提示し、これが [[Chef]]・[[Puppet]] を含む後続ツールに継承されたと述べる。本ページが扱う Terraform/Zodiac の「宣言的にリソースを記述し、フレームワークが実際の状態に到達させる」という設計も同じ3性質の直系の子孫であり、cfengine が定式化した性質が、ホスト単位の構成管理からクラウドリソース単位の IaC へと対象を変えながら20年以上にわたって核であり続けていることが、3つの独立した時代のソースを並べることで確認できる。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 5 コードとしてのインフラ]] §5.1.1.3, [[@2004__Wiley__Principles of Network and System Administration - Chapter 7 Configuration and maintenance]] §7.4, [[@2024__SOSP__Unearthing Semantic Checks for Cloud Infrastructure-as-Code Programs]]) - **同じ2011年の実務エッセイでも、ch5がインフラサービスの「設計原理」を語るのに対し、ch18は「変更管理パイプライン」という別の層を具体的に見せる——後年の GitOps が統合する2つの半身**: ch5(Adam Jacob)はインフラを再利用可能なサービスへ分割する設計原則を論じるが、その設定変更をどう履歴管理し、どう安全に本番へ適用するかという運用手順にはほとんど立ち入らない。18章([[Cookpad|クックパッド]])は対照的に、設計原則には触れず、[[Keepalived]]・[[Puppet]]・Nagiosの設定ファイルをGitで版管理し、変更はCapistranoの`cap deploy`(対象選択→デプロイ→シンタックスチェック→適用という順序)を通じてのみ本番に反映するという、変更管理パイプラインの具体的な手順を詳述する。両者を合わせると、「何を宣言的に記述するか」(ch5・cfengine・Terraform系譜)と「その記述をどう安全にレビュー・検証・適用するか」(ch18のGit+Capistranoパイプライン)という、後年のGitOptsが統合する2つの構成要素が、2011年の時点ですでに別々の実務エッセイとして独立に存在していたことが分かる。ch18のパイプラインが「デプロイ実行前の最終シンタックスチェック」を明示的に組み込む点は、[[Zodiac]]が2024年に定式化するデプロイ前検証(shift-left)を、クラウドAPIでなくホスト設定ファイルという対象で、13年早く簡易な形で先取りしていたとも読める。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 5 コードとしてのインフラ]] §5.1, [[@2011__OReillyJapan__ウェブオペレーション - Chapter 18 日本の料理のインフラ]] §18.4, [[@2024__SOSP__Unearthing Semantic Checks for Cloud Infrastructure-as-Code Programs]]) - **2019年のDevOps学術サーベイは、IaCを「Delivery(開発関連)」ではなく「Runtime(運用関連)」領域に分類し、これは本ページが集約する2011年のWebOps ch5(SOA由来の設計原理としてのインフラ)とは異なる軸での位置づけである**: Leite et al.(2019)第5章のRuntime概念地図(§5.4)は、パフォーマンス・可用性・スケーラビリティ・耐障害性・信頼性という望ましい成果を達成する経路として、Infrastructure as Codeを仮想化・コンテナ化・クラウドサービス・監視と並列に位置づける。同章の全体概念地図(図4)は、Runtime領域を「Ops related・Engineering perspective」の象限に置き、Delivery領域(バージョニング・CI・デプロイメントパイプライン等が属する)とは区別する。本ページが既に集約する[[@2011__OReillyJapan__ウェブオペレーション - Chapter 5 コードとしてのインフラ]](Adam Jacob, 2011)は、IaCをSOA由来の「サービスの合成」という設計原理の問題として扱っており、これはむしろLeite et al.(2019)のDelivery領域(何を単位に切り出し、どう構成管理するか)に近い枠組みである。同じIaCという対象が、2019年の学術サーベイでは「運用の安定性を実現する手段」(Runtime)として、2011年の実務エッセイでは「サービス設計の原理」(Delivery寄り)として、異なる軸で捉えられていることになる——ただし後者はDevOpsという語彙上の分類を経ておらず(本ページ既出のch5知見)、直接の矛盾ではなく分類軸の違いとして留めておく。(Source: [[@2019__ACM CSUR__A Survey of DevOps Concepts and Challenges - Chapter 5 Fundamental Concepts]] §5.4, §5, [[@2011__OReillyJapan__ウェブオペレーション - Chapter 5 コードとしてのインフラ]] §5.1) ## 未解決の問い - Leite et al.(2019)がIaCをRuntime(運用の安定性を実現する経路)に分類する一方、2011年のWebOps ch5はIaCをDelivery寄りの設計原理として扱う(本ページ既出の知見)。この分類の違いは、IaCという概念が2011年から2019年の間に「何を実現する手段か」という重心を移動させたことを反映するのか、それとも単に異なる文献が異なる粒度でIaCを切り取っているだけか。本ページの現ソース群では未検証。 - 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]] / [[@2004__Wiley__Principles of Network and System Administration - Chapter 7 Configuration and maintenance]] / [[@2011__OReillyJapan__ウェブオペレーション - Chapter 5 コードとしてのインフラ]] / [[@2011__OReillyJapan__ウェブオペレーション - Chapter 18 日本の料理のインフラ]] / [[@2019__ACM CSUR__A Survey of DevOps Concepts and Challenges - Chapter 5 Fundamental Concepts]](IaCをRuntime領域に分類する概念地図) - 概念: [[設定マイニング]] / [[障害注入]] / [[インシデント管理]] / [[根本原因分析]] / [[AIOps]] / [[クラウド管理モダリティ]] / [[収束型システム管理]] / [[べき等性]] - エンティティ: [[Terraform]] / [[Microsoft Azure]] / [[Zodiac]] / [[Ryan Beckett]] / [[NSync]] / [[Lilac]] / [[Ang Chen]] / [[AWS CloudTrail]] / [[aztfexport]] / [[Azure Copilot]] / [[cfengine]] / [[Mark Burgess]] / [[Adam Jacob]] / [[Chef]] / [[Puppet]] / [[Keepalived]] / [[Cookpad]] - 関連 MOC: [[Software Engineering - MOC]] / [[Network - MOC]] / [[SRE - MOC]] / [[AI4SE - MOC]] ## 出典 - [[@2011__OReillyJapan__ウェブオペレーション - Chapter 5 コードとしてのインフラ]](アダム・ジェイコブ, 2011, §5.1〜§5.2 — SOA由来の3原則とCfengine由来の4原則を合わせた「よいインフラサービスの10原則」) - [[@2011__OReillyJapan__ウェブオペレーション - Chapter 18 日本の料理のインフラ]](濱崎 健吾, 2011, §18.4 — Git+Capistranoによる設定ファイルの変更管理パイプライン) - [[@2004__Wiley__Principles of Network and System Administration - Chapter 7 Configuration and maintenance]](Mark Burgess, John Wiley & Sons, 2004, §7.2, §7.4 — 宣言的言語の先行例としての cfengine と make/Prolog との対比) - [[@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 弱み) - [[@2019__ACM CSUR__A Survey of DevOps Concepts and Challenges - Chapter 5 Fundamental Concepts]](Leite・Rocha・Kon・Milojicic・Meirelles, ACM Computing Surveys 52(6), 2019, §5.4, §5)— IaCをRuntime概念地図(パフォーマンス・可用性・スケーラビリティ・耐障害性・信頼性への経路)に分類