CloudflareはなぜDenoを買収したのか――Ryan DahlのJSランタイム、オープンソース治理、エッジ実行環境の未来を読み解く

2026年10月10日、CloudflareはJavaScriptランタイム「Deno」の開発企業Deno社の買収を発表しました。Node.jsの生みの親であるRyan Dahlが、自身の「2度目の挑戦」の全てをCloudflareへ託す決断をしたのです。

はじめに — Node.jsの父が17年かけてたどり着いた場所

「DenoやDeno Deployを使っているけど、買収後も使い続けられるのか」「Cloudflare Workersとの統合って、結局何が変わるのか」——10月10日の発表以降、JavaScript開発者の間でこうした声をよく見かけるようになりました。公式ブログに「今後1年でDenoランタイムの開発を終了」「Deno Deployは6ヶ月後に終了」といった記述が並び、実際に影響を受ける開発者は少なくありません。

本記事では、Cloudflare・Deno両社の公式発表とTechCrunchの報道を基に、この買収の全体像を整理します。具体的には、次の3点が分かる構成です。

1. 買収で確定した5つの事実 — ランタイム・Deploy・JSRなど、各資産の行方が読める
2. 技術的な意味 — Node.jsからDeno、そしてWorkersへの系譜と「workerd×celld統合」が目指すもの
3. 開発者が今取るべきアクション — 移行チェックリストとFAQで具体的な対応を示す

物語の主人公はRyan Dahlです。2009年、ベルリンのJSConf EUで500行のJavaScript IRCサーバーを披露してNode.jsを世に出し、2018年の同じ舞台で「Node.jsの設計上の過ち」を語ってDenoの構想を示し、2020年にDeno 1.0をリリース。そして2026年、チーム全員をCloudflareへ移します。17年間、「JavaScriptでサーバーを書くとはどういうことか」を問い続けた人物の、ひとつの到達点です。

まずは、この買収で「何が決まり、何が終わるのか」を公式発表ベースで確認していきましょう。

買収の5つの確定事実 — 何が決まり、何が終わるのか

買収の概要を先に押さえておきましょう。TechCrunchの報道（2026年10月10日）によれば、買収金額は非公開です。Deno社はBert BelderとRyan Dahlの共同創業で、累計調達額は2,600万ドル（Sequoia主導のシリーズAを含む）でした。買収の目的についてCloudflare側の発表者であるKenton Varda（Cloudflare Workers プリンシパルエンジニア）は、Workersのプログラミングモデルとプラットフォームの改善に活用すると説明しています。

開発者にとって重要なのは「各資産がどうなるか」です。Denoの公式ブログ「Deno is joining Cloudflare」（2026年10月10日付）は、今後の方針を5つの確定事項として明確に列挙しています。以下の表は、この公式発表に示された事項を対象資産ごとに整理したものです。期限はいずれも発表日（2026年10月10日）からの起算です。

注目すべきは、単なる「買収・協業」ではなく、DenoランタイムとDeno Deployに明確な終わりが設定された点です。Deno側は「今後の開発労力を、別々のランタイムとホスティングサービスの継続ではなく、統合プラットフォームに注ぐ」と説明しています。

一方で、JSR（JavaScriptレジストリ）は縮小ではなく運用継続・インフラ移管、rusty_v8はworkerdへの統合という「発展的な扱い」と筆者には読めます。つまりこの買収は「Denoの終焉」ではなく「資産の選別と集約」であり、その受け皿がCloudflare Workersというわけです。

では、なぜCloudflareはDenoを必要とし、DenoはCloudflareに活路を見出したのか。その答えは、Denoというランタイムが生まれた経緯にあります。

Node.jsからDenoへ — 「後悔」の修正が目指したサーバーの未来

Denoを理解するには、2018年のJSConf EUでRyan Dahlが行った講演「Design Mistakes in Node（Node.jsの設計上の過ち）」から始める必要があります。彼は自ら生み出したNode.jsについて、設計当時の制約から来る後悔を公の場で列挙し、その「やり直し」となる新しいランタイムの構想を示しました。それがDenoです。

2020年5月のDeno 1.0発表で、DahlはDenoを「コマンドラインスクリプトのためのWebブラウザ」と表現しました。その設計思想は明快です。

• シングルバイナリ: 設定ファイルなしに、1つの実行ファイルで動く
• URLインポート: モジュールをURL指定で直接読み込み、npm installのような事前処理を不要にする
• デフォルトでセキュアなサンドボックス: ファイルやネットワークへのアクセスは--allow-netのような明示的な権限付与が必要
• TypeScriptネイティブ対応: 追加のビルドツールなしで.tsファイルを実行できる
• 標準Web API準拠: ブラウザ標準から逸脱しないAPI設計

