【ITニュース解説】Deno Deploy Shuts Down in Six Months. Here Is the Migration Path to Cloudflare Workers.

Deno Deployサービスが半年後に終了し、Denoの開発チーム全体がCloudflareに合流するという大きなニュースがあった。これはDeno Deployを利用していた多くの開発者にとって、システムの移行を検討する重要な時期が来たことを意味する。

具体的に何が起こるのか。Deno Deployサービス自体は、およそ6ヶ月後の2027年4月頃に完全に停止する。現在Deno Deployでアプリケーションを動かしている場合、この期限までに別の環境へ移行する必要がある。Denoランタイム本体の開発も、現時点から1年後に終了する。その後1年間はバグ修正やセキュリティアップデートは提供されるが、それ以降はDenoを開発していた企業としての公式サポートは停止される。Denoはオープンソースプロジェクトのため、コミュニティが開発を引き継ぐ（フォーク）可能性はあるが、提供元からの公式な開発は終了する。しかし、全てのDeno関連技術が消滅するわけではない。JavaScriptのパッケージレジストリであるJSRはCloudflareのインフラで引き続き運営され、Denoの基盤技術であるV8エンジンのRustバインディングであるrusty_v8もCloudflareによって維持され、同社のWorkersの基盤であるworkerdに統合される予定だ。

CloudflareがDenoチームを買収した背景には、サーバーサイドJavaScriptの未来に対するビジョンがある。Denoの開発者であるRyan Dahl氏は、コンピューティング、ストレージ、通信といったアプリケーションの基盤要素が一体となって提供されるべきだと考えていた。Cloudflareは「celld」というプロジェクトを進めており、これはCloudflare Workersのプログラミングモデルを基盤とし、スケーリングがアプリケーション開発に組み込まれている仕組みを目指す。DenoチームはCloudflareのWorkersチームやDurable Objectsチームと協力し、このビジョンを実現していく。特に重要なのは、Durable ObjectsがAIエージェントの基盤として非常に有用であるとCloudflareが見ている点だ。Durable Objectsは、安価なサーバーレス実行、永続的な状態管理、WebSocket通信、高レベルなJavaScriptインターフェースを兼ね備えており、これらがAIエージェントの構築に必要な機能と一致するという。つまり、CloudflareはDenoそのものよりも、サーバーサイドJavaScriptをシンプルにするDenoチームの技術とアイデア、そしてDurable Objectsを強化し、AI分野で活用するポテンシャルに価値を見出したと言える。Node.jsと競合するDenoランタイムを単独で提供し続けることではなく、Durable Objectsが目指すべき最終地点なのだ。

では、Deno Deployで動かしていたアプリケーションをCloudflare Workersへ移行するにはどうすればよいか。一般的なDeno Deployアプリケーションは、Deno.serve()でサーバーを起動し、Deno KVでデータを保存し、必要に応じてDeno.cron()で定期実行タスクを設定していることが多い。これらの要素がWorkersでどのように置き換わるかを見てみよう。

まず、Deno.serve()で作成していたサーバー部分は、Workersではfetchハンドラーという関数に置き換わる。Workersはイベント駆動型なので、Denoのように明示的にサーバーを「起動する」概念がない。HTTPリクエストが来たらfetchハンドラーが実行される仕組みだ。既存のルーティングロジックやリクエスト処理のコードは、ほぼそのままfetchハンドラーの中に移植できるだろう。ただし、注意すべき点として、Workersの実行環境はリクエストごとに独立しているため、Deno Deployでトップレベルの変数にキャッシュしていたような、リクエスト間で永続するインメモリのグローバルな状態はWorkersでは期待できない。そのようなデータは、何らかの永続ストレージに保存する必要がある。

