DenoがCloudflareへ — ランタイムを置いて人だけが移る買収

これはランタイムの買収なのか、それともランタイムを手放すことと引き換えにプログラミングモデルを買ったのか?

導入

2026年10月9日、Denoのブログに Ryan Dahl 名義の記事「Deno is joining Cloudflare」が掲載された。Hacker Newsでは「Cloudflare acquires Deno」というタイトルで1389ポイントを集め、その日もっとも熱を帯びた話題の一つになった。同じ日、Cloudflareのブログにも Kenton Varda と Ryan Dahl の共同記事が公開された。

タイトルだけ見ればありふれた買収のニュースである。ところが本文の中ほどに置かれた四行のリストが、この出来事の性格を変えてしまう。Denoランタイムは今後1年間、バグ修正とセキュリティアップデートを含む月次リリースでサポートされ、その後は開発が終了する。Deno Deployはあと6か月運営したのちに閉鎖される。JSRはインフラをCloudflareに移して運営を続ける。rusty_v8は引き続きサポートし、workerdへの統合を目指す。

Hacker Newsのコメント欄の温度は、まさにこのリストで分かれた。一方は「DenoがCloudflareに合流するのではなく、Denoの人々が合流するのだ」としてタイトルから直すべきだと言い、もう一方はcelldとworkerdの統合こそ本当のニュースだと見た。その一週間前には、長年のDenoユーザーだった David Bushell が「Friendship ended with Deno, now Node is my best friend」という記事でNodeへの回帰を宣言し、323ポイントを得ていた。本稿はその二つの流れのあいだで、公開された事実と解釈を区別しながら、この買収の意味を検討する。

発表文が語ったこと、語らなかったこと

まず事実関係を整理しよう。Dahlの記事は、Denoが歩んできた道を三段階で説明する。モジュールの配布方法、ランタイムが提供できるセキュリティ保証、完結したツールチェーン、単一実行ファイルでの配布を問い直したDenoランタイムが第一段階である。次が、アプリケーションの実行をできる限りシンプルにしようとしたDeno Deployだ。そしてDeployを構築・運用するなかで、その開発者体験の下にどれほどの複雑さが残っているかを知り、その層まで単純化しようとして作ったのがcelldである。celldはCloudflare Workersのプログラミングモデルの上に築かれ、スケーリングを各アプリが自前で組み立てるインフラではなく、プログラミングモデルの中に組み込もうとする試みだ。

Dahlは「DenoからDeno Deploy、そしてcelldへと続く流れが、この決断がなぜ理にかなうかを説明している」と書く。Cloudflareでは Workers チームや Durable Objects チームと作業を統合し、このプログラミングモデルを、Cloudflareのネットワーク上でも自前のインフラ上でも、サーバーを作る標準的な方法にしたいという。そして「合流するということは、どこに力を注ぐかを選ぶことでもある」として、独立したランタイムとホスティングサービスの開発を続ける代わりに、この共有プラットフォームに今後の開発を注ぐと決めたと明かした。Denoの上に何かを築いてきた人々にとって重大な変化であることも、自ら認めている。

Cloudflare側の記事は力点が異なる。要約文は「DenoチームがWorkersとDurable Objectsのセルフホスティングを根本的に簡単にするためにCloudflareに合流する」である。Vardaは、workerdがすでにオープンソースであり、本番で動いているのと同じコードであること、しかしDurable Objectsは単一インスタンス方式でしか実装されておらず、ローカルテストには十分でもスケールできないことを率直に認める。最初のリリース時からTODOコメントが残っており、自分も昨春に一度試みたがうまく動かなかったという告白まで添えている。そこへDenoチームが8月に公開したcelldが、WorkersおよびDurable Objectsと完全に互換でありながらセルフホスティングとスケーラビリティに焦点を当てた実装だった、というわけだ。計画としては、Ryan Dahl と Bert Belder が workerd のセルフホスティングを第一級のサポート対象にする取り組みを率い、celldのコードとアイデアをworkerdへマージする。

ここには注目すべき非対称がある。Hacker Newsで simonw は、ランタイム終了という事実がDeno側の記事にはあるのに、Cloudflare側の記事には一言も触れられていないと指摘した（直接の引用ではなく、コメントの要旨の要約）。実際、Cloudflareの記事は1分で読める分量で、workerdとcelldの統合、そして「ロックイン」論への反論に紙幅を割いている。Denoランタイムの行く末を知りたい人は、Denoブログのリストまで読み進めなければならない。

もう一点、買収額はどちらの記事にも書かれていない。Hacker Newsのタイトルは「acquires」だが、発表文自体は「チーム全員が合流する」という表現を使っている。どのような取引構造だったのかは、公開資料からは分からない。本稿でもその点は判断しない。

なぜランタイムではなくプログラミングモデルなのか

