Apple container（apple/container）とは？macOSでLinuxコンテナを動かすCLIの使い方とDockerとの違い

「Apple container」を調べると、Appleがオープンソースで公開したコンテナCLIの話と、macOSの~/Library/Containers（App Sandbox）の話、さらにAPFSの「コンテナ」の話が混在してヒットします。本記事が扱うのは1つ目、つまりGitHubで公開されている apple/containerです。Apple siliconのMac上でLinuxコンテナを動かすためのSwift製ツールで、2026年6月に1.0.0、7月6日に1.1.0が公開されました。ここでは仕組み・動作要件・インストール・主要コマンド・Docker Composeが使えるのかという実務上の分かれ目までを、公式リポジトリの一次情報に基づいて整理します。

まとめ

• apple/containerは、Apple siliconのMacでLinuxコンテナを動かすApple公式のOSS CLI（Swift製・Apache-2.0）。WWDC25で公開され、2026年7月時点の最新版は1.1.0。
• 最大の特徴は「コンテナ1つにつき軽量VM 1つ」。Docker Desktopのように大きなLinux VMを1台共有するのではなく、コンテナごとに専用VMを起動するため、隔離が強くアイドル時のフットプリントが小さい。
• 動作要件は厳しい。Apple silicon搭載Mac必須、かつ公式サポートはmacOS 26。Intel MacやiPhone・iPadでは動かない。
• 導入は署名済みpkgを入れてcontainer system startを叩くだけ。OCI準拠なのでDocker Hub等のイメージをそのままpull・push・buildできる。
• 最大の弱点はDocker Compose非対応。複数サービスをcompose.yamlで束ねる開発環境が中心なら、Docker DesktopやOrbStackを使い続けるほうが早い。

以下、仕組みと使い方、そして「自分の環境で使うべきか」の判断材料を順に見ていきます。

Apple containerとは何か：WWDC25で公開されたSwift製のコンテナCLI

containerは、Macの上でLinuxコンテナを軽量な仮想マシンとして作成・実行するためのコマンドラインツールです。Appleが2025年5月末にGitHubへ公開し、Apache License 2.0のオープンソースとして開発が続いています。実装言語はSwiftで、Apple siliconに最適化されている点が公式に明言されています。GitHubのスター数は2026年7月時点で47,000を超えており、macOS向けコンテナ環境としては最も注目度の高いプロジェクトのひとつです。

扱うイメージはOCI（Open Container Initiative）準拠です。したがってDocker Hubをはじめとする標準的なコンテナレジストリからイメージをpullして実行でき、containerでビルドしたイメージを他のOCI互換ツールで動かすこともできます。「Apple独自形式のコンテナ」ではないので、既存のDockerfileやイメージ資産はそのまま活かせます。

バージョンの現在地（1.0.0と1.1.0で何が変わったか）

0.x系が1年ほど続いたあと、1.0.0が2026年6月9日に公開されました。ここでの目玉が後述するcontainer machineで、あわせてシステム設定の持ち方が変わっています。従来はUserDefaultsベースのcontainer system property get/setで設定していましたが、1.0.0でこのサブコマンドは廃止され、TOML形式の設定ファイルに置き換わりました。0.x系の解説記事どおりにsystem propertyを叩こうとして失敗する場合、原因はほぼこれです。

1.1.0は2026年7月6日公開で、非rootコンテナでのUnixドメインソケットのマウント対応、container cpが相対パスで失敗する不具合の修正、container machineのネスト仮想化対応などが入っています。なお0.12.3ではレジストリ関連コマンドのHTTPダウングレード防止とcontainer system dnsのインジェクション対策というセキュリティ修正が入っているため、0.12.2以前を使い続けている場合は更新が必要です。

紛らわしい3つの「Appleのコンテナ」を切り分ける

検索結果が混線しやすいので、名前の似た3つを先に切り分けておきます。混同したまま調べ続けると、いつまでも欲しい情報にたどり着けません。

後ろの2つはOSやファイルシステムの構造の話で、Linuxコンテナの実行とは無関係です。「Macでコンテナを動かしたい」という文脈で出てくるApple containerは、ほぼ例外なく1つ目のapple/containerを指します。コンテナ全般と仮想マシンの違いから整理したい場合は仮想マシンとは？物理マシン・コンテナとの違いから作成・運用まで実装者向けに解説もあわせて参照してください。

アーキテクチャ：コンテナ1つにつき軽量VMが1つ立つ

