2026年7月下旬、Vercel Labsが「scriptc」というオープンソースのコンパイラを公開しました。ライセンスはApache-2.0で、掲げるコンセプトは「Zero-runtime TypeScript」です。通常のTypeScriptを、NodeもV8もJavaScriptエンジンも同梱しない小さく高速なネイティブ実行ファイルへ変換する、と明記されています。サーバーレスやエッジでNode.jsアプリを運用してきた立場からすると、コールドスタートやメモリ消費の常識を揺さぶりかねない発想です。本記事では、GitHubのREADMEを主な事実の根拠として、scriptcの技術的な仕組みと実測値、そして実運用でどう見極めるべきかを整理します。

scriptcが掲げるZero-runtimeという発想

これまでNode.jsアプリを単一ファイルとして配布したい場合、Node.js自体のSEA（Single Executable Application）やDeno、Bunといった選択肢が使われてきました。いずれも便利ですが、共通しているのは「JavaScriptランタイムをまるごとバイナリに同梱する」という発想です。実行ファイルの中にJSエンジンが入っており、起動時にそのエンジンがコードを解釈して動かします。

scriptcのアプローチはここが根本から異なります。READMEは「no Node, no V8, no JavaScript engine in the binary」と述べており、生成されるバイナリからJavaScriptエンジンそのものを排除するという主張です。つまりランタイムを軽量化するのではなく、可能な範囲でランタイムを存在させないという方向にかじを切っています。この「Zero-runtime」という言葉が、scriptcを理解するうえでの出発点になります。

本物のtscから始まる3層コンパイルの仕組み

scriptcの変換パイプラインは、TypeScriptを本物のtsc（TypeScriptコンパイラ）でparseして型チェックし、loweringを経て型付き中間表現であるTyped IRに変換し、そこからC言語のコードを生成し、最後にclangでネイティブ実行ファイルへコンパイルする、という流れをとります。コードジェネレータはLLVMをデフォルトとし、Cを透過的なフォールバックとして用いる構成です。既存の型システムを自前で再実装するのではなく、実績あるtscをそのまま型検査に使う点が特徴といえます。

そのうえでscriptcは3層（three-tier）モデルを採用しています。第1層は静的にネイティブコードへコンパイルする既定の経路です。第2層は静的コンパイルできないコードを、埋め込みのJSエンジンであるquickjs-ng（約620KB）で動的に実行する経路で、--dynamicによるオプトインです。第3層は対応できない構文をコンパイル時に固有の診断エラーで拒否する経路で、たとえばSC1090のようなエラーコードが割り当てられています。この3層があることで、静的化できる部分はネイティブに、できない部分はエンジン実行か明示的な拒否へと振り分けられます。

正当性の担保も設計に組み込まれています。READMEによれば、800を超えるコーパスプログラムをNodeとネイティブバイナリの両方で実行し、標準出力・標準エラー・終了コードがバイト単位で一致することを求める差分テスト（differential testing）を行い、AddressSanitizerによるメモリ安全性の検査も実施しているとされています。

既存の単一バイナリ化と何が根本から違うのか

ここで、既存の単一バイナリ化とscriptcの違いを改めて整理します。Node.jsのSEAやDeno、Bunがランタイムを同梱する方式であるのに対し、scriptcはJavaScriptエンジン自体をバイナリから排除し、可能な範囲で真にネイティブなコードを生成します。前者は「エンジンごと持ち運ぶ」、後者は「エンジンを持たずに動くコードへ変換する」という違いです。

この違いは配布サイズや起動特性に直結します。ランタイム同梱型は、アプリのコード量にかかわらずエンジン分の重量がバイナリに乗ります。一方でscriptcは、静的化できたコードについてはエンジンを介さずに動くため、原理的に小さく速いバイナリを狙えます。ただしscriptcもnpm依存や静的化できないコードのためにquickjs-ngを埋め込む選択肢を持っており、その場合は限定的にエンジンを内包する形になります。二者択一ではなく、静的化率に応じて中間の姿もとりうると理解しておくのが正確です。

GitHub READMEのベンチマークが示す実測値

効果を語るうえで数値は欠かせませんが、ここで示す値はすべてGitHub READMEのベンチマークに掲載されたものに統一します。scriptcの公式サイトのトップページには別の丸めた数値も存在するため、混同を避けてREADME系の値のみを引用します。

この表が示すのは、静的化できたケースでの桁違いの差です。起動時間は約2.4msというごく短い水準で、メモリのRSSも一桁メガバイトに収まっています。動的実行を有効にした場合でもバイナリは約3MBで、埋め込むquickjs-ngは約620KBです。なお「Node.jsのバイナリは60〜100MB」という比較が各種報道によれば語られていますが、これはREADMEでは確認できないため、本記事の主軸にはしません。READMEが示すのはあくまでメモリRSSの67〜116MBという比較値です。数値はあくまでREADME掲載のベンチマークであり、自社の実環境で再測定すべきものだという前提を忘れないようにします。

現時点の制約と向き不向きを冷静に見る

魅力的な数値の一方で、scriptcはフルなNode.js API互換ではありません。静的コンパイル（第1層）できるのは対応する構文とAPIに限られ、READMEはfsやpath、process、child_process、os、crypto、url、zlib、net、http/https、tls、dgram、dns、readline、fetchなどを実装済みAPIとして列挙していますが、対応外の部分は--dynamicでquickjs-ng実行へフォールバックするか、第3層でコンパイルを拒否されます。

特に注意したいのは、any型のコードやnpm依存は第1層で静的化できないという点です。これらは動的実行に回るか、拒否対象になります。裏を返せば、型がきちんと付いた依存の少ないコードほど静的化の恩恵を受けやすいということです。scriptcにはscriptc coverageというコマンドがあり、対象コードがどれだけ静的コンパイル可能かを事前に割合として計測できます。全コードが静的化される保証はないという前提が、ツール自体の設計に織り込まれているわけです。

さらに、scriptcは公開直後であり、明確なバージョン番号やexperimentalといった公式ステータス表記はREADMEやトップページでは確認できませんでした。海外の技術コミュニティでは本物のブレークスルーなのか短命なプロジェクトなのかで評価が割れているとも報じられており、成熟度や継続性は現時点で断定できません。導入の意思決定では、この不確実性を前提に置く姿勢が求められます。

Ragateの現場で段階導入するなら

では、サーバーレスやエッジでNode.jsを運用してきた現場は、scriptcをどう扱えばよいでしょうか。事実に基づいて考えると、いきなり本番のサービス基盤へ載せるのではなく、影響範囲の小さいところから検証を積む進め方が現実的です。

最初の一歩はscriptc coverageで自社のCLIツールやユーティリティの静的化率を測ることです。数値が高いコードは静的ネイティブ化の恩恵を受けやすく、低いコードはanyやnpm依存が多いというサインになります。次に、コールドスタートが効くエッジやサーバーレス上の小さなツールから試します。起動が速く常駐しない用途ほど、起動時間とメモリの改善が体感につながりやすいためです。

そして、scriptcが正当性検証に採用している差分テストの考え方は、自社CIにも取り込む価値があります。同じ入力に対してNode実行とネイティブバイナリの出力・終了コードが一致するかを比較する仕組みを用意すれば、静的化による挙動差を早期に検知できます。数値や機能を鵜呑みにせず、自分たちの環境で計測し、記録を残し、チームで振り返る。この基本姿勢こそが、公開直後の技術を安全に見極める最短ルートになります。