ニュースの概要
Cloudflareが、JavaScriptやTypeScriptの実行環境（ランタイム）であるDenoを買収したと報じられた。Node.jsの生みの親として知られるRyan Dahl氏と、Denoチームの一部が、Cloudflare WorkersやDurable Objectsの開発に加わるという。Denoのランタイムは当面およそ1年間、不具合の修正とセキュリティパッチを受けながら維持され、その後はCloudflareのオープンソース基盤であるworkerdなど既存の仕組みとの統合が進む見通しとされる。ただし、報道には二次的な情報も含まれる。買収条件や組織の詳細、Deno製品の長期的な扱いは、公式発表で確認する必要がある。
引用元: Node.js開発者がCloudflareに参加、Deno買収でWorkers基盤を強化（The Register）
分析・見解
実行環境の競争は、道具選びから基盤選びへ移った
Denoは、Node.jsを作ったRyan Dahl氏が2018年に発表した実行環境である。Node.jsの設計への反省から、権限を絞った安全な実行、TypeScriptの標準対応、Web標準の機能を重んじる方針を打ち出した。技術的な評価は高かった。それでも多くの企業はNode.jsで資産を積み上げており、乗り換える理由は弱かった。
一方、Cloudflare Workersは、世界中の拠点でプログラムを動かす仕組みである。サーバーの管理をほとんど意識せずに済み、ここでもWeb標準の作法が重視される。Denoとは考え方が近い。ランタイムを単体で育てるより、動かす場所とセットで育てたほうが価値を出しやすい。今回の報道は、その流れを象徴している。
相性は良いが、統合の中身はまだ見えない
Cloudflareのworkerdは、Workersの中核をオープンソースにしたものだ。Denoの強みであるNode.js互換の改善、TypeScript周りの扱い、権限を細かく管理する考え方は、workerdに生かせる可能性がある。Durable Objects（＝状態を覚えたまま動く小さなサーバー）の開発にDahl氏らが関わる点も興味深い。リアルタイムの共同編集やオンラインゲームのように、状態の管理が難しい分野で道具立てが厚くなるかもしれない。
ただし、Denoの実行モデルとworkerdは別物である。どこまで統合し、何を終わらせるのかは、現時点で公表された範囲では分からない。「統合」という言葉の幅は広く、機能の吸収だけで終わる可能性もある。
小さな実行環境が大手に入る流れは珍しくない
過去にも似た動きはあった。2020年にはnpmがGitHub、つまりMicrosoftの傘下に入った。Svelteの作者Rich Harris氏はVercelに加わり、開発を続けている。共通点は、個人や小さな会社が生んだ道具が、クラウド事業者の競争力の一部として取り込まれることだ。
ここに一つの見方を加えたい。実行環境そのものは無料で配られ、収益は動かす場所から生まれる。だから、優れたランタイムほど、独立して稼ぐより大手の基盤に溶け込むほうが合理的になりやすい。Denoの買収は技術の敗北ではなく、収益の構造に合わせた着地と読める。
約1年の維持期間は、猶予であって保証ではない
Denoが約1年は修正とセキュリティパッチを受けるとされる点は、利用者にとって安心材料だ。しかし裏を返せば、その先の保証はない。オープンソースなので、コミュニティによる派生や継続の可能性は残る。それでも、中核の開発者が別の基盤に移れば、更新の速度や互換性の質は下がりかねない。
ビジネスへの影響
Denoを使うチームは、1年を区切りに棚卸しを始める
自社でDenoを使っている場合は、まず使い方を三つに分けたい。社内ツールや小規模な処理、Deno Deployなど同社のホスティングに依存したサービス、そして製品の中核に組み込んだ部分である。影響が大きいのは後ろの二つだ。ホスティングの扱いは報道だけでは分からないため、料金や提供期間の発表を待つ必要がある。
棚卸しでは、Deno固有の機能にどれだけ頼っているかを確認する。標準ライブラリや独自の依存の読み込み方式を多用しているなら、Node.jsやWeb標準へ戻す作業量を見積もっておく。見積もりだけでも、1年後の選択肢は広がる。
Node.js中心の企業も、エッジ実行の選択肢を見直す好機
Node.jsを使う企業にとっても無関係ではない。Workersでの動作互換が強まれば、既存のNode.js資産を世界各地の拠点で動かしやすくなる。表示速度が売上に直結するECや、地域ごとに応答を変える広告配信では、検討の価値がある。ただし、期待だけで移行を決めてはいけない。小さな機能を一つ試験的に載せ、遅延、料金、障害時の挙動を測るのが堅実だ。
運営元が変わっても困らない設計と選定基準を持つ
今回のように、使っていた道具の運営元が変わることはある。対策は、特定の実行環境に固有の書き方を一か所に集めることだ。入出力の部分を薄い層で包めば、将来の移行費用を抑えられる。調達の場面では、ソースの公開状況、更新の頻度、サポート終了時の通知条件を確認項目に入れたい。意思決定者は『人気があるか』より『運営が続く仕組みか』で選ぶと、後の手戻りが少ない。