コメント欄でもっとも繰り返された問いは単純だった。「殺すつもりなら、なぜ買ったのか」。この問いに答えるには、Cloudflareが何を欲していたのかを発表文から読み直す必要がある。

Vardaの記事の半分は、よくある批判、つまりWorkersが他のクラウドと異なる設計になっているのはロックインのためだ、という説への反論である。その説に従えば、WorkersとDurable Objectsのオープンソース実装であるcelldはCloudflareにとって脅威のはずだ。Vardaは逆だと言う。2022年にWorkers for PlatformsをShopifyのような顧客に提案した際、顧客たちはWorkersランタイムがオープンソースでなければその上には構築できないと答え、だからworkerdを公開した。workerdを使って離れていったかつての顧客もいるが、オープンソースでなければそもそも契約しなかった顧客であり、一社離れるごとにはるかに多くの顧客が残っている、というのが彼の説明だ。脱出口を用意することは良いビジネスだという主張である。

この論理を受け入れると、絵が噛み合う。Cloudflareに必要なのは「Workersのプログラミングモデルは、Cloudflareの外でも本気で動く」という信頼だ。その信頼を作るのに必要なのは汎用のJSランタイムではなく、分散Durable Objectsをセルフホスティング環境で実装できるチームと、そのチームがすでに作り上げたcelldである。Dahlの説明によれば、celldはRustで書かれた単一バイナリで、外部サービスへの依存はオブジェクトストレージ一つだけだ。複数のcelldインスタンスとバケット一つを管理すればよい。Hacker Newsの ryanrasti は、耐久性と協調の両方をオブジェクトストレージの上にブートストラップする設計がセルフホスティングを大きく単純化すると評価し、S3が自前でも運用できるプロトコルになった以上、その依存は正当だと見た（直接の引用ではなく、コメントの要旨の要約）。

逆に、Denoランタイムはこの戦略において重複する資産である。Cloudflareはすでにworkerdという自社ランタイムを本番で使っている。二つのJSランタイムを同時に第一級で維持する理由は、一社にとっては乏しい。Deno DeployもWorkersと正面から重なる。Deno側が有料顧客にWorkersへの移行支援を約束したのは、この重複を整理するやり方だ。Hacker Newsの networked は、celldは現行のworkerdより完成度の高い「自宅で動かすCloudflare」であり、今回の買収によって他社がcelld目当てにDenoを買う可能性はなくなったと指摘した（直接の引用ではなく、コメントの要旨の要約）。この観察は分析的に意味がある。Cloudflare互換のセルフホスティング実装の主導権が、Cloudflareの内側に入ったということだからだ。

ただし、これが利用者にとって悪いと断じる根拠もまだない。Vardaは今すぐcelldやworkerdをセルフホストできると書いており、Hacker Newsの heliosAtwork も、統合後の成果物がクローズドソースになる兆候はなく、ロードマップのコミュニケーションが足りないだけだと整理した（直接の引用ではなく、コメントの要旨の要約）。判断は、今後数か月のうちに出るという「追加の発表」を見なければ下せない。

Dahlがこの決断の動機としてAIを明示した点も記録しておきたい。彼は、Durable Objectsが安価なサーバーレス実行、永続状態、WebSocket、高水準のJavaScriptインターフェースを一つにまとめており、エージェントハーネスに特に有用だと書き、celldがDurable Objectsに注力する理由はそこにあるとした。エージェントを大規模に自前のインフラで動かしたい人は連絡してほしい、という一文で記事は締めくくられている。

独立ランタイムが消えた後のエコシステム

今回の件を単独の出来事として読みにくいのは、1年も経たない前例があるからだ。Bunのブログによれば、2025年12月2日にBunはAnthropicに買収された。その記事は、Claude CodeがBunの実行ファイルとして配布されており、Bunが壊れればClaude Codeも壊れるため、AnthropicにはBunを良い状態に保つ直接的な動機があると説明し、BunはMITライセンスのオープンソースとして残ると明言した。Denoの場合と決定的に違うのは、ランタイムそのものが買収側の製品サプライチェーンのど真ん中にあるという点である。Hacker Newsの wiseowise は、Bunもキラーアプリ（Claude Code）を見つけていなければ同じことが起きていただろうと述べた（直接の引用ではなく、コメントの要旨の要約）。

つまり二つの買収は、見た目は似ていても、ランタイムが担う役割が正反対だ。Bunは買収側にとって欠かせない部品だから生き残り、Denoランタイムは買収側がすでに代替物（workerd）を持っているから整理される。プラットフォーム企業に買収されたオープンソースのランタイムの運命は、ライセンスではなく、買収側の製品グラフの中での位置が決める。二つの事例を並べたときに見えてくるのは、このパターンである。

