属性値が動的計算だと静的監査が破綻する
予測可能性はgraph形状と属性値の両方に効く。運用の現場では「このリソースは具体的にどう設定されているか」をコードから知りたい場面 — インシデント対応、コンプライアンス監査、セキュリティレビュー、IAMポリシー検査、暗号化設定確認 — が頻出し、graph形状だけ見えても属性値が動的計算だらけだと運用上の予測可能性は半減する。
具体的には「全IAM Roleのassume_role_policyを機械的に確認する」「全RDSのstorage_encryptedを検証する」「全S3 Bucketは暗号化必須というpolicy engineルールを効かせる」といった属性値レベルの監査が、動的計算で属性値が決まると成立しなくなる。lint / 型検査 / policy engineが効くかどうかは、AIが読むかどうかとは独立に重要であり続ける。
この問題はgraph形状を変えずとも起きる。tags = compose(f, g, h)(env)のような複雑な合成は、ノード数もidentityも変えないまま属性監査を破綻させうる。したがって「graph形状側の自由度だけ縛れば予測可能性は保たれる」という整理は不十分である。
抽象化境界との関係も重要である。予測可能性軸をgraph形状 + 属性値に拡張したことで、module経由で隠される対象もリソース数/identity/依存関係だけでなく各リソースの属性値に広がった。「全S3 Bucketの暗号化設定をコードから機械的に確認する」ような属性値レベルの監査は、抽象化境界を越えた先まで読みに行く必要がある。
属性値計算の抽象化自由度には、Terraform (組込み関数のみ) < Bicep (funcあり) < Carina (関数合成 + closure) < CDK / Pulumi (高階関数 + クラス継承)という明確な差がある。graph形状側では同列に「言語が決める」と評価される3ツール(Terraform / Bicep / Carina)でも、属性値側では差が出る。
根拠の確度
属性値レベルの動的計算が静的監査をどこまで壊すか — tfsec / checkov相当のコンプライアンス監査・セキュリティスキャンがどこまで成立するか — の経験的検証はされていない。