Apple container（apple/container）とは？1.5系の使い方とDockerとの違い・compose代替とGUIの現状

「Apple container」で調べると、Appleがオープンソースで公開したコンテナCLIの話と、macOSの~/Library/Containers（App Sandbox）の話、APFSの「コンテナ」の話が混ざって出てきます。本記事が扱うのは1つ目、GitHubで公開されているapple/containerです。Apple siliconのMacでLinuxコンテナを動かすSwift製のツールで、2026年6月9日に1.0.0が出て、2026年10月18日時点の最新版は1.5.0（2026年9月29日公開）です。仕組み・動作要件・インストール・主要コマンドに加え、Docker Composeの代わりになるもの、VS CodeのDev Containersで使えるか、GUIの現状まで、公式リポジトリの1.5.0タグの記述をもとに整理します。

まとめ

• apple/containerは、Apple siliconのMacでLinuxコンテナを動かすApple公式のOSS CLI（Swift製・Apache-2.0）。最新版は1.5.0で、1.0.0のあと4か月で8回リリースされ、うち4回（1.2.0・1.3.1・1.4.1・1.5.0）に脆弱性修正が入っている。
• 仕組みは「コンテナ1つにつき軽量VM 1つ」。各コンテナが自分のIPアドレスを持つので、同じポート番号のサービスを並べて起動でき、DNS名（例：web.test）でも呼べる。
• 動作要件はApple silicon搭載MacとmacOS 26。Intel Mac・iPhone・iPadでは動かない。導入は署名済みpkgを入れてcontainer system startを実行するだけ。
• Docker Composeの公式機能は1.5.0でも無い。第三者製のContainer-Composeやorchard系のcontainer composeプラグインはあるが、カスタムネットワーク上でサービス名だけで名前解決できない制約が残るため、Compose中心の開発はDocker DesktopかOrbStackのほうが確実。
• VS CodeのDev Containersは「起動済みコンテナへのアタッチ」だけが実験的に使える。devcontainer.jsonからのビルド・起動はできない。公式GUIも無い（第三者製のorchard等で補える）。

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

containerは、Mac上でLinuxコンテナを軽量な仮想マシンとして作成・実行するコマンドラインツールです。Appleが2025年6月9日に0.1.0をGitHubのapple/containerリポジトリで公開し、Apache License 2.0で開発が続いています。スター数は2026年10月時点で約5万1千です。

扱うイメージはOCI（Open Container Initiative）準拠です。Docker Hubなど標準的なレジストリからpullして実行でき、containerでビルドしたイメージは他のOCI互換ツールでも動きます。既存のDockerfileやイメージ資産はそのまま使えます。

バージョンの現在地（1.0.0から1.5.0までの変化）

0.x系が1年ほど続いたあと、1.0.0が2026年6月9日に公開されました。目玉は後述するcontainer machineで、あわせてシステム設定がUserDefaultsベースのcontainer system property get/setからTOML形式の設定ファイル（~/.config/container/config.toml）へ移りました。0.x系の解説どおりにsystem property setを叩いて失敗するなら、原因はこれです。

1.4.0は存在しません。1.4.1のリリースノートに、1.4.0のタグを破棄したため1.4.1に1.3.1以降の全変更が含まれると書かれています。

1.5.0のリリースノートの要点は3つです。container k8sがゲスト側から受け取るkubeconfigの値を、ホストの~/.kube/configへ統合する前に無害化するようになりました（GHSA-44v5-vx46-ghv6）。container k8s startは削除され、止まったクラスタは削除して作り直す手順に変わりました（CLIの破壊的変更）。また、エントリポイントが空のイメージでも指定したコマンドが実行されるようになり、localhostのDNS設定を変えたあとにコンテナの外向き通信が切れる不具合が直っています。

Appleのコンテナ3種類と用途の違い

アプリのコンテナは~/Library/Containers/以下にアプリごとに作られる領域で、APFSコンテナはディスクユーティリティで見える区画です。どちらもLinuxコンテナの実行とは関係ありません。「Macでコンテナを動かしたい」という文脈のApple containerは、ほぼ例外なくapple/containerを指します。コンテナと仮想マシンの違いから整理したい場合は仮想マシンとは？物理マシン・コンテナとの違いから作成・運用まで実装者向けに解説を参照してください。

Apple containerのアーキテクチャ：コンテナごとの軽量VM

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

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

macOSにはLinuxカーネルが無いので、どのツールでもLinuxコンテナはVMの上で動きます。Docker DesktopやColimaは1台の大きなLinux VMの中に全コンテナを同居させる方式で、コンテナ同士はカーネルを共有します。公式のtechnical overviewは、コンテナごとにVMを分ける利点を次の3点で説明しています。

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

