Apple container（apple/container）とは？1.4系の使い方と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年9月時点の最新版は1.4.1です。ここでは仕組み・動作要件・インストール・主要コマンド・Docker Composeが使えるのかという実務上の分かれ目までを、公式リポジトリの一次情報に基づいて整理します。

まとめ

• apple/containerは、Apple siliconのMacでLinuxコンテナを動かすApple公式のOSS CLI（Swift製・Apache-2.0）。WWDC25で公開され、2026年9月時点の最新版は1.4.1（1.4.0はタグ破棄で欠番）。1.x系は脆弱性修正が続いており、版を固定して据え置く運用には向かない。
• 最大の特徴は「コンテナ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を使い続けるほうが早い。Compose互換のContainer-Compose、GUIのorchardなど第三者製の補完はあるが、いずれもAppleのサポート対象外。

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

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

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

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

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

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.0.0以降のリリースは次のとおりです（GitHub Releasesの公開日）。

1.3.0ではcontainer machineのmaskedPathsとreadonlyPathsが緩和され、イメージ操作の--scheme autoが廃止されて既定がhttpsになりました。1.4.1ではcontainer system statusの出力項目が変わっています（いずれも破壊的変更）。

この表で注意したいことが2つあります。

ひとつは1.4.0が存在しないことです。Appleはリリースノートで、1.4.0のタグを破棄したため1.4.1に1.3.1以降の全変更が含まれると明記しています。「1.4.0が見つからない」のは探し方の問題ではありません。

もうひとつはセキュリティ修正の頻度です。1.2.0、1.3.1、1.4.1と、1.x系の3リリースが脆弱性修正を含んでいます。内容もOCIイメージ読み込み時のシンボリックリンク追跡やローカルコンテンツストアのパストラバーサルなど、信頼できないイメージを扱うと踏みうるものです。版を固定して長く据え置く運用には向きません。0.12.2以前を使い続けている場合はもちろん、1.x系でも更新を追う前提で採用してください。

紛らわしい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変更が入るリリースがあるため、業務環境では版を固定したうえで、脆弱性の告知を追う前提で運用してください。1.x系は脆弱性修正が続いているため、固定したまま放置すると既知の脆弱性が残ります。

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

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

選択肢は実質3つです。

• 手動で組む：ネットワークを作り、各サービスをcontainer runで個別に起動するシェルスクリプトやMakefileを書く。サービスが2〜3個なら現実的です。
• サードパーティのCompose互換ツールを使う：compose.yamlを解釈してcontainerのコマンドへ変換するコミュニティ製ツールがあります。代表格がContainer-Compose（スター約925・2026年9月時点で更新継続）で、Homebrewから導入できます。ボリュームとネットワークのマッピングには対応していますが、作者自身がREADMEで「(limited) Docker Compose support」と断っており、対応するのは実装済みのキーに限られます。Apple公式のサポート対象ではありません。またREADMEには「macOS 15（Sequoia）ではDNSを自動構成しない」と明記されており、macOS 26での利用が前提です。なおライセンス表記が割れており、LICENSEファイルはApache-2.0ですがREADME本文はMITと書いています。
• Compose中心の環境ではDocker DesktopやOrbStackを使い続ける：もっとも確実です。Composeの仕組み自体はdocker-composeとは？複数コンテナをymlで定義し一括管理する仕組みを解説で解説しています。

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

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

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

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

公式GUIは提供されない

containerはCLIのみで、Docker DesktopやOrbStackのようなApple公式のGUIアプリはありません。コンテナ一覧やログの確認もターミナルから行います。

ただし「GUIがまったく無い」わけではなく、第三者製が複数あります。2026年9月時点でスター数が最も多いのがorchard（MIT・スター約1,560・更新継続）で、ほかにPodman Desktopの拡張、AppleContainerDesktop（Apache-2.0）などがあります。一方で更新が止まっているものもあるため（Craneは2025年6月を最後に更新なし）、選ぶ前に最終更新日を確認してください。

いずれもAppleのサポート対象ではありません。GUIでの管理が業務要件で、かつサポート窓口が必要なら、この点だけで採用が難しくなります。CLIとGUIの使い分けの考え方はCLIとは？コマンドライン操作の仕組みとGUIとの使い分けを実装視点で解説にまとめています。

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

リリースノートには「CLIの破壊的変更」「APIの破壊的変更」を示すマークが常に登場します。実際、1.0.0ではcontainer system propertyのgetとsetが削除され（listは現存）、0.12.0ではデフォルトで付与されるLinuxケーパビリティが削減されました（後者は既存コンテナの作り直しが必要でした）。チームで使うなら版を固定し、更新は検証環境で破壊的変更を確認してから本番へ上げる運用が現実的です。据え置きではなく、追随を前提にした固定です。

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

「置き換えるべきか」ではなく「どの用途で使うか」で考えるのが実務的です。Colimaの導入と設定の注意点はColimaの導入手順と設定の落とし穴をまとめた記事に整理しています。

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

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

比較表とは別に、「使わない」と判断してよい条件を挙げておきます。

• macOS 26へ上げられないMacが対象に含まれる：READMEは「macOS 26をサポートし、それ以前のmacOSはサポートしない。macOS 26で再現しない問題には対応しないことが多い」と明記しています。古いmacOSで動かす前提の検討は、動くかどうか以前にサポートの外です。
• 本番で複数サービスを常時動かす基盤にしたい：Compose相当の公式機能が無いため、依存順の起動やネットワークの管理を自前で持つことになります。オーケストレーションの安定性が要件なら割に合いません。
• 版を固定して長期間据え置きたい：1.x系は1.2.0・1.3.1・1.4.1と脆弱性修正が続いており、1.3.0では--scheme auto廃止という破壊的なCLI変更も入りました。更新を追い続けられない運用では、固定した版に既知の脆弱性が残ります。

逆に、開発者のMacがApple silicon＋macOS 26で揃っていて、扱うのが単体または少数のコンテナなら、上の3条件はどれも当たりません。

よくある質問

Apple containerとは何ですか？

Appleがオープンソースで公開しているコマンドラインツールapple/containerのことで、Apple silicon搭載のMac上でLinuxコンテナを軽量な仮想マシンとして実行します。Swiftで書かれApache License 2.0で公開されており、WWDC25の週にあたる2025年6月9日に0.1.0が公開されました。2026年9月時点の最新版は1.4.1です（1.4.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年9月時点の公式コマンドリファレンスに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・コンテナ・仮想マシンの違いと隔離レベルの選び方を実装者向けに解説
• コンテナレジストリとは？種類・選び方から企業の導入判断まで解説