✍️ 필사 모드: Deno 2と3 深掘り 2026 — Node互換の時代、JSR・Fresh 2・Deno KVの現在地(ランタイムの賭けはどこに着いたか) 日本語

プロローグ — Ryan Dahl の二度目の自己否定

Ryan Dahl は 2009年に Node を作り、2018年の JSConf EU で「Node について後悔している10のこと」という有名な発表をした。そして Deno を作った。デフォルト deny のセキュリティ、TS は一級市民、依存は URL import、package.json は存在しない — すべてが Node に対する明示的な回答だった。

ところが 2024年9月、Deno 2 が出た。最大の変化は自己否定だ。

• package.json 対応 — 一級市民として。
• node_modules ディレクトリ対応 — オプションだが有効化可能。
• npm レジストリからのパッケージ import — npm:/jsr: specifier で。
• deno install を npm 互換のパッケージマネージャに。
• workspace(モノレポ)対応。

Deno が当初拒んだ Node の設計判断のほぼ全てを、6年を経て受け入れた。プライドを呑んで。

これは退却なのか、進化なのか。両方だ。理想主義から実用主義への転換であり、同時に JS エコシステムの現実(npm は消えない)を認めた賭けでもある。

本稿は Deno 2 リリース後およそ20ヶ月、2026年5月時点で Deno の賭けがどこまで来たか、Bun・Node 22+ との三つ巴はどう収束したか、セキュリティモデル・JSR・Fresh 2・Deno KV が現実のどこに位置づいているかを整理する。

1章 · Deno 2 の核 — Node 互換がデフォルトになる

Deno 1 の世界観、その限界

Deno 1 は純粋な世界を描こうとした。

• URL import — import { foo } from "https://deno.land/std/...";
• 明示的な権限 — deno run --allow-net=api.example.com server.ts
• TypeScript 一級 — 設定なしで .ts を実行。
• node_modules なし、package.json なし。

問題は単純だった。JS 世界の 90% は既に npm の上にあった。Express, React, Prisma, AWS SDK, Sentry, Stripe SDK — すべて npm。Deno は早期に npm: specifier を互換シムとして追加したが、本格 production に持っていくには足りなかった。package.json に書かれた依存をそのまま読めず、node_modules を触るフルスタック・ツールが壊れ、モノレポのワークフローが不格好だった。

Deno 2 の答えは明快だ。「Node のやり方でも動く」。

何が変わったか(2024年9月)

# Deno 2 — 既存の Node プロジェクトから
deno install            # package.json を読み node_modules を生成
deno run npm:express    # npm パッケージを直接実行
deno task dev           # package.json の scripts.dev を実行

Deno 2 のモットーはもはや「Node を置き換える」ではない。**「Node と Deno の摩擦を限りなくゼロに近づける」**だ。

マイグレーションは楽になったか

既存の Node プロジェクトをそのまま Deno で動かすと:

• 小さな Express API — 5分で動く場合が多い。deno run --allow-net --allow-read npm:tsx server.ts。
• Next.js — 動く。ただし next dev/next build が Node を直接呼ぶことが多く、権限モデルの意味がぼやける。
• Prisma + Postgres — 動く。ネイティブバイナリ互換に少し摩擦がある場合あり。
• AWS SDK v3 — ほぼそのまま動く。

最初の1年で摩擦が大きかったのは ネイティブアドオン(sharp, canvas, bcrypt-native などの C++ バインディング)で、2025年を通じて N-API 互換は段階的に良くなった。2026年中盤時点で、一般的な npm パッケージの90%以上は Deno 2 でほぼ問題なく動く。

2章 · deno install — npm 互換のパッケージマネージャ

二つのモード

deno install は二つのモードで動く。

# グローバル binary インストール(Deno 1 から)
deno install -gA --name lint jsr:@std/cli/parser