Wasmerの創業者である syrusakbary は、BunはAnthropicが持っていき、Denoはもう開発されないため、独立したNode系ランタイムはほとんど残っていないと懸念を示した。自社のEdge.jsを代替として挙げつつ、利害関係を自ら明かしている（直接の引用ではなく、コメントの要旨の要約）。利害のある発言ではあるが、指摘そのものは事実に基づいている。2018年以降Nodeの代替として真剣に語られてきた二つのランタイムが、いずれもこの1年のうちにプラットフォーム企業の傘下に入った。

では何が残るのか。第一に、コードである。Denoはオープンソースとして残り、Dahlは開発を引き継ぎたい人を歓迎すると書いた。しかしHacker Newsの theodorejb がまとめたように、誰かが引き継がなければDenoはもうサポートされない（直接の引用ではなく、コメントの要旨の要約）。（10月16日追記: Bushellはこの日の記事で、意味のあるコミュニティフォークが長く生き延びるかは非常に疑わしいと書いた。）大型ランタイムは、V8のアップグレード、セキュリティ対応、Node互換レイヤーの維持という終わりのない労働を要求する。「オープンソースとして残る」という文と「メンテナンスされる」という文は、同じ意味ではない。

第二に、Nodeに吸収されたアイデアである。sholladay は、初期のDenoがあまりに良かったのでNodeがいくつかの機能を取り入れ、結果としてより良いNodeが生まれたと述べた（直接の引用ではなく、コメントの要旨の要約）。Bushellの10月3日の記事がそれを裏づける。彼はNode v26.10.0で静的サイトジェネレーターを移行した際、Denoのファイルシステム APIを node:fs に、Deno.serve をHonoのNodeアダプターに置き換える程度で済み、最小限の移行だけでビルドが15%速くなったと報告している。同時に、Nodeが node_modules 配下のTypeScriptファイルについては型ストリッピングを拒否するという制約も記録した。Denoが最初から解いていた問題の一部は、依然としてNodeに残っているということだ。

第三に、JSRである。JSRはインフラをCloudflareに移して運営を続ける。しかしJSRの主な利用者だったDenoランタイムが1年後に開発を止めるなら、TypeScriptファーストのレジストリへの需要がどこから来るのかは開かれた問いだ。Bushellは3月の記事で、JSRはインフラ投資の不足に苦しんだと評し、10月3日の記事ではJSRの攻撃的な429レスポンスを離脱理由の一つに挙げた。Hacker Newsの chaosharmonic も、JSRが残る理由や標準ライブラリの開発が続くのかを問うたが、発表文はそこに答えていない。

最後にガバナンスである。Hacker Newsでは、VC投資を受けた瞬間にこの結末は決まっていた、という意見がいくつも出た。Bushellの3月の記事は、Deno Landが490万ドルのシードと2,100万ドルのシリーズAを調達したと整理し、その時点で社員の相当数が会社を去ったと書いている。これらの数字は彼の記事に引用されたもので、本稿で独自に検証してはいない。一方Nodeは、io.jsの分裂を経て財団ガバナンスに落ち着いた。Hacker Newsの bilalq は、io.js、Bun、Denoを経るたびにメインストリームのNode/npmスタックに留まる選択が毎回正しかったと見つつも、代替勢力がNodeを動かしたことは認めている（直接の引用ではなく、コメントの要旨の要約）。企業が所有するランタイムと財団が所有するランタイムの違いは、平時には見えず、企業の戦略が変わる日に一気に表面化する。

結論

Denoを使うチームにとっての実務的な結論ははっきりしている。Deno Deployの利用者には6か月、ランタイムの利用者には1年という期限ができた。有料のDeploy顧客にはWorkersへの移行支援が約束され、ランタイムの利用者にとっては、Bushellの報告どおりNodeへの移行が以前よりはるかに容易になった。ただし、Deno固有のAPI、パーミッションシステム、URLインポートに深く依存してきたコードなら話は別だ。Hacker Newsで sheept は、エージェント用のサンドボックスとしてDenoのパーミッションシステムを使っていたと述べたが、こうした用途はNodeですぐには置き換えられない。

より大きな問いは産業構造にかかわる。Cloudflareの選択は、汎用ランタイムではなくプログラミングモデルに賭けるものであり、そのモデルをCloudflareの外でも動かせるようにするという約束とともにやって来た。その約束が守られるなら、利用者はDenoというランタイムを失う代わりに、WorkersとDurable Objectsを自前のインフラで動かす手段を得る。守られなければ、独立ランタイムが一つ消え、プラットフォームが一つ厚くなっただけで終わる。

あなたのサービスが依存しているランタイムは、いま誰の製品グラフの上に置かれているのか。そのランタイムはその企業にとって欠かせない部品なのか、それともすでに代替物がある重複資産なのか。ライセンスファイルよりも、その問いのほうが多くを語るはずである。

出典: