Deno、Cloudflareへ——JavaScriptランタイム戦争の終わりと始まり

メタディスクリプション: Node.js創始者Ryan Dahl率いるDenoチームがCloudflareに合流。Denoランタイムは2027年10月に開発終了、Deno Deployは半年で停止。Workers/Durable Objects統合の狙いとJSRの行方、Node.js代替の勢力図を解説します。

1. 2026年10月9日、JavaScript界に起きたこと

2026年10月9日、Node.js創始者でありDenoの生みの親でもある Ryan Dahl が、ひとつの時代の幕引きを宣言しました。DenoチームがCloudflareに全員合流し、Denoランタイムの開発は2027年10月をもって終了——そして、ホスティングサービスのDeno Deployは2027年4月にシャットダウンされます。

HackerNewsでのスコアは909点。単なる企業買収ニュースとしては異例の注目度です。その理由は後述しますが、まずは「自分に何が関係するのか」を3秒で確認しましょう。

3行でわかる要点

DenoチームがCloudflareに全員合流（2026年10月9日、Ryan Dahlが公式発表）
Denoランタイムは2027年10月に開発終了、Deno Deployは2027年4月に停止
JSRはCloudflareインフラ上で継続——TypeScriptエコシステムは守られた

影響を受けるのは誰か

あなたの状況	必要なアクション	猶予
Deno Deployを本番運用中	Cloudflare Workersへ移行	約6ヶ月
Deno CLIでローカル開発中	代替検討を開始（即時対応は不要）	約12ヶ月
JSRでパッケージ公開中	対応不要	—

HNスコア909が意味するもの

HackerNewsのスコア909は、単純なアクセス数の多さだけを意味しません。これは開発者コミュニティの「感情の揺れ」を数値化したものです。

Ryan DahlはNode.jsを作り、その10年後に「Node.jsへの10の後悔」というセッションでNode.jsの設計上の欠陥を公開の場で批判し、Denoを生み出しました。TypeScript-first、セキュリティ・バイ・デフォルト、ESモジュール——これらはすべて「Node.jsならこうすべきだった」という哲学の具現化でした。

その彼が、ランタイム開発に自ら幕を引く。技術的な事実の重さだけでなく、この歴史的な皮肉が開発者の感情を揺さぶったのです。

2. 【事実整理】公式発表で決まったこと・決まっていないこと

買収の詳細が発表されてから数日が経過した現在、公式ブログと報道から確認できる事実を整理します。「決まったこと」と「まだ不明なこと」を混同しないことが重要です。

プロダクト別ロードマップ一覧

プロダクト	現在の状態	今後の扱い
Denoランタイム	アクティブ開発 → バグ修正・セキュリティ更新のみ	2027年10月に開発終了（OSSライセンスは継続）
Deno Deploy	運用中	2027年4月にシャットダウン
JSR	運用中	Cloudflareインフラ上で継続
Fresh	OSS	公式見解なし（要注視）
deno compile	機能として存在	終了まで使用可能、以降は未定
Deno KV	ベータ的位置付け	後述

Denoランタイム：2027年10月までは「バグ修正とセキュリティ更新のみ」

重要な区別があります。Denoランタイムのコードはオープンソースとして残ります。しかしDenoチームによる積極的な機能開発は即座に停止し、今後1年間はバグ修正とセキュリティパッチのみが提供されます。

「OSSとして残る」という事実は、コミュニティによるフォーク継続の可能性を示しています。しかし主要な開発者が全員Cloudflareに移籍した状態では、活発なメンテナンスが続くかどうかは楽観視できません。

機能追加の凍結は、実質的な開発終了を意味します。新しいWeb標準への対応、パフォーマンス改善、新機能——これらが今後追加されることはないと考えるのが現実的です。

Deno Deploy：2027年4月シャットダウン、有料ユーザーには移行支援

発表から約6ヶ月というスケジュールは、本番運用中の開発者にとってタイトです。Cloudflareは有料ユーザー向けに移行支援を提供すると発表しており、具体的なサポート内容は順次公開される予定です。

無料プランのユーザーも含め、2027年4月以降はDeno Deployのエンドポイントへのアクセスが完全に停止します。段階的に移行を進める必要があります。

JSR：継続決定——40,000超のパッケージは守られる

TypeScriptコミュニティにとって最も重要な朗報は、JSRの継続です。2026年初時点で40,000以上のパッケージが登録されているJSRは、Cloudflareのインフラ上で運営が引き継がれます。

