未解決の問い
これらの探索で答えが出なかった問いの一覧。概念ノートではなく、次に調べるべきことのリストである。既に解決したものは各概念ノートに事実として書かれているのでここには含まない。
高階関数と境界設計
- 境界設計の技術的成立性:高階関数を入れたとき、関数値がresource生成位置・module選択位置・identity決定位置に到達しない型/文法/評価制約は実装可能か。graph形状の静的予測可能性を保つ条件として成立するか
- unknown値と高階関数の相互作用:関数引数/戻り値を流れるdeferred値をどう扱うか
- identityの安定性:高階関数経由で生成されるanonymous resourceの自動命名は安定するか
- plan表示:高階関数を経由した展開を予測可能な形で見せるUI設計(graph形状側 / 属性値側とも)
- 「IaCで高階関数は実需要があるか」の経験的検証:入れた後でユーザがどう使うかの観察
AI時代の予測可能性
- 属性値レベルの動的計算が静的監査に与える影響の経験的検証:高階関数経由で属性値計算が複雑化したとき、コンプライアンス監査 / セキュリティスキャン(tfsec, checkov相当)がどこまで成立するか
- 生成AIが動的構造を持つIaCコードでどの程度誤読・誤修正するか: AI時代の予測可能性議論を支える経験的根拠の収集(LLMベンチマーク、実運用事故の事例分析)。属性値レベルの動的計算とgraph形状レベルの動的計算でAI誤読率が異なるかも論点
- 「人前提」と「AI自律apply前提」の予測可能性要件の差:同方向と整理したが、AI自律でapplyまで完結する場合に追加の要件(より強い不変条件、例えばapply前のrollback可能性)が要るか
- 抽象化境界の透明性と構文設計の関係: 「
use+ インスタンス化分離は境界管理を明示しやすいが、呼び出し側透明性そのものは保証しない」という仮説の経験的検証。実プロジェクトでのmodule設計プラクティス・ドキュメント文化・型情報充実度との相互作用を観察する必要がある
DSL横断分析の残り
- 11 DSLの属性値計算自由度の再評価: cross-DSL分析の3自由度評価はgraph形状側に偏っている。Pkl / KCL / Dhall / Jsonnet / Nickelなど構成データ出力DSLは属性値計算が主用途なので、属性値自由度で見ると評価が変わる可能性がある
- Pklの構成データ計算vs IaCのresource graph:軸の読み替え(graph形状 → 最終value形状)が元の前提を緩めることになる
- Crossplaneの二層構造の評価: function言語選択は「設計判断」というより「ユーザの実装選択」で、3自由度の枠組みとレイヤが違う
- lazy評価の影響: Jsonnet / Nickel / Dhallのlazy性が「複数量の制御」「実装の切替」のセマンティクスに与える影響は未検証
- Pulumi MLCとの比較: MLC (multi-language components)はcross-DSL分析で扱わなかった(CDKのjsiiと同じ「単一原本からの自動bridging」軸)
型システムの形式化
- 変性(共変・反変)の明示:
List<T>/Map<K,V>の変性がコード上に書かれていない。「実装が何を選んでいるか」は変性は書かれていないだけで、既に決まっているで確認した(全て共変。Mapはキーも共変)ので、残る問いは書き戻しが入る場面があるかの点検と、変性を型の側に書く方法である - 「未確定」四表現の統合可否: deferred / 識別なしカスタム型 / Unknown / 注釈側の未知型の意味論を一枚に整理したとき、どれとどれが同じものか。「未確定」を表す表現が四つあるのは漸進的型付けの境界が引けていない徴候である
- 構造体の「開いた」様式の設計: プロバイダのスキーマ進化に耐えるため、どの構造体が未知フィールドを受けるかを型で宣言できるようにするか。構造体を封印すると打ち間違いは捕まるがスキーマ進化に弱くなる
is_assignable_toと注釈側の互換判定の統合方法: 一方を他方の薄いラッパーにするか、共通の正規化型を挟むか
型・schema・unknown (章3)
- Pulumi schemaの表現力: enum / oneOf / refinementの扱い、provider間の差
- CDKのjsiiでTS型をPython/Java/Goにbridgingする時の精度:型情報の損失があるか
state (章4)
- Carinaのstate v3の詳細: binding/dependency_bindingsの意味、state CLI、手動編集機構、refresh機構の有無
- Pulumi serviceの運用責任範囲:具体的に何をPulumi社が担うか
- CFN drift detectionの精度と限界
terraform state rm後のresource復元方法、pulumi state delete後の復元方法- multi-region / multi-account state設計
- secret値がstateにどう保存されるか: Pulumi secret機構との接続
identity (章5)
- CDKの
cdk refactorの存在と機能範囲 - Pulumiの
aliasesの使い方詳細 - Carinaの
moved相当機構の有無(carina#2194の進捗。機能点検では実装済みと記録されているが、章5の概観表では未確認のまま) - CDKで「Construct構造を変えると論理IDが変わる」の具体例とその回避策
- multi-stack / multi-environmentでのidentity設計
world取得の高速化
これらは「実装・実測をしていない設計アイデア」全体が未検証である。特に:
- awsccのCloud Control API由来の一様な同定子が、変更フィードとstateの対応づけを構造的に易しくするか(未検証だが、検証する価値が高いと評価されている)
- AWS Config / EventBridgeの配信遅延と欠落の実際の程度
- 排他所有の宣言をIAM / SCPで裏づけたとき、どこまで「読まなくてよい」を証明できるか