JavaScript・TypeScriptの実行環境「Deno」の開発チームが、2026年10月9日にCloudflareへの合流を発表しました。Deno Deployは6か月後に終了し、ランタイムは今後1年間の保守を経て、現チームによる開発が終了する方針です。
Denoで作ったすべてのアプリが一斉に停止するわけではありません。Deployで公開しているなら移行準備が必要で、ランタイムだけを使っているなら保守終了後の更新体制が判断の軸になります。本記事では、利用状況別の影響と、移行先を選ぶための確認点を整理します。
Denoとは？ランタイム・Deploy・JSRの違い
Denoは、JavaScript・TypeScriptのプログラムを動かすソフトウェアです。Webアプリのサーバー側処理、API、開発用スクリプトなどに使われます。今回の発表では、次の3つを区別すると影響がわかりやすくなります。
- Denoランタイム：PCやサーバーでプログラムを実行するソフトウェア。
- Deno Deploy：アプリをクラウド上で公開・運用するホスティングサービス。
- JSR：JavaScript・TypeScriptのパッケージを公開・取得するレジストリ。
サービスが終了することと、実行環境の開発が終了することでは、必要な作業が違います。自分のアプリがどちらに依存しているかで、対応を分けて考えます。
Deployは運用終了、ランタイムは保守後に開発終了
Denoは2026年10月9日、チーム全体がCloudflareへ合流すると発表しました。今後はWorkersやDurable Objectsのチームと共通プラットフォームの開発に注力し、独立したランタイムとホスティングサービスの開発を続けない方針です。出典：Denoの公式発表。
| 対象 | 発表された継続期間・条件 | その後の扱い |
|---|---|---|
| Deno Deploy | 6か月間、運用を継続。終了の目安は2027年4月頃 | ホスティングサービスを終了 |
| Denoランタイム | 今後1年間、月次で不具合修正・セキュリティ更新。現チームの保守・開発終了の目安は2027年10月頃 | 同チームによる開発を終了。コードはオープンソースとして残る |
| JSR | 運用を継続 | インフラをCloudflareへ移す |
2027年4月頃・10月頃は、2026年10月9日の発表から相対期間を換算した概算です。公式に指定された終了日時ではありません。JSRは継続運用が発表されていますが、個々のパッケージの保守は各開発者・プロジェクトの方針によります。
V8をRustから利用するためのrusty_v8もサポートを継続し、workerdへの統合を目指すとされています。これはDenoランタイム全体の保守継続を意味しません。
自分の利用環境にはどんな影響がある？
| 利用状況 | 優先して確認すること |
|---|---|
| Deno DeployでWebサイト・APIを公開 | 終了までに別環境へ切り替える計画。公開URL、データ、認証、定期処理を洗い出す。 |
| 自社サーバーやPCでランタイムを使用 | 今回の発表で直ちに停止するわけではない。長期運用では保守終了後の修正の入手先・適用担当を検討する。 |
| JSRからパッケージを取得 | JSR自体は継続。利用するパッケージの更新状況と実行環境への依存を確認する。 |
| Denoで作られた外部サービスを利用 | 移行作業は通常サービス提供者側が担う。停止予定や利用者に必要な対応を提供者の案内で確認する。 |
両方を使うチームでは、継続期間が短いDeploy側の準備を先に進めるのが現実的です。これは上記の期限を踏まえた編集部の対応案です。
Deployの移行準備は、コード以外の依存先も整理する
Deploy利用者が用意したいのは、公開アプリの一覧と、各アプリが使うサービス機能・保持データ・利用者の操作をまとめた移行対象です。コードを移せても、必要なデータへアクセスできなかったり、ログインや保存が成立しなかったりすれば、公開サービスとしての切替は完了しません。
たとえば、移行先で試す対象を「起動できるか」だけでなく、「利用者がログインし、データを読み書きできるか」まで具体化すると、切替前に必要なテストが明確になります。これはDeployの運用終了方針を踏まえた対応案で、公式の移行手順ではありません。アプリごとに実際に使っている機能を対象にすることが前提です。
DenoはCloudflare Workersへ移る有料顧客に移行支援を提供するとしています。該当する担当者には、支援範囲を問い合わせながら移行先を評価できる選択肢があります。一方、無料利用者や別の移行先を選ぶ人への同等の支援は、この発表では示されていません。出典：公式発表の移行支援条件。
移行先の選び方：Workersでそのまま動くとは限らない
Cloudflare Workersは公式の移行支援対象ですが、コード・データ・運用条件を確認して選ぶ必要があります。次の表は選択肢を比較するための観点で、個別アプリの互換性や性能を検証した結果ではありません。
| 選択肢 | 確認するポイント |
|---|---|
| Cloudflare Workers | 有料顧客向け移行支援の範囲、Deno固有APIの置き換え、データ保存方式、実行制限と料金。 |
| Node.js対応のホスティング | 依存パッケージやフレームワークの対応、Deno固有機能の変更箇所、デプロイ・監視方法。 |
| Denoを動かせる別のサーバー | 既存コードを維持できる範囲、サーバー運用の負担、ランタイムの長期保守の担い手。 |
支援の詳細、移行費用や工数は未確認です。支援があることだけで、変更なしに移せる、費用が下がるとは判断できません。
Deno固有APIとNode.js互換性を分けて確認する
Deno.serve()、Deno.cron()、Deno.openKv()などを使う箇所は、移行先の機能にどう置き換えるかを確認します。たとえば定期実行では、WorkersのCron Triggersと実行ハンドラーへの変更を検討することになります。
CloudflareのNode.js互換性の資料では、互換日付が2026-08-04以降なら対応するNode.js API・ポリフィルを標準で利用できると説明されています。ただし、対応はNode.js APIの一部で、部分対応やインポートのみ可能なスタブもあります。Node.js互換性はDeno固有APIを含むアプリ全体の動作保証ではありません。
Deno KVとWorkers KVは名前が似ていても仕様が違う
Deno KVのトランザクションは、バージョン条件を確認しながら複数の更新をまとめて確定するアトミック操作に対応します。一方、Workers KVは結果整合性モデルで、変更が他の拠点の読み取りに反映されるまで60秒以上かかる場合があります。
そのため、在庫数や残高のように競合する更新の整合性が重要な処理を、Workers KVへ単純に置き換えると想定した動作を保てない可能性があります。公式資料は、より強い整合性が必要な場合にDurable Objectsを検討するよう案内しています。保存先は名称ではなく、必要なトランザクション・読み取り・同時更新の条件から選びます。
Deno Deploy利用者が準備したい5つのこと
以下は公式の移行手順ではなく、今回の終了方針と一般的なシステム移行を踏まえた確認項目です。
- 公開アプリを一覧化する：Webサイト・API、公開URL、独自ドメイン、業務上の重要度を整理します。
- 依存機能を調べる：
Deno.*API、Deno KV、Cron、環境変数、認証、外部API、パッケージ、フレームワークを記録します。 - データと設定を保全する：バックアップを取得し、移行先で復元できることを確認します。APIキーなどの機密情報は安全に再設定し、コードへ埋め込みません。
- 利用者の操作を再現する：起動だけでなく、ログイン、読み書き、同時更新、定期処理、外部通信をテストします。実行制限と料金も確認します。
- 切り替えと復旧を計画する：DNS、最終データ同期、監視、障害時の戻し方を決めます。戻す場合も、切り替え後に増えたデータの整合性を確認します。
ランタイム単独利用者は、更新を誰が担うかを決める
自社サーバーや開発端末でDenoを使い、Deployには依存していない人は、ホスティング終了だけを理由に稼働場所を変える必要はありません。今回関わるのは、月次保守が終わった後も、必要な修正を受け取れる運用をどう維持するかです。
公式発表は、コードをオープンソースとして残し、他者による開発継続を歓迎するとしています。ただし、これは将来の保守担当や更新提供が決まったという案内ではありません。既存コードの存続と、継続的なセキュリティ更新は分けて扱う必要があります。
準備として役立つのは、依存するDeno API・パッケージと、ビルド・テストの手順を整理することです。現在の環境を維持する場合は修正の入手先と適用担当を、別の実行環境へ移す場合は同じテストが通るかを評価する材料になります。
この整理は、既存アプリを継続運用する担当者に向く進め方です。一方、長期の更新提供が必須の新規案件では、コードが残ることだけを採用理由にせず、保守体制を説明できる環境を選ぶ必要があります。本記事では代替環境との互換性や性能を検証しておらず、すべての利用者へ即時移行を勧めるものではありません。
Cloudflare合流で、今後どこへ開発を向けるのか
Cloudflare側の発表では、DenoチームのcelldとWorkersのオープンソース実行環境workerdのコード・設計を統合し、WorkersやDurable Objectsを自社インフラでも運用しやすくする方針が示されています。分散処理や状態保持を含むアプリの基盤に注力する計画です。この開発方針と、既存Denoアプリの互換性・長期保守は分けて判断する必要があります。
よくある疑問
DenoをPCにインストールしているだけなら、今すぐ削除すべき？
今回の発表でローカルの実行環境が直ちに使えなくなるわけではありません。利用目的、更新の必要性、依存関係を確認し、保守期間中に継続利用の方針を決めます。
JSRのパッケージも使えなくなる？
JSR自体は運用継続が発表されています。個別パッケージの保守やDenoへの依存は、それぞれ確認してください。
Deploy Classicの終了と同じ話？
別の案内です。Deploy公式ドキュメントでは旧サービスDeploy ClassicとSubhosting v1 APIの終了日を2026年7月20日と案内しています。今回の6か月間の継続方針は10月9日の発表によるものです。古い移行ガイドを読むときは、対象サービスと公開日を確認してください。
対応の優先順位
2026年10月11日（日本時間）更新：Deno・Cloudflareの公式発表と公式技術資料を照合し、終了時期の概算、利用状況別の影響、移行時のAPI・データ保存の注意点を追記しました。個別アプリの移行試験は行っていません。
Deployを使うチームは、まず切替前に成立させる操作を移行テストの項目にしてください。ランタイム単独利用者は、保守期間中に更新の入手先と適用責任を決められるかを、継続利用の条件にすると対応が具体的になります。
コメント