Cloudflare自身もJSRの価値を認識しており、単なる「維持」ではなく積極的な発展が期待されます。

まだ明らかになっていない論点

以下は本稿執筆時点（2026年10月12日）で公式見解が示されていない項目です。臆測と事実を混同しないために明示しておきます。

Fresh（Webフレームワーク）: OSSとして存続するとみられますが、積極的メンテナンスの継続は不透明
deno compile: バイナリコンパイル機能の長期的な運命は未定
Deno KV: Cloudflareの同等サービス（KV / D1）への公式移行パスが示されていない
既存のGitHub Issues: バグ報告・機能要望の扱いが明確化されていない

3. なぜCloudflareだったのか——「celld × workerd」統合という本命

買収の表面的な説明は「JavaScriptランタイムの専門家チームを獲得した」です。しかし技術的な文脈を深掘りすると、本当の狙いが見えてきます。

キーワードは"自己ホスト型Workers"

Cloudflare Workersは、世界300箇所以上のエッジロケーションで動作する分散実行環境です。しかし現在のWorkersは、Cloudflareのグローバルインフラ上でしか動きません。

企業、特に金融・医療・公共機関などの規制産業にとって、「自社のオンプレミスまたはプライベートクラウドでWorkersを動かしたい」というニーズは根強くあります。データ主権の観点から、すべてのコンピューティングを特定の地理的・組織的境界内に収める必要があるからです。

この「自己ホスト型Workers」の実現こそが、買収の本当の目的です。

celld とは何だったのか：DenoをベースにしたWorkersランタイム

DenoチームはCloudflareへの合流前から、密かに celld という内部プロジェクトを進めていました。これはDenoをベースとして、Cloudflare Workers互換のランタイムを自己ホスト可能な形で実装したものです。

Denoがすでに持っていた強みが、ここで活きています。

V8エンジンの深い統合
Web標準APIへの完全準拠
セキュリティ・サンドボックスの堅牢な実装
TypeScriptのネイティブサポート

celldは「WorkersをDenoのアーキテクチャで再実装する」プロジェクトとして機能していました。

workerd（V8 Isolate）との統合で実現すること

CloudflareのWorkers基盤となるランタイムは workerd と呼ばれ、V8 Isolateを核とした高性能な実行エンジンです。Ryan DahlとBert Belderが主導して、celldとworkerdをマージする作業が始まります。

この統合が完了したとき、何が実現するのでしょうか。

オンプレミスでWorkersを動かす: Cloudflareのグローバルインフラに依存せず、自社データセンターでWorkers互換のコードを実行できる
プライベートクラウドへの展開: AWS VPCやAzure VNetのような閉じたネットワーク内でWorkers互換環境を構築できる
エンタープライズ向けのデータ主権対応: EU-AI Act、HIPAA、FISC安全対策基準など、データの物理的所在を規定する規制に準拠できる

これはWorkersの利用範囲を劇的に広げます。現在のWorkers採用を阻んでいた「クラウド依存」「データ管理権」という障壁が、一気に取り除かれるのです。

Cloudflare側のメリット：ランタイム人材の一括獲得

Node.jsの発明者であるRyan Dahl、そしてlibuv（Node.jsの非同期I/Oライブラリ）の作者であるBert Belderを含むDenoチームは、JavaScriptランタイムの設計・実装において世界トップクラスの知識を持つ集団です。

V8エンジンとの低レベルな統合、Web標準APIの完全実装、高性能なサンドボックス設計——これらは一朝一夕に習得できるスキルではありません。Cloudflareはこのチームを丸ごと獲得することで、workerdの次世代開発を加速できます。

Deno側のメリット：ランタイム単体ではマネタイズできなかった現実

「なぜDenoはCloudflareへの参加を選んだのか」——この問いへの答えは、OSSランタイムビジネスの構造的な難しさにあります。

Deno Deployはホスティングサービスとして収益化を目指していましたが、Vercel、Cloudflare Workers、AWS Lambda@Edgeといった既存の巨人と真正面からぶつかる形になっていました。技術的な優位性があっても、マーケティング力・エコシステム・既存ユーザーベースの差は容易には埋まりません。

