Container Machine: Mac上の永続的なLinux環境

Appleの container ツールはWWDC週に1.0へと到達し、その目玉機能はMac開発者が長年回避策で対処してきたギャップに応えるものです。それが container machine、macOSの一部のように振る舞う永続的なLinux環境です。² これを紹介したWWDCセッションは、その狙いを一文に凝縮しています。「Container machineは、コンテナのように高速かつ軽量であり、仮想マシンのように永続的です」¹ リポジトリとdotfilesは両側で利用でき、ログインユーザーはMacのアカウントと一致し、マシンはセッションをまたいでファイルシステムを保持します。そのため、火曜日にセットアップしたLinuxツールチェーンは金曜日にもそのまま残っているのです。³

セッション389「Discover container machines」より。

TL;DR

• container machine は container 1.0.0に含まれ、WWDC週にGitHubで公開されました。Appleが WWDC 2025 でオープンソース化した Containerization フレームワークの上に、「ホストと緊密に統合された、長寿命のLinux環境」を提供します。²
• コンテナが「アプリケーションをモデルとしている」のに対し、container machineは「Linux環境をモデルとしています」。イメージ自体のinitシステムを実行し、ファイルシステムの変更を永続化し、標準的なOCIイメージから作成されます。³
• 差別化要因はホスト統合です。LinuxのログインユーザーはMacのアカウントと一致してパスワードなしの sudo が使え、ホームディレクトリはマシン内部にマウントされます。⁴ さらに、対話シェルを開くと、macOSで作業していたのと同じ作業ディレクトリにそのまま入れます。¹
• サブコマンドの全セットは create、run、list、inspect、set、set-default、logs、stop、delete で、短縮エイリアスとして m が使えます。⁴
• 1.0リリースでは、アップグレード前に知っておくべき破壊的変更が1つあります。~/.config/container/config.toml のTOML設定ファイルが、従来のUserDefaultsベースのシステムプロパティを置き換え、container system property サブコマンドは廃止されました。²

アプリケーションのサンドボックスではなく、Linux環境

Appleのドキュメントは境界を明確に引いています。「コンテナは通常、アプリケーションをモデルとしています。container machineはLinux環境をモデルとしています」³ この違いは3つの挙動に現れます。container machineはイメージ自体のinitシステム（systemd や openrc など）を実行するため、長時間稼働するサービスを登録し、本物のプロセススーパーバイザーの下でアプリケーションをテストできます。systemctl start postgresql は、Linuxマシン上と同じように動作します。³ また変更を永続化するため、インストールしたツールはプロセスとともに消えることなく、時間をかけて積み重なっていきます。¹ さらに、コンテナが使うのと同じOCIイメージから起動するため、container build で構築したイメージは、そのままマシンの出発点としても使えます。¹

この機能を実装したプルリクエストは、その動機を率直に述べています。container は各ワークロードを一時的なVMで実行するため、1.0以前にはログインして作業できる永続的なLinux環境を保持する組み込みの手段がありませんでした。⁴ 内部的には、各container machineは依然としてContainerizationの扱いを受けます。つまり、VMベースの分離を備えた独自の軽量な仮想マシンと、このフレームワークが核として設計したサブ秒の起動時間を持つのです。¹

セッションは設計目標をワークフローの観点で説明しています。macOSとLinuxの切り替えは容易であるべきで、環境はすばやく作成できるべきであり、「すばやい作成により、依存関係やツールチェーンの競合を心配することなく、複数のプロジェクトがそれぞれ専用の環境を持てます」¹ ターゲットとなるディストリビューションごとに1台のマシンを用意するのは意図されたパターンであり、各マシンはMac上の同じホームディレクトリとdotfilesを見ます。³

ループ：Macで編集し、Linux内部でビルドする

セッションのデモは Vapor のWebサーバーであり、そこで示されるワークフローこそが核心です。¹ プロジェクトはmacOS上の Xcode で編集します。ビルドと実行は、Swiftツールチェーンをインストールしたcontainer machine内部で行われます。Mac上の Safari は、稼働中のサーバーをIPアドレスとポートで読み込みます。発表者が Icon Composer からアプリアイコンをMac上で再エクスポートしてファイルを上書きすると、ブラウザを更新するだけでコピー手順なしに新しいアセットが表示されます。マシンとMacが同じファイルを共有しているからです。¹