# プロジェクト依存のインストール(Deno 2 で新規)
deno install            # package.json を読み node_modules を生成
deno install --add npm:express@4   # 新しい依存を追加
deno install --add jsr:@hono/hono  # JSR の依存を追加

二つ目のモードがパラダイム転換だ。npm install, pnpm install, yarn install をそのまま置換できるコマンドになった。

速度と lockfile

hot cache, 約500依存:
  npm install:    14s
  pnpm install:    4s
  bun install:     1.3s
  deno install:    2.1s

bun install ほど速くはないが、pnpm install より速く、npm install よりはるかに速い。lockfile は deno.lock(テキスト JSON)で、最初から diff-friendly に設計されている。Bun が binary lockfile で一度つまずいた点と対照的だ。

node_modules モード

// deno.json
{
  "nodeModulesDir": "auto",   // または "manual" または false
  "lock": true
}

auto にすると package.json を読んで自動的に node_modules を作る。manual は npm/pnpm/yarn で作られた既存の node_modules をそのまま使う(大きなモノレポ移行のシナリオ)。false だと Deno 1 スタイルのグローバルキャッシュのみ。

このオプションが存在すること自体が、理想主義を脇に置き実用主義を選んだ証拠だ。

3章 · deno run で npm パッケージを直接実行

npm: specifier の進化

Deno 2 のモットーの一つは**「追加設定なしで npm パッケージを import する」**だ。

// app.ts
import express from "npm:express@4";
import { z } from "npm:zod";
import OpenAI from "npm:openai";

const app = express();
app.get("/", (_, res) => res.json({ ok: true }));
app.listen(3000);

deno run --allow-net --allow-read --allow-env app.ts

これがそのまま動く。package.json も不要、node_modules も不要(グローバルキャッシュに取得される)。Bun と Node が package.json を必須とするのに比べ、単一ファイルのスクリプトは Deno が一番滑らかだ。

Bun と Node との比較

# 単一ファイルのスクリプトに npm 依存

# Deno
deno run --allow-net script.ts

# Bun
bun script.ts            # bun add が必要、または inline shebang のトリック

# Node
npm init -y && npm i express && node script.js

**「クイックスクリプト + npm 一つ二つ」**の領域では Deno の DX が優勢だ。Deno 1 からの強みが Deno 2 でも生きている。

4章 · JSR — JavaScript Registry の賭け

なぜまた別のレジストリ

JSR(jsr.io)は Deno チームが 2024年初に立ち上げた新しい JavaScript レジストリだ。npm が既にあるのになぜ?

JSR の主張:

1. TS-native publishing — TS ソースをそのまま publish。利用側がビルドツールを選ぶ。(npm は通常コンパイル済み JS + .d.ts。)
2. 標準 ESM のみ — CJS なし、package.json の迷路なし。
3. ランタイム非依存 — Deno だけでなく Node・Bun・ブラウザから import 可能。
4. 品質スコア — ドキュメント・テスト・型の充実度を score で表示。
5. scope が一級 — @scope/package モデルが基本。

使い方

// そのまま import
import { parse } from "jsr:@std/cli/parser";
import { Hono } from "jsr:@hono/hono";

# package.json スタイル
deno install --add jsr:@hono/hono

# Node からも使える
npx jsr add @hono/hono
# または直接 — ビルド済み形式で取得

採用の現実 — 2026 mid

JSR は**「npm を殺す」ではなく、「TS-first の別の選択肢を作る」**だ。一定程度成功した — Deno エコシステム内では standard、外では niche。

JSR が変えたこと

• TS ライブラリの著者がビルドツール選択を利用者に委ねられるようになった。それだけで大きな簡素化。
• npm の exports 迷路(CJS/ESM/types のパス対応)を回避できる道ができた。
• semver/型/ドキュメントを統合したスコアシステム — パッケージ品質の最初の真面目な標準化の試み。

npm 側の反応

