Apple純正コンテナツール「container」v1.0.0 — Dockerとの違いと実践的な使いどころ

AppleがWWDC25で発表したLinuxコンテナツール「container」v1.0.0。Dockerとの違い、Apple Silicon環境での実用性、Laravel・Next.js開発への活用まで、実案件ベースで解説します。

こんな悩みはありませんか？

「MacのDockerが重くて、起動するだけでファンが回り始める」「Docker Desktopのライセンス費用がチーム規模だと無視できない」「開発環境のセットアップをもっとシンプルにしたい」

Apple Siliconが普及して以降、macOS上のコンテナ環境にはこうした不満がつきまとってきました。WWDC25で発表されたApple純正のLinuxコンテナツール「container」は、まさにこの課題に正面から応えるプロダクトです。約1年のオープンソース開発を経て、2026年6月9日にv1.0.0が正式リリースされました。

本記事では、containerのアーキテクチャとDockerとの違いを整理し、どんな場面で使うべきか（使うべきでないか）の判断基準まで解説します。

なぜ今「Apple純正コンテナ」が登場したのか

Apple Silicon時代のコンテナ事情

Docker Desktopは裏で1つのLinux VMを立ち上げ、その中ですべてのコンテナを動かす構造です。このためVM分のメモリを常時確保し続け、Laravelの PHP-FPM + MySQL + Redis といった複数コンテナを同時起動すると、16GBのMacでも余裕がなくなることがあります。

そこでAppleは、macOSの仮想化フレームワーク（Virtualization.framework）とOCIコンテナ仕様を組み合わせた**純正CLIツール「container」**を開発し、Apache 2.0ライセンスのオープンソースとして公開しました。GitHubで26,000を超えるスターを集めており、注目度の高さがうかがえます。

設計思想とアーキテクチャ

containerの最大の特徴は「1コンテナ = 1軽量Linux VM」という設計です。Docker Desktopではすべてのコンテナが共有VMの1つのLinuxカーネルの上で動くのに対し、containerはVirtualization.frameworkを通じてコンテナごとに独立した軽量VMとカーネルを起動します。

一見オーバーヘッドが大きそうですが、Apple SiliconのハードウェアとmacOSの仮想化支援によりVMの起動・破棄は非常に高速で、サブ秒でのコンテナ起動を実現しています。さらにコンテナ同士がハードウェアレベルで分離されるため、セキュリティ面では共有カーネル方式より堅牢です。

実際に使ってみる — インストールから起動まで

前提環境

• macOS 26 Tahoe以降（それ以前のバージョンはサポート対象外）
• Apple Silicon搭載Mac（M1/M2/M3/M4。Intel Macは非対応）

インストール

GitHubのリリースページから署名付きインストーラーパッケージ（.pkg）をダウンロードし、ダブルクリックでインストールします。Homebrewのような手軽さはありませんが、Apple署名済みパッケージなので安心して導入できます。

インストール後、システムサービスを起動します。Docker Desktopのようなメニューバーアイコンはなく、すべてCLIで操作します。

# システムサービス起動
container system start

# バージョン確認
container --version

# 動作確認
container run --rm hello-world

コンテナを動かしてみる

コマンド体系はDockerとほぼ同一です。dockerをcontainerに置き換えるだけで動くケースがほとんどで、既存の知識がそのまま活用できます。

# PHP 8.4のコンテナを起動（マルチアーキイメージは自動でarm64版を取得）
container run -d \
  --name php-app \
  -p 8080:80 \
  -v $(pwd):/var/www/html \
  php:8.4-fpm

# コンテナ内に入る
container exec -it php-app bash

# MySQL 8.0コンテナを起動
container run -d \
  --name dev-mysql \
  -e MYSQL_ROOT_PASSWORD=secret \
  -e MYSQL_DATABASE=laravel \
  -p 3306:3306 \
  mysql:8.0

# 接続確認
container exec -it dev-mysql \
  mysql -uroot -psecret -e "SHOW DATABASES;"

