---
title: "DenoとFreshの開発環境セットアップ｜インストール・権限設計・LTS選定【2026年8月版】"
url: "https://www.issoh.co.jp/tech/details/4646/"
published: 2024-12-25
updated: 2026-10-13
categories: ["Node.js"]
publisher: "株式会社一創"
---

# DenoとFreshの開発環境セットアップ｜インストール・権限設計・LTS選定【2026年8月版】

Denoの環境構築でつまずくのは、どのインストーラを選ぶか、どの版に固定するか、実行時にどの権限を許可するかという判断です。この記事では2026年8月時点の最新安定版v2.9.5を前提に、OS別のインストールコマンドからLTSの選び方、権限フラグの設計、Node.js資産の持ち込み範囲、Fresh 2でのプロジェクト作成までを公式ドキュメントとインストーラの実体に沿って組み立てます。Freshというフレームワーク自体の設計思想は[Deno Freshとは｜Preactとアイランドアーキテクチャの軽量Webフレームワーク【Fresh 2対応・2026年版】](/tech/details/3619/)で扱っているため、ここでは手を動かす部分だけを追います。

## まとめ：インストーラは公式スクリプト、版はLTS、Freshは初期化コマンド1行

結論を先に置きます。DenoはmacOSとLinuxなら`curl -fsSL https://deno.land/install.sh | sh`、WindowsならPowerShellで`irm https://deno.land/install.ps1 | iex`で入ります。npm経由も動きますが公式が起動時間の理由で推奨しておらず、Ubuntu・Debianに至ってはaptの公式リポジトリどころか標準リポジトリにdenoパッケージ自体がありません。

業務で使うなら版はチャネルで決めます。2026年8月時点のLTSは2.9系（v2.9.3以降）で、維持期限は2027年1月31日と公式に明示されています。Freshのプロジェクトは`deno run -Ar jsr:@fresh/init`のウィザードで生成でき、Fresh 2からはViteプラグインとして動く構成に変わりました。以下、それぞれの手順と根拠を順に見ていきます。

## Denoの基本：TypeScriptを直接実行する単一バイナリのランタイム

Denoは外部依存を持たない単一の実行ファイルとして配布され、macOS・Linux・Windowsのx64とarm64で動きます。Node.jsの作者であるRyan Dahl氏が設計し直したランタイムで、綴りの`deno`は`node`のアナグラムです。

環境構築の観点で効いてくる違いは2つあります。ひとつはTypeScriptをそのまま実行できることで、tsconfig.jsonもトランスパイル手順も用意せずに`deno run app.ts`が通ります。もうひとつが権限モデルです。フラグで許可しない限り、実行されたコードはファイルにもネットワークにも触れません。実行エンジンはNode.jsと同じV8で、この共通部分の仕組みは[V8 Isolateとは？仕組み・Contextとの違い・サーバーレスでの活用を徹底解説](/tech/details/12608/)にまとめています。

## Denoのインストール：OS別コマンドと事前に要るもの

公式が第一に案内しているのはインストールスクリプトです。macOSとLinuxはシェル、WindowsはPowerShellで実行します。

```
# macOS / Linux
curl -fsSL https://deno.land/install.sh | sh

# Windows (PowerShell)
irm https://deno.land/install.ps1 | iex

# 導入後の確認
deno --version
```

シェル版のインストーラには前提が1つあります。スクリプトは配布物のzipを展開するため、冒頭で`unzip`と`7z`の有無を確認し、どちらも無ければ「either unzip or 7z is required to install Deno」と表示してその場で終了します。最小構成のUbuntuや多くのDockerベースイメージ、CIランナーはこれに該当するので、先に`sudo apt-get install -y unzip`を通してください。PATHへの追加はインストーラが既定で行います（無効化する`--no-modify-path`が用意されている＝既定は追加する側）。

