結論 — 用途別の推奨

計画書で用意した判断マトリクスを、実測値で埋めた結果です。総合スコアではなくこの表が本レポートの結論です。

3 行でまとめると

• 速さを買うなら Bun。11 項目のうち 9 項目で最速、起動系は他を 2〜4 倍引き離した。負けたのは SQLite（Node.js）と依存インストール（Deno）の 2 項目だけ。
• 長期運用を買うなら Node.js。性能は中位だが LTS・SQLite・エコシステムの実績で崩れない。
• 安全性とツールの一体感を買うなら Deno。権限モデルと 1 バイナリ完結が他に無い。生の速度では中位。

検証条件と方法

検証環境

検証対象

3 ランタイムはいずれもシステムにインストールせず、公式配布物をプロジェクト内 tools/ に展開して明示パスで呼び出しました。 Node.js と Deno は公式の SHA256 と一致することを確認済みです。既存のグローバル環境（node v25.8.2 / deno 1.31.1）には触れていません。

公平に測るために守ったこと

• 同一ソースで比較 — HTTP は 3 ランタイム共通の node:http 版と、Deno.serve / Bun.serve の固有 API 版を別項目として記録しました。片方だけを取り上げていません。
• ウォームアップ 3 回、本計測 10 回 — 代表値は平均ではなく中央値。最小・最大・標準偏差・変動係数も results/measurements.csv に残しています。
• シェルを介さない — hyperfine は --shell=none で実行し、起動時間に cmd.exe のコストを混ぜていません。
• 1 項目ずつ直列実行 — 4 コアのマシンなので並列化すると結果が濁ります。
• 失敗も記録 — 空欄にせず理由を残す方針にしましたが、結果として全項目が全ランタイムで完走しました。

計画から変えた点

起動性能とプロセス単位の速さ

プロセスを起動して終わるまでの時間を hyperfine で測った項目です。CLI ツールや使い捨てスクリプトでは、この時間がそのまま体感になります。

読み取れること

• Bun の起動優位は一貫している — 4 項目すべてで最速。空起動 41.7 ms は Node.js の 2.4 倍速で、依存を 5 つ import しても 66.9 ms に収まりました。JavaScriptCore と Zig 実装の効果が最も素直に出る領域です。
• Deno の空起動は最も遅い — 111.8 ms で Node.js より 10 ms 遅い。ただし TypeScript を含めると 178.8 ms で Node.js（224.0 ms）を逆転します。Deno は TS を前提に最適化されており、.ts を投げる使い方では有利になります。
• TypeScript は 3 者とも設定ゼロで動いた — tsconfig.json もトランスパイル手順も無しに .ts を直接実行できました。Node.js の型ストリップは消去可能な構文に限られるため、enum や namespace を使うコードでは差が出ます（今回はそれらを避けた共通コードで測定）。
• Node.js 26 と 24 の差は小さい — 起動系 4 項目で最大 8% 程度。世代を上げても起動は速くなっていません。
• テスト実行の差は 3.94 倍 — 3 ランタイムとも node:test 記法の 200 件を無修正で 200 件パスさせました。互換性は問題なく、差は純粋にランナーの速度です。

実行性能

B-03 HTTP スループット

10 秒間・50 同時接続で "Hello" を返し続けたときの毎秒リクエスト数です。共通の node:http 版と、各ランタイム固有 API 版を分けて測りました。

固有 API を使うかどうかで結論が変わります。 node:http のままなら Bun が唯一頭ひとつ抜けますが、固有 API まで許すと Deno と Bun はほぼ同着（差 2.7%、p99 も 0.15 ms 差）です。 注目すべきは Deno の伸び幅で、互換レイヤを捨てると 1.71 倍になりました。Deno の node:http は互換のためのラッパで、性能を出す経路ではないことがはっきり出ています。

B-04 JSON 処理（10 MB / 52,481 レコード）

合計では Bun が最速ですが差は 1.18 倍で、起動系ほど開きません。内訳を見ると JSON.parse は Deno・Bun が Node.js より 1.4 倍速く、 一方 Node.js 26 はメモリ使用量が最小（41.7 MB）です。Node.js 24 → 26 で heap が 61.5 MB → 41.7 MB に減っているのは、 この検証で見えた 26 系の明確な改善点でした。

B-05 ファイル I/O（2000 ファイルの書き込み・読み込み・一覧・削除）

この項目はランタイムの差がほぼ出ません。 最速の Bun と最遅の Deno で 1.05 倍しかなく、 1 ファイルあたり約 1.75 ms を Windows のファイル操作コストが占めています。差を見るなら内訳の方が有益で、 Deno の削除（1,123.6 ms）と一覧（8.6 ms）は他より明確に遅く、Windows のファイルシステム実装に改善の余地があることを示しています。

B-06 CPU バウンド処理

合計 1.81 倍という Bun の優位は、ほぼ配列ソートの 1 点から来ています（374.0 ms 対 715.4 ms）。 100 万要素の Array.prototype.sort で JavaScriptCore が V8 の 1.9 倍速く、これが合計の差を作っています。 逆に数値ループでは Bun が最も遅く（82.4 ms 対 Deno 68.5 ms）、V8 と JSC の得手不得手が分かれました。 「Bun は CPU 処理が速い」と一般化すると誤ります。

B-07 SQLite（インメモリ・10 万行）

Bun が唯一負けた実行性能項目です。 3 ランタイムすべてが node:sqlite を持っており、同じコードが無修正で動きました。 Node.js が全内訳で最速、Deno は INSERT で 1.96 倍遅い。DB アクセスが中心のワークロードでは、起動やソートの速さが結論を決めないことが分かります。

