目的とゴール

背景

Node.js は 2009 年から続くデファクトスタンダードで、npm エコシステムと LTS による長期運用が最大の武器です。 Deno は同じ作者による「Node.js の設計をやり直す」試みとして始まり、2.x 以降は npm 互換を取り込んで実務投入しやすくなりました。 Bun は Zig + JavaScriptCore による実装で、起動速度・実行速度とオールインワンのツールチェーンを前面に出しています。 3 者は今や「どれを選んでも一応動く」段階に入っており、だからこそ用途ごとの向き不向きを自分の手元で確かめる価値があります。

この検証のゴール

1. 定量データ — 起動時間・HTTP スループット・ファイル I/O・JSON 処理などを同一マシン・同一条件で計測し、数値を表とグラフで残す。
2. 定性評価 — TypeScript の扱い、標準搭載ツール、npm 互換性、エラーメッセージの分かりやすさ、Windows での挙動を実際に触って記録する。
3. 選定指針 — 「CLI ツールを作る」「API サーバを常駐させる」「スクリプトを 1 本書く」といった用途別に、どれを選ぶべきかの判断マトリクスを作る。
4. 再現性 — 計測スクリプトと生ログを残し、半年後に新しいバージョンで同じ検証を回せる状態にする。

スコープ外

• Cloudflare Workers・Vercel Edge などのエッジランタイム（V8 isolate 系）は対象に含めない。
• Linux / macOS でのクロスプラットフォーム比較は行わない（今回は Windows 11 単一環境での相対比較に絞る）。
• フレームワーク同士の比較（Express / Hono / Elysia など）は行わない。ただしランタイム差を見るための最小 HTTP サーバは各ランタイムの標準 API で書く。

比較対象バージョンと検証環境

最新バージョン（2026-08-24 時点）

各プロジェクトの公式配布情報から取得した最新版です。Node.js は Current 系列と LTS 系列の 2 本を対象に含めます。

手元環境の現状とギャップ

検証マシンに現在入っているバージョンを実測した結果です。着手前にこのギャップを埋めます。

バージョン切り替えの方針

Node.js は複数系列を測るためバージョンマネージャを使い、Deno / Bun は自前のアップグレードコマンドで単一の最新版に固定します。

3 ランタイムの立ち位置

検証環境の記録項目

結果の再現に必要な情報を、計測結果と同じ場所に必ず残します。

• OS（Windows 11 Home / ビルド番号）、CPU モデル・物理コア数、メモリ容量
• 電源プランと電源モード、AC 接続かバッテリー駆動か、計測中の常駐アプリの状態
• ストレージ種別（I/O 系ベンチに影響するため）とテスト用ディレクトリの配置ドライブ
• ウイルス対策のリアルタイムスキャン設定（node_modules の展開速度に影響する）

比較の観点（評価軸）

評価軸の一覧

「速さ」だけで選ぶと運用で詰まるため、性能と非機能要件の両方に重み付けをします。重みは合計 100 とし、集計時のスコア算出に使います。

定性評価のスコア基準

定性項目は主観が入るため、5 段階の意味を先に固定してから触ります。

検証項目とベンチマーク設計

定量計測の項目

npm 互換性チェックの対象

「動く／動かない」を切り分けたいので、性質の異なるパッケージを意図的に混ぜます。ネイティブアドオンを含むものは特に差が出やすい部分です。

公平に測るためのルール

1. 同一のソースを使う — ランタイム固有 API（Deno.serve、Bun.serve）を使う版と、共通の node:http 版の両方を測り、別々に記録する。片方だけを取り上げて有利／不利を言わない。
2. ウォームアップを行う — JIT が温まる前の値を混ぜない。hyperfine は --warmup 3 以上を指定する。
3. 試行回数と統計値 — 各項目 10 回以上実行し、平均ではなく中央値を代表値にする。最小・最大・標準偏差も併記する。
4. プロセスは毎回作り直す — キャッシュ状態が持ち越されないよう、計測ごとにサーバを再起動する。
5. 1 項目ずつ直列に実行 — 並列実行すると CPU とディスクを取り合って結果が濁る。
6. 失敗も結果として残す — 動かなかった項目は空欄にせず、エラー内容とともに記録する。互換性の比較ではこれ自体が重要なデータになる。

実施手順とディレクトリ構成

実施フロー

ステップの詳細

ディレクトリ構成

20260824-node-deno-bun-compare/
├── README.*                     プロジェクト概要（この計画書へのリンク）
├── docs/
│   ├── plan/
│   │   └── comparison-plan.*    この計画書
│   └── report/                  結果レポート（ステップ 5 で生成）
├── bench/
│   ├── common/                  3 ランタイム共通のソース（node: API のみ使用）
│   │   ├── b01-startup.js
│   │   ├── b03-http.js
│   │   └── ...
│   ├── native/                  ランタイム固有 API 版
│   │   ├── deno/
│   │   └── bun/
│   ├── compat/                  npm 互換性チェック用のプロジェクト
│   └── fixtures/                テストデータ（大きい JSON 等。生成スクリプトで作る）
├── src/scripts/                 番号付きフォルダ。各 .ps1 に同名の .cmd ランチャーを併置
│   ├── 10_setup_runtimes/       ランタイムの導入・配置
│   ├── 20_run_bench/            本計測ドライバ
│   ├── 30_run_install_bench/    依存インストールと npm 互換性
│   ├── 40_run_compile_bench/    単一実行ファイル化
│   ├── 50_build_report/         集計
│   └── 70_html2md/              HTML から Markdown を生成
├── results/
│   ├── env.txt                  検証環境と版数の記録
│   └── raw/                     生ログ（コミット対象）
├── etc/                         セッションログ・補助スクリプト（git 管理外）
└── tmp/                         一時ファイル（git 管理外）

成果物と評価方法

成果物

スコアの出し方

1. 定量項目は、各項目でもっとも良い値を 100 とした相対スコアに正規化する（時間系は「最小値 ÷ 実測値 × 100」）。
2. 定性項目は 5 段階スコアを 20 倍して 100 点満点に揃える。
3. 評価軸ごとに配下の項目スコアを平均し、章 3 の重みを掛けて合計する。
4. 総合スコアは順位付けの補助として示すだけにし、結論は用途別の判断マトリクスで述べる。

用途別 判断マトリクス（記入テンプレート）

最終的にこの表を埋めることが、この検証のアウトプットの本体です。 記入済みの表は 結果レポート の章 1 にあります。以下は計画時のテンプレートです。

スケジュールとリスク

フェーズと想定工数

リスクと対策

決定事項

未決事項

• npm 互換性チェックの対象パッケージを具体的に何にするか（章 4 の分類ごとに 1〜2 個ずつ確定させる）。P3 の着手前までに決める。
• 評価軸の重み（章 3 の配点）をこのまま使うか、用途を絞って調整するか。P6 の集計前までに確定させる。