Deno vs Bun vs Node.js 比較：2026年版JavaScriptランタイム完全ガイド

Node.jsは2009年から世界中で使われてきたJavaScriptランタイムです。しかしDeno（Node.js創設者Ryan Dahlが作った次世代ランタイム）とBun（Zig製の超高速ランタイム）が登場し、JavaScriptサーバーサイド実行環境の選択肢が大きく変わりました。2026年現在、どのランタイムを選ぶべきか詳しく解説します。

なぜNode.jsの代替が生まれたか

Node.jsには長年の技術的負債があります。Ryan Dahlは2018年のJSConfでNode.jsの後悔として以下を挙げました：

1. セキュリティ: デフォルトでファイルシステム・ネットワーク・環境変数への無制限アクセス
2. モジュールシステム: CommonJS（require）の設計ミス。ESModulesが後からの対応になった
3. package.json: npmの肥大化とnode_modulesの複雑さ
4. TypeScript非対応: 実行前にtscでコンパイルが必要
5. Web API非対応: ブラウザのfetch・Blob・WebCryptoが使えない

この反省からDenoが生まれ、Bunは実行速度の問題を解決するために登場しました。

主要ランタイムの概要

Node.js

2009年にRyan Dahlが開発し、現在はOpenJS Foundationが管理するJavaScriptランタイムです。GitHubスター110k+。V8エンジン上に構築され、CommonJS・ESModules両対応。npmエコシステム（230万パッケージ）の恩恵を受けられます。

# Node.jsのインストール（fnmで最新版管理）
# Windowsの場合
winget install Schniz.fnm
fnm install --lts
fnm use lts-latest

# Linuxの場合
curl -fsSL https://fnm.vercel.app/install | bash
fnm install --lts
fnm use lts-latest

node --version  # v22.x.x
npm --version   # 10.x.x

# 基本的なHTTPサーバー（Node.js）
node -e "
const http = require('http');
const server = http.createServer((req, res) => {
  res.writeHead(200, {'Content-Type': 'application/json'});
  res.end(JSON.stringify({message: 'Hello from Node.js', version: process.version}));
});
server.listen(3000, () => console.log('Server running on http://localhost:3000'));
"

// Node.js 22+: fetch API（ブラウザと同じ）が標準対応
const response = await fetch('https://api.github.com/repos/nodejs/node');
const data = await response.json();
console.log(data.stargazers_count);

// ESModulesはpackage.jsonで"type":"module"指定が必要
// または .mjs 拡張子を使用

Deno

2020年にRyan Dahlが公開したTypeScriptネイティブなランタイムです。GitHubスター100k+。V8エンジン上にRustで実装。TypeScriptをコンパイルなしで直接実行でき、ファイルシステム・ネットワーク・環境変数へのアクセスは許可フラグが必要なパーミッションモデルを採用します。npmパッケージもnpm:パッケージ名形式でインポート可能。Deno KV（組み込みKey-Value DB）やDenoのエッジデプロイ（Deno Deploy）も提供します。

# Denoのインストール
# Windows
winget install DenoLand.Deno
# Linux/macOS
curl -fsSL https://deno.land/x/install/install.sh | sh

deno --version  # deno 2.x.x (v8 x.x.x, typescript x.x.x)

# TypeScriptを直接実行（tsコンパイル不要）
cat > server.ts << 'EOF'
interface Env {
  PORT: number;
}

const port = parseInt(Deno.env.get("PORT") || "3000");

Deno.serve({ port }, (req: Request) => {
  const url = new URL(req.url);
  return new Response(
    JSON.stringify({ message: "Hello from Deno", path: url.pathname }),
    { headers: { "content-type": "application/json" } }
  );
});
EOF

# パーミッション指定で実行（--allow-net: ネット許可、--allow-env: 環境変数許可）
deno run --allow-net --allow-env server.ts

# Denoのパーミッションシステム（セキュリティモデル）
# デフォルト：全アクセス拒否
deno run script.ts                    # ファイル読み取りも不可
deno run --allow-read script.ts       # ファイル読み取りのみ許可
deno run --allow-read=/tmp script.ts  # /tmpのみ許可（最小権限）
deno run --allow-net=api.github.com script.ts  # 特定ドメインのみ
deno run --allow-all script.ts        # 全許可（Node.jsと同等）

