Apple container v1 と container machine を整理する

はじめに

2026年6月9日、Apple container¹ v1 がリリースされた🎉

Mac で Linux コンテナを動かす手段としては、Docker Desktop がよく使われる。 では、Apple container は Docker Desktop と何が違うのか。

この記事では、Apple container が何をするツールなのかを整理する。 特に、v1.0.0 で追加された container machine を中心に見る。

Apple container では、OCI イメージを pull / run / push できる。 Dockerfile や Containerfile から OCI イメージを build することもできる。 CPU、メモリ、環境変数、ユーザ、capability、mount、ポート公開など、一般的なコンテナ実行で使う機能も用意されている。

一見すると、Docker Desktop と同じ用途のツールに見える。 しかし、実行方式を見ると設計思想はかなり違う。

Apple container と Docker Desktop の違い

README では、Apple container は Mac 上で Linux コンテナを軽量 VM として作成・実行するツールだと説明されている¹。

Apple container の技術概要でも、Containerization パッケージを使い、作成するコンテナごとに軽量 VM を実行すると説明されている²。 つまり、Apple container は 1 container = 1 lightweight VM に近い設計である。

一方で、Docker Desktop for Mac は、Docker Desktop が管理する軽量 Linux VM の中で Docker daemon とコンテナを動かす構成である。 Docker 公式も、Docker daemon とコンテナは Docker が管理する軽量 Linux VM の中で動くと説明している³。

つまり、Apple container は「コンテナを VM として動かす」設計に近い。 Docker Desktop は「VM の中でコンテナを動かす」設計に近い。

ここが Apple container の面白いところである。 単に Docker Desktop の Apple 版と見るより、OCI コンテナの UX を持った VM-per-container ランタイムとして見た方が分かりやすい。

container machine とは

v1.0.0 で追加された大きな機能として、container machine がある。 v1.0.0 のリリースノートでも、container machine は長く使う Linux 環境を作る機能としてハイライトされている⁴。

通常の container run は、OCI イメージからコンテナを起動し、指定したプロセスを実行するためのコマンドである。 一方で container machine は、OCI イメージを元に、永続的な Linux 環境を作るための機能である。

公式のコマンドリファレンスでは、container machine create はイメージから container machine を作成して起動するコマンドとして説明されている。 container machine run は、必要に応じて machine を起動し、その中でコマンドを実行するコマンドである⁵。

container machine create alpine:3.22 --name my-machine
container machine run -n my-machine
container machine run -n my-machine uname -a

container run が「コンテナイメージからプロセスを実行する」ものだとすると、container machine は「コンテナイメージを元に、使い続ける Linux 環境を作る」ものに近い。

container run と container machine run の違い

container run と container machine run は、どちらも OCI イメージを元に Linux 環境を動かす。 しかし、用途は異なる。

container run は、イメージからコンテナを起動し、指定したプロセスを実行するためのコマンドである。 Web サーバを起動する、ビルドを実行する、一時的にシェルを開く、といった使い方に向いている。

一方で container machine run は、事前に作成した container machine の中でコマンドを実行する。 コマンドを指定しなければ、対話的なログインシェルが開かれる。 また、container machine は停止後も状態を保持するため、従来の軽量 VM や開発用 Linux 環境に近い使い方ができる。

container machine create では、--cpus、--memory、--home-mount を指定できる。 --home-mount の既定値は rw であり、ホストのホームディレクトリを読み書き可能な状態でマウントする⁶。

初回起動時には、ホスト側のユーザに対応する Linux ユーザが作られる。 そのユーザには passwordless sudo が設定される。 この挙動からも、container machine は単発のアプリケーション実行より、ログインして作業する Linux 環境に近い。

どういう用途に向いていそうか

短命なアプリケーション実行には container run が向いている。 たとえば、Web サーバを起動する、CI に近いビルドを再現する、一時的に別のディストリビューションでコマンドを試す、といった用途である。

一方で、シェルに入って継続的に作業する用途には container machine が向いていそうである。 たとえば、次のような使い方である。

• Mac 上に軽量な Linux 作業環境を作る
• 検証用の Linux 環境を OCI イメージから作る
• 壊してもよいトラブルシュート環境を用意する
• 開発用ツールを Mac 本体から分けて入れる