containerの設計を一言でいえば「コンテナごとに専用の軽量VMを起動する」です。低レベルの処理はApple製のSwiftパッケージContainerizationが担い、macOSのVirtualizationフレームワークでVMを、vmnetフレームワークで仮想ネットワークを扱います。

Docker Desktopの「共有VM方式」との違い

macOSにはLinuxカーネルがないため、どのツールを使うにせよLinuxコンテナは仮想マシン上で動きます。Docker DesktopやColimaは、1台の大きなLinux VMを起動し、その中で全コンテナを同居させる方式です。カーネルを共有するので効率は良い一方、コンテナ同士はカーネルを共有した隣人になります。

対してcontainerは、コンテナごとにVMを分けるため、次の性質が公式ドキュメントで説明されています。

• 隔離：各コンテナがVM相当の隔離境界を持つ。最小限のライブラリ構成で攻撃面も小さい。
• プライバシー：ホストのデータは必要なコンテナにだけマウントすればよい。共有VM方式では「いつか使うかもしれないデータ」をVM全体にマウントしておく必要がある。
• 性能：フルVMより必要メモリが小さく、起動時間は共有VM上のコンテナと同等。

この「コンテナ＝VM」という設計は、素性のわからないコードやAI生成スクリプトを試す用途では明確な利点になります。隔離レベルの考え方そのものを整理したい場合は仮想環境とは？venv・コンテナ・仮想マシンの違いと隔離レベルの選び方を実装者向けに解説が参考になります。

常駐する3つのヘルパープロセス

container system startを実行すると、launchdがcontainer-apiserverを起動します。これがコンテナとネットワークを管理するAPIの本体で、container system stopで終了します。apiserverはさらにXPC経由で、イメージ管理とローカルコンテンツストアを担うcontainer-core-images、仮想ネットワークを担うcontainer-network-vmnetを起動し、コンテナを作るたびに専用のcontainer-runtime-linuxを立てます。レジストリの認証情報はKeychainに、ログは統合ログ（Unified Logging）に載るため、macOSのコンソールやlogコマンドから追跡できます。Dockerのような単一の巨大デーモンではなく、launchdとXPCというmacOSの標準機構に沿って分割されているのが特徴です。

インストールと初期設定

動作要件：Apple siliconとmacOS 26

導入前に必ず確認すべき点です。公式READMEは「Apple silicon搭載のMacが必要」「macOS 26でサポートする」と明記しており、それより古いmacOSはサポート対象外で、macOS 26で再現しない問題は原則として対応されないと述べています。0.x系にはmacOS 15（Sequoia）で機能制限つきで動いた時期もありましたが、ネットワーク管理などmacOS 26前提の機能が増えており、いま新規に使うならmacOS 26が事実上の前提です。Intel Macでは動きません。

pkgを入れてサービスを起動する

インストールはGitHubのリリースページから署名済みのインストーラパッケージをダウンロードし、ダブルクリックして進めるだけです。/usr/local以下にファイルを置くため管理者パスワードを求められます。導入後、システムサービスを起動します。

# システムサービスの起動（初回・再起動後に必要）
container system start

# 動作確認：Alpineを取得して対話シェルに入る
container run --rm -it alpine:latest sh

# 稼働中のコンテナ一覧
container ls

この時点でDocker Hubからイメージが取得できていれば、基本セットアップは完了です。

アップグレードとアンインストール

更新・削除用のスクリプトが/usr/local/binに同梱されています。更新時は先にサービスを止めるのが公式手順です。

# 更新（先に停止しておく）
container system stop
/usr/local/bin/update-container.sh
container system start

# アンインストール（-k はユーザーデータを残す、-d は消す）
/usr/local/bin/uninstall-container.sh -k

特定バージョンへ戻したい場合は、uninstall-container.sh -kでいったん削除してからupdate-container.sh -v <バージョン>で指定版を入れ直します。破壊的なCLI変更が入るリリースがあるため、業務環境ではバージョンを固定しておくと安全です。

基本的な使い方：主要コマンドの体系

サブコマンドの命名はDockerに近く、Dockerを使ったことがあればほぼ読み替えで動かせます。ただしdockerコマンドの互換エイリアスやDocker互換ソケットは提供されないため、dockerを前提に書かれたスクリプトやツールがそのまま動くわけではない点は押さえておいてください。

コンテナの実行・操作

# バックグラウンドでnginxを起動し、ポートを公開する
container run -d --name web -p 8080:80 nginx:alpine

# 実行中コンテナでコマンドを実行
container exec -it web sh

# ログ・詳細・リソース使用状況
container logs web
container inspect web
container stats

