T-CREATOR

Mac Apple Silicon（M1/M2/M3/M4）でDockerを快適に動かすためのTips集

Mac Apple Silicon（M1/M2/M3/M4）でDockerを快適に動かすためのTips集

Apple Silicon（M1/M2/M3）チップ搭載のMacは、高速かつ省電力という魅力を持つ一方、Dockerの動作にはいくつかの注意点と工夫が求められます。

今回は、Docker Desktop for Mac（Apple Silicon）を最大限に活用するための実践的なTipsをまとめてご紹介いたします。

Apple Silicon環境でのアーキテクチャ差異の理解

Mac M1/MXは「ARM64（aarch64）」アーキテクチャを採用しています。Dockerのイメージは従来、Intel Mac向けに「x86_64（amd64）」で構築されていることが多く、アーキテクチャの不一致によるエラーやパフォーマンス劣化が起こる可能性があります。

RosettaではDockerは動かない

AppleのRosetta 2により、多くのx86アプリケーションはM1/MX上で問題なく動作しますが、DockerはRosettaでは動作しません。Docker自体は仮想化技術に依存しており、Apple Siliconにネイティブ対応しているDocker Desktopをインストールする必要があります。

▶ Docker公式Apple Silicon対応バージョン:
https://docs.docker.com/desktop/mac/apple-silicon/

ネイティブ対応のイメージを優先的に使う

アーキテクチャの不一致を避けるため、可能な限りarm64対応のDockerイメージを選びましょう。

イメージの対応アーキテクチャを確認する方法

bashdocker buildx imagetools inspect node:18

出力に以下のようなアーキテクチャ情報が含まれていれば、arm64に対応していると確認できます：

json"platform": {
  "architecture": "arm64",
  "os": "linux"
}

--platform を明示的に指定してpull/buildする

どうしてもamd64イメージを使いたい場合でも、DockerはApple Silicon用に変換（エミュレーション）できます。その際は以下のように--platformオプションを活用します。

bashdocker run --platform linux/amd64 node:18

ただし、エミュレーションはCPUコストが高いため、パフォーマンスが著しく低下することがあります。開発中はあくまで代替手段と考えるのが賢明です。

buildx によるマルチアーキテクチャ対応

より高度な対応として、docker buildx を使うと、複数アーキテクチャに対応したイメージをビルド・pushできます。

buildxのセットアップ方法

bashdocker buildx create --name mybuilder --use
docker buildx inspect --bootstrap

マルチプラットフォーム向けのビルド例

bashdocker buildx build \
  --platform linux/amd64,linux/arm64 \
  -t myrepo/myimage:latest \
  --push .

このようにして、CI/CDなどで両アーキテクチャ向けのDockerイメージを一度にビルドし、配布することが可能となります。

詳細は公式ガイドをご参照ください：
https://docs.docker.com/buildx/working-with-buildx/

開発中のTips：コンテナキャッシュとボリュームの工夫

Apple Silicon MacでDockerを使う際には、ストレージI/Oがボトルネックになることもあります。以下の対策を講じることで改善が期待できます。

ボリュームの使用を最小限に

Docker Desktop for Macでは、ホストとコンテナ間のファイル同期において大きなオーバーヘッドが生じるケースがあります。特にnode_modulesのような大量の小ファイルは注意が必要です。

対策例：node_modulesをボリュームマウントしない

yaml# docker-compose.yml
volumes:
  - .:/app
  - /app/node_modules

このようにすることで、node_modulesはコンテナ内で管理され、Mac側との同期を回避できます。

キャッシュディレクトリの明示的な指定

BuildKitでキャッシュを活用することで、ビルド時間を大幅に短縮できます。

Dockerfile# Dockerfile
RUN --mount=type=cache,target=/root/.npm \
    npm install

これにより、依存関係の再インストールを避けられます。

詳しくは BuildKit のキャッシュ利用に関する公式ページをご参照ください：
https://docs.docker.com/build/cache/

開発時のDocker Desktop設定最適化

Docker Desktopの設定画面にあるリソース配分は、適切に設定しておかないと、メモリ不足や過剰なCPU使用による動作不良の原因となります。

リソース設定のベストプラクティス（例）

設定項目推奨値（M1/M2）
CPUs4～6
Memory4～8 GB
Swap1 GB
Disk60 GB 以上

設定方法は以下の公式ガイドを参照ください：
https://docs.docker.com/desktop/settings/mac/

Docker Composeでのアーキテクチャ指定

複数のサービスを扱う際に活躍するDocker Composeでは、イメージごとに明示的なプラットフォーム指定を行うことで、M1/M2でも安定動作を確保できます。

サンプル構成：docker-compose.yml

yamlversion: "3.9"