パッケージマネージャからも入ります。macOSはHomebrewとMacPorts、WindowsはScoop・Chocolatey・winget、Linuxを含むクロスプラットフォームではNix、asdf、vfoxが公式ドキュメントに載っており、Rust環境があれば`cargo install deno --locked`でも導入できます。`npm install -g deno`も動きますが、公式は「npm経由で入れるとdenoコマンドの起動時間に影響が出る」と明記し、シェルまたはPowerShellのインストーラを推奨しています。Windowsは IsWow64Process2 に依存するため、Windows 10 バージョン1709またはWindows Server 2016 バージョン1709以降が必要です。

### Ubuntu・Debianでaptが使えない理由と、ディストリ別の実情

Denoは公式のaptリポジトリを提供していません。それどころか、Ubuntuのprimary archiveを照会すると`deno`の公開ソースパッケージは0件で、Debianのソースパッケージも存在しません。つまり素のUbuntuやDebianで`apt install deno`を叩いても、古い版が入るのではなく「パッケージが見つからない」で終わります。ここは選択の余地がなく、上のシェルインストーラを使います。

一方でディストリを一括りに「遅れている」と決めつけるのも正確ではありません。Archのextraリポジトリは2026年8月13日時点で2.9.5を配っており、最新安定版に追随しています。公式ドキュメントが「ディストリ同梱版はコミュニティ管理で最新リリースに遅れがち」と注意するのは事実ですが、実際の遅れ幅はディストリごとに違います。判断基準はシンプルで、そのディストリのパッケージ版がプロジェクトの要求する版に届いているかを`deno --version`で確認し、届いていなければ公式インストーラに切り替えれば済みます。

## 4つのリリースチャネルとLTSの維持期間

Denoはstable、lts、rc、canaryの4チャネルで配布され、メジャー版のプレリリース期間中はalphaとbetaが加わります。押さえるべきは、チャネルがバイナリ自体に焼き込まれている点です。同じ2.9.3という版番号が、stable版とLTS版という2つの異なるビルドとして存在します。`deno upgrade`が何を「最新」と見なすかは、いま動いているバイナリのチャネルで決まります。

| LTS版 | 維持開始       | 維持終了       |
| ---- | ---------- | ---------- |
| v2.1 | 2025-02-01 | 2025-04-30 |
| v2.2 | 2025-05-01 | 2025-10-31 |
| v2.5 | 2025-11-01 | 2026-04-30 |
| v2.9 | 2026-07-01 | 2027-01-31 |

LTSにバックポートされるのはセキュリティ修正と、クラッシュや計算誤りといった重大バグの修正だけです。API変更と新機能は入りません。表のとおり1系列の維持期間は3〜7か月で、1系列あたり約30か月のNode.jsとは前提が違います。年1〜2回はLTS系列を乗り換える作業が発生すると考えてください。その工数を確保できない案件では、LTSを選ぶより最新安定版のv2.9.5を追い続けるほうが結果的に運用は単純になります。

### 特定版へのピン留めと、LTSから滑り落ちる操作

CIやDockerイメージで版を固定したい場合、インストーラは第1位置引数をバージョンとして受け取ります。

```
# 特定版を入れる
curl -fsSL https://deno.land/install.sh | sh -s v2.9.5

# LTSチャネルへ切り替える
deno upgrade lts
```

ここに落とし穴があります。`deno upgrade`にバージョン番号を渡すと、常にstableビルドが選ばれます。LTSを使っている環境で`deno upgrade 2.9.3`と打つと、同じ版番号のstableビルドがダウンロードされ、そのマシンはLTSチャネルから外れてstableへ移ります。しかも公式ドキュメントが明記しているとおり、古いLTSパッチ版にピン留めする`deno upgrade`の形は存在しません。LTS運用では版番号を打たず`deno upgrade lts`だけを使う、と決めておくのが安全です。

## 権限フラグの設計：許可を書かないと何も触れない実行環境

公式ドキュメントはDenoを「既定で安全（secure by default）」と定義し、ファイルシステム、ネットワーク、環境変数、サブプロセス生成のいずれにも初期状態で触れないと明記しています。依存パッケージが自動的にすべてのI/O権限を得るNode.jsとは前提が逆です。必要な権限だけを実行時に渡します。

