Vercelの「scriptc」とは？TypeScriptをC経由でネイティブ実行ファイルにコンパイルする新発想を徹底解説

はじめに：TypeScriptが「ネイティブ実行ファイル」になる時代

「起動時間2.4ms、バイナリサイズ170KB」——これがVercel Labsの新しいOSSツールscriptcが叩き出した数字です。

2026年7月27日、VercelはこれまでにないアプローチでTypeScriptをネイティブバイナリに変換するコンパイラvercel-labs/scriptcを公開しました。BunやDenoのような「ランタイムをバンドルする」方法とは根本的に異なり、TypeScriptそのものをC言語経由でネイティブコードに変換するという発想で、開発者コミュニティの注目を集めています。

この記事では、scriptcのアーキテクチャからBun・Denoとの比較、実際のパフォーマンスベンチマーク、導入手順、そして現実的な制約まで、段階的に理解を深めていきましょう。

scriptcとは何か

基本情報

項目	内容
開発元	Vercel Labs
ライセンス	Apache-2.0
現バージョン	0.0.22（実験的ステータス）
公式サイト	scriptc.dev
リポジトリ	github.com/vercel-labs/scriptc

従来の「TypeScriptを配布する」方法の課題

TypeScriptで書かれたCLIツールやサーバーレス関数を配布する場合、従来は以下のような選択肢が主流でした。

Node.jsランタイムへの依存：実行環境にNode.jsのインストールを前提とする
esbundleなどでバンドル：node_modulesを同梱しても依然としてNode.jsが必要
BunやDenoのコンパイル機能：V8エンジンごとバンドルするため、バイナリが数十MBに膨らむ

コールドスタートの遅延、CLIツールの起動もたつき、配布パッケージの肥大化——これらは長年にわたる積年の課題でした。scriptcはこの問題に「TypeScriptをネイティブコードに変換する」という根本的なアプローチで挑んでいます。

scriptcのアーキテクチャ：TypeScript → C → ネイティブ

コンパイルパイプラインの全体像

scriptcのコンパイルプロセスは次のように進みます。

TypeScript
  ↓ tsc 型検査
型付き中間表現（IR）
  ↓ Cコード生成
C言語コード
  ↓ clang / LLVM
ネイティブバイナリ

「C言語を中間表現として使う」という選択が本ツールの最大の特徴です。CはLLVMと組み合わせることで成熟した最適化パスを利用でき、クロスプラットフォームのバイナリ生成も容易になります。TypeScriptの静的型情報をそのままC言語の型体系にマッピングすることで、JavaScriptエンジンを介さない真のネイティブ変換を実現しています。

3ティア構成という設計思想

scriptcは「どんなコードも無理やりコンパイルする」のではなく、コードの性質に応じて3つのティアで処理を分けています。

Tier 1（Static）：JSエンジン不要の完全ネイティブ

静的型が完全に付いたTypeScriptコードは、JavaScriptエンジンを一切使わないネイティブバイナリに変換されます。これが冒頭の「2.4ms・170KB」を実現しているモードです。実際の開発現場では、厳格な型付けを維持しているコードベースほど、この恩恵を最大限に受けられます。

Tier 2（Dynamic）：QuickJS-ngへのフォールバック

any型が含まれるコードやnpmパッケージへの依存がある場合、--dynamicフラグを使うことでQuickJS-ng（約620KB）を埋め込んだバイナリを生成します。この場合、バイナリサイズは約3MBになりますが、より広いコードベースへの対応が可能になります。

Tier 3（Rejected）：明示的な拒否という思想

サポートできない構文に対しては「動くけど遅い」状態で出力するのではなく、SCxxxx形式のエラーコードで明示的にコンパイルを拒否し、修正提案を提示します。これは「あいまいさを許容しない」という設計哲学であり、開発者体験の観点からも一貫した姿勢といえます。

対応しているNode.js API

技術的に正確な表現を心がけると、現時点では以下のAPIを標準でカバーしています。

fs / path / process / child_process / os / crypto / url / zlib / net / http / https / tls / dgram / dns / readline / fetch

CLIツールや軽量なHTTPサーバーを構築するうえで必要な主要APIはほぼ揃っています。

BunやDenoと何が違うのか

「ランタイムをバンドルする」vs「ネイティブコードに変換する」

この違いを理解することが、scriptcの本質を把握する鍵です。

ツール	アプローチ	バイナリの性質
Node.js SEA	V8エンジン + コードをバンドル	JSエンジン内包の大バイナリ
Bun（compile）	JSCエンジン + コードをバンドル	JSエンジン内包の大バイナリ
Deno（compile）	V8エンジン + コードをバンドル	JSエンジン内包の大バイナリ
scriptc	TypeScriptをCに変換してネイティブ化	JSエンジン不要の真のネイティブバイナリ

BunやDenoの「コンパイル」は厳密に言えば「ランタイムごとパッケージング」であり、バイナリサイズが数十MBになる構造的な理由がここにあります。scriptcはJavaScriptエンジンそのものを排除することで、桁違いの軽量化を実現しています。

どちらを選ぶべきか

汎用性・エコシステム互換を優先するなら：Bun / Deno。npmのエコシステムをフルに活用でき、既存のTypeScriptコードをほぼそのまま動かせます。
起動速度・配布サイズを極限まで削るなら：scriptc。ただし静的型付けの厳格な維持が前提になります。

パフォーマンスベンチマーク：数字で見るインパクト

