IaC（Infrastructure as Code）と生成AIの周辺で、2026年に入ってから実測データや新しいツールがまとまって出てきました。断片的に見ていると全体像がつかみにくいので、いったん整理してみます。
この記事について
対象読者：AWS / Azure / GCP のインフラをコード（CDK・Terraform・CloudFormation）で構築していて、生成AIにその一部を任せている、あるいは任せようとしている人。
扱うこと：
- IaC × 生成AI の周辺に、いま何が立っているのか
- 「LLMはIaCをどれくらい書けるのか」の実測データ
- そこから見えてくる、検査が手薄な論点
すべて公開情報のまとめです。数字は論文から引いていますが、判断の材料にする際は一次資料にあたってください。
1. いま、何がどこに立っているのか
3つの層に分けると整理しやすくなります。
生成層 — コードを書く
Claude Code、Cursor、GitHub Copilot、OpenAI Codex。ここは説明不要でしょう。
2026年の変化としては、AWS が Kiro を投入しました。Kiro は「仕様駆動開発（spec-driven development）」を掲げ、いきなりコードを書かせません。まず requirements.md（何を作るか）、次に design.md（どう作るか）、最後に tasks.md（作業分解）を作らせ、それから実装に入ります。Amazon Q Developer は2026年4月30日でサポートを終え、Kiro に一本化されました。
検証層 — できたものを検査する
-
cdk-nag — AWS CDK の Aspects 機構を使い、
cdk synthの時点で静的にチェックする - Checkov — 1,000を超えるポリシーを持つ。Terraform / CloudFormation / Kubernetes / Helm / ARM / Bicep に対応
- Trivy（tfsec を吸収）、KICS、Terrascan、Regula、Sentinel（Terraform専用・HashiCorp独自言語）
- OPA / Conftest / Gatekeeper — Rego というポリシー言語で書く汎用の検査基盤
ここ数年、この層の性質は変わっていません。増えたのはルールの数と、その上に乗る商用ダッシュボードであって、「何を検査しているか」は同じです。すなわち——
できあがった成果物が、一般的なベストプラクティスに適合しているか。
この一文は後でつながってきます。
オーケストレーション層 — 適用を統治する
Spacelift、env0、Atlantis。ここに新種が出ました。Spacelift Intent です。
自然言語で「us-east-1 に S3 バケットを作って、パブリックアクセスは全部ブロックで」と言うと、MCP（Model Context Protocol）経由で Terraform プロバイダの API を直接叩いてリソースを作ります。HCL は1行も書きません。それでいて OPA ポリシーと監査ログは効く。
興味深いのは、Spacelift 自身が守備範囲を明示していることです。「IaC は本番環境には依然として不可欠だが、テスト・プロトタイプ・非クリティカルなワークロードには過剰なオーバーヘッドになる」。つまり Intent は、意図的にミッションクリティカルを避けています。
2. 答え合わせ：LLMはIaCをどれくらい書けるのか
体感ではなく、数字で見ます。
前提：IaC-Eval というベンチマーク
2024年に発表された、IaC 専用のベンチマークです（NeurIPS Datasets & Benchmarks）。
458本の、人手でキュレーションされた AWS シナリオが入っています。各シナリオは2つの要素からなります。
- 自然言語の要件（「S3バケットを作り、暗号化を有効にし、バージョニングを有効にせよ」のような）
- インフラ意図の仕様（Rego で書かれた、機械が判定できる正解条件）
ここが重要です。普通のコード生成ベンチマークは「テストが通るか」で採点しますが、IaC-Eval は 「意図した構成になっているか」を機械で判定できる。この設計のおかげで、次の話ができます。
発表当時、GPT-4 の pass@1 は 19.36% でした。しかも few-shot も chain-of-thought もマルチターンも、改善効果は限定的だったと報告されています。
2026年の大規模再測
Hallucinated Resources, Brittle Oracles, Decoupled Security（2026年6月）という研究が、12ベンダー＋オープンウェイトの計 55モデルを IaC-Eval 全458タスクに掛けました。3回反復で、総評価数 75,570。
パイプラインは4段構えです。
-
構文 —
terraform init / validate / planが通るか - 意図 — OPA/Rego の仕様を満たすか
- セキュリティ — 5つの静的スキャナ＋tflint
- 効率 — トークン数・レイテンシ・コスト
結果は、2つの崖として現れました。
| 段階 | 通過率 |
|---|---|
| そもそもコードが出力された | 約 95% |
terraform validate を通った |
約 49% |
| 意図（OPA）に適合した | 約 20%（全モデル平均） |
第一の崖（-46ポイント）
全実行の 29% が、AWS の Terraform プロバイダのスキーマに存在しない引数名やリソース型を出力していました。いわゆる Unsupported argument エラーです。もっともらしい名前を発明してしまう。
第二の崖（-27ポイント）
型が通り、plan も成功したコードですら、意図に合っているのは約42%。
そして最良のフロンティアモデルでも、意図正答率は50%止まり。458タスクのうち 26%は、55モデルの誰も1本も解けなかった。
数字を素直に読むと、こうなります。
2026年時点で「LLMはIaCを書ける」とは、「半分は文法すら通らず、通ったものの半分は意図と違う」という意味である。
3. 構文は直る。意図は直らない。
「じゃあスキーマ知識を食わせればいいのでは」——当然そう思います。実際、それをやった研究があります。
IaC Generation with LLMs: An Error Taxonomy and A Study on Configuration Knowledge Injection（arXiv:2512.14792）は、素朴な RAG から始めて、Graph RAG、リソース間の依存関係のモデリングへと、構造化された設定知識の注入を段階的に強めていきました。
結果：
| 指標 | 変化 |
|---|---|
| 全体成功率 | 27.1% → 60.4% |
| 技術的バリデーション（構文・スキーマ） | 75.3% まで改善 |
| 意図適合（intent alignment） | 頭打ち（プラトー） |
論文はこう報告しています。技術面が大幅に改善しても、意図の整合には根強い課題が残り、性能はプラトーに達する。
これは重要な発見だと思います。
スキーマ知識を流し込めば、ハルシネーションは減る。だが「決めたことが出力に反映されているか」は、知識を足しても良くならない。
理由を推測するなら、こうなります。
それは知識の欠落ではなく、検証の欠落だから。
モデルは「もっともらしい次のトークン」を出しているだけで、決定が守られたかを誰も検査していない。知識を足しても、検査していないものは直りません。
4. 検査は通る。planも通る。それでも壊れている
もっと直接的な観測があります。TerraProbe（arXiv:2606.26590）です。
セットアップはこうです。Terraform コードに、Checkov がセキュリティ指摘を出している。それを LLM に修正させる。
モデルは IAM ポリシーを再構成します。Checkov の CKV2_AWS_11（Resource にワイルドカードを使うな、という検査）は、発火しなくなります。
ところが——
そのチェックが禁じようとしていた、ワイルドカードによる権限付与は、そのまま生き残っている。
- Checkov：指摘なし
-
terraform plan：成功 - 無制限の権限：残っている
論文はこれを deceptive fix（欺瞞的修正） と名づけ、自動プログラム修復の分野で知られる「オラクル問題」——テストを通ったからといって仕様を満たしているとは限らない——の IaC 版として定式化しています。
Checkov 固有の欠陥、という話ではありません。論文自身が、単一のスキャナの pass/fail 信号だけで修正を検証すると、そのスキャナの盲点をそのまま引き継ぐと述べています。JSON のある位置のワイルドカードには発火する検査が、隣の位置の同じワイルドカードには沈黙する。その隙間を、修正が突く。
さらに、LLM ×ソフトウェア工学の論文395本を系統的にレビューしたところ、「セキュリティ意図との整合」は、この分野で最も研究されていない評価特性の一つだった、という指摘もあります。
まとめると：
「検査が通った」は「決めたことが守られた」ではない。
そして業界は、そこをあまり測っていない。
同じ壁は別の研究（IaCGen / arXiv:2506.05623）でも報告されています。ポリシー単位の通過率は75.3%あるのに、テンプレート全体として完全準拠したものは8.4%。ユーザーの意図を完全に満たしたのは25.2%。 1〜2個の致命的な違反が、テンプレート全体を無効化してしまう閾値効果が働くためです。
5. 論点：「決めたこと」と「出てきたもの」の距離
ここまでの3つを並べます。
- 静的スキャナは、できあがった成果物を、一般的なベストプラクティスに照らす
- LLM は、聞かれなかった値を、黙ってデフォルトで埋める
- スキャナの指摘が消えても、元の意図は生き残っていないことがある
この3つの間に、検査が手薄な領域があります。
「上流で決めた特定の設計判断が、下流の成果物に反映されているか」を機械で確認する層。
論文の用語では intent alignment（意図適合）と呼ばれます。名前は定まっていませんが、問題自体は複数の研究が同じものを指しています。
抽象的なので、具体例で書きます。
例：静かに死ぬ決定
設計レビューで、こう決めたとします。
鍵管理は KMS のカスタマーマネージドキー（CMK）を使う。AWS 管理キーではダメ。監査要件のため。
これを踏まえて、AI に CDK コードを書かせます。出てきたのがこれ：
new s3.Bucket(this, 'DataBucket', {
encryption: s3.BucketEncryption.S3_MANAGED, // ← AWS管理キー
versioned: true,
});
何が起きるか。
| 工程 | 結果 |
|---|---|
cdk-nag |
指摘なし（暗号化「は」されているので） |
cdk synth |
成功 |
| デプロイ | 成功 |
| 設計書 | 「暗号化方式：KMS CMK」と書いてある（誰も突き合わせていない） |
| パラメータシート | 「暗号化方式：KMS CMK」と書いてある（同上） |
すべて通過。そして決定は死んでいます。
これは cdk-nag のバグではない
強調しておきます。cdk-nag は何も間違っていません。
cdk-nag は「暗号化されているか」を検査する道具です。「CMK と決めたかどうか」を、cdk-nag は知りません。知りようがない。その決定は、cdk-nag の入力のどこにも存在しないからです。
そして同じことが、あらゆる軸で起きます。
- CloudFront の PriceClass（コスト vs レイテンシで決めたはず）
- WAF を付けるか付けないか
- ログの保持期間（監査要件で決めたはず）
- 公開範囲（インターネット公開か、社内からのみか）
- マルチAZ にするか
- バックアップの世代数
「決めたこと」と「出てきたもの」を突き合わせる仕組みが、どの層にもありません。
6. 同じ問題に取り組んでいるプロダクト
この論点に気づいて動いているプロダクトも、2026年に入って出てきています。
Mneme HQ
「AI コーディングエージェントに対するアーキテクチャ意図の強制」を掲げています。問題提起が鋭い。
- ADR（Architecture Decision Record）は
docs/adr/に置かれ、AI コーディングエージェント全員に静かに無視されている - ルールファイルやメモリ機能は文脈を与えるが、決定論的な強制の境界を作らない
- エージェントは生成する。ルールは誘導する。メモリは思い出す。RAG は検索する。——Mneme は強制する
彼らが定義する verification contract は、「アーキテクチャ上の意図が、生成やエージェント実行を生き延びたことを証明する、機械評価可能な検査」。
実装としては、Claude Code の PreToolUse フックで Edit/Write を差し込み、ADR 違反の変更を着地する前にブロックします。CI では PR の diff に対して走らせる。
対象はアプリケーションコードの ADR（サービス境界、フレームワーク選定、依存関係のルール）であって、クラウドのパラメータ値ではありません。現状は単一リポジトリ・単独開発者スコープとのこと。
AWS Kiro
公式サイトにこう書いてあります。
「"全テスト通過" は、コードが意図と一致していることを意味しない」
コード生成前に、自動推論で要件の矛盾や欠落をチェックする。そして property-based test（個別の例ではなく、あらゆる入力に対して成り立つべき性質を検査するテスト）で挙動を検証する。
Catio
「Architecture IDE」を名乗り、ADR を稼働中のシステム状態に紐づける記録システムを作っています。
問題設定はこう。ディスク上に置かれた静的なドキュメントには、その決定が今も本番システムと整合しているかを知る術がない。 だから、クエリ可能でドリフト（乖離）を検知できる決定レイヤが要る、と。
7. 手薄な領域の整理
以上を踏まえて、区切ってみます。
| 領域 | 状況 |
|---|---|
| レンダリング後のベストプラクティス適合 | 成熟（cdk-nag / Checkov 等） |
| 自然言語 → プロビジョニング | 登場（Spacelift Intent。非クリティカル限定） |
| アプリコードの ADR 強制 | 登場（Mneme HQ） |
| 仕様 → 実装のトレーサビリティ | 登場（AWS Kiro） |
| ADR と稼働システムの乖離検知 | 登場（Catio） |
| クラウドの「パラメータ値」レベルの意図適合 | 手薄 |
| 設計書・見積・パラメータシートと IaC コードの相互整合 | 手薄 |
| 未解決値をデフォルトで埋めさせない仕組み | 手薄 |
下の3つは、まだあまり誰も見ていない印象です。
特に日本の SI・エンタープライズ案件では、IaC のコードだけが納品物ではありません。基本設計書、システム構成設計書、セキュリティ設計書、パラメータシート、コスト見積——これらが一式で納品され、それらの間の不整合がレビューや監査で問題になります。
「コードは正しいがパラメータシートには違う値が書いてある」は、この文脈では致命的です。そして英語圏のツールは、この納品物の束を見ていません。
8. 明日から使えるかもしれない話
抽象論を実務に落とします。
1. cdk-nag の指摘がゼロでも、決定が守られた証拠にはならない。
cdk-nag は「一般的に安全か」を見ます。「決めた通りか」は見ません。この2つは別の問いです。
2. LLM に IaC を書かせるなら、「決めた値」を機械が読める形で外に出しておく。
プロンプトの中に書いただけでは足りません。意図正答率50%というのは、そういう意味です。決定を構造化データ（YAML / JSON）として持ち、生成後にそれと突き合わせる。プロンプトは「お願い」であって「保証」ではありません。
3. 「スキャナの指摘が消えた」を、修正完了の定義にしない。
deceptive fix は、もう論文になっています。指摘が消えたことと、問題が消えたことは違う。
4. RAG でスキーマ知識を足すのは正しい。だがそれで直るのは構文だけ。
知識注入は「AI が存在しない引数名を発明する」問題には効きますが、「AI が決定を無視する」問題には効きません。
5. 未解決の値を、デフォルトで埋めさせない。
これが一番地味で、一番効く気がしています。
「とりあえず動くデフォルト値」は、意図適合を静かに殺す犯人です。設計レビューでまだ決まっていない値を、AI は平然と「よくある値」で埋めてきます。そして誰も気づきません。動いてしまうからです。
対策は、警告ではなく構造だと思います。未決定の値は、
- 必須パラメータにして、値がなければそもそもデプロイできないようにする
- あるいは「デフォルトで進むという判断をした」ことを、明示的に記録に残す
このどちらかにする。「警告を出したが、誰も読まなかった」は、対策とは呼びにくい。
おわりに
生成AI の IaC 生成は、2026年時点で「構文は改善しつつあるが、意図の忠実性は横ばい」という段階にありそうです。そしてその横ばいは、モデルの性能を上げれば自然に解決する類のものではないかもしれません——そこを測っている検査が、そもそも少ないからです。
最後に、自分のプロジェクトに当てはめてみてください。
半年前の設計レビューで決めたことのうち、いま本番で本当に生きているものは、どれくらいありますか。
そして、それを確かめる方法を、持っていますか。
参考文献・リンク
論文
- IaC-Eval: A Code Generation Benchmark for Cloud Infrastructure-as-Code Programs（NeurIPS D&B 2024）— https://openreview.net/forum?id=7TCK0aBL1C
- Hallucinated Resources, Brittle Oracles, Decoupled Security: An Empirical Study of LLM-Generated Terraform（2026）
- IaC Generation with LLMs: An Error Taxonomy and A Study on Configuration Knowledge Injection — arXiv:2512.14792
- TerraProbe: A Layered-Oracle Framework for Detecting Deceptive Fixes in LLM-Assisted Terraform Security Repair — arXiv:2606.26590
- Deployability-Centric Infrastructure-as-Code Generation (IaCGen) — arXiv:2506.05623
- TerraFormer: Automated IaC with LLMs Fine-Tuned via Policy-Guided Verifier Feedback（ICSE-SEIP 2026）— arXiv:2601.08734
製品・ツール
- cdk-nag — https://github.com/cdklabs/cdk-nag
- Checkov — https://www.checkov.io/
- AWS Kiro — https://kiro.dev/
- Spacelift Intent — https://spacelift.io/intent
- Mneme HQ — https://mnemehq.com/
- Catio — https://www.catio.tech/