Deno が Cloudflare に参加：TypeScript ランタイム、celld、AI エージェント向けエッジ基盤

2026年10月9日、Deno の創設者である Ryan Dahl 氏は、公式ブログに「Deno is joining Cloudflare」と題する記事を公開し、Deno チーム全体が Cloudflare に参加すると発表した。最初に明確にしておきたい点がある。私たちが読めたブログの抜粋は方向性を述べているだけで、取引金額、出資の取り決め、製品の継続時期、オープンソースプロジェクトの運営体制が変わるかどうかについては何も書かれていない。そこで本稿では、公表された事実と、業界の一般的な知識に基づく分析とを分けて記述する。分析の部分はそのつど明示する。この種のニュースは過大に読まれやすく、区別が欠かせないからだ。

まず、Dahl 氏自身の語り方を見ておこう。同氏によれば、Deno は長年にわたり、サーバーソフトウェアの構築をより簡単にしようと取り組んできた。モジュールをどう配布するのか、JavaScript ランタイムはどのような安全性の保証を提供できるのか、完全なツールチェーンには何が含まれるべきか、アプリケーションをどれだけ簡単に単一の実行ファイルとして配布できるのか、といった問いである。Node.js との互換性も重要な要素になった。利用者は Deno の改良点を求めつつ、既存の JavaScript エコシステムにも接続し続けたかったからだ。チームとコミュニティはこれらの機能を一つにまとめたランタイムを作り、JavaScript 開発のあるべき姿についての前提に疑問を投げかけた、というのが同氏の説明である。この列挙は、Deno の製品上の具体的な選択に対応している。権限モデルが安全性に、JSR がモジュール配布に、組み込みツールチェーンが完全性に、単一ファイルへのコンパイルが単独実行ファイルに、npm 互換層がエコシステムとの接続に、それぞれ当たる。

より情報量が多いのは、その次の段落である。Dahl 氏は、自分たちの野心は常にランタイムの外にあったと述べる。以前の「JavaScript コンテナ」に関する記事で、計算、ストレージ、通信が、アプリごとに基盤を組み立てることなく連携して動くべきだと書いたという。Deno Deploy はその目標に向けた一歩で、アプリケーションの実行をできるだけ素直にすることを狙っていた。ただ、Deploy を作り運用する中で、開発者体験の下にどれほど多くの複雑さが残っているかも見えてきた。同氏はその層も単純にしたいと考え、celld に至った。説明によれば、celld は Cloudflare Workers のプログラミングモデルを土台にし、開発者が最初から分散アプリケーションを構築できるようにしつつ、システムの運用を簡単にする。同氏が最も期待しているのは、スケーリングが各アプリの組み立てる基盤ではなく、プログラミングモデルに組み込まれている点である。抜粋は「Deno から Deno への歩み」という一文で途切れており、続きは確認できていないため、推測はしない。

以下は業界の文脈に置いた分析であり、発表内容そのものではない。第一に、Cloudflare Workers のモデルは、世界中のエッジ拠点で軽量かつ分離された JavaScript と TypeScript のコードを動かす。Deno チームが長年扱ってきたのは同じ系統の言語とランタイムの問題であり、両者の技術的な道筋はもともと近い位置にあった。第二に、Deno の公式サイトの製品一覧には、信頼できないコードを安全な Linux 仮想マシンで実行する Deno Sandbox（AI エージェント向けに作られている）と、エージェント向けのオープンソースのセキュリティファイアウォールである Claw Patrol がすでに載っている。エージェントが自らコードを書いて実行するようになると、そのコードをどこで安全に動かすかが新しい基盤要件になる。エッジ網は、利用者やデータの近くに分離された実行環境を置く場所として自然である。第三に、安全なデフォルトで知られるランタイムと、世界規模のネットワークと開発者向けプラットフォームを持つ企業との組み合わせは、筋の通った物語になっている。

一方で、疑問符として残すべき点もある。一つ目はガバナンスである。Deno のオープンソースランタイム、Fresh フレームワーク、JSR レジストリが現在の運営と中立性を保つのかどうか、抜粋は答えていない。特に JSR は TypeScript を第一に考えたパッケージレジストリで、複数のランタイムから使われるため、その帰属はエコシステム全体にとって敏感な問題になる。二つ目は重複である。Deno Deploy と Cloudflare 自身のサーバーレス製品は位置づけが重なっており、統合されるのか、併存するのか、徐々に収束するのかは続報次第である。三つ目は celld そのものだ。ブログでは言及されたプロジェクトにとどまり、API、公開時期、既存の Workers 製品との関係は抜粋に記載がない。すでに使える製品として評価すべきではない。

開発者にとって、現段階でもっとも無難な読み方は、移行の合図ではなく方向性の信号として受け取ることである。エッジ基盤は、ランタイム、サンドボックス、分散状態を一つのプログラミングモデルにまとめつつあり、TypeScript はその共通言語になっている。Deno Deploy、Subhosting、企業向けサポート契約に依存しているチームは、サービス継続についての明確な説明を待つべきだ。オープンソースのランタイムだけを使っているチームは、ライセンス、リリースの頻度、メンテナー体制の変化に注目するとよい。業界の観察者にとっては、このニュースの重みは金額ではなく方向にある。Node.js の路線に挑戦したことで知られたプロジェクトが、次の一歩をインフラ企業のプラットフォームの内側に置く選択をした。これがエコシステム統合の成熟なのか、独立したランタイムの空間が狭まる兆しなのかは、今後数四半期のリリースと運営の詳細によって確かめるしかない。