# 停止と削除
container stop web
container rm web

create／start／kill／cp／export／pruneも揃っており、日常的な操作で困ることはほとんどありません。

イメージのビルドとレジストリ操作

ビルドはcontainer buildで行い、既存のDockerfileをそのまま使えます。レジストリへの認証はcontainer registry loginで、認証情報はKeychainに保存されます。

# Dockerfileからビルド（プラットフォームを明示できる）
container build --tag myapp:1.0 --file Dockerfile .

# イメージ一覧・タグ付け・push
container image ls
container image tag myapp:1.0 registry.example.com/myapp:1.0
container registry login registry.example.com
container image push registry.example.com/myapp:1.0

ビルドはBuildKitを使って隔離環境で実行され、ビルダー自体もcontainer builder start/status/stopで管理する独立したコンポーネントになっています（-fを省略した場合はDockerfile、無ければContainerfileが探索されます）。イメージの置き場所そのものの選定基準はコンテナレジストリとは？種類・選び方から企業の導入判断まで解説で整理しています。

ネットワークとボリューム

ネットワーク管理（container network create/ls/inspectなど）はmacOS 26以降でのみ利用可能とドキュメントに明記されています。永続データはcontainer volume createで作成したボリュームを使うか、ホストのディレクトリをマウントします。

container volume create pgdata
container run -d --name db -v pgdata:/var/lib/postgresql/data postgres:17

container machine：1.0で追加された長期稼働のLinux環境

1.0.0の目玉がcontainer machineです。通常のコンテナが「1つのアプリ」をモデル化するのに対し、container machineは「Linux環境そのもの」をモデル化します。イメージのinitシステムを起動するため、systemdを含むイメージならsystemctl start postgresqlのように常駐サービスを立てられます。

# Alpineベースの開発用マシンを作って入る
container machine create alpine:latest --name dev
container machine run -n dev whoami   # rootではなくホストのユーザー名になる
container machine run -n dev          # 対話シェル

特徴的なのはホストのユーザー名とホームディレクトリが自動でマップされる点です。Mac側の$HOMEにあるリポジトリやdotfilesがLinux側からも同じパスで見えるため、「Macのエディタで編集し、Linux側でビルド・実行する」という往復にコピー操作が要りません。ターゲットのディストリビューションごとにマシンを作り分けて検証する、といった使い方も想定されています。

Docker Composeは使えるのか

結論から言えば、2026年7月時点のcontainerにDocker Compose相当の公式機能はありません。公式のコマンドリファレンスにもcomposeに相当するサブコマンドは存在しません。Web＋DB＋キャッシュをcompose.yamlで束ねてup一発で立ち上げる、という開発フローをそのまま持ち込むことはできない、ということです。

選択肢は実質3つです。

• 手動で組む：ネットワークを作り、各サービスをcontainer runで個別に起動するシェルスクリプトやMakefileを書く。サービスが2〜3個なら現実的です。
• サードパーティのCompose互換ツールを使う：compose.yamlを解釈してcontainerのコマンドへ変換するコミュニティ製ツールが存在します。ただしApple公式のサポート対象ではなく、対応範囲もCompose仕様の一部にとどまるため、業務環境で採用するなら機能とメンテナンス状況の確認が前提になります。
• Compose中心の環境ではDocker DesktopやOrbStackを使い続ける：もっとも確実です。Composeの仕組み自体はdocker-composeとは？複数コンテナをymlで定義し一括管理する仕組みを解説で解説しています。

「Composeが開発の中心にあるかどうか」は、containerを選べるかどうかを分ける最大の判断軸です。ここは正直に見積もっておいたほうが後で困りません。

つまずきやすい制限と注意点

コンテナが解放したメモリがホストに返らない

公式ドキュメントが既知の制限として挙げているのがメモリの扱いです。macOSのVirtualizationフレームワークはメモリバルーニング（VMが使わないメモリをホストへ返す仕組み）を部分的にしかサポートしていないため、コンテナ内のプロセスがLinuxへ解放したメモリページはホスト側に返却されません。メモリを多く使うコンテナを長時間並べて動かすと、実際の使用量以上にホストのメモリが埋まって見えることがあります。対処法は身も蓋もありませんが、該当コンテナを再起動することです。

公式GUIは提供されない

containerはCLIのみで、Docker DesktopやOrbStackのようなApple公式のGUIアプリはありません。コンテナ一覧やログの確認もターミナルから行います。GUIでの管理が業務要件になっている場合は、この点だけで採用が難しくなります。CLIとGUIの使い分けの考え方はCLIとは？コマンドライン操作の仕組みとGUIとの使い分けを実装視点で解説にまとめています。

