ツールの限界は出自を四層に分けないと解消手段を取り違える
「Terraformの限界はHCLに起因する」という仮説は部分的に正しいが不十分である。限界は単一原因ではなく、出自の違う四つの層が重なっている。層を分けないと、解消手段の見積もりを丸ごと間違える。
| 層 | 内容 | 解消手段 |
|---|---|---|
| 言語起因 | 型の表現力、参照モデル、モジュール境界 | DSLを作り直す |
| アーキテクチャ起因 | planの扱い方、state操作、schema語彙 | 別実装で設計思想ごと変える |
| 組織的優先順位起因 | 開発元が触らなかった制約 | Forkで解禁できる |
| 本質的制約 | リソース作成後にしか決まらない値、ブートストラップ | どの設計でも残る |
分けると何が言えるようになるか
四層に分けると、各ツールがどこまで届くかが構造的に決まる。
OpenTofuはForkの到達範囲を実証した事例として読める。変数の早期評価(backendやmoduleのsourceで変数を使える)、state暗号化の言語組み込み、provider iterationはいずれも組織的優先順位起因の制約であり、Forkで解禁できた。一方でHCLとプロトコルの根本は動いていない。Fork元互換が進化の上限を決める、というのが四層で見たときの読みである。
逆に、言語起因とアーキテクチャ起因の両方を同時に外そうとすれば、DSLも実行モデルも作り直すしかない。Carinaの位置取りはそこにある — schemaの型語彙を豊かにし、planを型付き値として同一プロセス内で加工し、state操作を単一の加工関数に統一する、というのは二層をまたいだ設計変更である。OpenTofuでは到達できない領域というのは、対抗心の表明ではなく層の話である。
そして最下層は誰も外せない。リソースを作る前には決まらない値があり、最初の一つを作るためのブートストラップが要る。段階を跨ぐ未知値の扱いが設計の焦点になり続けるのは、それが本質的制約の層にあるからで、どの設計を選んでも消えない。
帰属を間違えたときの症状
層の帰属は実際に間違えられる。この四層自体、当初は「商業・政治起因」という層を含んでいた。開発元が意図的に制約を課したという証拠は公開されていないため、根拠のある言い方は「組織的優先順位起因」に留まる。意図の帰属は検証できないが、優先順位の帰属は行動から読めるという差である。
帰属を間違えると、解消手段の見積もりが狂う。本質的制約を言語起因と読めば「作り直せば解決する」という誤った期待が立ち、逆に組織的優先順位起因を本質的制約と読めば、Forkで済むものを新実装で解こうとすることになる。