Appleのドキュメントはこのパターンを一般化しています。リポジトリはmacOS上の $HOME に存在し、マシン内部にマウントされるため、macOSネイティブのツール（プロファイラ、ブラウザ、GUIデバッガ）は、Linux環境が見るのと同じファイルを見ます。ドキュメントが述べるとおり、「ビルドした」と「検査している」の間にコピー手順は存在しないのです。³

ホスト統合は共有マウントよりもさらに深く及びます。マシンはMacのユーザー名と一致するLinuxユーザーを自動的に作成し、それにパスワードなしの sudo を付与し、現在の作業ディレクトリをミラーリングします。そのため whoami と pwd は内部でも外部でも同じ答えを返します。¹ 答えが変わる唯一のコマンドは uname です。Mac上では Darwin、マシン内部では Linux となります。¹

初日に直面するであろう摩擦が1つあり、ぶつかる前に知っておく価値があります。container machineは分離されたネットワークを持っており、内部のサーバーは、Mac上のブラウザが到達できるようになる前に外部インターフェースでリッスンする必要がある、とセッションは明言しています。¹ デモはこれを、あなたも実際に取る方法で処理します。container machine list は各マシンのIPアドレスを名前やリソースと並べて表示し、サーバー設定はそのアドレスにバインドし、SafariはマシンのIPとポートでアプリに到達します。¹ マシンからトラフィックを提供するワークフローでは、このIPアドレスの手順を見越して計画してください。

コマンド

クイックスタートは4行です。³

container machine create alpine:latest --name dev
container machine run -n dev whoami       # your host username, not root
container machine run -n dev pwd          # your Mac home directory, mounted in
container machine run -n dev              # interactive shell

container machine run は二役をこなします。コマンドを指定すれば一度実行して終了し、指定しなければ対話シェルを開き、マシンが停止していればまず起動します。³ デフォルトのマシンを設定すれば、すべての呼び出しから -n フラグを省けます。

container machine set-default dev
container machine run                     # operates on dev

管理はおなじみの動詞で行います。ls、inspect、logs、stop、rm で、マシンを削除するとその永続ストレージも削除されます。³ リソースは作成後にも container machine set -n dev cpus=4 memory=8G で調整でき、次回の停止と起動で反映されます。メモリのデフォルトはホストメモリの半分で、ホームマウントは rw（デフォルト）、ro、none のいずれかにできます。³ どのコマンドもエイリアス m を受け付けるため、m run や m ls が使えます。⁴

独自のマシンイメージを持ち込む

/sbin/init を含むLinuxイメージであれば、どれでもcontainer machineとして動作します。³ Appleのドキュメントには、ubuntu:24.04 を systemd、OpenSSH、一般的なコマンドラインツールを備えたマシンイメージに変換し、軽量VM内部では意味をなさないsystemdユニットをマスクする、完成したDockerfileが用意されています。³ それを container build でビルドし、そのタグを container machine create に渡します。

プロビジョニングには逃げ道があります。デフォルトでは、container は初回起動時に組み込みのセットアップスクリプトを実行し、一致するユーザーを作成します。イメージ内の /etc/machine/create-user.sh にある実行可能ファイルがそのスクリプトを置き換えます。これは初回起動時にrootとして一度だけ実行され、CONTAINER_USER、CONTAINER_UID、CONTAINER_GID、CONTAINER_HOME、CONTAINER_MACHINE_ID が設定されます。これにより、組織は独自のユーザーセットアップを共有のベースイメージに組み込めます。³

1.0のその他の変更点、破壊的変更を含む

マシン機能がこのリリースの目玉ですが、1.0には既存ユーザーに影響する変更も含まれています。²

破壊的なものは設定です。TOMLファイルがUserDefaultsベースのシステムプロパティを置き換え、container system property get と set のサブコマンドが削除されました。² サービスは起動時に ~/.config/container/config.toml を、先勝ち（first-match-wins）の優先順位で読み込みます（ユーザーファイル、次にパッケージインストールに同梱される任意のファイル、次にハードコードされたデフォルト）。変更を反映するにはサービスの再起動が必要です。⁶