素性のわからないコードやAIエージェントが生成したスクリプトを試す用途では、この隔離の強さがそのまま利点になります。隔離レベルの考え方は仮想環境とは？venv・コンテナ・仮想マシンの違いと隔離レベルの選び方を実装者向けに解説で整理しています。

launchdとXPCで分かれたヘルパープロセス

container system startを実行すると、launchdがcontainer-apiserverを起動します。apiserverはXPC経由で、イメージとローカルコンテンツストアを扱うcontainer-core-images、仮想ネットワークを扱うcontainer-network-vmnetを起動し、コンテナを作るたびに専用のcontainer-runtime-linuxを立てます。レジストリの認証情報はKeychainに、ログは統合ログ（Unified Logging）に入ります。Dockerのような単一デーモンではなく、macOS標準の仕組みに沿って分かれているため、Docker互換のソケット（/var/run/docker.sock）は存在しません。

コンテナごとの既定リソース（メモリ1GB・4CPU）

コンテナは1つずつVMなので、CPUとメモリの割り当てがコンテナ単位で決まります。config.tomlのリファレンスでは、--cpusと--memoryを省いたときの既定は4CPU・メモリ1GBです。ビルダー用VMは2CPU・2GiBです。PostgreSQLやElasticsearch、メモリを食うビルドは1GBでは足りないことがあるので、container run --memory 4gのように明示するか、config.tomlの[container]で既定値を上げてください。

インストールと初期設定

動作要件：Apple siliconとmacOS 26

公式READMEは「Apple silicon搭載のMacが必要」「macOS 26でサポートする」と書いており、古いmacOSはサポート対象外で、macOS 26で再現しない問題には原則として対応しないとしています。technical overviewにはmacOS 15で動かす場合の制限（コンテナ同士が通信できない、container network系コマンドが使えない等）が残っていますが、新しく導入するならmacOS 26が前提です。Intel Macでは動きません。

署名済みpkgのインストールとサービス起動

GitHubのリリースページから署名済みのインストーラ（container-1.5.0-installer-signed.pkg）をダウンロードし、ダブルクリックで進めます。/usr/local以下にファイルを置くため管理者パスワードを求められます。

# システムサービスの起動（初回・Macの再起動後に必要）
container system start
# 初回は「No default kernel configured.」と出て、推奨カーネルを入れるか聞かれる → y

# 動作確認：Alpineを取得して1行出力し、終了後に削除
container run --rm alpine echo hello

# 稼働中のコンテナ一覧（停止中も含めるなら --all）
container ls

初回のcontainer system startは、Linuxカーネルが未導入だと推奨カーネル（Kata Containersのビルド）のダウンロードを確認してきます。対話できないスクリプトから起動するなら--enable-kernel-installを付けます。

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

更新・削除用のスクリプトが/usr/local/binに入っています。更新の前にサービスを止めるのが公式手順です。

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

# 指定版へ戻す：サービスを停止してから削除し、版を指定して入れ直す
container system stop
/usr/local/bin/uninstall-container.sh -k
/usr/local/bin/update-container.sh -v 1.4.1

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

READMEによれば、アプリケーションデータの互換性は同じメジャー版の中で前方互換だけが保証されます。1.x系の中で上げるのは問題ありませんが、下げるときは-kで残したデータが読めない場合があると考えておくのが安全です。

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

サブコマンドの名前はDockerに近く、ほぼ読み替えで動きます。ただしdockerコマンドの互換エイリアスもDocker互換APIも無いため、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 --no-stream

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

create・start・kill・cp・export・pruneもあります。1.4.1で追加されたcontainer cleanは、稼働中のコンテナのルートファイルシステムと名前付きボリュームの未使用領域を回収するコマンドで、停止中のコンテナには使えません。

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

ビルドはcontainer buildで、既存のDockerfileをそのまま使えます（-fを省くとDockerfile、無ければContainerfileを探します）。ビルドはBuildKitを使う専用のビルダーVMで行われ、container builder start/status/stopで管理します。

# Dockerfileからビルド
container build --tag myapp:1.0 --file Dockerfile .

# タグ付け・ログイン・push（認証情報はKeychainに保存される）
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

1.3.0で--scheme autoが廃止され、レジストリへの接続は既定でhttpsです。社内のHTTPレジストリを使うなら--scheme httpを明示します。置き場所としてのレジストリの選び方はコンテナレジストリとは？種類・選び方から企業の導入判断まで解説で整理しています。

ネットワーク：コンテナごとのIPとDNS名

