2026年10月9日、JavaScript／TypeScriptの実行環境「Deno（デノ）」を作ってきたチームがCloudflareに合流すると発表されました。あわせて、Denoの開発は約1年後に終わり、ホスティングサービス「Deno Deploy」は約6か月後に止まる予定だと案内されています。名前を聞いたことがない方がほとんどだと思いますが、開発会社が裏側で使っていることがあります。
「開発会社が使っている技術のサービスが終わるらしい。うちのシステムは大丈夫なのか、誰に何を聞けばいいのか分からない」
先に結論をお伝えします。ほとんどの発注者にとって、今日すぐ何かが止まる話ではありません。ただし「自社のシステムがDenoやDeno Deployを使っているか」は、今のうちに開発会社へ確認しておく価値があります。使っていなければ何もしなくて構いません。使っているなら、半年〜1年という期限の中で、移行の担当・費用・時期を決める必要があります。
この記事は2026年10月13日時点の公開情報に基づいています。技術の仕組みには踏み込まず、発注・運用・費用への影響に絞って整理します。
ニュースの要点（2026年10月13日時点）
何が発表されたか
発表の主な内容は次のとおりです（Deno社・Cloudflare社それぞれのブログと、複数の報道による）。
| 項目 | 発表・報道されている内容 |
|---|---|
| 合流 | Denoのチームが米Cloudflareに合流する。Node.jsとDenoの生みの親であるRyan Dahl氏らが、Cloudflareの実行基盤「workerd」を自社サーバーでも動かしやすくする取り組みを進める |
| Denoランタイム（実行環境本体） | 約1年間は、月ごとの不具合修正とセキュリティ修正が続く。その後、Denoチームによる開発は終了する。コードはオープンソース（MIT）のまま公開され、他の人が引き継ぐことはできる |
| Deno Deploy（ホスティング） | 約6か月後に停止する予定。有料の利用者にはCloudflare Workersへの移行支援がある。正確な停止日は、執筆時点では公表されていない |
| JSR（パッケージ置き場） | 引き続き運用される |
| 買収の金額・条件 | 公表されていない |
📰 出典：Deno「Deno is joining Cloudflare」
📰 出典：Cloudflare Blog「Deno is joining Cloudflare」
なお、「買収」と呼ぶ報道もあれば、「チームの合流」と書く報道もあり、表現は分かれています。この記事では公式の表現に合わせて「合流」とします。細かい日程や対象サービスは今後更新される可能性があるため、判断の前に上記の公式ブログで最新の内容を確認してください。
発注者にとって何が変わるか／変わらないか
ここからは筆者の見解です。
変わらないこと
- Denoを使っていないシステムには、直接の影響はありません。 日本の業務システムやWebサイトでは、Node.js、PHP、Python、Rubyなどで作られているものが大半で、Denoは少数派です。
- 今日・明日にシステムが止まるわけではありません。 ランタイムは約1年間、セキュリティ修正が続く予定です。
変わること
- Deno Deployで動かしているシステムは、約6か月後までに引っ越し先を決める必要があります。 引っ越し作業は開発会社の作業になるため、費用と時期の話し合いが発生します。
- Denoで作っているシステムは、1年後以降の保守方針を決める必要があります。 開発元の更新が止まったあとも、オープンソースとして他の人が引き継ぐ可能性はあります。ただ、誰がどこまで面倒を見るかは今のところ決まっていません。
- 「その技術は将来も続くか」を確認する習慣が必要になります。 今回のように、人気のある技術でも、提供元の方針で突然期限が切られることがあります。
開発会社を責める話ではありません
開発会社がDenoを選んだ時点では、これは合理的な選択でした。技術の継続性は誰にも完全には予測できません。大切なのは、「使っていた」ことより「知ったあとに計画を立てているか」です。
今やるべきこと・まだ様子見でいいこと
| 状況 | やること |
|---|---|
| Denoを使っていないと確認できた | 何もしなくて構いません。確認した日付を記録しておく程度で十分です |
| Deno Deployで動いている | 今月中に開発会社へ移行の計画（移行先・費用・時期・誰が負担するか）を相談する。停止日が正式に決まったら、そこから逆算して日程を置く |
| Denoで作っているが、ホスティングは別の会社 | 慌てなくて構いません。1年以内に保守方針（そのまま使い続ける／別の技術へ移る）を決める。次の保守契約の更新時に議題へ入れると進めやすくなります |
| 使っているか分からない | まず開発会社に聞く。聞く相手は保守の窓口担当者で十分です |
様子見でよいのは「Denoの今後の引き継ぎ先がどうなるか」です。オープンソースの引き継ぎや、代わりの選択肢の動きは、半年ほどで見えてくる可能性があります。
発注者がやることチェックリスト
- ☐ 自社のシステムの一覧を出し、それぞれが「何の技術で作られ、どこで動いているか」を開発会社から聞いた
- ☐ 「Deno」「Deno Deploy」という名前を、開発会社に挙げて使用の有無を確認した
- ☐ 使っている場合、移行の費用が保守契約の範囲に入るか、別途見積もりになるかを確認した
- ☐ 使っている場合、停止日（公式の発表）に対する移行の予定日を決めた
- ☐ 提供元の終了・変更のお知らせを、誰が見て、誰に伝えるかを決めた
- ☐ 今後の新規開発では、使う技術の「継続性（更新が続いているか、運営が複数あるか）」を提案時に説明してもらうことにした
開発会社への質問例
打ち合わせやメールで、そのまま使える形にしています。
- 「先日発表されたDenoの開発終了とDeno Deployの停止について、うちのシステムは使っていますか。使っていない場合は、その根拠も教えてください」
- 「使っている場合、移行先の候補と、おおまかな作業量・期間・費用の目安を教えてください。また、その費用は保守契約に含まれますか」
- 「提供元のサービス終了や開発終了の知らせを、御社ではどなたがいつ確認し、いつ私たちに連絡する決まりになっていますか」
- 「今回の件に限らず、うちのシステムが使っているサービス・ライブラリのうち、更新が止まる可能性があるものを一覧にしてもらえますか」
- 「新しい提案では、使う技術について、いつまで更新が続く見込みか、終了した場合の移行先はどこかを、一言でも添えてもらえますか」
今回のニュースから学べること
- 技術選びは「今人気か」だけでなく「終わったときに移れるか」も見る。 標準的な仕様に沿った技術なら、引っ越しの負担は比較的小さく済みます。
- 保守契約には「提供元の終了時の対応」を書く。 誰が気づき、誰が計画し、費用は誰が持つか。決めておくと、今回のような場面で揉めません。
- 確認は「聞くだけ」で十分。 専門知識がなくても、使っているかどうかを聞くだけで、半年後の慌ただしさは大きく減ります。
まとめ
Denoの開発終了とDeno Deployの停止予定は、ほとんどの発注者には直接関係しません。ただ、自社のシステムが対象かどうかは、今のうちに開発会社へ一度聞いておくと安心です。使っていた場合は、停止までの半年、開発終了までの約1年を使って、移行の担当・費用・時期を決めましょう。
今回のように「技術の提供元の方針で、使っていたものに期限が付く」ことは、今後も起こり得ます。確認の仕組み（誰が見るか、誰が費用を持つか）を契約に入れておけば、次に同じことが起きても慌てずに済みます。
あわせて読みたい関連記事
