Claude CodeをVPSで動かす|対応4社は「4GB以上」。2GBで試したら268MBだった

本記事はプロモーションを含みます。 記事内の一部のリンクは広告リンクです。リンクの有無で内容を変えていません。 掲載している数値はすべて公式ドキュメントの記載か、自分のサーバーで実際に測った値です。 Claude Codeを自分のVPSで動かしたい。まず決まるのは「どのプランを買うか」です。 各社のページを調べたら、全社が「4GB以上」と書いていました。 一方、Anthropicの公式要件も4GB以上です。 では2GBでは動かないのか。2GBのVPSに手で入れて、動かしました。最大268MBでした。 結論 結果 各社の要件 4GB以上(2GB以下は非対応と明記する社もある) 2GBでの実測 最大268MB / ファイル作成もコード実行も成功 Node.js 不要(ネイティブインストーラ) ディスク +206MB インストール時間 6分46秒 アカウント 有料プラン必須(無料のClaude.aiでは使えない) ただし、「4GBは要らない」とは書きません。 理由は最後に書きます。 対応している4社と、その必要メモリ Claude Codeのテンプレート/アプリイメージを公式に出しているのは、確認できた範囲でこの4社です。 提供元 形式 公表している必要メモリ XServer VPS アプリイメージ 4GB以上。2GB以下のプランでは利用不可 シンVPS アプリイメージ 4GB以上。2GB以下のプランでは利用不可 ConoHa VPS スタートアップスクリプト 最小3GB、推奨4GB以上 KAGOYA CLOUD VPS テンプレート 記載を確認できず (表のXServer VPSとConoHa VPSは広告リンクです。他社は提携していないため通常のリンクです。リンクの有無と、この表に書いた内容は無関係です。) XServer VPSとシンVPSは、2GB以下のプランでは選択肢に出てきません。 「安いプランを買ってから気づく」ことになります。 Anthropicの公式ドキュメントも同じです。 Hardware: 4 GB+ RAM, x64 or ARM64 processor 4社と公式で、数字が一致しています。 ConoHaのスクリプトが入れるもの ConoHaのドキュメントには、中身まで書いてあります。 ソフト バージョン Claude Code 最新 Node.js 22 ripgrep 13.0.0 UFW 最新 Fail2ban 最新 対応OSは Ubuntu 24.04 LTS のみ。 ...

2026年9月8日 · 3 分

AI用途のVPSは何GB必要か|n8nとDifyを実測して積み上げた

本記事はプロモーションを含みます。 記事内の一部のリンクは広告リンクです。リンクの有無で内容を変えていません。 掲載している数値はすべて自分のサーバーで実際に測った値か、公式ドキュメントの記載です。 「AI用途のVPSは4GB以上がおすすめです」。よく見る書き方です。 その4GBの内訳がどこにも書いてありません。 OSがいくら使うのか、ツールがいくら足されるのか、どこに余裕を見ているのか。根拠が出てこないので、自分の用途に当てはめようがない。 このサイトでは、ここまで4本の記事で全部自分で測ってきました。 その数字を積み上げて、必要なスペックを出します。 先に結論 やりたいこと メモリ ディスク 根拠 静的サイト+小さな業務アプリ 1〜2GB 20GB〜 実測(アプリ3本で166MB) + n8n で自動化 2GB 50GB〜 実測(+402MB、空き1.1GB残) + Dify(起動して置くだけ) 4GB 100GB〜 実測(Dify単体で2,076MB) Dify を実際に使う 8GB 100GB〜 推定・未検証 + ローカルLLM(0.5Bクラス) 2GB 20GB〜 実測(本体2.1GB+モデル) ローカルLLM(1B以上) 4GB〜 50GB〜 推定・未検証 「実測」と書いた行は測った数字です。「未検証」の行は測っていません。どこまでが実測でどこからが推測か、はっきり分けて書きます。 土台:OSと常駐デーモンで何MB持っていかれるか まずアプリを何も載せない状態のコストです。ここを知らないと積み上げができません。 このサーバー(さくらのVPS 2Gプラン / Ubuntu 24.04)で、再起動直後・Dockerとnginxと自作アプリ1本が動いている状態が 398MB でした。 内訳のうち、多くの人が見落とすものが2つあります。 1. VPSでは働きようがないデーモンが50〜100MB 最初の記事で測った内訳です。 プロセス RSS 本来の用途 fwupd 44.0MB 物理デバイスのファームウェア更新 multipathd 26.7MB ストレージへの複数I/Oパスの管理 udisksd 13.4MB ディスク・リムーバブルメディアの管理 ModemManager 12.8MB モバイル通信モデムの管理 VPSに物理ファームウェアはありません。モバイル通信のモデムも刺さっていません。常駐3つで約53MB、fwupd が起動していると約97MB。 ...