公式のnetworkingドキュメントのとおり、container system startはdefaultという名前のvmnetネットワークを作り、各コンテナにそのネットワーク上のIPアドレスを割り当てます。Macからはそのまま届くので、80番で待ち受けるコンテナを2つ並べても-pでホスト側のポートをずらす必要がありません。

IPの代わりに名前で呼びたいときは、2段階の設定をします。

# 1) container側：~/.config/container/config.toml に追記する
[dns]
domain = "test"

上記を設定ファイルに保存したら、以下をターミナルで実行します。既に[dns]がある場合は、その節のdomainを変更してください。

container system stop
container system start

# 2) macOS側：*.test の問い合わせを container のDNSへ向ける（管理者権限）
sudo container system dns create test

# 確認：名前を付けたコンテナに <名前>.test で届く
container run -d --rm --name my-web python:alpine python3 -m http.server 8000
curl http://my-web.test:8000

注意点が1つあります。defaultネットワーク上でhttp-server.testのようにドメイン付きの名前を引くのは動きますが、container network createで作ったネットワーク上で、ドメインを付けない素のコンテナ名を引くことは1.5.0でもできません。Composeでいう「サービス名で隣のコンテナに届く」動作で、apple/container#1809として未実装のまま残っています。ネットワーク管理コマンド自体もmacOS 26以降でのみ使えます。

ボリュームとホスト連携（SSHエージェント・ホストのサービス）

# 名前付きボリュームで永続化する
container volume create pgdata
container run -d --name db --memory 2g -e POSTGRES_PASSWORD="${POSTGRES_PASSWORD:?事前にPOSTGRES_PASSWORDを設定してください}" -v pgdata:/var/lib/postgresql/data postgres:17

# MacのSSHエージェントを渡して private リポジトリを clone する
container run -it --rm --ssh alpine:latest sh

# コンテナから Mac 上のサービス（127.0.0.1:8000）へ届く名前を作る
sudo container system dns create host.container.internal --localhost 203.0.113.113

--sshはSSH_AUTH_SOCKのソケットをコンテナへマウントし、ログアウトして入り直してもソケットの場所を追従させます。--localhostで作るホスト向けの名前には、host integrationのドキュメントが制限を2つ書いています。作成するとプライベートリレーが無効になること、再起動するとこのドメイン用のパケットフィルタのルールが消えることです。

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

通常のコンテナが「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          # 対話シェル（止まっていれば起動してから入る）

# CPU・メモリを変える（次の stop → start で反映）
container machine set -n dev cpus=4 memory=8G
container machine stop dev

container machineのドキュメントによると、ホストのユーザー名とホームディレクトリが自動でマップされ、Mac側の$HOMEにあるリポジトリやdotfilesがLinux側からも見えます。Macのエディタで編集してLinux側でビルドする往復にコピーが要りません。ただし、既定ではホームディレクトリを書き込み可能で共有するため、マシン内の処理がMac側のファイルも変更できます。信頼できるイメージを使い、不要なホーム共有は無効にしてください。メモリの既定はホストの半分で、ホームのマウントはrw（既定）・ro・noneから選べます。マシンの中でさらにVMを動かすネスト仮想化は、M3以降のApple siliconとCONFIG_KVM=yのカーネルが必要で、既定のカーネルでは使えません。

container k8s：ローカルKubernetesクラスタ（experimental）

1.2系から、container k8s createでローカルのKubernetesクラスタを立てられます。既定のノードイメージはkindest/node:v1.35.5で、作成すると~/.kube/configに接続情報が統合され、kubectlがそのまま使えます。

container k8s create --name dev --cpus 4 --memory 8g
kubectl --context dev get nodes
container k8s load-image myapp:1.0 --name dev   # ローカルでビルドしたイメージを読み込む
container k8s delete --name dev

READMEはk8sをexperimental（後方互換を保証しない機能）と明記しており、実際に1.5.0でk8s startが削除されました。コントロールプレーンのノードが止まったら、削除して作り直すのが現行の手順です。安定したローカルクラスタが要るなら、k8sをローカルで動かす手順｜kindでクラスタ構築からDeployment公開・撤収までのとおりkindを使うほうが手順が固まっています。

Docker Composeの対応状況と代替ツール

1.5.0のcontainerにDocker Compose相当の公式機能はありません。公式のコマンドリファレンスにcomposeのサブコマンドは無く、要望のissue（#1846）も開いたままです。Web＋DB＋キャッシュをcompose.yamlで束ねてup一発で立ち上げる流れは、そのままは持ち込めません。

第三者製のCompose互換ツール2つ