# Node.js 22でNext.jsの開発サーバーを起動
container run -d \
  --name nextjs-dev \
  -p 3000:3000 \
  -v $(pwd):/app \
  -w /app \
  node:22-alpine \
  sh -c "npm install && npm run dev"

# ログをリアルタイムで確認
container logs -f nextjs-dev

よくあるつまずきポイントと対処法

❌ つまずき1：docker-composeをそのまま使おうとした

containerはv1.0.0時点ではDocker Composeに対応していません。複数コンテナを一括管理するcompose.ymlは動作しないため、マルチコンテナ構成を前提にした開発環境では導入直後に詰まります。

対処法： コンテナ間の連携が必要な場合は起動スクリプトを自作するか、Docker Desktop / OrbStack / Podmanなどcompose対応ツールと使い分ける。あるいはシングルコンテナで完結する用途（ツール実行・動作検証など）に絞って使用する。

❌ つまずき2：arm64版が存在しないイメージでエラーになった

Docker Hubの主要な公式イメージはマルチアーキテクチャ対応なので自動的にarm64版が取得されますが、古いイメージや社内イメージにはamd64（x86-64）版しかないものがあります。

その場合は--archオプションでアーキテクチャを明示すれば、Rosetta変換でamd64イメージをそのまま実行できます。

# amd64しかないイメージをRosettaで実行
container run --arch amd64 --rm legacy-image uname -m
# => x86_64

ただしRosetta経由はネイティブarm64より性能が落ちるため、常用するイメージはarm64対応のものを選ぶのが基本です。

❌ つまずき3：コンテナ停止後にデータが消えた

--rmフラグを付けたままデータベースコンテナを起動し、停止後にデータが消えてしまうのは初期にありがちなミスです。containerでもDockerと同様、ボリュームマウントによる永続化が必要です。

# NG: データが永続化されない
container run --rm -d mysql:8.0

# OK: ホスト側ディレクトリをマウントして永続化
container run -d \
  -v $(pwd)/mysql-data:/var/lib/mysql \
  mysql:8.0

Dockerと使い分けるための判断基準

flowchart TD
    A[コンテナツールの選定] --> B{Apple Silicon Mac +<br>macOS 26?}
    B -->|No| C[Docker Desktop / OrbStack を使う]
    B -->|Yes| D{Docker Compose構成?}
    D -->|複雑なマルチコンテナ| E[Docker Desktop / OrbStack / Podman]
    D -->|シングル or スクリプト管理でOK| F{GUI不要 / 軽量・分離重視?}
    F -->|GUIも使いたい| G[Docker Desktop / OrbStack]
    F -->|CLIだけで十分| H[container を採用]

シンプルにまとめると、「Apple Silicon + macOS 26 + CLIに慣れている + シングルコンテナ中心」という条件が揃えば、containerは非常に有力な選択肢です。VM単位の分離が効くため、出所の不確かなコードやAI生成スクリプトを隔離環境で試す用途にも向いています。

一方、チームでDocker Composeを使った開発環境を丸ごと管理している場合は、当面は既存ツールとの併用が現実的です。

まとめと次のステップ

Apple純正のcontainer v1.0.0は、軽量・高速・無償という三拍子が揃った、Apple Siliconユーザーにとって有望なツールです。ただし「Dockerの完全な置き換え」ではなく、**「用途を選べば非常に強力な代替手段」**という位置づけで捉えるのが現実的です。

まず試すなら、本番環境のミラーではなく、ローカルでのツール実行や単体コンテナの動作検証から始めると、リスクなく感触をつかめます。OS標準に近い形でコンテナ技術が提供されたことで、今後のmacOS開発環境の選択肢は確実に広がっていくはずです。

弊社ではLaravel・Next.js・WordPressを中心に、開発環境の標準化や本番インフラの構築支援も承っています。「うちのチームの環境もそろそろ整理したい」「コンテナ移行の相談窓口がほしい」といったご要望があれば、お気軽にご相談ください。