Cloudflareは2026年10月20日、VoidZeroおよびOwner.comのMax Schwenk氏と共同で、TypeScriptコンパイラをRustへ移植するプロジェクト「tsrs」を進めると発表した。JavaScript開発ツール群「Oxc」の一部として開発し、プログラムの型に矛盾がないかを調べる「型検査」の高速化を目指す。同社の初期ベンチマークでは、型検査を分担するワーカー数をそろえた条件で、TypeScript 7.0と比較して最大8倍の高速化と約70%のメモリ使用量削減を達成したという。
この取り組みの背景には、AIエージェントによるソフトウェア開発の普及がある。AIエージェントがコードの生成と修正を繰り返す環境では、そのたびに型検査を実行する必要があり、処理時間だけでなくメモリ消費も大きな負担となる。さらに、限られたメモリで動く環境やブラウザー内でも型検査を利用できれば、開発ツールの活用範囲も広がる。Cloudflareの発表と開発者の記録からは、単にプログラミング言語をRustに置き換えるだけでなく、型情報の生成や保持の仕組みそのものを見直すことで、速度とメモリ効率の両立を図っていることが分かる。
TypeScript 7.0比で最大8倍、ただし比較条件には注意が必要
Cloudflareが発表した最大8倍の高速化と約70%のメモリ削減は、同社による初期ベンチマークの結果だ。比較対象はTypeScript 7.0で、型検査に使用するワーカー数を同じにそろえて測定している。ワーカーを増やせば処理を並列化して高速化できる一方、それぞれがメモリを消費するため、実行条件によって性能とメモリ使用量の関係は変わる。特に、標準の適応的な設定では追加のメモリを使って処理を高速化するため、ワーカー数やメモリ設定の違いを無視して速度だけを比較することはできない。
比較対象となるTypeScript自体も改良が続いている。Cloudflareによると、TypeScript 7.1 betaは7.0と比べて最大2.5倍高速化しており、その一部にはtsrsで開発された最適化も取り込まれているという。つまり、Rust版とGo版の性能差が固定されているわけではなく、tsrsで得られた改善をTypeScriptのGo実装へ反映する動きも始まっている。今回の性能差は、あくまで特定のバージョンと設定における測定結果として捉える必要がある。
再現性の確保に向けた仕組みも整備されている。10月24日時点のベンチマーク用ドキュメントでは、測定対象プロジェクトのコミット、設定、コンパイラのハッシュ値などを記録する手順が定められている。CI環境では8仮想CPUと4ワーカーを使用し、ファイル出力と増分処理を無効にしたうえで、3回のウォームアップと10回の測定を行う。ただし、保存されている結果表やグラフについては、新しい実測データで更新されるまでは過去の測定結果であると明記されている。この手順が整備されていることをもって、発表時の最大8倍という性能差が独立して再現されたと判断することはできない。
37,000ファイルの型検査に19 GiB、Rust移植だけでは解決しなかったメモリ問題
今回の開発を主導するMax Schwenk氏は、Owner.comにおける大規模TypeScriptプロジェクトの運用経験をもとに、メモリ効率を改善する必要性を説明している。同氏が10月19日に公開した開発記録によると、Owner.comでは約37,000ファイルを単一のプログラムとして型検査していた。TypeScript 7.0を単一スレッドで実行すると、メモリ使用量は19 GiB、所要時間は80秒に達していたという。複数のAIエージェントがそれぞれ型検査を実行する環境では、1回の検査時間だけでなく、同時に何件の検証を実行できるかも問題になる。
当初のRust移植版はGo版より高速だったものの、メモリ使用量はかえって増加したという。プログラミング言語をRustに変更するだけでは、目標としていた省メモリ化を達成できなかったのだ。そこで開発チームは、型検査中に生成するデータの量や、それをメモリに保持する期間を見直した。
重要な改善の一つが、型のメンバー情報を必要になった段階で解決する仕組みだ。TypeScriptの型にはプロパティなどのメンバー情報が含まれるが、これらを最初からすべて構築すると、実際の検査では参照されない情報までメモリに保持することになる。tsrsでは、検査処理が実際に参照したメンバーについてのみ、具体的な型情報を構築する方式を採用した。必要になるまで計算を遅らせることで、使われない型情報の生成と保持を避けている。
さらに、データ構造の配置を見直して個々の情報が占めるメモリを減らすとともに、型検査が終わった葉ファイルの情報を解放する仕組みも導入した。これは、メモリに保存するデータ自体を小さくするだけでなく、不要になった情報をできるだけ長く保持しないための工夫だ。処理を高速な言語で書き直すことに加え、どの情報をいつ生成し、どの時点まで保持する必要があるのかを見直したことが、省メモリ化につながっている。
並列処理にも改善の余地があった。型検査を担当する各ワーカーは、型同士の関係を表す型グラフを保持するため、ワーカー数を増やすと共通の依存先に関する情報を重複して保存しやすくなる。そこでtsrsでは、同じ依存先を利用するファイルをできるだけ同一のワーカーに割り当て、重複を抑える工夫を加えた。単純に処理を細かく分割してワーカーを増やすだけでは、速度が向上してもメモリ使用量が増える可能性があるため、並列化とメモリ効率を一体で設計している。
ただし、Schwenk氏が示した個々の改善効果を、そのまま合算して全体の削減率を求めることはできない。A/Bテストによって使用したバージョンやマシンが異なるためだ。それでも、最初のRust移植版から型情報の生成方法やデータの保持方法を改良し、メモリ使用量を削減してきた経緯は確認できる。型検査1回あたりのメモリ使用量が減れば、限られたメモリ容量の環境でも複数の検証を同時に実行しやすくなる。ただし、実際に同時実行できるAIエージェント数がどれだけ増えるかについて、具体的な実証結果は示されていない。
Rust採用のもう一つの理由は、ブラウザーで動作するWebAssemblyへの対応
CloudflareはRustを採用した理由として、メモリ管理の仕組みに加え、WebAssembly（Wasm）との相性を挙げている。GoでもWasmへのコンパイルは可能だが、Cloudflareはガベージコレクターなどを実行環境に含める必要がある点を指摘している。目標はネイティブ環境での型検査を高速化することだけではなく、ブラウザーなど、より多様な環境でTypeScriptコンパイラを実行できるようにすることにもある。
10月24日時点のWasmパッケージのドキュメントによると、tsrsのWasm版はネイティブ版と共通のRustコードをwasm32-wasip1向けにコンパイルしたものだ。ブラウザーではメモリ上に用意したファイルを読み込んで型検査を行うことができ、JavaScriptコード、型宣言ファイル、ソースマップなどの出力にも対応している。TypeScriptの標準ライブラリも同梱されており、ブラウザー内のコードエディターに型検査機能を組み込むための基盤として利用できる。
ただし、ネイティブ版とWasm版では利用できる機能が異なる。ネイティブ版は複数のワーカーによる並列型検査に対応する一方、Wasm版の検査処理は単一スレッドで動作する。また、Wasm版ではファイル変更の監視機能やLSP（Language Server Protocol）、APIサーバーがサポートされていない。ネイティブ版で測定された最大8倍の高速化を、ブラウザー上でも同様に達成できるというわけではない。
10月24日時点の公開リポジトリのREADMEと互換性文書に基づき、主な違いを整理すると次のようになる。なお、開発中のmainブランチに記載されている機能が、すべての公開済みnpmパッケージで利用できることを保証するものではない。
| 比較項目 | ネイティブ版 | Wasm版 |
|---|---|---|
| 型検査の並列化 | 複数ワーカーに処理を分散可能。ワーカー数によって速度とメモリ使用量が変化 | 単一スレッドで動作し、並列型検査には非対応 |
| 処理速度 | CloudflareがTypeScript 7.0比で最大8倍の高速化を初期測定で報告 | 同等の高速化を裏付ける測定結果は提示されていない |
| 主な制約 | TypeScriptとの診断互換性や、既知の診断順序の問題を確認する必要がある | 左記に加え、watch、LSP、APIサーバーに非対応。Wasmの線形メモリは1インスタンスあたり最大4 GiB |
ブラウザー版では、Wasmモジュールの読み込みと初期化が完了すると、コンパイル処理が同期的に実行される。パッケージ側が自動的にWeb Workerを作成するわけではないため、型検査によって画面の応答が妨げられないようにするには、呼び出し側でWorkerを用意する必要がある。また、Wasmの線形メモリは1インスタンスあたり最大4 GiBで、実際の実行環境によってはさらに低い上限が適用される。ブラウザー内で型検査が可能になったからといって、巨大なリポジトリやデスクトップ向けエディターのすべての機能をそのまま扱えるわけではない。
なお、Cloudflareは9月28日にも、RustアプリケーションをWebやCloudflare Workersなどで動作させるためのEmscripten対応の実験的プレビューを紹介している。ただし、こちらはtsrsのWasmパッケージで採用されているWASI向けビルドとは別の取り組みだ。両者を同じ実装として扱うことはできない。
高速化だけでは不十分、TypeScriptとの互換性が実用化の鍵に
tsrsが既存のTypeScriptコンパイラを置き換えるには、処理速度やメモリ使用量だけでなく、検査結果の互換性も重要になる。tsrsの互換性文書では、TypeScriptのGo実装を基準とし、診断結果に違いがあればtsrs側の不具合として扱う方針が示されている。単に同じ型エラーを検出するだけでなく、エラーが表示される順序やメッセージの文言、終了コードまで一致させることを目指している。どれほど高速でも、コンパイラを変更したことで型検査の結果が変わるのであれば、既存の開発環境へそのまま導入することは難しい。
実際、10月24日時点のREADMEには、検査の実行順序によってエラーが現れたり消えたりする既知の問題が記載されている。Go実装と互換性のあるワーカー割り当て方式を使用することもできるが、それによってすべてのプログラムで検査結果の決定性が保証されるわけではない。開発チームはTypeScript 7.1との完全な互換性を安定版の目標として掲げており、こうした問題の解消を進めている。
開発中のコードと公開済みパッケージの違いにも注意が必要だ。10月24日時点の文書によると、mainブランチはTypeScript 7.1 betaのコミット3e9236361fa9に対応するよう移植されている。一方、公開済みのバージョン0.18.0が対応しているのは、それより前のコミットb85298b6a81fであり、バージョン0.19.0は準備中とされている。したがって、開発中のmainブランチで対応が進んでいる機能や修正が、手元にインストールした公開版でも利用できるとは限らない。
Cloudflareは、上流のTypeScriptに加えられる変更を継続的に追跡し、互換性をテストする方針を示している。今後はtsc-rsとの統合や、LSP、content mappersを含む機能への対応を進める計画だ。また、型情報を利用したOxlintの機能拡張も検討されているが、いずれも今後の開発課題であり、すべてが実装済みというわけではない。一方、tsrsで得られた最適化をGo実装にも取り込む方針は、Rust版を採用しない開発者にも改善の恩恵が広がる可能性を持つ。
現段階でtsrsを試験導入する場合は、使用するバージョンを固定し、既存のTypeScriptと診断結果が一致するかを確認することが重要だ。そのうえで、ワーカー数や測定条件をそろえ、型検査の所要時間とピークメモリ使用量を比較すれば、自分の開発環境でどの程度の効果が得られるかを判断できる。ブラウザーでの利用を検討する場合には、単一スレッドやメモリ上限、未対応機能が実際の用途に影響しないかも確かめる必要がある。
tsrsの意義は、TypeScriptの型検査を単に高速化することだけではない。必要な型情報だけを構築し、不要になったデータを解放する設計によって、検査に必要なメモリを減らせる点にもある。互換性や実行環境の制約が解消されれば、AIエージェントが繰り返し型検査を実行する開発環境や、ブラウザー上の開発ツールでも、限られた計算資源をより効率的に利用できるようになるだろう。