この記事の目次
CloudflareがTypeScriptのRust移植「tsrs」を発表、型チェックはTypeScript 7比で最大8倍
Cloudflareは2026年10月20日（日本の報道は22日）、TypeScriptをRustに移植した「tsrs」を発表しました。Cloudflareのブログによると、TypeScript 7.0と同じ数の型チェックワーカーで比べた場合、最大8倍高速で、メモリ使用量は約70%少ないとされています。現時点では実験的なリリースで、npmのtsrsパッケージで試せます。
ただし、この数字はCloudflare自身が公表したものです。ベンチマークの機材やテストしたプロジェクトなどの条件は、Publickeyの記事には記載がなく、ブログ本文のテキストからも確認できませんでした（数値の一部はグラフ画像の中にあります）。この記事では、ブログと報道で確認できる範囲を整理し、導入を考えるフロントエンド・Node.js開発者向けに「いま何が言えて、何が言えないか」を分けて説明します。
本家をフォークせず「忠実な移植」を目指すtsrs
tsrsは、TypeScriptのコンパイラ（型チェックを含む）をRustで書き直す取り組みです。CloudflareのブログによるとVoidZeroと共同で、Owner.comのMax Schwenk氏も加わっています。プロジェクトは、Oxc JavaScriptコンパイラツールチェーンの一部として開発が進められています。
ブログは「we are not forking TypeScript」と明言しています。言語の設計と方向性を決めるのはTypeScriptチームであり、tsrsはその決定に厳密に従う「忠実な移植（faithful port）」を目指すという立場です。ブログは、移植版はTypeScriptの決定に厳密に従わなければ、いずれ破綻して互換性を失うとも書いています。
8倍・70%減は「ワーカー数をそろえた」条件での値
ブログによると、比較の条件は次のとおりです。
- 比較対象はTypeScript 7.0（Go製）で、同じ数の型チェックワーカーを使った場合
- 結果は「最大8倍高速」「メモリ使用量が約70%少ない」
- 他の移植版が出す高い数値は、大きなマシンや既定と異なるオプションを使っていることが多いと指摘し、tsrsの比較はTypeScriptチームと協力して同じ設定で行ったと説明している
- tsrsの既定は、マシンの種類に応じた適応的な設定で、メモリを多く使う代わりにさらに速くなるとされている。つまり70%減は、ワーカー数をそろえたときの値で、既定のまま実行した場合のメモリ量とは限らない
- ベンチマークのコードは、tsrsのリポジトリ（oxc-project/tsrs）の
benchディレクトリで公開されている
TypeScript 7.1のベータ版は7.0より最大2.5倍速いとされており、その最適化の一部はtsrsから取り込まれたとブログは書いています。Publickeyは、tsrsは7.1ベータよりもさらに速いと書いています。ここからは編集部の見方ですが、「最大」という表現は、条件のよいプロジェクトでの数字として読むのが安全で、自分のプロジェクトで同じ割合になるとは限りません。
まだ試す段階の理由：互換性の差と未対応の機能
ブログは、現時点で本家との差があることも認めています。例として、診断メッセージが出力される順序の違いが挙げられています。安定版の公開までに、この差を最小限にする方針です。
対応範囲も途中です。Cloudflareは、Theo Browne氏と協力して、tsc-rs（pingdotgg/ts-rust）とtsrsを1つのパッケージに統合し、LSP（エディターに型情報を渡す仕組み）やcontent mappersを含むTypeScriptの全機能に対応することを目指すとしています。つまり、いまのtsrsだけで、エディター補完を含めた開発環境をそっくり置き換えられるわけではありません。
そのほか、予定として次の点が示されています。
- 上流（TypeScript）の変更をエージェントが確認し、互換性の一覧を夜間に更新する運用（CloudflareがVinext（Next.jsとの同期）で使った方式を適用する予定）
- 有用な性能改善を、TypeScript Goのコードベースにも還元すること
- Oxlintと連携し、型情報を使うlintルールなどを深く統合すること
WebAssembly版もあるが、用途は別
npmには@tsrs/wasmもあります。ブログは、Go製のツールをWebAssemblyにするとガベージコレクションも一緒に組み込む必要があるのに対し、Rustはゲストとホストの間のメモリ操作が単純でメモリ効率がよいと説明しています。CloudflareのWorkersはネイティブRustとWasmに対応しており、ブラウザ、組み込み機器、IoTでの実行も視野に入れているとされています。
CI（継続的インテグレーション）で型チェックを走らせる開発者と、ブラウザ上のエディターでTypeScriptを動かしたい開発者では、この移植に期待する点が違います。前者は速度とメモリ、後者はWasmで動くことが関心事です。
いま試すなら、本番の型チェックとは分ける
導入コマンドは、ブログによるとnpm install tsrsとnpx tsrsです。ここからは編集部の見方です。実験的な段階で、診断の順序などに差があることを認めている以上、いきなり本番のCIをtsrsに置き換えるのは避けたほうがよいと考えます。手順としては、既存のtscの結果と並べて、同じ指摘が出るかを見比べる使い方が現実的です。メモリの数字は、既定のまま実行するとブログの70%減と合わない可能性があるため、速度とあわせて、自分のプロジェクトで測るしかありません。
もう一点、見落としやすいのは、速さを競う型チェッカーの選択肢が増えることの意味です。ブログはtsc-rsとの統合にも触れています。選択肢が増えるほど、「どれを使うか」よりも「本家と結果が一致するか」を確かめる作業が重要になります。ブログが互換性の一覧を夜間に更新する運用を挙げているのは、この点への対策と読めます。
出典
- Cloudflare Blog「Introducing tsrs: a Port of TypeScript to Rust」（2026年10月20日）
- Publickey「Cloudflare、TypeScriptをRustに移植した「tsrs」を発表」（2026年10月22日）
2026年10月27日時点の情報です。