興味深いディテール。Deno は 2024年に npm CLI のBSD ライセンスのフォークを作った — 名前は "npm" ではなく別名で(コミュニティガイドラインに従う形)。これが小さなライセンス・ネーミング論争を生んだが、npm Inc. から大きな法的反応はなかった。最終的なメッセージは**「npm 互換が優先、敵対は二の次」**だ。

5章 · Fresh 2 — アイランド・アーキテクチャの第2ラウンド

Fresh 1 の約束

Fresh は Deno の公式フルスタック・フレームワークだった。中核のコンセプト:

• No build step — dev で SSR がそのまま動く。
• Islands architecture — ページの一部だけが hydrate(クライアント JS)し、残りは静的 HTML。
• JSX with Preact — React ではなく Preact、軽さ優先。
• Deno-native — ルーティングとハンドラを Deno の Request/Response 標準で構築。

優れた賭けだったが、1.x の時期は ルーティングモデルの限界(file-based + ハンドラ分離)と React エコシステム互換の不在が採用を制限した。

Fresh 2 が変えたもの

// routes/api/hello.ts (Fresh 2 スタイル)
import { define } from "$fresh/server.ts";

export const handler = define.handlers({
  async GET(ctx) {
    return new Response(JSON.stringify({ msg: "hello" }), {
      headers: { "content-type": "application/json" },
    });
  },
});

// routes/index.tsx
import { define } from "$fresh/server.ts";
import Counter from "../islands/Counter.tsx";

export default define.page<{ now: string }>((props) => (
  <main>
    <h1>現在時刻: {props.data.now}</h1>
    <Counter start={0} />
  </main>
));

Fresh 2 の主な変更:

• 型推論の改善 — define を通じてハンドラとページのデータ型が自動で伝播。
• server components 風のパターン — async コンポーネント、ページ単位のデータ fetch。
• island 検出の改善 — islands/ ディレクトリのコンポーネントだけが hydrate。
• Tailwind 統合の改善 — ビルドステップなしで dev に Tailwind。
• deno deploy 統合 — 一行で Deno Deploy へ。

Fresh が採用で追いつけなかった理由(率直に)

• Next.js の重みが大き過ぎる。フルスタックを始めるなら90%は Next.js を選ぶ。
• Preact という選択が React エコシステムの一部ライブラリ(Form/Data/Animation 系)との互換で摩擦を生む。
• ランタイム横断性が弱い — Vercel/Cloudflare で動かしたい場合に不格好。

Fresh 2 は Deno Deploy に紐づくフルスタックならとても良い選択。だがフルスタックの default になる道は狭い。

6章 · Deno KV — 内蔵 KV が production-ready に

Deno KV の正体

Deno KV は Deno ランタイムに内蔵されたキー・バリュー・ストアだ。SQLite に似た単一ノードモードと、Deno Deploy 上でのグローバル分散モードがある。

// kv.ts
const kv = await Deno.openKv();

// set
await kv.set(["users", "alice"], { name: "Alice", joined: Date.now() });

// get
const result = await kv.get<{ name: string }>(["users", "alice"]);
console.log(result.value?.name);  // "Alice"

// list (prefix query)
for await (const entry of kv.list({ prefix: ["users"] })) {
  console.log(entry.key, entry.value);
}

// atomic transaction
await kv.atomic()
  .check({ key: ["counter"], versionstamp: null })
  .set(["counter"], 1)
  .commit();

2026 時点の状態

Deno KV は Cloudflare KV や Workers KV の位置を狙ったが、Deno エコシステムに縛られている分ポジショニングは厳しい。それでも「一行で始められる分散 KV」というスローガンは本当に成立している。

よく使われる場面

• セッションストア — JWT 代わりのサーバーサイドセッション。
• フィーチャーフラグ — グローバル分散が意味を持つ小さな read-heavy データ。
• キュー / 作業分配 — kv.enqueue + worker。
• キャッシュ — 短い TTL のレスポンスキャッシュ。

弱い領域