さらに技術面では、Node.jsがPromise以前の世代に設計されたために依存しているEventEmitterパターンを批判し、ソケットを含むすべての非同期処理をPromiseベースに統一しました。back-pressure（背圧）が正しく働かず悪いテールレイテンシを生む、というNode.jsの構造的問題への対処です。

パッケージ管理にも問題意識があります。Deno 1.0の発表では、npmリポジトリへの中央集権化が「Webの理想と一致しない」と指摘されました。この思想は2024年、TypeScriptファーストのレジストリ「JSR」へと結実します。JSRはnpmの置き換えではなくスーパーセットとして設計され、Node.js・Deno・Bun・Cloudflare Workersなど任意のランタイムで利用できます。

そしてDahlの視線は、ランタイムからさらに先へ向かっていました。彼は「JavaScript Containers」という記事で、計算・ストレージ・通信が一体となった世界を構想し、その実装の第一歩がDeno Deploy、次が2026年8月リリースの「celld」です。celldはCloudflare Workersのプログラミングモデルをベースにした分散アプリケーション基盤で、スケーリングをインフラではなくプログラミングモデル側に組み込むことを特徴とします。

Deno → Deno Deploy → celld。この進化の系譜を見ると、Dahlが一貫して追求してきたのが「ランタイムそのもの」ではなく「サーバー開発の在り方全体」だったことが分かります。その終着点としてCloudflareが浮上した理由を、次はCloudflare側の技術から見ていきましょう。

Workersの技術的核心 — なぜDenoチームはCloudflareに合流したのか

Cloudflare Workersが2018年に登場したとき、その最大の特色は「コンテナを使わない」ことでした。Cloudflareの技術ブログ「Cloud Computing without Containers」（2018年）の説明によれば、従来のサーバーレス（Lambdaなど）がコールドスタートに500ミリ秒〜10秒かかるのに対し、WorkersはGoogle ChromeのJavaScriptエンジン由来の「V8 Isolate」を1プロセス内に大量に起動する方式を採用。同ブログの記述として、Isolateの起動は約5ミリ秒で、Nodeプロセス起動の約100倍速く、メモリ消費も1桁少ないと説明されています。

このWorkersランタイムは、2021年9月に「workerd」としてApache License 2.0でオープンソース化されました。興味深いのはその契機です。Cloudflareの共同投稿によれば、2022年にShopifyへ「Workers for Platforms」を商談した際、「ランタイムがオープンソースでない限り採用できない」というフィードバックを受け、workerdのOSS化を決断したといいます。

しかしworkerdには大きな制約がありました。Workersの最重要機能であるDurable Objects（DO）のサポートが、単一インスタンスに限定されていたのです。DOは「分散シングルトン」+SQLiteデータベースという構成で、シングルスレッド動作・WebSocket対応・同期SQLiteアクセスを提供します。チャットアプリなら「1チャネル=1DO」と置くだけで、シャーディングされたデータとWebSocket接続が手に入る。その上にQueues、KV、Durable Execution、さらにGitストレージまで構築できる基盤です。

ここに現れたのがDenoのcelldでした。Rust製の単一バイナリで、外部サービス依存はオブジェクトストレージのみ。Workersのプログラミングモデルを自前インフラで動かすことを可能にするこの実装は、Cloudflareチームを「大いに喜ばせた」（delighted）とVardaは書いています。そして買収により、workerdとcelldはマージされ、Ryan DahlとBert Belderの下でセルフホスティングが第一級のサポート方式になります。

graph TD;
  A[2009 Node.js発表 JSConf EU] --> B[2018 設計上の過ちを総括]
  B --> C[2020 Deno 1.0 リリース]
  C --> D[Deno Deploy マネージド実行]
  D --> E[2026年8月 celld リリース]
  E --> F[2026年10月 Cloudflare買収]
  F --> G[workerd × celld 統合]

この図が示す通り、17年間の系譜は「workerd×celld統合」という一点に向かおうとしています。Ryan Dahlは共同投稿の中で、Node.jsを「ベルリンの倉庫で500行のIRCサーバーと共に紹介した」日から、一貫して「より強い抽象化」を探求してきたと振り返ります。

もうひとつ見逃せないのがAI文脈です。DahlはDurable Objectsを「エージェントハーネスに特に有用な能力の集合」だと述べています。安価なサーバーレス実行、永続的な状態、WebSocket、高水準のJavaScriptインターフェース——AIエージェントの実行基盤に必要な要素が揃っているという指摘で、celldがDOに注力する理由もここにあります。

