【2026年版】AIツールのログがストレージを圧迫！VPSの容量不足を防ぐログ管理・定期削除術

最初に結論を書きます

VPS契約したら、AIツールを入れる前にdaemon.jsonとlogrotateを設定してください。これをやらないと数週間でディスクが死にます。自分が実際にやらかしました。

Ollamaを入れてOpen WebUIを動かして「いい感じじゃん」と思ってたら、2週間後にコンテナが全部落ちてた。原因はdf -hしたら一発でわかった。使用率98%。ログが溜まってただけ。

設定で完全に防げる問題です。それでも「突然サービスが落ちた」って経験する人が後を絶たないのは、AIツールのログがどれくらい膨らむか、事前に知らないから。知ってれば最初に設定するだけの話。

この記事は「やった方がいいかも」じゃなくて「やってください」という話です。

どのくらい溜まるのか？AIログのサイズ感

正直に言うと、最初にこの表を見たとき「DockerのJSONログがコンテナ1個で最大500MB/日？」と思って半信半疑だった。でも実際にOpen WebUIとOllamaを並べて動かしてたら、1週間で/var/libの下が7GBになってた。半信半疑だった自分が甘かった。

月単位では数十GBになるケースも珍しくありません。

はっきり書いておきます。Stable Diffusionを動かしてる人は特にやばい。出力画像が1枚2〜5MBだとして、1日100枚生成すれば200〜500MB。30日で6〜15GBが画像だけで消える。ログ込みだと月20GB超えは普通にある。

「50GBプランで余裕でしょ」と思ってた人、2ヶ月もたないかもしれない。

月換算で具体的に書くと、Dockerコンテナを5個動かして各500MB/日だとすると、それだけで月75GB。50GBプランはおろか100GBプランでも足りなくなる計算になる。設定で防げるのにプランアップグレードで対処しようとするのは完全に順番が逆です。

まず現状を把握する：df・duコマンド

対策の前に、今の自分のVPSがどういう状態か確認してください。「なんか重い」と言っても現状を数字で把握しないと対処のしようがない。

# ディスク使用量の全体確認
df -h

# 出力例
# Filesystem      Size  Used Avail Use% Mounted on
# /dev/vda1        50G   43G  3.7G  93% /   ← 危険域！

# 容量を食っているディレクトリをトップ10で表示
du -sh /* 2>/dev/null | sort -rh | head -10

# Dockerが使っているディスク容量の詳細
docker system df -v

# 特定ディレクトリの内訳
du -sh /var/log/* | sort -rh | head -20
du -sh /var/lib/docker/containers/*/  2>/dev/null | sort -rh | head -10

自分の場合、docker system df -vを最初に叩いたときに「BUILD CACHE: 4.2GB」という表示を見て固まった。何もしてないのに勝手に溜まってる。これを知らないままだと、どこが膨らんでるかすら分からない。まずここから始めてください。

「どのコマンドから叩けばいい？」と迷うなら、df -h→docker system df -vの順番で見れば8割の原因はわかります。自分はこれで原因が即特定できた。

KAGOYA CLOUD VPS →

logrotateでシステムログを自動管理

logrotateは「古いログを自動でまとめて圧縮・削除してくれる仕組み」です。設定しておけばほぼほったらかしでいい。逆に設定してないと、ログが延々と積み上がる。

「サーバー管理っぽくて難しそう」という印象があるかもしれないけど、設定ファイルに数行書くだけです。一度やれば触らなくていい。

Ollamaのログをrotateする

