notes mizzy.org

IaC言語の意味的本体はリソース定義と依存グラフだけである

規範的主張 出典: explorations/2026-06-10-carina-type-system-type-theory/design-position.md §1 作成

IaC言語の意味的本体は、リソースの定義と、その依存関係グラフである。それ以外のすべての言語機能は、あれば便利という程度のものにすぎない。

この一文が設計上の立場全体の起点になる。関数、モジュール、ループ、補間といった機構は、それ自体が言語の目的ではなく、グラフを書き下すための便宜でしかない。だから機能の追加可否は「便利か」ではなく「グラフに還元されるか」で判定される(言語機能はグラフへ消える糖衣である限りで許される)。

ただし「依存関係グラフの記述」には精密化が要る。エッジの大半はユーザーが明示するのではなく、値の参照(vpc.vpc_id)から推論される。つまり言語がユーザーに記述させるのは「グラフそのもの」ではなく「グラフが一意に定まるだけの情報」である。ユーザーはノードを宣言し、他ノードの属性を参照する。エッジはその参照から導出される。

ユーザーが書くもの ノードの宣言と、他ノードの属性への参照だけ resource vpc "main" { cidr = "10.0.0.0/16" } resource subnet "app" { vpc_id = vpc.main.vpc_id az = "ap-northeast-1a" } resource instance "web" { subnet_id = subnet.app.id ami = "ami-0c1d" } エッジを書く構文はない。 書いてあるのは「グラフが一意に定まるだけの情報」。 参照から エッジを導出 導出されたエッジ subnet.app → vpc.main instance.web → subnet.app 参照1本につきエッジ1本 意味的本体 vpc.main subnet.app instance.web 関数・モジュール・ループは 左端をノードの並びへ 展開するだけで、 ここには残らない
ソースからグラフへの経路には導出が一段挟まっている。ユーザーが宣言するのはノードと参照で、エッジはその参照が置かれた位置から機械的に決まる。

この立場を採ると、いくつかの派生的な性質が説明として自動的に出てくる。型を付けるべき「プログラム」が実質存在しないため、型検査は項ベースの体系をほぼ必要とせず、検査対象はグラフそのもの — ノード上の値の所属とエッジ両端の型の適合 — に還元される。汎用言語が提供する高階関数・クラス・任意計算とパッケージエコシステムは、「失ったもの」ではなく「このドメインでは要らないもの」として数えられる。

#設計原則 #iac #グラフ