ランタイム本体（Deno CLI）はOSSゆえに直接的な収益を生まず、Deno Deployの利益でチーム全体を維持するモデルには限界がありました。Cloudflareという強力なインフラ・財務基盤のもとで、技術的なビジョンを追求できる環境に移ることは、チームにとっても合理的な選択だったのです。

4. Durable Objects × AIエージェント——Dahlが本当に惹かれた技術

Ryan Dahlが合流の動機として強調したのが、Durable Objects というCloudflareの技術です。これを理解することが、買収の「思想的な理由」を理解することでもあります。

Durable Objects を60秒で理解する

従来のサーバーレス関数（FaaS）は「ステートレス」が前提です。リクエストが来るたびに関数が起動し、処理が終われば状態を捨てて終了します。永続的なデータが必要なら、外部のデータベースに保存する必要がありました。

Durable Objectsは、この常識を変えます。

**「アドレス可能なマイクロサーバー」**と考えると理解しやすいでしょう。各Durable Objectは一意のIDを持ち、そのIDに対してリクエストを送ることで、常に同じオブジェクトのインスタンスにアクセスできます。そしてこのオブジェクトは、自分自身の中に状態を持ちます。

AIエージェント基盤としての3つの強み

2026年現在、AIエージェント開発の主要な技術課題のひとつは「永続状態の管理」です。Durable Objectsはこの課題を次の3つの特性で解決します。

1. 最大10GBの組み込みSQLiteによる永続状態

各Durable Objectは自身のSQLiteデータベースを内蔵しています。エージェントの会話履歴、ツール呼び出しの記録、中間状態——これらを外部DBへのネットワーク越しの書き込みなしに保存できます。レイテンシが劇的に低下し、設計もシンプルになります。

2. WebSocket・スケジューラを一体で保持

Durable ObjectはWebSocket接続を維持し続けることができます。つまり、ユーザーとの長時間のリアルタイムセッションを、単一のオブジェクトが一貫して管理できます。また組み込みのスケジューラにより、「5分後に次のステップを実行」というような非同期タスクも外部キューなしに実現できます。

3. 休眠中はコンピュート課金ゼロ

Durable Objectは利用されていないときは自動的に休眠状態に入り、リクエストが来たときだけ起動します。常時稼働のサーバーと異なり、アイドル時間の課金が発生しません。これは多数のエージェントを並列に管理するシナリオで大きなコスト優位性をもたらします。

「永続状態 + リアルタイム通信」という2026年のアーキテクチャ課題

従来のAIエージェント実装では、「ステートレスなWorkers/Lambda」＋「外部のRedis/PostgreSQL」＋「外部のPub/Subシステム」という複雑な組み合わせが一般的でした。

// 従来のステートレスアーキテクチャ（簡略化）
module.exports = {
  async fetch(request, env) {
    // 外部DBから状態を取得（ネットワーク越し）
    const state = await env.DB.prepare(
      "SELECT * FROM agent_state WHERE id = ?"
    ).bind(agentId).first();

    // 処理
    const result = await callLLM(state.history, userMessage);

    // 外部DBに状態を保存（ネットワーク越し）
    await env.DB.prepare(
      "UPDATE agent_state SET history = ? WHERE id = ?"
    ).bind(JSON.stringify(result.history), agentId).run();

    return new Response(JSON.stringify(result));
  }
};

Durable Objectsを使うと、これが劇的にシンプルになります。

// Durable Objectsを使ったAIエージェント実装
class AIAgent extends DurableObject {
  constructor(state, env) {
    super(state, env);
    this.history = [];
  }

  async fetch(request) {
    const { message } = await request.json();

    // メモリ内の状態にアクセス（ネットワーク越しの読み込み不要）
    this.history.push({ role: "user", content: message });

    const response = await callLLM(this.history);

    // 状態の更新も同様にメモリ内（自動的に永続化）
    this.history.push({ role: "assistant", content: response.content });

    return new Response(JSON.stringify({ response: response.content }));
  }

  // WebSocket接続の維持
  async webSocketMessage(ws, message) {
    const parsed = JSON.parse(message);
    // リアルタイムで状態を更新しながらストリーミングレスポンス
    const stream = await streamLLM(this.history, parsed.content);
    for await (const chunk of stream) {
      ws.send(JSON.stringify({ chunk }));
    }
  }
}

module.exports = { AIAgent };

Cloudflare "Project Think" との接続点

