Deno 2.9 の deno desktop とツールチェーン統合を運用者目線で読む

Deno 2.9 は「Node の資産を取り込む all-in-one」に舵を切った

2026 年 6 月 25 日にリリースされた Deno 2.9（07-01 に 2.9.1 が続きました）は、単体で速くなっただけでなく、既に Node と npm で回っている現場を丸ごと引き受ける方向へ寄せてきたバージョンです。デスクトップ配布、既存 lockfile の取り込み、テスト分散が一度に入りました。

私は普段、Rails の API サーバと Next.js のフロントを Docker で回しています。ランタイムを乗り換えるかどうかは、機能表よりも「今の資産をどれだけ捨てずに済むか」で判断します。2.9 のリリースノートを運用者の目で読むと、その「捨てなくていい範囲」がはっきり広がっていました。

数字も無視できません。冷間起動は 2.8 の 34.2ms から 17.3ms へ、Deno.serve の実測スループットは 56.8k req/s から 72.4k req/s へ、ピーク RSS（常駐メモリ）は 142MB から 64MB へ改善したとされています。速さの話は他でも語られるので、この記事では運用で効く 4 つの変更に絞ります。

deno desktop — Electron を省いて配布まで一気通貫

deno desktop は、Web フレームワークのアプリを Electron のボイラープレートなしで単一バイナリのデスクトップアプリに変えるコマンドです。運用者にとっての価値は「配布物の面倒を Deno 側に寄せられる」点にあります。

使い方は素直で、deno desktop . を叩くとカレントのフレームワークを自動検出します。Next.js / Astro / Fresh / Remix / Nuxt / SvelteKit / SolidStart / TanStack Start / Vite SSR が対象です。開発中は deno desktop --hmr で HMR（変更を再起動なしに反映する仕組み）が効きます。

配布ターゲットが揃っているのが実運用では効きます。macOS は .app / .dmg、Windows は .exe / .msi、Linux は .AppImage / .deb / .rpm を出せて、--all-targets なら一発で全プラットフォーム分をビルドできます。既定のバックエンドは OS 内蔵エンジンを使う webview（Windows は WebView2、macOS と Linux は WebKit）で、レンダリングを全環境で揃えたいときだけ --backend cef で Chromium を同梱します。

ここは判断が分かれる部分です。webview 既定はバイナリが小さくなる代わりに、OS ごとのレンダリング差を自分で吸収する必要があります。私は社内配布ツールなら webview、顧客に配る製品なら cef、と線を引くつもりです。Electron 一式を保守してきた身としては、この選択肢が公式に入ったこと自体が朗報でした。

deno.lock を既存 lockfile から seed できる

deno install が package-lock.json / pnpm-lock.yaml / yarn.lock / bun.lock を読み、再解決なしで deno.lock を生成できるようになりました。地味ですが、移行を検討する運用チームには一番大きい変更です。

lockfile を作り直すという行為は、依存の正確なバージョンと integrity ハッシュ（改ざん検知用の指紋）が変わり得るということです。移行のたびに「本当に同じものが入ったのか」を疑う作業が発生していました。2.9 は既存 lockfile の厳密なバージョンとハッシュをそのまま deno.lock に転写するので、その疑いを一段減らせます。

npm / pnpm / yarn / bun のどれで管理していても入口になる、というのも実務的です。私のまわりでも pnpm と yarn が混在していて、片方しか受けないツールは検証段階で脱落しがちでした。「まず既存の lockfile を食わせて差分を見る」という安全な入り方ができるのは大きい。ランタイム移行の温度感は、少し前に追ったNode.js 26.2 の変更のときと近いものがあります。

deno test の shard・Deno.test.each・snapshot が CI を軽くする

テスト周りは --shard、Deno.test.each()、組み込み snapshot の 3 点が運用に直結します。CI のマシン時間をそのまま削れる変更だからです。

deno test --shard=<index>/<count> はテストファイルを CI の複数マシンに分散します。追加のプラグインなしでシャーディング（分割並列実行）が入るので、これまで外部ツールで組んでいた分散を素の Deno に寄せられます。Deno.test.each() は入力テーブルから独立してフィルタできるテストを生成し、名前テンプレートに %s / %i / %f / %j を使えます。組み込み snapshot（初回に出力を記録して次回以降と差分比較するテスト）は t.assertSnapshot() で __snapshots__/ に書き出し、deno test --update-snapshots で更新します。

地味に効くのが --changed（変更に影響するテストだけ走らせる）、--retry=N（flaky なテストを再試行）、--repeats=N（安定性の確認）です。CI を運用していると、落ちるのはコードよりも「たまに落ちるテスト」であることが多い。--retry を標準で持てるのは、深夜に赤くなった CI を眺める回数を確実に減らします。私のコードは落ちませんが、私の書いたテストはたまに落ちるので、この機能には正直救われました。

Happy Eyeballs と Web Locks — 地味だが障害時に効く土台

ネットワークと排他制御の土台も更新されました。Deno.connect の Happy Eyeballs と navigator.locks の Web Locks は、派手さはないものの障害時に効く種類の改善です。

Deno.connect と Deno.connectTls が Happy Eyeballs v2（RFC 8305、IPv6 と IPv4 を並行接続して速い方を採る手法）を実装し、デュアルスタック環境で両アドレスを競争させます。既定で有効で、切りたいときは autoSelectFamily: false、詰めたいときは autoSelectFamilyAttemptDelay（既定 250ms）で調整します。IPv6 だけが遅い環境で接続がもたつく、という運用でありがちな症状に効きます。

Web Locks API（navigator.locks、タブ間やプロセス間で排他ロックを取る Web 標準）も入りました。排他 / 共有モード、ifAvailable、steal、AbortSignal、navigator.locks.query() に対応します。同じジョブが二重に走るのを防ぐ、といった処理をランタイム標準の作法で書けるのは、独自ロックを持ち回るより保守が楽です。

運用チームとしてどこから触るか

結論として、Deno 2.9 は「今すぐ全面移行」ではなく「既存資産を壊さずに一部から試せる」バージョンです。私なら lockfile seeding から入ります。

理由は、リスクが最も小さいからです。deno install に既存の lockfile を食わせて差分を見るだけなら、本番にもコードにも触れません。そこで違和感がなければ、次は CI の一部ジョブを deno test --shard に置き換えてマシン時間の実測を取ります。デスクトップ配布は要件が出てから、が私の順番です。

一つ注意点を書いておくと、2.9 は 2026-06-25 のリリースで 2.9.1 が 07-01 と間隔が短く、機能が厚いぶん初期の細かい修正は続く前提で見たほうが安全です。all-in-one 化は歓迎ですが、運用者の仕事は「新機能を数える」ことではなく「壊れない範囲を見極める」ことなので、入口を小さく取るのが結局いちばん速いと私は考えています。