- Published on
Docker Desktop 代替ツール 2026 — Podman / OrbStack / Colima / Finch / Rancher Desktop 比較 深堀りガイド
- Authors
- Name
- Youngju Kim
- @fjvbn20031
- プロローグ — なぜ再び Docker 代替を語るのか
- 第1章 · Docker アーキテクチャ図で見るコンテナの本当の構成要素
- 第2章 · containerd / runc / CRI-O — 下層ランタイムの真の標準
- 第3章 · Podman + Buildah + Skopeo — Red Hat のデーモンレススタック
- 第4章 · nerdctl — containerd を Docker CLI のように
- 第5章 · Lima / Colima — Mac 上の Linux VM の出発点
- 第6章 · OrbStack — 商用だが速くて軽い
- 第7章 · Finch — AWS のオープンソース統合パッケージ
- 第8章 · Rancher Desktop — Kubernetes ユーザに最適
- 第9章 · Podman Desktop 深堀り — グラフィカルインタフェースのデーモンレス
- 第10章 · Apple Container Framework — Mac ネイティブコンテナの意味
- 第11章 · 私たちのチームは何を選ぶべきか — 意思決定ツリー
- 第12章 · 参考 / References
プロローグ — なぜ再び Docker 代替を語るのか
2021年8月31日。Docker Inc. は「Docker Subscription Service Agreement」を発表し、Docker Desktop を従業員250人以上または売上1,000万ドル以上の会社で商用利用するには有料サブスクリプションが必要だと宣言した。この一行の利用規約変更が、コンテナツールエコシステムを丸ごと揺さぶった。それまで「Docker = コンテナ」だったが、それ以降は「Docker = Docker Inc. という会社のひとつの製品」という事実が明白になった。
それから5年が経った2026年5月、風景は完全に変わった。
- Podman Desktop が Red Hat の本格的な支援のもと 1.20 系に到達した。デーモンレス(daemonless)アーキテクチャとルートレス(rootless)コンテナで差別化する。
- OrbStack は Mac で事実上の標準となった。商用ツールだがメモリ占有は Docker の3分の1程度、起動時間は2秒未満。
- Finch は AWS が出したオープンソース統合バンドルだ。Lima + containerd + nerdctl + BuildKit が一つのパッケージに入っている。
- Colima は無料を望む人たちの基本選択肢である。Lima ベースで Homebrew でインストール可能。
- Rancher Desktop は SUSE による買収後も、Kubernetes ユーザに最もフレンドリーなオプションのままだ。
- Apple Container Framework が2025年 WWDC で発表され、macOS 自体がコンテナランタイムを内包し始めた。2026年5月現在、macOS 15.4 以降で正式サポート。
- そしてその下で containerd が真の産業標準となった。CNCF Graduated プロジェクトで、Kubernetes のデフォルトランタイムであり、上記すべてのツールが何らかの形で containerd を呼んでいる。
本記事はこれら7つのツールを同じ軸で比較する。各ツールの内部構造、性能特性、長所短所、そしてどのチームにどのツールが合うのかを正直に検討する。価格・機能の数値は2026年5月時点であり、6か月後に変わっても構造的な違いを見るフレームは有効であるべきだ。
Docker は消えない。ただ Docker は今や数ある選択肢の一つ である。私たちは「Docker vs その他」の時代から「自分のチームに合うコンテナツール」の時代へ移った。
第1章 · Docker アーキテクチャ図で見るコンテナの本当の構成要素
「Docker 代替」と言うなら、まず Docker が何をしているかを5つのコンポーネントに分解する必要がある。同じ仕事をする別のツールを選べて初めて「代替」になる。
コンポーネント1 · コンテナランタイム(Container Runtime) コンテナを実際に実行する低レベルのコード。Linux の namespace・cgroup・capabilities を扱う。Docker は内部で containerd を呼び、containerd はさらに runc を呼ぶ。1) runc — OCI 標準の参照実装、Go 製。2) crun — Red Hat の C 実装、より速くて小さい。3) kata-containers — VM ベースの隔離。
コンポーネント2 · ランタイムデーモン(Runtime Daemon) ランタイムを呼び出す長期実行プロセス。Docker は dockerd、その下にさらに containerd がある。Podman はデーモンを持たず直接実行するのがシグネチャ。nerdctl は containerd を直接呼ぶ。
コンポーネント3 · CLI / クライアント
ユーザが入力するコマンド。docker、podman、nerdctl、finch、crictl など。ほとんどが Docker CLI と互換のコマンドインタフェースを提供する — run、build、pull、push、ps、images、exec、logs。
コンポーネント4 · イメージビルダ(Image Builder) Dockerfile を OCI イメージに変換する。1) classic builder — Docker の古いビルダ、シングルスレッド。2) BuildKit — Docker の現行ビルダ、並列ビルド、キャッシュマウント、シークレットマウント対応。3) Buildah — Red Hat、デーモンレス、シェルスクリプトでビルド可能。4) kaniko — Google、クラスタ内で動くビルダ。
コンポーネント5 · VM レイヤ(macOS/Windows 限定) コンテナは Linux カーネル機能に依存するため、macOS と Windows では Linux VM が必要。1) Hyperkit / VZ — Docker Desktop の旧/新バックエンド。2) Lima — Colima、Finch、Rancher Desktop がすべて依存する。3) WSL2 — Windows。4) Apple Virtualization Framework — OrbStack のコア。
この5つのコンポーネントを異なる組み合わせで束ねたのが「Docker 代替ツール」たちである。表にまとめると:
| ツール | ランタイム | デーモン | CLI | ビルダ | VM レイヤ |
|---|---|---|---|---|---|
| Docker Desktop | containerd + runc | dockerd | docker | BuildKit | VZ(新)/Hyperkit(旧) |
| Podman Desktop | crun | なし | podman | Buildah | QEMU / Apple Hypervisor |
| OrbStack | containerd + runc | 独自デーモン | docker(互換) | BuildKit | Apple Virtualization Framework |
| Colima | containerd + runc | なし(または dockerd) | nerdctl / docker | BuildKit | Lima |
| Finch | containerd + runc | なし | nerdctl(finch ラッパ) | BuildKit | Lima |
| Rancher Desktop | containerd | なし | nerdctl または docker | BuildKit / moby | Lima |
| Apple Container | runc(macOS 移植) | なし | container | BuildKit | Apple Virtualization Framework |
ポイントは containerd がほぼすべての場所にある ということだ。コンテナランタイム戦争は実質的に終わっており、containerd が勝った。上のツール群の違いは、その上に何を載せるかの違いである。
第2章 · containerd / runc / CRI-O — 下層ランタイムの真の標準
containerd は2017年に Docker から分離され、CNCF に寄贈されたプロジェクトだ。2019年に Graduated 段階に入り、2026年現在 Kubernetes 1.30 以降のデフォルトランタイムであり、AWS Fargate、GKE、AKS、EKS、IBM Cloud、DigitalOcean Kubernetes のデフォルトでもある。
containerd の仕事 イメージを pull/push し、OCI イメージを展開してコンテナバンドルを作り、runc を呼び出してコンテナを実行し、コンテナのライフサイクル(start/stop/kill/delete)を管理する。namespace や cgroup の設定は runc に委ねる。
なぜ Docker より軽いのか Docker は dockerd の上にさらに containerd を呼ぶ二段構造だ。containerd だけ使えば一段減り、dockerd が持つビルド・ネットワーク・ボリュームのオーケストレーション機能(多くの人が使わない)が外れる。メモリ占有が小さくなり、起動時間が速くなる。
runc vs crun
runc は Go 製で標準。crun は Red Hat が C で新規に書いたもので、より速い — コンテナ起動が約2倍速いというベンチマークが一貫して出ている。メモリも少ない。Podman はデフォルトで crun を使う。containerd も runtimeclass 経由で crun に切り替え可能。
CRI-O はどこで使うか CRI-O は Kubernetes 専用の最小ランタイムだ。CRI(Container Runtime Interface)のみを実装し、他の機能は持たない。Red Hat OpenShift がデフォルトで使う。開発者デスクトップではほとんど使わない — 本記事の範囲では「Kubernetes ノード専用」と覚えておけばよい。
containerd を直接扱うコマンドは ctr だが、人間が使うには粗い。そこで2つのユーザフレンドリーな CLI が登場する — nerdctl(Docker CLI 互換)と Kubernetes で使う crictl(CRI 専用)。
# containerd 自体の CLI
sudo ctr image pull docker.io/library/nginx:latest
sudo ctr container create docker.io/library/nginx:latest mynginx
sudo ctr task start mynginx
# nerdctl で同じ作業 (はるかに簡単)
nerdctl run -d --name mynginx -p 8080:80 nginx:latest
containerd が標準であるという事実はツール選びに大きな含意を持つ。上のツールのほとんどが同じ containerd を呼ぶ。だからツール間の本当の違いは(a)CLI の慣れ、(b)VM レイヤの性能、(c)付加機能(Kubernetes、GUI、ビルダ統合)にある。
第3章 · Podman + Buildah + Skopeo — Red Hat のデーモンレススタック
Podman は Red Hat が2018年にリリースした Docker 代替だ。「Pod Manager」の略であり、本来は Kubernetes Pod をローカルで実行するツールとして始まった。2026年現在 5.5 系で、RHEL・Fedora・CentOS Stream のデフォルトコンテナツール。
Podman のシグネチャ — デーモンレス
Docker は dockerd が常に立ち上がっていなければならない。コンテナがゼロでもデーモンはメモリを食い、systemd サービスとして生きている。Podman は違う。podman run と入力すると、その瞬間に fork されたプロセスがコンテナを立ち上げ、コンテナが終わるとともに消える。デーモンなし。バックグラウンドサービスなし。
# Docker — デーモンを先に立ち上げておく必要がある
sudo systemctl start docker
docker run -d nginx
# Podman — デーモンなしで直接実行
podman run -d nginx
# コンテナが終了すると管理プロセスも自然に終わる。
なぜデーモンレスが重要か
3つの理由がある。1) セキュリティ — dockerd は root で動く巨大な攻撃面だ。dockerd の権限は事実上 root だ。Podman は fork モデルなので root が不要。2) ルートレス(rootless)コンテナ — 一般ユーザ権限でコンテナを立ち上げられる。user namespace を使ってコンテナ内の root をホストの一般ユーザにマッピングする。3) systemd 統合 — コンテナ1つが systemd ユニット1つ。podman generate systemd で自動生成される。
Buildah — イメージビルダ
Podman はビルドを直接やらない。ビルドは Buildah がやる。Buildah の利点は2つ。1) Dockerfile なしでシェルスクリプトでビルド — buildah from、buildah run、buildah copy、buildah commit を組み合わせて手続き的なビルドができる。CI パイプラインで強力。2) ルートレスビルド — root なしでイメージを作れる。セキュリティ環境で決定的。
# Buildah でシェルスクリプト風ビルド
container=$(buildah from alpine:3.20)
buildah run $container -- apk add --no-cache python3
buildah copy $container app.py /app/
buildah config --cmd 'python3 /app/app.py' $container
buildah commit $container myapp:1.0
Skopeo — イメージ運搬
Skopeo はイメージレジストリ間を運ぶツールだ。コンテナの実行はせず、イメージそのものだけ を扱う。1) レジストリ間コピー — skopeo copy docker://docker.io/nginx:latest docker://my-registry.com/nginx:latest。2) イメージ検査 — pull せずにマニフェストだけ見る。3) 署名検証 — Sigstore/Cosign 統合。CI で「イメージを取得せずに検査だけ」するシナリオの標準。
Podman Desktop 2022年に Red Hat がリリースした GUI。2026年現在 1.20 系で、Docker Desktop とほぼ同等の使い勝手を提供する。Windows・macOS・Linux。Kubernetes 統合(Kind/Minikube)、コンテナ移行ウィザード、AI Lab(ローカル LLM)などの付加機能。無料 であり、オープンソース(Apache 2.0)。
Podman の弱点
- Docker と100%互換ではない。一部の Docker Compose オプションやネットワークモードが異なる動きをする。
podman-composeや別途 Docker 互換ソケットが必要。2) macOS/Windows では結局 VM が必要 — デーモンレスの利点がホスト OS では薄れる。3)docker-composeのようなツールが Docker ソケットを期待する場合、互換レイヤを挟む必要がある。
第4章 · nerdctl — containerd を Docker CLI のように
nerdctl は containerd プロジェクトの公式姉妹ツールだ。名前は「containerd 用の nerdy CLI」の略。2026年現在 2.x 系で、containerd さえ入っていれば Docker のコマンドをほぼそのまま使えるようにしてくれる。
なぜ nerdctl が必要か
containerd 自体の ctr は低レベルすぎる。ctr image pull → ctr container create → ctr task start の3段階を踏まなければならない。nerdctl は Docker CLI とほぼ同じコマンドで同じことをやる。
# Docker
docker run -d -p 8080:80 --name web nginx:latest
# nerdctl — ほぼ同一
nerdctl run -d -p 8080:80 --name web nginx:latest
# Docker Compose 互換
nerdctl compose up -d
nerdctl の強み — Docker が出来ないこと
- イメージ lazy pull —
nerdctl run --snapshotter=stargzでイメージのダウンロードが終わる前にコンテナが立ち上がる。大きなイメージで起動時間を劇的に短縮。2) イメージ暗号化 —nerdctl image encryptでイメージレイヤを暗号化。3) Rootless — Podman と同レベルにきれいなルートレス対応。4) P2P イメージ分散 — IPFS 統合、eStargz 形式など実験的機能。
nerdctl が使われる場所
- Lima/Colima/Finch/Rancher Desktop のデフォルト CLI。2) Kubernetes ノードでのデバッグ —
crictlが粗すぎるとき。3) containerd だけ入れたサーバで直接コンテナを運用する とき。
弱点
Docker CLI と90%互換だが10%は異なる動作をする。--platform の処理、一部の --volume オプション、ネットワークドライバの細部。Compose 互換は nerdctl compose で実装されたが Docker Compose の全オプションをサポートするわけではない。
第5章 · Lima / Colima — Mac 上の Linux VM の出発点
Lima は「Linux on Mac」の略だ。日本の LINE Corporation で始まり、今は CNCF Sandbox プロジェクト。2026年現在 1.0 系を超えて安定化し、macOS で Linux VM を立ち上げる事実上の基準となった。
Lima のアイデンティティ Lima 自体はコンテナランタイムではない。macOS で Linux VM を立ち上げ、その中でコンテナランタイムを動かす役割に徹する。デフォルトバックエンドは QEMU(x86)または Apple Virtualization Framework(arm64)。VM の中には containerd + nerdctl が自動で入る。
# Lima のインストールとデフォルト VM の起動
brew install lima
limactl start
# VM の中で nerdctl を使う
lima nerdctl run -d -p 8080:80 nginx
Lima の強み
- 宣言的設定 — VM 仕様を YAML で定義。
cpus: 4、memory: 8GiB、mounts: [~/projects]のような形式。2) 複数 VM を同時運用 — k8s クラスタ用 VM とコンテナ開発用 VM を分離可能。3) ポートフォワーディング自動化 — VM 内のポートをホストに自動で公開。
Colima のアイデンティティ Colima は「Containers on Lima」の略だ。Lima を一行コマンドで使えるようにするラッパー。2026年現在 0.8 系。開発者デスクトップ用 Lima のユーザ体験を Docker Desktop レベルまで引き上げた のがコア。
# Colima で一度に起動
brew install colima docker
colima start --cpu 4 --memory 8
# Docker CLI をそのまま使用 — Colima が Docker 互換ソケットを公開
docker ps
docker run -d nginx
Colima vs Lima を直接使う Lima は「VM ツール」で Colima は「Docker Desktop 代替ツール」というのがユーザの認識の違いだ。Colima は自動的に Docker ソケット互換を提供し、k3s オプションで Kubernetes を一発で立ち上げられる。
# k3s オプションで Kubernetes を一緒に起動
colima start --kubernetes --cpu 4 --memory 8
# kubectl が自動でコンテキストを掴む
kubectl get nodes
Colima の強み
- 完全無料 — MIT ライセンス。会社規模と無関係。2) Docker 互換 — Docker CLI をそのまま使いつつ、バックエンドだけ containerd に置き換え。3) k3s 統合 — 一つのコマンドで Kubernetes。4) 複数プロファイル —
colima start -p work、colima start -p personalのようにコンテキスト分離。
Colima の弱点
- GUI なし — ターミナルのみ。2) macOS の初回起動で VM ブートに10〜20秒。OrbStack の2秒と対比される。3) ファイルシステム共有性能が普通(virtiofs/sshfs ベース)。大きなモノレポでは体感する。4) Windows 未対応(Lima が Windows 未対応)。
第6章 · OrbStack — 商用だが速くて軽い
OrbStack は2023年にリリースされた商用 Docker Desktop 代替だ。作者は一人(Danny Lin)、会社名も OrbStack。macOS 専用。2026年現在 1.10 系。有料商用ソフトウェア だが個人利用は無料、会社はユーザあたり月8ドル程度。
なぜみんな OrbStack を好むのか 3つ。1) 速い — 起動2秒。Docker Desktop の30〜60秒とは比較にならない。2) 軽い — メモリ占有が Docker Desktop の3分の1程度。M2 Air でも圧迫がない。3) 滑らか — ファイルシステム共有がほぼネイティブ速度。virtiofs の上に独自最適化レイヤ。
技術的に何が違うのか OrbStack は(a)Apple Virtualization Framework を積極活用し、(b)Linux カーネルを独自パッチして macOS とのファイルシステム共有を最適化し、(c)Rosetta 2 を通じた x86 コンテナ実行を一級機能としてサポートする。M1/M2/M3 Mac で amd64 イメージをほぼ ARM ネイティブレベルで動かす。
機能 — Docker 互換 + Kubernetes + Linux マシン
- Docker 互換 — Docker CLI そのまま。Docker Desktop の Compose、ボリューム、ネットワークすべて動作。2) Kubernetes — ワントグルでオン/オフ。K3s ベース。3) Linux マシン — コンテナ以外に本格的な Linux VM をホスト。Ubuntu、Fedora、Debian、Arch、NixOS などを一行で開始。
# Docker コマンドをそのまま使う
docker run -d nginx
# Linux VM を起動
orb create ubuntu my-vm
orb -m my-vm # VM の中に入る
OrbStack の弱点
- クローズドソース + 商用。エンタープライズ導入はポリシーに引っかかる可能性。2) macOS 専用。Linux/Windows ユーザは使えない。3) 会社1人依存。Danny が去れば未来が揺らぐ(2026年現在チーム拡張中という発表はある)。4) 価格はユーザあたり月8ドル、Docker Desktop Business と同水準だが Docker よりはわずかに安い。
いつ OrbStack を選ぶか
- macOS 開発者で無料オプションの速度がもどかしいとき。2) 会社が Docker Desktop ライセンスを買うつもりなら OrbStack も同じ価格帯。3) ローカルで本当に重いコンテナワークロード(動画処理、ML 推論など)を回すとき。
第7章 · Finch — AWS のオープンソース統合パッケージ
Finch は2022年に AWS がリリースしたオープンソースコンテナツールだ。名前はガラパゴスのフィンチ鳥に由来(ダーウィン、進化、多様性)。2026年現在 1.5 系。
Finch のアイデンティティ Finch は新しいコンテナランタイムではない。既存のオープンソースツールを一つのパッケージにまとめたもの だ。中には: 1) Lima — VM レイヤ、2) containerd — ランタイム、3) nerdctl — CLI、4) BuildKit — ビルダ、5) Soci-snapshotter — lazy pull 対応。AWS が直接統合テストとパッケージングを行う。
# インストール — Homebrew または公式 .pkg
brew install --cask finch
finch vm init
finch vm start
# コマンドは nerdctl とほぼ同じ
finch run -d -p 8080:80 nginx
finch compose up -d
finch build -t myapp .
Finch の強み
- 完全無料 + オープンソース(Apache 2.0)。会社規模無関係、ライセンスの心配なし。2) AWS 統合 — ECR 認証、AWS Fargate 互換イメージビルドなどが滑らか。3) キュレーション済みスタック — Lima + containerd + nerdctl + BuildKit が検証済みの組み合わせで束ねられている。4) macOS・Windows・Linux すべて対応。
Finch の弱点
- GUI なし。Docker Desktop/OrbStack の GUI に慣れていると物足りない(2026年5月現在 Finch Desktop がベータ段階で開発中)。2) VM 起動が Lima 並みに遅い — 初回起動に10〜20秒。3) Kubernetes 統合が弱い — Rancher Desktop や Colima ほど滑らかではない。k8s を使うには Kind や Minikube を別途入れる必要がある。
いつ Finch を選ぶか
- AWS エコシステムで働き、ECR/Fargate が主ターゲットのとき。2) Colima よりも「公式サポート」感のある無料ツールがほしいとき。3) 会社ポリシー上、クローズドツール(OrbStack)や Docker ライセンス購入を避けたいとき。4) Linux/Windows ユーザ。
第8章 · Rancher Desktop — Kubernetes ユーザに最適
Rancher Desktop は SUSE(2020年 Rancher Labs を買収)が作ったオープンソース Docker Desktop 代替だ。2026年現在 1.18 系。Kubernetes フレンドリー がシグネチャ。
Rancher Desktop のシグネチャ
起動すると k3s Kubernetes クラスタが一緒に立ち上がる。kubectl が自動でコンテキストを掴む。Kubernetes バージョンも GUI からワンクリックで選択可能。1.28、1.29、1.30 などどのバージョンでも即時切替。
コンテナエンジン選択 GUI オプション一つでコンテナエンジンを変えられる。1) containerd + nerdctl — デフォルト。2) dockerd + docker — Docker CLI をそのまま使いたいなら。
# nerdctl モードのとき
nerdctl run -d nginx
# dockerd モードに変えると Docker CLI をそのまま
docker run -d nginx
# Kubernetes は常に一緒に立ち上がっている
kubectl get pods --all-namespaces
Rancher Desktop の強み
- 無料 + オープンソース(Apache 2.0)。会社規模無関係。2) Kubernetes 統合 — k3s、kubectl、Helm が一緒に入る。3) コンテナエンジン選択肢 — containerd と dockerd の間で切替可能。4) macOS・Windows・Linux すべて対応。
Rancher Desktop の弱点
- 重い — Lima ベース + k3s が常時動いており、メモリ8GB はベースで使う。M2 Air では負担。2) 起動時間 — k3s まで起動すると30秒以上。3) k8s を使わないなら過剰スペック。単純なコンテナ開発だけなら Colima や Finch のほうが軽い。
いつ Rancher Desktop を選ぶか
- Kubernetes 開発がメインのとき。2) k8s バージョン切替を頻繁にする必要があるとき(複数クライアントの異なるバージョン)。3) Rancher/SUSE エコシステムとの一貫性が必要なとき。4) GUI を望むが OrbStack のコストが負担なとき。
第9章 · Podman Desktop 深堀り — グラフィカルインタフェースのデーモンレス
Podman 本体は第3章で扱った。本章は Podman Desktop、つまりグラフィカルインタフェース側面に集中する。2026年現在 1.20 系。
Podman Desktop の役割
- Podman マシン(Lima または WSL2 ベース VM)を GUI で管理。2) コンテナ・イメージ・ボリューム・ネットワークの可視化。3) Compose ファイル実行。4) AI Lab — ローカルで LLM(Llama、Mistral など)をコンテナとして立ち上げ、OpenAI 互換 API で接続。5) Kubernetes — Kind/Minikube 統合。6) Docker Desktop Extension 互換 — 一部の Docker Desktop 拡張が Podman Desktop でも動く。
Podman の進化 — 2026年時点
- Quadlet — Podman コンテナを systemd ユニットとして宣言的に定義。Kubernetes YAML 風の systemd ネイティブコンテナオーケストレーション。2) Podman AI Lab — 1.20 で本格的に入った。モデル選択、量子化、推論コンテナを一発で。3) Kubernetes Play —
podman play kubeコマンドで Pod YAML を直接実行。
# Podman で Pod YAML を直接実行
podman play kube my-pod.yaml
# 逆に、実行中のコンテナから Pod YAML を生成
podman generate kube my-container > my-pod.yaml
Podman Desktop は Docker Desktop を本当に代替するか
- 単純なコンテナ開発 — ほぼ代替可能。
- Compose — 互換レイヤあるが一部オプションは異なる。
- 会社ポリシー上デーモンレス/ルートレスが要求される環境 — より優れている。
- Windows — WSL2 上でよく動くが Docker Desktop より設定がやや複雑。
- macOS — Apple Hypervisor ベースのマシンを自動で立ち上げる。OrbStack ほど速くはない。
第10章 · Apple Container Framework — Mac ネイティブコンテナの意味
2025年6月の WWDC で Apple が発表した新フレームワークだ。正式名称は「Container Framework」、パッケージ名 Apple.ContainerKit。2026年5月現在 macOS 15.4 以上で正式サポート、コマンドは container。
Apple Container のアイデンティティ Apple の視点: 「macOS で Linux コンテナを動かすのに別途 VM マネージャがなぜ必要なのか? 我々が直接作る。」 Virtualization.framework の上に OCI 互換コンテナランタイムを載せたものだ。コンテナごとにマイクロ VM を立ち上げる — 各コンテナが自分専用の Linux カーネルを持つ。
# インストール — macOS 15.4+ ではデフォルト同梱
container --version
# イメージ pull / run — Docker と似たインタフェース
container image pull docker.io/library/nginx:latest
container run -d -p 8080:80 nginx:latest
container ps
Apple Container のシグネチャ
- コンテナごとマイクロ VM — コンテナ間のカーネル分離が強い。kata-containers と類似のセキュリティ特性。2) 起動時間1秒未満 — Virtualization.framework の最適化。3) Mac ハードウェアへの直接アクセス — Neural Engine、GPU のようなアクセラレータをコンテナに公開。4) OCI 互換 — Docker Hub イメージをそのまま pull できる。
弱点 — 2026年5月時点
- macOS 15.4+ 専用 — 以前のバージョンの macOS、Linux、Windows では使えない。2) エコシステム未成熟 — Compose、Buildah、Skopeo のような周辺ツールとの統合がまだ。3) イメージビルド — BuildKit 互換だが一部のマルチステージビルドで問題報告。4) Kubernetes — k3s/minikube との統合はベータ。
Apple Container の意味 Apple がコンテナを OS 一級市民として取り込んだという事実自体が大きい。iOS/iPadOS への拡張可能性、Xcode との統合(シミュレータ + コンテナの統合デバッグ)、セキュリティモデルの一貫性。5年後には macOS コンテナユーザの多数が Apple Container をデフォルトで使う可能性は十分ある。ただし 2026年5月時点ではまだ実験的 で、OrbStack/Colima/Finch ほど成熟していない。
第11章 · 私たちのチームは何を選ぶべきか — 意思決定ツリー
上記7つのツールを同じ軸で並べると表はこうなる。価格・OS 対応・ライセンス・デーモン有無・Kubernetes 統合を一目で見る。
| ツール | 価格 | OS | ライセンス | デーモン | k8s |
|---|---|---|---|---|---|
| Docker Desktop | 月9〜24 USD(大企業) | Mac/Win/Linux | 商用 | dockerd | Kind 別途 |
| Podman Desktop | 無料 | Mac/Win/Linux | Apache 2.0 | なし | 統合 |
| OrbStack | 月8 USD(会社) | Mac のみ | 商用 | 独自 | 統合(k3s) |
| Colima | 無料 | Mac/Linux | MIT | なし | k3s オプション |
| Finch | 無料 | Mac/Win/Linux | Apache 2.0 | なし | 別途 |
| Rancher Desktop | 無料 | Mac/Win/Linux | Apache 2.0 | なし | 統合(k3s) |
| Apple Container | 無料 | Mac のみ(15.4+) | Apple | なし | ベータ |
シナリオ1 — 1人 Mac 開発者、無料希望 第一候補: Colima。軽い、MIT、Docker CLI そのまま。第二候補: Finch。AWS エコシステムならより滑らか。macOS 15.4+ で実験的に使いたければ Apple Container。
シナリオ2 — 1人 Mac 開発者、速度重視 第一候補: OrbStack。起動2秒、メモリ軽い。個人は無料。第二候補: Apple Container(macOS 15.4+)。
シナリオ3 — 会社、50人以上、ライセンス整理必要 第一候補: Podman Desktop。無料、オープンソース、エンタープライズ利用可能。第二: Finch または Rancher Desktop。Docker Desktop ライセンスを買うつもりなら OrbStack も同じ価格帯だが macOS 専用という制約。
シナリオ4 — Kubernetes 学習 / 開発 第一候補: Rancher Desktop。k3s 統合、k8s バージョン切替、kubectl/Helm が一緒に入る。第二: Colima --kubernetes、OrbStack の k8s トグル。
シナリオ5 — CI 環境、root 権限制約、セキュリティ重視 第一候補: Podman + Buildah。デーモンレス、ルートレス、systemd 統合。第二: nerdctl + BuildKit(ルートレスモード)。
シナリオ6 — Windows 開発者 第一候補: Podman Desktop または Rancher Desktop。どちらも WSL2 ベース。Docker Desktop の有料ライセンスを避けたいとき。OrbStack と Apple Container は不可。
シナリオ7 — 本当に重いワークロード(動画/ML/大容量データ) 第一候補: OrbStack(Mac)または Podman ネイティブ(Linux 直接)。VM オーバヘッドを最小化。Apple Container も候補。
シナリオ8 — 会社の標準化、一つのツールで統一したい 第一候補: Podman Desktop または Rancher Desktop。3つの OS すべて対応、オープンソース。第二: Finch。AWS 親和なら強み。
意思決定チェックリスト
- 会社規模とライセンス — Docker Desktop の250人/1,000万ドル閾値を超えるか? 超えるなら無料オプションまたは OrbStack/Finch。
- 主 OS — Mac だけなら選択肢が広い。Linux/Windows も一緒に対応する必要があるなら Colima は外れる。
- Kubernetes 比重 — 日常的に使うなら Rancher Desktop または Colima+k8s。
- GUI 必要性 — チームメンバが CLI に慣れていなければ Podman Desktop、OrbStack、Rancher Desktop。
- 速度 vs コスト — OrbStack は速いが会社利用は有料。Colima/Finch は無料だが起動が遅い。
- セキュリティポリシー — デーモンレス/ルートレスが要求されれば Podman。
- 長期的な賭け — Apple Container は5年後 macOS 標準になる可能性あり。今学んでおく価値はある。
第12章 · 参考 / References
ツール別の公式ドキュメントとコア資料だ。URL はすべて2026年5月時点で生きている場所のみ選んだ。
コンテナ標準 / ランタイム
- OCI(Open Container Initiative)スペック: https://opencontainers.org/
- containerd 公式: https://containerd.io/
- runc GitHub: https://github.com/opencontainers/runc
- crun GitHub: https://github.com/containers/crun
- CRI-O 公式: https://cri-o.io/
Docker
- Docker 公式: https://www.docker.com/
- Docker Subscription Service Agreement 発表(2021-08-31): https://www.docker.com/blog/updating-product-subscriptions/
- BuildKit GitHub: https://github.com/moby/buildkit
Podman / Buildah / Skopeo
- Podman 公式: https://podman.io/
- Podman Desktop: https://podman-desktop.io/
- Buildah: https://buildah.io/
- Skopeo GitHub: https://github.com/containers/skopeo
- Quadlet ドキュメント: https://docs.podman.io/en/latest/markdown/podman-systemd.unit.5.html
nerdctl
- nerdctl GitHub: https://github.com/containerd/nerdctl
Lima / Colima
- Lima GitHub: https://github.com/lima-vm/lima
- Colima GitHub: https://github.com/abiosoft/colima
OrbStack
- OrbStack 公式: https://orbstack.dev/
Finch
- Finch 公式: https://runfinch.com/
- Finch GitHub: https://github.com/runfinch/finch
Rancher Desktop
- Rancher Desktop 公式: https://rancherdesktop.io/
- Rancher Desktop GitHub: https://github.com/rancher-sandbox/rancher-desktop
Apple Container Framework
- Apple Developer "Virtualization" ドキュメント: https://developer.apple.com/documentation/virtualization
- WWDC25 セッション "Meet Container Framework": https://developer.apple.com/videos/play/wwdc2025/
その他のコンテナビルダ
- kaniko GitHub: https://github.com/GoogleContainerTools/kaniko
- ko GitHub: https://github.com/ko-build/ko
結びの言葉
Docker は2013年にコンテナの使いやすさを開いた。それは偉大な仕事だった。2021年に Docker は自社製品の有料化でエコシステムに亀裂を作り、その亀裂が5年で7つの異なるツールを育てた。2026年の結果は明らかだ。選択肢が増え、コンテナユーザが勝つ。
明日新しいプロジェクトを始めるなら私はこう決める。1人 Mac 開発なら OrbStack(速い)または Colima(無料)。会社規模なら Podman Desktop または Rancher Desktop。AWS 中心なら Finch。そして Apple Container を週に一度触りながら未来に備える。
5年後この記事の表は再び変わっているだろう。しかし「Docker は標準ではない、ツール選択はチームの文脈次第である」という命題は、もはや後退しない。