Cloudflareの公式ブログでは、"Project Think" というAIエージェント基盤への取り組みが言及されています。このプロジェクトの核心にあるのが、Durable Objectsを使った「永続的なエージェント実行環境」の構築です。

DenoチームのWorkersランタイム技術と、CloudflareのDurable Objects・AIインフラが統合されることで、Project ThinkはJavaScriptエコシステム全体に向けた新しいAIエージェント基盤として進化していきます。Ryan Dahlが「Durable Objectsは最も興奮する技術だ」と発言した背景には、このビジョンがあります。

5. JSRの行方——TypeScriptエコシステムにとっての朗報

今回の発表で最も安心できるニュースは、JSRの継続です。TypeScriptコミュニティにとってJSRは単なるパッケージレジストリ以上の意味を持ちます。

JSRが継続する理由と、Cloudflareインフラ移管後の体制

Cloudflareにとって、JSRを継続する動機は明確です。40,000以上のパッケージを抱える活発なエコシステムは、開発者をCloudflare Workersへ引き付ける強力な磁石になります。JSRで公開されたTypeScriptパッケージがCloudflare Workersで簡単に使えるという体験は、Workersプラットフォームの競争力を高めます。

JSRがnpmと違う4つの設計思想

JSRはnpmの「後継」ではなく、「補完的な進化」として設計されています。4つの特徴的な設計思想を理解しておくことが重要です。

1. TypeScript-first

JSRでは型定義が一級市民です。パッケージの型情報はJSRのインデックスに直接統合され、別途@types/パッケージを管理する必要がありません。TypeScriptソースコードをそのまま公開でき、JSRが自動的にJavaScriptへのトランスパイルと型定義の生成を行います。

2. ESM-only

JSRはECMAScript Modulesのみをサポートします。CommonJSのrequire()は使えません。これは「過去との互換性を保ちながら前進する」npmと対照的な「クリーンな設計」の選択です。

3. Sigstoreによる来歴（Provenance）保証

各パッケージはSigstoreを使って暗号署名されます。「このパッケージは本当にそのGitHubリポジトリのCI/CDから公開されたのか」を検証できるため、サプライチェーン攻撃への耐性が高まります。

4. npmのスーパーセットとして共存

JSRのパッケージはnpm互換のインターフェースを持ち、npm installでもインストールできます。既存のnpmエコシステムを壊すことなく、段階的に移行できます。

マルチランタイム対応という価値

JSRの設計において最も重要な点のひとつが、ランタイム中立性です。JSRで公開されたパッケージは、次のすべての環境で動作します。

Node.js
Deno
Bun
Cloudflare Workers
ブラウザ（ESMをサポートする環境）

Denoというランタイムへの依存がなくなった今、この特性の価値はさらに高まります。「JSRに公開すれば、どのランタイムのユーザーにもリーチできる」という事実は変わりません。

2026年、新規TypeScriptパッケージはJSRに公開すべきか

判断フローを示します。

新規TypeScriptパッケージを作る
        │
        ▼
  主なターゲットは？
   ┌────┴────┐
Node.jsのみ    マルチランタイム
   │              │
   ▼              ▼
npmで十分     JSRを推奨
（JSR併用も可）  （npm互換で両対応可）

実際のところ、ライブラリの利用者のほとんどがNode.js環境である場合は、npmへの公開が依然として主流です。しかしCloudflare Workers、Deno（2027年10月まで）、Bunのユーザーにもリーチしたい場合や、TypeScriptの型情報を適切に管理したい場合は、JSRが優れた選択肢です。npmと併用することも可能なので、「JSRにも公開する」という追加作業のコストは低く抑えられます。

6. Node.js代替の勢力図はこう変わる

Denoという「Node.jsの対抗軸」が実質的に消えることで、JavaScriptランタイムの競争図は大きく変化します。

Denoという「対抗軸」が消えた後の三極構造

2026年10月以降、JavaScriptランタイムの主要プレイヤーは事実上3つに収束します。

	Node.js	Bun	Cloudflare Workers
起動速度	普通	非常に速い	エッジで超高速
Node.js互換性	✅ ネイティブ	✅ 高い	⚠️ 限定的
TypeScript	トランスパイル必要	✅ ネイティブ	⚠️ ビルドステップ必要
実行モデル	サーバープロセス	サーバープロセス	エッジ/サーバーレス
エコシステム	✅ 最大	✅ npm互換	✅ Workers専用 + npm
運用形態	セルフホスト/クラウド	セルフホスト/クラウド	Cloudflare専用（→自己ホスト型は開発中）

