Apple純正Linuxコンテナ実行基盤「container」徹底解説：1コンテナ1軽量VMの設計思想とDocker互換性・使い分け
macOS 上で Linux コンテナを動かすための選択肢といえば、長らく Docker Desktop や軽量互換環境の OrbStack、オープンソースの Colima（Lima） といったサードパーティ製ツールが主流でした。
しかし、Apple 自身が WWDC 2025 でオープンソース（Apache 2.0 ライセンス）として公開し、WWDC 2026 で v1.0（および永続環境「Container Machine」） へと進化させた純正プロジェクト apple/container（および基盤フレームワーク apple/containerization）の登場により、Apple Silicon Mac におけるコンテナ実行のアーキテクチャは新しいフェーズに入っています。
一方で、現場の開発者が最も気になるのは 「普段使っている Docker のイメージや Dockerfile、CLI オプション、docker compose とどの程度互換性があるのか？」 という点ではないでしょうか。
本記事では、Apple 純正のコンテナツール container の内部アーキテクチャ（1コンテナ＝1軽量VMモデル）から、Docker との具体的な互換性マトリクス（そのまま動くもの・仕様が異なるもの・ブリッジが必要なもの）、そして OrbStack 等との実践的な使い分けまでを徹底解説します。
1. Apple 純正「container」とは？2つのオープンソースリポジトリの関係
Apple が GitHub 上で公開しているコンテナ関連プロジェクトは、役割に応じて以下の 2つのリポジトリ に分かれています。いずれも Swift でゼロから記述されており、Apple Silicon（arm64：M1 / M2 / M3 / M4 以降）と macOS 標準の Virtualization.framework に徹底して最適化されています。
| リポジトリ名 | 役割・レイヤー | 主な機能 |
|---|---|---|
apple/containerization | 低レベル基盤（Swift パッケージ） | OCIイメージの取得・展開、ext4 ファイルシステム構築、Virtualization.framework を用いた極小 Linux VM の起動、ゲスト内 init（vminitd）との通信を担うコアライブラリ。 |
apple/container | ユーザー向け CLI ツール | containerization を内部で利用し、開発者がターミナルから container run や container build、container machine を実行できるようにしたコマンドラインツールおよびバックグラウンドサービス。 |
2. 従来の Docker と何が違う？「1コンテナ＝1軽量VM」の革新性
macOS には Linux カーネルが存在しないため、Linux コンテナを動かすには必ずどこかで仮想マシン（VM）を起動する必要があります。ここで、従来のツール（Docker Desktop / OrbStack / Colima）と Apple の container では、仮想化の粒度（アーキテクチャ）が根本的に異なります。
従来方式（単一の大規模 Linux VM 共有モデル）
Docker Desktop や Colima などの従来方式では、まず macOS 上に 1つの大きな Linux 仮想マシン を起動し、その VM の内部で containerd や dockerd を動かして、複数のコンテナを Linux の Namespace / cgroups で論理的に隔離（相乗り）させます。
- 課題：コンテナが1つしか動いていなくてもベースとなる Linux VM 全体のリソースが必要になるほか、万が一コンテナ内のプロセスがカーネルの脆弱性を突いて脱出（コンテナエスケープ）した場合、同じ VM 上で動いている他のすべてのコンテナやマウントされたホストのファイルに影響が及ぶリスクがあります。
Apple container 方式（VM-per-Container：1コンテナ＝1マイクロVMモデル）
一方、Apple の container は 「起動するコンテナ1つにつき、専用の超軽量な仮想マシン（マイクロVM）を1つ割り当てる」 というアプローチ（AWS の Firecracker や Kata Containers に近い思想）を採用しています。
- macOS (Host)
- 1つの巨大な Linux VM（共有カーネル）
- Container A (Web)
- Container B (DB)
- Container C (Untrusted Tool)
- ※同一カーネル空間を共有
- 1つの巨大な Linux VM（共有カーネル）
- macOS (Host / Virtualization.framework)
- 軽量マイクロVM 1（最小Linuxカーネル + vminitd）
- Container A
- 軽量マイクロVM 2（最小Linuxカーネル + vminitd）
- Container B
- 軽量マイクロVM 3（最小Linuxカーネル + vminitd）
- Container C
- ※ハードウェア仮想化レベルで完全に分離・独立
- 軽量マイクロVM 1（最小Linuxカーネル + vminitd）
「VMを毎回起動するのに、なぜサブ秒（1秒未満）で立ち上がるのか？」
「コンテナごとに VM を作ったら起動が遅くなるのでは？」と思うかもしれませんが、Apple は以下の4つの技術要素を組み合わせることで、コンテナと同等のサブ秒（数百ミリ秒）起動 を実現しています。
- 極限まで削ぎ落とされた最小構成の Linux カーネル：一般的なディストリビューションの起動処理（複雑な systemd の初期化など）を省き、コンテナ実行に必要なドライバだけを組み込んだ専用カーネルを使用。
- Swift 製の超軽量 init プロセス
vminitd：ゲスト VM 内のPID 1（最初のプロセス）として、Swift の Static Linux SDK（muslベース）でビルドされた極小のvminitdが直接起動します。ホスト側とは gRPC over vsock（仮想ソケット） で高速に直結されます。 - OCI イメージの
ext4ブロックデバイス直接マウント：Docker Hub などから取得した OCI 標準イメージを Swift コード側でext4形式に展開し、virtio-blk（ブロックデバイス）およびvirtiofs（ディレクトリ共有）として VM に直接アタッチします。 - 専用 IP アドレスの自動割り当て（ポートフォワーディング不要）：macOS の
vmnetフレームワークにより、各コンテナ（VM）に固有のローカル IP アドレスが割り当てられます。面倒なポートマッピング（-p 8080:80）を意識せず、コンテナの IP へ直接アクセス可能です。
3. 【重要】Docker との互換性はどこまであるのか？詳細検証
apple/container は「Docker のクローン（Docker API の再実装）」ではなく、「OCI（Open Container Initiative）標準仕様に準拠した Apple 独自のコンテナランタイム」 として設計されています。
そのため、「イメージや Dockerfile、基本的な CLI オプションはほぼそのまま使える」 一方で、「Docker デーモン（docker.sock）や docker compose に依存する周辺ツールはそのままでは動かない（またはブリッジが必要）」 という明確な境界線があります。
3.1 Docker 互換性一覧マトリクス
| 機能・要素 | 互換性レベル | apple/container での挙動・詳細 |
|---|---|---|
| Docker Hub 等のイメージ | ◎ 完全互換 | OCI 準拠。docker.io、ghcr.io、AWS ECR 等の標準レジストリからそのまま Pull / Push 可能。 |
Dockerfile によるビルド | ◎ 高い互換性 | container build -t ... . で既存の Dockerfile をそのままビルド可能（内部で BuildKit シムが動作）。 |
x86_64 (amd64) イメージ実行 | ◎ 完全対応 | macOS の Rosetta 2 とハードウェアレベルで統合。--arch amd64 指定で x86_64 イメージも高速に実行・ビルド可能。 |
基本 CLI フラグ（run 等） | ◯ ほぼ共通 | -it, --rm, -d, -e (--env), --env-file, -v (--volume), -p (--publish), -w (--workdir) 等は Docker と同じ感覚で利用可能。 |
レジストリ認証（login） | ◯ 対応 | container registry login でプライベートレジストリへの認証が可能（認証情報は macOS キーチェーンと安全に連携）。 |
| ポート公開とネットワーク | △ 仕組みが異なる | -p 8080:80 も使えるが、標準で各コンテナに専用ローカル IP（192.168.64.x）が割り当てられるため、本来はポート変換なしで直接通信する設計。 |
/var/run/docker.sock | × 非搭載（要ブリッジ） | 標準では Docker ソケットを持たず macOS の Mach XPC で通信する。必要なら Socktainer 等のブリッジツールを導入する。 |
docker compose | × 本体には非搭載 | docker-compose.yml を直接読み込むコマンドは標準搭載されていない（後述の代替アプローチが必要）。 |
--privileged / DinD | × 制限あり | 1コンテナ＝1マイクロVM構造のため、ホストカーネル空間を共有する前提の特権モードやソケット共有型 Docker-in-Docker は動作が異なる。 |
3.2 そのまま使えるもの①：OCI イメージ・Dockerfile・Rosetta 2（amd64）
既存の Docker イメージと Dockerfile
Docker Hub 上の公式イメージ（alpine, ubuntu, postgres, redis, node, python など）は OCI 標準フォーマットであるため、1ミリも変更することなく container run でそのまま起動できます。
また、イメージのビルドについても、Apple は内部で BuildKit を動かす専用のビルダーコンテナ（container-builder-shim）を統合しているため、手元のプロジェクトにある Dockerfile を書き換えることなく container build コマンドでそのままビルド できます。マルチステージビルド（FROM ... AS builder）も問題なく動作します。
x86_64 (amd64) コンテナの Rosetta 2 高速実行
Apple Silicon Mac で開発していると、「古いライブラリや社内ツールが linux/amd64（Intel/AMD系）用の Docker イメージしか提供されていない」という場面に遭遇します。
apple/container は Virtualization.framework の Rosetta 2 Linux バイナリ変換機能と直結しており、--arch amd64 オプションを付けるだけで、QEMU エミュレーションよりもはるかに高速に amd64 コンテナを実行・クロスビルドできます。
# Apple Silicon 上で x86_64 (amd64) 版のコンテナを Rosetta 2 経由で高速実行
container run --rm -it --arch amd64 ubuntu:24.04 uname -m
# 出力: x86_64
# amd64 ターゲット向けに Dockerfile をビルドする場合
container build --arch amd64 -t my-legacy-app:amd64 .（※事前に macOS 側で softwareupdate --install-rosetta により Rosetta 2 が導入されている必要があります）
3.3 そのまま使えるもの②：Docker CLI とよく似たコマンド・フラグ体系
container のサブコマンドやオプションフラグは、普段 docker コマンドを叩いているエンジニアが迷わないよう意図的に揃えられています。
| やりたいこと | Docker コマンド | Apple container コマンド |
|---|---|---|
| 対話型で一時起動 | docker run --rm -it alpine sh | container run --rm -it alpine sh |
| バックグラウンド起動 | docker run -d --name web nginx | container run -d --name web nginx |
| 環境変数の注入 | docker run -e KEY=VAL --env-file .env ... | container run -e KEY=VAL --env-file .env ... |
| バインドマウント | docker run -v $(pwd):/app -w /app ... | container run -v $(pwd):/app -w /app ... |
| ポートフォワーディング | docker run -p 8080:80 nginx | container run -p 8080:80 nginx |
| メモリ・CPU上限指定 | docker run --memory 2g --cpus 2 ... | container run --memory 2G --cpus 2 ... |
| 稼働中コンテナ一覧 | docker ps | container list（または container ls） |
| コンテナ内での追加実行 | docker exec -it web sh | container exec -it web sh |
| ログの確認 | docker logs -f web | container logs -f web |
| イメージのビルド | docker build -t app:v1 . | container build -t app:v1 . |
3.4 挙動が異なるもの・そのままでは動かないもの（注意点と回避策）
ここが Docker Desktop や OrbStack から乗り換える際に最も注意すべきポイントです。
① /var/run/docker.sock（Docker Engine API）が存在しない
VS Code の「Dev Containers」拡張機能や、テスト自動化フレームワークの「Testcontainers」、CI ツールの「act」などは、裏側で /var/run/docker.sock という UNIX ドメインソケットを通じて Docker Engine API を叩いています。
apple/container はセキュリティとパフォーマンスのために macOS 固有の Mach XPC サービス で通信しており、標準では docker.sock を作成しません。
② docker compose（マルチコンテナ一括オーケストレーション）が非搭載
現在の apple/container 本体には、docker-compose.yml を読み込んで Web・DB・キャッシュ・マイグレーションを一括起動・依存解決する compose 機能は組み込まれていません。
- 2〜3個のコンテナを連携させたい場合：
container network create my-netでカスタム仮想ネットワークを作成し、container run --network my-netで各コンテナを起動することでコンテナ間通信が可能です。 - 複雑な
docker-compose.ymlをそのまま動かしたい場合：無理にapple/containerだけで完結させようとせず、素直に OrbStack や Colima を併用するのが現時点でのベストプラクティスです。
③ ボリューム（-v）のファイル所有権と ext4 の挙動
Docker Desktop や OrbStack では、1つの共有 Linux VM 上で独自のファイルシステム変換レイヤーを挟んでいますが、apple/container ではコンテナのルートファイルシステムが ext4 ブロックデバイス として各マイクロ VM にマウントされ、ホスト共有ディレクトリは virtiofs で渡されます。
そのため、Linux ネイティブのファイル属性（chmod / chown や extended attributes）の再現性が高く高速である一方、Docker 独自のサードパーティ Volume Plugin 等は利用できません。
4. container のインストールと初期セットアップ手順
Apple Silicon Mac（macOS 15 以降、フル機能およびカスタム仮想ネットワーク・Container Machine の利用には macOS 26 推奨）であれば、Homebrew または公式の署名済み .pkg インストーラから数分で導入できます。
ステップ1：Homebrew でインストールする
ターミナルを開き、以下のコマンドを実行します。
# Apple container CLI のインストール
brew install container（※GitHub Releases から公式の署名済みインストーラ container-*-installer-signed.pkg をダウンロードして導入することも可能です）
ステップ2：システムサービスの起動と推奨カーネルのセットアップ
インストール直後に、バックグラウンドサービスを起動し、マイクロVM用の推奨 Linux カーネルを自動取得・設定します。
# container システムサービスの開始
container system start
# 初回のみ：推奨される最小 Linux カーネルが未設定の場合は明示的にセット
container system kernel set --recommended
# 動作確認とステータスチェック
container system status
container --version5. 基本的な CLI コマンドの実践例
5.1 コンテナの起動と対話シェル実行（container run）
# Alpine Linux をダウンロードして対話型シェルを起動（終了時に自動削除）
container run --rm -it alpine:latest /bin/shシェル内で uname -a や ps aux を実行してみると、他のコンテナのプロセスが一切存在しない、独立した軽量カーネル環境上で動いていることが確認できます。
5.2 バックグラウンド実行と専用 IP への直接アクセス
# Nginx コンテナをバックグラウンド（デタッチモード）で起動
container run -d --name web-test docker.io/library/nginx:alpine
# 稼働中のコンテナ一覧と割り当てられたローカルIPを確認
container listcontainer list に表示された IP アドレス（例：192.168.64.2）に対して、ポートマッピング（-p）を指定していなくても Mac 側のブラウザや curl http://192.168.64.2 から直接アクセスできます。もちろん、従来通り localhost:8080 でアクセスしたい場合は -p 8080:80 を付与すればポートフォワーディングも機能します。
5.3 ローカルディレクトリの共有（--volume / -v）
ホスト（macOS）側のソースコードや作業ディレクトリをコンテナ内へマウントする際は、virtiofs による高速なファイル共有が使われます。
# カレントディレクトリをコンテナ内の /workspace にマウントして Node.js を実行
container run --rm -it -v "$(pwd):/workspace" -w /workspace node:22-alpine sh6. v1.0 の目玉機能「Container Machine」による永続 Linux 開発環境
WWDC 2026 でリリースされた v1.0 において特に注目すべき進化が、使い捨て（エフェメラル）のコンテナだけでなく、開発用の永続的な Linux 環境を1コマンドで構築できる container machine（Container Machine） 機能です。
AI コーディングエージェントとのペアプログラミング や Linux 固有のビルドツールチェーン（C/C++、Rust、システムデーモン等）を動かす際、「ホストの macOS 環境は汚したくないが、Mac 上のエディタや SSH 鍵、ホームディレクトリのファイルはそのままシームレスに使いたい」という場面が多々あります。
container machine を使うと、以下のような統合環境が即座に手に入ります。
- ユーザーの自動マッピング：macOS 側のユーザー名・UID と同じ Linux ユーザーが自動構成されるため、ファイル権限（パーミッション）のズレが発生しません。
- ホームディレクトリの透過的な共有：手動で複雑な
-vオプションを指定しなくても、Mac 側のプロジェクトファイルにそのままアクセスできます。 systemd等の初期化システムに対応：単一プロセスだけでなく、複数のバックグラウンドサービス（さらにはその内部でdockerdやpodman）を動かす開発ボックスとして利用可能です。
# デフォルトの永続 Linux マシン（例：Ubuntu / Alpine ベース）を作成
container machine create --name devbox --set-default ubuntu:24.04
# 作成したマシン内でコマンドを直接実行
container machine run -n devbox uname -a
# 対話シェルにログインして作業する
container machine run -n devbox7. 徹底比較：Apple container vs OrbStack vs Docker Desktop
現在 Apple Silicon Mac でコンテナを扱う主要な3つの選択肢を比較すると、それぞれの強みと適したユースケースが明確に分かれます。
| 比較軸 | Apple container | OrbStack | Docker Desktop |
|---|---|---|---|
| 開発元・ライセンス | Apple 純正（Apache 2.0 完全無料・OSS） | OrbStack（個人無料 / 商用有料） | Docker Inc.（個人無料 / 一定規模以上の商用有料） |
| 仮想化アーキテクチャ | 1コンテナ＝1軽量VM（完全分離） | 1つの超最適化 Linux VM を共有 | 1つの Linux VM を共有 |
| セキュリティ隔離性 | 極めて高い（ハードウェアVMレベルで分離） | 標準的（Linux Namespace 分離） | 標準的（Linux Namespace 分離） |
| メモリ・バッテリー効率 | 非常に高い（使ったコンテナ分だけ最小起動） | 非常に高い（動的メモリ解放が優秀） | やや重い（アイドル時も数GB占有しやすい） |
Dockerfile / OCI 互換 | ◎ そのままビルド・実行可能 | ◎ 完全互換 | ◎ 公式標準 |
docker compose 互換性 | × 非搭載（単体コンテナ・Machine 中心） | ◎ docker compose が100%そのまま動く | ◎ 公式標準 |
| 既存エコシステム連携 | 独自 CLI（container）および Swift API | /var/run/docker.sock 互換・VS Code連携 | フル機能の GUI・Docker Scout 等 |
実践的な使い分けのおすすめ指針
-
単体コンテナの高速検証・AIエージェントのサンドボックス実行・商用ライセンスフリー環境 →
Apple container- AI コーディングエージェント に自律的にコマンドを実行させる環境や、信頼性の分からない外部スクリプト・パッケージを検証する場合、他のコンテナやホスト環境から VM レベルで完全に隔離される
apple/containerが圧倒的に安全です。 - また、単体の DB コンテナや CLI ツールコンテナをサッと立ち上げたい場合や、
Dockerfileから OCI イメージをビルドしたい場合にも、常駐デーモンのメモリ負荷がほぼゼロで快適に使えます。 - Apache 2.0 ライセンスのオープンソースかつ Apple 純正であるため、企業のセキュリティポリシーや商用ライセンス制限で Docker Desktop / OrbStack の導入が難しい現場でも安心して導入できます。
- AI コーディングエージェント に自律的にコマンドを実行させる環境や、信頼性の分からない外部スクリプト・パッケージを検証する場合、他のコンテナやホスト環境から VM レベルで完全に隔離される
-
複数コンテナが連携する Web アプリ開発（
docker-compose.yml/ Dev Containers 運用） →OrbStack- フロントエンド・バックエンド・PostgreSQL・Redis・ワーカーなど、複数のコンテナを
docker compose up -dで一括起動したり、VS Code の Dev Containers や Testcontainers（/var/run/docker.sock必須ツール）を使ったりする日々の Web 開発ワークフローには、引き続き OrbStack が最もスムーズです。
- フロントエンド・バックエンド・PostgreSQL・Redis・ワーカーなど、複数のコンテナを
まとめ
Apple の container は、「Docker のイメージ資産や Dockerfile、Rosetta 2 による amd64 実行、そして直感的な CLI オプションの互換性を維持しながら、裏側の実行エンジンだけを『1コンテナ＝1軽量VM』という macOS ネイティブかつセキュアな構造に刷新したツール」 です。
ぜひ手元の Apple Silicon Mac に導入して使い分けてみてください。