CloudflareがDenoを買収 — Deno Deployは6か月で終了、ランタイムは1年で開発終了。移行先の選び方を解説
はじめに
2026年10月9日、Deno の作者 Ryan Dahl が「Deno is joining Cloudflare」と題した記事を公開しました。Deno の会社のチーム全員が Cloudflare に移ります。Hacker News では800ポイントを超え、大きな議論になっています。
注目すべきは、買収されたあとも Deno が続くわけではない点です。Deno Deploy は6か月後に終了し、Deno ランタイムも1年間の保守のあとで開発を終えます。
この記事では、発表の内容を整理したうえで、Cloudflare が何を狙っているのかを説明します。最後に、Deno や Deno Deploy を使っている人がいつまでに何を決めればよいかを考えます。
発表の内容 — 何が終わり、何が残るのか
発表は Deno のブログと Cloudflare のブログの両方に出ています。Cloudflare 側は Workers を率いる Kenton Varda と Ryan Dahl の連名です。製品ごとの扱いをまとめると次のようになります。
| 対象 | 今後の扱い |
|---|---|
| Deno ランタイム | 発表から1年間、バグ修正とセキュリティ修正を含むリリースを毎月出す。その後、Deno チームとしての開発は終了。オープンソースのまま残る |
| Deno Deploy | 6か月間は運用を続けたあと終了。有料ユーザーには Cloudflare Workers への移行支援がある |
| JSR | 運営を続ける。インフラは Cloudflare に移る |
| rusty_v8 | 保守を続け、workerd への組み込みを進める |
Deno 側の発表では、開発終了後のランタイムについて「コミュニティが引き継いで開発を続けるなら歓迎する」としています。ただし、誰が引き継ぐかは発表の中では決まっていません。
一方で、Deno KV、Fresh、6月に発表された Deno Desktop の扱いは、どちらの発表にも書かれていません。これらを使っている場合は、今後の公式アナウンスを確認する必要があります。
技術的な背景 — Cloudflare が欲しかったのは celld
この買収を読み解く鍵は、celld というソフトウェアです。Cloudflare のブログによると、celld は Ryan Dahl が始め、Deno チームが2026年8月に公開した Workers と Durable Objects の実装で、自分のサーバーで動かすことを前提にしています。Rust で書かれた1つのバイナリで、外部に必要なのはオブジェクトストレージだけです。
比較対象になるのが、Cloudflare が2022年にオープンソース化した workerd です。workerd は Cloudflare の本番環境で動いている Workers ランタイムと同じコードですが、Durable Objects は1台のマシンでしか動かせませんでした。つまり、Workers のコードを自前のサーバーで動かすことはできても、複数台に分散させる部分はほぼ Cloudflare のネットワークに頼るしかありませんでした。
Durable Objects は、Cloudflare の言葉では「SQLite データベースを持つ分散シングルトン」です。オブジェクトごとに状態を持ち、リクエストや WebSocket 接続を受けます。チャットルームやドキュメントの共同編集のように、1つの単位に処理を集めたい用途に向いています。Deno 側は、AI エージェントの実行基盤にも向いている点を合流の理由に挙げています。
今後は Ryan Dahl と Bert Belder が、celld のコードと考え方を workerd に取り込む作業を率います。目標は、workerd を自前のインフラで動かすことを正式にサポートされた使い方にすることです。Kenton Varda は Cloudflare のブログで、Deno チームには自前で動かすランタイムの使いやすさを作るノウハウがあり、workerd ではそこが十分にできていなかったと書いています。
同じ記事で Kenton Varda は、Workers に逃げ道がなければ大口の顧客の一部はそもそも契約しなかっただろう、とも書いています。自前で動かせる workerd は、顧客が安心して Workers を選ぶための材料になっていると読めます。
Deno がたどった道
Deno は2018年、Ryan Dahl が Node.js の設計を振り返る講演とともに発表しました。標準で TypeScript を動かせること、権限を明示しないとファイルやネットワークに触れない仕組みなど、Node.js とは違う道を目指していました。
その後、2024年の Deno 2 で npm パッケージとの互換性を大きく強化し、同じ年にパッケージレジストリの JSR を始めます。Hacker News では、この方向転換を巡って意見が割れました。「Node から離れること自体が価値だったのに、互換を取りにいったことで使う理由が薄れた」という声がある一方で、Node.js が TypeScript の実行、権限モデル、.env の読み込みを取り込んだのは Deno の影響だという評価もあります。
Deno を使って製品を作ってきた Organic Software は「In Memory of Deno」という記事で、Deno の手軽さに感謝しつつ、ロックインが強い製品ではないので移行は難しくないとも書いています。
エンジニアへの影響 — いつまでに何を決めるか
影響の大きさは、Deno をどう使っているかで変わります。
Deno Deploy で動かしている場合は、残りは6か月です。いちばん急ぐ必要があります。公式の移行先は Cloudflare Workers で、有料ユーザーには移行支援があります。Workers は互換フラグを有効にすると Node.js の API を多く使えますが、Deno.* の API をそのまま使えるわけではありません。まず、コードの中で Deno. で始まる呼び出しと Deno KV を使っている箇所を洗い出すと、作業量の見積もりがしやすくなります。
Deno ランタイムを CLI やサーバーで使っている場合は、1年間はセキュリティ修正が届きます。急ぐ必要はありませんが、新しい機能は入らなくなります。npm 互換の範囲で書いているコードなら Node.js や Bun に移しやすく、Deno.* の API や権限フラグに頼っているほど書き換えが増えます。
JSR にパッケージを公開している場合は、JSR 自体は続くので、すぐの対応は不要です。ただし、1年後には Deno ランタイムの開発が止まるので、npm にも公開しておくと利用者の選択肢を狭めずに済みます。
これから新しく作る場合は、開発終了が決まったランタイムをあえて選ぶ理由は少なくなりました。Workers の書き方で作っておけば、Cloudflare 上でも、統合が進んだ workerd で自前のサーバーでも動かせるようになる見込みです。
まとめ
- Deno チームは Cloudflare に移り、Deno Deploy は6か月後、Deno ランタイムの開発は1年後に終わる
- JSR は Cloudflare のインフラで続き、Deno ランタイムはオープンソースのまま残る
- Cloudflare の狙いは、celld を workerd に取り込み、Workers と Durable Objects を自前のサーバーでも動かせるようにすること
- Deno Deploy の利用者は、
Deno.*API と Deno KV の使用箇所の洗い出しから移行を始めるとよい
Node.js の課題に答える形で生まれた Deno は、Deno チームの手を離れます。今後は、Workers の書き方が Cloudflare の外でも通用するようになるかが注目点です。