2026年10月7日、Theo Browne 氏が ts-rust リポジトリをオープンソースとして公開した。対応する npm パッケージ名は tsc-rs である。これは、マイクロソフトが Go 言語で再実装した「TypeScript 7」のコンパイラ、型チェッカー、そして LSP（Language Server Protocol）の全システムを Rust へと移行するという巨大な移植プロジェクトだ。プロジェクトは上流のアルゴリズム構造、動作パターン、コマンドラインインターフェース、API を忠実に踏襲しており、コードの状態は 2026-09-29 時点の TypeScript 7.1.0-dev（リビジョン 673a5f17d713）に厳格に固定されている。同一の開発タスクに対し、二大フロンティアモデルファミリーは所要時間と消費コストの両面で一桁もの開きがある対照的な請求書を突きつけることとなった。
額面40万ドルのAPIトークンと、実質2.4万ドルのサブスクリプション支出
作者が最初に取り組んだ試みは、GPT-5.6 Sol と GPT 6 Astra に依存していた。これら2つのモデルは数か月にわたる自律的な /goal ループの中で、API 定価換算で40万ドル以上におよぶトークンを消費し、130万行もの Rust コードを出力したものの、最終的に84%前後の互換性で行き詰まり、それ以上の前進が完全にストップしてしまった。その後 Claude Opus 5.5 へと切り替えたところ、移植工程の全体がわずか2週間で完了した。作者は X 上で「Codexのトークンを約40万ドル分燃やしても何も得られなかったが、Opusに約2万ドル投じたら2週間で完了した」と率直に振り返っている。
この40万ドルという金額は API の定価ベースで換算した額面に過ぎず、実際に Opus の利用で生じたキャッシュアウトは、上位サブスクリプションプランの利用枠を活用した約2万4,047ドルにとどまった。この金額は、週200ドルの利用枠プランにおける 925%〜983% に相当する。超長期にわたるエンジニアリングタスクの成否を分ける最大のボトルネックは、モデルが長大なコンテキストを維持し続けられるか、そして過去の出力物が破綻していると察知した際に躊躇なくすべてを白紙に戻せるかにある。同様のタスクを API 定価で支払い続ければ中小チームの資金ショートを招くことは必至であり、本プロジェクトが成立したのもサブスクリプション枠の活用があってこそだった。
図：2回にわたる移植試行のトークン費用と所要時間の比較。出典：@theo / X
130万行のコードを捨て去る勇気：ゼロからの書き直しという意思決定
Opus 5.5 を投入した際、モデルは Astra が残した130万行のコードに継ぎ接ぎを当てる道を選ばなかった。過去のコードベースを完全に修復不能と見なし、まっさらな crate を新規作成してゼロから再構築を開始したのだ。わずか10時間後には実用的な v0 バージョンを組み上げ、前任モデルが数週間にわたって足踏みしていた進捗を一瞬で追い抜いた。
数十万トークンにおよぶコンテキストの重圧下において、粗悪な生成物を思い切って破棄し、土台から作り直せる決断力こそがプロジェクトの頓挫を防ぐ分水嶺となる。長大なライフサイクルを伴うコード生成タスクでは、無理にパッチを重ねることが予期せぬ連鎖破綻を引き起こす。破綻したコードにパッチを当て続けるよりも、完全に推し直すほうが遥かに効率的であり、この判断は人間が囚われがちなサンクコスト効果という直感を軽々と打破した。
18万1,711件の上流テストが担う防衛線
スター数 572、コミット数 5,963 を誇るこの MIT ライセンスリポジトリの README の警告欄には、作者による象徴的な一言が記されている。「私はこのコードを1行も読んでいない」。それどころか、区切り線より下の README 本文すらすべて Claude Code が執筆したものだ。1行たりともコードを精読していない超巨大プロジェクトをそのまま一般公開できた自信の根拠は、Go 版から移植された 18万1,711 件のテストスイートがすべてパスしたという客観的事実にある。
検証段階において、TanStack Query core や Hono の型検査ログは Go 版の出力と1件ずつ完全に一致し、言語サーバー（LSP）と API の応答もオラクルテストセット上で上流と完全に符合した。120件のオープンソースリポジトリでの実測でも、CLI の出力差分はごく少数の既知の問題を除いて皆無だった。巨大な LLM 生成コードの信頼性は、上流の堅牢なテストスイートという防衛線によってのみ担保される。人間の限られた認知帯域に頼った「コードレビュー」という検証プロセスは、信頼の環からすでに切り離されている。
図：ts-rust リポジトリのソーシャルプレビューカード。出典：GitHub
Bunには及ばずとも、Effect診断の内蔵で実利を奪取
作者は Apple M4 Pro チップ環境で hyperfine を用いて5回測定を行い、その中央値から客観的なパフォーマンスを導き出した。6つのオープンソースプロジェクトを対象とした型検査において、tsc-rs の幾何平均速度は tsc 7 の 1.61倍を記録した。375万行の VS Code プロジェクトでは、tsc 6 が 54.56秒、tsc 7 が 6.84秒を要したのに対し、tsc-rs は 4.20秒まで短縮した。現在公開されているプレビューパッケージでは PGO や BOLT によるプロファイル最適化が施されていないため、正式版の実測値はさらに高速化する見込みだ。もっとも、Bun が提供する bun check は同テストを 1.62秒で走破しており、最速の座は依然として揺らいでいない。
一方で、特定のエコシステムに特化した診断においてアーキテクチャ統合の真価が発揮された。T3 Code に含まれる5つのプロジェクト合算テストでは、Effect の独自検査を省いた場合、tsc-rs は 7.25秒（tsc 7 は 16.10秒）で終了した。これに対し Effect 診断（エラーコード 377xxx）を有効にした場合、tsc-rs は 11.13秒を記録し、tsc 7 と @effect/tsgo を組み合わせた場合の 21.07秒を大きく引き離した。Effect 診断が組み込み機能としてメインの検査パイプラインに統合されたことで、2回目の構文解析スキャンにかかるオーバーヘッドが丸ごと削減されたのだ。開発者は npm install -D tsc-rs を実行するだけで、この完全な組み込み診断チェーンを利用できる。
プラットフォームの制約と「計算リソースの採算性」を巡るコミュニティの疑念
初期段階の実験的プロジェクトとして、tsc-rs には現時点で厳格な動作制約が存在する。現状サポートされているのは Linux x64（静的リンク）および macOS arm64 アーキテクチャのみで、Windows および Linux arm64 環境は未対応のままだ。既知の問題として、一部のモノレポ構造で TS6059 エラー（ファイルが rootDir の配下に存在しないという警告）が送出される点や、tsc -b のビルドキャッシュから古い出力が残る場合がある。興味深いことに、報告された最初の5件の Issue のうち4件は、上流である TypeScript 本体の既存の挙動を忠実に再現したものだった。移植ツールが上流の挙動をピクセル単位で再現するとき、上流のバグや欠陥もまた忠実に「仕様」として継承されることになる。
Hacker News の議論では、技術的な実装詳細を超えて、より本質的な価値観の衝突が起きた。40万ドルあれば優秀なコンパイラエンジニアをフルタイムで雇用できたはずだと電卓を叩き、なぜその資金をコンピュートクラスタに注ぎ込むのかと疑問を投げかける声が上がる一方で、40万ドルはあくまで API の見かけ上の額面であり実支出は2.4万ドルにすぎないと反論する者も現れた。さらに、莫大な計算リソースを消費しながら人間が1行も目を通さずに公開する姿勢に対する懐疑論や、リポジトリの README 自体が Claude Code のプロモーションではないかという冷めた見方も示された。コーディングの参入障壁がサブスクリプション費用へと引き下げられたいま、ソフトウェア工学の議論の重心は「コードをどう書くか」から「機械の計算力と人間の対価の換算式」へと移り変わろうとしている。
参考リンク：
- Theo Browne による X での声明
- pingdotgg/ts-rust リポジトリ README
- TypeScript の AI 書き直しに関するコミュニティの議論