# npmパッケージをnode_modulesなしで使用
deno run --allow-net - << 'EOF'
import express from "npm:express@4";
const app = express();
app.get("/", (req, res) => res.json({runtime: "deno", npm: "works!"}));
app.listen(3000);
EOF

Bun

2022年にJarred Sumnerが公開したJavaScript/TypeScriptランタイムです。GitHubスター76k+。JavaScriptCoreエンジン（Safariが使うV8以外のエンジン）上にZig言語で実装され、起動速度・実行速度がNode.jsの3〜5倍高速。Node.jsとの互換性を最優先に設計されており、既存のNode.jsコードがほぼそのまま動作します。パッケージマネージャー（bun install）・バンドラー（bun build）・テストランナー（bun test）が単一の実行ファイルに統合されています。

# Bunのインストール
# Windows
powershell -c "irm bun.sh/install.ps1|iex"
# Linux/macOS
curl -fsSL https://bun.sh/install | bash

bun --version  # 1.x.x

# Bunで高速HTTPサーバー
cat > server.ts << 'EOF'
const server = Bun.serve({
  port: 3000,
  fetch(req) {
    const url = new URL(req.url);
    return Response.json({
      message: "Hello from Bun",
      path: url.pathname,
      runtime: "bun",
      version: Bun.version,
    });
  },
});
console.log(`Listening on http://localhost:${server.port}`);
EOF

bun run server.ts  # TypeScriptもそのまま実行

# Bunのパッケージマネージャー（npmより高速）
bun install              # npm install の5〜10倍高速
bun add lodash           # npm install lodash
bun add -d vitest        # npm install -D vitest
bun remove lodash        # npm uninstall lodash

# bun.lockbファイル（バイナリ形式のロックファイル）
# package-lock.json / yarn.lock の代替

# Bunテストランナー（Jest互換）
bun test                 # src/**/*.test.ts を自動検出
bun test --watch         # ウォッチモード
bun test --coverage      # カバレッジレポート

# 既存のNode.jsプロジェクトをBunで実行
cd existing-node-project
bun install    # node_modulesを高速インストール
bun run dev    # package.jsonのdevスクリプトをBunで実行

ベンチマーク比較（2026年）

# HTTPサーバーの性能比較（wrk ベンチマーク）
# 4コア, 8GB RAM の環境で計測

# Node.js (fastify)
wrk -t4 -c100 -d30s http://localhost:3000
# Requests/sec: ~45,000

# Deno (標準サーバー)
wrk -t4 -c100 -d30s http://localhost:3001
# Requests/sec: ~50,000

# Bun (Bun.serve)
wrk -t4 -c100 -d30s http://localhost:3002
# Requests/sec: ~120,000

# 起動時間の比較
time node -e "console.log('started')"   # ~50ms
time deno run --allow-env -e "console.log('started')"  # ~100ms (初回はキャッシュミス)
time bun -e "console.log('started')"    # ~15ms

機能比較表

比較項目	Node.js 22	Deno 2	Bun 1
TypeScript対応	❌（要コンパイル）	✅ネイティブ	✅ネイティブ
セキュリティモデル	なし	パーミッション制御	なし
npm互換	✅	✅（npm:プレフィックス）	✅（高い互換性）
起動速度	中	中（初回遅い）	最速
実行速度	中	中〜高	最高
バンドラー内蔵	❌	✅	✅
テストランナー内蔵	✅(実験的)	✅	✅
フォーマッター内蔵	❌	✅(deno fmt)	❌
エッジデプロイ	Vercel/Netlify	Deno Deploy	Fly.io
GitHub Stars	110k+	100k+	76k+

Bunの実行速度と同様の最適化技術がLLMツールにも応用されています。/categories/llm-toolsでAI/LLM関連ツールの最新動向をご確認ください。JavaScriptランタイムの選択はDevOpsのCI/CDパイプライン設計にも影響します。/categories/devopsで実践的なCI/CD構成を解説しています。

FAQ

Q. 既存のNode.jsプロジェクトはBunやDenoに移行できますか？

A. Bunへの移行は最も簡単です。Node.js互換性を最優先に設計しているため、多くのケースでpackage.jsonとソースコードをそのままでbun install && bun run startが動作します。互換性問題が出やすいのは: ①Node.jsのネイティブモジュール（.node拡張子のC++アドオン）②特定のAPIの微妙な挙動の違い③__filename・__dirnameのESModules環境での扱い。Denoへの移行は書き直しが必要なケースが多い: ①CommonRequest(require)をESModules(import)に変更②node_modulesをnpm:プレフィックスかURLインポートに変更③process.envをDeno.env.get()に変更④セキュリティ許可フラグの追加。まずbun install && bun testで既存テストが通るか確認し、問題なければBunへの移行を検討するのが現実的です。

