TypeScriptをネイティブバイナリに変換するRust製コンパイラ「Perry」の仕組みとできること

TypeScriptをそのまま書いて、Node.jsもElectronも不要なスタンドアロンバイナリを作れたら—。その問いに対する実装がRustとLLVMで構築されたネイティブTypeScriptコンパイラ「Perry」（GitHub: PerryTS/perry）だ。2026年4月時点でGitHubスター304を獲得し、急速に注目が集まっている。

perry compile src/main.ts -o myappの1コマンドでmacOS・Windows・Linux・iOS・Android・Webのネイティブバイナリが生成でき、出力サイズはHello Worldで約330KB。Node.jsより最大38倍高速なベンチマーク結果を公式が公開し、Rust・C++と肩を並べるパフォーマンスを一部のベンチマークで達成している。

この記事では、Perryが「何をどこまでできるか」を、RustとLLVMを採用した技術的背景とともに詳しく解説する。

Perryとは—TypeScriptをネイティブコンパイルするRust製コンパイラ

Perryは「One codebase. Every platform. Native performance.」をコンセプトに掲げるTypeScriptコンパイラだ。既存のランタイム（Node.js・Bun・Deno等）がTypeScriptを実行時に変換・解釈するのに対し、PerryはTypeScriptを直接コンパイルしてネイティブマシンコードを生成する。

Perryのパイプラインは、SWC（Rust製TypeScriptパーサー）でASTを生成し、HIR（High-level Intermediate Representation）を経由してLLVM IRに変換し、LLVMが最終的なネイティブバイナリを出力する、という多段階の変換で構成されている。

既存のTypeScriptエコシステムとの最大の差は「実行モデル」だ。Node.jsやBunはJITコンパイラを内蔵するV8エンジンまたは独自エンジンが実行時にコードを最適化するのに対し、PerryはAOT（事前コンパイル）方式で実行前に全ての最適化を済ませる。JITウォームアップ時間がなく、最初の命令から最高速で動作するため、CLIツールやサーバーレス関数のようなコールドスタートが重要なシナリオで特に有利だ。

コードベースの規模は2026年4月時点で約900万行のRustコード（一部Kotlin・Swift・JavaScript・GoなどのUI/テスト関連コードを含む）で構成されており、コンパイラ本体・ランタイム・UIライブラリ・stdlibのRust実装が1リポジトリに収まっている。

バージョン0.5.0からコードジェネレーターをCraneliftからLLVMに完全移行した。初期のLLVM導入時は多くのベンチマークでパフォーマンスが大幅に悪化したが（method_callsが16ms→1,084msに悪化）、その後スカラー置換・インラインバンプアロケーター・整数最適化等の改善で現在はCranelift時代を大幅に上回る性能を達成している。

Perryでできること—主な機能の全体像

Perryが提供する機能は、単なる「TypeScript→バイナリ変換」にとどまらない。クロスプラットフォーム対応、npmパッケージのネイティブ実装、ReactコンポーネントのネイティブUI変換、プラグインシステム、UIテスト基盤など、フルスタックのアプリケーション開発環境として設計されている。

以下に主要機能を整理する：

ネイティブバイナリの生成と特徴

Perryが生成するバイナリは、実行時に一切の外部依存を持たない。Node.jsのnode_modulesもランタイムDLLも不要で、単一ファイルを配布するだけでアプリが動く。

自動デッドコード除去により、importした関数のうち実際に呼ばれるものだけがバイナリに含まれる。巨大なnpmパッケージをimportしても、使用した関数のみがコンパイルされる設計だ。これは静的リンクとLLVMのLTO（Link Time Optimization）によって実現されている。

コールドスタートの速さも特徴のひとつだ。Node.jsはランタイムの初期化・JITコンパイルのウォームアップに数十〜数百ミリ秒かかる場合があるが、Perryのバイナリは直接マシンコードを実行するため、コールドスタートは事実上ゼロに近い。MongoDBのGUIクライアントMango（perryで構築）がサブ秒コールドスタートを実現しているのも、このアーキテクチャによる。

クロスプラットフォームコンパイル

Perryが対応するターゲットプラットフォームは以下の通り：

