---
title: "Docker Desktopの導入手順とライセンス境界｜4.89系の要件と無料代替への移行"
url: "https://www.issoh.co.jp/tech/details/17442/"
published: 2026-09-06
updated: 2026-10-05
categories: ["Kubernetes・コンテナ"]
publisher: "株式会社一創"
---

# Docker Desktopの導入手順とライセンス境界｜4.89系の要件と無料代替への移行

Docker Desktopは、Docker EngineとCLI、Composeをひとつのアプリにまとめた配布物です。入れれば動く代わりに商用利用には従業員数と売上の条件が付き、外れた時点で有償サブスクリプションが必要になります。この記事では、Windows・macOSでの無人インストールと起動確認、無料で使える境界の当てはめ方と超えた場合の実額、Desktopを外してWSL2上のDocker CEやColimaへ移す作業までを扱います。公式リリースノートで4.89.0が最新（2026年8月31日）の時点の情報です。

## まとめ：Docker Desktop導入とライセンス判定の要点

Docker Desktopの導入判断は、技術要件と課金要件を別々に見ると迷いません。技術要件はWindowsならWindows 11 23H2以上とWSL 2.1.5以上、macOSならサポート対象OSとRAM 4GB以上。Windows Serverは対象外です。

課金要件の分岐は1本だけ。従業員250人未満かつ年間売上1000万ドル未満なら無料、どちらか一方でも超えたら有償です。実額はPro 月11ドル、Team 月16ドル、Business 24ドル（1ユーザーあたり）。30人の開発組織でBusinessを選ぶと年間8,640ドル、1ドル150円換算で約130万円が固定費として乗ります。

この固定費を避ける道は用意されています。WindowsならWSL2の中にDocker CEを入れる、macOSならColimaを使う。どちらもDocker Desktop本体を外したうえで`docker`コマンドと`docker compose`をそのまま使えます。ただしGUIの診断画面、Kubernetesの同梱クラスタ、Enhanced Container Isolationは失われるため、そこを使っている組織は有償のまま維持したほうが総コストは低く済みます。CIランナーとWindows Serverについては、そもそも候補に入れません。

## Docker Desktopの構成要素とEngine単体との実行環境の違い

「Dockerを入れる」と言ったとき、実際に何が入るのかを先に切り分けます。

### Engine・CLI・Composeを同梱する構成の内訳と起動単位

中核は、コンテナを動かすDocker Engine、操作する`docker`コマンド（Docker CLI）、複数コンテナを定義するDocker Composeの3点です。加えてダッシュボードのGUI、Kubernetesクラスタ、Docker Scoutによるイメージ検査、拡張機能の枠組みが同じインストーラに入ります。

起動単位はアプリケーション1つ。`docker`コマンドを叩くとDesktopのバックエンドが起動し、常駐プロセスがEngineを保持します。Engine単体を入れたLinuxでは`dockerd`がsystemdの管理下に入るため、起動・停止・自動起動の制御方法が変わります。この差が、後述する移行作業で最初につまずく箇所です。

### Linux VM上でEngineが動く二段構成とファイル共有の経路

WindowsとmacOSでLinuxコンテナが動くのは、Docker Desktopが内部にLinux仮想マシンを立てているからです。器はWindowsならWSL 2かHyper-V、macOSなら仮想化フレームワークかDocker VMM。1つのアプリに見えても実体は「ホスト」「Linux VM」「コンテナ」の三層です。