Q. Denoのパーミッションシステムは実際の開発で面倒ではありませんか？

A. 開発中はやや面倒ですが、本番環境のセキュリティには大きなメリットがあります。実用的な対処法:

# deno.json で許可設定を記述（プロジェクト単位）
cat > deno.json << 'EOF'
{
  "tasks": {
    "dev": "deno run --allow-net --allow-read=. --allow-env --watch main.ts",
    "start": "deno run --allow-net=api.yourservice.com --allow-read=/tmp --allow-env=PORT,DATABASE_URL main.ts",
    "test": "deno test --allow-net --allow-read=./test"
  },
  "permissions": {
    "net": true,
    "read": [".", "/tmp"],
    "env": ["PORT", "DATABASE_URL"]
  }
}
EOF

deno task dev   # 上記の設定で起動

# あるいは開発中は --allow-all で全許可（本番は最小権限）
deno run --allow-all main.ts

本番環境での最小権限適用により、サプライチェーン攻撃（悪意のあるnpmパッケージが個人情報を外部送信する等）のリスクを大幅に下げられます。npm installで入れたサードパーティパッケージもDenoのパーミッション制約を受けるため、悪意のあるパッケージが環境変数（API鍵等）を盗もうとしてもネットワーク送信が拒否されます。

Q. Deno DeployとVercel・Cloudflare Workersの違いは何ですか？

A. Deno DeployはDenoネイティブのエッジコンピューティングプラットフォームです。

// Deno Deploy: Denoのコードをそのままデプロイ
// deployctl install でCLIインストール後:
// deployctl deploy --project=myapp main.ts

// World-wide edge: 35+のデータセンターで自動分散
Deno.serve((req) => {
  return new Response(`Hello from ${Deno.version.deno}!`);
});

比較:

• Deno Deploy: Denoのフルランタイム（TypeScript・Deno KV・Web API）。無料プランあり。GitHubと直接統合。
• Cloudflare Workers: V8 Isolateベース（Denoよりも制限あり）。最速のエッジネットワーク。Workers KV・R2ストレージ統合。
• Vercel Edge Runtime: Next.js統合が最強。Web標準API対応。Node.jsのすべての機能は使えない。

TypeScriptで書かれたAPIサーバーをDenoでデプロイする場合: deno task start → CI/CDでDeployへ自動デプロイ、という流れが最もシンプルです。

Q. BunはNode.jsより本当に速いですか？どのようなユースケースで差が出ますか？

A. 速度差が最も顕著なユースケース:

# 1. パッケージインストール速度
time npm install  # 中規模プロジェクト（100パッケージ）: 30秒
time bun install  # 同上: 3秒（10倍高速）

# 2. 起動時間（CLIツール・Lambda等の短命プロセス）
time node dist/cli.js --help    # 200ms
time bun run dist/cli.js --help # 30ms

# 3. ファイルI/O集約処理
# Bunは独自の最適化されたI/O実装で高速

# 4. シンプルなHTTPサーバー
# Bun.serveは Node.js HTTPより2〜3倍のスループット

# 速度差が小さいユースケース
# - CPU集約処理（暗号化・圧縮等）: V8とJavaScriptCoreは似たような速度
# - データベースクエリ主体のアプリ: ボトルネックがDBなので差は小さい
# - 既存のExpress.jsアプリをBunで動かす場合: Express自体のオーバーヘッドが大きい

まとめ: CLIツール・Lambda関数・パッケージマネージャーでは速度差が劇的。長時間稼働のAPIサーバーではBun.serveを使えば差が出るが、Expressをそのまま使うと差は小さい。

まとめ

ユースケース	推奨ランタイム
既存Node.jsの高速化	Bun
TypeScript+セキュリティ重視	Deno
最大エコシステム・実績重視	Node.js
CLIツール作成	Bun
エッジデプロイ	Deno Deploy

関連外部リソース

• Deno公式サイト↗
• Bun公式サイト↗
• Node.js公式サイト↗
• bun vs node benchmark↗