ホーム画面ウィジェット対応は特に注目で、TypeScriptを書くだけでiOSのWidgetKit・AndroidのGlance API・Wear OS Tilesのウィジェットが作成できる。 バックエンドではSwiftUI（iOS/tvOS/watchOS向け）とAndroid Glance API（Wear OS向け）のコードジェネレーターがそれぞれ独立したクレートとして実装されており、プラットフォーム固有のコードを自動生成する。

perry publish <platform>コマンドと組み合わせると、ローカルのTypeScriptソースをクラウドビルドサーバー「perry-hub」に送信し、各プラットフォーム向けのクロスコンパイル・コード署名・App Store/Google Play公開を1コマンドで完結させることができる。macOSのコード署名、iOSのプロビジョニングプロファイル管理など、ネイティブアプリ配布で発生する煩雑な作業をPerry CLIが吸収する設計だ。

npmパッケージのネイティブ実装

通常のnpmパッケージはJavaScriptとして動作するためJavaScriptランタイムを必要とするが、Perryはよく使われるパッケージをRustでネイティブ実装しており、--enable-js-runtimeなしで使用できる：

これらのパッケージはRustのTokioランタイム上で非同期I/Oを処理し、V8エンジンを介さずに動作する。結果として、Node.jsでは難しかった「npmパッケージを使いながらネイティブバイナリを出力する」という要件を満たしている。

ReactコンポーネントをネイティブUIに変換する「perry-react」

Perryエコシステムで特にユニークな機能が、perry-reactパッケージだ。標準的なReact/JSXのコードを書くと、ブラウザのDOMではなくOSネイティブのUIウィジェットにコンパイルされる。

macOSではAppKit、iOSではUIKit、tvOSではTVUIKit、watchOSではWatchKit、AndroidではAndroid View Systemのコンポーネントにそれぞれマッピングされ、プラットフォーム固有のルック&フィールを持つネイティブアプリが生成される。

useState・useEffect・useCallbackなど標準Reactフックはそのまま動作し、TypeScriptの型チェックも効く。Reactを知っているエンジニアが、追加学習コストなしにネイティブアプリを作れる設計となっている。

React Nativeとの根本的な違いは「ブリッジの有無」だ。React NativeはJavaScriptエンジンとネイティブ側をブリッジで接続し、実行時に通信するアーキテクチャを取る。perry-reactはコンパイル時にReactコンポーネントをネイティブUIコードに変換するため、ブリッジのオーバーヘッドが発生しない。実行バイナリにJavaScriptエンジンは含まれない。

実際にperryで構築されたMongoDBクライアントMango（MangoQuery/app）の画面はTypeScript+perry-reactで作られたネイティブアプリの実例だ：

Mangoは約7MBのバイナリサイズ、100MB未満のRAM使用量、サブ秒のコールドスタートを実現している。同等機能のElectronアプリが通常150MB超のバイナリになることと比較すると、その差は明らかだ。

プラグインシステム

Perryは共有ライブラリ（動的ライブラリ）としてコンパイルする機能も持つ。--output-type dylibフラグを指定することで、TypeScriptコードを.dylib（macOS/Linux）や.dll（Windows）として出力できる。

この仕組みを使うと、TypeScriptで書いたロジックをC・Rust・Go等の他の言語から呼び出せるようになる。PerryプラグインAPIを使えば、AIコードエディタHone（hone.codes）のようなPerry製アプリへのプラグイン拡張も可能だ。既存のエディタをPerryで書き換える際の段階的移行戦略としても使える。

UIテスト基盤「Geisterhand」

Perryには「Geisterhand」と呼ばれる組み込みUIテストフレームワークが付属している。--enable-geisterhandフラグをつけてコンパイルすると、アプリの起動時にHTTPサーバー（デフォルト: localhost:7676）が立ち上がり、HTTP経由でUIを操作・スクリーンショット取得・状態検証ができる。

WebベースのPlaywright/Puppeteerと異なり、GeisterhandはネイティブUIを対象としており、macOSのAccessibility API、iOSのXCTest UIInteraction、Androidのuiautomator2などのプラットフォーム固有のUI自動化機構をPerryが抽象化する。

Perryが対応するTypeScript言語機能

