「コンテナ関連のツールが 2 つ入ってるの、違和感あるんだよね。無駄に容量食うし」
筆者の Mac には OrbStack と Lima が同居している。OrbStack は普段の開発用。Lima は、sandbox の中で動かしている AI エージェントに使わせる docker を、Mac から切り離して動かす隔離 VM 用に後から足した。コンテナの道具が 2 つ。どう見ても重複だ。隔離 VM を一緒に作った Claude Codeに確かめた。「Lima は OrbStack じゃ実現できないから入れた、って認識で合ってるよね？」
続く 3 往復で、AI は一本化を勧め、撤回し、最後に容量を測ってきた。結論は、2 つのまま。決め手は、一本化を勧めた AI への「なんで？」の一言だった。
「OrbStack じゃできないから入れた」で合っているか
AI の答えは「合っています」。OrbStack の Linux マシンは Mac のファイルを /mnt/mac に見せ、host.orb.internal で Mac 上のサーバーにも届く。コンテナにも、Mac のファイルをそのまま bind mount できる。普段の開発ではありがたい統合も、閉じ込めたい相手から見れば裏口の一覧表だ。
Lima も素のままでは閉じない。既定のネットワークでは、VM から host.lima.internal で Mac の 127.0.0.1 に届く。だから筆者は、VM が Mac にも LAN にも届かないよう Lima にパッチを当て、共有は作業用の一時ディレクトリ 1 つに絞った。
AI はさらに、OrbStack には「これを切る設定はありません」と言い切った。筆者はそこを素通りした。記事を書くにあたって公式 docs を確かめると、あった。OrbStack には v2.1.0（2026 年 4 月）から isolated machine がある。Mac のファイルを mount せず、Mac にも直接届かず、用途にはご丁寧に AI エージェントまで挙げている。
ただし同じページに「完全なセキュリティ境界ではない」とも書いてある。全マシンとコンテナが 1 つの Linux カーネルを共有するからだ。isolated machine に入れたエージェントの隣の部屋で、普段の compose が同じカーネルに乗る。壁はあっても、床は一枚。カーネルごと分けたいなら別 VM、という結論は動かない。
筆者の認識は半分だけ合っていた。外れていた半分は、筆者が素通りしたところにあった。
| OrbStack | Lima | |
|---|---|---|
| 料金 | 個人の非商用は無料。商用は Pro $8/ユーザー/月 | 無料。Apache 2.0 |
| カーネル | 全マシン・コンテナで 1 つを共有 | VM ごとに別 |
| Mac のファイル | 通常は /mnt/mac に見える。isolated machine は指定したフォルダだけ | 既定のテンプレートはホームを読み取り専用で mount。外せる |
| VM から Mac へ | 通常は届く。isolated machine は届かない | 既定で Mac の 127.0.0.1 に届く。vz の VM で塞ぐ設定は v2.3 で入る予定（11 月 1 日時点で rc） |
| メモリ | 使う分だけ確保し、空きは macOS に返す | VM ごとに上限を決める。既定は 4GiB とホストの半分の小さいほう |
| 向く役 | 手で回す compose、普段の開発 | 中身を信用しないエージェントに渡す docker |
「なら Lima に寄せればシンプルでは」
筆者は docker compose up を手でしょっちゅう打つ。向け先が Lima でも困らないなら、そっちのほうがシンプルでは？ と続けた。
AI は乗ってきた。手作業用の Lima VM をもう 1 台立て、OrbStack を外す手順まで添えて。ところが同じ返答に見立てとして並んだ比較は、メモリもファイル共有の速さもポートの扱いも、OrbStack が上か同等。比較は OrbStack 優勢なのに、勧めは Lima。見事な背中合わせである。
しかも手当てが 1 つ要るという。Lima は全 VM に共通の ssh 鍵で入る。そこへホームを書き込みで mount する VM を足すとどうなるか。Mac 側の sandbox でホームへの書き込みを止めていても、その鍵を読めるエージェントは VM に入り、VM 経由で Mac のホームを書き換えられる。玄関に鍵をかけたまま、勝手口を増やす話だ。
そこで、ごく素朴に聞き返した。「OrbStack に分がありそうに書いてあるのに、なんで Lima に一本化を勧めるの？」
AI はあっさり撤回した。Lima に寄せても、VM は隔離用と手作業用で 2 台。減るのは OrbStack というアプリ 1 つで、代わりに 2 台の設定・起動・更新を自分で抱える。「一本化はシンプル」という前提に引っ張られ、自分で並べた比較と逆の結論を出していた、と。
1 つにまとめる案を数えてみたら、VM が 2 台残っていた。
「二重に持ってない？」と聞いたら
最後の懸念は容量。2 つ入れていたら、container image も volume も二重に持っているのでは？
AI は推測で答えず、両方の docker の容量を測ってきた。
- 二重になっていたのは postgres の image の 400MB ほど。tag も違い、厳密には別物だった
- 容量を食っていたのは、OrbStack 側の使っていない image の 21GB だった
- Lima 側には、使っていない匿名 volume が 9 個、432MB 溜まっていた
AI はついでに volume の出どころも突き止めてきた。犯人は筆者の自作の DB 払い出しスクリプト。テスト用の postgres を消す docker rm -f に -v が無い。postgres の image は VOLUME を宣言しているので、コンテナごとに匿名 volume ができる。-v 無しで消すと残る。手元でも、-v の有無で残る・消えるがきれいに分かれた。
容量を食うのは二重持ちだと思っていた。実際は、一重のほうが静かに太っていた。太らせたのは、OrbStack 側は筆者の放置、Lima 側は筆者のスクリプトだった。
2 週間後の 11 月 1 日に測り直すと、今度は Lima 側が育っていた。image が約 4GB（docker の集計では 85% が回収できる分）、build キャッシュが約 3GB。並ぶのは node の base image が中心で、AI が「今後増えうる経路」に挙げたとおりの増え方だ。匿名 volume は 0 個で、-v を付けてからは溜まっていない。postgres 17 に加えて node 22 も両側に入り、AI の言った二重持ちの経路が動き始めている。「とはいえ数 GB 程度の話」という AI の見立てまで、きっちり当たっていた。
掃除も docker ごとに別だ。OrbStack 側で prune しても、Lima 側は 1 バイトも減らない。
エージェントに確かめさせること
| 確かめさせること | 外すと起きること |
|---|---|
| 一本化を勧められたら、自分で並べた比較と結論が同じ向きか言わせる | 「シンプル」という前提だけで、不利な案に寄る |
| まとめた後に残る VM・アプリ・設定を数えさせる | 1 つにしたつもりで、自分で抱えるものが増える |
| 「できない」「設定はない」と言われたら、公式 docs と製品の版で確かめさせる | 半年前の正解で構成を決める |
容量は両方の docker で docker system df を測らせ、重なりは image 名で突き合わせる（tag や取得時期が違っても、両側にあれば容量はそれぞれにかかる） | 存在しない二重持ちを理由に構成を変える |
コンテナを消す処理に -v があるか見させ、docker volume ls -f dangling=true で残りを数えさせる | VOLUME を宣言した image の volume が溜まる |
| ホームを mount する VM を足すなら、VM に入る鍵をエージェントから読めなくさせる | 隔離 VM とは別の VM 経由で、Mac のホームに届く |
6 行のうち、筆者が最初から気にしていたのは容量の 1 行だけだった。
まとめ
Mac のコンテナ環境を 1 つにまとめるかは、まとめた後に何が残るかで決まる。カーネルを分けた隔離が要るなら、OrbStack と Lima の 2 つ。カーネルの共有を許せるなら、OrbStack の isolated machine で 1 つにまとまる見込みがある（筆者は未検証）。容量は推測せず、両方を測ってから決める。
効いた問い返しは、どれも一言だった。「なんで？」で比較と結論の向きが揃い、「二重に持ってない？」で推測が実測に変わった。外したのは 2 回。最初の「合ってる？」の答えに頷いたのと、「シンプルでは？」と前提を自分から差し出したのと。次からは、前提を言わせたら、それがどの docs のどの版に書いてあるかまで聞く。
テスト用 DB の払い出しはsandbox のエージェントに Postgres を渡す記事にまとめた。エージェントに任せる開発環境の相談はAI 開発支援で受けている。
