【ITニュース解説】AI coding agents and Theo's Rust TypeScript compiler: the caveats

Theo Browne氏が、TypeScriptコードを処理する新しいコンパイラ「tsc-rs」を開発したことを発表した。このコンパイラは、マイクロソフトがGo言語で実装した既存のTypeScriptコンパイラをRust言語に移植したもので、AIコーディングエージェントがその開発に大きく貢献した点が特徴である。一部の処理速度において大幅な改善が見られ、特に型チェックに時間がかかっていた開発者にとって注目すべきプロジェクトだ。しかし、この技術を実用する上では、いくつかの注意点も存在する。

AIコーディングエージェントが「tsc-rs」の開発において具体的にどのような役割を果たしたのかを理解することが重要だ。このプロジェクトは、既存のGo言語で書かれたマイクロソフトのTypeScriptコンパイラの設計、アルゴリズム、テストをRustにそのまま移植することを目的としていた。つまり、AIは完全にゼロから新しいコンパイラを生み出したわけではない。既に存在する、振る舞いやテストが明確に定義されたGo言語のコードを「翻訳」する作業を担ったのである。これにより、AIは既存の膨大なテストケースを使って、自分が生成したRustコードが元のGoコードと同じように動作するかを確認できた。Theo氏が「ゼロから始めた」と語ったのは、以前のRustによる試みを置き換えたという意味であり、Go言語のコンパイラが依然として基準として機能した。リポジトリでは、Go言語版のテストを18万件以上パスし、主要なプロジェクトで診断結果が元のコンパイラと一致すると報告されており、AIがこの特定の、詳細な参照のある問題に対して効果的に機能したことを示している。

AIの利用コストについても、注意深く評価する必要がある。Theo氏の発表では、以前のGPTを使った試みに40万ドル以上、今回のOpusによる作業に約2.4万ドル相当の「トークン利用」があったとされている。しかし、これらはAPIのトークン価格に基づいた推定であり、実際にTheo氏が支払った費用は、Claudeのサブスクリプションを通じて行われたため、金額の計算方法が異なる可能性がある。重要なのは、AIによる最初の実装は比較的短期間（Opusでは10時間）で可能だったとしても、その後のコードの検証、修正、微調整にはさらに多くの時間（2週間）とリソースが必要だったという点だ。AIを活用するチームは、最初の動くバージョンができるまでの時間と、実際にリリースできる品質になるまでの時間を区別し、また支払った費用と消費されたリソース（トークン量など）を分けて考える必要がある。

「tsc-rs」の速度に関するベンチマーク結果を読み解く際にも、比較の条件を理解することが不可欠だ。発表されている「12.5倍高速」という数字は、特定のシナリオ、すなわちT3 CodeというプロジェクトでEffect診断を有効にし、TypeScript 6と古いEffect言語サービスプラグインと比較した場合に得られたものである。Go言語版のTypeScript 7（Effect診断有効）との比較では、速度向上は約1.89倍にとどまる。さらに、Effect診断を無効にした場合、Bunという別のツールが「tsc-rs」よりも高速な結果を示している。これらの測定はM4 Pro Mac上で、いくつかの特定の条件（インクリメンタルチェック無効、特定のヒープ割り当てなど）のもとで行われている。また、公開されているプレビュー版のバイナリは、ベンチマークで使用された最適化（PGOやBOLT）が適用されていない可能性があり、ダウンロードして試した結果が発表された数字と異なることもあり得る。そのため、ベンチマーク結果を評価する際は、比較対象、診断設定、使用されたハードウェア、ビルド設定といった具体的な条件を常に確認する必要がある。

互換性も「tsc-rs」を導入する上で確認すべき重要なポイントである。現在のREADMEファイルでは9月29日のTypeScript上流リビジョンへの追従が推奨されているが、上流のツールチェインのデフォルトは6月のリビジョンを指しているという不一致が指摘されている。このバージョン間の不一致は、コンパイラの振る舞いや診断結果の違いを引き起こす可能性があるため、実際に使用する際には、どのTypeScriptリビジョンに基づいているのかを確認することが重要だ。また、サポートされるプラットフォームは現在Linux x64とmacOS arm64に限られており、WindowsやLinux arm64は利用できない。モノレポ環境でのルートディレクトリに関する診断エラーや、一部のビルドにおける出力の問題、エディタでの繰り返しの編集作業中にメモリ使用量が増加するなどの既知の問題も報告されている。これらの問題は、小規模なアプリケーションでのテストでは顕在化しない場合があるため、本格的な導入を検討する際には、既存のチェッカーと並行して「tsc-rs」を実行し、診断結果やビルドの出力、エディタでの挙動などを注意深く比較検討する包括的なテストが推奨される。

「tsc-rs」はWebAssembly（WASM）としてビルドし、ブラウザ上で実行する可能性も秘めている。これにより、型チェックの処理をサーバー側ではなくユーザーのブラウザ側で行うことで、サーバーの負荷を軽減できる可能性がある。WASMモジュールのサイズは約4.2MB（圧縮後1.5MB）と報告されており、ブラウザでの使用にはWeb Workerによるシングルスレッドでの実行が推奨されている。しかし、このWASM版には監視モードやネイティブのLSP（Language Server Protocol）機能など、いくつかの機能的な制限がある。したがって、ブラウザでの展開を検討する際には、必要な機能がWASM版で提供されているかを個別に確認する必要がある。サーバー負荷軽減の効果についても、実際に製品に導入し、その効果を測定することが次のステップとなる。

最終的な評価は「要レビュー」である。このプロジェクトの速度に関する主張は、同バージョンの既存コンパイラとの公平な比較検証を必要とする。さらに、プロジェクトの長期的な維持管理についても考慮が必要だ。マイクロソフトのTypeScriptコンパイラは今後も進化し続けるため、「tsc-rs」のようなダウンストリームの移植版には、その変更を継続的に追跡し、発生する可能性のある問題を調査し、今後のリリースをレビューする責任者が不可欠である。この継続的なメンテナンスパスの確保は、実際に動作している既存のコンパイラを置き換える前に、最も重要な採用基準の一つとなるだろう。プラットフォームサポート、診断の正確性、そしてメンテナンスの責任体制のいずれが、プロジェクト導入の障壁となるか、検討する価値がある。

この新しいコンパイラ技術は、AIの活用、速度向上、WASMとしての可能性など、多くの魅力的な側面を持っている。しかし、その導入には、ベンチマークの条件理解、互換性の詳細な検証、そして継続的なメンテナンス体制の確保といった、実用上の課題を慎重に評価する必要がある。