Deno チームが Cloudflare に参加 — workerd と celld を統合し、Workers / Durable Objects の self-host を一級サポートへ
Cloudflare が Deno チームの参加を発表した。Node.js の作者 Ryan Dahl と共同創業者 Bert Belder を含むチームが加わり、Dahl の言葉として「workerd と celld をマージする」が引用されている。目的は Cloudflare の OSS ランタイム workerd の self-host を一級サポートの選択肢にすること。workerd は Durable Objects を単一インスタンスとしてしか実装しておらず、公式はこれをスケールに適さないと認めている。Deno チームが2026年8月に公開した celld（外部依存がオブジェクトストレージだけの単一 Rust バイナリ）のコードと設計を取り込む。Cloudflare 公式投稿には退役日程・移行要件・価格の記載が無く、「今後数か月でさらに発表する」とだけ書かれている。Deno ランタイム・Deno Deploy・JSR の今後については公式投稿が一切触れていない。
ニュース原文を読む ↗要約
Cloudflare 公式ブログが、Deno チームの Cloudflare 参加を発表しました。Node.js の作者 Ryan Dahl と共同創業者 Bert Belder を含むチームが加わります。投稿は Cloudflare の Kenton Varda と Ryan Dahl の共同署名です。
Dahl の言葉として引用されているのは1文です。「workerd と celld をマージする」。
この1文の意味を理解するには、workerd の現状の制約を知る必要があります。 workerd は Cloudflare の Workers ランタイムのオープンソース実装です。自分のサーバーで Workers を動かせます。ただし Durable Objects が単一インスタンスとしてしか実装されていません。 公式投稿はこれを「スケールに適さない」と自ら認めています。
Durable Objects は、Workers のプラットフォームで最も代替が難しい部品です。 一貫性を持つ状態を、特定のオブジェクトに紐づけて保持する仕組みです。エージェントのセッション、WebSocket のコーディネーション、カウンタ、ロック——状態を持つ処理の大半がここに乗ります。 これが self-host でスケールしないということは、**実質的に「workerd では本番のアーキテクチャを再現できない」**という意味でした。
celld がその欠けている部分を埋めます。 Deno チームが 2026年8月に公開したもので、公式投稿は「外部依存がオブジェクトストレージだけの単一 Rust バイナリ」と説明しています。Ryan Dahl と Bert Belder が、workerd の self-host を一級サポートにする新しい取り組みを率い、celld のコードと設計を workerd へ戻していくとされています。
公式投稿に書かれていないことを明示します。 退役日程・移行要件・価格・コミットメントの記載はありません。 「今後数か月でさらに発表する」とだけ書かれています。self-host については「celld も workerd も、今日から自分で動かせる」とあります。
Deno 側の製品——Deno ランタイム、Deno Deploy、Deno KV、JSR、Node.js 互換性——について、Cloudflare 公式投稿は一切触れていません。 投稿は Ryan Dahl 自身の Deno ブログの記事を参照するよう案内していますが、本記事の執筆時点で deno.com は調査環境から DNS 解決できず、一次情報を直接確認できていません。
報道ベースでは、次の日程が伝えられています。 Deno ランタイムは1年間の保守・セキュリティ更新を経て公式開発を終了（OSS のままコミュニティへ）、Deno Deploy は6か月後に停止（有料顧客は Cloudflare Workers への移行を支援）、JSR はインフラを Cloudflare へ移して継続。ただしこれらは一次確認が取れていません。 Deno の製品を使っている場合は、deno.com の公式発表を直接確認してください。
何が変わったか
- Deno チームが Cloudflare に参加（2026-10-09 公表）。Ryan Dahl と Bert Belder を含む
- Ryan Dahl と Bert Belder が、workerd の self-host を一級サポートにする取り組みを率いる
- celld のコードと設計を workerd へ取り込む。 celld は2026年8月公開、外部依存はオブジェクトストレージだけの単一 Rust バイナリ
- 背景の制約: workerd は Durable Objects を単一インスタンスとしてしか実装していない。公式が「スケールに適さない」と認めている
- 現時点では機能変更なし。 celld / workerd の self-host は従来どおり可能
- Cloudflare 公式投稿に無いもの: 退役日程、移行要件、価格、具体的なコミットメント。「今後数か月でさらに発表する」とのみ
- Deno 側製品の扱いは Cloudflare 公式投稿に記載なし（Deno ランタイム / Deno Deploy / Deno KV / JSR / Node.js 互換性）
- 報道ベースの日程（一次確認できていない）: Deno ランタイムは1年の保守後に公式開発終了（OSS 継続）、Deno Deploy は6か月後に停止、JSR は Cloudflare 配下で継続
業務インパクト（一般企業向け）
まず、今すぐ対応が必要かどうかを切り分けてください。2つに分かれます。
Workers / Durable Objects を使っているだけなら、今日やることはありません。 機能変更はなく、価格の変更もありません。これは将来の選択肢が増えるという話です。
Deno ランタイム・Deno Deploy・JSR を使っているなら、今週中に確認が必要です。 報道されている日程——Deno Deploy が6か月後に停止——が正しければ、移行計画を立てる期間は半年です。 ただしこの日程は一次確認が取れていません。 deno.com の公式発表を自分で確認してください。本記事の日程を根拠に意思決定しないでください。
中期的に効くのは、ベンダーロックインの評価軸が動く可能性です。
Workers を採用するときの最大の懸念は、「Cloudflare から出られるか」でした。 Workers 単体なら workerd で動きます。しかし Durable Objects を使った時点で、実質的に出口がなくなっていました。 self-host 版がスケールしないからです。状態を持つアーキテクチャほど、ロックインが強くなる構造でした。
公式がこの制約に正面から着手したこと自体が、評価に影響します。 「将来 self-host できる見込みがある」というのは、技術選定の稟議で効く材料です。ただしまだ何も出ていません。 「今後数か月でさらに発表する」という段階です。稟議に「将来 self-host 可能」と書くのは、発表が出てからにしてください。
社内の技術選定ドキュメントに、この動きを1行入れておく価値はあります。 「Durable Objects は self-host 不可（workerd は単一インスタンスのみ）」と書いてある資料があれば、「2026-10 に Cloudflare が改善に着手、続報待ち」を添えてください。 制約が変わりうる前提で書いておけば、半年後に読んだ人が古い情報で判断しません。
celld の存在は、今日から評価できます。 公式投稿は「celld も workerd も今日から self-host できる」と書いています。外部依存がオブジェクトストレージだけの単一 Rust バイナリという構成は、オンプレミスや規制のある環境での検証対象になります。ただし celld は Cloudflare の製品ではなく、Deno チームが公開したものです。 統合がどう進むかは未定で、今日の celld にそのまま依存する判断はリスクを伴います。
人材の動きとして見るなら、Workers の方向性が読めます。 Node.js と Deno を作った人物が、Cloudflare のランタイムを「どこでも動くもの」にする側に回ったということです。Dahl 自身の動機は、報道ベースでは「エージェントの数が爆発的に増えており、そのすべてに Linux VM が必要とは思わない」という文脈で語られています。エージェント実行基盤としての Workers を、Cloudflare 外へ広げる方向と読めます。
副業・個人活用視点
この発表は、技術ニュースとして書く価値が高い一方で、書き方を間違えやすい題材です。
間違えやすい点は、公式が言っていることと報道が言っていることの区別です。 Cloudflare 公式投稿が言っているのは「Deno チームが参加する。workerd の self-host を一級サポートにする。今後数か月で続報」だけです。Deno Deploy の停止期限や、ランタイムの開発終了は、Cloudflare 公式投稿には一文字も書かれていません。 多くの記事がこれを混ぜて書きます。分けて書けば、それだけで信頼される記事になります。
題材として一番おいしいのは、「なぜ Durable Objects の self-host が難しいのか」です。 公式が「単一インスタンスのみ、スケールに適さない」と認めている。なぜ単一インスタンスになるのかを説明できれば、分散システムの記事として成立します。 Durable Objects は「特定のオブジェクト ID に対して、常に1つのインスタンスだけが存在する」という保証を提供します。この保証をマルチノードで維持するのが難しい——ここが技術的な核です。celld がそれをオブジェクトストレージ1つで解いているなら、その設計自体が読む価値のある題材です。
個人開発者にとっての実利は、「出口が見える」ことです。 Workers は無料枠が広く個人開発に向きますが、Durable Objects を使い始めると移行先がなくなります。 趣味プロジェクトなら構いませんが、それが収入源になったとき、プラットフォーム依存は怖い。 self-host の道筋が付くなら、Durable Objects を使う判断のハードルが下がります。
ただし、今の段階で設計を変えないでください。 「今後数か月で発表」という状態です。発表されていない機能を前提に設計すると、発表されなかったときに全部やり直しです。 今やるべきは「celld を触ってみる」程度の検証で、本番の設計判断は続報を待つのが正しいです。
Deno を使っている個人開発者は、今週 deno.com を確認してください。 報道ベースで Deno Deploy は6か月です。個人のプロジェクトなら移行は大仕事ではありませんが、6か月後に突然止まるより、今知っておくほうが楽です。JSR にパッケージを公開している場合も、継続とされてはいますが、運営主体が変わります。 自分で確認する価値があります。
記事にするなら、「一次情報が取れなかった」と書くことにも価値があります。 本記事も deno.com に到達できず、日程を一次確認できていません。取れなかったことを書く記事は、取れたふりをする記事より信頼されます。 読者が自分で確認する動線を作れます。