次に、Deno KVを使ったデータの保存方法についてだ。Deno KVはその使いやすさで定評があったが、Workersには2つの代替手段があり、どちらを選ぶかが移行における最も重要な設計判断となる。一つは「Workers KV」だ。これは設定データ、ルーティングテーブル、機能フラグ、認証トークンなど、主に読み込みが多いデータに適している。Workers KVはグローバルにデータが複製され、高速な読み込みが可能だ。しかし、キーは文字列でなければならないため、Deno KVで配列キーを使っていた場合は「preferences:ada」のように文字列に変換する必要がある。また、値も文字列として保存されるため、JavaScriptオブジェクトを保存する場合はJSON形式にエンコードする必要がある。そして、重要なこととして、Workers KVには複数のキーにまたがる原子的なトランザクション機能や、既存の値を確認して更新するような競合防止の機能はない。

もう一つの選択肢は「Durable Object storage」だ。こちらは、カウンター、レートリミッター、ユーザーのセッション状態など、データの書き込み頻度が高く、特に原子的な操作や厳密な一貫性が必要な場合に適している。Durable Objectは、それぞれが独自のプライベートでトランザクションが可能なストレージを持つ。最近ではSQLiteをバックエンドとして利用できるようになり、実際のSQLテーブルや過去30日間のポイントインタイムリカバリといった高度な機能も使えるようになった。Deno KVのatomic()のような原子操作をWorkersで実現したい場合は、Durable Object storageがまさにその代替となる。例えば、カウンターのような「現在の値を取得し、新しい値を計算して、それを安全に書き戻す」といった処理は、Workers KVでは競合状態を引き起こす可能性があるが、Durable Object storageではトランザクション機能を使って安全に実行できる。つまり、単純な読み込み主体のデータであればWorkers KV、複数の操作をまとめて実行するトランザクションや高い一貫性が求められるデータであればDurable Objectを選ぶのが良いだろう。

定期実行タスクであるDeno.cron()については、Cloudflare Workersでは、Wranglerという設定ファイルにトリガーを設定し、Workerスクリプト内にscheduledハンドラーという関数を記述することで対応できる。Cronの記述形式自体はDenoとほぼ同じなので、既存のロジックをscheduledハンドラー内に移植すれば良い。

npmパッケージの依存関係については、Cloudflare WorkersはNode.js互換モードをサポートしているため、ほとんどのnpmパッケージは特別な設定なしでそのまま動作するはずだ。また、もしDeno DeployのプロジェクトがAPIと一緒にフロントエンドの静的ファイルも提供していた場合、Cloudflare WorkersではWrangler設定ファイルのassetsブロックを使って静的ファイルを簡単にホスティングできる。Cloudflareはまず静的ファイルを探索し、該当するものがなければWorkerスクリプトにリクエストをフォールバックさせるため、Deno Deployと同じ単一オリジンでの運用が可能だ。

Deno Deployからの移行先はWorkersだけではない。CloudflareはWorkersへの移行を推奨するが、他の選択肢も存在する。一つは、Deno Deployのサービス停止期限までそのまま利用し続けることだ。もしアプリケーションが低トラフィックのサイドプロジェクトであれば、コミュニティによるDenoのフォークの登場を待つ時間稼ぎにもなる。もう一つは、Node.js、Bunといった別のJavaScriptランタイム、あるいは自前のサーバー環境へ移行することだ。もしアプリケーションがごく普通のHTTP処理とデータベースの組み合わせであれば、Deno.serveからこれらの環境への移行は比較的簡単で、特定のベンダーに依存しない選択肢となる。

いずれの選択肢を選ぶにしても、最も重要なのは、Deno KVに保存されているデータを今のうちにエクスポートしておくことだ。データのエクスポートは、後回しにすると問題が大きくなりがちなので、早めに対応しておくことを強く推奨する。

今回のDeno Deployの終了とDenoチームのCloudflare合流は、サーバーサイドJavaScriptの進化の大きな流れを示している。過去10年間で主要なランタイムが登場したが、最終的にはどちらも「エッジにデプロイされた軽量な実行環境と、それに付随する状態管理」という共通のパラダイムに収束しつつある。もしDahl氏が言うように、Durable Objectsが将来的なAIエージェントの基盤となるのであれば、今回のWorkersへの移行パスは、まさに次の大きなトレンドへの入り口となるかもしれない。この機会に、自分のアプリケーションの構成要素を整理し、適切な移行パスを選択することは、今後のキャリアにおいても貴重な経験となるだろう。