Dockerは知っていても、Colimaは初耳という方が多いはずなので、初学者向けに整理します。
まず結論
Colimaは、ざっくり言うと「Dockerを動かすための土台を、使うときだけ立ち上げて、終わったら完全に消せる」道具です。メモリの限られたノートPCでローカルLLMと同居させるなら、これが正解でした。
実際、こんな数字が出ました。
土台を起動したまま → AIの応答速度：21
土台を止めた状態 → AIの応答速度：30.9
（1秒あたりの生成量。単位は省略）
裏で寝ているだけの土台が、AIの速度を3割も奪っていたわけです。
発見：入っていたのはDocker Desktopではなかった
そもそもの始まりは、勘違いでした。私は自分のMacに「Docker Desktop（あの有名なクジラのアプリ）」が入っていると思っていたのですが、コマンドを叩いてみたら——入っていたのはColimaで、しかも停止中でした。
過去に自分で入れたことを、すっかり忘れていたのです。ここでも「推測せず、現物を確認する」が効きました。もし思い込みのまま進めていたら、存在しないアプリの設定画面を探し続けるところでした。
Colimaの何が良いのか
調べてみると、私の環境にはむしろColimaのほうが向いていました。理由は3つです。
① 止めればメモリが1バイトも残らない
Docker Desktopは常駐アプリなので、「使っていないのに裏で動いている」状態が起きがちです。Colimaはコマンドで起動・停止するので、止めればゼロ。
これが今回、決定的でした。私のノートPCではローカルLLMがメモリの大半を占めており、余りはごくわずか。そこに数GBの土台が常駐していたら、AIの居場所がなくなります。冒頭の速度差は、まさにそれが数字になったものでした。
② ライセンスの制約がない
Docker Desktopは、一定規模以上の企業での業務利用が有償です。Colimaはオープンソースのライセンスで、この論点自体が発生しません。
私は病院のシステムに関わっているので、将来「職場で使えないか」を相談する場面を想像すると、この違いは効いてきます。技術の話とは別に、組織で通るかどうかの障壁が1つ減るというのは、地味ですが大きな価値です。
③ 設定がコマンドとして残る
Colimaの設定は、起動コマンドの1行がそのまま設定です。GUIでポチポチした設定と違い、記録に残り、そのまま再現できます。「記録が価値になる」というこのブログの型と、きれいに一致しました。
起動する前に、現状を測った
ここが今回いちばん「型が身についたな」と思った部分です。私はすぐ起動せず、まず既存の設定を確認しました。
結果、過去の自分が作った設定が残っていて、土台に割り当てるメモリが「8GB」になっていました。今の環境では明らかに大きすぎます。何も考えず起動していたら、その瞬間にメモリが破綻し、AIが極端に遅くなって「なぜか重い」と悩むところでした。
そこで割り当てを2GBに絞って起動。やることはログの集計程度なので、これで十分すぎるほどです。
ちなみに、ディスクの割り当てが「80GB」と表示されて一瞬ぎょっとしたのですが、これは「最大80GBまで使える」という上限で、実際は使った分しか消費しません。上限と実消費は別物——これも初学者が驚きやすいポイントでした。
本題：AIの暴走スクリプトを「閉じ込める」二重ブレーキ
ここからが、この環境を作った本当の目的です。
ローカルLLMにスクリプトを書かせると、当然ながら怪しいものも出てきます。無限ループでメモリを食い尽くすようなものが混じるかもしれない。実行するのが怖い、でも実行しないと確かめられない——この板挟みが、初学者最大の足かせでした。
解決策は、ブレーキを二重にかけることでした。
- 土台そのものに、メモリの上限をかける（例：2GB）
- さらに、個々の作業場にも上限をかける（例：512MB）
こうしておくと、AIが書いたスクリプトが暴走しても、その小さな上限で頭打ちになり、Mac本体には影響しません。同じ日にローカルLLMが暴走したばかりだったので、この設計の意味が骨身に染みました。前回の記事で書いた「ブレーキは一番外側に付ける」の、もう一つの実践形です。
そして作業場は使い捨てです。オプションを一つ付けて起動すると、終了した瞬間に環境ごと消えます。作って、使って、壊す。
ただし「壊せないもの」が1つある
ここは絶対に間違えてはいけない線引きです。作業場に「Mac側のフォルダを見せる」設定をすると、そこだけは本物です。中で消せば、本当に消えます。
「コンテナだから安全」ではなく、「見せていない部分が安全」。
壊れて困るものは、見せない場所に置く。中は好きに壊す。
実際、私は検証用に作った専用フォルダだけを見せる形にしました。ホームフォルダ全体を見せてしまうと、AIが書いた削除コマンドが本物になります。ここだけは、慎重すぎるくらいでちょうどいい部分でした。
作った検証環境で、何をしたか
最初の練習として置いたのは、疑似的なシステムログでした。エラーが何種類か混ざったテキストを用意し、それをAIに集計させるのです。
ポイントは、正解を先に自分で数えておくこと。そうすればAIの答えを採点できます。「AIが出した答えが合っているか分からない」という状態を作らないための工夫で、これはこのブログでずっとやってきた「物差しを先に用意する」そのものでした。
そしてこの練習、実は本業の予行演習でもあります。病院のシステムログは外に出せません。だからクラウドのAIには相談できない。手元のAIに読ませて、隔離した環境で検証する——今日組んだ手順は、そのまま将来の相談材料になります。
ただし順番は間違えません。
技術的に可能か → ✅ 今日、自宅で実証した
組織的に許されるか → ❓ これは規程と申請の話
自宅で実績を作り、説明できる形にしてから、相談する。順番を飛ばさない、という当然のことを、ここでも守ります。
おまけ：Dockerの学習が、立体的になった
最後に、Docker学習中の方に一番伝えたいことを。
今回、土台の起動に約40秒かかり、その上で作業場を作るのは一瞬でした。この差を体感して、初めて腑に落ちたことがあります。
土台の起動＝建物を建てる（重い・数十秒）
作業場の作成＝部屋を作る（軽い・一瞬）
Docker入門で必ず出てくる「仮想マシンとコンテナの違い」の話は、まさにこれでした。教科書で読んだときは分かった気になっていましたが、自分のマシンで40秒と一瞬を体験して、やっと立体になりました。
そして「気軽に壊せる」のは部屋のほうです。建物（土台）は数ヶ月に一度しか壊しませんが、部屋は毎回壊すのが前提。失敗のコストがゼロになると、試す回数が増える——「環境を壊すのが怖くて試せない」という足かせが、今日で外れました。
おわりに
使い終わったら、コマンド一つで土台ごと停止。メモリが完全に返ってきて、AIの速度も戻ります。「AIに相談する時間帯」と「検証する時間帯」を、きれいに切り替えられるのが、この構成の一番の心地よさでした。
あとは月に一度、溜まった不要なイメージを掃除するだけ。派手さはありませんが、限られたメモリで欲張るための、静かな工夫です。同じように24GB前後のマシンでローカルLLMを動かしている方の参考になれば。
環境構築 / Colima / Docker / ローカルLLM
このブログでは、ローカルLLM・Aider・個人開発の試行錯誤をそのまま記録しています。