繰り上がる本命：なぜBunが最有力のNode.js代替になるのか

Denoの撤退によって、Bunが「Node.jsに不満を持つ開発者」の受け皿として一層明確な立ち位置を得ます。

BunのNode.js代替としての強みは、「互換性を犠牲にしない速度向上」にあります。既存のNode.jsアプリを大幅な変更なしに動かしながら、起動速度・パッケージインストール速度・ランタイム性能のすべてで上回る実績を積み上げてきました。

Denoが「Node.jsの再設計」を目指したのに対し、Bunは「Node.jsの高速版」として設計されています。このアプローチの違いが、エコシステム移行のコストを下げ、採用の敷居を低くしています。

Node.js本体への逆流効果

Denoが終わっても、Denoがもたらした影響はNode.js本体に刻まれています。

パーミッションモデル: Node.js 22以降に実験的実装として取り込まれた--permissionフラグは、Denoのセキュリティモデルに着想を得ています
型ストリッピング: TypeScriptの型注釈を実行時に除去する機能が実験的に実装され、TypeScriptを直接実行する道が開かれつつあります
組み込みテストランナー: node:testモジュールの標準化は、Denoの組み込みテスト機能への応答です
Web標準APIの採用: fetch()、ReadableStream、Crypto APIなど、Denoが先行実装したWeb標準をNode.jsが後から採用するパターンが続きました

「Denoはランタイムとして生き残れなかったが、Node.jsを良くした」という評価は、皮肉ではなく正当な歴史的評価だと思います。

"Cloudflareによるエッジ実行環境の寡占"への懸念

HackerNewsのコメント欄では、技術的な評価と並んで、Cloudflareによるエッジ実行環境の寡占化への懸念が多く見られました。

Cloudflare Workersは世界最大規模のエッジコンピューティングプラットフォームです。そこにDenoチームが加わり、JSRも傘下に入ることで、「JavaScriptのエッジ実行環境における標準を、一社が実質的に決定してしまう」リスクは現実的です。

Fastly（Compute@Edge）、Vercel（Edge Functions）、Netlify（Edge Functions）なども独自のWorkers互換ランタイムを持っていますが、技術的なリソースと市場シェアでCloudflareには遠く及びません。

この懸念は一方的な批判ではありません。Cloudflareはこれまでも積極的にWeb標準化活動に参加し、オープンソース化を進めてきた実績があります。workerdはオープンソースですし、workerd + celldの統合成果も同様にオープンに公開されると予想されます。しかし「コードがオープンでも、実質的な標準決定権は一社が持つ」という構造的な問題は、引き続き注視が必要です。

Ryan Dahl と「Node.jsへの10の後悔」から18年

2009年、Node.jsが誕生しました。2018年、Ryan DahlはJSConf EUで「Node.jsについて後悔していること10のこと」を発表し、Denoを発表しました。そして2026年、彼はDenoの開発に自ら幕を引きます。

「私はNode.jsを作った。その失敗から学んでDenoを作った。そしてDenoより大きな舞台でその知識を活かす」——これがDahlのキャリアの軌跡です。

ランタイムを「終わらせた」のではなく、ランタイムの哲学が「次のプラットフォームに昇華した」と解釈することもできます。Web標準への準拠、セキュリティ・バイ・デフォルト、TypeScript-firstという思想は、Cloudflare Workers + JSRという形で生き続けます。

7. 【実践】いま取るべきアクション

ニュースを把握したら、次は行動です。状況別に具体的なアクションを示します。

Deno Deployユーザーの移行チェックリスト

移行期限は2027年4月です。6ヶ月は短いようで、段階的に動けば十分な時間です。慌てた全面書き換えは避け、以下のステップで進めましょう。

ステップ1: 現在の依存関係を棚卸しする（今週中）

# Deno Deployに依存している機能を確認
# - Deno KV を使っているか
# - Deno Cron を使っているか
# - WebSocket永続接続を使っているか
# - Deno固有のAPIを使っているか

ステップ2: Cloudflare Workers機能へのマッピングを確認する（1〜2週間）

Deno Deploy	Cloudflare側の受け皿
Deno Deploy（HTTPハンドラ）	Workers
Deno KV	Workers KV（シンプルな Key-Value）/ D1（SQLite互換）
永続状態・WebSocket	Durable Objects
Deno Cron	Workers Cron Triggers
静的ファイル配信	Workers Static Assets / R2
環境変数	Workers Secrets / Workers Variables

