Colimaは、Mac上にLinux仮想マシンを1台立て、その中でDockerやcontainerdを動かすためのオープンソースのツールです。ライセンスはMITで、2026年6月4日公開のv0.10.3が9月時点の最新版にあたります。Docker Desktopを入れずにdockerコマンドとdocker composeをそのまま使えるため、課金境界を超えた組織の置き換え先として名前が挙がります。
この記事では、Homebrewでの導入から、作り直しが必要になる設定項目、Rosettaでのamd64実行、TestcontainersやbuildxをColimaへ向ける設定までを、コピーして動かせる形で扱います。最後に、受託開発の端末で標準にしてよい条件と見送る場面を示します。
まとめ：Colimaを入れる前に決めておく設定と採用の線引き
先に結論です。Apple Silicon機でmacOS 13以上なら、初回のcolima startで--vm-type vz --mount-type virtiofsを明示し、CPUとメモリも既定の2コア・2GiBから引き上げて作成してください。VMの種類やマウント方式はあとから変えられず、変えるにはVMの削除が要ります。
- 構成：ColimaはLimaの上位ツールで、Linux VMの作成・起動・docker contextの登録までを1コマンドで済ませる。Homebrewのformulaもlimaに依存している
- 導入：
brew install colima docker docker-composeでCLIまで揃う。Docker Desktop本体は不要 - 既定値：CPU 2、メモリ2GiB、ディスク100GiB。VM種別の既定はドキュメントと実装で記述が食い違うため、明示指定が安全
- 作り直しが要る項目：arch・runtime・vmType・mountTypeの4つ。ディスクは増やす方向にしか変えられない
- 詰まる箇所：ホームディレクトリ外のバインドマウント、buildxとcomposeのプラグイン検出、TestcontainersのDocker接続先
- 見送る場面：GUIの診断画面や同梱Kubernetesに頼るメンバーが多いチーム、CLIの面倒を見る担当者を置けないチーム
ColimaとはLima上のLinux仮想マシンでDockerを動かすMac用ツール
LinuxコンテナはLinuxカーネルの機能で隔離されるため、macOSのカーネルの上では直接動きません。どの製品を選んでも、Mac上ではLinuxの仮想マシンを1台用意し、その中でコンテナを動かすことになります。この前提はコンテナと仮想マシンの違いから導入判断までをまとめた解説で整理しています。
Colimaが担うのは、その仮想マシンの作成・起動・停止と、ホスト側のdockerコマンドから中のデーモンへ届くソケットの用意です。仮想マシンそのものはLimaが動かしており、公式FAQは「Colima is a higher level usage of Lima」と説明しています。Limaを直接使うと設定ファイルを書く手間がかかるところを、ColimaはDocker向けの既定値つきで包んだ形です。
Docker・containerd・Incusから選べるランタイムと0.10系の追加点
ランタイムは起動時の--runtimeで選び、既定はdockerです。GitHubのREADMEに載っている選択肢はdocker、containerd、Incusの3つで、dockerとcontainerdには--kubernetesでk3sを載せられます。containerdを選んだ場合はcolima nerdctl経由で操作する形になります。
2026年2月10日のv0.10.0では、GPUへのアクセスを重視した仮想マシン種別krunkitと、colima model runによるAIモデルの実行が加わりました。ただしkrunkitは設定テンプレート上で実験的と明記されています。業務端末の標準にするなら、現時点ではdockerランタイムとvzの組み合わせに絞るのが無難です。
Docker Desktopのライセンス境界とColimaへ移る判断の関係
Colimaが比較対象に上がる最大の理由は費用です。Dockerのライセンス説明では、Docker Desktopを無料で使える小規模事業者を「従業員250人未満かつ年間売上1000万ドル未満」と定めています。同じページには、Docker EngineなどオープンソースのDocker・Mobyプロジェクトの条件は変わらないとも書かれています。
ColimaはDocker Desktopを使わず、Linux VMの中でオープンソースのDocker Engineを動かす構成です。境界の当てはめ方や、有料プランの人数ごとの年額試算はDocker Desktopの導入手順とライセンス境界を扱った記事に譲ります。本記事は、境界を超えたと判断したあとの置き換え作業に絞ります。
HomebrewでColimaとDocker CLIをインストールして起動する手順
導入はHomebrewで完結します。2026年9月25日時点のHomebrewのcolima formulaは0.10.3で、依存としてlimaが一緒に入ります。dockerのCLIは29.8.1、docker-composeは5.5.1が入る版です。
# Colima本体とDocker CLI・Composeを入れる（Docker Desktop本体は入れない）
brew install colima docker docker-compose
# Apple Silicon・macOS 13以上：VM種別とマウント方式を明示して作成する
colima start --cpu 4 --memory 8 --disk 60 --vm-type vz --mount-type virtiofs
# 状態と接続先を確かめる
colima status
docker context ls
docker run --rm hello-worldcolima statusでRunningと出て、hello-worldのメッセージが返れば導入は終わりです。CPU 4コア・メモリ8GiBは、Webアプリとデータベースをdocker composeで同時に立てる想定の値として置いています。ビルドが重い案件ではメモリを12GiB程度まで上げてください。
docker contextの自動切り替えとDocker Desktopとの共存
公式FAQによると、Colimaはv0.3.0からdocker contextに対応しており、起動時に自分を既定のコンテキストに設定します。Docker Desktopが入ったままの端末でも共存はできますが、どちらへコマンドが飛んでいるかを取り違えやすい構成です。
# 現在の向き先を確認する（*が付いているものが有効）
docker context ls
# Colimaへ向ける
docker context use colima
# Docker Desktopへ戻す
docker context use default移行期間に両方を残すなら、朝一番にdocker context lsを確認する手順を周知しておくと取り違えを防げます。Docker Desktopを外したあとにdockerコマンドが「credentials helper」関連のエラーで止まる場合は、~/.docker/config.jsonに"credsStore": "desktop"が残っていないかを確かめてください。Docker Desktopが書き込んだ設定で、本体を外すと参照先が消えます。
brew servicesでログイン時にVMを自動起動させる設定
毎朝colima startを打つ運用が面倒なら、Homebrewのサービスとして登録できます。FAQはbrew services start colimaと、v0.5.6以降の--foregroundフラグの2通りを案内しています。
自動起動は、VMの作成を済ませてから登録するのが順序です。brew services経由の起動では引数を渡しにくいため、CPUやメモリの指定は次章のcolima.yamlへ書いておきます。
colima.yamlの既定値と作り直しが要るVM種別・マウント方式の決め方
起動時のフラグは、プロファイルごとの設定ファイルへ保存されます。場所は$HOME/.colima/default/colima.yamlで、別プロファイルなら$HOME/.colima/<プロファイル名>/colima.yamlです。colima start --editでエディタが開き、保存すると次回起動から反映されます。
# $HOME/.colima/default/colima.yaml の主要項目（抜粋）
cpu: 4
memory: 8
disk: 60
arch: host
runtime: docker
vmType: vz
mountType: virtiofs
rosetta: false
mounts: []既定値は設定テンプレートによるとCPU 2、メモリ2GiB、ディスク100GiB、archはhost、runtimeはdockerです。メモリ2GiBではデータベースとアプリを同時に動かす開発に足りない場面が多いため、初回から引き上げておきます。
ドキュメントと実装で食い違うvmTypeの既定を明示指定で避ける
VM種別の既定には注意が要ります。設定テンプレートと設定ドキュメントは、vmTypeの既定をqemuと記載しています。一方でソースコードのenvironment/vm.goにあるDefaultVMTypeは、macOS 13以上ならvzを返す実装です。マウント方式も連動し、vzならvirtiofs、qemuならsshfsが既定になります。
つまり同じcolima startでも、macOSの版によって作られるVMが変わります。ドキュメントを読んだ人と実際に動かした人で認識がずれる原因になるため、手順書では--vm-typeと--mount-typeを必ず書き、既定値には頼らないでください。テンプレートはvirtiofsを「最も速い」と説明しており、vzを使える端末ではこれを選ばない理由がありません。
arch・runtime・vmType・mountTypeの4項目は削除と再作成が必要
設定ドキュメントは、arch、runtime、vmType、mountTypeの4項目をVM作成後に変更できない不変設定としています。設定ファイルを書き換えて再起動しても反映されず、変えるにはVMを消して作り直すことになります。ディスク容量も、テンプレートの注記どおり増やす方向にしか変えられません。
# 設定を変えるためにVMを作り直す（コンテナとイメージは消える）
colima stop
colima delete
# v0.9.0以降はコンテナのデータごと消す指定もできる
colima delete --data
colima start --vm-type vz --mount-type virtiofs --cpu 4 --memory 8作り直すとVM内のイメージとボリュームは失われます。レジストリから取り直せるイメージは気にしなくて構いませんが、ローカルにしかないデータベースのボリュームは、作業前にdocker volume lsで洗い出して退避してください。
Apple Silicon機のamd64イメージ用Rosetta設定とプロファイル分割
Apple Silicon機では、VMのアーキテクチャはhost、つまりarm64になります。amd64向けにしか配布されていないイメージを動かす手段は2つあります。
1つ目はRosettaです。設定テンプレートによるとrosetta: trueはvzでのみ有効で、起動時には--vz-rosettaを付けます。arm64のVMのままamd64のバイナリを変換して実行する方式で、arm64向けのイメージと同じVMに同居させられます。2つ目は--arch x86_64でVMそのものをamd64にする方式です。この場合はqemuでCPUごと模倣するため、両者の速度差は案件のイメージで測ってから決めてください。
案件ごとにVMを分ける–profileの使い方と設定の保存先
amd64前提の案件とarm64で完結する案件を同じ端末で扱うなら、VMをプロファイルで分けます。--profileを付けると別のVMが作られ、設定もソケットも別の場所に置かれます。
# arm64で完結する案件用（default）
colima start --vm-type vz --mount-type virtiofs --cpu 4 --memory 8
# amd64イメージが必要な案件用。Rosettaを有効にした別VM
colima start --profile amd64 --vm-type vz --vz-rosetta --mount-type virtiofs --cpu 4 --memory 8
# 一覧と切り替え
colima list
docker context use colima-amd64プロファイルを分けると、片方の作り直しがもう片方に波及しません。メモリはVMごとに確保されるため、両方を同時に起動すると16GiB近くを占めます。使わない側はcolima stop --profile amd64で止めておいてください。
TestcontainersとbuildxをColimaへ向ける接続設定の書き方
Docker Desktopを外したあとに壊れやすいのは、dockerコマンド以外からDockerへつなぐ経路です。Docker Desktopは/var/run/docker.sockを用意していましたが、Colimaのソケットは公式FAQのとおりv0.4.0以降$HOME/.colima/default/docker.sockにあります。ソケットの場所を決め打ちしているツールは、ここで接続に失敗します。
Testcontainersに必要な環境変数3つとネットワークアドレス
JavaのTestcontainersは、対応環境のページでColima向けの設定を示しています。VMにIPアドレスを持たせて起動し、3つの環境変数を設定する形です。
# VMにホストから届くIPアドレスを割り当てて起動する
colima start --network-address
# ~/.zshrc などに書いておく
export TESTCONTAINERS_DOCKER_SOCKET_OVERRIDE=/var/run/docker.sock
export TESTCONTAINERS_HOST_OVERRIDE=$(colima ls -j | jq -r '.address')
export DOCKER_HOST="unix://${HOME}/.colima/default/docker.sock"--network-addressは、FAQによるとroot権限が必要で起動にも時間がかかります。テストでコンテナを使わない端末では付けなくて構いません。2行目のjqはHomebrewで別途入れてください。
buildxとcomposeのプラグインを認識させるconfig.jsonの追記
Homebrewで入れたComposeとbuildxは、そのままではdockerコマンドから見えない場合があります。docker-buildxのformula（2026年9月時点で0.37.1）は、~/.docker/config.jsonへcliPluginsExtraDirsを追記するよう注意書きを出しています。
{
"cliPluginsExtraDirs": [
"/opt/homebrew/lib/docker/cli-plugins"
]
}パスはApple Silicon機のHomebrewの場所です。Intel機では/usr/local/lib/docker/cli-pluginsに読み替えます。追記後にdocker buildx versionとdocker compose versionが返れば認識されています。
ホームディレクトリ外のマウントやDNS不調で詰まる箇所と戻し方
導入後の問い合わせで多い症状は、公式FAQのTroubleshootingに対処が載っています。優先度の高い順に並べます。
| 症状 | 原因 | 対処 |
|---|---|---|
| マウントした中身が空 | ホーム外は共有されない | mountsに追記しrestart |
| 名前解決できない | VM内のDNS設定 | –dnsで解決先を指定 |
| statusがBroken | VMの状態不整合 | stop –force後に再起動 |
| ディスクが減らない | 未使用領域の未解放 | 起動時に自動解放 |
| ディスクが足りない | 既定値の不足 | diskを増やして再起動 |
最も多いのは1行目です。既定で書き込み可能にマウントされるのはホームディレクトリだけで、/Users/$USERの外に置いたソースを-vで渡すと中身が空に見えます。colima.yamlのmountsに対象のパスを足し、colima restartで反映させてください。
DNSはcolima start --dns 8.8.8.8 --dns 1.1.1.1で指定でき、colima ssh -- ping -c4 google.comで疎通を確かめられます。社内プロキシやVPNを使う端末では、社内の解決先を指定する必要があるため、情報システム部門と値を揃えておきます。
Docker Engineの更新をcolima updateで反映させる運用
Docker Desktopは本体の更新でEngineも上がりますが、Colimaではbrew upgrade colimaだけではVM内のDocker Engineは上がりません。FAQはv0.7.6以降のcolima updateで、VM内のコンテナランタイムを更新する手順を案内しています。
更新の順序は、Homebrewでcolimaとdocker CLIを上げ、続けてcolima updateを実行する流れです。CLIとEngineの版が大きく離れると、新しいオプションが通らない不具合の切り分けに時間を取られます。チームでは月に1回など更新日を決めておくと、端末ごとの版のばらつきを抑えられます。
受託開発の端末でColimaをチーム標準にする条件と見送る場面
ここからは判断です。Colimaは無料で軽い一方、GUIがなく、困ったときに頼れるのはCLIと公式FAQだけです。次の3条件がそろうなら、チームの標準にして構いません。
- Docker Desktopの課金境界を超えている：従業員250人以上、または年間売上1000万ドル以上で、Desktop固有の機能に払う理由がない
- 開発がdocker composeで完結している：同梱Kubernetesや拡張機能、GUIのリソース画面を日常的に使っていない
- 設定を配る担当者を置ける：
colima templateで作る既定テンプレート（$HOME/.colima/_templates/default.yaml）とconfig.jsonの追記を、手順書として配布・保守できる
逆に、CLIに不慣れなメンバーが多く、問い合わせ窓口を置けないチームでは見送ります。費用は浮いても、VMの作り直しやソケットの接続先といった問い合わせ対応に工数を払うことになるためです。Docker Desktopの中で仮想化方式を替える選択肢はDocker VMMの切り替え判断を扱った記事に、Apple純正の実行環境はApple containerの使い方とDockerとの違いをまとめた記事に整理しています。
開発端末とクラウドの実行環境をそろえて本番との差を減らす設計
Colimaで置き換えられるのは、開発端末の実行基盤だけです。本番との差で不具合が出ているなら、端末側を替えても解決しません。ベースイメージの版、arm64とamd64のどちらでビルドするか、本番のコンテナ実行基盤の構成を、クラウド側と揃えて設計する必要があります。社内で設計や運用の手が足りない場合は、一創のインフラ構築（AWS・Google Cloud・Azure）で、開発環境と本番環境の構成を揃える設計から相談できます。
よくある質問
Colimaの導入と運用について、検索で多い質問に答えます。
Colimaは無料で商用利用できますか？
できます。ColimaはMITライセンスで公開されており、中で動くDocker Engineもオープンソースの条件で配布されているソフトウェアです。Dockerのライセンス説明でも、Docker Engineなどオープンソースプロジェクトの条件は変わらないと明記されています。有料の対象になるのはDocker Desktopで、従業員250人以上または年間売上1000万ドル以上の組織が該当します。
ColimaとLimaはどう違いますか？
Limaは、MacでLinux仮想マシンを動かす基盤そのものです。ColimaはLimaの上に載るツールで、Docker向けの既定値でVMを作り、ソケットとdocker contextの登録まで自動で済ませます。Limaを直接使う場合は、VMの定義ファイルやランタイムの導入を自分で書く必要がある構成です。Dockerを動かす目的だけならColimaで足ります。
Docker Desktopと同じ端末に入れても大丈夫ですか？
同じ端末での共存は可能です。公式FAQはv0.3.0からdocker contextで切り替えられると説明しています。ただしColimaは起動時に自分を既定のコンテキストにするため、向き先を取り違えやすくなります。移行期間だけ共存させ、落ち着いたらDocker Desktopを外す運用が安全です。外したあとはconfig.jsonのcredsStoreを確認してください。
Colimaの設定を変えたのに反映されないのはなぜですか？
arch、runtime、vmType、mountTypeの4項目は、VM作成後に変更できない不変設定だからです。設定ファイルを書き換えても、既存のVMは作成時の値のまま動きます。変更するにはcolima deleteでVMを消して作り直すことが必要です。CPUやメモリ、ディスクの増量はcolima start --editで変更でき、次回起動から反映されます。
ColimaでKubernetesは使えますか？
使えます。dockerかcontainerdのランタイムでcolima start --kubernetesを付けると、VMの中でk3sが起動し、kubectlのコンテキストも登録されます。ただしDocker Desktopの同梱Kubernetesとは別物なので、マニフェストの動作確認は改めて行ってください。本番に近いクラスタで検証したい場合は、kindなど別の手段と比べて選びます。
関連記事
- OrbStackとは？Docker Desktopより軽いMac用コンテナ環境の特徴・料金・使い方：Colima以外のMac向け代替を、有償ツールの側から比べられます
- Podmanとdockerの違いは？デーモンレス・rootlessの仕組みと移行判断：Docker Engineを動かす構成そのものを見直す場合の判断材料です
- docker-composeとは？複数コンテナをymlで定義し一括管理する仕組みを解説：Colimaへ移したあとも使い続けるcompose定義の読み方が分かります
- Dev Container（devcontainer）のメリットとは｜Dockerで開発環境を統一する仕組みと設定：端末ごとの差を設定ファイルで吸収する方法を扱っています
- Dockerの仕組みを原理から理解する｜コンテナ隔離・アーキテクチャ・VMとの違い：ColimaのVMの中で何が動いているかを原理から確認できます