• 本格 RDB の位置には合わない — スキーマ・JOIN・広範なトランザクション。
• 外部サービスから直接 KV へアクセスしにくい(必ず Deno ランタイム経由)。
• 大きな値は別所に置き、KV にはメタデータのみ。

7章 · workspace — Deno のモノレポ回答

モノレポが一級市民に

Deno 2 で deno.json の workspace フィールドが追加された。

// ルートの deno.json
{
  "workspace": [
    "./packages/api",
    "./packages/web",
    "./packages/shared"
  ],
  "tasks": {
    "dev": "deno task --filter=* dev"
  }
}

// packages/api/deno.json
{
  "name": "@app/api",
  "version": "0.1.0",
  "exports": "./mod.ts",
  "tasks": {
    "dev": "deno run --watch --allow-net mod.ts"
  }
}

内部パッケージを import { foo } from "@app/shared" で import 可能。pnpm workspace や Bun workspace とほぼ同じモデルだが、Deno の lockfile/キャッシュ統合のおかげでインストール時間は非常に短い。

Turborepo・Nx との比較

Deno workspace は小〜中規模モノレポで滑らか。ビルドグラフキャッシュが必須になる大規模モノレポは Turborepo/Nx をそのまま使う方が安全。

8章 · セキュリティモデル — なお殺し技

最初から最後まで生き残った差別化要因。デフォルト deny。

permission flag 一覧

deno run script.ts                    # ほぼ何もできない
deno run --allow-read script.ts       # ファイル読込
deno run --allow-net script.ts        # ネットワーク
deno run --allow-env script.ts        # 環境変数
deno run --allow-write=./data script.ts   # 特定ディレクトリのみ書き込み

# Deno 2 以降: より細かいスコープ
deno run --allow-net=api.example.com,db.internal:5432 script.ts
deno run --allow-env=DATABASE_URL,REDIS_URL script.ts

運用での実際の意味

良い点:

• 依存に悪意のあるコードが混入しても暴走を抑えられる(サプライチェーン攻撃対策)。
• production コンテナの権限を OS の他にランタイムレイヤーでもう一度狭められる。
• AI エージェントのサンドボックス・ランタイムとして非常に良い — モデルが生成したコードが何をできるかが明示的。

摩擦:

• 最初の1週間は毎回「どの権限が要るか」を推測する。
• --allow-all(-A)で消して始める人が多い。そうなると効果はゼロ。
• 開発と本番で違う権限を与えなければならない場面で設定が複雑になる。

Deno 2 のセキュリティ改善

• --allow-net などに CIDR / ドメイン単位の指定がより精密に。
• --deny-net 系の 明示的拒否フラグ追加 — 広い allow から一部だけ除外。
• production モード推奨 — deno deploy 環境で自動的に狭い権限。
• audit / trace — 実際に呼び出された権限のログ化。

セキュリティモデルは 2025〜2026 年にかけてソフトウェア・サプライチェーン攻撃が増えたことで価値が上がった領域だ。xz-utils 事件、npm の event-stream 事件以降、「デフォルト deny」を真面目に考える会社が増えた。

9章 · Deno 3 はどこにあるか

2026 mid 時点の状況

Deno 3 は 公式リリース前だ(2026年5月時点)。ロードマップ記事と RFC の議論から、次の方向が見える。

• WinterCG 1.0 適合の強化 — fetch、Streams、Response の標準整合。
• TypeScript の type-check デフォルトの再考 — Deno 2 まで type check はデフォルトだったが、重さからデフォルト off の議論がある。
• Node API 互換の最後の隙間 — cluster, dgram, inspector の一部領域。
• JSR とのより深い統合 — score、セキュリティアドバイザリのメタデータを CLI から活用。
• Deno Deploy の isolate-per-region モデルの進化 — Cloudflare Workers との直接競合。

本当に大きな次の賭けが出るのか、段階的アップグレードに留まるのかはまだ決まっていない。Deno 2 が大きな自己否定だった分、Deno 3 は保守的な evolution の可能性が高い。