この三層構造は性能と共有設定の両方に効きます。ソースコードをホスト側に置いてバインドマウントすると、ファイルI/OはVM境界をまたぐぶん遅くなる。WSL 2バックエンドなら、リポジトリをWSLのファイルシステム側（`/home/user/work`）に置くだけで体感が変わります。WSL側の設定やディスク肥大化への対処は[WSLで開発環境を構築する手順（.wslconfig調整とDocker連携）](https://www.issoh.co.jp/tech/details/17354/)に譲ります。

## Windowsでのインストール手順とWSL2バックエンド有効化の確認

Windows版が失敗する原因は、ほぼ前提条件の取りこぼしです。要件・無人インストール・起動確認の順に見ます。

### Windows 11 23H2以上とWSL 2.1.5以上という前提条件

公式の[Install Docker Desktop on Windows](https://docs.docker.com/desktop/setup/install/windows-install/)が示す対象は、Windows 10 64bitの22H2（build 19045）またはWindows 11 64bitの23H2（build 22631）以上、エディションはEnterprise・Pro・Educationです。Windows Server 2019および2022はサポート対象外と明記されています。見落とすと、検証用のサーバーOSに入れて動かないという手戻りが起きます。

WSL 2バックエンドの追加条件は、WSLのバージョンが2.1.5以上であること。Enhanced Container Isolationを使うなら2.6以上です。ハードウェア側はSLAT対応の64bitプロセッサ、システムRAM 8GB以上、BIOSまたはUEFIでの仮想化有効化。RAM 8GBという下限は、macOS版の4GBより厳しい設定になっています。Hyper-Vバックエンドを選ぶ場合の有効化と仮想マシン操作は[Hyper-Vの有効化と仮想マシン作成手順](https://www.issoh.co.jp/tech/details/17468/)で扱っています。さらにWindows Server サービス（LanmanServer）が有効かつ自動起動である必要があり、セキュリティ設定で無効化している端末では起動に失敗します。

### インストーラのCLIフラグでバックエンドを指定する無人導入の手順

台数があるとGUIのウィザードを人が押す運用は破綻します。インストーラは`install`サブコマンドで無人導入に対応しており、バックエンドの指定までフラグで済みます。

```
REM 全ユーザー向け・無人・WSL 2バックエンドを明示して導入
"Docker Desktop Installer.exe" install --quiet --accept-license --backend=wsl-2 --always-run-service

REM 特定ユーザーのみ・Windowsコンテナ機能を入れない
"Docker Desktop Installer.exe" install --user --quiet --accept-license --no-windows-containers
```

`--backend`に渡せる値は`hyper-v`、`windows`、`wsl-2`の3つ。`--allowed-org`を付けると、指定したDocker組織のアカウントでサインインしないと使えない状態にできます。`--always-run-service`は特権ヘルパーを常駐させるフラグで、付けないと管理者権限のない利用者が起動時にUACへ引っかかります。

### docker desktop statusでの起動確認とengine lsの切り替え

導入後の確認はGUIの目視をやめてCLIで済ませます。公式の[Docker Desktop CLI](https://docs.docker.com/desktop/features/desktop-cli/)に状態確認と起動制御のサブコマンドが揃っています。

```
REM 起動しているかどうかを確認する
docker desktop status

REM 停止していれば起動し、Engineのバージョンを確認する
docker desktop start
docker version --format '{{.Server.Version}}'

REM Windowsのみ: LinuxコンテナとWindowsコンテナを切り替える
docker desktop engine ls
docker desktop engine use windows

REM 不調時は診断を取得する（4.60以降）
docker desktop diagnose
```

使えるサブコマンドは`start`、`stop`、`restart`、`status`、`update`、`logs`、`enable`、`disable`、`version`。`engine ls`と`engine use`はWindows専用です。`kubernetes`は4.44以降、`diagnose`は4.60以降の追加なので、端末バージョンが古いと存在しません。手順書に書く前に`docker desktop version`で確認してください。

## macOSでのインストールとDocker VMM切り替えの操作手順

macOS版はWindows版より要件が緩い一方、仮想化方式の選択肢が増えました。

### Docker VMMとApple仮想化フレームワークの切り替え条件

公式の[Install Docker Desktop on Mac](https://docs.docker.com/desktop/setup/install/mac-install/)が示す要件は、Apple silicon・Intelともサポート対象macOS（現行バージョンと直前2メジャー）、RAM 4GB以上です。Apple siliconではRosetta 2の導入が推奨され、x86\_64向けイメージを動かす場面で効きます。

仮想化方式は設定画面で切り替えます。従来のApple仮想化フレームワークに加え、Docker自前のハイパーバイザであるDocker VMMが4.86でパブリックベータとして入りました。判断材料と既知の制約は[Docker VMMとは？4.86の自前ハイパーバイザと切り替え判断](https://www.issoh.co.jp/tech/details/16896/)で整理しています。ベータ機能を業務端末へ一律展開する判断は、この記事では推奨しません。

### hdiutilでの無人導入とライセンス承認・ユーザー指定の書式

macOS版もCLIから無人導入できます。dmgをマウントして内部のインストーラを直接叩く形式です。

```
# dmgをマウントし、ライセンス承認と対象ユーザーを指定して導入する
sudo hdiutil attach Docker.dmg
sudo /Volumes/Docker/Docker.app/Contents/MacOS/install --accept-license --user testuser
sudo hdiutil detach /Volumes/Docker

# プロキシをPACファイルで指定する場合
sudo /Applications/Docker.app/Contents/MacOS/install --user testuser \
  --proxy-http-mode="manual" \
  --override-proxy-pac="http://localhost:8080/myproxy.pac"
```

`--user`で指定したアカウントに初期設定が適用されるため、共用端末のキッティングでは指定を忘れないでください。プロキシ配下の社内ネットワークでは`--override-proxy-pac`が使えます。この2つでMDM経由の配布スクリプトはほぼ書けます。

## 商用利用の課金境界と組織配布｜250人基準での判定と設定ロック

判定は1本の条件式で、超えた場合の金額は公式の料金ページに載っています。試算まで落とします。

### 250人・年間売上1000万ドルという無料条件の当てはめ方と注意

公式の[Docker Desktop license agreement](https://docs.docker.com/subscription/desktop-license/)は、無料の対象を「Small businesses (fewer than 250 employees AND less than $10 million in annual revenue)」と書いています。ANDである点に注意してください。従業員249人でも年間売上が1000万ドルを超えれば対象外です。個人利用、教育機関、非営利のオープンソースプロジェクトも無料の対象になります。

落とし穴は3つ。判定対象は「利用者が所属する組織」なので、客先常駐で見るのは常駐先ではなく雇用元です。次に連結の扱いで、子会社単体では250人未満でも親会社を含めると超えることがあります。3つめは、対象がDocker Desktopという配布物に限られること。Docker Engine単体や`docker-ce`は対象外で、そのため後述の移行が成立します。

### Pro・Team・Businessの月額と年額の差の実額と最小人数

金額は[Docker Pricing](https://www.docker.com/pricing/)に1ユーザー単価で掲載されています。年払いで単価が下がるプランと、下がらないプランがあります。

| プラン      | 月払（1人） | 年払（1人） | ユーザー数 | 主な追加要素             |
| -------- | ------ | ------ | ----- | ------------------ |
| Personal | 0ドル    | 0ドル    | 1     | Hub pull 100回/時    |
| Pro      | 11ドル   | 9ドル    | 1     | Build Cloud 200分/月 |
| Team     | 16ドル   | 15ドル   | 最大100 | Hub のRBAC・Scout無制限 |
| Business | 24ドル   | 24ドル   | 無制限   | SSO・SCIM・設定ロック     |

Businessだけは月払と年払が同額です。無料のPersonalはDocker Hubのpullが1時間あたり100回に制限され、プライベートリポジトリは1つ、Docker Scoutの検査対象も1リポジトリまで。CIから同じイメージを何度も引く構成では、この100回制限が先に効きます。設定ロックやSSOが要件ならBusiness以外に選択肢はありません。

### 30人でBusinessを選ぶ場合の年額試算と増え方の見立て方

単価だけ見ると小さいので、組織規模で掛け算します。開発者30人でBusinessなら24ドル×30人×12か月＝年間8,640ドル、1ドル150円換算で約130万円。Teamの年払（15ドル）なら同じ30人で年間5,400ドル、約81万円。差額は約49万円です。

増え方の見立てで効くのは3点。人員が10人増えるとBusinessでは年間2,880ドル（約43万円）増える点、Teamは最大100ユーザーで上限に当たる点、そして為替です。1ドル130円と170円では同じ30人契約で年額が約31万円動く。円建ての予算に固定費として載せるなら、為替の振れ幅を含めた枠を取ってください。

### admin-settings.jsonでの設定ロックと配置先のパス指定

Businessプランで使えるのが設定のロックです。[Settings Management](https://docs.docker.com/enterprise/security/hardened-desktop/settings-management/configure-json-file/)では、管理者が置いたJSONで各設定の値と変更可否を固定します。配置先はWindowsが`C:\ProgramData\DockerDesktop\admin-settings.json`、macOSが`/Library/Application Support/com.docker.docker/admin-settings.json`です。

```
{
  "configurationFileVersion": 2,
  "analyticsEnabled": { "locked": true, "value": false },
  "enhancedContainerIsolation": { "locked": true, "value": true }
}
```

`configurationFileVersion`は書式のバージョンで、現行は2。各設定を`locked: true`にすると利用者側のUIから変更できなくなります。テレメトリ送信を切る、コンテナの分離を強制する、といった要件をファイル1本で担保できるのがBusinessを選ぶ実利的な理由です。逆に、この要件が無い組織にBusinessの単価を払う根拠は薄い。

## Docker Desktopを外す移行手順とColima・Docker CEの構築

課金境界を超え、かつDesktop固有の機能を使っていないなら、外す選択が成立します。

### WSL2にDocker CEを入れてDesktopを外すまでの作業手順

Windowsでは、WSL 2のディストリビューション内にDocker CEを直接入れます。手順は[Install Docker Engine on Ubuntu](https://docs.docker.com/engine/install/ubuntu/)のaptの流れそのまま。以下はUbuntu 24.04（noble）の例です。

```
# リポジトリ鍵を配置する
sudo apt-get update
sudo apt-get install -y ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

# apt ソースを追加する
echo "deb [arch=amd64 signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu noble stable" | sudo tee /etc/apt/sources.list.d/docker.list

# Engine本体とプラグインを入れる
sudo apt-get update
sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# 起動して自ユーザーをdockerグループへ入れる
sudo service docker start
sudo usermod -aG docker $USER
```

入るパッケージは`docker-ce`、`docker-ce-cli`、`containerd.io`、`docker-buildx-plugin`、`docker-compose-plugin`の5つ。Composeもプラグインとして入るため`docker compose`はそのまま使えます。WSL 2ではsystemdが既定で動かないディストリビューションもあるので、`service docker start`で起動するか、`/etc/wsl.conf`でsystemdを有効化して`systemctl enable docker`に寄せるかを先に決めてください。決めずに手順書を配ると、端末ごとに起動方法が違う状態になります。

### ColimaでmacOSのdocker contextを差し替える操作手順

macOSでは[Colima](https://github.com/abiosoft/colima)が置き換え先です。Lima上のLinux VMでランタイムを動かし、`docker`コマンドはHomebrewで入れたCLIを使う構成になります。

```
# CLIとColimaを入れる（Docker Desktop本体は入れない）
brew install colima docker docker-compose

# CPU 4コア・メモリ8GB・ディスク60GBでVMを起動する
colima start --cpu 4 --memory 8 --disk 60 --vm-type vz --mount-type virtiofs

# 接続先コンテキストがcolimaに向いているか確認する
docker context ls
docker context use colima
docker run --rm hello-world
```

要点は`docker context`です。Desktopは`desktop-linux`というコンテキストを作るため、両方が入っている端末では向き先が意図せず切り替わります。移行時はDesktopをアンインストールしたうえで`docker context ls`を確認し、`colima`が使われている状態にしてください。作り直しが要る設定項目やTestcontainers・buildxの接続設定は[Colimaの導入手順と設定の落とし穴をまとめた記事](https://www.issoh.co.jp/tech/details/17842/)で扱っています。デーモン構成そのものを比べるなら[Podmanとdockerの違い（デーモンレス・rootlessの仕組みと移行判断）](https://www.issoh.co.jp/tech/details/13202/)も選択肢に入ります。

### 移行で壊れやすいvolume・ポート公開・DNS解決の落とし穴

移行そのものは短時間で終わります。壊れるのは周辺です。

- 名前付きvolumeはVM内にあり、アンインストールで消える。DBのデータは`docker run --rm -v`でtarに退避してから外す
- `localhost`へのポート公開の見え方が変わる。移行直後にホストのブラウザから引けるかを確認する
- Desktopが提供していた`host.docker.internal`の名前解決が、環境によっては効かなくなる
- バインドマウントのパス表記が変わる。Desktopは`C:\work`を受けるが、WSL内のEngineは`/mnt/c/work`を要求する

移行後の確認はコマンドで固定化しておくと再現できます。

```
# 接続先とバージョン、Composeの有無を確認する
docker context ls
docker info --format '{{.ServerVersion}} {{.OperatingSystem}}'
docker compose version

# ポート公開がホストから引けるかを確認する
docker run --rm -d -p 18080:80 --name nginx-check nginx:1.27-alpine
curl -sSI http://localhost:18080 | head -n 1
docker rm -f nginx-check
```

この4項目が通れば移行完了と判断してかまいません。`curl`の1行目が返らないなら、ポート公開ではなくVMのネットワーク設定を疑います。

ホストまで引けたポートを、さらに社外の相手や外部サービスのWebhookから叩かせたい場合は、コンテナ側の設定ではなくトンネルで解決します。その手順は[ngrokでローカルサーバーを外部公開する手順](https://www.issoh.co.jp/tech/details/17470/)にまとめています。

## Docker Desktopを採用しない条件とCI環境での見送りの基準

Docker Desktopは開発端末のための製品です。置く場所を間違えると単価と運用の両方で損をします。

### CIランナーとWindows Serverで採用しない技術的な理由

次の3条件のいずれかに当てはまるなら採用しません。第一に、実行環境がWindows Server 2019または2022である場合。公式がサポート対象外と明記しており、動いても支援を受けられません。第二に、GUIを誰も開かないCIランナー・ビルドマシン。常駐アプリとGUIの分だけリソースを食い、ライセンスの人数カウントも無駄に増えます。ここはDocker CE、あるいはBuildKitやPodmanといったデーモンレスの構成を選びます。第三に、コンテナを動かす先がマネージドサービスだけで、端末では設定ファイルしか書かない場合。CLIで足ります。

ECSやCloud Runへの載せ替え、CI実行環境の分離まで含めた設計を外に出す選択もあります。その範囲は[インフラ構築（AWS・Google Cloud・Azure）](https://www.issoh.co.jp/service/system/aws/)で対応しています。

### Desktopを維持すべき場面＝Kubernetes同梱とGUI診断

一方で、Desktopを維持したほうが安いケースもはっきりしています。ひとつは同梱Kubernetesを使っている場合。ローカルクラスタを別途構築して維持する手間と、年間8,640ドル（30人・Business）を比べると、人数が少ない組織ではDesktopのほうが安く収まります。もうひとつは設定ロックとSSOが監査要件になっている場合で、これはBusinessでしか担保できません。

3つめは開発者の習熟度がばらつく組織です。GUIでログとリソース使用量を見られること、`docker desktop diagnose`で診断を一括送信できることは、CLIに不慣れなメンバーを抱えるチームではサポートコストの削減に直結します。「安いから全員をColimaへ寄せる」という判断は問い合わせ対応の時間を払うことになるので、移行前に誰が面倒を見るかを決めてから動いてください。

## よくある質問

Docker Desktopの導入・課金・移行について、検索でよく出てくる質問に答えます。

### Docker Desktopは有料ですか？無料で使える条件は何ですか？

条件を満たせば無料です。公式のライセンス条項では、従業員250人未満かつ年間売上1000万ドル未満の事業者、個人利用、教育機関、非営利のオープンソースプロジェクトが無料の対象とされています。従業員数と売上はANDの条件なので、どちらか一方でも超えると有償サブスクリプション（Pro 月11ドル、Team 月16ドル、Business 24ドル）が必要です。対象はDocker Desktopに限られ、Docker Engine単体やCLIは含まれません。

### Docker Desktopを入れずにDockerを使えますか？

使えます。WindowsならWSL 2の中にDocker CE（`docker-ce`と`docker-compose-plugin`）をaptで入れる構成、macOSならColimaでVMを立ててHomebrewの`docker` CLIから接続する構成が代表的です。どちらも`docker run`と`docker compose`はそのまま動きます。失われるのは同梱Kubernetes、GUIダッシュボード、Enhanced Container Isolationです。Windowsでは2026年9月29日のWSL 3.0.1から、WSL標準のwslc.exeでコンテナを動かす方法も選べます（Compose未対応。詳しくは[WSL Containersとは？wslcの使い方とDocker Desktopとの使い分け](https://www.issoh.co.jp/tech/details/18105/)）。

### WSL2バックエンドとHyper-Vバックエンドはどちらを選べばよいですか？

Linuxコンテナを動かすなら既定のWSL 2バックエンドです。ファイル共有とメモリの扱いがWSL 2側で改善されており、WSLの設定ファイルでリソース上限も制御できます。Hyper-Vを選ぶのは、Windowsコンテナが必要な場合か、組織のポリシーでWSLを無効化している場合。インストーラでは`--backend=wsl-2`または`--backend=hyper-v`で指定します。

### Docker Desktopが起動しないときは何を確認すればよいですか？

まず`docker desktop status`で、停止なのかハングなのかを切り分けます。停止していれば`docker desktop start`、それでも上がらなければ`docker desktop logs`を見ます。Windowsでの原因は、WSLが2.1.5未満、BIOSで仮想化が無効、Windows Server サービス（LanmanServer）が停止、のいずれかが多い。絞れないときは`docker desktop diagnose`で診断データを取得します（4.60以降）。

### Docker Desktopをアンインストールするとイメージやvolumeは残りますか？

残りません。イメージと名前付きvolumeは内部のLinux VMのディスク内にあるため、アンインストールで消えます。移行や再インストールの前に必要なデータを退避してください。データベースのvolumeなら、一時コンテナからマウントしてtarに固め、ホスト側へ出すのが確実です。設定ファイルやComposeの定義はホスト側のリポジトリにあるため影響を受けません。

## 関連記事

- [コンテナとは？仮想マシンとの違いからDocker・企業の導入判断まで解説](https://www.issoh.co.jp/column/details/13000/)：仮想マシンとの使い分けを判断側から整理
- [OrbStackとは？Docker Desktopより軽いMac用コンテナ環境の特徴・料金・使い方](https://www.issoh.co.jp/tech/details/4058/)：Colima以外のMac代替を比較する場合に
- [k8sをローカルで動かす手順｜kindでクラスタ構築からDeployment公開・撤収まで](https://www.issoh.co.jp/tech/details/17438/)：同梱Kubernetesを外してkindへ寄せる手順
- [Apple container（apple/container）とは？macOSでLinuxコンテナを動かすCLIの使い方とDockerとの違い](https://www.issoh.co.jp/tech/details/7219/)：Apple純正CLIという別方式
- [Linuxとは？仕組み・ディストリビューション・サーバー用途を実装目線で解説](https://www.issoh.co.jp/tech/details/13160/)：Docker CEを入れるWSL 2側のOSの土台

---

出典: [Docker Desktopの導入手順とライセンス境界｜4.89系の要件と無料代替への移行](<https://www.issoh.co.jp/tech/details/17442/>)（株式会社一創）