```
# ネットワークだけ許可
deno run --allow-net main.ts

# 読み取り先を限定し、その中の一部を除外
deno run --allow-net --allow-read=./data --deny-read=./data/secrets main.ts
```

ここで`-A`（全許可）を癖で付けると、この設計は何も守りません。`--allow-read`や`--allow-net`は値を渡してパスやホスト単位に絞れ、`--deny-*`で広い許可から一部を切り抜けます。フラグを毎回書くのが面倒なら`deno.json`の`permissions`フィールドに宣言できますし、起動後にコードから`Deno.permissions.revoke()`で権限を降ろすこともできます。依存パッケージの既知脆弱性は権限とは別問題なので、CIのゲートには`deno audit`を挟みます。

過信を避けるための例外も押さえておきます。公式は「同一スレッド上のコードはすべて同じ権限レベルを共有する」と明記しており、依存モジュール1つだけを隔離することはできません。さらに、初期の静的モジュールグラフの読み込みは権限チェックの対象外です。静的な`import`文と文字列リテラルの`import()`で解決されるモジュールは、ローカルファイルでも`--allow-read`なしに、リモートURLでも`--allow-net`なしに読み込まれます。この免除が効くのは読み込みまでで、実行が始まったあとの動作は通常どおり権限に従います。

### サンドボックスを素通りする–allow-runと–allow-ffi

すべての許可フラグが同じ重さではありません。公式が「サンドボックスできないものへのアクセスを与える＝実質的に全権付与」と名指ししているのが2つあります。

`--allow-run`はサブプロセスの起動を許します。子プロセスは親から制限を引き継がない別プログラムとして走るため、そこで起きることはサンドボックスの外側です。とりわけ`--allow-run=deno`が危険だと公式が指摘しています。新しいdenoプロセスを`--allow-all`付きで起動できてしまい、制限を丸ごと脱出できるからです。渡すなら`--allow-run=git`のように信頼できる実行ファイルを名指しし、denoやシェルを起動させないこと。`--allow-ffi`も同様で、ネイティブライブラリは同一プロセス内の機械語として動き、どの`--allow-*`を渡したかに関係なくシステムコールを直接発行できます。

### 組織で許可範囲を統制する権限ブローカー

フラグの管理を個々の開発者やCIジョブに任せると、結局`-A`が横行します。Denoはこれを組織側で封じる仕組みを持っています。環境変数`DENO_PERMISSION_BROKER_PATH`にUnixドメインソケット（Windowsは名前付きパイプ）のパスを指定すると、すべての権限判断が外部のブローカープロセスへ委譲されます。

挙動は明確です。ブローカーが有効な間は`--allow-*`と`--deny-*`がすべて無視され、対話プロンプトも表示されません。権限チェックは1件ずつブローカーへ送られ、接続失敗・メッセージ破損・ID不一致など異常があればDenoはその場でプロセスを終了します。要求と応答の形式はJSON Schemaでバージョン管理されています。

ただし公式が「上級者向け」と警告しているとおり、ブローカーが落ちればアプリも道連れで止まります。単一のWebサービスを動かすだけなら導入する必要はありません。検討する価値があるのは、複数チームの実行環境で許可範囲を監査ログとして残す義務がある場合に限られます。

## Node.js資産の持ち込みで詰まる3か所

既存のNode.jsプロジェクトを持ち込む場合、Deno 2系ではほとんどが修正なしで動きます。公式は「Deno 2.8時点でNode自身のテストスイートの75%超が通過し、ほぼすべての`node:`モジュールをカバーする」と計測値を出しています。npmパッケージは`npm:`指定子またはpackage.json経由、`require()`を含むCommonJSもサポート対象です。package.jsonのdependencies・scripts・typeフィールドはそのまま読まれ、scriptsは`deno task`から実行できます。node\_modulesは任意で、isolatedとhoistedの2レイアウトを選べます。

