Edge.jsとは何か

Edge.jsは、Wasmer社が開発したJavaScriptランタイムです。一言で表すなら「Node.js互換 × WebAssemblyサンドボックス × プラガブルJSエンジン」を同時に実現するランタイムです。

公式サイト（edgejs.org）では「Run Node.js safely, anywhere, with any JS engine」と謳われており、その設計思想が端的に表れています。

Edge.jsの主要な特徴

既存のDeno DeployやCloudflare Workersとは根本的にアプローチが異なります。DenoやCloudflare Workersは独自のAPIやWinterCG仕様を導入することで安全性を担保しましたが、Edge.jsはNode.jsとの完全互換性を保ったまま、「安全でない部分だけ」をWebAssemblyでサンドボックス化するという戦略を採っています。

インストールと基本的な使い方

Edge.jsのインストールはシンプルです。

# Edge.jsのインストール
curl -fsSL https://edgejs.org/install | bash

インストール後は、edgeコマンドでNode.jsスクリプトをそのまま実行できます。

# スクリプトを直接実行
edge myscript.js

# 既存のNode.js/npmコマンドをEdge.jsで実行
edge pnpm run dev

# サンドボックスモードで実行
edge --safe myscript.js

--safeフラグを付けることで、WebAssemblyサンドボックスが有効になり、システムコールやネイティブコードの実行が完全に隔離されます。

DockerとWebAssemblyの根本的な違い

Edge.jsのアーキテクチャを理解するには、まずDockerコンテナとWebAssemblyの分離モデルの違いを把握する必要があります。

Dockerコンテナは本質的にLinuxカーネルの機能を利用してプロセスを分離します。WebAssemblyはバイトコードレベルでの分離を提供し、メモリアクセスは線形メモリ空間に閉じ込められ、外部リソースへのアクセスは明示的なインポートを通じてのみ許可されます。

WebAssemblyサンドボックスの仕組み

Edge.jsのサンドボックスアーキテクチャは、実行環境を2つのサイロに分離する設計に基づいています。

2つの分離サイロ

サイロ1：JavaScriptエンジン（ネイティブ実行）
V8などのJavaScriptエンジンはネイティブで動作します。JavaScript自体は言語仕様としてサンドボックス化されており、追加のハードニングは不要です。JavaScriptの実行パフォーマンスはNode.jsとほぼ同等を維持できます。

サイロ2：OSシステムコールとネイティブコード（WASIX経由で分離）
ファイルの読み書き、スレッド生成、ネットワーク操作などのシステムコールと、C/C++で書かれたネイティブモジュールはWASIXを通じてWebAssemblyサンドボックス内で実行されます。WASIXはWASI（WebAssembly System Interface）を拡張したもので、Wasmer社が開発しており、スレッドやネットワークソケットといったPOSIX互換のAPIを提供します。

Edge.js Runtime
  JS Engine (V8等)  [ネイティブ実行]
       |
      NAPI
       |
  WASIX Sandbox  [システムコール・ネイティブコード分離]
       |
    libuv / OS

この設計の本質は「安全でない部分だけをサンドボックス化する」という点です。パフォーマンスへの影響を最小限に抑えながら、セキュリティ上の脅威となる部分だけを確実に隔離しています。

Node.jsをまるごとWASIXにコンパイルしなかった理由

Node.jsをV8ごとWebAssemblyにコンパイルするアプローチは既に試みられていますが、V8がWasm内でインタプリタモードで動作するため深刻なパフォーマンス問題が生じます。Edge.jsはJSエンジンをネイティブで動作させ、安全でない部分のみをWasm化することでこの問題を回避しています。

JavaScriptエンジンのプラグイン機構

NAPIによる抽象化レイヤー

Node.jsにはNAPI（Node-API）という仕組みがあります。これはネイティブモジュールがNode.jsやV8の特定バージョンに依存せずに動作するための安定したABIレイヤーです。Edge.jsはこのNAPIをJSエンジン抽象化の基盤として活用しており、NAPIのインターフェースさえ実装すれば背後のJSエンジンを自由に差し替えられます。

対応エンジンと特性

Node.jsエコシステムとの互換性

Edge.jsが最も強くアピールしているのが、Node.jsとの互換性の高さです。Wasmer社は「Node.jsで動くものはEdge.jsでも動く。動かなければバグ」と宣言し、非互換が報告された場合は1週間以内に対応すると公約しています。

Node.jsテストスイートの互換性（macOS M3 Max環境）

Edge.jsのテスト通過率は99.1%（3592/3626）。BunとDenoがそれぞれ約42%・44%であることを考えると、Node.js互換性において圧倒的な差をつけています。特にnode:fs、node:http、node:cryptoといったサーバーサイドの中核モジュールで100%の互換性を達成している点は注目に値します。

