Go製TypeScript 7の公開から約3か月後、なぜRust製の別実装が相次いだのか
はじめに
2026 年 7 月 8 日、Go で実装された TypeScript 7.0 が正式にリリースされました。公式発表では従来の TypeScript 6 と比べてフルビルドが概ね 8〜12 倍速くなったと報告されています。
そこから約 3 か月後の 10 月、Go 版をもとにした Rust 製の別実装の動きが目立つようになりました1。10 月 10 日には Bun 1.4.3 が bun check を公開し、20 日には Cloudflare と VoidZero が tsrs への協力体制 を発表しています。
tsc-rs も含め、Rust に移植するプロジェクトが複数進んでいます。公式の Go 実装も引き続き開発されており、Rust 版は別プロジェクトです。
TypeScript チームは Rust も検討したうえで Go を選んでいます。それなのに、今度は Rust への移植がいくつも進んでいるのが気になったため、これまでの経緯と各実装の特徴を調べてみました。
この記事では TypeScript 5 から Go 移植までを振り返り、各実装の特徴を見ながら、Rust 製の別実装が相次いだ背景を考えてみます。公開ベンチマークや、Rust 以外の方法で高速化する処理系も紹介します。
※情報は 2026 年 10 月 27 日時点のものです。ベンチマークは開発元や測定者が公開した結果を引用しており、自分の環境で測定したものではありません。
型チェックとトランスパイルについて
TypeScript の型注釈の除去や構文の変換によって JavaScript を生成するのがトランスパイルです。一方、代入や関数呼び出しが型のルールに合っているかを調べるのが型チェックです。
const count: number = "3";
このコードは型注釈を取り除けば JavaScript として実行できますが、型チェックではエラーになります。
esbuild は TypeScript を変換できますが、型チェックは行いません。公式ドキュメント でも、型チェックには別途 tsc --noEmit を使うよう説明されています。SWC や Oxc も TypeScript の変換機能を提供していますが、今回の中心は型チェック自体を高速化する処理系です。
TypeScript 5 から Go 移植まで
TypeScript は 2012 年 10 月に公開 され、長く TypeScript で書かれたコンパイラを JavaScript にして動かしてきました。Go に移植する前にも、既存実装の高速化は続いています。
日付
出来事
コンパイラの変化
2025 年 3 月 11 日
Go への移植を発表
ネイティブコードと並列処理による高速化を目指す
2025 年 5 月 22 日
Native Preview 公開
npm から Go 版を試せるようになる
2026 年 3 月 23 日
TypeScript 6.0 公開
JavaScript ベースの最後のメジャーリリースとする方針
2026 年 7 月 8 日
TypeScript 7.0 公開
Go 製コンパイラを正式に提供
TypeScript 5.0 では、内部オブジェクトの構造をそろえて JavaScript エンジンが処理しやすくするなどの改善が行われました。7.0 ではネイティブコードで動かし、複数の CPU コアも利用するようになった、という流れです。
ちなみに、tsc は公式コンパイラのコマンド名で、7.0 では Go 製の実行ファイルを起動します。tsgo はプレビュー時のコマンド名であり、Go 実装を指す名前としても使われます。この記事でも、従来の JavaScript 実装と区別するときに使っています。
なぜ Go が選ばれたのか
既存の挙動を保って移植したかった
公式の Why Go? では、言語選定の最大の条件として既存実装との互換性を挙げています。型チェックの結果に加えて、コードの構造を似せることも重視していました。
旧実装と新実装を並行して保守するには、片方の変更をもう片方に移しやすい方が便利です。Go は既存のコーディングパターンに近く、メモリ配置を制御しながら、不要なメモリを回収する GC も使えます。
TypeScript の内部では、構文を表す AST、名前と宣言を結ぶ Symbol、型情報などが相互に参照します。構文の親子関係は木構造ですが、実装には子から親へ戻る参照もあり、参照をたどると循環します。こうした参照関係を保ちやすいことが、Go を選ぶ理由になっていました。
Rust への移植で難しかったこと
Anders Hejlsberg は インタビュー で、Rust も試したものの、循環するデータ構造を多用する既存実装の移植には適さなかったと説明しています。
自分は GC を前提にした参照や後からの書き換えを、従来の構造を保って Rust に移す作業の難しさを説明している、と理解しました。Rust で循環参照を扱う方法は、この後の tsrs でも使われています。
Rust で書くなら、参照の表現やメモリを解放する単位などを別途設計できます。ただし、その分だけ移植の作業も増えます。互換性を保ちつつ少ない変更で高速化したい、という目的では Go が適していたということですね。
このあたりの歴史や構造は、TSKaigi 2026 の 制約と時代から読み解く TypeScript コンパイラ設計史 でも詳しく解説されています。
その後の TypeScript 処理系
2026 年 10 月時点の主な処理系を、ざっくり整理してみました。
処理系
実装と由来
主な特徴
tsc / tsgo
Go 製の公式実装
互換性を比較する基準
tsrs
Go 版を Rust に移植
メモリ配置の最適化、WebAssembly 対応
tsc-rs
Go 版を Rust に移植した別プロジェクト
AI による移植、Effect 向けの診断機能
bun check
Go 版を移植し、Rust 製の Bun に統合
実行・テスト・ビルド前に型チェック
tsz
Rust 製の TypeScript 互換実装
Checker と Solver を分ける設計
tsc-ts
Go 版を TypeScript に移植
scriptc でネイティブコードにコンパイル
移植元を図にすると、以下のようになります。tsz は設計を組み直した互換実装なので、同じ方式の移植としては結んでいません。
tsrs
2026 年 10 月 20 日、Cloudflare と VoidZero は、Owner.com の Max Schwenk 氏とともに tsrs に取り組むと発表しました。Oxc のツールチェーンの一部として開発し、TypeScript チームとも協力する方針です。
移植ガイド によると、tsrs は Go 版のアルゴリズムや関数の分割、処理順序を保つ方針です。一方、メモリ管理には独自の実装を使っています。
循環参照するオブジェクトは、メモリをまとめて管理するアリーナに確保します。オブジェクト同士は P<T> という型で参照します。
型チェック用のスレッド内だけで使うデータの更新には、Cell や RefCell などの内部可変性を使います。複数のスレッドで共有する AST などには独自の OwnedCell / FrozenCell を使い、原則として型チェック前に更新を終えます。遅延初期化が必要な共有データは、ロックなどで同期します。
こうするとオブジェクト間の参照関係と、メモリを所有・解放する単位を分けられます。親子が互いを参照していても、個々のノードが相手のメモリを所有する必要はありません。
Unix 向けの既定構成では ポインター圧縮 を使い、予約したアドレス範囲内の位置を 32 ビットのハンドルで表します。大量のノードや型が持つ参照を小さくすることで、メモリ使用量を減らす設計です。通常のポインターを使う設定もあります。
この実装には unsafe も含まれます。いつデータを解放し、どのスレッドで更新できるかは実装側で確認する必要があり、監査やチェック方法は Rust 実装上のルール にも文書化されています。
以前の Rust 移植で難しかった部分に対して、こうした設計を用意しているわけですね。個人的には言語を置き換えるだけでなく、メモリの扱いまで変えているところが面白いと感じました。
なお、互換性についてのドキュメント では、完全な互換性を安定版の目標としています。通常モードと高速化用の fast モードも区別され、後者では型チェックの順序などの変更に伴うエラーの差が明記されています。
tsc-rs
Theo Browne 氏の ts-rust は npm では tsc-rs という名前で提供されています。こちらも Go 版を Rust に移植し、コンパイラや言語サーバーを対象にした実験的なリリースです。
特徴的なのは、開発者自身が LLM による移植の実験として説明していることです。README には移植の試行やモデルを変えた経緯も書かれています。
ちなみに冒頭で紹介した 10 月 20 日の発表では、tsrs と tsc-rs を単一のパッケージに統合するため協力していることにも触れています。別々の実装として増え続ける、という状況でもなさそうです。
bun check
Bun 1.4.3 は 2026 年 10 月 10 日に bun check を公開しました。Go 版の移植を組み込み、tsconfig.json を読んで型チェックします。Bun 本体も 1.4 で Zig から Rust への移行を発表しています。
型チェックのドキュメント にあるように、bun run --check、bun test --check、bun build --check と普段の開発コマンドに組み込めるのが特徴です。型エラーがあれば実行やテストの前に止められます。
ただし、bun check は JavaScript や .d.ts の出力、言語サーバーを提供しません。エディターは別の TypeScript を使うため、診断結果をそろえるには、Bun が対応するバージョンを確認してエディター側も合わせます。
tsz
tsz は、型チェック、JavaScript の生成、言語サービスを扱う Rust 製の互換実装です。アーキテクチャの説明 では、Checker と Solver を分ける設計を紹介しています。
Checker はソースコードのどこを調べ、どの位置にエラーを報告するかを扱います。Solver は型推論や、ある型の値を別の型に代入できるかの判定を担当します。同じ構造の型を共有し、TypeId で参照する設計も説明されています。
Go 版の関数との対応を重視する tsrs と比べると、型を判定する処理をどう分けるかに違いがあります。ただし、既存処理の整理は続いており、すべての処理が完全に分離されているわけではありません。公式との互換性についての課題 も公開されています。
tsc-ts
Rust 以外の言語による別実装として、tsc-ts も紹介します。Go 製 TypeScript 7.0.2 を TypeScript に移植した実験的なコンパイラで、そのコードを scriptc でコンパイルし、ネイティブ実行ファイルとして提供します。
TypeScript に戻したのに速くなる、というのが少し不思議に見えますが、従来とは実行方法が違います。JavaScript にして動かす代わりに、コンパイラ自身を機械語にしています。
scriptc は型情報を使って値の表現を決め、LLVM でコードを生成します。コンパイルできる範囲には制限があり、未対応の処理は報告されます。
なぜこの時期に別実装が相次いだのか
tsrs や tsc-rs には、Go 版という移植元と公開テストがあります。言語の挙動やアルゴリズムを一から設計するのとは出発点が違い、元の実装と比較しながら開発できます。こうした蓄積も後発の移植を支えているのではないかと考えています。
移植に使う手段も変わっています。tsc-rs は LLM による移植の実験で、先ほどの tsrs の発表でも AI が大規模な移植を進められるようになったことを背景に挙げています。ただし、Rust 側のメモリ管理の設計や、元と同じエラーを出すかの確認は残ります。
さらに、各実装が目指す使い方も異なります。tsrs は速度に加えて、メモリ使用量や WebAssembly（Wasm）での実行を重視しています。bun check は実行・テスト・ビルドと型チェックをまとめています。こうした用途に合わせてメモリ管理や組み込み方を変えることも、別実装を作る動機になっていると感じました。
公開ベンチマークを見てみる
公開されている測定結果をいくつか載せます。
測定環境や対象コードが異なるので、別々の表の秒数を比べて順位は付けられません。処理系による違いに加えて、同じ処理系でも対象コードによって差が出る点を見ていただければと思います。
tsgo・tsrs・bun check の比較
tsrs の 公開ベンチマーク から、型チェックを並列に行うワーカー数を 4 にそろえた測定を抜粋しました。これは 0.19.0 beta より前に行われた測定の記録です。
対象
tsgo
tsrs
bun check
VS Code
10.94 秒
2.21 秒
4.48 秒
Playwright
1.23 秒
0.24 秒
0.50 秒
16 vCPU / 63 GB RAM の AMD EPYC / Linux で、--noEmit による型チェックを測っています。tsgo は 7.0.2、tsrs はコミット d57703ab5f07 の PGO（事前に集めた実行プロファイルを使う最適化）適用ビルド、Bun は 1.4.4-canary.1+5f5799ed1 です。中央値を使っていますが、測定回数は tsgo が 3 回、ほかは 10 回です。
この結果では tsrs が速いものの、移植元は 7.1 の開発版（b85298b6）で、tsgo の 7.0.2 とはバージョンが違います。VS Code ではエラー数にも差があり、公開資料では対応する Go の開発版と照らして説明しています。速度と互換性は分けて見る必要がありそうです。
tsc-rs の比較
tsc-rs の開発元も実際のアプリを使った 測定結果 を公開しています。入力コードや各回の記録は、測定データ から確認できます。
対象
tsgo
tsc-rs
tsc-rs --fast
VS Code
9.57 秒
4.81 秒
2.64 秒
Sentry
13.49 秒
5.30 秒
2.97 秒
Playwright
0.82 秒
0.41 秒
0.33 秒
測定日は 2026 年 10 月 13 日で、16 AMD EPYC vCPU / Linux、ウォームアップ 1 回後の 5 回の中央値です。--noEmit --incremental false を使い、並列数は各ツールのデフォルトのままです。
tsc-rs は 0.6.0 の release PGO ビルドで、BOLT は使っていません。比較する Go 版は移植元と同じ 7.1.0-dev.20261008.1 です。この測定では、通常モードと fast モードの両方で Go 版と診断結果が一致したと報告されています。互換性の確認はこの測定対象の範囲です。
tsz は対象によって結果が変わる
tsz の 公開結果 では、速いケースと遅いケースの両方が見られます。
対象
tsgo
tsz
RxJS
129 ミリ秒
51 ミリ秒
ts-essentials
100 ミリ秒
109 ミリ秒
これは 2026 年 10 月 25 日 04:55 UTC 生成の一覧ページに掲載された値です。tsz はコミット 0b4641a、PGO なしの release ビルドです。GitHub Actions の Linux 上で、Intel Xeon Platinum 8370C、4 CPU / 15.6 GiB RAM という条件の測定です。
同じ一覧には、Zod では tsz の型チェックに Go 版の約 19.4 倍の時間がかかることや、型チェックが完了しなかったケースも記載されています。なお、一覧ページだけでは Go 版の厳密なコミットや測定回数を確認できませんでした。一覧と個別ページの表示値にも差があるため、ここでは一覧に掲載された結果の紹介にとどめます。
tsc-ts の公開された測定例
tsc-ts については、enyst 氏が手順と記録を公開しているベンチマーク がありました。以下は GitHub Actions 上の結果です。
対象
従来の tsc
tsgo
tsc-ts
Canvas
29.071 秒
5.452 秒
3.770 秒
SDK の TypeScript クライアント
2.253 秒
0.319 秒
0.334 秒
SmolPaws server
2.647 秒
0.898 秒
0.546 秒
測定日は 2026 年 10 月 17〜18 日で、Ubuntu 24.04 / x86-64、4 論理 CPU のランナー上の結果です。--noEmit の新規プロセスを起動し、ウォームアップ後に 5 回ずつ交互に測った中央値を使っています。各プロジェクトは別ジョブで、並列数は各ツールのデフォルトのままです。
tsc-ts は 0.0.2、Go 版は @typescript/native-preview@7.0.0-dev.20260707.2 という正式公開前のプレビューです。従来の tsc は Canvas と SDK が 6.0.3、server が 5.9.3 です。Canvas では baseUrl を削除し、paths に相当する指定を追加した共通設定を 3 ツールで使っています。互換性の確認は、意図的に追加した少数の型エラーに対するものです。
Canvas と server では tsc-ts が速く、SDK では Go 版が少し速い結果でした。比較対象の Go 版が古いため、現在の公式実装にも同じ差があるとは言えませんが、TypeScript 製のコンパイラをネイティブで動かす例として興味深いです。
「何倍速い」の前提も確認したい
公式実装も改善を続けています。10 月 20 日公開の TypeScript 7.1 Beta では、4 ワーカー、--noEmit の条件で、7.0 から 1.2〜1.9 倍の高速化が報告されています。
先ほどの tsrs の発表でも、一部の最適化が公式実装に取り込まれたと説明されています。Rust と Go の実装が別々に速くなるだけでなく、改善を共有しているのも面白いところです。
おわりに
今回調べてみて、Go 版や公開テストを利用でき、AI で移植を進める手段も増えたことが、別実装を作りやすくしているのではないかと感じました。後発の実装は公式の成果を使いながら、用途に合わせてメモリ管理や実行方法を工夫しています。
エディターとの連携や CI の高速化、ブラウザー内での実行など、用途によって選ぶ処理系も変わっていくのではないかと思います。
一方で、公式の変更を追って互換性を保ち続ける作業は残ります。個人的には速度だけでなく、各実装がどのように変更を取り込み、協力・統合していくのかも引き続き追っていきたいと思います。
脚注
「約 3 か月後」は、7.0 の正式公開から、10 月に型チェック機能の公開や協力体制の発表が続いた時期までの間隔です。各プロジェクトの開発開始日や、移植にかかった期間を示すものではありません。 ↩︎
Source: pingdotgg/ts-rust. Costs, test counts and speed are the README's own figures, not our benchmarks. Would you ship code nobody has read?
An AI Ported the TypeScript Compiler. Nobody Read It.
ts-rust is an experiment porting the TypeScript compiler, type checker and language server to Rust using AI agents. The README says a first attempt cost over $400k in API-priced tokens and stalled near 84% compatibility, and a restart cost about $24k. The project reports all tests passing and faster type checking on one codebase. The author says he has never read the code. Figures are from the README; we have not verified them.
Voiceover is AI-generated.
Repo: pingdotgg/ts-rust
#shorts #typescript #rust #ai #github #opensource
1 comment · 31 views
tsc-rsは最速ではない?OpenAI数学719本と売上500億ドルの読み方
2026年10月5日から11日の週のAI関連ニュースから、手を動かす人にも経営側にも影響が大きい3本を選んでまとめた記事です。取り上げるのは、LLMが移植したTypeScriptの型チェッカー「tsc-rs」、OpenAIが公開した数学の成果、OpenAIの売上をめぐる報道です。
どれも、成果をどの物差しで確かめるかという点でつながっています。数字には出どころ(作者の測定、公式、企業の発表値、報道)を添えました。
動画
youtu.be
tsc-rs: LLMが移植した型チェッカー
tsc-rsは、Go製になったTypeScript 7のコンパイラ(tsc 7)をRustへ移植したものです。型チェックだけでなく、コンパイラと言語サーバーまで含みます。GitHubのpingdotgg/ts-rustで公開され、0.1.0が10月7日、0.2.0が10月9日に出ました。ライセンスはMITです。
作者の記載では、移植元のGo側にあるテスト18万1711件がすべて通っています。60のオープンソースのリポジトリで、tsc 7と同じ出力になったとも書かれています。
速さの数字は作者の測定です。VS Code、Sentry、Playwright、Excalidraw、TypeORM、tRPCという6つの実アプリの平均(幾何平均)で、tsc 7の1.89倍でした。1つ前のtsc 6と比べると13.4倍で、tsc 7自体は7.1倍です。測定はApple M4 Pro 1台、hyperfineによる5回の中央値なので、自分の環境で同じ倍率になるとは限りません。
誤解1: LLM製だから最速、ではない
Bunの型チェック機能であるbun checkは、同じ測定でtsc 7の2.95倍です。速さだけならtsc-rsより上です。一方、tsc 7と同じ出力になったリポジトリは、tsc-rsが60本中60本、bun checkは37本でした。tsc-rsはtsc 7と同じ出力を守るため、並列処理の作りを変えていないとされています。
分かれ目は単純です。CIで公式版と結果をそろえたいならtsc-rs、速さを優先するならbun checkという選び方になります。
誤解2: 2万4000ドルで作れた、ではない
「2万4000ドルで作れた」という話は、Claude Opus 5.5の分だけです。Opus 5.5は一から書き直し、2週間で約2万4047ドルを使いました。その前に、GPT-5.6 SolとGPT-6 Astraで40万ドル超を使い、互換性は84%前後で止まったと書かれています。合計は42万ドル超で、いずれもAPI料金に換算した作者の自己申告です。作者はコードを1行も読んでいないとも記載しています。
それでも形になった背景には、先にテストという物差しがそろっていたことがあると読めます。
試し方と1週間のチェック表
導入は2行です。比べる相手は、TypeScript 7.1の開発版(typescript@7.1.0-dev.20260929.1)にそろえます。7.0.xと比べると、7.1で増えたチェックの分だけエラーが多く見えるためです。
npm install -D tsc-rs
npx tsc-rs -p tsconfig.json
CIで今のtscと並べ、出力が同じかを1週間見る
tsc -bの参照漏れで、TS2305やTS2307が出ないか確認する
モノレポでTS6059(rootDir外)が増えないか確認する
切り戻しのため、typescriptパッケージは消さずに残す
立場別に見ると、開発者はCIでの併走、PMは自分のリポジトリで型チェック待ちの時間を測ること、会社の側ではテストが厚い既存システムの別言語への移植見積もりが変わりうること、が要点です。
OpenAIの数学719本: 機械で確認できたのは約42%
OpenAIはGitHub(openai/math)で、数学の未解決問題に対する成果を大量に公開しました。公式の説明では、未公開の社内モデルに約4000問を解かせています。今の一覧は原稿719本、372の系統にまとまっています。
ここで重要なのがLeanです。証明が正しいかを機械が確かめるための言語で、公式の変更履歴では、主要な結果のうちLeanで確認済みなのは300 / 719(約42%)です。残りについて、公式自身が未検証の結果には問題があるかもしれないと記載しています。
公開は10月6日で、翌7日に3本が取り下げられました。原因は1本の符号の誤りで、証明の一部が崩れ、それに依存する2本が連鎖しました。ほかに14本が修正され、関連する13本は参照が更新されています。
外部からの指摘もあります。数学者の助言グループは推論の過程も出すよう求めていました。TechCrunchによると、推論の要約が付いたのは10件です。集合論の研究者は個人ブログで、読んでも評価できない書き方だと批判しています。
誤解3: 数百の未解決問題が解けた、ではない
この一件は、「数百の未解決問題が解けた」とも、「取り下げが出たから全部が怪しい」とも読めません。確認済みは半分弱で、取り下げは719本の一部だからです。
AIが出したコードや報告を受け取るときにも、同じ3点を確認できます。
機械で検証できたか(テストやLean)
何に依存しているか(1本の誤りが連鎖する)
同じ手順で作り直せるか(モデルと手順が公開されているか)
PMなら、成果の発表を見たとき件数ではなく検証済みの割合を聞くのが有効です。
OpenAIの売上約500億ドル: 差は数え方
FTとCNBCの報道によると、OpenAIは投資家に、9月下旬時点の年換算の売上が約500億ドルだと説明しました。年換算は、足元の売上のペースを1年分に直した数字です。先月は約700億ドル(CNBCは680億ドルと記載)という数字が出回っていたため、200億ドル減ったように見えました。
誤解4: 200億ドル減った、ではない
CNBCは関係者の話として、大きい方の数字は提携先の売上まで含んでいたと伝えています。TechCrunchは、約700億ドルは投資家がAnthropicと並べるために作った数字だと書いています。Anthropicは7月時点で650億ドルと報じられ、こちらはクラウド経由の販売を含みます。
どちらが同じ物差しなのかは、報道の間でも説明が割れています。さらに、今回の数字は会社の発表ではなく、投資家への説明を報道が伝えたものです。OpenAIはコメントしていません(TechCrunch)。
他社と並べて資料にするなら、確認したいのは次の3点です。
いつ時点か
提携先経由の売上を含むか
会社の発表か、投資家経由の報道か
3つがそろわない場合は、定義を1行添えるか、比較を外すのが安全です。開発者に今日効く変化は今のところ見当たらず、料金の背景として追う話です。
そのほかの話題
文章ではなく判断を返すAI
TypeSafeは公式ブログで8.7億ドルの調達を発表し、評価額は75億ドルです。モデルのJevは答えを確率で返しますが、速さの数値は未公開で、Fortune 500の3分の1が利用しているという点は自己申告です。
同じ週にOpenAIがDecisions APIを公開ベータにしました。モデルはgpt-6-lunaのみで、POST /v1/decisionsが窓口です。料金は入力100万トークンあたり0.10ドル、出力の課金はなしと公式ドキュメントにあります。問い合わせの振り分けのような分類を文章生成で回しているなら、比べる候補になります。
今週の読み
以上は動画での私の読みです。各社の差は性能よりも、確かめ方と記録の残し方に出始めています。
今週の読みは「AIの成果が使えるかは、検証の物差しで分かれた」です。Leanで確認済みの数学の結果から取り下げが出たら、この読みは外れです。違っていれば訂正します。
出典
ts-rust (GitHub)
openai/math (GitHub)
openai/math の変更履歴
OpenAIの数学と分野の基準 (TechCrunch)
集合論の研究者の個人ブログ
OpenAIの売上 (TechCrunch)
OpenAIの売上 (CNBC)
TypeSafe公式ブログ
TypeSafe Jev (TechCrunch)
Decisions API (OpenAI公式ドキュメント)
詳しくは動画で
各章のスライドと、チームに共有できる3点のまとめは動画にあります。毎週のAIニュースの整理を続けているので、更新を追っていただけるとうれしいです。
tsrs 登場 — Rust 製 TypeScript で型チェックを CI に組み込む
はじめに
2026 年 10 月、Cloudflare が VoidZero や TypeScript チームと協力して開発している tsrs が発表されました（Introducing tsrs: a Port of TypeScript to Rust）。
tsrs は TypeScript コンパイラを Rust に移植したもの で、Oxc（Vite / Rolldown / Oxlint / Oxfmt などを擁する JavaScript ツールチェーン）の一部としてインキュベートされています。
公式ベンチマークによると、同じ型チェックワーカー数で比較した場合、TypeScript 7.0 に対して 最大 8 倍高速、メモリ使用量は約 70% 削減 とされています。これは開発体験、とくに CI での型チェックに大きなインパクトをもたらします。
この記事では、tsrs がどういう技術なのかを整理したうえで、「なぜ CI に型チェックを組み込む仕組みをわざわざ作る必要があるのか」という実務的な話までまとめてみます。
tsrs とは何か
TypeScript の「フォーク」ではなく「ポート」
重要なポイントとして、tsrs は TypeScript を フォークするものではありません。言語の設計と方向性は引き続き TypeScript チームが完全にコントロールし、tsrs はその実装に忠実に追従する「ポート（移植）」という立場をとっています。
TypeScript チームは機能によっては何年もかけて実装方針を検討することがあり、ポート側がそこから外れると最終的に互換性が崩れてしまいます。そのため tsrs は、オリジナル実装に厳密に沿って TypeScript 言語を保つ方針をとっています。
なぜ Rust なのか
TypeScript チーム自身がすでに Go への移植（いわゆる TypeScript 7.x 系）で約 10 倍の高速化とメモリ効率改善を達成しています。それでもなお Rust を選ぶ理由として、ブログでは次の点が挙げられています。
WebAssembly との相性の良さ: Go を Wasm にコンパイルするとガベージコレクタも一緒に積む必要がありますが、Rust のメモリ管理モデルは Wasm ホストとゲスト間のメモリ連携が素直に行え、メモリフットプリントを小さく保てます。
動かせる場所が増える: 小さなメモリフットプリントのおかげで、ブラウザ内・組み込みデバイス・IoT、あるいは Cloudflare Workers のようなサンドボックス環境でも開発ツールチェーンをまるごと動かせる可能性が広がります。
エージェントとの組み合わせ: 完全にサンドボックス化された環境でビルド・デプロイの一連を回せるため、AI エージェントによる開発フローとも噛み合います。
なぜ今なのか
TypeScript のポートはこれまで何度も試みられてきましたが、複雑さゆえに成功したのは TypeScript チーム自身による Go への移植だけでした。しかし現在は、フロンティアな AI モデルが大規模なポートを数日単位でほぼ自律的に進められるようになったことが、tsrs 登場の背景にあると説明されています。
使い方
実験的なリリースは npm から試せます。
npm install tsrs
npx tsrs
なお現時点では、診断メッセージの出力順などがアップストリームの TypeScript と異なる部分が残っているとされており、安定版リリースまでにこうした差分を最小化していく方針です。
なぜ「CI で型チェックする仕組み」を作る必要があるのか
ここが実務上いちばん重要なポイントです。
ビルドツールは型チェックをしてくれない
Vite や Next.js などのモダンなビルドツールは、ビルド時に 型チェックを行っていません。これらは esbuild や SWC などを使って型情報を「剥がす（type stripping）」形で高速にトランスパイルしているだけで、tsc のような型検査は走らないのが基本です。
つまり、
ローカルの開発サーバーが起動する・ビルドが通る、ということは 型が正しいことを保証しません。
型エラーがあってもビルドは成功してしまい、実行時やレビュー時になって初めて気づく、ということが起こり得ます。
この「ビルドは通るが型は壊れている」を防ぐには、ビルドとは別に型チェックを実行する仕組みを自分たちで用意する必要があります。その代表的な置き場所が CI です。
これまでの CI 型チェックの課題
CI に tsc --noEmit を組み込むのは定番ですが、大規模プロジェクトでは以下がネックになりがちでした。
型チェックに時間がかかり、CI 全体のボトルネックになる。
メモリを大量に消費し、ランナーのスペックを上げる or OOM と戦うことになる。
結果として PR のフィードバックが遅くなり、開発体験が落ちる。
ここで tsrs の「最大 8 倍高速・メモリ約 70% 削減」が効いてきます。型チェックが速く・軽くなれば、CI の型チェックを現実的なコストで回せるようになり、フィードバックループが短くなる というわけです。
CI への組み込みイメージ
現時点では tsrs は実験的なリリースのため、まずは「既存の tsc --noEmit と並走させて挙動と速度を比較する」ところから始めるのが安全です。
.github/workflows/typecheck.yml の例（イメージ）
name: typecheck
on:
pull_request:
jobs:
typecheck:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 22
- run: npm ci
既存の型チェック（正とする基準）
- name: tsc
run: npx tsc --noEmit
tsrs を試験導入し、差分や速度を観察する
- name: tsrs (experimental)
run: npx tsrs
continue-on-error: true
ポイントは次のとおりです。
Vite / Next.js のビルドとは 独立した型チェックジョブ として用意する（ビルド成功 ≠ 型 OK なので）。
実験段階の tsrs は continue-on-error: true で「落ちても CI 全体は止めない」状態から始め、出力差分（診断順の違いなど）や速度を観察する。
十分に信頼できると判断できたら、tsc を tsrs に置き換えて CI 時間を短縮する、という移行パスを描けます。
今後の展望
Theo Browne 氏の tsc-rs と tsrs を統合し、LSP やコンテンツマッパーを含む TypeScript のフル機能をサポートする単一パッケージを目指しています。
Cloudflare が Next.js のポートである Vinext で実践しているのと同様に、エージェントを使ってアップストリーム TypeScript との差分を日次で追従・検証していく運用が計画されています。
パフォーマンス改善は可能な限り TypeScript の Go 実装側へも還元し、エコシステム全体が恩恵を受けられるようにするとしています。
さらに Oxlint の型を考慮した Lint ルールなど、tsrs を他ツールと深く統合する実験も視野に入っています。
まとめ
tsrs は TypeScript コンパイラの Rust ポートで、最大 8 倍高速・メモリ約 70% 削減という大きな性能向上が期待できます。
Vite / Next.js は ビルド時に型チェックをしない ため、型の正しさを担保するには 別途 CI などで型チェックを回す仕組みが必須 です。
従来 CI の型チェックは「遅い・重い」が課題でしたが、tsrs によってそのコストが下がれば、フィードバックループが短くなり開発体験が大きく向上します。
まだ実験段階なので、まずは既存の tsc と並走させて差分・速度を観察し、信頼できたら置き換える、という段階的な導入がおすすめです。
参考リンク
Introducing tsrs: a Port of TypeScript to Rust（Cloudflare Blog）
tsrs（GitHub / oxc-project）
tsrs（npm）
2 likes
Theo's port is tsc-rs[0] as reference, and is significantly slower and uses more memory than this new version.
[0] pingdotgg/ts-rust
TS-Rust itself is fully compatible though, we use it for all the type checking in T3 Code and it's been awesome for us
pingdotgg/ts-rust
1 like
@super6plx @localhost_5173 TS-Rust itself is fully compatible though, we use it for all the type checking in T3 Code and it's been awesome for us
pingdotgg/ts-rust
9 likes · 3,347 views
Топ-10 GitHub за 3 дня: ИИ-пентестер и Word на Rust
10 новых open-source проектов GitHub за 7–10 октября 2026, быстрее всех набравших звёзды: ИИ-пентестер, аналог Word на Rust и драйвер NVIDIA для macOS.
1. mhtsec/ARTEX — ИИ-система, которая сама проводит тест на проникновение. (Go, +2684 ★)
2. storytold/wordcraft — Открытый аналог Microsoft Word, написан с нуля на Rust. (Rust, +2426 ★)
3. nullmoth/nvidia-macos-driver — Драйвер Metal для видеокарт NVIDIA RTX на macOS 15 Sequoia. (Rust, +2104 ★)
4. storytold/cadcraft — Открытая САПР в духе AutoCAD на чистом Rust. (Rust, +1557 ★)
5. alejandrobujan/tendedero — Маленькое приложение для macOS: скриншоты висят на верёвке сверху экрана. (Swift, +1390 ★)
6. noahdunnagan/fsearch — Поиск файлов по всему диску на macOS. (Rust, +1358 ★)
7. LoreanXavier/pt-pc — Нативный порт P.T. на PC. (C++, +1254 ★)
8. pingdotgg/ts-rust — Экспериментальный порт компилятора TypeScript 7 (tsc) на Rust. (Rust, +845 ★)
9. HelixDB/helix-foundry — Локальное рабочее пространство для данных компании. (TypeScript, +700 ★)
10. bas3line/ascii — Анимированный ASCII-арт для веб-страниц на TypeScript. (TypeScript, +693 ★)
Источник: GitHub Search API, репозитории созданы с 2026-10-07, отсортированы по звёздам.
Лидер: mhtsec/ARTEX
Остальные: storytold/wordcraft, nullmoth/nvidia-macos-driver, storytold/cadcraft, alejandrobujan/tendedero, noahdunnagan/fsearch, LoreanXavier/pt-pc, pingdotgg/ts-rust, HelixDB/helix-foundry, bas3line/ascii
#GitHub #opensource #программирование
Каждые 3 дня — 10 новых open-source проектов GitHub, быстрее всех набравших звёзды. Подписывайся, чтобы не пропустить следующий выпуск.
1 like · 51 views
AI Rewrote TypeScript in Rust. Can You Trust It?
AI rewrote Microsoft's TypeScript compiler in Rust, and the README says nobody read the code. It passes all 181,711 of the ported tests. So can you ship code nobody read? Four big AI coding projects this year (tsc-rs, Anthropic's C compiler, Bun, GitHub Copilot) show what decides it, what broke, and a four-point checklist if you're thinking about a rewrite. Sources are on screen and below.
0:00 The README that says nobody read the code
0:39 The Rust port nobody read
1:31 The answer key
2:31 Bun: 535,496 lines in 11 days
3:24 GitHub: 18x faster, and what slipped through
5:27 What the tests can't see
6:50 If you're eyeing a rewrite
7:46 The question
SOURCES (primary pages; numbers are the authors' own unless marked)
- tsc-rs (ts-rust) README: pingdotgg/ts-rust
- Microsoft, "Announcing TypeScript 7.0": devblogs.microsoft.com
- Anthropic, "Building a C compiler with a team of parallel Claudes": anthropic.com
- Bun, the Zig-to-Rust port post: bun.com
- GitHub, "Migrating the GitHub Copilot runtime to Rust, using Copilot": github.blog
Context.md: AI news with the footnotes, with the sources on screen. Subscribe if you want the receipts.
10 likes · 3 comments · 3,353 views
Mentions
Go製TypeScript 7の公開から約3か月後、なぜRust製の別実装が相次いだのか はじめに 2026 年 7 月 8 日、Go で実装された TypeScript 7.0 が正式にリリースされました。公式発表では従来の TypeScript 6 と比べてフルビルドが概ね 8〜12 倍速くなったと報告されています。 そこから約 3 か月後の 10 月、Go 版をもとにした Rust 製の別実装の動きが目立つようになりました1。10 月 10 日には Bun 1.4.3 が bun check を公開し、20 日には Cloudflare と VoidZero が tsrs への協力体制 を発表しています。 tsc-rs も含め、Rust に移植するプロジェクトが複数進んでいます。公式の Go 実装も引き続き開発されており、Rust 版は別プロジェクトです。 TypeScript チームは Rust も検討したうえで Go を選んでいます。それなのに、今度は Rust への移植がいくつも進んでいるのが気になったため、これまでの経緯と各実装の特徴を調べてみました。 この記事では TypeScript 5 から Go 移植までを振り返り、各実装の特徴を見ながら、Rust 製の別実装が相次いだ背景を考えてみます。公開ベンチマークや、Rust 以外の方法で高速化する処理系も紹介します。 ※情報は 2026 年 10 月 27 日時点のものです。ベンチマークは開発元や測定者が公開した結果を引用しており、自分の環境で測定したものではありません。 型チェックとトランスパイルについて TypeScript の型注釈の除去や構文の変換によって JavaScript を生成するのがトランスパイルです。一方、代入や関数呼び出しが型のルールに合っているかを調べるのが型チェックです。 const count: number = "3"; このコードは型注釈を取り除けば JavaScript として実行できますが、型チェックではエラーになります。 esbuild は TypeScript を変換できますが、型チェックは行いません。公式ドキュメント でも、型チェックには別途 tsc --noEmit を使うよう説明されています。SWC や Oxc も TypeScript の変換機能を提供していますが、今回の中心は型チェック自体を高速化する処理系です。 TypeScript 5 から Go 移植まで TypeScript は 2012 年 10 月に公開 され、長く TypeScript で書かれたコンパイラを JavaScript にして動かしてきました。Go に移植する前にも、既存実装の高速化は続いています。 日付 出来事 コンパイラの変化 2025 年 3 月 11 日 Go への移植を発表 ネイティブコードと並列処理による高速化を目指す 2025 年 5 月 22 日 Native Preview 公開 npm から Go 版を試せるようになる 2026 年 3 月 23 日 TypeScript 6.0 公開 JavaScript ベースの最後のメジャーリリースとする方針 2026 年 7 月 8 日 TypeScript 7.0 公開 Go 製コンパイラを正式に提供 TypeScript 5.0 では、内部オブジェクトの構造をそろえて JavaScript エンジンが処理しやすくするなどの改善が行われました。7.0 ではネイティブコードで動かし、複数の CPU コアも利用するようになった、という流れです。 ちなみに、tsc は公式コンパイラのコマンド名で、7.0 では Go 製の実行ファイルを起動します。tsgo はプレビュー時のコマンド名であり、Go 実装を指す名前としても使われます。この記事でも、従来の JavaScript 実装と区別するときに使っています。 なぜ Go が選ばれたのか 既存の挙動を保って移植したかった 公式の Why Go? では、言語選定の最大の条件として既存実装との互換性を挙げています。型チェックの結果に加えて、コードの構造を似せることも重視していました。 旧実装と新実装を並行して保守するには、片方の変更をもう片方に移しやすい方が便利です。Go は既存のコーディングパターンに近く、メモリ配置を制御しながら、不要なメモリを回収する GC も使えます。 TypeScript の内部では、構文を表す AST、名前と宣言を結ぶ Symbol、型情報などが相互に参照します。構文の親子関係は木構造ですが、実装には子から親へ戻る参照もあり、参照をたどると循環します。こうした参照関係を保ちやすいことが、Go を選ぶ理由になっていました。 Rust への移植で難しかったこと Anders Hejlsberg は インタビュー で、Rust も試したものの、循環するデータ構造を多用する既存実装の移植には適さなかったと説明しています。 自分は GC を前提にした参照や後からの書き換えを、従来の構造を保って Rust に移す作業の難しさを説明している、と理解しました。Rust で循環参照を扱う方法は、この後の tsrs でも使われています。 Rust で書くなら、参照の表現やメモリを解放する単位などを別途設計できます。ただし、その分だけ移植の作業も増えます。互換性を保ちつつ少ない変更で高速化したい、という目的では Go が適していたということですね。 このあたりの歴史や構造は、TSKaigi 2026 の 制約と時代から読み解く TypeScript コンパイラ設計史 でも詳しく解説されています。 その後の TypeScript 処理系 2026 年 10 月時点の主な処理系を、ざっくり整理してみました。 処理系 実装と由来 主な特徴 tsc / tsgo Go 製の公式実装 互換性を比較する基準 tsrs Go 版を Rust に移植 メモリ配置の最適化、WebAssembly 対応 tsc-rs Go 版を Rust に移植した別プロジェクト AI による移植、Effect 向けの診断機能 bun check Go 版を移植し、Rust 製の Bun に統合 実行・テスト・ビルド前に型チェック tsz Rust 製の TypeScript 互換実装 Checker と Solver を分ける設計 tsc-ts Go 版を TypeScript に移植 scriptc でネイティブコードにコンパイル 移植元を図にすると、以下のようになります。tsz は設計を組み直した互換実装なので、同じ方式の移植としては結んでいません。 tsrs 2026 年 10 月 20 日、Cloudflare と VoidZero は、Owner.com の Max Schwenk 氏とともに tsrs に取り組むと発表しました。Oxc のツールチェーンの一部として開発し、TypeScript チームとも協力する方針です。 移植ガイド によると、tsrs は Go 版のアルゴリズムや関数の分割、処理順序を保つ方針です。一方、メモリ管理には独自の実装を使っています。 循環参照するオブジェクトは、メモリをまとめて管理するアリーナに確保します。オブジェクト同士は P<T> という型で参照します。 型チェック用のスレッド内だけで使うデータの更新には、Cell や RefCell などの内部可変性を使います。複数のスレッドで共有する AST などには独自の OwnedCell / FrozenCell を使い、原則として型チェック前に更新を終えます。遅延初期化が必要な共有データは、ロックなどで同期します。 こうするとオブジェクト間の参照関係と、メモリを所有・解放する単位を分けられます。親子が互いを参照していても、個々のノードが相手のメモリを所有する必要はありません。 Unix 向けの既定構成では ポインター圧縮 を使い、予約したアドレス範囲内の位置を 32 ビットのハンドルで表します。大量のノードや型が持つ参照を小さくすることで、メモリ使用量を減らす設計です。通常のポインターを使う設定もあります。 この実装には unsafe も含まれます。いつデータを解放し、どのスレッドで更新できるかは実装側で確認する必要があり、監査やチェック方法は Rust 実装上のルール にも文書化されています。 以前の Rust 移植で難しかった部分に対して、こうした設計を用意しているわけですね。個人的には言語を置き換えるだけでなく、メモリの扱いまで変えているところが面白いと感じました。 なお、互換性についてのドキュメント では、完全な互換性を安定版の目標としています。通常モードと高速化用の fast モードも区別され、後者では型チェックの順序などの変更に伴うエラーの差が明記されています。 tsc-rs Theo Browne 氏の ts-rust は npm では tsc-rs という名前で提供されています。こちらも Go 版を Rust に移植し、コンパイラや言語サーバーを対象にした実験的なリリースです。 特徴的なのは、開発者自身が LLM による移植の実験として説明していることです。README には移植の試行やモデルを変えた経緯も書かれています。 ちなみに冒頭で紹介した 10 月 20 日の発表では、tsrs と tsc-rs を単一のパッケージに統合するため協力していることにも触れています。別々の実装として増え続ける、という状況でもなさそうです。 bun check Bun 1.4.3 は 2026 年 10 月 10 日に bun check を公開しました。Go 版の移植を組み込み、tsconfig.json を読んで型チェックします。Bun 本体も 1.4 で Zig から Rust への移行を発表しています。 型チェックのドキュメント にあるように、bun run --check、bun test --check、bun build --check と普段の開発コマンドに組み込めるのが特徴です。型エラーがあれば実行やテストの前に止められます。 ただし、bun check は JavaScript や .d.ts の出力、言語サーバーを提供しません。エディターは別の TypeScript を使うため、診断結果をそろえるには、Bun が対応するバージョンを確認してエディター側も合わせます。 tsz tsz は、型チェック、JavaScript の生成、言語サービスを扱う Rust 製の互換実装です。アーキテクチャの説明 では、Checker と Solver を分ける設計を紹介しています。 Checker はソースコードのどこを調べ、どの位置にエラーを報告するかを扱います。Solver は型推論や、ある型の値を別の型に代入できるかの判定を担当します。同じ構造の型を共有し、TypeId で参照する設計も説明されています。 Go 版の関数との対応を重視する tsrs と比べると、型を判定する処理をどう分けるかに違いがあります。ただし、既存処理の整理は続いており、すべての処理が完全に分離されているわけではありません。公式との互換性についての課題 も公開されています。 tsc-ts Rust 以外の言語による別実装として、tsc-ts も紹介します。Go 製 TypeScript 7.0.2 を TypeScript に移植した実験的なコンパイラで、そのコードを scriptc でコンパイルし、ネイティブ実行ファイルとして提供します。 TypeScript に戻したのに速くなる、というのが少し不思議に見えますが、従来とは実行方法が違います。JavaScript にして動かす代わりに、コンパイラ自身を機械語にしています。 scriptc は型情報を使って値の表現を決め、LLVM でコードを生成します。コンパイルできる範囲には制限があり、未対応の処理は報告されます。 なぜこの時期に別実装が相次いだのか tsrs や tsc-rs には、Go 版という移植元と公開テストがあります。言語の挙動やアルゴリズムを一から設計するのとは出発点が違い、元の実装と比較しながら開発できます。こうした蓄積も後発の移植を支えているのではないかと考えています。 移植に使う手段も変わっています。tsc-rs は LLM による移植の実験で、先ほどの tsrs の発表でも AI が大規模な移植を進められるようになったことを背景に挙げています。ただし、Rust 側のメモリ管理の設計や、元と同じエラーを出すかの確認は残ります。 さらに、各実装が目指す使い方も異なります。tsrs は速度に加えて、メモリ使用量や WebAssembly（Wasm）での実行を重視しています。bun check は実行・テスト・ビルドと型チェックをまとめています。こうした用途に合わせてメモリ管理や組み込み方を変えることも、別実装を作る動機になっていると感じました。 公開ベンチマークを見てみる 公開されている測定結果をいくつか載せます。 測定環境や対象コードが異なるので、別々の表の秒数を比べて順位は付けられません。処理系による違いに加えて、同じ処理系でも対象コードによって差が出る点を見ていただければと思います。 tsgo・tsrs・bun check の比較 tsrs の 公開ベンチマーク から、型チェックを並列に行うワーカー数を 4 にそろえた測定を抜粋しました。これは 0.19.0 beta より前に行われた測定の記録です。 対象 tsgo tsrs bun check VS Code 10.94 秒 2.21 秒 4.48 秒 Playwright 1.23 秒 0.24 秒 0.50 秒 16 vCPU / 63 GB RAM の AMD EPYC / Linux で、--noEmit による型チェックを測っています。tsgo は 7.0.2、tsrs はコミット d57703ab5f07 の PGO（事前に集めた実行プロファイルを使う最適化）適用ビルド、Bun は 1.4.4-canary.1+5f5799ed1 です。中央値を使っていますが、測定回数は tsgo が 3 回、ほかは 10 回です。 この結果では tsrs が速いものの、移植元は 7.1 の開発版（b85298b6）で、tsgo の 7.0.2 とはバージョンが違います。VS Code ではエラー数にも差があり、公開資料では対応する Go の開発版と照らして説明しています。速度と互換性は分けて見る必要がありそうです。 tsc-rs の比較 tsc-rs の開発元も実際のアプリを使った 測定結果 を公開しています。入力コードや各回の記録は、測定データ から確認できます。 対象 tsgo tsc-rs tsc-rs --fast VS Code 9.57 秒 4.81 秒 2.64 秒 Sentry 13.49 秒 5.30 秒 2.97 秒 Playwright 0.82 秒 0.41 秒 0.33 秒 測定日は 2026 年 10 月 13 日で、16 AMD EPYC vCPU / Linux、ウォームアップ 1 回後の 5 回の中央値です。--noEmit --incremental false を使い、並列数は各ツールのデフォルトのままです。 tsc-rs は 0.6.0 の release PGO ビルドで、BOLT は使っていません。比較する Go 版は移植元と同じ 7.1.0-dev.20261008.1 です。この測定では、通常モードと fast モードの両方で Go 版と診断結果が一致したと報告されています。互換性の確認はこの測定対象の範囲です。 tsz は対象によって結果が変わる tsz の 公開結果 では、速いケースと遅いケースの両方が見られます。 対象 tsgo tsz RxJS 129 ミリ秒 51 ミリ秒 ts-essentials 100 ミリ秒 109 ミリ秒 これは 2026 年 10 月 25 日 04:55 UTC 生成の一覧ページに掲載された値です。tsz はコミット 0b4641a、PGO なしの release ビルドです。GitHub Actions の Linux 上で、Intel Xeon Platinum 8370C、4 CPU / 15.6 GiB RAM という条件の測定です。 同じ一覧には、Zod では tsz の型チェックに Go 版の約 19.4 倍の時間がかかることや、型チェックが完了しなかったケースも記載されています。なお、一覧ページだけでは Go 版の厳密なコミットや測定回数を確認できませんでした。一覧と個別ページの表示値にも差があるため、ここでは一覧に掲載された結果の紹介にとどめます。 tsc-ts の公開された測定例 tsc-ts については、enyst 氏が手順と記録を公開しているベンチマーク がありました。以下は GitHub Actions 上の結果です。 対象 従来の tsc tsgo tsc-ts Canvas 29.071 秒 5.452 秒 3.770 秒 SDK の TypeScript クライアント 2.253 秒 0.319 秒 0.334 秒 SmolPaws server 2.647 秒 0.898 秒 0.546 秒 測定日は 2026 年 10 月 17〜18 日で、Ubuntu 24.04 / x86-64、4 論理 CPU のランナー上の結果です。--noEmit の新規プロセスを起動し、ウォームアップ後に 5 回ずつ交互に測った中央値を使っています。各プロジェクトは別ジョブで、並列数は各ツールのデフォルトのままです。 tsc-ts は 0.0.2、Go 版は @typescript/native-preview@7.0.0-dev.20260707.2 という正式公開前のプレビューです。従来の tsc は Canvas と SDK が 6.0.3、server が 5.9.3 です。Canvas では baseUrl を削除し、paths に相当する指定を追加した共通設定を 3 ツールで使っています。互換性の確認は、意図的に追加した少数の型エラーに対するものです。 Canvas と server では tsc-ts が速く、SDK では Go 版が少し速い結果でした。比較対象の Go 版が古いため、現在の公式実装にも同じ差があるとは言えませんが、TypeScript 製のコンパイラをネイティブで動かす例として興味深いです。 「何倍速い」の前提も確認したい 公式実装も改善を続けています。10 月 20 日公開の TypeScript 7.1 Beta では、4 ワーカー、--noEmit の条件で、7.0 から 1.2〜1.9 倍の高速化が報告されています。 先ほどの tsrs の発表でも、一部の最適化が公式実装に取り込まれたと説明されています。Rust と Go の実装が別々に速くなるだけでなく、改善を共有しているのも面白いところです。 おわりに 今回調べてみて、Go 版や公開テストを利用でき、AI で移植を進める手段も増えたことが、別実装を作りやすくしているのではないかと感じました。後発の実装は公式の成果を使いながら、用途に合わせてメモリ管理や実行方法を工夫しています。 エディターとの連携や CI の高速化、ブラウザー内での実行など、用途によって選ぶ処理系も変わっていくのではないかと思います。 一方で、公式の変更を追って互換性を保ち続ける作業は残ります。個人的には速度だけでなく、各実装がどのように変更を取り込み、協力・統合していくのかも引き続き追っていきたいと思います。 脚注 「約 3 か月後」は、7.0 の正式公開から、10 月に型チェック機能の公開や協力体制の発表が続いた時期までの間隔です。各プロジェクトの開発開始日や、移植にかかった期間を示すものではありません。 ↩︎
Source: pingdotgg/ts-rust. Costs, test counts and speed are the README's own figures, not our benchmarks. Would you ship code nobody has read?
An AI Ported the TypeScript Compiler. Nobody Read It. ts-rust is an experiment porting the TypeScript compiler, type checker and language server to Rust using AI agents. The README says a first attempt cost over $400k in API-priced tokens and stalled near 84% compatibility, and a restart cost about $24k. The project reports all tests passing and faster type checking on one codebase. The author says he has never read the code. Figures are from the README; we have not verified them. Voiceover is AI-generated. Repo: pingdotgg/ts-rust #shorts #typescript #rust #ai #github #opensource
tsc-rsは最速ではない?OpenAI数学719本と売上500億ドルの読み方 2026年10月5日から11日の週のAI関連ニュースから、手を動かす人にも経営側にも影響が大きい3本を選んでまとめた記事です。取り上げるのは、LLMが移植したTypeScriptの型チェッカー「tsc-rs」、OpenAIが公開した数学の成果、OpenAIの売上をめぐる報道です。 どれも、成果をどの物差しで確かめるかという点でつながっています。数字には出どころ(作者の測定、公式、企業の発表値、報道)を添えました。 動画 youtu.be tsc-rs: LLMが移植した型チェッカー tsc-rsは、Go製になったTypeScript 7のコンパイラ(tsc 7)をRustへ移植したものです。型チェックだけでなく、コンパイラと言語サーバーまで含みます。GitHubのpingdotgg/ts-rustで公開され、0.1.0が10月7日、0.2.0が10月9日に出ました。ライセンスはMITです。 作者の記載では、移植元のGo側にあるテスト18万1711件がすべて通っています。60のオープンソースのリポジトリで、tsc 7と同じ出力になったとも書かれています。 速さの数字は作者の測定です。VS Code、Sentry、Playwright、Excalidraw、TypeORM、tRPCという6つの実アプリの平均(幾何平均)で、tsc 7の1.89倍でした。1つ前のtsc 6と比べると13.4倍で、tsc 7自体は7.1倍です。測定はApple M4 Pro 1台、hyperfineによる5回の中央値なので、自分の環境で同じ倍率になるとは限りません。 誤解1: LLM製だから最速、ではない Bunの型チェック機能であるbun checkは、同じ測定でtsc 7の2.95倍です。速さだけならtsc-rsより上です。一方、tsc 7と同じ出力になったリポジトリは、tsc-rsが60本中60本、bun checkは37本でした。tsc-rsはtsc 7と同じ出力を守るため、並列処理の作りを変えていないとされています。 分かれ目は単純です。CIで公式版と結果をそろえたいならtsc-rs、速さを優先するならbun checkという選び方になります。 誤解2: 2万4000ドルで作れた、ではない 「2万4000ドルで作れた」という話は、Claude Opus 5.5の分だけです。Opus 5.5は一から書き直し、2週間で約2万4047ドルを使いました。その前に、GPT-5.6 SolとGPT-6 Astraで40万ドル超を使い、互換性は84%前後で止まったと書かれています。合計は42万ドル超で、いずれもAPI料金に換算した作者の自己申告です。作者はコードを1行も読んでいないとも記載しています。 それでも形になった背景には、先にテストという物差しがそろっていたことがあると読めます。 試し方と1週間のチェック表 導入は2行です。比べる相手は、TypeScript 7.1の開発版(typescript@7.1.0-dev.20260929.1)にそろえます。7.0.xと比べると、7.1で増えたチェックの分だけエラーが多く見えるためです。 npm install -D tsc-rs npx tsc-rs -p tsconfig.json CIで今のtscと並べ、出力が同じかを1週間見る tsc -bの参照漏れで、TS2305やTS2307が出ないか確認する モノレポでTS6059(rootDir外)が増えないか確認する 切り戻しのため、typescriptパッケージは消さずに残す 立場別に見ると、開発者はCIでの併走、PMは自分のリポジトリで型チェック待ちの時間を測ること、会社の側ではテストが厚い既存システムの別言語への移植見積もりが変わりうること、が要点です。 OpenAIの数学719本: 機械で確認できたのは約42% OpenAIはGitHub(openai/math)で、数学の未解決問題に対する成果を大量に公開しました。公式の説明では、未公開の社内モデルに約4000問を解かせています。今の一覧は原稿719本、372の系統にまとまっています。 ここで重要なのがLeanです。証明が正しいかを機械が確かめるための言語で、公式の変更履歴では、主要な結果のうちLeanで確認済みなのは300 / 719(約42%)です。残りについて、公式自身が未検証の結果には問題があるかもしれないと記載しています。 公開は10月6日で、翌7日に3本が取り下げられました。原因は1本の符号の誤りで、証明の一部が崩れ、それに依存する2本が連鎖しました。ほかに14本が修正され、関連する13本は参照が更新されています。 外部からの指摘もあります。数学者の助言グループは推論の過程も出すよう求めていました。TechCrunchによると、推論の要約が付いたのは10件です。集合論の研究者は個人ブログで、読んでも評価できない書き方だと批判しています。 誤解3: 数百の未解決問題が解けた、ではない この一件は、「数百の未解決問題が解けた」とも、「取り下げが出たから全部が怪しい」とも読めません。確認済みは半分弱で、取り下げは719本の一部だからです。 AIが出したコードや報告を受け取るときにも、同じ3点を確認できます。 機械で検証できたか(テストやLean) 何に依存しているか(1本の誤りが連鎖する) 同じ手順で作り直せるか(モデルと手順が公開されているか) PMなら、成果の発表を見たとき件数ではなく検証済みの割合を聞くのが有効です。 OpenAIの売上約500億ドル: 差は数え方 FTとCNBCの報道によると、OpenAIは投資家に、9月下旬時点の年換算の売上が約500億ドルだと説明しました。年換算は、足元の売上のペースを1年分に直した数字です。先月は約700億ドル(CNBCは680億ドルと記載)という数字が出回っていたため、200億ドル減ったように見えました。 誤解4: 200億ドル減った、ではない CNBCは関係者の話として、大きい方の数字は提携先の売上まで含んでいたと伝えています。TechCrunchは、約700億ドルは投資家がAnthropicと並べるために作った数字だと書いています。Anthropicは7月時点で650億ドルと報じられ、こちらはクラウド経由の販売を含みます。 どちらが同じ物差しなのかは、報道の間でも説明が割れています。さらに、今回の数字は会社の発表ではなく、投資家への説明を報道が伝えたものです。OpenAIはコメントしていません(TechCrunch)。 他社と並べて資料にするなら、確認したいのは次の3点です。 いつ時点か 提携先経由の売上を含むか 会社の発表か、投資家経由の報道か 3つがそろわない場合は、定義を1行添えるか、比較を外すのが安全です。開発者に今日効く変化は今のところ見当たらず、料金の背景として追う話です。 そのほかの話題 文章ではなく判断を返すAI TypeSafeは公式ブログで8.7億ドルの調達を発表し、評価額は75億ドルです。モデルのJevは答えを確率で返しますが、速さの数値は未公開で、Fortune 500の3分の1が利用しているという点は自己申告です。 同じ週にOpenAIがDecisions APIを公開ベータにしました。モデルはgpt-6-lunaのみで、POST /v1/decisionsが窓口です。料金は入力100万トークンあたり0.10ドル、出力の課金はなしと公式ドキュメントにあります。問い合わせの振り分けのような分類を文章生成で回しているなら、比べる候補になります。 今週の読み 以上は動画での私の読みです。各社の差は性能よりも、確かめ方と記録の残し方に出始めています。 今週の読みは「AIの成果が使えるかは、検証の物差しで分かれた」です。Leanで確認済みの数学の結果から取り下げが出たら、この読みは外れです。違っていれば訂正します。 出典 ts-rust (GitHub) openai/math (GitHub) openai/math の変更履歴 OpenAIの数学と分野の基準 (TechCrunch) 集合論の研究者の個人ブログ OpenAIの売上 (TechCrunch) OpenAIの売上 (CNBC) TypeSafe公式ブログ TypeSafe Jev (TechCrunch) Decisions API (OpenAI公式ドキュメント) 詳しくは動画で 各章のスライドと、チームに共有できる3点のまとめは動画にあります。毎週のAIニュースの整理を続けているので、更新を追っていただけるとうれしいです。
tsrs 登場 — Rust 製 TypeScript で型チェックを CI に組み込む はじめに 2026 年 10 月、Cloudflare が VoidZero や TypeScript チームと協力して開発している tsrs が発表されました（Introducing tsrs: a Port of TypeScript to Rust）。 tsrs は TypeScript コンパイラを Rust に移植したもの で、Oxc（Vite / Rolldown / Oxlint / Oxfmt などを擁する JavaScript ツールチェーン）の一部としてインキュベートされています。 公式ベンチマークによると、同じ型チェックワーカー数で比較した場合、TypeScript 7.0 に対して 最大 8 倍高速、メモリ使用量は約 70% 削減 とされています。これは開発体験、とくに CI での型チェックに大きなインパクトをもたらします。 この記事では、tsrs がどういう技術なのかを整理したうえで、「なぜ CI に型チェックを組み込む仕組みをわざわざ作る必要があるのか」という実務的な話までまとめてみます。 tsrs とは何か TypeScript の「フォーク」ではなく「ポート」 重要なポイントとして、tsrs は TypeScript を フォークするものではありません。言語の設計と方向性は引き続き TypeScript チームが完全にコントロールし、tsrs はその実装に忠実に追従する「ポート（移植）」という立場をとっています。 TypeScript チームは機能によっては何年もかけて実装方針を検討することがあり、ポート側がそこから外れると最終的に互換性が崩れてしまいます。そのため tsrs は、オリジナル実装に厳密に沿って TypeScript 言語を保つ方針をとっています。 なぜ Rust なのか TypeScript チーム自身がすでに Go への移植（いわゆる TypeScript 7.x 系）で約 10 倍の高速化とメモリ効率改善を達成しています。それでもなお Rust を選ぶ理由として、ブログでは次の点が挙げられています。 WebAssembly との相性の良さ: Go を Wasm にコンパイルするとガベージコレクタも一緒に積む必要がありますが、Rust のメモリ管理モデルは Wasm ホストとゲスト間のメモリ連携が素直に行え、メモリフットプリントを小さく保てます。 動かせる場所が増える: 小さなメモリフットプリントのおかげで、ブラウザ内・組み込みデバイス・IoT、あるいは Cloudflare Workers のようなサンドボックス環境でも開発ツールチェーンをまるごと動かせる可能性が広がります。 エージェントとの組み合わせ: 完全にサンドボックス化された環境でビルド・デプロイの一連を回せるため、AI エージェントによる開発フローとも噛み合います。 なぜ今なのか TypeScript のポートはこれまで何度も試みられてきましたが、複雑さゆえに成功したのは TypeScript チーム自身による Go への移植だけでした。しかし現在は、フロンティアな AI モデルが大規模なポートを数日単位でほぼ自律的に進められるようになったことが、tsrs 登場の背景にあると説明されています。 使い方 実験的なリリースは npm から試せます。 npm install tsrs npx tsrs なお現時点では、診断メッセージの出力順などがアップストリームの TypeScript と異なる部分が残っているとされており、安定版リリースまでにこうした差分を最小化していく方針です。 なぜ「CI で型チェックする仕組み」を作る必要があるのか ここが実務上いちばん重要なポイントです。 ビルドツールは型チェックをしてくれない Vite や Next.js などのモダンなビルドツールは、ビルド時に 型チェックを行っていません。これらは esbuild や SWC などを使って型情報を「剥がす（type stripping）」形で高速にトランスパイルしているだけで、tsc のような型検査は走らないのが基本です。 つまり、 ローカルの開発サーバーが起動する・ビルドが通る、ということは 型が正しいことを保証しません。 型エラーがあってもビルドは成功してしまい、実行時やレビュー時になって初めて気づく、ということが起こり得ます。 この「ビルドは通るが型は壊れている」を防ぐには、ビルドとは別に型チェックを実行する仕組みを自分たちで用意する必要があります。その代表的な置き場所が CI です。 これまでの CI 型チェックの課題 CI に tsc --noEmit を組み込むのは定番ですが、大規模プロジェクトでは以下がネックになりがちでした。 型チェックに時間がかかり、CI 全体のボトルネックになる。 メモリを大量に消費し、ランナーのスペックを上げる or OOM と戦うことになる。 結果として PR のフィードバックが遅くなり、開発体験が落ちる。 ここで tsrs の「最大 8 倍高速・メモリ約 70% 削減」が効いてきます。型チェックが速く・軽くなれば、CI の型チェックを現実的なコストで回せるようになり、フィードバックループが短くなる というわけです。 CI への組み込みイメージ 現時点では tsrs は実験的なリリースのため、まずは「既存の tsc --noEmit と並走させて挙動と速度を比較する」ところから始めるのが安全です。 .github/workflows/typecheck.yml の例（イメージ） name: typecheck on: pull_request: jobs: typecheck: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: 22 - run: npm ci 既存の型チェック（正とする基準） - name: tsc run: npx tsc --noEmit tsrs を試験導入し、差分や速度を観察する - name: tsrs (experimental) run: npx tsrs continue-on-error: true ポイントは次のとおりです。 Vite / Next.js のビルドとは 独立した型チェックジョブ として用意する（ビルド成功 ≠ 型 OK なので）。 実験段階の tsrs は continue-on-error: true で「落ちても CI 全体は止めない」状態から始め、出力差分（診断順の違いなど）や速度を観察する。 十分に信頼できると判断できたら、tsc を tsrs に置き換えて CI 時間を短縮する、という移行パスを描けます。 今後の展望 Theo Browne 氏の tsc-rs と tsrs を統合し、LSP やコンテンツマッパーを含む TypeScript のフル機能をサポートする単一パッケージを目指しています。 Cloudflare が Next.js のポートである Vinext で実践しているのと同様に、エージェントを使ってアップストリーム TypeScript との差分を日次で追従・検証していく運用が計画されています。 パフォーマンス改善は可能な限り TypeScript の Go 実装側へも還元し、エコシステム全体が恩恵を受けられるようにするとしています。 さらに Oxlint の型を考慮した Lint ルールなど、tsrs を他ツールと深く統合する実験も視野に入っています。 まとめ tsrs は TypeScript コンパイラの Rust ポートで、最大 8 倍高速・メモリ約 70% 削減という大きな性能向上が期待できます。 Vite / Next.js は ビルド時に型チェックをしない ため、型の正しさを担保するには 別途 CI などで型チェックを回す仕組みが必須 です。 従来 CI の型チェックは「遅い・重い」が課題でしたが、tsrs によってそのコストが下がれば、フィードバックループが短くなり開発体験が大きく向上します。 まだ実験段階なので、まずは既存の tsc と並走させて差分・速度を観察し、信頼できたら置き換える、という段階的な導入がおすすめです。 参考リンク Introducing tsrs: a Port of TypeScript to Rust（Cloudflare Blog） tsrs（GitHub / oxc-project） tsrs（npm）
Theo's port is tsc-rs[0] as reference, and is significantly slower and uses more memory than this new version. [0] pingdotgg/ts-rust
TS-Rust itself is fully compatible though, we use it for all the type checking in T3 Code and it's been awesome for us pingdotgg/ts-rust
@super6plx @localhost_5173 TS-Rust itself is fully compatible though, we use it for all the type checking in T3 Code and it's been awesome for us pingdotgg/ts-rust
Топ-10 GitHub за 3 дня: ИИ-пентестер и Word на Rust 10 новых open-source проектов GitHub за 7–10 октября 2026, быстрее всех набравших звёзды: ИИ-пентестер, аналог Word на Rust и драйвер NVIDIA для macOS. 1. mhtsec/ARTEX — ИИ-система, которая сама проводит тест на проникновение. (Go, +2684 ★) 2. storytold/wordcraft — Открытый аналог Microsoft Word, написан с нуля на Rust. (Rust, +2426 ★) 3. nullmoth/nvidia-macos-driver — Драйвер Metal для видеокарт NVIDIA RTX на macOS 15 Sequoia. (Rust, +2104 ★) 4. storytold/cadcraft — Открытая САПР в духе AutoCAD на чистом Rust. (Rust, +1557 ★) 5. alejandrobujan/tendedero — Маленькое приложение для macOS: скриншоты висят на верёвке сверху экрана. (Swift, +1390 ★) 6. noahdunnagan/fsearch — Поиск файлов по всему диску на macOS. (Rust, +1358 ★) 7. LoreanXavier/pt-pc — Нативный порт P.T. на PC. (C++, +1254 ★) 8. pingdotgg/ts-rust — Экспериментальный порт компилятора TypeScript 7 (tsc) на Rust. (Rust, +845 ★) 9. HelixDB/helix-foundry — Локальное рабочее пространство для данных компании. (TypeScript, +700 ★) 10. bas3line/ascii — Анимированный ASCII-арт для веб-страниц на TypeScript. (TypeScript, +693 ★) Источник: GitHub Search API, репозитории созданы с 2026-10-07, отсортированы по звёздам. Лидер: mhtsec/ARTEX Остальные: storytold/wordcraft, nullmoth/nvidia-macos-driver, storytold/cadcraft, alejandrobujan/tendedero, noahdunnagan/fsearch, LoreanXavier/pt-pc, pingdotgg/ts-rust, HelixDB/helix-foundry, bas3line/ascii #GitHub #opensource #программирование Каждые 3 дня — 10 новых open-source проектов GitHub, быстрее всех набравших звёзды. Подписывайся, чтобы не пропустить следующий выпуск.
AI Rewrote TypeScript in Rust. Can You Trust It? AI rewrote Microsoft's TypeScript compiler in Rust, and the README says nobody read the code. It passes all 181,711 of the ported tests. So can you ship code nobody read? Four big AI coding projects this year (tsc-rs, Anthropic's C compiler, Bun, GitHub Copilot) show what decides it, what broke, and a four-point checklist if you're thinking about a rewrite. Sources are on screen and below. 0:00 The README that says nobody read the code 0:39 The Rust port nobody read 1:31 The answer key 2:31 Bun: 535,496 lines in 11 days 3:24 GitHub: 18x faster, and what slipped through 5:27 What the tests can't see 6:50 If you're eyeing a rewrite 7:46 The question SOURCES (primary pages; numbers are the authors' own unless marked) - tsc-rs (ts-rust) README: pingdotgg/ts-rust - Microsoft, "Announcing TypeScript 7.0": devblogs.microsoft.com - Anthropic, "Building a C compiler with a team of parallel Claudes": anthropic.com - Bun, the Zig-to-Rust port post: bun.com - GitHub, "Migrating the GitHub Copilot runtime to Rust, using Copilot": github.blog Context.md: AI news with the footnotes, with the sources on screen. Subscribe if you want the receipts.