株式会社ホコサキ

apple/containerはDocker Desktopの代替になるか——Apple Silicon Macで検証した

天京祐輔
天京祐輔
apple/containerはDocker Desktopの代替になるか——Apple Silicon Macで検証した

Apple Silicon Macで日常的にDockerを使っているなら、Docker Desktopの重さに一度は不満を覚えたことがあるはずです。起動のもたつき、常駐するメモリ消費、そして一定規模以上の組織に課されるライセンス費用。そこに2025年のWWDC25で「Meet Containerization」セッションとともに公式に紹介されたのが apple/container です。

Lightweight VMというアーキテクチャが実務上の体験にどう影響するか——この一点に絞って、実際に手を動かした記録をベースに整理します。読み終わった後に「自分のプロジェクトで乗り換えるか・併用するか・見送るか」を自分の判断で決められる材料を持ち帰ってもらえれば十分です。

1コンテナ＝1VM という設計の意味

apple/container の正体を一言で言うと、Swiftで書かれたCLIツールです。Apple公式のOSSとして GitHub で公開されており、apple/containerization というフレームワークの上に乗っています。現在はv0.x系で活発に開発が続いており、GitHubのREADMEには「マイナーバージョン間では破壊的変更が入る可能性がある」と明記されています。

Docker Desktopとの本質的な違いはアーキテクチャにあります。Docker Desktopは「1つの共有Linux VMを起動し、その上で複数のコンテナを動かす」という構造です。コンテナ同士はLinuxのnamespaceとcgroupで分離されていますが、カーネルは共有しています。

一方 apple/container は、コンテナを1つ起動するたびに独立したLightweight VMを立ち上げるという設計を採っています。このLightweight VMはmacOSの Virtualization.framework を直接使って起動します。HyperKitやQEMUを経由しないため、Apple Siliconのハードウェア仮想化支援をストレートに活かせます。VMの起動オーバーヘッドが小さく抑えられているのはこのためです。

セキュリティの観点では、この設計は明確なメリットをもたらします。コンテナごとに独立したカーネルを持つため、あるコンテナのカーネル脆弱性が別のコンテナに波及しにくい。また各コンテナが独立したIPアドレスを持つため、ネットワーク分離も自然に実現されます。

トレードオフも正直に書いておきます。コンテナ数が増えるとVM数も増えます。10個のコンテナを同時に動かせば10個のVMが立ち上がる。軽量とはいえ、各VMが一定のメモリを消費することに変わりはありません。少数の独立したコンテナを動かすユースケースでは恩恵が大きく、多数のコンテナを密に連携させる構成では注意が必要です。

WWDC25のセッションでAppleは「secure, private, and performant」という言葉でこの設計を紹介しました。マーケティング的な表現ではありますが、1コンテナ＝1VMというアーキテクチャの必然として、その三つは確かに成立しています。

インストールから基本操作まで——手を動かした記録

前提条件を先に整理します。動作には Apple Silicon Mac（M1以降）と macOS Tahoe（26 beta）以降が必要です。筆者はM2・macOS Tahoe beta環境で検証しました。macOS Sequoiaでの動作は確認できていないため、現時点では Tahoe beta 環境を前提として読んでください。

インストールは公式リポジトリの Releases ページ からバイナリを取得する方法が確実です。インストール後、まずシステムサービスを起動します。container はデーモンレスではなく、バックグラウンドのシステムサービスとして動作します。

# サービス起動
container system start

# イメージのpull
container pull nginx:alpine

# 基本的なコンテナ起動
container run --name web nginx:alpine

# ポートフォワードを指定して起動
container run --name web -p 8080:80 nginx:alpine

# ボリュームマウントを加える
container run --name web -p 8080:80 -v $(pwd)/html:/usr/share/nginx/html nginx:alpine

# コンテナ一覧・停止・削除
container list
container stop web
container rm web

コマンド体系は docker とよく似ていて、docker を container に置き換えるだけで動くケースが多いです。ただし完全互換ではなく、オプションの一部は未実装だったり挙動が異なったりします。慣れた手順で叩いて「あれ、このオプションが効かない」となる場面は覚悟しておいた方がいいでしょう。

実際に触って気づいたのは、初回起動時の感触です。Docker Desktopのように「VMが温まるまで待つ」という感覚がなく、container run を叩くとほぼ即座にコンテナが応答し始めます。nginxを起動して curl localhost:8080 で応答を確認するまで、体感で2〜3秒ほど。Docker Desktopで同じことをすると、デーモンが起動済みでも数秒のラグを感じることがあるのと比べると、明らかに軽いです。

ログの表示は container logs web で標準出力がそのまま流れてきます。余計な抽象化レイヤーがない分、「コンテナの中で何が起きているか」が素直に見えるという印象で、デバッグ時のストレスが少ないです。

Docker Composeとの互換性——既存資産はどこまで動くか

apple/container を実務で使う上で最初に直面するのが、Compose機能が存在しないという事実です。OCI準拠なのでDocker HubのイメージもDockerfileもそのまま使えますが、docker-compose.yml を読み込んで複数コンテナを一括起動する機能は本体に含まれていません。

