サーバーサイドJavaScriptのランタイム選定が、2026年に新たな転換点を迎えている。Node.jsが16年にわたって築いた生態系の上に、Denoがセキュリティファーストの設計で挑み、Bunがパフォーマンス至上主義で割って入る ── 三者三様の設計思想が、いずれも成熟期に入った。Node.js 24はTypeScript ネイティブサポートとPermissionモデルを導入し、Denoの優位性を取り込みにかかる。Deno 2.7はnpm完全互換を達成しつつTemporal APIを安定化させた。Bun 1.3は組み込みデータベースクライアントでフルスタック化を推し進める。本稿では、テクノロジーの視点から、パフォーマンス・エコシステム・企業採用の3軸でこの3ランタイムを定量比較し、プロジェクト特性に応じた選定基準を提示する。なお、フロントエンド開発ツールチェーンの全体像についてはVite vs Next.js vs Astroの選定基準分析も参照されたい。

アーキテクチャと設計思想の根本的差異

3ランタイムの技術的差異を理解するには、まずJavaScriptエンジンの選択から始める必要がある。Node.jsとDenoはGoogle V8エンジン（現行V8 14.5/13.6）を採用し、BunはApple JavaScriptCore（JSC）を採用している。この選択が、パフォーマンス特性の大半を規定する。V8は長時間稼働プロセスでの最適化に優れ、JITコンパイラの段階的最適化で実行時間が長いほどパフォーマンスが向上する。一方JSCは起動速度に最適化されており、コールドスタートが高速な反面、ピークスループットではV8に劣る場面がある。

Denoの設計思想は「セキュリティファースト」に集約される。デフォルトでファイルシステム、ネットワーク、環境変数、サブプロセス起動のすべてが拒否される deny-all モデルを採用し、--allow-read、--allow-net などのフラグで明示的に許可を与える。Deno 2.5で導入されたPermission Sets機能により、設定ファイルで権限プロファイルを定義し deno run -P set-name script.ts で参照する運用が可能になった。これはコンテナ化されたマイクロサービスやエッジファンクションで特に有用であり、最小権限の原則をランタイムレベルで強制できる。

Node.js 24もこの領域に参入し、--experimental-permission フラグで --allow-fs-read、--allow-fs-write などの細粒度制御を導入した。2026年1月のセキュリティリリースでは、fs.futimes()による書き込み権限バイパス（CVE-2025-55132）、Unix Domain Socketによるネットワーク権限回避（CVE-2026-21636）、シンボリックリンクチェーンによるサンドボックス脱出（CVE-2025-55130）の3件が修正され、Permissionモデルの堅牢化が進んでいる。ただし、experimentalフラグであることから本番環境での採用にはリスク評価が必要である。

Bunの設計思想は「オールインワン」である。ランタイム、バンドラー、テストランナー、パッケージマネージャーを単一バイナリに統合し、外部ツールへの依存を最小化する。Bun 1.3ではゼロコンフィグのフロントエンド開発環境（HMR + React Fast Refresh対応）と、MySQL・MariaDB・PostgreSQL・SQLiteをカバーする統合データベースクライアント Bun.SQL APIが追加された。この「バッテリー同梱」思想は、プロジェクトの立ち上げ速度では圧倒的な優位性を持つが、各機能の成熟度がNode.jsエコシステムの専用ツール群に追いつくかが長期的な課題となる。

パフォーマンスベンチマーク ── 合成テストと本番環境の乖離

ランタイム選定においてベンチマークは最も頻繁に引用されるが、最も誤解されやすい指標でもある。筆者自身、過去に複数の高並行性システム開発を手がけた経験から断言できることがある ── 合成ベンチマークの数値と本番環境のパフォーマンスは、ほぼ別物である。2000人同時接続のリアルタイムサービスを構築した際に痛感したのは、ボトルネックはランタイムのRPSではなくアーキテクチャ設計にあるという事実だ。

とはいえ、ベースラインとしてのベンチマークは有用である。2026年3月時点の主要な計測結果を整理する。