起動時間：Node.js SEAの約20倍高速

ツール	起動時間
scriptc（Tier 1）	2.4ms
Bun（compiled）	約10ms
Node.js SEA	35〜47ms

CLIツールでは起動時間がそのままUXに直結します。Node.js SEAと比べて約20倍高速という数値は、インタラクティブなツール開発において実感しやすい差です。

バイナリサイズ：400分の1以下

ツール	バイナリサイズ
scriptc（Tier 1）	170〜200KB
Bun（compiled）	約50MB
Node.js SEA	60〜100MB

CI/CDパイプラインのアーティファクト転送、コンテナイメージのプル、エッジへのデプロイ——あらゆるシーンでこのサイズ差が効いてきます。

メモリ使用量（RSS）：1〜4MB

Node.js SEAが67〜116MBのRSSを消費するのに対し、scriptcは1〜4MBに収まります。サーバーレス環境での課金やコンテナの密度向上において、この差は無視できないインパクトを持ちます。

ベンチマークを読む際の注意点

これらの数字はすべて**Tier 1（完全静的コンパイル）**での計測値です。any型が混在してTier 2にフォールバックした場合は、バイナリサイズが約3MBになり、起動時間やメモリ効率も変化します。ベストプラクティスとして、数字を評価する際はコードのTier適合率を必ず確認してください。

実用上のメリットとユースケース

シングルバイナリ配布

生成されたバイナリは単一ファイルで動作します。Node.jsのインストール、node_modulesの同梱、ランタイムのバージョン管理——これらすべてが不要になります。GitHubリリースへのバイナリ添付やHomebrewでの配布が格段にシンプルになります。

CLIツール：起動遅延ゼロへ

npx経由でTypeScript製CLIを実行するときのもたつきは、多くの開発者が体験したことがあるはずです。scriptcでコンパイルしたバイナリならその遅延がほぼゼロになり、シェルスクリプトに近い体感を実現できます。

コンテナ・サーバーレス：コールドスタート問題の解消

AWS LambdaやVercel Functionsのようなサーバーレス環境では、コールドスタートのレイテンシが問題になりがちです。起動2.4ms・170KBのバイナリは、この問題を根本から解決するアプローチとして注目されています。

クロスプラットフォーム対応

macOS、Linux、Windowsに加え、WebAssembly（WASI）もターゲットに含まれます。一つのTypeScriptコードベースから複数プラットフォーム向けのネイティブバイナリを生成できます。

使ってみる：OSSとしての導入手順

インストール

npm install -g scriptc

基本のビルド

scriptc build index.ts

静的コンパイル適合率のチェック（最重要コマンド）

scriptc coverage index.ts

このコマンドは、既存コードのどの割合がTier 1でコンパイル可能かを事前にレポートしてくれます。移植を検討する際はまずこのコマンドを実行し、Tier 1適合率を把握することをベストプラクティスとして強く推奨します。any型の多いコードベースでは、ここで現実を直視することが重要です。

動的モードでのビルド

scriptc build --dynamic index.ts

Tier 1で対応できないコードもTier 2でコンパイルしたい場合は--dynamicフラグを追加します。

導入前に知っておくべき制約と注意点

「80%問題」：実リポジトリの約8割が`any`型を使用

実際の開発現場では、TypeScriptのany型は驚くほど広範に使われています。scriptcの調査によれば、実際のOSSリポジトリの約80%がany型を含んでおり、その場合はTier 2にフォールバックします。Tier 2でもNode.js SEAより軽量ではありますが、Tier 1の劇的なメリットは享受できません。

逆に言えば、scriptcの登場は「TypeScriptの型を厳格に書くと実行バイナリが速くなる」という新しいインセンティブを開発者にもたらすともいえます。型の厳格化が、単なるコード品質の話を超えて実行性能に直結する時代が来るかもしれません。

初期コミット80万行と「Claudisms」問題

コミュニティでは、初期コミットが80万行という規模に加え、コード中にAI生成コードを示唆する「Claudisms」（Claude特有の表現パターン）が見られるとして、長期的な保守性に懸念を示す声もあります。OSSとしての持続的なメンテナンス体制については、引き続き動向を注視する必要があります。

バージョン0.0.22という実験的ステータス

公式に「実験的」と明示されている通り、APIや挙動は今後変わる可能性があります。本番環境への採用は慎重な評価を前提とし、まずは社内CLIツールや小規模なユーティリティスクリプトなど、影響範囲の限定されたユースケースから試し始めるのが現実的な選択です。

まとめ：scriptcは「配布の革命」になりうるか

scriptcは、BunやDenoとは根本的に異なるアプローチでTypeScriptをネイティブバイナリに変換するツールです。「ランタイムをバンドルする」のではなく「TypeScriptをネイティブコードに変換する」という発想の転換が、起動2.4ms・バイナリ170KBという驚異の数値を生み出しています。

現時点での現実的な立ち位置を整理すると：

Tier 1の恩恵を受けられるのは、any型を使わない厳格な型付けのコードベースに限られる
CLIツールや軽量サーバーレス関数は最も相性の良いユースケース
バージョン0.0.22という実験的ステータスを踏まえ、本番採用には段階的なアプローチが適切

「静的型付けを守ればネイティブ並みの性能を得られる」という新しい価値観が普及すれば、TypeScript開発の文化そのものを変えるインパクトを持つかもしれません。Vercel Labsの今後のアップデートに注目していきましょう。