高い互換性を実現できたのは、Node.jsと同じ依存ライブラリを採用しているからです。イベントループにlibuv、UTF-8処理にsimdutf、URLパースにada、HTTPパースにllhttp、暗号化にncrypto、DNS解決にc-aresと、Node.jsと完全に同じスタックを使っています。

エッジコンピューティングへの影響と可能性

Cloudflare Workers、Deno Deploy、Vercel Edge Functionsといった既存のエッジランタイムは、Node.jsとは異なる独自のAPI体系を採用しています。WinterCG（Web-interoperable Runtimes Community Group）という標準化の取り組みもありますが、フレームワーク側が各プラットフォームに合わせたアダプターを用意する必要があり、開発者の負担は小さくありません。

Edge.jsのアプローチは、この問題を根本から解消します。Node.js互換であるため、Next.js、Astro、Remixなどのフレームワークを無修正でエッジ環境にデプロイできます。また、WebAssemblyベースの分離によって、1台の物理サーバーで数千のNode.jsアプリケーションを同時に実行するという密度が達成可能になります。

サーバーレスの世界で戦ってきた経験から言えば、Edge.jsの設計思想はサーバーレスの本質と強く共鳴しています。WebAssemblyベースのサンドボックスが成熟すれば、サーバーレス関数の起動がマイクロ秒オーダーになり、メモリフットプリントも劇的に小さくなる。これはAWS LambdaのSnapStartやProvisioned Concurrencyとは異なるアプローチで、根本的にコールドスタート問題を解消する可能性を秘めています。

WinterJSからEdge.jsへの進化

WinterJSはWinterCG仕様に準拠したJSランタイムでしたが、WinterCGはNode.jsと互換性がないため、ExpressやKoa、Next.jsといった既存のNode.jsフレームワークが動作しませんでした。Wasmer社は率直に「WinterCGはNode.jsエコシステムの外に位置しており、Node.js互換性という最大の資産を活用できなかった」と認め、Edge.jsという新たな方向性に舵を切りました。失敗から学んで素直に方向転換できる姿勢は、エンジニアリング組織として誠実だと思います。

実際に試してみた

百聞は一見にしかず。Edge.jsのインストールから簡単なExpressアプリの実行まで試してみました。

セットアップ

# Edge.jsのインストール
curl -fsSL https://edgejs.org/install | bash

# バージョン確認
edge --version
# edge v0.1.0 (node v24.1.0)

既存のExpressアプリをそのまま動かす

// app.js
const express = require('express');
const app = express();

app.get('/', (req, res) => {
  res.json({
    message: 'Hello from Edge.js!',
    runtime: process.version
  });
});

app.listen(3000, () => {
  console.log('Server running on port 3000');
});

# 通常実行
edge app.js
# Server running on port 3000

# サンドボックスモードで実行
edge --safe app.js
# Server running on port 3000

# curlでテスト
curl http://localhost:3000/
# {"message":"Hello from Edge.js!","runtime":"v24.1.0"}

コードの変更は一切不要でした。既存のNode.jsアプリがそのまま動く、というのは本当で、ぶっちゃけ拍子抜けするくらいシンプルでした（笑）。

--safeモードの動作確認

# 通常モード（サンドボックスなし）
edge sandbox-test.js
# Read successful: 2847 bytes

# --safeモード（サンドボックス有効）
edge --safe sandbox-test.js
# Sandboxed! Error: EACCES

--safeモードを有効にすると、明示的に許可されていないシステムリソースへのアクセスがブロックされます。マルチテナント環境でユーザーコードを安全に実行するユースケースでは、このフラグが非常に有効です。

コンテナとWebAssemblyの共存期に備えて

Edge.jsは発表されたばかりで、まだプロダクション採用に向けた検証が必要な段階です。しかし、その設計思想と技術的アプローチは、コンテナが抱える構造的な問題に対する説得力のある答えを提示しています。

Wasmer社がAIを活用してEdge.jsを数週間で実装した、というエピソードも示唆的です。かつてなら数年かかったような技術的チャレンジが、AIの支援によって短期間で実現できる時代になってきています。

まずはローカル環境でEdge.jsを試してみることをおすすめします。既存のNode.jsアプリがそのまま動く体験は、次世代ランタイムの可能性を直感的に感じさせてくれます。

Wasmerが描く「コンテナ後の世界」が実現するかどうかはまだわかりません。ただ、WebAssemblyが単なるブラウザ向け技術ではなく、サーバーサイドインフラの基盤技術として成熟しつつあることは間違いないと感じています。