【2026年版】開発環境を汚さない！VPS上のDockerでAIツールを安全に動かすメリット
最初に結論を言う
ローカルPCにAIツールを直接インストールするのは、もうやめたほうがいい。
はっきり書いておきます。「Pythonのバージョンが競合した」「あのツール入れたら環境が壊れた」——これ、全部「ローカルに直接入れる」からです。VPS上のDockerで動かせば、この手のトラブルはほぼ消える。docker rm一発で全部なかったことにできるし、ローカルPCには何も残らない。
自分もかつてローカルにpip installしまくって、半年後に「なんでこれ動いてるか分からない」状態になった経験がある。あの絶望感は二度と味わいたくない。だからこそ、今はVPS+Dockerに完全に移行している。
この記事で言いたいことを先にまとめると：
- Claude CodeにGPUは不要。GPU VPS推しの記事は読まなくていい
- VPSなしでPC立ち上げっぱなしは「手放し感ゼロ」でしんどい
- 月76時間以下の使い方ならKAGOYA、以上ならXServerが安い
- 無料お試しはKAGOYAの14日がベスト（週末2回入る）
なぜローカルPCに直接AIツールを入れてはいけないか
環境汚染の典型パターン
pip install torch # PyTorch 2.3 インストール
pip install diffusers # → PyTorch 2.1 に引きずり下ろされる
pip install llama-cpp # → gccバージョン競合でビルドエラー
conda create -n ai_env ... # → またenv増殖、管理が煩雑に
これ、笑い話じゃなくてほぼ全員通る道です。最初は「condaで管理すればいけるやろ」と思う。でもenvironmentが5個、10個と増えていくうちに何がどのenvに入ってるか分からなくなる。自分も経験済み。
数ヶ月後に「なぜ動いているか分からない環境」が出来上がります。 これが本当につらい。何か触るたびに壊れるんじゃないかとビクビクする。condaのenvを整理しようとして、必要なものまで消して詰む——あの虚無感、伝わりますか。
Dockerコンテナが解決すること
| 問題 | ローカル直接インストール | Docker（VPS上） |
|---|---|---|
| 依存関係の競合 | 頻発 | コンテナ内に閉じ込め |
| Pythonバージョン管理 | pyenv/conda必須 | イメージで固定 |
| チーム共有 | 「自分の環境では動く」 | compose.ymlで統一 |
| 削除・リセット | 残骸が残る | docker rmで完全削除 |
| PCへの負荷 | 常駐プロセスが増加 | VPSに完全オフロード |
「自分の環境では動く」問題、チーム開発あるある。これがcompose.yml一個で解決するのはマジで快適。「動く状態をファイルとして保存できる」感覚は、一回体験したらローカル直インストールには戻れなくなる。
VPS選定：Docker運用に必要なスペック
正直に言うと、VPSを使わずにローカルPCを立ち上げっぱなしにするのは精神的にしんどい。
「あ、昨日PC落としてたわ」「バッテリーどうなってるんだろ」って気になるし、何か問題が起きたらリモートデスクトップで入らなきゃいけない。「自動化してるから放置でいいはず」なのに、全然手放しにならない。その点VPSは基本的に「あとはよろしく」で置いておける。電気代も気にしなくていい。これが地味に大きい。
| 用途 | 推奨メモリ | 推奨CPU | ストレージ |
|---|---|---|---|
| LLM API（7Bモデル） | 8〜16GB | 4コア | 50GB以上 |
| 画像生成（CPU推論） | 8GB | 4コア | 30GB以上 |
| 画像生成（GPU推論） | 16GB+ | 4コア | 50GB以上 |
| 複数AIツール同時運用 | 16〜32GB | 8コア | 100GB以上 |
| 開発・テスト環境 | 4GB | 2コア | 20GB以上 |
ここで一点、はっきり言っておきます
「Claude Code用途でGPU VPSを推してくる記事」は疑ってください。
Claude CodeはAPI経由で動くので、GPUは一切不要です。Claude本体はAnthropicのサーバーで動いている。自分のVPSのGPUは関係ない。それなのにGPU VPSを勧めてくる記事があるとしたら、アフィリエイト報酬が高いからという理由が大きい。GPU VPSは単価が高いので、紹介料も上がる。仕組みとしてはわかるけど、読む側は損する。
GPUが本当に要るのは：
- Stable Diffusionなどのローカル画像生成を速くしたい場合
- ローカルLLMの推論速度を上げたい場合（7B以上を実用的な速度で使いたいなど）
これ以外の用途でGPUを勧めてきたら、一回立ち止まって考えてほしい。Stable Diffusion用ならセットアップが楽なプランであればGPU VPSもありだとは思う。ただ月数万はまぁまぁ高い。費用対効果はちゃんと考えてから契約する。
Dockerインストールと基本設定
# Ubuntu 22.04 での Docker CE インストール
curl -fsSL https://get.docker.com | sh
usermod -aG docker $USER
systemctl enable --now docker
# Docker Composeプラグイン確認
docker compose version
# Docker Compose version v2.x.x
これだけ。正直、Dockerのインストール自体は難しくない。詰まるとしたらその後のファイアウォール設定とかポート開放あたりだけど、そこは各VPSの管理コンソールからできる。「Dockerって難しそう」と思って敬遠してる人がいたら、インストールはコマンド3行で終わると伝えたい。
AIツール別 docker-compose.yml 実例
Open WebUI + Ollama（ローカルLLM）
自分がまず試してほしいのはこれ。ローカルLLMをDockerで動かす入門として一番わかりやすい。「Dockerって何ができるの？」という段階の人は、まずこれを動かすことだけ考えればいい。
# compose.yml
services:
ollama:
image: ollama/ollama:latest
container_name: ollama
volumes:
- ollama_models:/root/.ollama
ports:
- "11434:11434"
restart: unless-stopped
open-webui:
image: ghcr.io/open-webui/open-webui:main
container_name: open-webui
depends_on:
- ollama
ports:
- "3000:8080"
environment:
- OLLAMA_BASE_URL=http://ollama:11434
volumes:
- open_webui_data:/app/backend/data
restart: unless-stopped
volumes:
ollama_models:
open_webui_data:
# 起動
docker compose up -d
# Mistralモデルをプル
docker exec ollama ollama pull mistral
restart: unless-stoppedを入れておくとVPS再起動後も自動で立ち上がる。これ忘れると「あれ、なんか繋がらない」ってなるので必ず入れること。自分も最初に1回忘れて「壊れた？」と焦った経験がある。
Stable Diffusion WebUI（CPU）
services:
sd-webui:
image: universonic/stable-diffusion-webui:latest
container_name: sd-webui
ports:
- "7860:7860"
volumes:
- sd_models:/app/stable-diffusion-webui/models
- sd_outputs:/app/stable-diffusion-webui/outputs
command: >
--listen
--port 7860
--no-half
--use-cpu all
restart: unless-stopped
volumes:
sd_models:
sd_outputs:
率直に言うと、CPU推論での画像生成は遅い。1枚数分かかる。「え、こんなに遅いの」と思うかもしれないけど、「動く」と「速い」は別の話。まずこれで動作確認して、「もっと速くしたい」と思ってからGPUプランを検討するのが正しい順番。いきなりGPU VPSを契約して「思ったより使わなかった」になるよりずっとマシ。
Dify（LLMアプリビルダー）
# Dify公式compose.yml抜粋
services:
api:
image: langgenius/dify-api:latest
environment:
- SECRET_KEY=your_secret_key
- DB_USERNAME=postgres
- DB_PASSWORD=your_db_password
depends_on:
- db
- redis
web:
image: langgenius/dify-web:latest
ports:
- "3000:3000"
db:
image: postgres:15-alpine
volumes:
- dify_db:/var/lib/postgresql/data
redis:
image: redis:7-alpine
volumes:
- dify_redis:/data
volumes:
dify_db:
dify_redis:
Difyはコンテナ数が多いので最低でもメモリ8GBは欲しい。4GBだとRedisとPostgresが競合してコンテナが落ちることがある。「なんか不安定だな」と感じてるならメモリ不足がほぼ原因。ここはケチらないほうがいい。スペックアップのコストより、原因調査に使う時間のほうが高くつく。
ボリューム管理：モデルデータを永続化する
ここ、地味に重要です。 コンテナを削除したらモデルデータも消えた——という経験を一度でもするとわかる。数GBのモデルデータが消えて、また何十分もかけてダウンロードし直すあの徒労感。必ずNamedボリュームを使うこと。バインドマウント（./data:/app/dataみたいな書き方）でも悪くはないけど、VPS上ではNamedボリュームのほうが管理しやすい。
# ボリューム一覧確認
docker volume ls
# 使用中ボリュームの詳細
docker volume inspect ollama_models
# ボリュームのディスク使用量確認
docker system df -v
# 不要ボリュームの削除（注意：データも消える）
docker volume prune
モデルデータのバックアップ
# ボリュームをtarでバックアップ
docker run --rm \
-v ollama_models:/source \
-v /backup:/dest \
alpine tar czf /dest/ollama_models_$(date +%Y%m%d).tar.gz -C /source .
# 復元
docker run --rm \
-v ollama_models:/dest \
-v /backup:/source \
alpine tar xzf /source/ollama_models_20260715.tar.gz -C /dest
7Bモデルで4GB前後ある。バックアップ先のディスク容量も確認してからやること。「バックアップ先もディスク不足でした」は笑えないのでちゃんと確認する。
コンテナのクリーンアップ：ディスクを圧迫させない
VPS使い始めてしばらくすると「あれ、ディスク残り5GB……」となりやすい。Dockerイメージが静かにディスクを食いつぶすから。自分も最初の1ヶ月で「なんかVPS重いな」と思って調べたら、使ってないイメージが20GB以上溜まってた。定期的に確認する習慣をつけたほうがいい。
# 停止中コンテナ・未使用イメージ・キャッシュを一括削除
docker system prune -a
# 使用中ボリュームを除いた全削除
docker system prune -a --volumes
# イメージサイズ確認
docker images --format "table {{.Repository}}\t{{.Tag}}\t{{.Size}}" | sort -k3 -h
# 不要なビルドキャッシュ削除
docker builder prune -a
docker system dfで定期的に確認するだけで大半の問題は防げる。月1回やるくらいでいい。「ディスク逼迫でコンテナが落ちる」は完全に防げるトラブルなのでここだけは習慣にしてほしい。
よくある質問（FAQ）
まとめ：あなたの使い方で選ぶ
ここまで読んでくれた人向けに、状況別の判断をまとめる。「自分はどれに当てはまるか」で見てほしい。
| あなたの状況 | 判断 | 理由 |
|---|---|---|
| Claude Codeをメインに使いたい | GPU不要。メモリ4〜8GBのCPU VPSで十分 | API経由なのでGPUは一切不要。月数万のGPU VPS推しは無視していい |
| Stable Diffusionで画像生成したい（速度より手軽さ優先） | まずCPU VPSで試す | GPU VPSは月数万かかる。CPU推論で動作確認してから考えればいい |
| Stable Diffusionで本格的に使いたい（速度も欲しい） | GPU VPS。ただしセットアップが楽なプランを選ぶ | 月数万かかるのは事実。用途が明確ならそれに見合う |
| 複数のAIツールをまとめて動かしたい | メモリ16GB以上のVPS | 4GBだとコンテナ同士で競合する。ここはケチらない |
| まずDockerの感触だけ掴みたい | KAGOYAの14日無料お試しで始める | 週末が2回入る。平日は仕事で触れなくても2回の週末で動作確認には十分 |
| 月額をなるべく固定したい | XServer VPS（830円〜の固定料金） | 時間課金は「今月いくらになるか」が気になる人には精神的にしんどい |
| 使う時間が月76時間未満 | KAGOYA（時間課金） | 計算すると76時間未満ならKAGOYAのほうが安い |
| 使う時間が月76時間以上 | XServer VPS（固定料金） | 830円固定は使えば使うほどコスパが上がる |
費用の目安（正直ベース）
- XServer VPS 最安プラン：月830円固定 → 1日あたり約27円。コンビニのコーヒー1杯より安い。「毎月いくらになるか計算したくない」人にはこっちが精神的にラク
- KAGOYA Cloud VPS：時間課金。 メモリ4GBで約1円/時間 → 月76時間で約780円。76時間超えるとXServerのほうが安くなる。損益分岐点は月76時間がひとつの目安
- GPU VPS（画像生成用）：月1〜数万円。 「これ使い続けるか」を冷静に考えてから契約する。「とりあえずGPU」は高くつく
VPS + Docker構成は最初の設定さえ終われば、あとは本当に楽になる。ローカルPCに何も入れなくていい。PCが壊れても環境はVPSにある。docker compose up -dで全部戻せる。この安心感はやってみないとわからない。
これが最終回答じゃないから、まずは無料お試しで動かしてみてほしい。 「思ってたより簡単だった」か「思ってたより難しかった」か、どっちにしても自分で触った情報のほうがこの記事より100倍価値がある。読んで満足するより、手を動かした1時間のほうがずっといい。