Container-ComposeはHomebrewでbrew install container-composeと入れられ、.env、依存順の起動、ボリュームとネットワークの対応付けを扱います。作者自身がREADMEで「(limited) Docker Compose support」と書いており、対応は実装済みのキーに限られます。1.2.0でライセンスがApache-2.0に変わりましたが、README本文はMITのままです。

もう1つは、GUIのorchardを作っている開発者によるcomposeパッケージで、containerのプラグインとしてcontainer compose upの形で動きます。orchardのREADMEは、制限を2つ先に書いています。依存先を先に起動はするが準備完了までは待たないこと、ホスト名はマシン上の全コンテナで一意である必要があるため、サービスは<プロジェクト名>-<サービス名>で呼ぶことです。さらに、containerのインストーラは更新のたびにプラグインディレクトリを消すため、containerを上げたらプラグインを入れ直す必要があります。

どちらもAppleのサポート対象外です。

複数コンテナの手動構成とサービス名の名前解決制約

サービスが2〜3個なら、シェルスクリプトやMakefileでcontainer runを並べるほうが確実です。そのときに引っかかるのが、前述のカスタムネットワーク上で素のコンテナ名を引けない制約です。接続文字列にdb:5432と書く既存の設定はそのまま動かないので、defaultネットワークで[dns] domainを設定してdb.test:5432のようにドメイン付きの名前へ書き換えるか、container inspectで調べたIPを渡します。

Composeの仕組みそのものはdocker-composeとは？複数コンテナをymlで定義し一括管理する仕組みを解説で解説しています。

VS Code Dev Containersの対応範囲と接続手順

使えるのは「起動済みのApple containerにアタッチする」ところまでです。Microsoftの担当者はvscode-remote-release#11012で、Dev Containers拡張の0.424.0プレリリースに「Dev Containers: Attach to Running Apple Container」を実験的な設定の裏で追加したと書いています（2025年7月14日）。このissueは2026年10月時点でも開いたままです。有効にする設定名は、同じissueで利用者がdev.containers.experimentalAppleContainerSupportと報告しています。

# VS Code の設定で dev.containers.experimentalAppleContainerSupport を true にする
# 先にコンテナを起動しておき、VS Code の F1 から
# 「Dev Containers: Attach to Running Apple Container」で接続する
container run -d --name devbox -v "$PWD":/workspace -w /workspace node:24 sleep infinity

一方、devcontainer.jsonを読んでイメージをビルドし、コンテナを作るところはDockerを前提にしています。Dev Containersの公式CLI（devcontainers/cli）に--docker-path containerを渡す方法も、dockerとcontainerのコマンド体系の違いで失敗することがapple/container#2259で報告されています。ポートの自動転送も効かず、Portsパネルで手動追加が要るとされています。チームでdevcontainer.jsonを共有して「Reopen in Container」で揃える運用は、現時点ではDocker DesktopかOrbStackが前提です。devcontainer.jsonの書き方はVS Codeで開発コンテナを作る（Create Dev Container）｜手順・devcontainer.json設定・複数コンテナ・言語別テンプレートにまとめています。

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

コンテナのメモリ返却制限と再起動による対処

technical overviewが既知の制限として挙げています。macOSのVirtualizationフレームワークはメモリバルーニング（VMが使わないメモリをホストへ返す仕組み）を一部しか実装しておらず、コンテナ内のプロセスがLinuxへ解放したメモリはホストへ返りません。メモリを多く使うコンテナを長時間並べると、実際より多くのメモリがアクティビティモニタ上で埋まって見えます。対処は該当コンテナの再起動です。

Apple公式GUIの提供状況と第三者製orchard

containerはCLIのみで、Docker DesktopやOrbStackのようなApple公式のGUIはありません。第三者製ではorchard（MIT・v2.5.2を2026年10月14日に公開）があり、コンテナ・container machine・k8sクラスタ・composeプロジェクトを1つの画面で扱えます。orchardはmacOS 26とcontainer 1.5.0を要件にしているので、containerを古い版に固定する運用とは相性がよくありません。CLIとGUIの使い分けの考え方はCLIとは？コマンドライン操作の仕組みとGUIとの使い分けを実装視点で解説にまとめています。

1.x系の互換性方針と、それでも起きた破壊的変更