指標Node.js 24Deno 2.7Bun 1.3
HTTP Hello World（req/sec）25,000〜30,00029,000〜40,00052,000〜70,000
Express風JSONレスポンス（req/sec）約13,000約29,000約52,000
DB+ビジネスロジック込み実アプリ（RPS）約12,000約12,000約12,000
コールドスタート（Lambda環境）245ms40〜60ms156ms（カスタムランタイム）
パッケージインストール速度（vs npm）基準15%高速（cold）/ 90%高速（hot）20〜30倍高速
SQLite性能基準Bunの1/8〜1/9better-sqlite3比3〜6倍高速
JSON.stringify性能2倍以上高速化（V8 13.6）V8 14.5で同等JSCベース（同等水準）

注目すべきは、DB接続やビジネスロジックを含む実アプリケーションベンチマークでは3ランタイムがほぼ同一のRPSに収束する点である。合成テストでBunが2〜3倍の差をつける指標も、本番に近い条件では差が消失する。これはI/Oバウンドなワークロードにおいて、ランタイムのオーバーヘッドよりデータベースやネットワークのレイテンシが支配的になるためである。

コールドスタートはサーバーレス環境で特に重要な指標である。DenoはAWS Lambdaで40〜60msと最速であり、これはDeno Deployのエッジ実行基盤でも活かされている。一方Bunは理論上の起動は数十ミリ秒と高速だが、AWS Lambdaに公式ランタイムサポートがなく、カスタムランタイム構築が必要なため実測値は156msとNode.jsの245msより速いものの、プラットフォーム最適化の恩恵を受けられない。

パッケージインストール速度ではBunが圧倒的である。バイナリロックファイル（bun.lockb）の採用とネイティブ実装により、npmの20〜30倍の速度を実現している。CI/CDパイプラインの高速化を重視するチームにとって、これは無視できない差である。

エコシステムとnpm互換性 ── 310万パッケージの重力

npm registryには310万以上のパッケージが登録されており、この生態系の重力はランタイム選定を強く拘束する。Node.jsはnpmとの完全互換性を持つ唯一のランタイムであり、あらゆるパッケージがそのまま動作する。この「何でも動く」という保証は、特にエンタープライズ環境で決定的な意味を持つ。

Deno 2.0以降、npm互換性は飛躍的に改善された。npm:指定子による直接インポート、package.jsonとnode_modulesの認識、そして@types/nodeのデフォルト同梱（Deno 2.6以降）により、既存のNode.jsプロジェクトの多くがDeno上で動作する。Deno 2.7ではpackage.jsonベースのnpmオーバーライドもサポートされ、依存関係の細粒度制御が可能になった。加えて、JSR（JavaScript Registry）はTypeScriptファーストの設計で.tsファイルを直接公開でき、自動ドキュメント生成と品質スコアリング機能を備える。

Bun 1.1でnpm互換性99%を達成したとされるが、重大な制約がある ── ネイティブNode.jsアドオン（.node C/C++バインディング）が非互換である点だ。BunはV8ではなくJSCを使用するため、node-gypやN-APIでコンパイルされたバイナリモジュールが動作しない。bcrypt、sharp、canvasなど、ネイティブバインディングに依存するパッケージは代替手段が必要になる。この制約は、既存プロジェクトの移行において最も頻繁に遭遇する障壁である。

筆者がフルスタックエンジニアとして数え切れないプロダクトを開発してきた経験から、技術選定において最も重要なのはバイアスなく最適解を選べる視野の広さである。ランタイムの選択もフレームワーク同様、プロジェクト特性との適合度で判断すべきであり、ベンチマーク至上主義は危険である。メタフレームワーク選定と同様、定量指標だけでなくチームの習熟度やエコシステムの安定性を含めた総合評価が不可欠だ。

TypeScript対応とDX ── ネイティブサポートの収束

2026年において、TypeScriptサポートは3ランタイムすべてで「ネイティブ」の域に達しつつある。ただし、その実装深度には明確な差がある。

Denoは初期設計からTypeScriptを第一級市民として扱い、.tsファイルを直接実行できる。Deno 2.6ではGoベースのTypeScriptチェッカー tsgo を導入し、型チェック速度を2倍に高速化した。TypeScript 5.9.2をサポートし、deno.jsonで compilerOptions を指定できるため、tsconfig.json相当の設定が統合されている。Deno 2.7では deno audit コマンドも追加され、依存関係のCVEスキャンがランタイム組み込みで提供される。

