JSをC言語へ直接コンパイル：Porfforが描く極限の軽量化と厳しい現実

深夜3時、アラート音で起こされ画面を開くと、Kubernetesクラスタ上のNode.js podsがOOMKilled（メモリ不足によるプロセス強制終了）で次々と死んでいる——そんな惨劇を経験したエンジニアは少なくないはずだ。我々が普段当たり前のように使っているNode.jsやBun、DenoといったモダンなJavaScriptランタイムは、非常に優れたV8やJavaScriptCoreといったJIT（Just-In-Time）コンパイルエンジンを抱えている。しかし、その代償として、わずか数行のスクリプトを動かすためだけに数十MBから数十GBもの巨大なエンジン本体をメモリ上に常駐させなければならないという、逃れられない構造的敗北を抱えていた。

この『巨大なランタイムの肥大化』という宿命に、真っ向から単身叩きつけられた回答が、2026年8月25日にアルファ版（v0.61.13）へと到達したAoT（Ahead-of-Time）コンパイラ「Porffor（ウェールズ語で紫）」である。Porfforの思想は極めて明快かつ過激だ。JITコンパイルを一切排除し、JavaScriptコードを100%事前にC言語へとコンパイルし、それをネイティブバイナリとして出力する。V8のような巨大エンジンをバイナリ内にバンドルしないため、生成される単一ファイルの実行サイズは数十KBレベルにまで凝縮される。

公式が提示する検証数値は、我々クラウドインフラのコストに苦しむエンジニアにとって俄かには信じがたいほどのインパクトを持っている。1GBのメモリしか搭載されていない低スペックなサーバーにおいて、従来のNode.jsコンテナであれば25個、セルフホスト型のワーカープロセスであっても45個程度が限界であったのに対し、Porfforによってビルドされたアプリケーションであれば、なんと『1,000個』のアプリが同時に動作するという。実にメモリ効率にして数十倍の差だ。実際に `console.log(‘hello world!’)` をコンパイルした例では、処理時間わずか105msで33.7KBという超軽量な単一バイナリが生成されている。

LLVMやCraneliftといった重厚なコンパイラ基盤にすら依存せず、あえて「C言語を中間表現として経由する」という泥臭いアプローチを選択したことで、可搬性とカスタマイズ性を両立させている点も極めて興味深い。我々が長年夢見てきた『JavaScriptの気軽さで書き、C言語の速度とメモリ効率で動かす』という理想郷が、ついに現実味を帯びて目の前に突きつけられたのだと、私は胸を熱くせざるを得ない。

しかし、魔法のようなパフォーマンスの裏には、必ず冷酷なトレードオフが存在する。ソフトウェア工学において「銀の弾丸」が存在しないことは、無数のスパゲッティコードと戦ってきた我々エンジニアが身にしみて知っている歴史的真実だ。Porfforが達成した極限のパフォーマンスと引き換えに捧げられた犠牲、それこそが「JavaScriptという言語の柔軟性そのもの」である。

ソースコードとドキュメントを読み込んでいくと、実務における導入をためらわせる強烈な制限事項が次々と浮かび上がってくる。まず、AoTコンパイルである以上当然ではあるが、`eval()` や `new Function()` といった動的コード評価は一切利用できない。メタプログラミングや動的なモジュール読み込みに依存している既存のエコシステムや多くのライブラリは、この時点で全滅することを意味する。

さらに決定的なのは、スコープの制限と非同期処理の未熟さだ。Porfforの現在の制限として「グローバル変数以外の変数はスコープを跨げない」という衝撃的な仕様が存在する。つまり、レキシカルスコープを利用して親関数の内部変数を保持するような、日常的に我々が書く「クロージャ（Closure）」のパターンが動作しないのだ。プログラミング言語JavaScriptの強みでありアイデンティティとも言えるクロージャが封じられることは、単なる制約を超えて「JavaScriptの書き方そのものをC言語的に再設計しなければならない」ことを意味している。加えて、モダン開発の要である `async/await` にも既知の重大なバグが存在し、現段階では「使用を避けるべき」とされている。

ECMAScriptの公式テストスイートである「Test262」におけるPorfforのテスト通過率は現在わずか「約60%」に過ぎない。コンパイルエラー自体は克服されつつあるものの、実行時にクラッシュするランタイムエラーや仕様不適合の山がまだ高くそびえ立っている。速度のために言語のセマンティクスをどこまで歪めてよいのか。単にC言語の皮をかぶった「JavaScript風の別言語」になってしまってはいないかという強い技術的懸念を、私は抱かざるを得ないのだ。

