CloudflareにDenoチームが合流　開発停止・サービス終了方針を発表

ニュースの要点

ソフトウエア実行基盤「Deno」の開発チームと米Cloudflareは2026年10月9日、Denoの全チームがCloudflareに加わると発表しました。開発資源を共通基盤に集中させるため、アプリケーションを複数の場所で動かす仕組みを一緒に開発します。取引価格や持分の扱いは公表していません。

Deno側は、自社の実行基盤を今後1年間、月次の不具合修正とセキュリティ更新で支え、その後は当チームによる開発を終了する方針です。運用サービス「Deno Deploy」は6か月後に終了し、有料顧客のCloudflare Workersへの移行を支援します。公開されたDenoのコードは残り、ソフトウエア配布の仕組み「JSR」も基盤を移して継続します。

ニュース出典：Deno／原題：Deno is joining Cloudflare／公開日：2026年10月9日／Denoの公式発表を読む

共同発表：Cloudflareの説明を読む

---

イノベーション総研の考察

今回の統合は、作り手には開発を集中する機会、使い手には基盤を見直す期限をもたらします。すべての製品が終了するわけではありません。何が残り、誰が保守し、どこで動かすのかを分けると、新規事業で外部サービスを選ぶ際の判断材料になります。

自前の実行基盤から、アプリの運営全体へ開発を集中する

Denoは、JavaScriptなどのプログラムを実行する基盤です。実行基盤だけがそろっても、サービスを大きくするには、データの保存、通信、複数のサーバーへの処理の分担などが必要になります。作り手は、それぞれをつなぐ運用を用意しなければなりません。

今回の当事者は、Deno、運用サービスDeno Deploy、自社運用用のcelldという開発の経緯を説明しています。Cloudflare側は、公開しているworkerdに、複数機器で動くための機能や周辺支援が不足していたと認めています。得意分野を合わせる判断であり、すでに統合が完成したという発表ではありません。

統合の狙いは製品数を増やすことではなく、利用者が組み合わせる作業を減らすことにあります。

読者が技術事業の提携や統合を考えるなら、機能一覧より、顧客が何に時間を使っているかを調べてください。各製品が優れていても、接続や運営が難しければ採用されにくくなります。ただし、今回の統合で実際に工数が減るかは、完成後の利用条件と運用実績で確認する必要があります。

一つの統合でも、利用者には異なる移行期限が生まれる

今回、Denoの実行基盤とDeno Deployでは、対応の時間軸が異なります。前者は約1年の保守を経て当チームの開発が止まり、後者は約6か月で運用サービスが終わる方針です。公開コードが残ることと、現在のサービスが動き続けることは同じではありません。

利用中の機能ごとに、終了するもの、保守だけ続くもの、そのまま継続するものを分けます。

Deno Deployで稼働させているサービスなら、実行するプログラムだけでなく、保存データ、外部接続、監視、契約、課金の移行を考える必要があります。Denoの公開コードを自社で動かしている場合は、開発終了後に誰が不具合や脆弱性へ対応するかが課題です。

新規事業の責任者は、まず自社がどの製品をどう使っているかを一覧にします。告知された期間から日付を一律に推定せず、確定終了日や対象機能を提供者に確認します。同じ会社の製品だからといって、すべて同じ日に切り替える必要があるとは限りません。

公開コードと、保守・運営の引受先は別に確認する

ソースコードが公開されていれば、自社や外部の開発者が引き継げる余地はあります。しかし、公開されていることだけで、更新担当者、支援窓口、稼働保証が確保されるわけではありません。自社運用に移れば、これまで提供者が担った仕事が利用者側へ移る可能性があります。

基盤を選ぶときは、移せるかだけでなく、移した後の保守を誰が担うかを確認します。

Cloudflareは、自社以外でも動かせる仕組みが顧客の採用判断に関わると説明しています。この説明は、利用者に出口を用意する事業上の意味を示します。ただし、移せるコードがあることと、現在と同じ品質・費用で移せることは別です。

担当者の方は、試験環境で切替を試し、必要な改修、操作手順、支援費用を記録できます。新しい基盤で機能が不足するなら、代替実装の費用も必要です。価格だけで比べず、運営を続ける担当者と費用まで含めれば、公開コードを残す選択が自社に合うかを判断しやすくなります。

開発の効率化と、既存顧客の切替負担を同時に評価する

統合で開発資源を集中できても、既存顧客が安心して使い続けられなければ、事業上の価値は失われる可能性があります。今回、Denoは有料顧客の移行支援を示していますが、改修の範囲、費用、互換性、個別契約の条件は確認できていません。

事業統合の評価には、自社が省ける開発費と、顧客へ移る切替費用の両方が必要です。

提供者の立場では、終了を知らせるだけでなく、移行手順、試験環境、問い合わせ先、対応期限を明確にすることが重要です。利用者の立場では、期限内に移す計画と、切替が遅れる場合の選択肢を用意します。統合先への移行以外に、自社運用や他の基盤も比較対象になります。

次の観測点は、統合基盤の提供予定が具体化するか、顧客が必要とする機能と支援条件が示されるかです。今回の発表段階では、買収価格から投資効果を計算したり、統合が完了したと評価したりすることはできません。

まとめ

Denoチームの合流は、共通基盤への開発集中と、既存製品の終了・継続を組み合わせた判断です。読者は製品ごとの期限、データ移行、保守の引受先を確認する必要があります。提携や統合を企画する側にも、顧客の切替負担を最初から事業計画へ入れるという示唆があります。