10章 · Deno vs Bun vs Node 22+ — 三つ巴の整理

2026 mid 時点のポジション

意思決定ガイド

Deno 2 が合う場面:

1. AI エージェントのサンドボックス — モデル生成コードを権限制限して実行。この領域で Deno は明確に1位。
2. 高セキュリティ / 政府 / 金融の一部ワークロード — permission モデルが audit 追跡で意味を持つ。
3. 新規プロジェクトの素早いプロトタイプ — 単一ファイル + npm 依存が最も滑らか。
4. Deno Deploy 上の小さなフルスタック — Fresh 2 + Deno KV。
5. @std 中心のバックエンド・ツール — 標準ライブラリの安定性が魅力。

Bun が合う場面:

1. CI 速度(bun install, bun test)。
2. CLI ツール(bun build --compile)。
3. Edge の cold start。
4. SQLite ヘビーな小規模サービス。

Node 22+ が依然合う場面:

1. 大半のエンタープライズ production。
2. APM/observability が重要な環境。
3. ネイティブアドオンを抱える大規模モノレポ。
4. 会社標準ランタイム — 採用しやすい。

三つのランタイムは zero-sum ではない。一つの会社で Node(メインサービス)、Bun(CLI/CI)、Deno(AI エージェント sandbox、高セキュリティ部分)を併用するパターンが増えている。「どれか一つが全勝」という narrative は 2026 年にはもう合わない。

11章 · npm 互換の broken / over-delivered 領域

Over-delivered

• deno install の安定性 — Deno 1 ユーザーの懸念より滑らかに着地。
• npm: specifier の互換 — Express, Hono, Zod, Prisma client, AWS SDK などメジャー・ライブラリのほぼ全てが OK。
• deno deploy の npm パッケージ対応 — Cloudflare Workers が v8 isolate の制約で動かせない一部 npm を Deno Deploy では動かせる。
• Deno KV の GA — 初期ベータの不安を覆して production-ready。
• JSR のスコアシステム — パッケージ品質の最初の真面目な標準化、急速に定着。

Broken / 依然弱い

• ネイティブアドオン(N-API) — sharp, canvas, bcrypt などは依然摩擦あり。改善中だがゼロではない。
• APM auto-instrumentation — Datadog/NR の Node レベル instrumentation を Deno でそのまま受けられない。Bun と同じ弱点。
• デバッガ統合 — Chrome DevTools プロトコル互換はあるが、VSCode デバッガ統合の安定性は Node より一歩遅い。
• Fresh の採用 — Fresh 2 が良くなっても Next.js を崩せない。
• JSR の採用 — Deno エコシステム外への拡大が遅い。
• Deno 3 のタイムラインが不透明 — 大きな次のマイルストーンがまだ霞んでいる。

12章 · 誰が production で Deno 2 を使っているか

ケース A — AI エージェントの sandbox

最も明確な win 領域。モデル生成コードを権限制限して実行したい環境:

• e2b, Modal, Replit — AI インフラの一部オプションとして Deno が登場。
• 自社コードインタープリタを作るスタートアップのバックエンド。
• Claude / GPT の tool use のコード実行ツールをセルフホストする場合。

ケース B — Deno Deploy 上のフルスタック

Fresh 2 + Deno KV による小さなフルスタック:

• 社内ダッシュボード、マイクロ SaaS。
• API + 静的ページの結合型サービス。
• グローバル read 分散が必要な小さなデータ。

ケース C — 標準ライブラリ重視のバックエンド・ツール

@std/cli, @std/path, @std/fs, @std/encoding を多用する CLI / dev tool。外部依存を最小化する価値があるところ。

ケース D — Slack/Discord ボット、webhook ハンドラ

Deno.serve + Deno.openKv() による小さな webhook サービス。権限モデルで爆発半径を狭め、グローバル展開は Deno Deploy で。