Node.js v23.6以降、TypeScriptの型ストリッピングがフラグなしで安定動作する。ただしこれは型の除去のみであり、decoratorsやenumsなどJavaScriptへの変換が必要な構文には --experimental-transform-types フラグが必要である。また、tsconfig.json の paths や compilerOptions は読み込まれないため、パスエイリアスを使用するプロジェクトでは追加の設定が必要となる。Node.jsの組み込みテストランナー（node:test）は安定版に昇格し、Jestからの移行で600%のテスト実行速度改善が報告されている。

BunはTypeScriptを無設定で実行でき、バンドラーとテストランナーも統合されている。開発体験の一貫性では最も優れているが、型チェック自体はBun内蔵ではなく外部の tsc に依存する。Bun Shellによるクロスプラットフォームbashライクスクリプティング（Bun.$ API）や、コンパイル時コード変換を可能にするマクロ機能など、DXを向上させる独自機能が充実している。

開発体験の観点では、3ランタイムの機能マトリクスを以下に整理する。

機能Node.js 24Deno 2.7Bun 1.3
TypeScript実行型ストリッピング（安定）ネイティブ（第一級）ネイティブ（無設定）
型チェック外部tsc内蔵（tsgo, 2倍高速）外部tsc
組み込みテストランナーnode:test（安定）deno test（安定）bun test（安定）
パッケージマネージャーnpm（Corepack v25で削除）deno install / add / removebun install（20〜30倍高速）
バンドラーなし（外部依存）なし（外部依存）bun build（内蔵）
フォーマッター/リンターなし（外部依存）deno fmt / deno lintなし（外部依存）
脆弱性スキャンnpm auditdeno audit（内蔵）なし
単一実行ファイル生成--build-sea（v25.5）deno compile（安定）bun build --compile
WebSocket Client安定（v22.4以降）安定安定
Temporal API未対応安定（v2.7）未対応

企業採用と本番運用 ── リスク評価の実際

エンタープライズ採用においては、技術的優位性以上に「リスクの低さ」が選定基準を支配する。Node.jsは16年の実績、310万パッケージ、Fortune 500企業での大規模採用実績があり、この領域では圧倒的な安定資産である。Node.js 24のLTS（Krypton）は2025年5月にリリースされ、Active LTSは2026年10月まで、Maintenance期間は2028年4月まで続く。さらに2027年からはリリースサイクルが年2回から年1回に変更され、各リリースの36ヶ月サポートが保証される。エンタープライズのIT資産管理にとって、この予測可能性は極めて重要である。

Denoは2,100万ドルの資金調達を実施し、チーム規模を30人に拡大しているが、Fortune 500企業での大規模採用事例は公開されていない。Deno Deployは月額20ドルのProプランで商用利用が可能であり、Deno Subhostingはマルチテナントのコード実行基盤として特定のSaaS事業者に採用されている。2026年1月には3人チームのSaaSバックエンドがNode.jsからDeno 2.2に移行した事例が報告されているが、大規模事例の蓄積は発展途上である。

Bunについては、2025年12月にAnthropicが推定1億ドル以上で買収したことが最も重要なターニングポイントである。Claude CodeとClaude Agent SDKの基盤技術としてBunが採用されたことで、プロジェクト継続性のリスクは大幅に低下した。月間700万ダウンロード、GitHubスター82,000超の規模に達しているが、Fortune 500での採用は「黎明期」にとどまる。Midjourney、Lovableなどのスタートアップでの採用が先行している状況である。Next.js 16のエンタープライズ移行ROI分析で示されているように、大規模プロジェクトのランタイム移行は240ファイル規模の作業となり得るため、移行コストを定量評価した上での判断が求められる。

筆者が複数企業の技術顧問として関わってきた経験から言えることがある ── コンサルティングの価値は答えを出すことではなく、クライアントが自走できる判断基準を渡すことにある。ランタイム選定も同様であり、以下のディシジョンマトリクスが判断基準として機能する。

