先に要点
- Deno は Node.js を作った Ryan Dahl 氏が再設計 した JavaScript / TypeScript ランタイム。「Node の反省点を組み直す」 という強い動機からスタートしている。
- 特徴は 権限ベースのセキュリティ」 「Web 標準 API ベース」 「TypeScript を標準サポート」 「URL / npm: からの import」 `Deno Deploy(エッジ実行基盤) の5本。「Node が抱える歴史的負債を引き継がない」 設計。
- v2 以降は npm: 接頭辞で npm パッケージをそのまま使える 互換性が大きく改善し、「Node 資産を捨てずに Deno に乗せ替える」 が現実的になってきた。
- 本命の使い所は セキュリティを構造的に保ちたいスクリプト / サーバレス / エッジ用途。Bun と並んで、「Node 以外の選択肢」 として実用フェーズに入っているランタイム。
Deno ってよく聞くけど、結局 Node / Bun との違いは何？ セキュリティが厳しいって本当？ npm のパッケージは使えるの？ 「Deno Deploy って何？」 ── 2020年の v1 リリース以降、Deno は 「Node を再設計したランタイム」 として段階的に成長を続け、2026年現在では 本番運用に乗せる選択肢のひとつ として扱われています。
ざっくり言うと、Deno は Node が10年で積み上げてきた歴史的負債を、最初から避けて作り直した JavaScript / TypeScript ランタイム です。 Web 標準 API、TypeScript の標準サポート、権限ベースの実行モデル、URL ベースの import など、「Node とは違うやり方」 が随所に組み込まれています。
この記事では、2026年5月時点の Deno の現状をベースに、何ができるか・Node / Bun との違い・どう書くか・Deno Deploy・採用判断軸 を整理します。 仕様や互換性は活発に変化しているので、最終確認は 公式ドキュメント を見るのが安全です。
Deno を作った動機
Deno が 「何を解決するために生まれたか」 を押さえると、設計判断の意味が分かります。
Node.js の反省点
Ryan Dahl 氏は Node.js を作って後悔している10のこと という講演で、「node_modules の膨らみ」 「セキュリティの緩さ」 「package.json の中央集権」 などへの後悔を表明している。Deno はその反省を初期設計に反映している。
Web 標準を採用
「fetch」 「WebSocket」 「URL」 「crypto」 など、「ブラウザにある API はそのまま使えるべき」 という思想。Node が独自 API を増やした世界とは逆方向。
セキュリティ第一
「 何も許可しない状態から、必要な権限だけ明示的に与える」 設計。Node のように 「スクリプト実行 = ファイルシステムも環境変数も全部触れる」 を構造的に防ぐ。
TypeScript ファースト
TypeScript を 「公式に標準サポート」。「.ts ファイルを直接実行」 が 「deno run app.ts」 だけで可能。
「Node の後継として作られた」 のではなく、Node の経験を踏まえて別の道を歩むランタイム という立ち位置です。
Deno の中心となる5つの特徴
「Deno を選ぶと何が変わるか」 を5つに整理します。
①権限ベースのセキュリティ
「deno run」 はデフォルトで ネットワーク・ファイル・環境変数・サブプロセス起動などへのアクセスを拒否。必要な権限を 「--allow-net」 「--allow-read」 などで明示する。「怪しい script を実行 = 即マシン全部が危険」 という Node 的なリスクを構造的に減らせる。
② Web 標準 API ベース
「fetch」 「Request」 「Response」 「URL」 「WebSocket」 「crypto」 など、ブラウザに揃っている API がそのまま使える。「Node API と Web API のダブルスタンダードを覚える」 必要がない。
③ TypeScript 標準サポート
「deno run app.ts」 で TS をそのまま実行。Node では 「ts-node」 / 「tsx」 / Bun に頼っていた領域を、ランタイム自身が肩代わり。
④ URL / 「npm:」 経由の import
「import { z } from "npm:zod"」 のように 直接 npm パッケージを import できる(v2 以降)。「package.json は要らない、必要ならあってもよい」 が方針。
⑤ ツールチェーン統合
「deno fmt」(整形)、「deno lint」、「deno test」、「deno bench」 が 1コマンドで揃う。「設定ファイルを各種揃える」 苦労がない。
「Web 標準 + セキュア + TS + 統合ツール」 という4つの方向性が、Deno を 「モダンな選択肢」 として位置づけている主因です。
Node / Bun との比較
3つを並べると、それぞれの立ち位置が立体的に見えます。
| 軸 | Node.js | Deno | Bun |
|---|---|---|---|
| 登場時期 | 2009 | 2018(v1.0 は2020) | 2022 |
| 実装言語 | C++ + JavaScript | Rust | Zig |
| エンジン | V8 | V8 | JavaScriptCore |
| セキュリティ | 明示的サンドボックスなし | 権限ベース(「--allow-*」) | Node 同様、外で管理 |
| TypeScript | 外部ツール必須 | 標準サポート(「.ts」 直接実行) | 標準サポート |
| パッケージ | npm + node_modules | URL / npm: / JSR | npm 高互換 + 内蔵 install |
| 速度感 | 標準的 | Node より速い場面が多い | 速い(install / start) |
| 本番採用実績 | 圧倒的 | 増加中 | 増加中 |
| マネージドサービス対応 | あらゆる PaaS / Lambda 等 | Deno Deploy / Supabase Edge / Netlify Edge 等 | Vercel ほか拡充中 |
| 主な強み | 圧倒的な互換性と実績 | セキュリティ + Web 標準 + Deploy | 速度 + ツール統合 |
「どれが優れている」 ではなく、Node = 業界標準、Deno = セキュアでモダン、Bun = 速度と統合体験 という3つの軸でそれぞれ強い領域を持っている、というのが2026年現在の正しい認識です。
基本の書き方 — 「deno run」 と権限
最小例で雰囲気をつかみます。
// server.ts
Deno.serve((req) => {
return new Response("こんにちは Deno!");
});
# 何も許可しない場合は権限エラーになる
deno run server.ts
# ネットワーク許可で実行
deno run --allow-net server.ts
「Deno.serve」
Deno 標準の HTTP サーバ。「Bun.serve」 と似たシンプル API で、Express や Fastify を入れなくても 「1行で HTTP 待ち受け」 が可能。
権限フラグ
「--allow-net」(ネット)、「--allow-read」(ファイル読み込み)、「--allow-write」(書き込み)、「--allow-env」(環境変数)、「--allow-run」(サブプロセス)など。「必要なものだけ」 を明示するのが流儀。
「-A」 / 「--allow-all」
全部許可。「開発時の楽さ」 と引き換えに 「Node と同程度のセキュリティモデル」 になる。本番ではなるべく避け、最小権限に絞り直すのが理想。
npm 利用
「import express from "npm:express"」 のように接頭辞 「npm:」 を付けるだけで npm パッケージを取り込める。「package.json 不要」 が魅力。
「権限のことを毎回意識する」 のは最初少し面倒に感じるかもしれませんが、「 どのスクリプトが何を触るか」 が明文化されること は、長期的にチームのセキュリティ衛生に効きます。
Deno Deploy — エッジ実行基盤
Deno を語る上で外せないのが、Deno 公式が提供する Deno Deploy という エッジ実行基盤 です。
グローバル分散
世界中のリージョンで実行される 「エッジ寄りのサーバレス」。Cloudflare Workers / Vercel Edge と同じカテゴリ。
無料枠もある
個人や小規模プロジェクト向けに使いやすい無料枠を提供。「小さなアプリを試したい」 に対する敷居が低い。
「書いて Deploy するまでが Deno のセット」 という設計が、Node や Bun とは異なる体験を与えます。
どこで詰まりやすいか
便利な反面、Deno で踏みやすい注意点も整理します。
①npm の非互換パッケージ
「 npm:」 で取り込めるとはいえ、「Node 固有 API(child_process, ネイティブアドオン)」 に強く依存するパッケージは動かない / 動くが警告が出る。移行候補のパッケージを最初に試して動作確認 が必須。
② エコシステムの厚み
Node の 「数十万のライブラリ + ブログ記事 + StackOverflow」 と比べると、まだ厚みは劣る。英語の Deno コミュニティ・GitHub Issue を読む覚悟 が必要な場面がある。
③ ホスティング
「 Deno を一級サポートする PaaS」 は増えてきているが、「Node 専用の PaaS にそのままは載らない」 ケースがある。Lambda などで動かす場合は 「Custom Runtime」 等の段取りが必要。
④ チームの学習コスト
「 --allow-net をいつ書くか」 「package.json をどう扱うか」 「npm: 接頭辞をいつ使うか」 など、Node に慣れている人ほど新しい概念に慣れる時間が必要。
「Node にあったライブラリは全部使える」 という期待で行くと痛い目を見やすいので、採用前に主要依存を試す ことが大事です。
採用判断のチェックリスト
「いま Deno を選ぶべきか」 の判断軸を整理します。
「Node を完全に置き換える」 ではなく、「Deno が合う場面に Deno を選ぶ」 という付き合い方が現実的です。 Bun と用途を分けて考えるなら、「セキュリティと Web 標準志向は Deno、速度と統合体験は Bun」 という棲み分けが分かりやすい指標になります。
AI 時代の Deno 観
AI 連携の文脈でも、Deno の特徴は活きます。
権限ベース × エージェント実行
「 AI エージェントが書いたスクリプトを安全に実行する」 用途で、権限ベースモデルは強い味方になる。「AI が出したコードを試したいが、全権限を渡すのは怖い」 という現実的な懸念に応える設計。
エッジ + AI ストリーミング
Deno Deploy / Supabase Edge は AI のストリーミング応答と相性が良い。「AI 出力 → エッジで整形 → クライアントに流す」 の構成を素直に組める。
小さなツールを書きやすい
「deno run script.ts」 で即実行できるので、AI 開発で頻発する 「スクリプトをサッと書いて試す」 用途に向く。「package.json を作る前段の摩擦」 がない。
「セキュア + Web 標準 + エッジ + 小さなツール志向」 という Deno の強みは、AI 時代の使い方とも自然に結びついています。
Deno に関するよくある質問
Q. Deno は Node の代わりになりますか？
A. 一部の用途で代わりになる、すべてを置き換える段階ではない」、というのが正確な答えです。「小さなツール / 内部スクリプト / エッジ向け API」 では Deno が十分実用的ですが、「既存の大規模 Node プロジェクトを丸ごと移行する」 のは依存パッケージの互換性次第です。
Q. 「npm:」 で全部の npm パッケージが動きますか？
A. 大半は動きますが、例外があります。Node 固有 API に強く依存するもの、ネイティブモジュール、特殊な後方互換 hack を使うパッケージで動かないケースが残ります。「採用前に依存を確認」 する習慣を持つのが安全です。
Q. Deno と Bun はどちらを学ぶべきですか？
A. 用途で分けると分かりやすいです。「 セキュアにスクリプトを動かしたい・エッジで動かしたい」 なら Deno、「Node 資産を活かしながら速度を上げたい」 なら Bun。両方触ってみて自分の好みに近い方を主軸にするのも現実的です。
Q. Deno Deploy は商用利用できますか？
A. はい。有料プランが用意されており、商用利用も可能 です。無料枠は試行 / 個人向け、有料はビジネス向け、というプラン構造になっています。最終的な料金は公式の Pricing で確認してください。
Q. JSR とは何ですか？
A. JavaScript Registry の略で、Deno チームが推進する モダンな npm の代替パッケージレジストリです。TypeScript ファースト、URL ベース、整理された API という設計で、「npm の後継候補のひとつ」 として位置づけられています。「JSR + npm を併用する」 のが現実的な運用です。
Q. セキュリティ権限を細かく設定するのは煩わしくないですか？
A. 最初は煩わしく感じるかもしれませんが、何を許可しているかを意識する ことが結果的にコードレビューや事故防止に効きます。「deno.json で開発用のスクリプトを定義して、必要な権限を一覧化する」 のが運用上のコツです。
Q. Deno は学習コストが高いですか？
A. Node / TypeScript の経験があれば 1〜2日で書き始められる 程度です。「権限フラグ」 「import の書き方」 「npm: 接頭辞」 など、「Node とは違うところ」 を意識して覚えれば、コードそのものは普通の TypeScript として読み書きできます。
参考リンク
- Deno: 公式サイト
- Deno Docs: Documentation
- Deno Deploy: 公式
- JSR: JavaScript Registry
- Ryan Dahl: 10 Things I Regret About Node.js
- Supabase Edge Functions: 公式
- Netlify Edge Functions: 公式