IaC、エミュレータ、ガードレール

対象本文

第14章のAIが書いたinfrastructure codeを、静的検査、plan、policy、隔離した実cloud、段階配備へ通す道具を補います。特定toolの推薦ではなく、どの証拠をどの関所で得られるかの対応表です。

収集方法

2026年7月10日に、Terraform、AWS SAM/Lambda testing、Google Functions Framework、Azure Functions Core Tools、Cloudflare Wrangler/Miniflare、OPA/Sentinelの公式資料を確認しました。機能数ではなく、localで検証できる範囲と実cloudでしか確かめられない範囲を比較しています。

2026年8月2日の0.10.0では、評価軸「認知負荷をいつ払うか」の段落を追加しました。上表に既収載の道具(CDK、HCL、Bicep、YAML等)を内部DSL型/外部DSL型として分類し、記述と宣言の関係、plan・policyの判定対象という仕組み上の違いだけを述べます。認知負荷の軽重という効果は、チーム・道具・規模に依存するため主張せず、段落内と既知の未知で未検証と明示します。新しい道具、製品事実、数値、一次資料は導入していないため、last_verifiedは2026年7月10日の一次資料照合日のまま据え置きます(次回確認はnext_reviewどおり)。

現在の答え

関所代表的な道具得られる証拠得られない証拠
format/schemaTerraform/OpenTofu validate、CloudFormation validate、Bicep build、Wrangler typessyntax、type、参照の一部providerの実挙動、quota、権限の完全性
unit/testTerraform test、CDK assertions、Functions Framework、handler unit testmodule出力、business logic、event変換managed integration、service identity、network path
local runtimeSAM CLI、Functions Core Tools、Functions Framework、Miniflare、LocalStack等runtime互換、handler、代表event、開発速度production IAM、control plane、全API、scale、billing
plan/diffTerraform plan、CloudFormation change set、Bicep what-if、provider preview変更対象、replacement、主要attributeapply時race、quota、外部状態、runtime data migration
policyOPA/Conftest、Sentinel、organization policy、cloud-native policypublic設定、region、tag、許可resource等の機械判定business intent、runtime prompt/tool behavior
disposable cloud専用account/project/subscriptionでapplyとintegration test実IAM、service integration、quota、network、provider APIproduction data量、実traffic、全障害条件
rolloutalias/revision/deploymentと監視新旧比較、停止、rollback証拠作用済み結果の自動補償

共通方向は、infrastructureを宣言へし、変更前に差分とpolicyを機械判定し、隔離した環境で実serviceの挙動を確かめることです。差は、provider-nativeな宣言とmulti-cloud IaC、local emulatorとreal cloud、admission-time policyとruntime detectionのどこを正本にするかです。

もう一つの評価軸は、認知負荷をいつ払うかという問いです。汎用言語で書く内部DSL型(CDKなどのprogramming model)は、既存言語の抽象と道具立てで記述し、宣言はそこから生成されます。宣言的な外部DSL型(HCL、Bicep、YAML)は、記述の自由度を絞り、plan差分とpolicy判定は宣言そのものを対象にします。どちらの負荷が軽いかはチームの習熟、道具、対象規模に依存し、本表では検証していません。AIがIaCを書く場合、この軸は「モデルが書きやすい形か」と「人間とpolicyが検査しやすい形か」という問いの対になります。どちらの型でも、関所で得る証拠(plan、policy結果、承認)の要件は変わりません。

AWS Lambdaのtesting guideは、local emulationがidentity、managed integration、quotaを完全には検証しないことを明示し、cloud-based integration testを推奨します。この限界は他社にも通じます。emulatorの成功を「本番と同じ」の証拠にせず、速いfeedbackの証拠として使います。

AIが生成したIaCには、生成者とは別の決定主体が必要です。最低限、使用provider/versionの固定、plan artifact、policy結果、承認者、対象environment、apply結果、drift、rollbackをrelease_idへ結びます。agentにapply権限を直接渡す場合も、承認済みplan digestと短命credentialへ限定します。

一次資料

既知の未知

変更履歴