ケース E — ほぼ無し — 大規模エンタープライズ・モノリス

Bun と同じ理由。APM、デバッガ、人の慣れ、既存コードベースの重み。

名前のついた事例(公開情報ベース)

• Netlify Edge Functions — Deno 基盤のランタイム。
• Supabase Edge Functions — Deno 基盤。
• Slack/Salesforce の一部自動化 — Deno の権限モデルを活用。
• Deno Deploy 自身 — eat your own dogfood。

13章 · マイグレーション — Node プロジェクトを Deno 2 へ

段階的な導入

1. deno fmt・deno lint のみ導入 — 他ツールの変更なし。摩擦が少ない最初の一歩。
2. CI で deno test — Vitest/Jest と並行。Deno test の速度とゼロ設定 TS の魅力を確認。
3. 単一スクリプトを Deno へ — scripts/migrate.ts のようなワンオフから。
4. 新規小サービスを Deno で書く — 新マイクロサービス / 内部ツール。
5. deno install で依存管理 — Node ランタイムを保ちつつ install だけ Deno に。
6. production ランタイムを Deno に — 最大の一歩、最後。

導入チェックリスト

• 我々の APM(Datadog/NR/Sentry)は Deno をサポートしているか? instrumentation の深さは?
• ネイティブアドオン依存(sharp, canvas, bcrypt)は Deno で動くか?
• CI イメージは Deno を受け入れられるか? 公式の denoland/deno イメージを活用。
• production で本当に権限を狭める意志があるか? -A で消すなら差別化はゼロ。
• Fresh 2(Deno 1st-party)を使うか、Hono/Express の Deno モードで行くか?
• ロールバック・シナリオ — Deno→Node に戻すコストは?

よくある anti-pattern

• -A で全権限を許可してそのまま放置。権限モデルの価値をゼロに。
• Fresh を新規プロジェクトの default に強要。Next.js エコシステムの豊富さを諦めるなら相応の理由が要る。
• JSR-only で publish。ユーザーの80%は npm 派。両方に publish するのが安全。
• Deno KV を RDB の位置に置く。小さな read-heavy データには合うが、トランザクションや JOIN が複雑な場所には不向き。
• deno run を node ドロップインと前提する。互換は良くなったが100%ではない。重要パスは実測。
• ベンチマークだけで決める。自分のワークロードで測ろう。

エピローグ — 理想主義から実用主義へ

Deno 1 は Node への明示的反論として生まれた。Deno 2 はその反論の半分を撤回し実用主義を選んだ。結果:

Deno は「Node を置き換える」 narrative を諦め、代わりに「Node の隣に意味ある居場所を作る」 narrative に移った。 その居場所が AI エージェント sandbox、Deno Deploy、標準ライブラリ中心のツールだ。

覚えておくべきこと:

• Deno 2 は Node コードの移行を難しくないものにした。90% はそのまま動く。摩擦はネイティブアドオン、APM、一部デバッガ。
• JSR は npm を殺せなかったが、Deno エコシステムの default になった。TS-native publish は本当に綺麗な勝ち筋。
• Fresh 2 は良くなったが Next.js の位置は奪えない。Deno Deploy バンドルでは魅力的。
• Deno KV は production-ready。小サービスの一行 KV として十分価値がある。
• セキュリティモデルは AI 時代に価値が上がった。モデル生成コードの実行は Deno の自然なホーム。
• Deno 3 はまだ公式発表なし。大きな自己否定二連は難しい、段階的 evolution の可能性が高い。

導入チェックリスト(Deno を入れる前)

• 本当に権限モデルが必要なワークロードか、それとも -A で消すか?
• APM/observability の要求水準は? フル Datadog/NR instrumentation が必須なら Node に留まる方が安全。
• ネイティブアドオン依存を全部点検したか?
• CI イメージと Dockerfile に Deno を追加する準備は?
• 新規小サービスから始めるか、既存コードのマイグレーションから始めるか? 前者がほぼ常に正解。
• Deno Deploy を使うか、自社インフラ(Kubernetes/Fly)に Deno コンテナを置くか?

