> [!abstract] 概要(arXiv abstract の日本語訳) > クラウドインフラは複数のインターフェースの混在で管理される——従来はクラウドコンソール・コマンドラインインターフェース(CLI)・SDK が選択肢だった。近年、Infrastructure-as-Code/IaC フレームワーク(例: Terraform)が急速に普及している。従来のツールと異なり、IaC フレームワークはインフラを「信頼できる唯一の情報源(source-of-truth)」の構成として符号化する。それらは実際のインフラを IaC 構成に一致させるべく、リソースのデプロイ・更新・破棄といった変更をクラウドに自動的に適用できる。IaC フレームワークがコンソール・CLI・SDK と併用されると、IaC はこれら非 IaC インターフェース経由の変更を認識できず、IaC 構成は意図した状態を捉えなくなる。これを infrastructure drift と呼ぶ。IaC フレームワークは古くなった IaC 構成に基づいて非 IaC 変更を巻き戻し、設定不整合や障害を引き起こす。 > 我々は IaC reconciliation のための自動システム NSync を提案する。これは帯域外(out-of-band)の変更を更新の形で IaC プログラムへ反映させることを目指す。我々の鍵となる洞察は、IaC・コンソール・CLI・SDK のいずれを経たインフラ変更も、最終的にはすべてクラウド API 呼び出し——クラウド管理操作の最下層——として生じる、というものだ。したがって NSync は API トレースから洞察を引き出して drift(非 IaC 変更)を検知し、それを reconcile する(変更を捉えるよう IaC 構成を更新する)。これは難しいタスクだ——低レベルでノイズの多い API トレースから意図した変更を特定するのは容易でなく、加えてクラウドインフラの重要性ゆえに、NSync は合成した更新をライブ環境で直接テストできない。NSync はこれらの課題をエージェント的設計で扱う。LLM の助けを借りてクラウド API 列から高レベルのインフラ変更意図を推論し、カスタマイズしたエージェントツールによるドメイン固有のコンテキスト管理で的を絞った IaC 更新を合成する。さらに過去の成功した reconciliation 実行の進化する知識ベースを保持し、先行する洞察を再利用して将来のタスクで高い精度を達成する。システム設計に加え、権威あるクラウド運用事例から取得して IaC 中心のフレームワークへ移し替えることで、クラウドインフラに drift を注入し reconciliation の試行を評価する新しい評価パイプラインを貢献する。5 つの実 Terraform プロジェクトと 372 drift シナリオでの実験は、NSync が精度(0.71→0.97 pass@3)とトークン効率(1.47 倍改善)の両面でベースラインを上回ることを示す。 ## 論文情報 - タイトル: Automated Cloud Infrastructure-as-Code Reconciliation with AI Agents - 著者・所属: [[Zhenning Yang]]・[[Ang Chen]]([[University of Michigan]])、Hui Guan・Victor Nicolet・Brandon Paulsen・Joey Dodds・Daniel Kroening([[Amazon Web Services]]) - 媒体: arXiv プレプリント(cs.SE) - 発表: 2025-10-23(arXiv:2510.20211v1) - コード: オープンソース公開予定(本文に明記、URL は未記載) ## 概要 NSync は、コンソール・CLI・SDK 経由の帯域外変更で生じる infrastructure drift を、クラウド API トレースから検知して IaC 構成へ反映する初の自動 reconciliation システム。タスクを program repair として定式化し、(1) ノイズの多い API トレースから変更意図を特定する intent identification、(2) ライブ実行なしで read-only ツールで評価する patch generation、(3) プロジェクト単位の知識ベースで過去の成功を再利用する continual learning の 3 段で構成する。 ## 問題設定 - 入力: IaC プロジェクトのソース構成(Terraform `.tf` 一式)と、クラウド API 監視サービス(AWS CloudTrail)が記録した API 呼び出しトレース。 - 出力: drift を捉えるよう既存 IaC 構成を更新するコードパッチ(新規リソースの `import` ブロックや属性更新の diff)。 - 前提: IaC・非 IaC のすべての変更が最終的に RESTful なクラウド API を呼ぶ。クラウドは中央集権的な状態ファイルを持たず、各リソースが個別に状態 API を露出する。 - 重要な制約: クラウド運用の重要性ゆえ合成パッチをライブ環境でテストできない。`terraform plan` の dry-run は IaC 管理下のリソースに限られ、帯域外リソースを完全には検証できない。 ## 提案手法 - **アーキテクチャ**(Figure 2): intent identification がノイズの多い API トレースを解析して変更の有無と性質を判定し、patch generation が source 構成・特定した変更意図・プロジェクト単位の進化する知識ベースを参照しつつ専用ツールで更新を合成する。 - **Intent Identification(意図特定)**: 系列順序に依存せず、イベントの内容と関係に注目する(監査サービスはイベントを順不同に記録しうるため)。前処理で read-only 呼び出し(`Describe*`・`List*`)を破棄し、リトライを最終成功のみに重複排除し、timestamp/request ID 等の無関係フィールドを除く。 - **Step 1 — Annotation(注釈)**: ニューロシンボリックな注釈手続き。固定スキーマ(Table 1: category/type/id/type1/id1/type2/id2)で異種の API 呼び出しに一貫したラベルを付与する。category は create・delete・update・attach・detach・unknown の 6 種。LLM は意味を文脈で判断する(例: `CreateTags` は新規作成に見えて実は update、`RunInstances` は更新に見えて実は create)。スケーラビリティのため API 呼び出しをバッチ単位で注釈し(Algorithm 1)、既出のリソース型 $T$ をメモリとして渡し一貫性を保ち、バッチごとに最大 $r$ 回リトライする。 - **Step 2 — Consolidation(統合)**: reconciliation は末尾に残る persistent drift のみを要する。イベントをリソース識別子(ノード)とエッジ ⟨id1, id2⟩ ごとに整理し、reduction rules を独立に適用——Persistent Create(作成後に削除なし→create のみ残し中間 update を捨てる)、Persistent Delete(削除→delete のみ残す)、Persistent Update(update のみ→保守的に残す)、Persistent Attach/Detach(均衡ペアは相殺、不均衡は残す)。出力は保守的にまとめた persistent drift の集合。 - **Patch Generation(パッチ生成)**: patch–evaluate–refine の反復ループ。実行フィードバックの代わりに read-only ツールで評価する。 - **drift_report**: `terraform plan` に着想を得た read-only 操作だが、reconciliation 向けに再構成する。`terraform plan` は古い IaC を source-of-truth とみなしてクラウド側変更を巻き戻す計画を出し、"known after apply" を含む冗長出力で LLM の文脈を汚染する。drift_report は実際に drift したリソースのみに出力を絞り、IaC コードベース内の位置を注記する。 - **self_critique**: reflection / self-refinement に着想を得た、実行なしの安全な内省機構。これまでの編集を列挙させ正しさと必要性を推論させる。drift_report より粗い粒度で、編集の蓄積を定期的に見直し reconciliation の意図に整合しているかを問い、幻覚的変更・スコープクリープを防ぐ。 - **Continual Learning(継続学習)**: 軽量でドメイン固有・プロジェクト単位の知識ベース(KB)。有効なパッチ戦略・頻出する drift パターン・プロジェクト固有の規約(命名・モジュール構造・依存)を記録する。原則は (1) 成功した reconciliation のみが新エントリに寄与(失敗は破棄)、(2) KB はグローバル共有でなくプロジェクト単位(クロスプロジェクト汚染の防止)。ReAct 風の Observation–Thought–Action ループで、エージェントが `knowledge_update`・`knowledge_retrieval` を自律的に呼ぶ。プロトタイプの KB はプロジェクト固有のテキストファイルで、ベクトル DB へ拡張可能。 ## 新規性 - IaC reconciliation という新タスクを提起し、API トレースから洞察を得て program repair として解く初の自動システム。 - 既存の lifting ツール(Terraformer・[[aztfexport]]・TerraCognita 等)が「ゼロからの program synthesis」で脆く低カバレッジなのに対し、NSync は「既存 IaC への的を絞った program repair」に問題を縮約して脆弱性を回避(§5 Discussion)。 - 従来の APR が明示的なテスト/仕様を持つのに対し、IaC reconciliation の「仕様」は API トレースに暗黙に符号化される。実行可能なテストケースなしで宣言的更新を合成する点が新しい。 - ライブテスト不能という制約下で、read-only ツール(drift_report・self_critique)による静的評価で反復修復を実現。 ## 実験設定 - **実装**: Python 11k 行。AWS 向け Terraform を対象。Boto3 で CloudTrail に接続し API トレースを取得。 - **ベースライン**: 3 エージェントすべて Strand agent framework 上で、AWS Bedrock 経由の Claude 3.7 Sonnet を backbone とする。(1) Baseline(汎用のファイル編集 + shell ツールのみ、ドメイン特化なし)、(2) NSync-NL(継続学習なし、各 reconciliation を独立扱い)、(3) NSync(全機構)。共通ツールは file_read・file_write・editor・shell(Table 3)。 - **データセット**: 5 つの実 Terraform プロジェクト・372 検証済み drift ケース(Table 2)。lab12(47 リソース・96 シナリオ)、flask(74・94)、ssm3(66・103)、live-score(193・61)、mega-mesh(1930・18)。うち 127 が偽陽性ケース(変更後に巻き戻し、永続 drift なし)。 - **drift 生成パイプライン**(Figure 3): AWS Systems Manager(SSM)Automation runbook(763 件→90 シナリオに絞り込み)を主な出典に、LLM でベース構成と自然言語シナリオから変異構成を生成し、デプロイテストで検証して残す。API スクリプト直接実行でなく変異 IaC のデプロイで drift を注入し、再現性と ground truth(変異構成の Terraform state)を確保。 - **評価指標**: pass@k(正しさ)、処理トークン数とエージェントステップ数(効率)。各システム 3 回独立実行、シナリオ順は任意化。パッチは ground truth state に対する `terraform plan` が `import` 以外の差分を出さなければ正解。 ## 実験結果 - **RQ1/2 効果と効率**(Table 4): 372 ケース全体で NSync は pass@3 0.97(Baseline 0.71、NSync-NL 0.95)、平均 0.47M トークン(Baseline 0.69M、1.47 倍効率化)、平均 17.7 ステップ(Baseline 22.0)。モジュール構造を持つ複雑プロジェクトで差が拡大。Baseline は冗長な `terraform plan` 出力で文脈が肥大化し、「現構成を適用すれば直る」(=帯域外変更の巻き戻し)と誤推論する幻覚を起こす。 - **pass@1**(Table 7): 全体で NSync 0.80(Baseline 0.49、NSync-NL 0.76)。継続学習は精度だけでなく分散も低減(より信頼できる出力)。 - **RQ3 intent identification**(Table 5・Figure 4): IID はトークン・ステップを 23% 削減しつつ精度を維持。注釈は 1 drift あたり平均 5.6K トークンで全体コストの約 1%。合成 190 イベントのトレースで batch size 40 が最適点、140 超で精度が急落。 - **RQ4 patch generation**(Table 6): live-score で各ツール除去が精度を下げ、drift_report 除去が最大の低下(0.98→0.60)。self_critique 除去で 0.81。tool 使用タイミング(Figure 5): drift_report は全体を通じ均一、self_critique は終盤に集中、knowledge_retrieval は前段・knowledge_update は後段。 - **RQ5 continual learning**(Figure 7): drift 複雑度(変異 API 呼び出し数)が増すと Baseline の精度が低下しトークンが増えるのに対し、NSync-NL/NSync は安定。Figure 8 に lab12 の進化する KB のスニペット(VPC flow log の `$` エスケープ、`moved` ブロックでのリネーム処理等)。 ## 考察 - **lifting との対比**(§5): lifting ツール(Terraformer・aztfexport・TerraCognita・aws2tf・Terracognita)は非 IaC インフラをゼロから IaC へ起こす関連だが別タスクで、リソース型ごとに手作業対応を増やす必要があり、生のランタイム値を埋め込んだ平坦で非モジュラーな脆い構成を生む。NSync は「ゼロからの合成」でなく「既存への修復」に縮約して脆弱性を避ける。 - **Terraform/AWS を超えて**(§5): アーキテクチャは Pulumi・OpenTofu や Azure・GCP に一般化可能と主張。各クラウドの API 監視ツールやイベントスキーマの差、各 IaC フレームワークの local state/plan 操作の差が変更点。 - **限界**: 残る失敗は主に import 処理(リソース名と識別子の取り違え等)。RAG で正しい import 構文を直接供給すれば緩和しうる。drift_report は現状すべての検知変更を IaC に取り込む前提で、意図的 drift(保持すべき)と巻き戻すべき drift の区別は future work。 ## 強み / 弱点・課題 - **強み**: API トレースという IaC・非 IaC 共通の最下層を観測点に据えた着眼。ライブテスト不能という制約を read-only ツールの静的評価で回避。program repair への問題縮約で lifting の脆弱性を避ける。新しい drift 注入パイプラインと 372 ケースのデータセットを貢献。 - **弱点・課題**: 評価は Terraform + AWS に限定(他クラウド/IaC は未検証)。意図的 drift と巻き戻すべき drift の区別が未対応。import 処理の取り違えが残存。KB はテキストファイルのプロトタイプ。