ハクソク

世界を動かす技術を、日本語で。

VercelのScriptc: TypeScriptからネイティブへのコンパイラ、バイナリにJavaScriptエンジンなし

2026年7月27日原文(github.com)

概要

scriptc は、TypeScriptコードを ネイティブ実行ファイル に直接コンパイルするツール。 Node.jsやV8 などのランタイム不要で、 高速・小型バイナリ を生成。 コード変更や独自記法は不要で、既存のTypeScriptと完全互換。 静的解析で99% 以上のコードをネイティブ化し、残りは明確な診断付きで処理。 幅広い標準・Node APIをサポートし、 パフォーマンスと互換性 を両立。

scriptcの特徴

  • TypeScriptをそのまま ネイティブバイナリに変換
  • NodeやV8 などのJavaScriptエンジン不要
  • コード変更やアノテーション不要、既存のTypeScriptで動作
  • 高速な起動時間 （約2ms）、小型バイナリ（170〜200KB）
  • 静的解析 による高いネイティブ化率（99%以上）
  • 標準ライブラリやNode API の広範なサポート
    • fs、path、process、crypto、http/https、zlib、timers、net、fetchなど
  • npm依存パッケージ にも対応（--dynamicオプション）
  • 型安全性 と メモリ安全性 を重視した設計
  • 差分テスト と アドレスサニタイザ による品質保証

インストールと環境

  • npm によるグローバルインストール
    • npm install -g scriptc
  • clang 必須（macOSはXcode Command Line Toolsに同梱）
  • macOS arm64 が主プラットフォーム
    • Linux/Windowsもクロスコンパイルで対応
  • tsconfig.json や @types/node も利用可能

静的/動的/拒否の3段階判定

  • 静的コンパイル ：デフォルト。ネイティブコードのみで実行
  • 動的実行（--dynamic） ：QuickJSエンジンを埋め込み、静的化できない部分のみ実行
    • npm依存やany型など、動的要素もサポート
    • 静的⇔動的間の値は 型チェック を厳格に実施
  • 拒否 ：未対応構文は明確なエラーとヒントを出力

サポートされるTypeScript・標準API

  • クラス、継承、クロージャ、ジェネリクス、分岐型、async/await、例外、デストラクチャリング など
  • UTF-16文字列、配列、Map/Set、JSON、Math、Buffer、Error階層 など
  • Node API ：fs、path、process、child_process、os、crypto、url、zlib、timers、net、http、https、tls、dgram、dns、fs.watch、readline
  • WHATWG fetch/Web API ：fetch、Streams、Headers、AbortSignalなど
  • npm依存 ：--dynamic時に埋め込み、ビルド時にバイナリ化

パフォーマンス比較（Apple Mシリーズ）

  • 起動時間 ：~2.4ms（Nodeは~47ms、Zig並み、Go/Rustより高速）
  • バイナリサイズ ：170–200KB（--dynamic時は~3MB、Node SEAは60–100MB）
  • メモリ使用量 ：1–4MB（Nodeは67–116MB）
  • 数値演算 ：JS完全互換、Nodeとバイト単位で一致

安全性・正確性の担保

  • 差分テスト ：800以上のテストケースでNodeとバイナリ出力を比較
  • メモリ安全 ：AddressSanitizerによる全ケース検証
  • 意図的なNodeとの差異 は全てドキュメント化

エスケープハッチ・拡張

  • comptime ：ビルド時にTypeScriptをVMで実行し、結果をリテラルとして埋め込み
  • Native FFI（--ffi） ：TypeScript型宣言でC ABIに直接バインド
  • --dynamic ：npm依存や動的コードもサポート
  • Checked casts ：JSON.parseなどの型アサーションもランタイムで検証

アーキテクチャ概要

  • TypeScript → tsc（パース・型チェック） → IR → C → clang → ネイティブ実行ファイル
  • Cランタイム ：参照カウント付き値、イベントループ、サーバースタック、数値演算
  • 機能単位でリンク ：必要な機能のみバイナリに含める設計

開発・テストフロー

  • pnpm による開発・ビルド・テスト
    • pnpm install && pnpm build
    • pnpm test（差分テスト・診断スナップショット）
    • SCRIPTC_SAN=1 pnpm test（ASan＋参照カウント監査）
  • IRやC出力 もオプションで取得可能（--emit-ir）

まとめ

  • Node互換のTypeScriptコード を 高速・安全なネイティブバイナリ に変換可能
  • 静的解析と厳格なテスト による高い信頼性
  • 幅広いAPIサポート と npm依存対応 で実用的なアプリケーション開発が可能

Hackerたちの意見

Porforrhttps://porffor.dev>は、しばらくの間同じ目標に向かって取り組んでいるね。クリエイターのCanadaHonkhttps://honk.foo>はめっちゃ才能があるし、プロジェクトはまだTest262の約68%しか通過してない。Vercelがこんなに早く進展したのはちょっと疑わしいな。プロジェクトの範囲を誤解してるのかもしれないけど。

└

Vercelがこんなに早く進展したのはちょっと疑わしいな。コーディングエージェントたち。彼らは1週間で918,000行のコードを作ったんだって: https://github.com/vercel-labs/scriptc/graphs/contributors?s...

TypeScriptの強みの一つは、その表現力だけじゃなくて、膨大なnpmエコシステムと互換性があることだね。ほとんどのパッケージは型宣言でインターフェースを定義した未型のJavaScriptしか出荷しないから、実際にはパッケージを使うならJavaScriptエンジンが必要になる。だけど、もしゼロから始めてnpmパッケージを使わないって分かってるなら、AssemblyScriptを使うのもアリだよ。[0] TypeScriptでパッケージを公開するのはNodeによって明示的に推奨されてないし、TypeScriptはマイナーリリースでも後方互換性がないし、コンパイラの設定もパッケージに対してポータブルじゃない。[1]: https://github.com/nodejs/node/blob/main/doc/api/typescript.... [2]: https://www.assemblyscript.org/

└

実際にはパッケージを使うならJavaScriptエンジンが必要になるみたいだね。Scriptcの解決策は、依存関係を実行する必要がある場合に620KBのquickjs-ng JavaScriptエンジンをオプションでバンドルできることみたい。

└

それは未型ライブラリを公開する良い理由だね、確かに。でも、その理由が型の価値を上回るって主張はちょっと驚きだよ、正直言って！

└

依存関係が多いコードには使わないけど、より大きなTypeScriptプロジェクトとコードを共有するための集中したコマンドラインツールには使うかな。

READMEがClaudismsでいっぱいなのは無視できないね。

└

PRは積極的に受け入れられてるみたい。さっき一つ消してきたよ！ https://github.com/vercel-labs/scriptc/commit/c4b68dc6d9c259...

VercelがAIの影響で信頼を失っていくのを見るのは面白いね。彼らの製品は元々好きじゃなかったから、業界にはプラスになると思うよ :)

Vercel、また注目を集めようとしてるね。毎月のようにやってるし、ニュースに載り続けたいんだろうな。正直、これを使う真剣な企業やプロジェクトは思いつかない。追記：貢献者リストを見たけど、彼らにはすごく敬意を払ってる（特にsimonwね）。でも、このコードはちょっと怪しい感じがするし、貢献者には入ってないのがさらに疑わしい。

└

これはすごい貢献だね ;-) https://github.com/vercel-labs/scriptc/commit/725b931cf43ba7...

└

貢献タブを見ると、99%が1人によって vibe-coded されてるみたいで、彼らにコンパイラのバックグラウンドはなさそうだね。追記：タイプミス

Hacker Newsで議論の続きを見る