2026年10月9日、Denoの開発チーム全体がCloudflareに参加することが発表された。
本合流の技術的な中核は、独立したランタイム開発からCloudflareとの共通プラットフォーム開発へのリソース集中である。具体的には、Deno側が開発してきたセルフホスト向けプロジェクト「celld」の知見やコードをCloudflareの「workerd」に統合し、自社インフラ上でCloudflare Workersのプログラミングモデルをスケールする形で運用可能にすることを目指す。
これに伴い、既存のDenoエコシステム(Denoランタイム、Deno Deploy、JSR)は段階的な移行・運用フェーズへと移行する。
事象の背景と構造
今回の合流は、メディア(The New Stack)によって「Cloudflareによる買収(取引条件は非開示)」と報じられている一方、両社の公式発表では「チーム全体の参加」と表現されている。
この体制変更に伴い、Denoがこれまで提供してきた各プロダクトおよびサービスのロードマップは以下のように再編される。
| プロダクト/サービス | 今後の方針・タイムライン |
|---|---|
| Denoランタイム | 今後1年間にわたり月次でバグ修正とセキュリティ更新を提供。その後、Deno側での開発は終了するが、コードはオープンソース(OSS)として残され、コミュニティによる継続開発に委ねられる。 |
| Deno Deploy | 発表から6か月間運用を継続した後にサービスを終了。有料顧客に対してはCloudflare Workersへの移行支援が提供される。 |
| JSR(パッケージレジストリ) | 運営は継続。運用インフラをCloudflareへと移行する。 |
| rusty_v8 | サポートを継続し、workerdへの統合を進める。 |
![[Deno]Cloudflare合流と「workerd」統合](https://mtoy.work/develop/wp-content/uploads/sites/3/2026/02/Deno-logo-160x90.png){kind=logo}
コアとなる技術的仕組みの解説
今回の技術的統合における最大の焦点は、「celld」の知見を用いた「workerd」のセルフホスト環境におけるスケーラビリティ課題の解決である。
celldのアーキテクチャ
`celld`は、Cloudflare WorkersやDurable Objectsのプログラミングモデルを、Cloudflareのインフラに依存せず自社インフラ(セルフホスト環境)で動作させるために開発され、2026年8月に公開されたプロジェクトである。
その構成は、Rust製の単一バイナリとオブジェクトストレージを中心としている。
従来のworkerdにおける課題
オープンソース版の`workerd`を自前でホストする場合、Durable Objectsの実装が単一インスタンスに制限され、スケールしないという課題が存在していた。これはCloudflareの本番環境(マネージドサービス)の制限ではなく、セルフホスト版固有のアーキテクチャ上の制約であった。
統合によるアプローチ
固有の識別名と永続ストレージを組み合わせるDurable Objectsのモデルに対し、`celld`が培ってきたRust製バイナリとオブジェクトストレージ中心の設計アプローチを`workerd`に取り込む。これにより、自社インフラ上でもスケールアウト可能なDurable ObjectsおよびWorkersプログラミングモデルの運用基盤を確立する。
また、Denoが主導してきたV8のRustバインディングである`rusty_v8`のサポートも継続され、`workerd`への統合が進められる。
![[Deno]Cloudflare合流と「workerd」統合](https://mtoy.work/develop/wp-content/uploads/sites/3/2026/10/cloudflare-Clef-320x180.png)
今後の影響と論点
1. セルフホスト型分散アプリケーションの台頭
Cloudflareの強力なプログラミングモデル(Workers / Durable Objects)が、Cloudflareのプロプライエタリなネットワーク外、すなわち任意の自社インフラやプライベートクラウド上でも制限なくスケールする形でデプロイ可能になる。これにより、ベンダーロックインを懸念していたエンタープライズ層にとって、エッジファーストなアーキテクチャの採用ハードルが大きく下がる。
2. Denoエコシステムの移行対応
Deno Deployの利用者は、6か月という比較的短い猶予期間の中でCloudflare Workersへの移行を完了させる必要がある。Deno側から提供される移行支援の詳細を注視し、移行計画を早期に策定することが求められる。
3. ランタイムのガバナンス移行
Denoランタイム自体の開発は1年後にコミュニティ主体へと移管される。V8エンジンのアップデート追従や新機能の取り込みなど、今後のメンテナンス体制がどのように構築されるかが、既存のDenoランタイムユーザーにとっての長期的な論点となる。
コメント