抽象化境界の透明性は記述自由度とは独立した軸である
記述自由度から導かれる予測可能性の議論は、すべて「抽象化を経由していない範囲」に限定される。Terraform / Carinaのmodule、CDK Construct、Pulumi Componentのいずれかを呼び出した瞬間、呼び出し側からは中身が見えなくなる — リソース数・identity・依存関係、そして各ノードの属性値も。
抽象化境界の透明性は、記述言語や記述自由度の所在ではなく「呼び出し側がどれだけ中身を読みに行く必要があるか」で決まる独立した軸であり、各ツールのドキュメント文化・テスト文化・preview UIが補う部分である。
予測可能性の軸を属性値まで広げたことで、module経由で隠される対象も広がった。「全S3 Bucketの暗号化設定をコードから機械的に確認」のような属性値レベルの監査は、抽象化境界を越えた先まで読みに行く必要がある。生成AIの文脈ではこれが射程条件になる: AIがmodule中身までコンテキストに入れないと修正できない場合、透明性の低い抽象化はAI検証性・plan精度・静的監査の前提条件を毀損する。透明性は予測可能性の内実ではなく、AI時代の議論を成立させる射程条件である。
構文設計が透明性に効きうる、という仮説的観察もある。use式とインスタンス化の分離、同一templateからの複数インスタンス化、use式のlet RHS限定といった設計は、moduleの境界を構文レベルで明示する性質を持ち、汎用言語のnew SomeConstruct(scope, 'id', props)という慣習より境界管理を明示しやすい可能性がある。ただし構文レベルでの明示性は、呼び出し側透明性そのものを自動では保証しない。module中身を読まずに呼び出し側だけでgraph形状 / 属性値を予測できるかは、依然としてmodule設計者のドキュメント文化・テスト文化・型情報の充実度に依存する。
根拠の確度
構文設計が透明性を促すという後段は仮説であり、経験的検証を経ていない。