READMEのProject Statusは、リリース番号はセマンティックバージョニングではなく製品の版であり、CLIは同じメジャー版の中で基本的に後方互換を保つが例外はありうる、と書いています。実際の1.x系では、1.3.0の--scheme auto廃止、1.4.1のcontainer system statusの出力変更（API）、1.5.0のk8s start削除がありました。加えて1.2.0・1.3.1・1.4.1・1.5.0が脆弱性修正を含み、内容もOCIイメージ読み込み時のシンボリックリンク追跡やローカルコンテンツストアのパストラバーサルなど、信頼できないイメージを扱うと踏みうるものです。チームで使うなら版を揃えて固定しつつ、リリースのたびに検証環境で確かめてから上げる運用にしてください。固定したまま放置すると、既知の脆弱性が残ります。

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

「置き換えるか」ではなく「どの用途で使うか」で選びます。

Apple silicon＋macOS 26で、単体か少数のコンテナを強い隔離で動かしたいならcontainerが有力です。Compose・Dev Containers・Docker互換APIのどれかが必須なら、Docker DesktopかOrbStackを使い続けるのが妥当です。各ツールの導入はOrbStackとは？使い方・料金とDocker Desktopからの移行手順【v2.2系】とColimaとは？MacでDocker Desktopを外す導入手順と設定の落とし穴【0.10系】で解説しています。Windows側で同じ位置づけのMicrosoft製ツールはWSL Containersとは？wslcの使い方とDocker Desktopとの使い分け【WSL 3.0.1時点】です。

開発者のMacで作ったイメージを、そのままクラウドのコンテナ基盤へ載せるところまで設計したい場合は、弊社のAWS・Google Cloud・Azureのインフラ構築支援でもご相談を受けています。

採用を見送るべき3つの条件

• macOS 26へ上げられないMac、またはIntel Macが対象に含まれる：READMEは古いmacOSをサポートしないと明記しています。チーム内で環境が揃わないなら、手順書が2系統になります。
• Composeかdevcontainer.jsonで開発環境を配っている：Composeは公式非対応で、互換ツールもサービス名での名前解決に制約があります。Dev Containersはアタッチしかできません。
• 版を固定して長期間据え置きたい：1.x系は4か月で4回の脆弱性修正があり、1.5.0でも破壊的なCLI変更が入りました。更新を追えない運用では、固定した版に既知の脆弱性が残ります。

よくある質問

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

公式には使えません。1.5.0のコマンドリファレンスにcomposeのサブコマンドはありません。第三者製のContainer-Compose（container-compose up）かorchard系のcontainer composeプラグインで代用できますが、Appleのサポート対象外で、対応するキーも限られます。Composeが開発の中心なら、Docker DesktopかOrbStackのほうが確実です。

Apple containerにGUIはありますか？

Apple公式のGUIはなく、操作はCLIで行います（一覧はcontainer ls、ログはcontainer logs、使用状況はcontainer stats）。第三者製では、MITライセンスのorchardがあり、コンテナ・container machine・k8sクラスタ・composeプロジェクトを扱えます。

Apple containerでdevcontainerは使えますか？

一部だけ使えます。Dev Containers拡張のプレリリース版にある実験的な「Attach to Running Apple Container」で、先にcontainer runで起動したコンテナへ接続できます。devcontainer.jsonからイメージをビルドしてコンテナを作る機能はDockerが前提で、Apple containerでは動きません。

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

Apple containerはどれでも動きません。必須要件はApple silicon搭載のMacで、対応OSはmacOS 26です。iOSとiPadOSにはLinuxコンテナを動かす仕組みが無く、DockerもiPhone・iPadでは動きません。Intel MacならDocker Desktop・OrbStack・Colimaが使えます。iPadから開発したい場合は、リモートのLinuxマシンやクラウドの開発環境へSSHで接続する構成が現実的です。

Apple containerをアンインストールするには？

同梱のスクリプトを使います。/usr/local/bin/uninstall-container.sh -dでツールとユーザーデータをまとめて削除し、-kを付けるとユーザーデータを残して本体だけを消します。-kで残したデータは、あとで再インストールしたときに引き継がれます。sudo container system dns createで作ったDNS設定は/etc/resolver/に残るので、不要なら、本体をアンインストールする前にsudo container system dns delete testのように削除してください。この記事のホスト接続例も設定した場合は、同じく削除前にsudo container system dns delete host.container.internalを実行します。

関連記事

• docker-composeとは？複数コンテナをymlで定義し一括管理する仕組みを解説
• OrbStackとは？使い方・料金とDocker Desktopからの移行手順【v2.2系】
• Colimaとは？MacでDocker Desktopを外す導入手順と設定の落とし穴【0.10系】
• VS Codeで開発コンテナを作る（Create Dev Container）｜手順・devcontainer.json設定・複数コンテナ・言語別テンプレート
• Podmanとdockerの違いは？デーモンレス・rootlessの仕組みと移行判断