破壊的変更のペースが速い

リリースノートには「CLIの破壊的変更」「APIの破壊的変更」を示すマークが常に登場します。実際、1.0.0ではcontainer system propertyが削除され、0.12.0ではデフォルトで付与されるLinuxケーパビリティが削減されました（後者は既存コンテナの作り直しが必要でした）。チームで使うならバージョンを固定し、更新時はリリースノートの破壊的変更を確認する運用が現実的です。

Docker Desktop・OrbStack・Colimaとの使い分け

「置き換えるべきか」ではなく「どの用途で使うか」で考えるのが実務的です。

整理すると、Apple silicon＋macOS 26で、単体コンテナや少数のサービスを、強い隔離と低いアイドルコストで動かしたいならcontainerが有力です。逆にComposeが前提、GUIが必要、チームにIntel Macが残っているのいずれかに当てはまるなら、Docker DesktopやOrbStackを使い続けるのが妥当です。デーモンレス・rootlessという別方向の代替を検討しているならPodmanとdockerの違いは？デーモンレス・rootlessの仕組みと移行判断もあわせて比較してください。

よくある質問

Apple containerとは何ですか？

Appleがオープンソースで公開しているコマンドラインツールapple/containerのことで、Apple silicon搭載のMac上でLinuxコンテナを軽量な仮想マシンとして実行します。Swiftで書かれApache License 2.0で公開されており、WWDC25にあわせて2025年5月末に公開されました。2026年7月時点の最新版は1.1.0です。OCI準拠のイメージを扱うため、Docker Hubなどのレジストリからイメージを取得してそのまま実行できます。なお、macOSアプリのデータ領域である~/Library/ContainersやAPFSの「コンテナ」は別概念です。

Apple containerのインストール方法は？

GitHubのリリースページから署名済みのインストーラパッケージ（pkg）をダウンロードし、ダブルクリックしてインストールします。/usr/local以下にファイルを配置するため、途中で管理者パスワードの入力を求められます。インストール後にcontainer system startを実行してシステムサービスを起動すれば使い始められます。更新は同梱のupdate-container.sh、削除はuninstall-container.shで行い、更新前にはcontainer system stopでサービスを停止しておきます。

Apple containerでdocker composeは使えますか？

使えません。2026年7月時点の公式コマンドリファレンスにcomposeに相当するサブコマンドはなく、compose.yamlを直接読み込む機能も提供されていません。複数サービスを扱うには、ネットワークを作って各サービスをcontainer runで個別に起動するスクリプトを用意するか、compose.yamlをcontainerのコマンドへ変換するコミュニティ製ツールを使うことになります。後者はApple公式のサポート対象外で対応範囲も限定的なため、Composeが開発フローの中心にある場合はDocker DesktopやOrbStackを使い続けるほうが確実です。

Apple containerにGUIはありますか？

Apple公式のGUIアプリは提供されておらず、操作はすべてCLIで行います。Docker Desktopのダッシュボードのように、コンテナ一覧・ログ・リソース使用状況をウィンドウで確認する機能はありません。ただしコンテナ一覧はcontainer ls、ログはcontainer logs、リソース使用状況はcontainer statsで確認でき、ログはmacOSの統合ログにも出力されるためコンソールアプリからも追跡できます。GUIでの管理が必須要件なら、現時点ではDocker DesktopやOrbStackが選択肢になります。

iPhoneやiPad、Intel MacでApple containerは動きますか？

いずれも動きません。containerはApple silicon搭載のMacを必須要件としており、Intelチップ搭載のMacはサポート対象外です。iOSやiPadOSはmacOSのVirtualizationフレームワークを利用できないため、iPhone・iPadでLinuxコンテナを動かす用途にも使えません。加えて対応OSはmacOS 26で、それより古いmacOSは公式サポート外です。「iPadでDockerを動かしたい」といった要件は、リモートのLinuxマシンやクラウド上の開発環境へSSH接続する構成で満たすのが現実的です。

関連記事

• docker-composeとは？複数コンテナをymlで定義し一括管理する仕組みを解説
• Podmanとdockerの違いは？デーモンレス・rootlessの仕組みと移行判断
• 仮想マシンとは？物理マシン・コンテナとの違いから作成・運用まで実装者向けに解説
• 仮想環境とは？venv・コンテナ・仮想マシンの違いと隔離レベルの選び方を実装者向けに解説
• コンテナレジストリとは？種類・選び方から企業の導入判断まで解説