--- title: "Apple container（apple/container）とは？1.5系の使い方とDockerとの違い・compose代替とGUIの現状" url: "https://www.issoh.co.jp/tech/details/7219/" published: 2025-06-12 updated: 2026-10-18 categories: ["Kubernetes・コンテナ"] publisher: "株式会社一創" --- # 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リポジトリ](https://github.com/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.0.0 | 2026年6月9日 | `container machine`追加、設定がTOMLへ | | 1.1.0 | 2026年7月6日 | 非rootでのUnixソケットマウント、ネスト仮想化 | | 1.2.0 | 2026年7月29日 | CVE-2026-64786ほか脆弱性修正 | | 1.2.1 | 2026年8月7日 | `k8s`プラグイン追加、稼働中の`export`、`build --ssh` | | 1.2.2 | 2026年8月8日 | リリースpkgでの`container k8s`動作不具合修正 | | 1.3.0 | 2026年8月24日 | 既定カーネル更新、`--scheme auto`廃止 | | 1.3.1 | 2026年8月29日 | Containerizationの脆弱性修正6件 | | 1.4.1 | 2026年9月9日 | 脆弱性修正2件、`container clean`追加 | | **1.5.0** | **2026年9月29日** | k8sの脆弱性修正、`k8s start`削除 | **1.4.0は存在しません**。[1.4.1のリリースノート](https://github.com/apple/container/releases/tag/1.4.1)に、1.4.0のタグを破棄したため1.4.1に1.3.1以降の全変更が含まれると書かれています。 [1.5.0のリリースノート](https://github.com/apple/container/releases/tag/1.5.0)の要点は3つです。`container k8s`がゲスト側から受け取るkubeconfigの値を、ホストの`~/.kube/config`へ統合する前に無害化するようになりました（GHSA-44v5-vx46-ghv6）。`container k8s start`は削除され、止まったクラスタは削除して作り直す手順に変わりました（CLIの破壊的変更）。また、エントリポイントが空のイメージでも指定したコマンドが実行されるようになり、localhostのDNS設定を変えたあとにコンテナの外向き通信が切れる不具合が直っています。 ### Appleのコンテナ3種類と用途の違い | 呼ばれ方 | 実体 | 使う場面 | | ---------------------- | --------------------- | ------------------ | | `apple/container`（本記事） | Linuxコンテナを軽量VMで動かすCLI | Macでの開発・検証環境 | | アプリのコンテナ | App Sandboxのデータ領域 | macOS/iOSアプリのデータ隔離 | | APFSコンテナ | ボリュームを束ねる区画 | ディスク・ボリューム管理 | アプリのコンテナは`~/Library/Containers/`以下にアプリごとに作られる領域で、APFSコンテナはディスクユーティリティで見える区画です。どちらもLinuxコンテナの実行とは関係ありません。「Macでコンテナを動かしたい」という文脈のApple containerは、ほぼ例外なく`apple/container`を指します。コンテナと仮想マシンの違いから整理したい場合は[仮想マシンとは？物理マシン・コンテナとの違いから作成・運用まで実装者向けに解説](/tech/details/13372/)を参照してください。 ## Apple containerのアーキテクチャ：コンテナごとの軽量VM `container`は**コンテナごとに専用の軽量VMを起動します**。低レベルの処理はApple製のSwiftパッケージ[Containerization](https://github.com/apple/containerization)が担い、macOSのVirtualizationフレームワークでVMを、vmnetフレームワークで仮想ネットワークを扱います。 ### Docker Desktopの「共有VM方式」との違い macOSにはLinuxカーネルが無いので、どのツールでもLinuxコンテナはVMの上で動きます。Docker DesktopやColimaは**1台の大きなLinux VMの中に全コンテナを同居させる**方式で、コンテナ同士はカーネルを共有します。[公式のtechnical overview](https://github.com/apple/container/blob/1.5.0/docs/technical-overview.md)は、コンテナごとにVMを分ける利点を次の3点で説明しています。 - **隔離**：各コンテナがVMと同じ隔離境界を持ち、最小限の構成で攻撃面も小さい。 - **プライバシー**：ホストのデータは必要なコンテナにだけマウントすればよい。共有VM方式では、使うかもしれないデータをVM全体にマウントしておく必要がある。 - **性能**：フルVMより必要メモリが小さく、起動時間は共有VM上のコンテナと同程度。 素性のわからないコードやAIエージェントが生成したスクリプトを試す用途では、この隔離の強さがそのまま利点になります。隔離レベルの考え方は[仮想環境とは？venv・コンテナ・仮想マシンの違いと隔離レベルの選び方を実装者向けに解説](/tech/details/13536/)で整理しています。 ### 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のリファレンス](https://github.com/apple/container/blob/1.5.0/docs/container-system-config.md)では、`--cpus`と`--memory`を省いたときの既定は**4CPU・メモリ1GB**です。ビルダー用VMは2CPU・2GiBです。PostgreSQLやElasticsearch、メモリを食うビルドは1GBでは足りないことがあるので、`container run --memory 4g`のように明示するか、`config.toml`の`[container]`で既定値を上げてください。 ## インストールと初期設定 ### 動作要件：Apple siliconとmacOS 26 [公式README](https://github.com/apple/container/blob/1.5.0/README.md)は「Apple silicon搭載のMacが必要」「macOS 26でサポートする」と書いており、古いmacOSはサポート対象外で、macOS 26で再現しない問題には原則として対応しないとしています。technical overviewにはmacOS 15で動かす場合の制限（コンテナ同士が通信できない、`container network`系コマンドが使えない等）が残っていますが、**新しく導入するならmacOS 26が前提**です。Intel Macでは動きません。 ### 署名済みpkgのインストールとサービス起動 [GitHubのリリースページ](https://github.com/apple/container/releases)から署名済みのインストーラ（`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`を明示します。置き場所としてのレジストリの選び方は[コンテナレジストリとは？種類・選び方から企業の導入判断まで解説](/tech/details/13259/)で整理しています。 ### ネットワーク：コンテナごとのIPとDNS名 [公式のnetworkingドキュメント](https://github.com/apple/container/blob/1.5.0/docs/networking.md)のとおり、`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](https://github.com/apple/container/issues/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のドキュメント](https://github.com/apple/container/blob/1.5.0/docs/host-integration.md)が制限を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のドキュメント](https://github.com/apple/container/blob/1.5.0/docs/container-machine.md)によると、ホストのユーザー名とホームディレクトリが自動でマップされ、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公開・撤収まで](/tech/details/17438/)のとおりkindを使うほうが手順が固まっています。 ## Docker Composeの対応状況と代替ツール **1.5.0の`container`にDocker Compose相当の公式機能はありません**。[公式のコマンドリファレンス](https://github.com/apple/container/blob/1.5.0/docs/command-reference.md)に`compose`のサブコマンドは無く、要望のissue（#1846）も開いたままです。Web＋DB＋キャッシュをcompose.yamlで束ねて`up`一発で立ち上げる流れは、そのままは持ち込めません。 ### 第三者製のCompose互換ツール2つ | ツール | 実行方法 | ライセンス | 最新（2026年10月） | | ----------------- | ---------------------- | ---------- | ------------------------------ | | Container-Compose | `container-compose up` | Apache-2.0 | 1.2.0（9月21日） | | compose（orchard系） | `container compose up` | MIT | orchardはパッケージを内蔵、CLIプラグインは別途導入 | [Container-Compose](https://github.com/Mcrich23/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](https://github.com/andrew-waters/orchard)は、制限を2つ先に書いています。依存先を先に起動はするが準備完了までは待たないこと、ホスト名はマシン上の全コンテナで一意である必要があるため、サービスは`<プロジェクト名>-<サービス名>`で呼ぶことです。さらに、**`container`のインストーラは更新のたびにプラグインディレクトリを消す**ため、`container`を上げたらプラグインを入れ直す必要があります。 どちらもAppleのサポート対象外です。 ### 複数コンテナの手動構成とサービス名の名前解決制約 サービスが2〜3個なら、シェルスクリプトやMakefileで`container run`を並べるほうが確実です。そのときに引っかかるのが、前述の**カスタムネットワーク上で素のコンテナ名を引けない制約**です。接続文字列に`db:5432`と書く既存の設定はそのまま動かないので、`default`ネットワークで`[dns] domain`を設定して`db.test:5432`のようにドメイン付きの名前へ書き換えるか、`container inspect`で調べたIPを渡します。 Composeの仕組みそのものは[docker-composeとは？複数コンテナをymlで定義し一括管理する仕組みを解説](/tech/details/13282/)で解説しています。 ## VS Code Dev Containersの対応範囲と接続手順 使えるのは**「起動済みのApple containerにアタッチする」ところまで**です。Microsoftの担当者は[vscode-remote-release#11012](https://github.com/microsoft/vscode-remote-release/issues/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](https://github.com/apple/container/issues/2259)で報告されています。ポートの自動転送も効かず、Portsパネルで手動追加が要るとされています。チームで`devcontainer.json`を共有して「Reopen in Container」で揃える運用は、現時点ではDocker DesktopかOrbStackが前提です。`devcontainer.json`の書き方は[VS Codeで開発コンテナを作る（Create Dev Container）｜手順・devcontainer.json設定・複数コンテナ・言語別テンプレート](/tech/details/9565/)にまとめています。 ## つまずきやすい制限と注意点 ### コンテナのメモリ返却制限と再起動による対処 technical overviewが既知の制限として挙げています。macOSのVirtualizationフレームワークはメモリバルーニング（VMが使わないメモリをホストへ返す仕組み）を一部しか実装しておらず、**コンテナ内のプロセスがLinuxへ解放したメモリはホストへ返りません**。メモリを多く使うコンテナを長時間並べると、実際より多くのメモリがアクティビティモニタ上で埋まって見えます。対処は該当コンテナの再起動です。 ### Apple公式GUIの提供状況と第三者製orchard `container`は**CLIのみ**で、Docker DesktopやOrbStackのようなApple公式のGUIはありません。第三者製では[orchard](https://github.com/andrew-waters/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との使い分けを実装視点で解説](/tech/details/13574/)にまとめています。 ### 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/container | Docker Desktop | OrbStack | Colima | | ---------------------- | --------------- | -------------- | ---------- | ---------- | | VMの方式 | コンテナごとに軽量VM | 共有Linux VM | 共有Linux VM | 共有Linux VM | | Intel Mac | 非対応 | 対応 | 対応 | 対応 | | Docker互換API | なし | あり | あり | あり | | Compose・Dev Containers | 公式は非対応 | 対応 | 対応 | 対応 | | GUI | なし（第三者製あり） | あり | あり | なし | | 費用 | 無償（Apache-2.0） | 規模により有償 | 商用は有償 | 無償（MIT） | **Apple silicon＋macOS 26で、単体か少数のコンテナを強い隔離で動かしたい**なら`container`が有力です。**Compose・Dev Containers・Docker互換APIのどれかが必須**なら、Docker DesktopかOrbStackを使い続けるのが妥当です。各ツールの導入は[OrbStackとは？使い方・料金とDocker Desktopからの移行手順【v2.2系】](/tech/details/4058/)と[Colimaとは？MacでDocker Desktopを外す導入手順と設定の落とし穴【0.10系】](/tech/details/17842/)で解説しています。Windows側で同じ位置づけのMicrosoft製ツールは[WSL Containersとは？wslcの使い方とDocker Desktopとの使い分け【WSL 3.0.1時点】](/tech/details/18105/)です。 開発者のMacで作ったイメージを、そのままクラウドのコンテナ基盤へ載せるところまで設計したい場合は、弊社の[AWS・Google Cloud・Azureのインフラ構築支援](/service/system/aws/)でもご相談を受けています。 ### 採用を見送るべき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で定義し一括管理する仕組みを解説](/tech/details/13282/) - [OrbStackとは？使い方・料金とDocker Desktopからの移行手順【v2.2系】](/tech/details/4058/) - [Colimaとは？MacでDocker Desktopを外す導入手順と設定の落とし穴【0.10系】](/tech/details/17842/) - [VS Codeで開発コンテナを作る（Create Dev Container）｜手順・devcontainer.json設定・複数コンテナ・言語別テンプレート](/tech/details/9565/) - [Podmanとdockerの違いは？デーモンレス・rootlessの仕組みと移行判断](/tech/details/13202/) --- 出典: [Apple container（apple/container）とは？1.5系の使い方とDockerとの違い・compose代替とGUIの現状]()（株式会社一創）