DenoがCloudflareに合流、ランタイム開発は約1年で終了──期限から逆算した移行の判断材料

開発2026.10.14

2026年10月9日、Denoの開発チーム全員がCloudflareに合流すると発表されました。期限は2つあります。ホスティングサービスのDeno Deployは発表から約6か月（2027年4月ごろ）で停止、Denoランタイム本体は約1年（2027年10月ごろ）まで月次のバグ修正とセキュリティ更新が続き、その後は開発元による開発が終了します。コードはオープンソースとして残り、引き継ぐ開発者が現れれば継続されるという整理です。今すぐやるべきなのは移行先の決定ではなく、2つの期限が自社のどこに当たるかの棚卸しです。

発表で確定したこと

Denoランタイム: あと1年、バグ修正とセキュリティ更新を含む月次リリースを継続。その後は開発元としての開発を終了。公開は続き、開発を引き継ぐ人を歓迎すると明記
Deno Deploy: 6か月運用したのち停止。Cloudflare Workersへ移る有料顧客には移行支援を提供
JSR（JavaScript/TypeScript向けパッケージレジストリ）: 運用を継続し、インフラをCloudflareへ移管
rusty_v8（RustからV8を扱うライブラリ）: サポートを継続し、Workersの実行環境workerdへの統合を進める

注意すべき点として、発表に書かれているのは「1年」「6か月」という相対表現だけで、カレンダー上の終了日は示されていません。2027年4月・10月という日付は発表日からの逆算です。正確な日付は後から公式ドキュメントで告知される可能性が高く、社内の計画には余裕を持たせる必要があります。

発表に書かれていないもの

Deno KV、Webフレームワークの Fresh、Subhosting、Deno Sandbox、標準ライブラリは、2つの発表のどちらにも名前が出てきません。終了するとも継続するとも書かれていない状態です。特にDeno KVは、Deno Deploy上での提供とランタイム側のAPI（Deno.openKv相当の機能）の両方に関わるため、2つの期限の影響を同時に受ける位置にあります。データを置いているなら、移行先を決める前にまずエクスポート手段を確認しておくのが安全です。

なお、Deno Deployは旧版の Deploy Classic を2026年7月20日に停止した経緯があります。Deployユーザーにとっては2年連続の移行となるため、前回の移行作業で得た環境変数やカスタムドメインの手順書が、今回もそのまま点検リストとして使えます。

なぜCloudflareはDenoチームを迎えたのか

Cloudflare側の説明を読むと、今回の主眼はDenoランタイムではありません。Workersの実行環境workerdはすでにオープンソースですが、状態を持つ仕組みであるDurable Objectsの実装は単一インスタンスに限られ、ローカルテストには足りても本番のスケールには足りないと認めています。Cloudflare本番のルーティング実装は多数の外部サービスに依存しており、自前運用したい利用者が求めるものではない、という説明もあります。

そこに、Denoチームが2026年8月に公開した celld が重なりました。celld はWorkersのプログラミングモデルに基づき、オブジェクトストレージ1つだけを外部依存とするRust製のバイナリとして設計されています。両者を統合し、自前インフラでWorkersとDurable Objectsを動かせるようにするのが今回の目的です。

ここから読み取れる実務上の意味は明確です。この統合の成果物は「Denoの後継」ではありません。Workersのプログラミングモデルを自社サーバーで動かすためのものであり、deno runで動かしてきたスクリプトやCLIツールの置き換えにはなりません。しかも統合の完了時期は公表されていないため、移行計画のクリティカルパスに置くべきではありません。

自社のどこに影響するかを4つに分けて見る

Deno Deployで本番を動かしている

最も急ぎます。棚卸しの対象は、プロジェクト一覧、カスタムドメイン、環境変数とシークレット、cronジョブ、KVに入っているデータ、監視とログの転送先、契約と課金です。移行支援が明示されているのは有料顧客で、無料プランの扱いには言及がありません。個人アカウントで動かしている社内向けツールは誰も代わりに移行してくれない点にも注意が必要です。

サーバーやコンテナで Deno ランタイムを動かしている

