IaCで高階関数は「あれば嬉しいが必須ではない」かもしれない
ハイブリッド象限への合流は構造的整合性の議論であって、ユーザの実需要とは別の問題である。実需要の観点から見ると、IaCで高階関数は「あれば嬉しいが必須ではない」機能かもしれない。
高階関数なしで十分かもしれない根拠
- Bicepが意図的に入れていない: Microsoft設計で、
funcのみを持ち高階関数は仕様にない。それでもAzureのIaCとして広く使われている - Terraformが14年高階関数なしで運用:
for_each/dynamicで大半の用途を満たしている - CDK / Pulumiの高階関数活用は実は限定的:命名関数や
mapでループする程度で、Constructを関数で渡す/返すパターンは現場では稀
IaCで実際に必要な抽象化
- 値計算の再利用:命名規則 / 環境別パラメタ →
fnで十分 - 構成のテンプレート化: VPC + Subnet × N + IGWのセット → moduleで十分
- 多数生成: multi-region展開 / リスト要素ごと →
for式で十分
この三つでIaCの現実的な用途はカバーできる可能性が高い。IaCが本当に必要とする再利用は検証済みパターンのパラメータ付き合成であって任意計算ではなく、それはモジュール・for・exportsという有界な合成手段で足りる。汎用言語に人が求める「表現力」の実態の多くは繰り返しの除去であり、チューリング完全性はそれに対して過剰である。
取りうる立場
- A.入れない(Bicep路線): 「IaCでは値計算と構成テンプレート化で十分」と割り切る。Bicep成功の経験的裏付けあり
- B.入れる(KCL路線):構造的に5DSLと整合し、長期的な拡張余地がある。ただし大改修コスト
- C.保留:現状の
fn+ 関数合成で実需要を観察し、ユーザから具体ユースケースが出てきたら検討
実験的プロジェクトという位置づけからは、A / CよりB(積極導入)の方が学びが多い。境界設計はgraph出力DSLでは先行例がない領域なので、新しい設計象限の実証として価値が高い。「IaCで本当に必要か」の答えは入れてみないと分からない。