Perryは現時点でTypeScriptの主要機能の大部分を実装している。公式のtypescript-compatibility-tests.mdで詳細なテスト結果が公開されている。

ジェネリクスはコンパイル時にモノモーフ化（型パラメーターごとに専用の実装を生成）される。これはC++テンプレートと同様の手法で、実行時の型ディスパッチコストをゼロにする代わりにバイナリサイズが増加する可能性がある。型情報はコンパイル後に消去されるため、実行時にジェネリクスの型パラメーターにアクセスすることはできない。

標準ライブラリについては、console・fs・path・process・JSON・Math・Date・crypto・os・Buffer・child_process・Map・Set・setTimeout/setInterval・worker_threadsが実装されており、一般的なCLI・サーバーアプリケーション開発に必要な機能は揃っている。

Rustを採用した理由—コンパイラとランタイムの両方にRustを選ぶ意味

Perryがコンパイラ本体とランタイムの両方にRustを採用したのは、いくつかの明確な理由がある。

メモリ安全性とコンパイラの信頼性

コンパイラは複雑なデータ構造（AST・IR・型情報）を大量に操作するプログラムだ。C++で実装された伝統的なコンパイラ（GCC・Clang等）はメモリバグ（use-after-free・バッファオーバーフロー等）のリスクを常に抱えている。Rustの所有権システムはこれらのバグをコンパイル時に除去し、コンパイラ自体の安定性を保証する。

「コンパイラのバグはユーザーコードのバグよりも発見が難しい」という問題をRustの型システムが根本的に解決するのが、Rustを選ぶ最大の理由の一つだ。コンパイラのバグは誤ったコードを生成するため、バグの影響がユーザーのランタイムエラーとして現れ、根本原因の特定が非常に困難になる。Rustはこのリスクを下げる。

Rayonによる並列コンパイル

Rustのデータ並列ライブラリrayonを使い、複数モジュールのコードジェネレーション・変換パス・シンボルスキャンをCPUコア数に応じて自動並列化している。スレッドセーフティもコンパイル時に保証されるため、並列化起因のレースコンディションが発生しない。

Goの並列化ではsync.Mutexでランタイム排他制御が必要だが、Rustでは型システムが「可変参照が同時に複数存在しないこと」をコンパイル時に保証するため、ロックが不要なケースが多い。これによりrayonのスレッドプールが最大限に活用できる。

LLVMバックエンドへの移行でコンパイル時間は8〜19%増加したが、全体的なコンパイル時間の大部分はSWCパース・HIR変換・リンクであり、バックエンドそのものが支配的ではない。「LLVMは遅い」というイメージとは異なり、Perryの実装では増加幅は小さかった。

ゼロコスト抽象化によるランタイム実装

PerryのランタイムはRustで実装されており、NaN-boxing（64ビットワードで全値を表現する技法）・マークアンドスイープGC・インラインバンプアロケーターなどの低レベル最適化をunsafeコードを交えながら実装している。

GCのアリーナ走査、NaN-boxingのビット操作など、C相当のパフォーマンスが必要な部分でRustのunsafeブロックを使い、その周囲をRustの安全なAPIで包む設計だ。「安全性とパフォーマンスのトレードオフ」ではなく「デフォルト安全、ホットパスのみunsafe」という構成が実現している。

SWCとの統合コスト最小化

SWC（Speedy Web Compiler）はRustで書かれており、Perryと同一言語で記述されているため、FFIを介さずにライブラリとして直接取り込める。異なる言語間の境界でデータを変換するコストがなく、ASTの所有権もRustの型システムで安全に管理できる。

SWCはNext.js・Vercel・Denoなど主要なTypeScriptエコシステムが採用しており、TypeScript仕様への追従も速い。SWCがRust製であることにより、PerryはTypeScriptパーサーを自前で実装せずに済み、代わりに最適化・コードジェネレーション・ランタイムに開発リソースを集中できている。

LLVM IRの直接生成

LLVMのRustバインディング（llvm-sys/inkwell等）を使うことで、LLVM IRを直接生成できる。PythonやGoからLLVMを呼び出す場合と比べ、バインディングの薄さ（ほぼゼロコスト）とRustの型システムによるIR生成の正確性保証が得られる。