# /etc/logrotate.d/ollama
cat > /etc/logrotate.d/ollama << 'EOF'
/var/log/ollama/*.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    create 0644 root root
    postrotate
        systemctl reload ollama 2>/dev/null || true
    endscript
}
EOF

rotate 7は「7日分だけ残す」という意味。正直これで十分。「過去7日より前のログが必要になる状況」って何度あった？自分はゼロだった。長くても14日にしておけばいい。それ以上残してるのは「念のため」という気持ちで容量を食ってるだけ。

「念のために30日分残しておこう」という判断をするなら、30日分 × 1日最大100MB = 最大3GB をOllamaのログだけで消費する覚悟が必要になる。7日で十分です。

nginxアクセスログのrotate

cat > /etc/logrotate.d/nginx-ai << 'EOF'
/var/log/nginx/access.log
/var/log/nginx/error.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    sharedscripts
    postrotate
        nginx -s reopen 2>/dev/null || true
    endscript
}
EOF

# 動作確認（dry-run）
logrotate -d /etc/logrotate.d/ollama
# 実行
logrotate -f /etc/logrotate.d/ollama

dry-runを先にやるのは面倒に見えて大事です。設定を間違えたまま実行して、必要なログを消した、なんてことにならないように。「どうせ大丈夫」は根拠がない。30秒のdry-runを惜しむ理由はないです。

DockerのJSONログを制限する（これが最重要）

使ってみた感想としては、この設定が全対策の中で一番コスパが高い。Dockerはデフォルトでコンテナのログを無制限に蓄積します。 これを知らないまま使い続けてる人が多い。自分もそうだった。

「デフォルトで無制限」というのは、言い換えると「何もしなければ確実にディスクが死ぬ」ということです。Dockerを使ってAIツールを動かすなら、この設定は義務だと思ってください。

グローバル設定（新規コンテナ全てに適用）

cat > /etc/docker/daemon.json << 'EOF'
{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "50m",
    "max-file": "3"
  }
}
EOF

# Dockerデーモンを再起動
systemctl restart docker

これで1コンテナあたり最大150MB（50MB × 3ファイル）に抑えられる。コンテナが10個あっても1.5GB。人間が管理できる範囲に収まる。

VPS契約してAIツールを入れるなら、これを最初にやってください。 後からやると既存コンテナには反映されないので二度手間になる。「後でやろう」が一番危ない。自分がまさにこれをやって、後から全コンテナ再作成する羽目になった。

既存コンテナに適用（compose.yml）

services:
  ollama:
    image: ollama/ollama:latest
    logging:
      driver: "json-file"
      options:
        max-size: "50m"
        max-file: "3"

  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    logging:
      driver: "json-file"
      options:
        max-size: "20m"
        max-file: "5"

既存コンテナに適用したい場合は、compose.ymlにこれを追加してdocker compose up -d --force-recreateで再作成するのが一番確実。「daemon.jsonを設定したからもう大丈夫」と思ってると、既存コンテナが古い設定のまま動き続けるので注意。

ここは自分も最初はまった落とし穴なので、遠回しに言っても仕方ないので。daemon.jsonを設定してDocker再起動しただけでは、すでに動いているコンテナのログ制限は変わりません。 必ず再作成してください。

XServer VPS →

cronで定期クリーンアップを自動化

ここまでの設定で「これ以上増えない」仕組みができた。次は「すでに溜まったものを自動で掃除する」仕組みを作る。これをセットでやって初めて「ほったらかしで動く状態」になる。

逆に言うと、daemon.jsonとlogrotateだけ設定して「よし完璧」と思ってると、Dockerのビルドキャッシュやイメージの残骸が少しずつ積み上がって、数ヶ月後にまた容量不足になる。自動クリーンアップまでセットです。

crontab -e

以下を追記します：

# 毎日3時に古い画像生成ファイルを削除（30日以上前）
0 3 * * * find /opt/sd-outputs -name "*.png" -mtime +30 -delete

# 毎週日曜3時にDockerの不要リソースを削除（ボリューム除く）
0 3 * * 0 docker system prune -f 2>&1 | logger -t docker-cleanup

# 毎日4時にjournaldの古いログを削除（7日以上）
0 4 * * * journalctl --vacuum-time=7d 2>&1 | logger -t journal-cleanup

# 毎時30分にディスク使用率をチェック（90%超で通知）
30 * * * * USAGE=$(df / | awk 'NR==2{print $5}' | tr -d '%'); \
  [ "$USAGE" -gt 90 ] && \
  curl -s -X POST "https://hooks.slack.com/services/YOUR_WEBHOOK" \
  -d "{\"text\":\"⚠️ VPSディスク使用率: ${USAGE}%\"}" || true

自分の場合、Slack通知は最初「面倒だからいいや」と思って設定しなかった。そしたら気づかないまま容量が詰まった。VPSはリモートで動いてるから、「何かあったら確認しに行く」という前提だと手放しにならない。

VPSをローカルPCで代替しようとする人がいるけど、「PCを立ち上げっぱなし」という運用は精神的に気になるし、何かあったらリモートデスクトップで入らないといけないから全然手放しにならない。VPSにする意味は「ほったらかしで動く」ことのはずなので、通知設定は絶対にやっておいてください。

ディスク使用率アラートの設定

シンプルなメール通知スクリプト

cat > /usr/local/bin/disk-alert.sh << 'EOF'
#!/bin/bash
THRESHOLD=85
USAGE=$(df / | awk 'NR==2 {print $5}' | tr -d '%')

if [ "$USAGE" -gt "$THRESHOLD" ]; then
  echo "VPSディスク使用率が${USAGE}%を超えました。" \
    | mail -s "[ALERT] ディスク容量不足" your@email.com

  # Slack通知（webhookがある場合）
  curl -s -X POST "$SLACK_WEBHOOK_URL" \
    -H "Content-Type: application/json" \
    -d "{\"text\":\"[VPS] ディスク使用率: ${USAGE}% / / への対応が必要です\"}"
fi
EOF

chmod +x /usr/local/bin/disk-alert.sh

# cronに登録（毎時実行）
echo "0 * * * * /usr/local/bin/disk-alert.sh" >> /var/spool/cron/crontabs/root

閾値を85%にしてるのは理由があって、90%だと「対処しようと思ったときにもう手遅れ」になりやすいから。85%で気づけば、docker system prune -f一発で数GBは確保できる。猶予を持って気づくための設定です。

「メール通知の設定が面倒」という場合は、Slack webhookだけでもいい。Slack webhookは5分で設定できる。それすら面倒という場合でも、cronで毎時df -hの結果をログファイルに書き出すだけでも「後から確認できる」という状態が作れる。何もしないよりはるかにマシです。

SDの出力ファイルを世代管理する

Stable Diffusionを動かしてる人向けに言っておくと、出力画像の管理が一番やっかいです。消したくないものもあるし、でも溜め続けると確実にディスクが死ぬ。正直「取捨選択がめんどう」という気持ちはわかる。だからこそ自動化する。

Stable Diffusion用のGPU VPSを月数万円で借りてる人もいると思うけど、セットアップが楽ならその選択はありだと思う。ただ、月数万はまぁまぁ高い。そのコストを払ってるなら、ストレージ管理も最初からちゃんとやっておかないと、画像生成してるうちにあっという間にディスクが死ぬ。コストに見合う環境を作るためにも、この設定は必須です。

cat > /usr/local/bin/sd-cleanup.sh << 'EOF'
#!/bin/bash
OUTPUT_DIR="/opt/sd-outputs"
KEEP_DAYS=14
KEEP_COUNT=1000  # 最新1000枚は残す

# 14日より古いファイルを削除
find "$OUTPUT_DIR" -name "*.png" -mtime +$KEEP_DAYS -delete
find "$OUTPUT_DIR" -name "*.jpg" -mtime +$KEEP_DAYS -delete

# 1000枚を超えた分を古い順に削除
ls -t "$OUTPUT_DIR"/*.png 2>/dev/null | tail -n +$((KEEP_COUNT+1)) | xargs rm -f

echo "[$(date)] SD cleanup done. Current count: $(ls $OUTPUT_DIR/*.png 2>/dev/null | wc -l)"
EOF

chmod +x /usr/local/bin/sd-cleanup.sh

「14日」「1000枚」は自分の感覚で決めていい数字です。気に入った画像は別ディレクトリに移しておく習慣をつければ、自動削除でも困らない。「全部残したい」という気持ちはわかるけど、全部残したままにするとサービスが落ちる。どちらを選ぶかは明らかです。

よくある質問（FAQ）

まとめ：あなたの使い方で選ぶ対策テーブル

対策の優先順位は「どのAIツールをどう使ってるか」で変わる。自分の状況に近い行を見て、そこから始めてください。全部一気にやろうとしなくていい。

一点、誤解されたくないので書いておく。Claude Code目的でVPSを借りてる人はGPUは不要です。Claude CodeはAPI経由で動くのでGPUは関係ない。「GPU搭載プランの方が快適」という記事を見かけることがあるけど、GPU不要な用途にGPUプランを勧めるのはアフィリエイト報酬目的の記事を疑っていい。月額が跳ね上がるだけで体験は変わらないので、そういう記事に乗っからないように。

対策の優先度を整理するとこうなります：

ちなみに、「ストレージが足りないからプランをアップグレードしよう」と考える前に、まずこの記事の対策をやってほしい。ログ管理をちゃんとやれば、50GBプランでも相当長く戦える。アップグレードはその後の話。お金を増やす前に設定を直す方が先です。

KAGOYAとXServerのどちらを選ぶかという話をすると、Claude Code用途ならKAGOYA寄りの判断になる。GPU不要で時間課金が効く用途だとKAGOYAの方が安く収まることが多い。ただしXServerの月830円固定は「毎月いくらか計算したくない」という人には精神的にラクなので、これも無視できない。月76時間以上使うならXServerの固定料金の方が得になる計算になるので、自分の使い方と照らし合わせてください。

最初の設定さえ済ませれば、あとはほぼ自動で動きます。この記事の設定値が自分の環境に完全に合ってるかどうかは、使いながら確認してください。「rotate 7じゃ少ない」と思ったら14にすればいいし、「1000枚多すぎる」と思ったら500にすればいい。失敗しても月額数百円。取り返しがつく範囲でまず試してみてほしい。

KAGOYA CLOUD VPSでストレージ豊富な環境を作る →

XServer VPSで安定したAI運用環境を始める →

あわせて読みたい

• AIツール（Claude Code / Codex）向けVPS比較ランキング初心…
• 失敗しないGPUサーバー選び：VRAM 24GB以上を格安で確保できるVPSラン…
• GPU搭載VPSを「必要な時だけ」時間単位で借りて画像生成AIをお試しする方法
• あなたに合うVPSを30秒で診断する