新しい技術が登場した際、我々エンジニアが最初に通る儀式が「ローカル環境での手元検証（PoC）」である。しかし、Porfforが提示する素晴らしい世界観に惹かれて一歩足を踏み入れた開発者を待ち受けているのは、開発体験（DX）における泥沼の課題だ。検証を試みた記者が直面したトラブルは、現在のPorfforが抱えるネイティブ依存のハードルの高さを如実に物語っている。

`porf native test.js output` を実行した瞬間、画面に吐き出されたのは `compiling C to native (using cc)… ‘cc’ は内部コマンドまたは外部コマンドとして認識されていません` という味気ないエラーログであった。PorfforはJavaScriptを一旦C言語のソースコードへトランスパイルし、それをシステム上に存在するCコンパイラ（`cc` や `gcc`）を介してバイナリへとコンパイルする構造を採っている。そのため、実行環境には完全なC言語のビルドツールチェーンが整っていることが絶対条件となる。

特にWindows環境におけるビルド手順の複雑さは壊滅的だ。かつてのシンプルなMinGWインストーラは姿を消し、現在ではまず「MSYS2」を導入し、専用ターミナルから `pacman -S mingw-w64-ucrt-x86_64-gcc` コマンドを打ってGCC環境を構築しなければならない。しかし、パスの通し忘れや環境変数の不整合によって「`gcc: command not found`」の無限ループに陥り、パフォーマンスのベンチマークをとる前段階で挫折してしまう開発者が続出しているのが現実である。

どんなにコンパイル後のバイナリが軽量で高速であろうとも、開発者が `npm install` 一発で試せないようなツールチェーンの複雑さは、普及における巨大な壁となる。Bunが絶大な支持を集めた最大の理由は「単一の実行ファイルで完結し、ダウンロードした瞬間に完璧に動く開発体験」にあった。Porfforが実験室を飛び出し、現場のCI/CDパイプラインや開発者のマシンで広く使われるランタイムとなるためには、Cコンパイラへの依存をバックグラウンドで完全に隠蔽するか、ポータブルなクロスコンパイル環境を自動提供するエコシステムの成熟が絶対に不可欠である。

Porfforという野心的なプロジェクトは、我々に「Web技術の未来とリソース効率のあり方」について痛烈な問いを投げかけている。現在、我々がクラウドに支払っている莫大なインフラコストの数割は、実はビジネスロジックの実行そのものではなく、V8という巨大なエンジンを動かすための「ランタイムのオーバーヘッド」に消えている。Cloudflare Workersのようなエッジコンピューティングや組み込みIoT機器の領域において、100KBを切るバイナリと数MBのメモリで動くJavaScriptという存在は、間違いなくゲームチェンジャーになり得るポテンシャルを秘めている。

しかし、我々エンジニアが真に自問すべきは、『クロージャもevalも使えない制限だらけのJavaScriptを書いてまで、なぜ我々はJavaScriptに固執するのか？』という根本的な問いだ。それほどの制約を受け入れるのであれば、最初からメモリ安全性が保証されたRustや、シンプルな並行処理が得意なGo言語でマイクロサービスを書く方が、型システムやエコシステムの恩恵をフルに享受できるのではないだろうか。

それでもなおPorfforに惹かれるとすれば、それは「世界で最も普及したプログラミング言語の記述力を、最も効率的なネイティブコードへ変換したい」というエンジニアの根源的なロマンがあるからに他ならない。アルファ版から正式リリースへの道のりは、残り40%の仕様適合と非同期処理の完全実装という、極めて困難な断崖絶壁が待っている。

我々が明日からの実務で取るべき処方箋は明確だ。既存の大型Webアプリケーションを無理やりPorfforでコンパイルしようとして討ち死にするのは避けるべきである。代わりに、状態を持たない単機能のCLIツールや、シンプルなエッジ関数、あるいは組み込み環境での極小スクリプトといった「仕様制限の影響を受けにくい領域」から、部分的かつ実験的な検証を始めることだ。この紫色の野心的なプロジェクトが、Web開発の重厚化した歴史に風穴を開ける本物のイノベーションになるのか、それとも美しい徒花として終わるのか。我々は一人のエンジニアとして、その進化のプロセスから決して目を離してはならない。