「Deno 2.0が出たって聞いたけど、Node.jsからもう移行すべき？」

5月の連休明けに、フリーランス仲間のDiscordサーバーでこの話題が盛り上がっていました。

僕自身もタイミングよく「新規の小規模APIプロジェクトが入ってきた」ので、思い切ってDeno 2.0で構築する1ヶ月実験をしてみました。

結論から言うと——**新規プロジェクトで使うなら、Denoはかなり”アリ”**です。でも「既存のNode.jsプロジェクトを全部Denoに移行しよう」は、現時点では正直おすすめしない理由があります。

この記事では、1ヶ月間の使用ログと、「移行すべきかどうか」の判断基準を書きます。

そもそもDenoとは？なぜ今注目されているのか

Denoは、Node.jsの作者であるRyan Dahlが「Node.jsへの後悔」を語った有名な講演の後に開発した、新しいJavaScript/TypeScriptランタイムです。

「package.json」「node_modules」「CommonJS」などに後悔があると語り、Denoが解決しようとしている問題を一言で言えば：

「TypeScriptがネイティブで動き、セキュリティが設計段階から組み込まれた、シンプルなランタイム」

主な特徴：

• TypeScript nativeで動く — tscやts-nodeが不要
• セキュリティファーストの設計 — ファイルシステム・ネットワークへのアクセスは明示的な許可が必要
• 標準ライブラリが充実 — npmに頼らず基本的な機能が使える
• NPM互換 — npm: プレフィックスでnpmパッケージも使える（2.0で大幅改善）
• URLインポートに対応 — ファイルを直接URLからインポートできる

Node.js入門でNode.jsの基礎を学んだ後に読むと、比較の視点が持ちやすいです。

1ヶ月の検証ログ

1週目：環境構築と初期印象

まず環境構築。これが異様に簡単でした。

# macOSの場合
curl -fsSL https://deno.land/install.sh | sh

# バージョン確認
deno --version
# deno 2.0.x

以上。これだけで環境が整います。Node.jsのようにnvm/nvmrcでバージョン管理する必要もなく、npmも不要。

（ここ書くのに「本当にこれだけ？」と3回確認した）

最初に書いたHello Worldはこんな感じ：

// server.ts
const handler = (req: Request): Response => {
  return new Response("Hello from Deno!", {
    headers: { "Content-Type": "text/plain" },
  });
};

Deno.serve(handler);

実行：

deno run --allow-net server.ts

TypeScriptのまま動く。ビルドもなし。これが地味にストレスフリー。

2週目：TypeScript nativeの恩恵と標準ライブラリ

2週目は、実際のAPIを書きながら標準ライブラリを探索しました。

Node.js + TypeScriptの構成と比べて最も感じたのが、型チェックの即座性です。Node.jsでTypeScriptを使う場合、ts-nodeやtsxなどのツールが必要で、tsconfig.jsonの設定も必要です。Denoはそれが一切いらない。

Denoの標準ライブラリも便利です：

// ファイル操作（Node.jsのfsモジュール相当）
import { readTextFile } from "jsr:@std/fs";
import { parse as parseCSV } from "jsr:@std/csv";

const data = await readTextFile("./data.csv");
const rows = parseCSV(data, { skipFirstRow: true });

Node.jsで同じことをやると、csvParseのnpmパッケージを入れて、tsconfigを設定して…と手順が増えます。

3週目：NPM互換の現実とHono.jsとの組み合わせ

3週目で最も時間を使ったのが、NPM互換の確認でした。

Deno 2.0ではnpm:パッケージ名という記法でnpmパッケージをそのまま使えます：

// npmパッケージをそのまま使う
import { z } from "npm:zod";
import type { Handler } from "npm:express";

ただ、ここがポイントなんですが——全てのnpmパッケージがそのまま動くわけではない。特にバイナリビルドを含む一部のパッケージ（native addonsを使うもの）は動作しないケースがあります。

今回の案件ではHono.jsをDeno上で動かしました。これは問題なく動いた：

import { Hono } from "jsr:@hono/hono";

const app = new Hono();

app.get("/api/health", (c) => c.json({ status: "ok" }));
app.get("/api/users/:id", async (c) => {
  const id = c.req.param("id");
  return c.json({ id, name: "sample" });
});

Deno.serve(app.fetch);

Hono + Denoの組み合わせは、かなりスムーズでした。

4週目：CI/CDとデプロイ

4週目はGitHub ActionsでのCI/CDと、デプロイを試しました。