利便性の追加点としては、ファイルをコピーする container cp コマンド、container run の --stop-signal オプション、そしてコンテナ・イメージ・ネットワーク・ボリュームにわたる ls と inspect コマンドの整理された構造化出力（JSON、YAML、TOML）があります。² ネットワークには、XPC接続をリースとして利用しIPアドレスのリークを止める正確性の修正が入りました。² バージョン0のXPC APIとの互換性は削除され、バージョン管理されたAPIは後のリリースで提供される予定です。²

要件は0.x系列から変わりません。Apple silicon を搭載し、macOS 26 を実行するMacです。メンテナーは、macOS 26 で再現できない問題には通常対応しないと述べています。⁵

エージェントのワークフローが注目すべき理由

これは私の立場からの解釈であり、Appleの主張ではありません。container machineは、コーディングエージェントが求める環境の形そのものです。Mac上で動作するエージェントは、ホストに触れずにビルドを実行し、サーバーを動かし、依存関係をインストールする場所を必要とします。すばやく作成でき、本物のVM境界で分離され、あるセッションでインストールしたツールチェーンが次のセッションまで生き残る程度には永続的な場所です。これまでMacでの答えは、Docker Desktop スタイルのVM（重量級で、1つの大きな共有環境）か、一時的なコンテナ（分離されているが記憶しない）のいずれかでした。バージョン管理されたOCIイメージから作成され、リポジトリがマウントされ、内部でパスワードなしの sudo が使える、プロジェクトごとのマシンは、Linuxホスト上ですでに機能しているエージェントのサンドボックスの仕組みと一致します。

同じ性質は、純粋なクロスプラットフォーム作業にも役立ちます。サーバーサイドの Swift が明らかな恩恵を受けます。セッションのデモは Vapor であり、Foundation Models フレームワークはこの夏にオープンソース化されLinuxをサポートするため、「私のSwiftコードはUbuntuで動くのか」をテストする環境は、いまや container machine create 1回分の距離にあります。Windowsを使ったことのある人なら誰もが思い浮かべる比較が WSL であり、統合の方向性は同じです。シェル一つでアクセスできる本物のLinuxカーネルがあり、ファイルは両側で見えます。Appleのバージョンは、イメージベースのワークフローをすでに備えて登場しました。

FAQ

container machineとは何ですか？

container machineは、macOS上の永続的なLinux環境であり、Appleのオープンソース container ツールの機能として、バージョン1.0.0から提供されます。² Containerization フレームワークを介して独自の軽量な仮想マシン上で動作し、標準的なOCIイメージから起動し、イメージのinitシステムを実行し、セッションをまたいでファイルシステムの変更を永続化します。¹ ホスト統合により、ホームディレクトリが内部にマウントされ、LinuxユーザーがMacのアカウントと一致してパスワードなしの sudo が使え、作業ディレクトリが境界をまたいで一貫して保たれます。⁴

通常のコンテナとどう違うのですか？

Appleのドキュメントはこれを一文で表しています。コンテナは「アプリケーションをモデルとしている」のに対し、container machineは「Linux環境をモデルとしています」³ 通常の container run ワークロードは一時的でプロセス中心です。マシンはステートフルで、systemd や openrc を実行し、コンテナ並みの作成速度を持つVMのように、時間をかけて何度も訪れることを想定しています。¹

何が必要ですか？

Apple silicon を搭載し macOS 26 を実行するMacで、container ツール全般と同じ要件です。⁵ このツールはGitHubでオープンソースとして公開されており、Swiftで書かれています。⁵

1.0へのアップグレードで何か壊れますか？

1つあります。システム設定がUserDefaultsベースのプロパティから ~/.config/container/config.toml のTOMLファイルに移行し、container system property get/set サブコマンドが削除されました。² 1.0のリリースノートには、この移行のためのチュートリアルへのリンクがあります。² バージョン0のXPC API互換性も削除されており、APIに対してクライアントを構築していた場合には影響します。²

container machineは、このWWDCが語り続けてきたのと同じ物語に収まります。クロスプラットフォーム開発とエージェント開発の本格的な拠点としてのMacという物語です。MLXでMac上のエージェントAIを実行するはその物語のモデル提供の側面を扱い、Swiftの新機能（2026）はSwift-on-Linuxを第一級のターゲットにする言語面の取り組みを扱います。シリーズ全体のハブは Apple Ecosystem Series です。

References