Deno が Cloudflare に入る、というニュースは、単なる企業買収の話ではない。JavaScript の runtime と hosting をどう組み合わせるか、そしてそれを AI 時代のサーバー基盤にどうつなげるか、という流れの話だ。元記事を書いた Ryan Dahl は、Deno を「より簡単にサーバーソフトを作るための試み」として積み上げてきたが、その延長線上にある次の舞台として Cloudflare を選んだ。Deno を使ってきた人には影響が大きい一方で、Web の実行基盤がどこへ向かうのかを示す出来事でもある。
元記事は、Deno がここまで何を目指してきたかを振り返るところから始まる。JavaScript でサーバーソフトを書くとき、モジュールの配り方はどうあるべきか、runtime はどこまで安全性を保証できるのか、ツールチェーンはどこまで一体化できるのか、そしてアプリを独立した実行ファイルとして配布しやすくできるのか。Deno チームはそうした問いを重ねてきたという。Node.js との互換性も、その過程で重要になった。利用者は Deno の改善を求めつつ、既存の JavaScript エコシステムともつながり続けたかったからだ。
その結果、Deno は単なる runtime ではなく、開発体験そのものを見直す存在になった。だが、Ryan Dahl はそこに留まらなかった。彼は以前から、計算資源、保存領域、通信がばらばらに組み立てられるのではなく、ひとまとまりで扱える世界を構想していた。Deno Deploy は、その理想に近づくための一歩だった。アプリを動かすこと自体は簡単にしたが、運用の下回りにはまだ複雑さが残っていた。そこで生まれたのが celld で、Cloudflare Workers の programming model を土台にしながら、最初から distributed applications を作りやすくし、しかも運用を単純にする方向を狙っている。
この流れを受けて、Deno チーム全体が Cloudflare に加わる。Cloudflare では Workers と Durable Objects のチームと合流し、ネットワーク上でも自前インフラ上でも、同じ programming model をサーバー構築の標準にしたいという。つまり、Deno の開発を続けるのではなく、共通の platform に力を集中させる判断だ。
その代わり、既存ユーザーへの移行計画も明示された。Deno runtime は今後 1 年は月次リリースで bug fix と security update を続けるが、その後は開発を止める。オープンソースのまま残り、継続したい人には開発を引き継いでほしいとしている。Deno Deploy は 6 か月で終了し、課金中の顧客には Cloudflare Workers への移行支援を行う。JSR は継続し、インフラだけが Cloudflare に移る。さらに rusty_v8 も支援し続け、将来的には workerd への統合を目指す。最後に、AI 向けの用途では Durable Objects が特に有用だとして、Rusty V8 や celld との関係も含めて、より深い abstractions を探っていく姿勢が示されている。
率直に言うと、この発表でいちばん重いのは「Deno runtime の開発を終える」という部分だと思う。Deno は長く、Node.js と別の道を歩みながら、より安全で、より統合された JavaScript runtime を作ろうとしてきた。そのチームが自分たちの看板そのものを畳み、別の shared platform に乗るのだから、ファンにとってはかなり大きい転換だ。ただし、これは後退というより、賭け先を変えたと見るほうが自然ではないか。runtime 単体で勝負するより、実際にアプリが走る基盤全体に入り込んだほうが、彼らの理想に近づけると判断したのだろう。
面白いのは、Cloudflare 側にとっても筋が通っていることだ。Workers は以前から edge での実行基盤として存在感があるが、Deno 側が持っていた runtime 設計、配布、開発体験の知見は、そのまま Cloudflare の資産になる。逆に Deno 側は、単独で hosting を抱えるより、より大きな運用基盤の上で理想を試せる。ここで起きているのは吸収というより、方向性の一致に近い。少なくとも元記事はそう読ませる。私は、この判断は「小さくて美しい runtime」を育てるより、「広く使われる実行モデル」に賭けたのだと受け取った。
利用者目線では、Deno Deploy の終了時期がかなり気になるはずだ。6 か月で shut down されると明言され、課金ユーザーには Cloudflare Workers への migration support が付く。これは冷たい打ち切りではなく、移行ルートを用意した上での整理ではある。それでも、Deno Deploy を前提に作ったサービスには影響がある。runtime と hosting を同じブランドで使っていたからこそ楽だった部分が、今後は分かれる。Deno を選ぶ理由が「runtime が好きだから」なのか「Deploy まで含めて楽だったから」なのかで、受ける痛みは変わるだろう。
一方で、JSR が続くのは救いだ。JSR は TypeScript-first の package registry で、Deno のエコシステムの中でも将来性を感じさせる部分だった。ここが生き残り、しかもインフラが Cloudflare に移るなら、少なくともモジュール配布の基盤はすぐには消えない。私はここに、Deno チームが本当に切りたかったのは「運用の重さ」であって「コミュニティの積み上げ」ではない、という意思を感じる。runtime を止めるのは痛いが、JSR の継続は、全体を焼き払うのではなく、残すべきものを残している。
元記事は AI をかなり前面に置いているわけではないが、最後の段落で急に輪郭がはっきりする。Ryan Dahl は、AI のためには better abstractions が必要だと言い、Durable Objects が agent harness に向いている理由として、安価な serverless execution、persistent state、WebSockets、高レベルな JavaScript interface を挙げている。ここで重要なのは、AI を動かすための GPU の話ではなく、状態を持った連続的なやり取りをどう設計するか、という点だと思う。エージェントは一回の応答で完結しない。会話の文脈や外部との接続を維持しながら動く必要があり、その土台には素直な state 管理がいる。
だからこそ、Deno の人たちが Cloudflare Workers と Durable Objects に寄るのは、AI ブームへの便乗というより、彼らが以前から追っていた「サーバーをもっと単純にする」という課題の延長に見える。違いは、昔は Web アプリの簡素化が主な対象だったのに対し、今は agent や distributed application のように、状態と通信がさらに複雑な相手になっていることだ。私はここに、Deno の思想がようやく今の市場に追いついた面もあると感じる。runtime を作るだけでは足りず、その上で動く高レベルな実行モデルまで持たないと、AI の現場では戦えない。Cloudflare との合流は、その現実への答えなのではないか。
この発表でいちばん揺れるのは、Deno を「別の選択肢」として採用していた開発者だろう。Node.js の外に逃げ道がある、という安心感で使っていた人にとって、Deno runtime の終了は心理的な支えを失うことになる。一方で、Cloudflare Workers をすでに使っている人や、これから edge ベースの開発を始める人には、Deno 側の知見が流れ込むのは歓迎材料だ。API の設計や実行モデルが洗練されれば、Cloudflare の基盤はさらに使いやすくなるはずだ。
ただ、ここで注意したいのは、こうした統合は「技術的に正しい」だけでは評価できないことだ。長く使ってきた人ほど、移行のコストや将来への不安を背負う。Deno がオープンソースとして残るとはいえ、実際に人がどれだけ継続して育てるかは別問題だ。私は、今回の発表を前向きに見る一方で、Deno が築いた独自性が Cloudflare の大きな流れの中に埋もれないかは少し気にしている。理想が広がるのと、名前が薄れるのは、しばしば同時に起こるからだ。