よくある anti-pattern(再強調)

• 権限モデルを ON にして全許可で差別化をゼロに。
• Fresh を新規プロジェクトの default に強要。
• Deno KV を RDB の位置に置く。
• JSR-only publish でユーザーの80%を諦める。
• npm: import の互換を100%と前提する。
• 自ワークロードを測らずベンチマーク図表を引用する。

次回予告

• 「AI エージェント sandbox ランタイム比較 2026 — Deno, Bun, Firecracker microVM, gVisor」 — モデル生成コードを安全に実行する5つのオプション。
• 「Fresh vs Next.js vs Astro 2026 — islands architecture の三つの答え」 — SSR フルスタックの陣取り。
• 「Deno Deploy vs Cloudflare Workers vs Vercel Edge」 — Edge ランタイム三強の比較。

参考 / References

Deno 公式

• Deno 公式サイト — https://deno.com/ — 最新版、変更内容。
• Deno マニュアル — https://docs.deno.com/ — ランタイム・CLI・標準ライブラリ。
• Deno GitHub — https://github.com/denoland/deno — issue・リリースノート。
• Deno blog (releases) — https://deno.com/blog — メジャー・バージョンごとの変更。

Deno 2 リリース資料

• 「Deno 2.0」発表記事 — Node 互換と package.json 対応の賭け。
• Deno 2 の RFC と設計ノート — nodeModulesDir、workspace 導入の背景。

JSR

• JSR 公式 — https://jsr.io/ — パッケージ検索、スコア、ドキュメント。
• JSR docs — TS-native publishing、scope 管理。
• 「Why JSR」記事 — Deno チームの動機、設計判断。

Fresh

• Fresh 公式 — https://fresh.deno.dev/
• Fresh 2 マイグレーションガイド — Fresh 1 から 2 への移行。
• Preact 公式 — https://preactjs.com/ — Fresh のレンダリングエンジン。

Deno KV

• Deno KV ドキュメント — Deno.openKv() API、キー構造、atomic transaction。
• Deno KV GA ブログ記事 — production-ready 宣言。
• FoundationDB — Deno Deploy KV の背後の技術。

Deno Deploy

• Deno Deploy — https://deno.com/deploy — グローバル isolate ランタイム。
• Deno Deploy 価格と制限 — プラン、キーあたりの制限、エッジ制約。

Node.js (比較)

• Node.js 公式 — https://nodejs.org/
• Node --experimental-strip-types ドキュメント — TS 直接実行。
• node:test ドキュメント — Node 22+ ネイティブテストランナー。

Bun (比較)

• Bun 公式 — https://bun.sh/
• Bun ランタイム互換マトリクス — Node API 互換状況。

セキュリティ / 権限モデル

• Deno permission system ドキュメント — 全 --allow-* フラグ。
• OWASP supply chain security — npm/JS エコシステムの脅威モデル。
• xz-utils 事件 回顧 — サプライチェーン攻撃がセキュリティモデルの賭けに与えた影響。

運用採用事例(公開記事ベース)

• Netlify Edge Functions エンジニアリングブログの Deno 導入記事。
• Supabase Edge Functions のアーキテクチャ — Deno 基盤ランタイムの設計。
• Slack 自動化に Deno を採用した事例。

批判的視点 / 回顧

• 「Why we did NOT pick Deno」スタートアップ記事 — 意図的に選ばなかった会社の理由。
• APM auto-instrumentation の限界に関する運用チームの記事。
• Deno 2 の自己否定に対するコミュニティの反応(フォーラム、Hacker News、Reddit)。

標準化 / WinterCG

• WinterCG — https://wintercg.org/ — JS ランタイム間の互換標準グループ。
• Web-interoperable runtimes 仕様 — Deno・Bun・Workers・Vercel が従う標準。