公式が「正直に言えば」と前置きして挙げる難所は3つです。一部のAPIが部分実装であること、Node-APIを使うネイティブアドオンにはローカルのnode\_modulesと`--allow-ffi`が要ること、そして一部のツールがnpmのディスク配置そのものを前提にしていることです。裏を返せば、純粋なJavaScriptのパッケージだけで構成されたプロジェクトなら移行の障害はほぼありません。モジュール解決の考え方でつまずく場合は[Native ESMの基本仕組みとCommonJSとの根本的な違いの整理](/tech/details/12462/)を先に読むと切り分けが早くなります。

## Freshプロジェクトの作成：初期化コマンドと生成されるファイル

DenoにはWebフレームワークが同梱されていないため、Webアプリを作るならFreshを載せます。Fresh 2.0.0は2025年9月9日に正式リリースされ、最新版は2.3.3（2026年4月28日）です。配布先はJSRの`@fresh/core`に移っています。新規プロジェクトは次の1行で作成します。

```
deno run -Ar jsr:@fresh/init
```

ウィザードがプロジェクト名、tailwindcssを使うか、VS Codeを使うかを順に尋ね、回答に応じたひな形を生成します。出来上がるのは`routes/`、`islands/`、`components/`、`static/`の各ディレクトリと、サーバーのエントリである`main.ts`、クライアント側エントリの`client.ts`、`deno.json`、そして`vite.config.ts`です。`deno.json`には`@/`のパスエイリアスが最初から設定されているので、相対パスの階層を数えずに`import { Button } from "@/components/Button.tsx"`と書けます。開発サーバーは`deno task dev`で起動します。

CSSファイルの読み込み先だけ間違えやすいので補足します。Viteはモジュールグラフに含まれるものしかホットリロードしないため、スタイルシートは`client.ts`からインポートします。ルーティングの書き方やアイランドの考え方は[Deno Freshとは｜Preactとアイランドアーキテクチャの軽量Webフレームワーク【Fresh 2対応・2026年版】](/tech/details/3619/)を参照してください。

### Fresh 1.xプロジェクトを2系へ移行する手順

1.x向けの構成は自動では移りません。まず更新スクリプトをプロジェクトディレクトリで実行します。`$fresh/server.ts`から`fresh`へのインポート書き換えなど、API変更の大半はこれで片付きます。続けて、Viteの依存を`deno.json`のimportsへ追加します。

```
deno run -Ar jsr:@fresh/update
deno install npm:vite jsr:@fresh/plugin-vite
```

残るのは手作業です。Fresh 2は専用の設定ファイルを持たなくなったため、`fresh.config.ts`とマニフェストの`fresh.gen.ts`、そして`dev.ts`を削除します。代わりに`vite.config.ts`を作って`@fresh/plugin-vite`の`fresh()`プラグインを登録し、CSS読み込み用の`client.ts`を追加します。`deno.json`のtasksも書き換えが必要で、devは`vite`、buildは`vite build`、本番起動は`deno serve -A _fresh/server.js`になります。エントリファイルをFreshが生成する形に変わったためです。最後に、テンプレートの`_404.tsx`と`_500.tsx`は`_error.tsx`1本へ統合されているので、これも自分で寄せます。なおVite構成では`jsr:@fresh/plugin-tailwindcss`は不要になり、`npm:@tailwindcss/vite`に置き換わります。

この移行の見返りは、開発時だけ必要なコードが本番から切り離されることです。公式はこれによってデプロイのサイズが小さくなり、アップロードと本番の起動が速くなると説明しています。

## 業務採用の判断材料となる更新の継続性