Denoチームの合流先となったWorkersは、エッジ実行環境という競争市場の中でどこに位置するのか。次は競合との比較で整理します。

エッジ実行環境の比較 — 5プラットフォームの現在位置

エッジ・サーバーレス市場は今、複数のプラットフォームが競合しています。ここでは今回の一次情報（Cloudflare・Deno両公式ブログ、TechCrunch）で確認できる範囲を軸に、主要5プラットフォームの位置づけを整理します。Fastly・Vercel・AWSについては今回の公式情報源では詳細を確認していないため、一般論としての整理である点にご留意ください。

表から読み取れるのは（一般論としての整理を含む点にご留意ください）、Cloudflare Workersが「実行方式の先進性」「ランタイムのOSS化」「ステートフル基盤の充実」の3点で独自の立ち位置を持つと同社が主張できる状態にある、ということです。特にDurable Objectsの存在は大きく、ステートレスな関数実行が主流だったエッジ環境に、ステートフルなプログラミングモデルを持ち込んだ点が特徴と筆者は考えます。

ただし「他と違う動作をするのはベンダーロックインのためだ」という批判は以前からありました。これについてVardaは、Cloudflareの共同投稿で次のように反論しています。「オープンソースであること、そしてescape hatch（脱出路）を与えることは、良いビジネスなのだ」。実際、Shopifyとの商談でOSS化を迫られ応えた歴史は、この言葉に整合しています。ロックインを避ける道を用意することが顧客の信頼を獲得し、結果としてプラットフォームの中心への引力を強める——という戦略です。

Deno Deployの行き先がWorkers移行であることも含め、この買収はエッジ実行環境の市場構図を再編する可能性を持ちます。あくまで筆者の見立てですが、「ランタイムの覇権争い」が「プログラミングモデルの標準化競争」に変わる転換点と見ることもできるでしょう。

市場の話はこの辺りにして、ここからは自分のプロジェクトへの影響を具体的に見ていきます。

開発者向け移行チェックリスト — Deno資産をどう守り、どこへ動かすか

買収発表を開発者視点で消化するには、「自分の資産のうち何が影響を受け、いつまでに何を決めるべきか」の整理が不可欠です。公式発表に基づき、状況別のチェックリストを6ステップで示します。

1. 資産の棚卸し — Deno依存の特定

• やること: プロジェクト内の--allow-*フラグ使用箇所とDeno.*名前空間API（Deno.readTextFile等）の利用箇所を洗い出す
• 確認元: これらはDenoランタイム固有の機能で、移行時の作業量を左右します。標準Web API（fetch、URL等）のみを使っているコードは移植性が高い状態です

2. JSRパッケージは継続利用可

• やること: JSR経由の依存は現状維持でよい
• 確認元: Deno公式ブログは「JSRは運用を継続し、インフラをCloudflareへ移管する」と明記。JSR自体がnpmのスーパーセットとして任意のランタイムで動く設計である点も、将来の選択肢を広げます

3. Deno Deploy利用者 — 6ヶ月の移行期限

• やること: 本番利用がある場合は移行計画の策定を開始する。有償契約者は移行支援の対象
• 確認元: 「Deno Deployは6ヶ月間の運用継続後に終了。有償顧客にはCloudflare Workersへの移行支援を提供」

4. Workers移行時の着目点

• やること: 標準Web API準拠のコードはそのまま移行しやすい。あわせてDurable Objectsによるステートフル設計の再検討を
• 確認元: WorkersとDenoはどちらもWeb標準APIを尊重する設計。DOは「分散シングルトン+SQLite+WebSocket」という構成で、ステート管理を自前実装する必要を減らします

5. セルフホスト派 — workerdとcelld統合をウォッチ

• やること: 自社インフラでWorkers互換環境を動かしたい場合、workerd（Apache 2.0）の動向を追う
• 確認元: 今後celldのコードとアイデアがworkerdに統合され、セルフホスティングが第一級のサポート方式になります。DOの単一インスタンス制限という既存のギャップが解消されるかが焦点です

6. Denoランタイム本番利用 — 1年の期限を計画化

• やること: バグ修正・セキュリティ更新の月次リリースは1年間。この期限を移行の逆算基準にする
• 確認元: 「今後1年間は月次リリースでサポートし、その後Denoランタイムの開発を終了。オープンソースは継続し、他者による継続開発を歓迎」

一括して言えば、「JSRは安心、Deployは急ぎ、ランタイムは1年以内」という優先順位です。次のFAQで、個別の疑問に答えます。

よくある質問（FAQ） — 買収に関する疑問に答える

Deno（ランタイム）はすぐ使えなくなりますか？