2026年9月7日 · 2 分

43時間、1分ごとにVPSを測り続けた|メモリを一番食っていたのは自分のアプリではなかった

前回の記事で、VPSのメモリを1回だけ測りました。ただしあれはアイドルに近い状態の1サンプルです。ピークは写っていません。 そこで、1分ごとに記録するスクリプトを仕掛けて放置しました。43時間、2,590サンプル、欠測ゼロ。 結果、予想は外れました。メモリのピークを作っていたのは、自分のアプリではありませんでした。 上がメモリ、下がCPUです。山が重なっていません。 これが今回いちばん面白かったところです。 測定条件 サーバー:さくらのVPS 2Gプラン / Ubuntu 24.04 LTS 期間:2026-09-04 01:10 〜 09-05 20:19(43.1時間) 間隔:1分(cron) サンプル数:2,590(120秒を超える欠測ゼロ) 載せているもの:定期的にデータを取得して予測を回すバッチ処理と、静的サイト1本 使ったスクリプト 追加パッケージは不要です。free / vmstat / ps / awk だけで動きます。 #!/usr/bin/env bash set -u OUT="${1:-$HOME/vps-metrics.csv}" if [ ! -f "$OUT" ]; then echo "timestamp,mem_total_mb,mem_used_mb,mem_available_mb,swap_used_mb,load1,load5,cpu_idle_pct,p1_name,p1_rss_mb,p2_name,p2_rss_mb,p3_name,p3_rss_mb" > "$OUT" fi ts=$(date '+%Y-%m-%d %H:%M:%S') mem=$(free -m | awk '/^Mem:/{print $2","$3","$7}') swp=$(free -m | awk '/^Swap:/{print $3}') ld=$(awk '{print $1","$2}' /proc/loadavg) idle=$(vmstat 1 2 | awk 'NR==2{for(i=1;i<=NF;i++) if($i=="id") c=i} END{print (c?$c:"")}') top=$(ps -eo comm=,rss= --sort=-rss | head -3 | tr -d ',' \ | awk '{printf "%s,%.1f,", $1, $2/1024}' | sed 's/,$//') echo "$ts,$mem,$swp,$ld,$idle,$top" >> "$OUT" cronに1行足すだけです。 ...

2026年9月5日 · 2 分

さくらのVPS 2GBで自作システムを3本動かしている|実測したら、要らないプロセスがアプリより食っていた

さくらのVPS 2Gプランで、自作の業務システムを3本動かしています。9日間連続稼働、ロードアベレージ0.20、メモリは7割が空いたままです。 測ってみて、想定外だったことがあります。アプリ3本が使っているのは約166MB。一方で、このサーバーでは働きようがないOSのデーモンが、合計50〜100MBを占めていました。 自分のアプリより、使う予定のない仕組みのほうが目立つ。プラン変更を考える前に、見るべき場所がありました。 測定条件 数字を出す記事なので、どういう状態で測ったかを先に書きます。 サーバー:さくらのVPS 2Gプラン / Ubuntu 24.04 LTS 測定時刻:平日15:57、業務時間内だがアクセスはほぼない状態 稼働日数:9日15時間(無停止) サンプル数:1回(vmstat のみ5秒間) したがって以下の数字はアイドルに近い状態のものです。ピーク時の値ではありません。負荷時の測定は別途行い、追記します。 動かしている3本 すべて自作の業務システムです。フロントには Caddy を置いています。 システム 構成 常駐メモリ(RSS) 反応計測システム FastAPI 0.141.1 / uvicorn 0.52.4 / SQLite 約66MB 基幹システム Python + gunicorn(-w 1 --threads 8 -t 120) 約65MB 仮想待合室 Go(静的リンクの単一バイナリ)/ 設定はJSON 約35MB 3本合計 約166MB Caddy リバースプロキシ / HTTPS 約23MB 3本とも 127.0.0.1 のポートで待ち受けていて、外部に直接は晒していません。Caddyが受けて振り分けています。 基幹システムは自社の業務用なので、フレームワークやデータ構造の詳細は伏せます。この記事で必要なのはメモリの数字だけなので、そこは支障ありません。 3本で166MBに収まっている理由 DBサーバーを1台も動かしていないからです。 systemctl list-units --type=service --state=running \ | grep -iE "postgres|mysql|maria|redis|mongo" # → 何も返らない PostgreSQLもMySQLもRedisも入っていません。反応計測システムはSQLiteのファイル1つ(data/dareyomi.db)で動いています。 ...

2026年9月3日 · 2 分