LLVM IRは型付きの中間表現であり、Rustの型システムとの親和性が高い。不正なIRの生成をコンパイル時に防ぎやすく、コードジェネレーターのデバッグが容易になる。

Perryのアーキテクチャ—コンパイルパイプラインの全体像

Perryのコンパイルパイプラインは、複数のRustクレートに分割されて動作する：

各クレート（Rustパッケージ）は明確な責務で分割されており、コードジェネレーターはターゲット別に独立している。追加ターゲットは新しいcodegen-*クレートを実装することで拡張できる構造だ。

リポジトリ構成は以下の通り：

perry/
├── crates/
│   ├── perry/                  # CLI（compile/run/check/init/doctor/publish）
│   ├── perry-parser/           # SWC TypeScriptパーサー
│   ├── perry-hir/              # HIRデータ構造とAST→HIR変換
│   ├── perry-transform/        # IR変換パス（クロージャ変換・async・インライン化）
│   ├── perry-codegen/          # LLVMネイティブコードジェネレーター
│   ├── perry-codegen-js/       # JavaScriptコードジェネレーター
│   ├── perry-codegen-wasm/     # WebAssemblyコードジェネレーター
│   ├── perry-codegen-swiftui/  # SwiftUIコードジェネレーター
│   ├── perry-codegen-glance/   # Android Glanceウィジェット
│   ├── perry-runtime/          # ランタイム（NaN-boxing・GC・arena・strings）
│   ├── perry-stdlib/           # Node.js API実装（fastify・mysql2・redis等）
│   ├── perry-ui-*/             # ネイティブUI（macOS/iOS/tvOS/watchOS/Android/GTK4/Windows）
│   └── perry-diagnostics/      # エラーレポーティング

ランタイムモデルとしては、シングルスレッドの非同期I/O（TokioのI/Oワーカー＋メインスレッドのコールバック）をデフォルトとし、perry/threadパッケージで明示的なマルチスレッドを使えるハイブリッド設計だ。

パフォーマンス—Node.jsを超える数字の根拠

Perryの公式ベンチマーク結果から主要な数値をまとめる（macOS ARM64、Apple Silicon、Node.js v25・Bun 1.3との比較）：

クロージャベンチマーク（38倍差）が特に大きい理由は、JavaScriptエンジンがクロージャを動的オブジェクトとして実行時に生成するのに対し、Perryはコンパイル時にクロージャを「ネイティブ関数ポインタ＋キャプチャされた変数の構造体」に変換するためだ。 ヒープアロケーションが発生せず、関数呼び出しも直接ジャンプになる。

さらに注目すべきはRust・C++との比較だ。同一のf64演算（TypeScriptのnumber型に対応）で比較すると、Perryは多くのベンチマークでRustに肩を並べるかそれを上回る：

loop_overheadでPerryがRust・C++・Goより速い（12ms vs 96ms）のは、i32ループカウンターの最適化とreassocfast-mathフラグによるLLVMのARM NEONベクトル化が効いているためだ。厳密なIEEE754準拠が不要なTypeScriptのnumber型の特性を活用し、LLVM最適化パスが並列アキュムレーター＋SIMD命令を生成できる。

主要な最適化手法の一覧：

• スカラー置換（Scalar Replacement）: 非エスケープオブジェクトをレジスタ割り当てのフィールドに分解。ヒープアロケーションをゼロにする
• インラインバンプアロケーター: エスケープするオブジェクトに13サイクルのインラインアリーナバンプを使用（関数呼び出しなし）
• i64特化: 純粋数値の再帰関数をネイティブi64レジスタにコンパイル（f64のラウンドトリップなし）
• 整数剰余fast path: fptosi → srem → sitofpでfmodを置き換え（factorialで64倍高速化）
• i32ループカウンター: ループ変数を整数レジスタで管理（f64ラウンドトリップなし）
• FMA・CSE・ループアンロール: 融合積和演算・共通部分式除去・8倍ループアンロール

競合ツールとの比較

Bunは「Node.js完全互換」を強みとし、既存のNode.jsコードをそのまま高速化するアプローチだ。一方Perryは互換性より「ネイティブバイナリ出力とクロスプラットフォーム」に重点を置く。どちらが適しているかはユースケース次第だ。