いいえ、すぐに使えなくなるわけではありません。Deno公式ブログによれば、ランタイムは今後1年間、月次リリースでバグ修正とセキュリティ更新が続きます。その後に公式開発は終了しますが、コードはオープンソースのまま残り、他の開発者による継続開発は歓迎されている状態です。

Deno Deployで動いているアプリケーションはどうなりますか？

Deno Deployは6ヶ月間の運用継続後に終了します。有償契約中の顧客には、Cloudflare Workersへの移行支援が提供されます。本番環境でDeployを利用している場合は、この6ヶ月を移行期間として逆算した計画づくりが急務です。

JSRで公開したパッケージはどうなりますか？

JSRは運用を継続します。インフラストラクチャがCloudflareへ移管されるものの、レジストリ自体が閉鎖される予定は公式には示されていません。JSRはnpmのスーパーセットとしてNode.jsやCloudflare Workersなど複数ランタイムで動く設計なので、パッケージ資産の価値は維持される見通しです。

Cloudflare Workersがベンダーロックインになったのでは？

心配は自然ですが、方向性はむしろ逆です。WorkersランタイムはworkerdとしてApache 2.0でオープンソース化済みで、さらに今回の買収でcelldの統合によるセルフホスティング強化が決まりました。CloudflareのKenton Vardaは「オープンソースであること、escape hatchを与えることは良いビジネスだ」と述べており、脱出可能性の確保が戦略の中心にあります。

Node.jsへの影響はありますか？

直接的な影響はありません。Node.jsはDenoとは別のプロジェクトとしてOpenJS Foundationの下で継続します。今回の買収はRyan Dahl率いるDeno社とその資産に関するもので、Node.js本体の開発体制には関与しません。なおJSRパッケージはNode.jsからも利用できるため、エコシステムの交流は続きます。

主要な疑問を確認したところで、最後にこの買収の本質と、読者それぞれの次のアクションを整理します。

まとめ — 次に取るべき3つのアクション

Ryan Dahlはこの移籍について、「Workersプログラミングモデルをサーバー構築の主流の方法にするためにCloudflareに参加する」と述べています。この一言に、買収の本質が凝縮されていると筆者は読みます。Deno買収の狙いは「競合ランタイムの排除」ではなく、Denoが培ってきた設計思想とチームを、Workersというプログラミングモデルの標準化に注ぎ込むこと。ランタイムの覇権争いが、プログラミングモデルの標準化競争へと変わる転換点になる可能性があるでしょう。

読者の状況別に、次のアクションを3つ示します。

1. Deno Deploy利用者は6ヶ月の期限を逆算する — 移行支援の対象となるか契約状況を確認し、Workersへの移行計画を今週中にたたき台にする
2. JSR資産は継続利用しつつWorkers/DOを試す — JSRは継続運用が明言済み。Durable Objectsを使った小さなユースケース（WebSocketやステートフルなAPIなど）を検証し、移行時の設計パターンを体得しておく
3. セルフホスト関心層はworkerd×celld統合をウォッチする — Apache 2.0のworkerdにcelldのアイデアが統合されるロードマップは、クラウド依存を減らす選択肢を広げる可能性があります

2009年のベルリンでNode.jsが示した「JavaScriptで書けるサーバー」という理想は、Denoでの「やり直し」を経て、2026年、workerd×celldという統合プラットフォームへと向かおうとしています。17年越しの理想が新たなカタチに移る瞬間を、開発者として見届ける価値はあるでしょう。

参考文献

• Deno is joining Cloudflare（Deno公式ブログ） — https://deno.com/blog/cloudflare
• Deno is joining Cloudflare（Cloudflare公式ブログ） — https://blog.cloudflare.com/deno-joins-cloudflare/
• Cloudflare acquires Deno to improve its Workers programming model（TechCrunch） — https://techcrunch.com/2026/10/10/cloudflare-acquires-deno-to-improve-its-workers-programming-model/
• Deno 1.0（Deno公式ブログ） — https://deno.com/blog/v1
• Cloud Computing without Containers（Cloudflare公式ブログ） — https://blog.cloudflare.com/cloud-computing-without-containers/
• Introducing workerd: the Open Source Workers runtime（Cloudflare公式ブログ） — https://blog.cloudflare.com/workerd-open-source-workers-runtime/
• JSR: the JavaScript Registry — https://jsr.io/
• celld — https://celld.dev/
• Deno raises $21M to launch a fully managed runtime service（TechCrunch） — https://techcrunch.com/2022/06/21/deno-raises-21m-to-launch-a-fully-managed-runtime-service/

関連記事

• WebMCPとCloudflare OSで作るAIエージェント向けWeb
• AWSが「データは戻りません」と言った日——マルチAZ設計が折れた中東リージョン