ステップ3: ローカルでWorkers開発環境を構築する（1〜2週間）

# wrangler CLIのインストール
npm install -g wrangler

# Cloudflareアカウントにログイン
wrangler login

# 新しいWorkerプロジェクトを作成
wrangler init my-migrated-app
cd my-migrated-app

# ローカルでの開発・テスト
wrangler dev

ステップ4: 本番ワークロードを段階的に移行する（1〜3ヶ月）

全機能を一度に移行しようとせず、トラフィックの少ない機能から始めましょう。Deno DeployとCloudflare Workersを並行運用しながら、徐々に移行を進めます。

ステップ5: 期限管理（2027年4月を逆算）

2026年11月末: 開発・ステージング環境の移行完了
2027年1月末: 本番環境の主要機能移行完了
2027年3月末: 完全移行・旧環境の停止確認

Deno CLIでローカル開発している人の選択肢

本番環境をDeno Deployに依存していない場合は、2027年10月まで猶予があります。急いで移行する必要はありません。状況に応じて以下から選択してください。

選択肢1: 2027年10月まで使い続ける

短期プロジェクト、学習目的、個人開発であれば、これが最も合理的です。セキュリティアップデートは引き続き提供されます。

選択肢2: Node.js（+ 型ストリッピング）へ寄せる

チームがNode.jsに慣れており、既存のnpmエコシステムへの依存が大きい場合に適しています。Node.js 22以降の--experimental-strip-typesフラグを使うことで、TypeScriptをほぼネイティブに実行できます。

# Node.js 22以降での型ストリッピング実行（実験的）
node --experimental-strip-types my-typescript-file.ts

選択肢3: Bunへ移行する

TypeScript-first、高速起動、Node.js互換というDenoに近い体験を求めるなら、Bunが最も自然な移行先です。

# Bunのインストール（macOS/Linux）
curl -fsSL https://bun.sh/install | bash

# TypeScriptを直接実行
bun run my-typescript-file.ts

# パッケージ管理（npmと互換）
bun install
bun add some-package

選択肢4: Workers / wrangler ネイティブ開発に移る

エッジコンピューティングやAIエージェント開発に注力する場合、最初からWorkersとwranglerをベースとした開発環境に移行することも検討に値します。

移行判断フローチャート

本番環境でDeno Deployを使っているか？
      │
   ┌──┴──┐
  Yes    No
   │      │
   ▼      ▼
期限：2027年4月  Deno CLIのみ？
Workers移行必須   │
               ┌──┴──┐
              Yes    No
               │      │
               ▼      ▼
          2027年10月まで  個別に対応
          時間あり      （Deno KVなど確認）
               │
               ▼
          プロジェクト規模は？
           ┌───┴───┐
          小規模    大規模
           │         │
           ▼         ▼
      そのまま継続  今から移行先を検討
      or Bun移行   （Bun or Node.js推奨）

今やらなくていいこと

パニックして全てのDenoコードを今すぐ書き換える必要はありません。以下は不要です。

今すぐの全面書き換え: 期限を確認し、優先度の高いものから順番に対応してください
Deno KVからの即時移行: 2027年4月まで動作します。移行先を慎重に検討する時間があります
使用しているすべてのnpm/JSRパッケージの再確認: JSRは継続するため、パッケージ側での対応は不要です
Denoを使っていることを隠す: 既存のDenoコードは1年間は正常に動作します

猶予期間を正しく使い、計画的に移行を進めることが最善策です。

8. まとめ：ランタイムの時代から、プラットフォームの時代へ

本記事の要点5つ

DenoチームはCloudflareに合流した: 2026年10月9日、Ryan Dahlが公式発表。Denoランタイムは2027年10月に開発終了、Deno Deployは2027年4月にシャットダウン
統合の本命は自己ホスト型Workers: celld（DenoベースのWorkersランタイム）とworkerd（CloudflareのV8ランタイム）のマージが目的。エンタープライズ・規制産業向けのオンプレWorkers実現が戦略核心
JSRは守られた: 40,000超のパッケージはCloudflareインフラ上で継続運営。TypeScriptエコシステムへの影響は限定的
BunがNode.js代替の最有力に: DenoというNode.js対抗軸が消えた後、Bunが唯一の明確な代替ポジションを占める
「標準Web APIへの投資」が正解だった: ランタイム固有APIへの依存を最小化し、Web標準APIだけで書かれたコードは、今後もどの環境でも動く