環境を整えたあと、社内で採否を問われたときに出す材料は開発の継続性です。最新安定版v2.9.5が2026年8月6日にリリースされ、LTSの維持期限も2027年1月31日まで公式に切られています。放置されたプロジェクトではありません。実務上の論点はむしろ前述のLTS周期で、乗り換え作業を年間計画に織り込めるかどうかが採否ラインになります。なお2026年10月9日、Denoチームは1年間の保守ののちにランタイムの開発を終えると発表し、Deno Deployも約6か月後に終了します。新規案件で採用を決める前に、[Deno Deploy終了と移行手順：Cloudflare WorkersへのコードとKV・cronの移し方](https://www.issoh.co.jp/tech/details/18318/)で日程と移行先を確認してください。

同じくNode.js互換をうたう高速ランタイムと比較検討する場合は、[Bunとは？インストール（brew・curl）から使い方・コマンドまで解説｜Node.jsに挑む高速JSランタイム](/tech/details/9264/)に導入手順と設計思想をまとめています。

### JavaScript商標をめぐる係争の現在地

採用可否とは別に、質問されやすいのがJavaScript商標の話です。Deno Land社は2024年11月22日、USPTOにOracleが保有する「JavaScript」商標の取消を申し立てました。TTABは2025年6月18日に3つの主張のうち詐欺の主張を却下しましたが、中心である一般名称化（genericness）と放棄（abandonment）の主張は取り下げられておらず、審理が続いています。2026年8月時点で結論は出ていません。この係争はDenoの製品仕様にも配布条件にも影響しないため、技術選定の判断材料には使えません。

## よくある質問

### Denoの読み方と名前の由来は？

公式ドキュメントは発音を /ˈdiːnoʊ/、読みを dee-no と記載しています。日本語では「ディーノ」に当たります。綴りの`deno`は`node`のアナグラムで、Node.jsの作者であるRyan Dahl氏が設計上の反省点を踏まえて作り直したランタイムであることが名前に表れています。

### Windowsに入れるにはどのコマンドを使いますか？

PowerShellで`irm https://deno.land/install.ps1 | iex`を実行するのが公式の第一候補です。Scoop、Chocolatey、wingetからも導入できます。`npm install -g deno`でも入りますが、公式ドキュメントはnpm経由だとdenoコマンドの起動時間に影響が出ると注意しています。前提としてWindows 10 バージョン1709またはWindows Server 2016 バージョン1709以降が必要です。

### UbuntuでAPTからインストールできますか？

できません。Denoは公式のaptリポジトリを提供しておらず、Ubuntuのprimary archiveにもDebianのソースパッケージにも`deno`は存在しないため、`apt install deno`はパッケージが見つからずに失敗します。`curl -fsSL https://deno.land/install.sh | sh`を使ってください。実行前に`unzip`（または`7z`）を入れておく必要があります。

### TypeScriptを動かすのにtsconfig.jsonやビルド設定は必要ですか？

不要です。Denoは`.ts`ファイルを受け取ってそのまま実行するため、`deno run app.ts`だけで動きます。トランスパイル用の依存パッケージもビルドスクリプトも用意しません。設定を書くとすれば`deno.json`にインポートマップやタスク、権限を定義する場面ですが、単一ファイルを動かすだけなら設定ファイル自体が要りません。

### Freshで作ったアプリをSSRで動かすには追加設定が要りますか？

要りません。Freshは全ページをサーバー側でHTMLに描画してからブラウザへ返す設計で、これが既定の動作です。追加でJavaScriptを配信するのは`islands/`に置いたコンポーネントだけになります。`deno run -Ar jsr:@fresh/init`で生成した時点でこの構成なので、SSRのために書く設定はありません。レンダリング方式そのものの違いは[CSRとSSRの違いと使い分け｜レンダリング方式を比較して実装で選ぶ](/tech/details/5895/)で整理しています。

## 関連記事

- [Deno Freshとは｜Preactとアイランドアーキテクチャの軽量Webフレームワーク【Fresh 2対応・2026年版】](/tech/details/3619/)
- [Bunとは？インストール（brew・curl）から使い方・コマンドまで解説｜Node.jsに挑む高速JSランタイム](/tech/details/9264/)
- [CSRとSSRの違いと使い分け｜レンダリング方式を比較して実装で選ぶ](/tech/details/5895/)
- [Native ESMの基本仕組みとCommonJSとの根本的な違いの整理](/tech/details/12462/)
- [V8 Isolateとは？仕組み・Contextとの違い・サーバーレスでの活用を徹底解説](/tech/details/12608/)

---

出典: [DenoとFreshの開発環境セットアップ｜インストール・権限設計・LTS選定【2026年8月版】](<https://www.issoh.co.jp/tech/details/4646/>)（株式会社一創）