選定基準ディシジョンマトリクス ── プロジェクト特性別の推奨

3ランタイムの選定は、プロジェクトの特性によって最適解が異なる。以下に、ユースケース別の推奨を整理する。

ユースケース推奨ランタイム理由
エンタープライズ既存システムNode.js 24 LTSnpm完全互換、LTS 36ヶ月保証、既存知見の活用
新規スタートアップAPIBun 1.3立ち上げ速度、オールインワン、CI/CD高速化
エッジ/サーバーレスファンクションDeno 2.7最速コールドスタート、Permission model、Deno Deploy統合
セキュリティ重視のマルチテナントDeno 2.7deny-allセキュリティモデル、Permission Sets、Subhosting
高スループットAPI GatewayBun 1.3HTTP 52,000 RPS以上、JSCの高速起動
Next.js / Remix フルスタックNode.js 24フレームワーク公式サポート、安定した実績
CLIツール / スクリプティングDeno 2.7単一ファイル実行、依存関係なし、deno compile
組み込みDB + APIBun 1.3Bun.SQL統合、SQLite 3〜6倍高速
ポリグロット戦略（併用）Bun (API) + Node.js (SSR)各ランタイムの強みを活かす分離戦略

重要なのは、2026年の段階で「唯一の正解」は存在しないということである。ポリグロット戦略 ── BunをAPI層に、Node.jsをSSRフロントエンドに使う併用アプローチ ── が実務的に最も合理的なケースも増えている。Platform Engineering 2026の分析で指摘されているように、IDP（Internal Developer Platform）の設計次第でランタイムの選択を抽象化することも可能になりつつある。

最終的な選定は、以下の3問に回答することで収束する。

  1. 既存コードベースはあるか？ → Yesならnpm完全互換のNode.jsが最もリスクが低い
  2. コールドスタート性能は重要か？ → Yesならサーバーレス最適化されたDenoが最適
  3. 開発速度を最優先できるか？ → Yesならオールインワンで最速のBunが有利

FAQ

Deno 2.7でnpmパッケージはそのまま使えるのか？

Deno 2.7では npm: 指定子による直接インポートで大半のnpmパッケージが動作する。package.json と node_modules の認識、@types/node のデフォルト同梱により、多くの既存Node.jsプロジェクトがそのまま実行可能である。ただし、ネイティブアドオンに依存するパッケージは個別確認が必要である。

Bun 1.3のネイティブアドオン非互換はどの程度深刻か？

BunはJavaScriptCoreを採用しているため、V8向けにコンパイルされた .node バイナリモジュールは動作しない。bcrypt、sharp、canvas、better-sqlite3 などのパッケージが影響を受ける。ただしBun独自の bun:sqlite やWASM版ライブラリで代替可能なケースも多い。既存プロジェクト移行時は依存関係の全量チェックが必須である。

Node.js 24のTypeScriptサポートはtscの代替になるか？

Node.js 24の型ストリッピングは型注釈の除去のみを行い、型チェックは実行しない。decorators、enums、namespace等の変換が必要な構文は --experimental-transform-types フラグが必要である。また tsconfig.json の paths を読み込まないため、パスエイリアスを使用するプロジェクトでは依然として tsc や tsx が必要となる。

AWS Lambdaで最もパフォーマンスが良いのはどのランタイムか？

コールドスタート性能ではDenoが40〜60msで最速である。Node.jsは245ms、Bunはカスタムランタイム経由で156msとなる。ただしBunはAWS Lambda公式ランタイムが提供されておらず、カスタムランタイム構築によるメンテナンスコストが発生する。ウォームスタート後の処理性能では3ランタイムの差は縮小する。

2026年時点でNode.jsからの移行は推奨されるか？

既存の安定したNode.jsプロジェクトについて、パフォーマンス向上のみを目的とした移行は非推奨である。本番環境でのDB+ビジネスロジック込みの性能差はほぼ存在しない。一方、新規プロジェクトの立ち上げ、エッジコンピューティング基盤の構築、セキュリティサンドボックスが必要なマルチテナント環境など、各ランタイムの設計思想と合致するユースケースでは積極的に検討すべきである。

参考文献