LLMとTypescriptって実は相性悪いよねって話

2025-07-24

今時点の使えそうな Sonnet4 を使ってコード生成とか業務でやる時に Typescript は案外うまくいかないことが多い。

UIとかシンプルなものであれば結構うまくいくけど、graphql, prisma みたいなところになると、token数すごくなるし結局完成しない。

この辺りが、なんとも小骨がひっかかるから。Typescriptの型ってやっぱりあれなのかと思って調べてもらったんだ。

↓↓↓↓↓↓↓

Web上の専門的な議論や論文では、TypeScriptの課題は主に以下の3点に集約されます。これらはすべて、JavaScriptという土台との不適合性に起因するものです。

1. 不健全な型システム (Unsound Type System)

ソフトウェア工学において、型システムの**「健全性（Soundness）」**とは、「コンパイル時に型エラーがなかったプログラムは、実行時に型エラーを起こさない」という保証を指します。

具体的な不健全さ:

配列の扱い: string 型の変数に (string | number) 型の配列を代入できてしまうなど、配列の扱いに不健全な部分があります。これが原因で、実行時に数値を取り出してしまい、string型のメソッドを呼び出してエラーになる、といったことが起こり得ます。

any型と型アサーション: any型の存在や、開発者がコンパイラに「これはこの型で間違いない」と強制する型アサーション（as構文）は、健全性を根本から破壊する「抜け道」です。

関数の引数（Bivariance）: 関数の引数の型チェックが、他の多くの言語（反変）とは異なり、より緩いルール（双変）になっています。これも実用性を優先した結果、理論的な正しさを犠牲にしている例です。

学術的な観点では、この「不健全さ」はTypeScriptの型システムが持つ最大の弱点と見なされています。

2. 構造的部分型（Structural Typing）の罠

TypeScriptは、クラス名などによらず「構造が同じなら同じ型」とみなす構造的部分型を採用しています。これはダックタイピングが主流のJavaScript 文化に合わせた賢い選択ですが、ソフトウェア工学的にはいくつかの罠があります。

意図しない互換性: 全く異なる目的で作られた二つのオブジェクトが、偶然同じ構造を持っていたために、型チェックをパスしてしまうことがあります。これにより、ドメイン（業務領域）の意図とは無関係にコードが結合してしまい、予期せぬバグを生む原因となります。

過剰なプロパティの許容: const config: { port: number } = { port: 8080, host: 'localhost' }; のように、変数経由で代入すると、型に定義されていない余分なプロパティ（host）がエラーになりません。これは仕様ですが、開発者の意図しないデータが紛れ込むことを許容してしまい、セキュリティやバグのリスクに繋がります。

これは「TypeScriptの型は、データの『形状』を記述するが、その『意味』や『文脈』を保証しない」という根本的な限界を示しています。

3. 「漏れのある抽象化（Leaky Abstraction）」としての本質

Joel Spolskyが提唱した「漏れのある抽象化の法則」に倣えば、TypeScriptはまさにその典型例です。

TypeScriptは「静的型付け」という抽象化レイヤーを提供しますが、開発者は常にその下にあるJavaScriptの泥臭い現実（undefined, null, thisの挙動など）を意識し続けなければなりません。

抽象化の不徹底: 型を書いているときも、最終的にそれがundefinedになりうることや、thisが何を指すかを常に考えなければなりません。抽象化レイヤーが、下位レイヤーの詳細を隠蔽しきれていないのです。

摩擦コスト: この「漏れ」が、これまで議論してきた「Union地獄」や「境界での型変換の手間」といった、開発上の継続的な摩擦コストを生み出しています。

TypeScriptの課題は、個別の機能の優劣ではなく、「健全性を犠牲にしてでも、JavaScriptという動的な土台との互換性を最優先した」という、その成り立ちそのものにあります。その結果として生じる「不健全さ」「構造的部分型の罠」「漏れのある抽象化」といった問題は、この言語を使い続ける限り、アーキテクトが向き合い続けなければならない、本質的なトレードオフなのです。