2027年までのカウントダウン・カレンダー

日付	イベント
2026年10月9日	DenoチームのCloudflare参加を正式発表
2026年10月〜	Denoランタイム：バグ修正・セキュリティ更新のみに移行
2027年4月	Deno Deployシャットダウン
2027年10月	Denoランタイム開発終了（OSSとして存続）

開発者が学ぶべき教訓

今回の出来事が示す最も重要な教訓は、**「特定のランタイムに賭けるより、標準Web APIに賭ける」**という移植性の価値です。

fetch()、Request/Response、ReadableStream、crypto.subtle——これらはNode.js、Deno、Bun、Cloudflare Workers、そしてブラウザのすべてで動く標準です。Denoがなくなっても、これらのAPIは全てのプラットフォームで動き続けます。

ランタイム固有のAPI（Deno KV、Deno.openKv等）に深く依存したコードは移行コストがかかります。一方、標準APIで書かれたコードは「乗り換え可能」という資産を持ち続けます。

「どのランタイムが生き残るか」という予測に賭けるより、「どのAPIがどのランタイムでも動くか」を意識した設計こそが、長期的な価値を持ちます。

JavaScriptの世界は、個別のランタイムが競い合う時代から、プラットフォームが統合されていく時代に入りました。その変化に柔軟に対応するための武器は、標準への準拠と移植性の高い設計です。

9. よくある質問（FAQ）

Denoは完全になくなるのですか？

完全になくなるわけではありません。Denoランタイムはオープンソースソフトウェアとして存続します。ただしDenoチームによる積極的な機能開発は停止し、2027年10月以降はコミュニティに委ねられます。コミュニティがフォークを継続する可能性はありますが、現時点では具体的な動きは確認されていません。

Deno Deployはいつまで使えますか？移行は有料ですか？

Deno Deployは2027年4月にシャットダウンされます。有料プランのユーザーに対しては、Cloudflare Workersへの移行支援が提供される予定です。移行支援の具体的な内容や費用については、Cloudflareからの追加発表を待ちましょう。無料ユーザーについても期限まではサービスが継続されます。

Deno製アプリはそのままCloudflare Workersで動きますか？

Web標準APIのみを使ったアプリであれば、最小限の修正でCloudflare Workersへ移行できます。一方、Deno固有のAPI（Deno.openKv()、Deno.cron()、Node.js互換レイヤーの一部等）に依存している場合は、対応するCloudflareサービスへの置き換え作業が発生します。

JSRは使い続けて大丈夫ですか？

問題ありません。JSRはCloudflareインフラ上で継続運営されることが確定しており、既存のパッケージも引き続き利用可能です。新規パッケージのJSRへの公開も引き続き推奨されます。

Deno KV / Deno Cron はどうなりますか？

Deno DeployのシャットダウンがDeno KV / Deno Cronの実質的な終了を意味します（ローカルのDeno KVはランタイム開発終了まで動作）。移行先としては、Cloudflare Workers KVまたはD1（Deno KV）、Workers Cron Triggers（Deno Cron）が対応します。公式の移行ガイドが提供される予定です。

いまからBunに移行すべきですか？

現在Node.jsで開発しており、不満がないのであれば急ぐ必要はありません。BunはNode.js互換性が高く移行コストは低いですが、まだエッジケースで非互換が存在します。Denoからの移行としては、BunはDenoに最も近い開発体験を提供するため有力な選択肢です。

Node.jsに戻るのは後退ですか？

後退ではありません。Node.js本体は着実に進化しており、2026年現在の最新Node.jsはTypeScriptストリッピング、組み込みテストランナー、Web標準APIの多くをサポートしています。Denoの哲学はNode.jsに逆流しており、「Node.jsに戻る」というより「進化したNode.jsへ移行する」という捉え方が正確です。

DenoはOSSとしてフォーク継続される可能性はありますか？

技術的には可能です。DenoのライセンスはMITであり、誰でもフォークを作成・継続できます。しかしコアチーム全員がCloudflareへ移籍した状態での継続的なメンテナンスは容易ではありません。もしコミュニティ主導のフォークが立ち上がれば注目に値しますが、現時点では具体的な動きは確認されていません。