providerを増やすのは対応範囲の拡大ではなく、モデルへの反例探しである
CarinaはAWSを中心に実装してきたので、コアの型(とくにcreate結果の型)がAWS固有の前提に寄っていないかは分からない。GitHubとCloudflareのproviderを書くのは、使える範囲を広げるためではなく、AWSで作った抽象が他のサービスでも成り立つかを確かめるためである。
型でproviderの裁量を絞る設計では、これが避けて通れない。providerが自由にstateを書けるなら、サービス固有の妙な振る舞いはprovider内部で吸収されて表に出ない。裁量が無いと、型が用意していない状況はそのまま型の問題として表に出る。Terraformはproviderに裁量を渡し、Carinaは型で取り上げる
反例に出会ったときの三つの行き先
- 既存の型で表せるAWSで作った抽象が他でも通用した証拠になる。
- 型を広げる必要がある抽象が足りなかった場所が見つかった。モデルを直す。
- provider固有の処理として閉じるべきだと分かるコアが責任を持つ範囲の境界が引き直される。
3が一番情報量が多い。providerの裁量を減らすことは、すべての振る舞いをコアで決めることではない。APIごとのリトライ条件やリソース固有の更新制約まではコアが知らなくてよい。一方で「createの結果が分からないときstateをどう扱うか」は、サービスによらず揃えたい。サービスに依らない不変条件と、サービス固有の振る舞いの境界を見つける作業になる。createの失敗は「外部世界について何が分かっているか」で分ける
評価の基準
コアの型をどれだけ変えたか、の量では測れない。既存の型に無理に押し込めば変更は少なく見えるが、provider内部に不自然な処理が溜まる。逆に型を変えて、より単純で一般的なモデルに着けば前進である。見るべきは、新しいサービスに当たるたびにモデルが単純になっていくのか、例外が積み重なっていくのかである。
当たりそうな場所の見当(未検証):
- GitHub: 名前が識別子を兼ねる(リポジトリのrename、削除直後に同名で作り直せない)。identityの規則が試される。identityは「何を同一資源と見なすか」の規則であり、stateとは独立軸である
- Cloudflare: DNSレコードのように、同じ内容のものが複数存在しうる。createがタイムアウトしたとき、名前と内容だけで「作られたか」を判定できるかが試される
共通の失敗試験
反例探しを偶然に任せないなら、provider固有の知識を外した共通の試験が要る。「createは成功したが直後のreadが失敗する」「送信後に応答が失われる」「識別子だけが返る」といった状況を、全providerに同じ形で注入して、型が約束している性質を各providerが満たすかを見る。これはproviderの試験ではなく、実行モデルの試験になる。
根拠の確度
GitHub / Cloudflare providerをモデル検証のために書いているという動機は本人の発言による。carina-rs/carina-provider-githubが存在することは確認した(2026-05-28作成)。三つの行き先、評価の基準、共通試験の案はChatGPTとの対話で出たもので、まだ実装も検証もしていない。GitHubとCloudflareで当たりそうな場所は推測で、各APIの仕様では確認していない(要確認)。