Vercelのscriptc登場：TSをネイティブ化しNode.js依存を脱却する衝撃の性能

• Vercel LabsがTypeScriptをネイティブバイナリに変換する実験的コンパイラ「scriptc」を公開。
• Node.jsやV8エンジンを排除し、起動速度は最大12倍、メモリ消費は72倍削減という驚異的な数値を記録。
• 既存のnpmパッケージ依存や実行速度の課題が残るため、現時点では限定的なユースケースでの検証が推奨される。

深夜の障害対応で、Node.jsの巨大なランタイムと格闘した経験があるエンジニアなら、このニュースの衝撃は計り知れないはずだ。Vercel Labsがリリースした「scriptc」は、TypeScriptコードをNode.jsやV8エンジンを一切必要としないネイティブ実行ファイルにコンパイルする。これまで我々は、Webアプリケーションを動かすために、巨大なランタイムをコンテナに詰め込み、コールドスタートの遅延に頭を悩ませてきた。scriptcは、この「JavaScriptの呪縛」を物理的に断ち切ろうとしている。

具体的なベンチマークを見てみよう。scriptc 0.0.16とBun 1.3.12、Node 24.18.0を比較した際、CLIの起動時間はNodeが61.78ms、Bunが21.29msであるのに対し、scriptcはわずか1.78msという驚異的な数値を叩き出した。さらに、フレームワークなしのnode:httpサーバーにおけるアイドルメモリ消費量は、わずか1.9MiBだ。これは、マイクロサービスやエッジコンピューティングの現場において、リソース効率を劇的に改善する可能性を秘めている。

しかし、シニアエンジニアとして冷静に分析すれば、この技術には「トレードオフ」という名の高い壁が存在する。scriptcは、すべてのコードを静的にコンパイルできるわけではない。npmパッケージや型定義が複雑なコードは、埋め込まれたQuickJSエンジン（約620KB）上で動的に実行される。Honoを用いたテストでは、サーバーの62%がQuickJSに依存し、スループットはBunの70.5k req/sに対し18.4k req/sまで低下した。つまり、現状のscriptcは「万能な代替品」ではなく、特定のホットパスを最適化するための「外科手術ツール」に近い存在だと言える。

「既存のプロジェクトをすべてscriptcでバイナリ化すれば、サーバーコストが激減するのではないか？」という期待は、残念ながら現時点では幻想に近い。実際にローカルのプロジェクトで試した開発者からは、カバレッジ生成時に数百ものエラーが発生するという報告が上がっている。TypeScriptの柔軟な型システムと、ネイティブコンパイルの厳格さの間には、埋めがたい溝があるのだ。特に、サードパーティライブラリへの依存が深い現代のWeb開発において、これらをすべて静的に解決するのは至難の業である。

また、Vercelの過去のプロジェクトである「zerolang」が短期間で開発停止した経緯を鑑みると、コミュニティには「この技術は本当に長続きするのか？」という根深い不信感がある。技術的な面白さと、ビジネス上の安定性は別物だ。もしあなたが明日から本番環境への導入を検討しているなら、まずはCLIツールや、依存関係が極めて少ないエッジ関数の一部から適用範囲を限定すべきだ。以下に、scriptcの現状の特性を整理した。

結局のところ、scriptcは「JavaScriptの書き心地」と「ネイティブの実行効率」という、これまで両立不可能だった二つの聖杯を同時に追い求める挑戦だ。しかし、現状ではRustやGo、Zigといった、最初からネイティブコンパイルを前提に設計された言語と比較して、パフォーマンス面で7.5倍ほど遅いという結果も出ている。我々エンジニアは、このツールを「Node.jsの完全な置き換え」として見るのではなく、「TypeScriptという言語の可能性を拡張する実験場」として捉えるべきではないだろうか。

最後に、我々エンジニアが自問すべきは「なぜ今、ネイティブコンパイルなのか」という点だ。AIエージェントがコードを生成し、修正し、デプロイする時代において、人間が書くコードの「読みやすさ」以上に、機械が解析・最適化しやすい「構造」が重要視され始めている。scriptcが目指しているのは、単なる高速化ではなく、AIエージェントがプログラムをネイティブレベルで操作・最適化するための「中間言語としてのTypeScript」の確立かもしれない。

しかし、技術の流行り廃りに振り回されるキャリアは、もはや持続可能ではない。Vercelが提供する新しいインフラやツールは魅力的だが、それらに依存しすぎることは、自らの技術的基盤を特定のベンダーに預けるリスクを伴う。あなたが明日から取るべき対策は、scriptcを盲信することではなく、自身のアプリケーションが「なぜNode.jsのランタイムを必要としているのか」を再定義することだ。もし、その依存が単なる慣習であるならば、GoやRustへの移行を検討するのか、それともscriptcのような新しいパラダイムに賭けるのか。技術選定の責任は、常に現場のエンジニアにある。

我々は、この実験的なコンパイラを「実務で使えるか否か」という二元論で語るべきではない。むしろ、このツールが突きつける「JavaScriptのランタイム依存という負債」を、我々がどう清算していくのかという問いこそが重要だ。scriptcが消えてなくなる未来が来たとしても、そこで得られた「TypeScriptをネイティブに落とし込む」という知見は、次の世代のコンパイラ技術に確実に継承される。あなたは、この破壊的な変化を傍観するのか、それとも自らの手でその限界をテストし、次世代のアーキテクチャを設計する側に回るのか。その選択が、あなたのエンジニアとしての価値を決定づけることになるだろう。