services:
  app:
    image: node:18
    platform: linux/arm64
    volumes:
      - .:/app
    working_dir: /app
    command: ["npm", "start"]

  db:
    image: postgres:15
    platform: linux/arm64
    environment:
      POSTGRES_USER: user
      POSTGRES_PASSWORD: pass

このようにplatformを明示しておくことで、Docker Desktopのアーキテクチャ推論ミスによる不具合を避けられます。

参考：Composeファイルリファレンス
https://docs.docker.com/compose/compose-file/compose-file-v3/

Rosettaでは解決できないエミュレーションの限界

Apple SiliconではRosetta 2により多くのアプリがx86上で動きますが、Dockerではqemuベースのエミュレーションが行われます。

問題例：x86バイナリを含むCLIツールがクラッシュ

bashdocker run --platform linux/amd64 hashicorp/terraform

このようなケースでは、ツール内部での/proc/cpuinfoなどの判定が失敗するため、想定外の挙動やクラッシュが発生します。

対応策

  • なるべくarm64対応の公式イメージに切り替える
  • Dockerfile内で明示的にARM向けバイナリをインストールする
DockerfileRUN curl -L https://releases.hashicorp.com/terraform/1.6.5/terraform_1.6.5_linux_arm64.zip \
  -o terraform.zip && unzip terraform.zip -d /usr/local/bin

よくあるエラーとその対処法

M1/MX環境に特有のエラーと、その原因および対策について以下にまとめます。

エラー内容原因対応策
exec format errorx86向けバイナリをarm64上で実行対応アーキテクチャのバイナリを使う
qemu: unsupported syscallQEMUエミュレータが未対応エミュレーションを避け、ネイティブに切り替える
Segmentation faultコンパイル済バイナリが未対応イメージやベースOSを見直す

対処の基本

  • uname -m や dpkg --print-architecture で動作環境を確認
  • Dockerfile内でアーキテクチャ分岐を実装する
DockerfileRUN ARCH=$(uname -m) && \
  if [ "$ARCH" = "aarch64" ]; then \
    echo "ARM用処理"; \
  else \
    echo "x86用処理"; \
  fi

パフォーマンス改善のTips

Apple Silicon環境でのDockerは非常に高速ですが、いくつかの設定を見直すことでさらに快適な開発体験を実現できます。

Volumeパフォーマンスの改善

MacホストとLinuxコンテナ間のファイル同期は遅延の原因になります。

cached オプションの使用

yamlvolumes:
  - .:/app:cached

これは読み取り中心のファイルに対してパフォーマンスを向上させます。

公式ドキュメント：
https://docs.docker.com/docker-for-mac/osxfs/#cached-and-delegated-options

ファイルシステムウォッチャーの抑制

Node.jsアプリなどでfs.watchやchokidarを多用すると、パフォーマンスが著しく低下する場合があります。

対処法：Watch対象ディレクトリを限定

js// chokidarの例
chokidar.watch(['src/**/*'], {
  ignored: /node_modules/,
  usePolling: false
});

GUIアプリのコンテナ化と制限事項

MacでGUIアプリ（例：ChromeやVSCode）をDocker内で動かしたいというニーズもありますが、Apple SiliconではX11互換問題やグラフィック系ドライバの未対応があります。

結論として：

  • GUIアプリのDocker化は原則非推奨
  • CLIベースの開発に集中するのが無難

コンテナ間通信の注意点

host.docker.internal が使えないケースが一部存在します。特にLinuxベースの公式イメージではこの名前解決ができません。

対応方法

bash# docker network を使って名前解決
docker network create mynet

docker run -d --network=mynet --name backend my-backend
docker run -it --network=mynet my-frontend curl http://backend:3000

このようにすることで、コンテナ名をDNSとして扱うことが可能です。

最後に：Apple SiliconのDockerは成熟してきた

2021年〜2023年にかけて多くの制限があったApple Silicon向けDockerですが、現在では公式の改善とコミュニティの対応が進み、ほとんどのユースケースで安定稼働が可能となってきました。

とはいえ、エミュレーションや互換性の観点から、「常にarm64ネイティブを意識することが成功の鍵」です。

まとめ

項目ポイント
イメージ選定arm64対応のものを優先
Docker設定リソース割当・キャッシュ活用
エラー対応アーキテクチャ差異を正確に把握
buildx活用マルチプラットフォーム対応の鍵
Docker Composeplatform指定で安定性UP

引き続き、公式ドキュメントの更新や新しいベストプラクティスに目を向けて、快適なDocker開発環境を維持していきましょう。

▶ Docker Desktop for Mac（Apple Silicon）公式：
https://docs.docker.com/desktop/mac/apple-silicon/

▶ Buildx公式ガイド：
https://docs.docker.com/buildx/working-with-buildx/

▶ Composeファイル参照：
https://docs.docker.com/compose/compose-file/

Dockerの記事Docker

記事Article

もっと見る