# .github/workflows/ci.yml
name: Deno CI

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: denoland/setup-deno@v2
        with:
          deno-version: v2.x
      - name: Lint
        run: deno lint
      - name: Format check
        run: deno fmt --check
      - name: Type check
        run: deno check **/*.ts
      - name: Test
        run: deno test --allow-all

ここは正直感動しました。 deno lint・deno fmt・deno checkが全部標準で入っているので、ESLint/Prettier/tscの設定ファイルを書く必要がない。

pnpm vs npm vs yarnで悩んだパッケージマネージャー問題が存在しないのも地味にうれしい。

---

Denoが本当に良かった点

4週間使って「これは本当に良い」と感じた点をまとめます。

1. TypeScriptをそのまま実行できるシンプルさ

プロジェクトのセットアップ時間が体感で3分の1になりました。Node.js + TypeScriptの場合、最低でもtsconfig.json、.eslintrc、.prettierrcを書く必要があります。Denoはこれらが不要。

2. セキュリティが明示的

# ファイルアクセスとネットワーク、環境変数だけを許可
deno run --allow-read --allow-net --allow-env server.ts

「このスクリプトは何にアクセスするか」が実行時に明示されます。本番環境にデプロイするときに、スコープが明確になるのはセキュリティ上のメリットです。

3. deno fmt / deno lint の一体感

設定ファイルなしで標準のコードスタイルが使えます。Biome vs ESLint/Prettierで書いたような「フォーマッター設定戦争」が起きません。

---

正直微妙だった点（ここ書くのに少し悩んだ）

全部ポジティブだとAIっぽいので、正直に書きます。

1. npmエコシステムとの互換性が100%ではない

native addonsを使うパッケージは動きません。特に：

• 画像処理系（sharpなど）
• データベースドライバの一部（MySQL系のネイティブドライバなど）

今回の案件はシンプルなREST APIだったのでほぼ問題なかったですが、複雑なNode.jsプロジェクトへの移行はリスクがあります。

2. エコシステムがNode.jsに比べてまだ小さい

JSRレジストリは充実してきていますが、npmと比べると選択肢が少ないのは事実。「npmにはあるけどDenoで使いやすい形で提供されていない」ツールがまだあります。

3. チームへの浸透コスト

ソロ開発なら問題ないですが、チームでDenoを採用する場合は学習コストが発生します。「Node.jsはわかるけどDenoは初めて」というメンバーへのオンボーディングが必要。

ここ、マジで大事なんですけど——「技術的に良い」と「チームで採用すべき」は別の話なんですよね。これはプログラミング的に言うと、コードの正確さとデプロイのコストは別問題、みたいな話。

---

結論：Denoに移行すべきプロジェクトの条件

1ヶ月間の実験を踏まえた判断基準です。

Denoが向いているプロジェクト：

• 新規のAPI/サーバーサイドプロジェクト
• TypeScriptを最初から使う予定
• npmの依存が少ない（シンプルなビジネスロジック中心）
• CI/CDをシンプルに保ちたい
• ソロ or 少人数チーム

Node.jsのままにすべきプロジェクト：

• 既存の大規模Node.jsプロジェクト
• native addonsに依存したパッケージを使っている
• チームメンバーがNode.jsに慣れていて、Deno学習コストが負担になる
• 安定性優先のプロダクション環境

BunとNode.jsの比較記事も書いていますが、2026年時点での感触は「Node.js → Bun の方が移行コストが低く、Node.js → Deno はより大きな思考の切り替えが必要」です。

---

よくある質問

Q: DenoとNode.js、2026年に新規プロジェクトを始めるならどちらがいい？

A: 小〜中規模の新規プロジェクトで、TypeScriptをメインに使うならDenoは十分に選択肢になります。大規模なプロジェクト、または既存のnpmエコシステムへの依存が多い場合はNode.jsが安全です。「正しい答え」は用途次第なので、この記事の判断基準を参考に選んでください。

Q: DenoはNPMパッケージが使えないの？

A: Deno 2.0からはnpm:パッケージ名という記法でnpmパッケージが使えます。多くの主要パッケージは問題なく動きますが、native addons（C++バインディングなど）を使うパッケージはまだ非対応のものがあります。REST APIやフロントエンドビルドツールなど、JavaScriptのみで動くパッケージはほぼ使えます。

Q: Denoの学習にかかる時間はどれくらい？

A: Node.jsの経験があれば、基本的なAPIサーバーが書けるようになるまで週末2〜3日程度です。文法自体はNode.jsとほぼ同じTypeScript/JavaScriptで、違いはセキュリティ許可フラグとJSR/URLインポートあたりです。

Q: DenoとBunはどっちが速い？

A: ベンチマーク上はどちらも「Node.jsより速い」という結果が多いですが、実用上の差は体感しにくいです。「速さ」よりも「DX（開発者体験）の違い」で選ぶ方が本質的です。Denoはセキュリティ/標準ライブラリ優先、BunはNode.js互換性優先という思想の違いがあります。

Q: Dockerと組み合わせて使えますか？

A: 問題なく使えます。Docker入門で紹介しているコンテナ化の概念はそのまま適用できます。公式のdeno:alpineイメージが提供されており、Dockerfileも数行で書けます。

---

追記（2026/05/22）: この記事を書いた後、Deno 2.1のRC版がリリースされたという情報が出てきました。Node.js互換性がさらに改善され、より多くのnpmパッケージが動くようになるとのこと。本記事はDeno 2.0.x時点の情報ですが、今後もエコシステムの成熟は続きそうです。

---

あわせて読みたい

• Node.js入門：JavaScriptでバックエンドを作る最初の一歩（2026年版）
• BunとNode.jsを1ヶ月使い比べた話【2026年版】
• pnpm vs npm vs yarn 2026：現場で使うパッケージマネージャーの選び方
• Hono.js入門：よくある疑問をQ&Aで解説【2026年版】
• GitHub Actions入門2026：CI/CDパイプラインを最速で構築する