これは、まさに自分たちが欲しかった機能に近い。 Mac 上に、壊してもよい Linux 作業環境を作れる。 普段使いの macOS 環境を汚さず、必要なら作り直せる。 それだけでも、検証やトラブルシュートの道具としてかなり魅力がある。

たとえば ICTSC や HITSC のような、隔離環境や短命 VM を扱う問題基盤を考えると、container machine は特に面白い。 将来、ICTSC の問題基盤として Apple silicon Mac を使う回があってもおかしくない。 コンテナの UX を保ちながら、実行単位は VM に寄せている。 そのため、単なる Docker Desktop の置き換えというより、macOS 上で軽量な Linux 環境を扱うための新しい選択肢として見ると理解しやすい。

注意点

Apple container は、Apple silicon Mac 向けのツールである。 README では、サポート対象は macOS 26 と説明されている。 macOS 15 でも動作する場合はあるが、ネットワークなどに制限がある¹。

また、Apple container はコンテナごとに軽量 VM を使う。 そのため、Docker Desktop と完全に同じものではない。

この設計は隔離の面で分かりやすい。 一方で、メモリやネットワークの挙動は、通常の Linux ホスト上のコンテナとは違って見える可能性がある。 技術概要では、macOS の Virtualization.framework におけるメモリバルーニングが部分対応であり、コンテナ内 Linux で解放されたメモリページがホストに返らない場合があると説明されている²。

つまり、Docker CLI、Docker Compose、Kubernetes との統合を含めた開発体験をそのまま置き換えるものとして見ると、少しずれる。 OCI イメージを Mac 上でより強く隔離して実行するための Apple 製ランタイムとして見る方がよい。

特に container machine は、Docker Desktop の代替というより、OCI イメージを元に作れる軽量な Linux 作業環境として見ると理解しやすい。

おまけ: Kata Containers の kernel が出てくる

Apple container で container system start を実行すると、初回に default kernel のインストールを求められた。

hitto@hot:~ $ container system start
Launching container-apiserver...
Testing access to container-apiserver...
Verifying machine API server is running...
No default kernel configured.
Install the recommended default kernel from [https://github.com/kata-containers/kata-containers/releases/download/3.28.0/kata-static-3.28.0-arm64.tar.zst]? [Y/n]: y
Installing kernel...

ここで Kata Containers の release が出てくる。 一瞬、Apple container は Kata Containers なのか、と思う。

しかし、正確には少し違う。 Apple の Containerization README では、macOS 上で軽量 VM を起動するには Linux kernel が必要であり、Kata Containers project がコンテナ向けに最適化された Linux kernel を提供していると説明されている⁷。 その kernel image は、Kata Containers の配布物内の /opt/kata/share/kata-containers/ にある vmlinux.container である。

つまり、Apple container / Containerization は、Linux VM を起動するための推奨 default kernel として、Kata Containers の static release に含まれる kernel を利用している。

ただし、これは Kata Containers runtime そのものを使っているという意味ではなさそうである。 Apple container の実行基盤は Apple の Containerization package であり、macOS の Virtualization.framework などを使ってコンテナごとに軽量 VM を起動する構成である²。

整理すると、次のようになる。

• Kata Containers の pre-built kernel を推奨 kernel として利用できる
• その kernel は、Kata Containers の static release に含まれる vmlinux.container である
• ただし、Kata runtime や containerd-shim-kata-v2 をそのまま使っているわけではない

この点は誤解しやすい。 Apple container は Kata Containers そのものではない。 一方で、推奨 default kernel として Kata Containers の配布物に含まれる kernel を利用している。

まとめ

Apple container は、単に Docker Desktop の Apple 版というより、OCI コンテナを軽量 VM として実行する Apple 製のランタイムである。

Docker Desktop が「Linux VM の中でコンテナを動かす」方向だとすると、Apple container は「コンテナを軽量 VM として動かす」方向に近い。

さらに v1.0.0 では container machine が追加された。 これにより、短命なコンテナ実行だけでなく、永続的な Linux 作業環境として使う方向も見えてきた。

今後、Mac 上の開発環境や検証環境として、Docker Desktop などとどう使い分けられていくのかが気になる。

参考