実際の使い方—インストールから動作確認まで

# macOSはHomebrewで
brew install perryts/perry/perry

# Linuxはワンライナーインストール
curl -fsSL https://raw.githubusercontent.com/PerryTS/perry/main/packaging/install.sh | sh

# 環境確認（Cリンカーの有無をチェック）
perry doctor

perry doctorコマンドで依存関係の確認ができる。エラーが出た場合は指示に従ってXcodeコマンドラインツール（macOS）やGCC/Clang（Linux）、MSVC（Windows）をインストールする。

プロジェクト作成からビルドまでの流れ：

# プロジェクト初期化
perry init my-app && cd my-app

# コンパイル
perry compile src/main.ts -o my-app

# コンパイル+実行をワンステップで
perry run .

# TypeScript互換性チェック（コンパイルなし）
perry check src/

perry checkコマンドは「このTypeScriptをPerryがコンパイルできるか」を事前に確認するためのツールだ。既存プロジェクトをPerryに移行する際の事前調査として活用できる。

ローカル環境からビルドするだけでモバイルアプリに

perry run iosを実行するとiOSシミュレーターでのビルド＆実行が行われる。Xcodeのプロジェクトファイルを手動で管理する必要はなく、PerryがSwiftUIコードを生成してビルドパイプラインを処理する。

Androidもperry run androidで同様に動作し、Glanceコードが生成されてGradleビルドが走る。クロスプラットフォームフレームワークの中で、ここまでTypeScriptの記述量を変えずに複数プラットフォームへの展開を実現しているツールは多くない。

Perryのエコシステム—関連パッケージと実例

Perryには公式・コミュニティによるエコシステムが形成されつつある：

Prisma互換APIでSQLite/PostgreSQL/MySQLを扱えるライブラリが揃っているのは実用上大きい。PrismaのAPIに慣れたTypeScriptエンジニアが、同じコードのまま（またはほぼ同じまま）Perry向けのネイティブアプリに移行できる可能性がある。

@perryts/threadsパッケージによるワーカースレッド並列処理は、TypeScriptで重い計算を並列化したいユースケースに対応する。parallelMap・parallelFilter・spawnといった高レベルAPIで並列処理を記述でき、内部ではRustのスレッドとメッセージパッシングが動いている。

ゲームエンジンのBloom Engineは、TypeScriptでゲームロジックを書きながらMetal（macOS/iOS）・DirectX 12（Windows）・Vulkan/OpenGL（Linux/Android）にコンパイルできる。3Dレンダリング・スケルタルアニメーション・空間オーディオ・物理演算を含み、TypeScriptゲームエンジンとしては最もネイティブ指向の設計だ。

まとめ—Perryが示す「TypeScript+Rust」の可能性

Perryが示す方向性は明確だ。TypeScript開発者がRustを書かなくてもRust級のパフォーマンスを得られる道を作ること。そのためにRust・SWC・LLVMという実績あるコンポーネントを組み合わせ、TypeScriptのコード資産を最大限に活用しながらネイティブアプリ開発を可能にする。

v0.5.17時点ではまだ発展途上で、TypeScriptとの完全な互換性はない。動的eval・全てのnpmパッケージ・高度な動的機能には制約がある。プロダクション投入には公式のtypescript-parity-gaps.mdを確認し、使用するAPIが対応済みかを事前に確認することが必須だ。

それでも、Perryが実証したことは重要だ。TypeScriptからネイティブバイナリを生成するアプローチで、Node.jsを最大38倍上回るパフォーマンスが出る。iOS・Android・Webへの1コードベース展開が実現できる。330KBのHello Worldバイナリが現実的に作れる。これらの数字は、TypeScriptをネイティブ開発の主要言語として使う可能性が技術的には成立することを示している。

関連記事:

• tscircuit：TypeScriptで電子回路設計をコード化するOSSツール
• Claude Codeベストプラクティスガイド2026年版

参照ソース

• PerryTS/perry - GitHub
• Perry 公式ドキュメント
• Perry 公式サイト
• TypeScript Compatibility Tests
• TypeScript Parity Gaps
• Benchmark Results (polyglot)