パッケージ管理と npm 互換性

B-08 依存インストール

性質を混ぜた 8 パッケージ（純 JS 2・HTTP フレームワーク・DB ドライバ・ビルドツール・CLI・ネイティブアドオン 2）を、 同一の package.json から各パッケージマネージャでインストールした時間です。

キャッシュが効いたときの差が極端です。 deno install の 1.3 秒に対し bun install は 10.8 秒、npm install は 17.1 秒。 Deno はグローバルキャッシュから node_modules を組み立て直すだけで済む設計になっており、この条件では 13 倍の差がつきました。 一方クリーン（キャッシュもロックも無い）状態では 17.1〜26.3 秒に収まり、ネットワーク待ちが支配的になって差は 1.54 倍まで縮みます。

生成される node_modules はどれも 74 MB 前後・2,200 件前後でほぼ同じでした。 bun install が postinstall を既定でブロックしても完走したのは、今回の対象がプリビルドバイナリを optionalDependencies で配る方式（sharp・better-sqlite3）だったためです。ソースからビルドが必要なパッケージでは結果が変わります。

P3 npm 互換性チェック

各パッケージマネージャが作った node_modules に対し、対応するランタイムで import と主要エクスポートの存在確認を行いました。

ツールチェーンと配布

B-10 単一実行ファイル化

依存を持たない 1 ファイルの CLI を、実行ファイルに固めた結果です。生成物は実際に起動して期待した出力が出ることを確認しています。

3 者すべて動く実行ファイルを作れましたが、手数が違います。Bun と Deno は 1 コマンドで完結、Node.js は blob 生成 → node.exe の複製 → postject による注入の 3 段階で、しかも postject を npm から入れる必要があります。 18.1 秒のうち大半はこの npm インストールです。出力サイズは Deno が最小（75.9 MB）、Node.js が最大（98.5 MB）でした。

標準で持っているもの

Deno の権限モデルは今回の検証で実際に体感しました。-A（全許可）を付けないと、 ファイル読み込み・環境変数参照・ポート待ち受けのいずれもエラーになります。手間ではありますが、 外部から持ち込んだスクリプトを走らせる場面ではこの既定拒否が他 2 者に無い価値になります。

総合スコアと読み方の注意

評価軸ごとのスコア

定量項目は「各項目の最良値を 100 とした相対値」を軸内で平均、定性項目は 5 段階を 100 点満点に換算した値です。重みは計画時に確定させたものを変更していません。

総合スコア

この総合スコアを信用しすぎないための注意

1. 相対スコアは差を誇張する — 最良値を 100 とする方式なので、実測差が小さくてもスコア差は開きません／逆に開きすぎます。 典型はパッケージ管理で、キャッシュ有インストールが Deno 1.3 秒・Bun 10.8 秒・npm 17.1 秒なので、Node.js は 7.9 点という壊滅的な数字になります。 実際には「17 秒か 1 秒か」であって、日常の開発を左右する差ではありません。逆にファイル I/O は 1.05 倍しか違わないのに、全員 95〜100 点で横並びになります。
2. 重みが結論を決めている — 速さ関連（起動 15＋実行 20＋TypeScript 10）で 45 点を占める配点なので、Bun が勝つのは配点の帰結でもあります。 「運用・サポート」を 30 に上げれば Node.js が最上位になります。重みは計測後に動かしていませんが、自分の状況に合わせて再計算する前提の数字です。
3. ツールチェーン軸が B-10・B-11 の時間だけで決まっている — fmt / lint / bundle の有無という本来この軸で重要な要素は、 定量化できていないため章 6 の表に分離してあります。スコア 14.5 は「Node.js のツールチェーンが弱い」ことの証拠としては不十分です。
4. 単一マシン・単一 OS の相対比較 — 4 コアのノート PC 1 台、Windows のみ。絶対値を「このランタイムは毎秒 N リクエスト処理できる」と一般化はできません。 変動係数は多くの項目で 2〜16% あり、10% 以内の差は「差なし」として扱うべきです。
5. Deno と Bun の HTTP は固有 API では同着 — 実行性能の軸には共通コード（node:http）のみを入れています。 固有 API を使う前提なら Deno の実行性能スコアは上がります。

再現方法

同じ計測を後日やり直せます。tools/ のバイナリと bench/fixtures/ のテストデータはリポジトリに含めず、スクリプトから再生成します。

# 1. ランタイムと計測ツールを tools/ に配置（SHA256 検証つき）
src\scripts\10_setup_runtimes\setup-runtimes.ps1

# 2. ベンチ本体（項目を分けて実行し、-Append で結果をマージできる）
src\scripts\20_run_bench\run-bench.ps1 -Runs 10 -Warmup 3 -Only B-01,B-02,B-09,B-11
src\scripts\20_run_bench\run-bench.ps1 -Runs 10 -Warmup 3 -FileCount 2000 -Only B-04,B-05,B-06,B-07 -Append
src\scripts\20_run_bench\run-bench.ps1 -Only B-03 -HttpSeconds 10 -HttpConnections 50 -Append

# 3. 依存インストールと npm 互換性
src\scripts\30_run_install_bench\run-install-bench.ps1

# 4. 単一実行ファイル化
src\scripts\40_run_compile_bench\run-compile-bench.ps1

# 5. 集計（定性評価は results/qualitative.json を読む）
src\scripts\50_build_report\build-report.ps1