互換性の現状を整理するとこうなります。

  • 使える: OCI準拠のコンテナイメージ（Docker Hub等）、Dockerfile、container run の基本オプション
  • 使えない: docker-compose.yml のネイティブ実行、Docker Composeのサービス依存関係管理
  • 回避策あり: コミュニティ製の container-compose（Hacker Newsで紹介されたOSS）、または手動でコンテナを繋ぐシェルスクリプト

複数コンテナを手動で繋ぐアプローチについては、Mediumに公開された移行事例（Migrating a Real docker-compose Stack to Apple's Container CLI）が参考になります。Node.js API・Postgres・Redisの3サービス構成を apple/container に移行した事例で、コンテナ名がDNS名として解決されることを活かしつつ、依存関係と起動順序をシェルスクリプトで管理するアプローチが紹介されています。「一度書いてしまえば再利用できる」という評価をしており、移行コストは思ったより小さいとのことです。

ただし docker-compose.yml が持つ depends_on・healthcheck・restart ポリシーといった宣言的な設定を手動で再現するのは手間であることに変わりはありません。「既存の docker-compose.yml をそのまま持ち込む」は現時点では無理、というのが正直な結論です。container-compose の成熟度次第ではありますが、現状では移行コストを見積もった上で判断する必要があります。

ローカルLLMと業務開発環境——実務シナリオで見えた適性と限界

AI推論ワークロードへの適性

AI活用支援の文脈で最初に気になるのが、OllamaなどのローカルLLM実行環境としての適性です。結論から言うと、現時点ではMetalパススルーが未対応です。

GitHub Discussions #62 では複数の開発者から要望が上がっており、AI推論プラットフォームを開発しているエンジニアが「macOSではパフォーマンスのためにホスト上で直接ランタイムを管理している」と述べているコメントが象徴的です。Metalが使えないということは、コンテナ内でのLLM推論はCPUのみで動くことになります。

小規模なモデルの動作確認や、推論ではなくAPIサーバー部分のコンテナ化といった用途なら現実的ですが、M2/M3のGPUコアをフル活用した高速推論をコンテナ内で実現したいなら、今はまだホスト上でOllamaを直接動かす方が合理的です。Metalパススルーは今後の開発で対応が期待される機能ですが、現時点では待ちの状態です。

業務システム開発環境での使い心地

Rails・Django・Node.jsといったWebアプリケーションの開発環境としては、apple/container の軽量・高速起動という特性が素直に活きます。アプリサーバー単体を素早く立ち上げてコードの動作確認をする、というサイクルでは体感的な速さが出ます。

ただし、実際の業務開発環境はアプリサーバー単体で完結することはほぼなく、DB・キャッシュ・メッセージキューといった周辺サービスとの組み合わせが前提になります。前節で触れたComposeの不在がここで効いてきます。3〜4サービスを手動で繋ぐシェルスクリプトを書いて管理するのは、慣れれば問題ないレベルですが、チームで共有する開発環境として docker-compose.yml の代わりに使うには、それなりの整備コストがかかります。

v0.x系という成熟度も判断に影響します。マイナーバージョン更新で破壊的変更が入る可能性があるツールを、複数人が使うチーム開発環境の基盤に据えるのはリスクがあります。個人の開発マシンで試す分には問題ありませんが、チーム標準化は1.0.0リリースを待つのが現実的な判断でしょう。

乗り換え・併用・見送りの判断軸

採用判断は用途と文脈によってかなり変わります。整理するとこうなります。

  • 乗り換え推奨: 単一コンテナで完結する用途（CLIツールの実行環境・シンプルなWebサーバーの動作確認など）で、Docker Desktopのライセンスコストやリソース消費に不満がある個人開発者。Composeの不在が制約にならない用途であれば、今すぐ移行する理由がある
  • 併用推奨: 軽量な単体コンテナは apple/container で、Composeを使う複数サービス構成はDocker Desktop（またはOrbStack）で、と用途で使い分けるケース。新しいツールを試しながら既存環境を壊したくないチームにも向く
  • 見送り推奨: ローカルLLM推論でMetalを使いたい・docker-compose.yml をそのまま流用したい・チーム全員が同じ環境を使う必要がある、といった制約がある場合。v1.0.0リリースまで待つという判断も十分合理的で、焦って移行する必要はない

apple/container は「Docker Desktopを完全に置き換えるもの」として今すぐ採用するには、まだ機能的なギャップがあります。一方で、Lightweight VMというアーキテクチャの方向性は技術的に筋が通っており、Appleが公式に開発を続けているという事実は重みがあります。今の段階で触っておくことで、成熟した時の判断が速くなる——そういう位置づけで手元に置いておくのが、現時点では最も実用的な関わり方だと思っています。

株式会社ホコサキは、山口県宇部を拠点にWeb制作・業務システム開発・AI活用支援・DX推進に取り組んでいます。apple/container のような新しいツールの評価や、開発環境の整備・改善についてご相談があれば、お問い合わせページからお気軽にどうぞ。