Deno チームが Cloudflare に加わることは、2026 年 10 月 9 日、Deno 創設者の Ryan Dahl が Deno 公式ブログで発表し、Cloudflare も同日に公式ブログで計画を確認しました。単なる人材移動ではありません。チーム全員が移籍すると同時に、Deno のホスティングサービス Deno Deploy は終了へのカウントダウンに入り、独立したランタイムも公式保守の残り期間が1年となりました。
Cloudflare に足りないのは、セルフホストできる Durable Objects
Cloudflare は同日の記事で弱点を率直に語っています。オープンソースのランタイム workerd は本番環境とコードを共有していますが、その Durable Objects 実装は単一インスタンス版のみで、ローカルテストには十分でも、セルフホストの規模には耐えられません。一方、Cloudflare 自身の本番用オブジェクトルーティングは世界各地の拠点と外部サービス群に依存しており、顧客のデータセンターへ持ち込むには向きません。Deno チームが 2026 年 8 月に公開した celld は、まさにこの穴を埋める存在です。Workers と Durable Objects のオープンソース実装であり、最初からセルフホストと水平スケールを想定して設計されています。今後、Ryan Dahl と Bert Belder が中心となり、celld のコードと考え方を workerd に統合し、Workers のプログラミングモデルを自前サーバーで動かすことを正式な選択肢にしていく計画で、詳細は今後数か月で発表されます。
二つの期限：Deploy は半年、ランタイムは1年
Deno を使っているチームにとって、ビジョンより日程が重要です。Deno Deploy は6か月間運用を続けた後、終了します。有料ユーザーには Cloudflare Workers への移行支援が用意されます。Deno ランタイムは今後1年間、月次でバグ修正とセキュリティ修正を受け取りますが、その後は元のチームによる開発が終わります。コードはオープンソースのまま残り、コミュニティが引き継げます。パッケージレジストリ JSR は運営を続け、インフラは Cloudflare へ移ります。基盤コンポーネントの rusty_v8 も継続し、workerd への統合が目標です。6か月先に数えると、2027 年 4 月前後に Deploy 上で動いているサービスは移行を終えている必要があり、その猶予は発表日からすでに始まっています。
エージェント開発者が注目する理由
Dahl は発表文の中でエージェントのシナリオに特に触れています。Durable Objects は、安価なサーバーレス実行、永続状態、WebSocket 接続を一つのオブジェクトに詰め込んでおり、長時間動くエージェント基盤が求める土台に近いからです。大規模にエージェントを構築しているチームには、直接連絡してほしいとも呼びかけました。エージェントのトラフィックがすでに人間のトラフィックを上回っている以上、実行レイヤーがどこに集約されるかは、エージェント製品のコスト構造とデプロイの境界を直接左右します。Workers が Cloudflare のネットワークでも顧客の自前サーバーでも同じように動けば、エージェント事業者は「プラットフォームの便利さ」と「データを自社ネットワークの外に出さないこと」の二者択一を迫られなくなります。
もっとも、約束が実装されるまでは、これはまだ路線図にすぎません。セルフホスト版 workerd の周辺ツールこそ、Cloudflare 自身が手薄だったと認める部分であり、Deno チームの合流がそれを埋められるかは、今後数か月の実際の出荷次第です。Deno ユーザーの判断はもっと単純で、まず Deploy の終了日に合わせて移行を準備し、その上でセルフホスト版 workerd を追う価値があるか見極めることです。