約1年は修正リリースが出ます。決めるべきは「2027年10月以降、脆弱性対応を誰が担うのか」です。別ランタイムへ移すか、自社で保守を引き受けるか、未修正のまま使うかの三択で、前者ほど早く着手するほど安く済みます。

CIやビルドスクリプト、社内ツールで使っている

影響は小さいものの、棚卸しからは漏れやすい領域です。deno.jsonを含むリポジトリ、CIのセットアップ手順、Denoを前提にする外部ツールを検索しておきます。

JSRでパッケージを公開している

当面の対応は不要です。レジストリは継続し、インフラがCloudflareへ移ります。

移行先の選択肢と判断の軸

Cloudflare Workersは、Deploy固有の機能や世界各地への配信を使っている場合の第一候補です。Deno.serveに渡すハンドラはRequestを受けてResponseを返す形なので、Web標準のAPIだけで書かれていればエントリーポイントの書き換えで済みます。一方で設計判断が要るのは次の2点です。1つはリクエストをまたいで生き続けるプロセスがないこと。トップレベル変数に載せていたキャッシュは、実際のストレージに移す必要があります。もう1つはKVの移行先で、読み取り中心の設定値ならWorkers KV、カウンタやセッションのように「確認してから書く」処理が必要ならDurable Objectsのストレージが対応先になります。npm依存については、Cloudflareの公式ドキュメントによれば compatibility_date が 2026-08-04 以降のWorkersでは nodejs_compat が既定で有効になり、追加設定なしでNode.js組み込みAPIが使えます。

Deno固有APIへの依存が薄く、HTTPとデータベースが中心のアプリなら、Node.jsへ戻す方が素直です。Bunという選択肢もありますが、開発元のOvenは2025年12月にAnthropicに買収されており、独立系ランタイムが大手プラットフォームに吸収される構図という点では同じです。低トラフィックの個人プロジェクトであれば、期限まで様子を見てコミュニティのフォークが立ち上がるか確認するのも合理的ですが、本番の前提にはできません。

判断の軸は、期限までの残り時間、Deno固有APIへの依存度、状態をどこに持っているか、移行後の運用コストの4つに整理できます。

期限から逆算した進め方

今週: Deploy上のプロジェクトとKVのデータ、deno.jsonを持つリポジトリ、CIのDenoセットアップを一覧化する
今月: KVなどのデータをエクスポートし、別の保存先への復元まで試す。移行ツールの発表を待たない
年内から2027年初頭: 代表的なサービスを1つだけ移植し、工数と実トラフィックでの費用を実測してから全体方針を決める。有料顧客なら移行支援の依頼を期限間際より前に出す
2027年4月の1か月前: Deployからの移行を完了させる
2027年10月まで: 自前で動かしているDenoランタイムの扱いを決着させる

あわせて、公式の終了日が確定したときに気づける導線を用意しておきます。Denoの公式ブログとドキュメントが一次情報です。

ランタイム選定への示唆

今回の件が示したのは、オープンソースであることは「使い続けられる保証」ではなく「自分たちで保守できる余地」にすぎない、ということです。Cloudflareは2026年6月にViteの開発元VoidZeroの買収も報じられており、JavaScriptまわりのツールチェーンは少数のプラットフォーム企業に集約されつつあります。体制変更は数か月の猶予とともにやってきます。

現実的な備えは、派手なものではありません。ハンドラをWeb標準のRequest/Responseで書き、ランタイム固有APIを薄い層に閉じ込めておくこと。状態の保存先を、エクスポート手段のある場所にしておくこと。この2つを守っていれば、今回のような移行は週末規模の作業と、データ移行の計画で収まります。

まとめ

まずは棚卸しです。Deno Deployで動いているもの、KVに入っているデータ、Denoランタイムを前提にしているリポジトリを書き出し、2027年4月と2027年10月という2つの期限に割り当てる。ここまで終われば、移行先の比較は落ち着いて進められます。

Deno DeployからWorkersへの移植や、Denoで書かれた社内ツール・フロントエンド基盤の移行方針の検討で手が足りない場合は、chot Inc. のお問い合わせからご相談ください。現状の棚卸しと移行方針の整理からお手伝いします。

出典

この記事をシェア