コーディングエージェント用VPSの必要RAMは？

コーディングエージェント用 VPS には、どれくらいの RAM が必要ですか？

リポジトリで常時稼働するコーディングエージェント 1 つには、まず 4 GB の RAM と 2 vCPU を割り当てます。言語サーバーまたは Docker のビルドをセッションに追加した時点で、8 GB の RAM と 4 vCPU に増強してください。ほとんどのリポジトリでは、これは初日から必要になります。エージェントのプロセス自体は小さいため、サーバーのリソースを消費するのは、エージェントがユーザーに代わって操作するツールチェーンです。

[
  {
    "plan": "Minimum viable",
    "ram_gb": 4,
    "vcpu": 2,
    "disk_gb": 50
  },
  {
    "plan": "Comfortable",
    "ram_gb": 8,
    "vcpu": 4,
    "disk_gb": 100
  },
  {
    "plan": "Team, 4 sessions",
    "ram_gb": 16,
    "vcpu": 8,
    "disk_gb": 200
  }
]

上記の各行では、モデルが別の場所で実行され、ネットワーク経由で呼び出す API の背後にあることを前提としています。この前提がサイジング全体を左右するため、最初に確認してください。

エージェントを実行していますか、それともモデルを実行していますか？

クラウドモデルを呼び出すコーディングエージェントは、シェルを接続したネットワーククライアントです。ファイルと計画を API に送信し、応答を待ってから、ローカルでファイルを編集してコマンドを実行します。応答を待っている間は、CPU をほとんど使用しません。エージェント自体のメモリ使用量は数百 MB です。そのため、適度な性能の CPU マシンが適しています。

モデルを自分で実行する場合は、異なるハードウェア上で別の製品を運用することになります。サーバーが稼働している間、重みはメモリに保持されます。4 bit に量子化した 70 億パラメータのモデルでは、コンテキスト長に応じて増加する key/value cache を除いても、重みだけで約 5 GB が必要です。CPU のみを使用する場合、共有 vCPU では 1 秒あたり数トークンしか生成できません。1 つのエージェントタスクで数千トークンを出力することもあるため、API 経由なら 1 分未満で完了する処理に、ローカルではほぼ 1 時間かかります。この構成を求めている場合は、VRAM（GPU のビデオメモリ）を基準にリソースを見積もり、このページではなくGPU 搭載 VPS で実際に利用できるものを確認してください。

以下では、すべてクラウドモデルを使用する構成を前提とします。

実際にメモリを使用するもの

[
  {
    "label": "Agent CLI process, idle",
    "typical_mb": 250,
    "peak_mb": 600
  },
  {
    "label": "TypeScript language server",
    "typical_mb": 700,
    "peak_mb": 2000
  },
  {
    "label": "rust-analyzer, large workspace",
    "typical_mb": 1200,
    "peak_mb": 4000
  },
  {
    "label": "Headless Chrome, one tab",
    "typical_mb": 350,
    "peak_mb": 900
  },
  {
    "label": "Node test run, 4 workers",
    "typical_mb": 1600,
    "peak_mb": 3000
  },
  {
    "label": "Docker image build",
    "typical_mb": 800,
    "peak_mb": 2500
  }
]

これらは中規模プロジェクトで一般的に公開されている数値です。自分のコードに対する保証ではなく、規模の目安として扱ってください。

このグラフには 6 行があり、最も少ないのは agent です。agent は会話の状態と小さなファイルキャッシュだけを保持するため、アイドル時は 250 MB 前後です。TypeScript language server はインデックス作成中に約 2000 MB に達します。tsconfig.json から到達可能なすべてのファイルについて型グラフを構築し、次の要求にすばやく応答できるよう、そのグラフをメモリに保持するためです。大規模な workspace では、rust-analyzer も同じ理由で、workspace 内のすべての crate を対象に、通常 4000 MB を超えます。

Headless Chrome は、ブラウザーと 1 つのタブで約 350 MB を使用します。タブを 1 つ追加するたびに、別の operating system process が起動します。4 workers で Node test を実行すると、Node process が 4 つ起動するため、ピーク時は約 3000 MB です。Docker image build は、約 2500 MB がピークです。build 中にコンテナー内でプロジェクト独自の compiler が動作し、同時に daemon が layer を書き込むためです。

sudo apt update && sudo apt install -y time
/usr/bin/time -v -o /tmp/build.rusage npm run build
grep "Maximum resident set size" /tmp/build.rusage

free -h の available 列を確認し、free 列は見ないでください。Linux は空いているすべてのページを disk cache に使用するため、正常なマシンでは free が小さくなり、何も判断できません。新しい process が実際に取得できるのは available です。

動作する3つの構成

最小構成: 4 GB RAM、2 vCPU、50 GB ディスク。 エージェントセッション1つ、リポジトリ1つ、言語サーバー1つを実行し、ビルドの完了を待てる構成です。この構成でも動作しますが、大規模なテスト実行とインデックス作成中の言語サーバーが重なると、最初から out-of-memory killer によってプロセスが終了する可能性があります。swap を追加し、ビルドワーカー数に上限を設定してください。

快適な構成: 8 GB RAM、4 vCPU、100 GB ディスク。 エージェント1つに加えて、Docker、テスト用のヘッドレスブラウザーを実行でき、ビルドが一時的に負荷を増しても余裕があります。1人で開発する場合は、通常この構成を選ぶべきです。vCPU 数を2倍にすると、ビルドの待ち時間もおおむね半分になります。メモリ不足よりも、こちらの効果を実感する機会のほうが多くなります。

チーム構成: 16 GB RAM、8 vCPU、200 GB ディスク。 それぞれ専用の checkout とツールチェーンを持つセッションを4つ、同時に実行できます。ピーク時の負荷を基準にサイジングしてください。アイドル状態のエージェント4つはほとんどコストになりませんが、テストを同時に4つ実行すると、上の表のピーク時コストが4倍になります。

2026年8月時点では、最初の行から最後の行への変更で、年間契約の VPS 料金はおおむね4倍になります。最小構成は月額1桁ドル、最大構成は月額数十ドルです。料金は変動するため、計画を立てる前に現在の料金表を確認してください。通常、サーバーが最も高額な部分になることはありません。エージェントを毎日利用する場合、モデル API の料金はすぐにサーバー料金を上回ります。そのため、サーバーを小さくする前に、エージェントの利用額に上限を設定することを推奨します。ビルド自体については、VPS でコーディングエージェントを実行する手順で、アカウントの設定と、切断後もセッションを維持する方法を説明しています。

RAM より先にディスク容量が不足する理由

[
  {
    "label": "Ubuntu 24.04 base and toolchain",
    "typical_gb": 6
  },
  {
    "label": "One JS monorepo checkout",
    "typical_gb": 3
  },
  {
    "label": "node_modules across 3 branches",
    "typical_gb": 4
  },
  {
    "label": "Docker images and build cache",
    "typical_gb": 20
  },
  {
    "label": "Agent logs and journal, 90 days",
    "typical_gb": 2
  }
]

これらの行を合計すると、コードを 1 行も書く前に 50 GB のディスクがほぼ満杯になります。最大の項目は Docker で、約 20 GB を使用します。BuildKit は削除を指示するまで、すべてのビルドの中間レイヤーを保持するためです。

docker system df
docker builder prune --filter until=168h

docker system df はカテゴリごとの再利用可能な容量を表示するため、実行前後で確認します。until=168h のフィルターは 1 週間より古いビルドキャッシュを削除し、今週のキャッシュは保持します。これは、作業時間の短縮に役立つキャッシュです。docker image prune -a はさらに処理を進め、どのコンテナからも使用されていないすべてのイメージを削除します。そのため、次回のビルドでは再度 pull が発生します。

Node プロジェクトでは、より分かりにくい問題が発生します。npm install は数十万個の小さなファイルを書き込むため、df -h が数 GB の空き容量を報告していても、ファイルシステムの inode が枯渇することがあります。その結果、ディスクが半分空いているように見えても、書き込みが No space left on device で失敗します。

df -h /
df -i /

IUse% が 100 を示す場合は、現在使用していないブランチの node_modules ディレクトリを削除します。または、pnpm に切り替えます。これは各パッケージバージョンを 1 回だけ保存し、すべてのプロジェクトからハードリンクで参照します。

ログは気付きにくい原因です。常時稼働するエージェントはセッションの記録を書き込み、systemd の journal はデフォルトでディスク容量の一部を使うまで増え続けます。

sudo journalctl --disk-usage
sudo journalctl --vacuum-size=200M
du -xh --max-depth=1 / 2>/dev/null | sort -h | tail

/etc/systemd/journald.conf に SystemMaxUse=200M を設定し、sudo systemctl restart systemd-journald を実行して上限を永続化します。一度だけ vacuum を実行しても、その時点の容量が一時的に戻るだけだからです。

Swap: 何を補い、何を隠すか

Swap は追加する価値があります。メモリ使用量の小さな超過を、プロセス停止ではなく低速な処理に変えられるためです。サイズは RAM の半分を目安にし、最大でも約 4 GB にします。ビルド用サーバーでそれ以上にする理由はほとんどありません。

sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
swapon --show

swapon --show には、指定したサイズの /swapfile が表示されるはずです。/etc/fstab の行がないと、次回の再起動後に Swap が失われ、サーバーは気付かないうちに以前の動作へ戻ります。fallocate の結果が Operation not supported なら、sudo dd if=/dev/zero of=/swapfile bs=1M count=4096 でファイルを作成し、chmod から続行します。

echo 'vm.swappiness = 10' | sudo tee /etc/sysctl.d/99-swappiness.conf
sudo sysctl --system

swappiness を低くすると、カーネルはプログラムのメモリをディスクへ追い出す前に、ディスクキャッシュを回収します。これにより、言語サーバーの応答性を維持できます。

ここからが、Swap が隠す問題です。サーバーの搭載メモリを実際に超えるメモリをジョブが必要とすると、カーネルはビルドを実行する代わりに、RAM とディスクの間でページを移動し続けます。クラッシュは起きません。すべての処理が遅くなり、CPU がアイドル状態でも load average は上昇します。

vmstat 1 10

si 列と so 列に 0 ではない値が継続して表示される場合は、Swap が継続的に使用されています。この場合の対策は、並列度を下げるか RAM を増設することであり、Swap をさらに増やすことではありません。小規模なサーバーでは、sudo apt install -y zram-tools により RAM 上に圧縮 Swap を確保できます。/etc/default/zramswap で調整します。Swap ファイルより大幅に高速ですが、RAM を使って RAM を節約する仕組みです。そのため、使用されていないページには有効ですが、実際に大きな作業メモリを必要とするビルドには効果がありません。

コーディングエージェントがハングしたように見える理由

小規模なエージェント用サーバーで、最も誤診されやすい障害です。コマンドが何も返さず、エージェントは待機し、セッションが停止したように見えます。プロセスはカーネルの out-of-memory (OOM) killer によって強制終了されています。SIGKILL を受けたため、エラーを出力したり、ログを書き出したり、エージェントに何が起きたかを通知したりできませんでした。エージェントには空の結果と終了メッセージがない状態だけが返ります。

カーネルには記録が残ります。

sudo dmesg -T | grep -iE "out of memory|killed process"
sudo journalctl -k -b | grep -i oom

実際の行は次のようになります。

[Thu Aug  6 11:02:14 2026] Out of memory: Killed process 4711 (node) total-vm:4210880kB, anon-rss:3820104kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:8236kB oom_score_adj:0

anon-rss は、終了時にそのプロセスが確保していたメモリ量です。どのプロセスが選ばれたかにも注目してください。カーネルは主に使用中のメモリ量でスコアを付けるため、メモリ不足を引き起こしたビルドではなく、言語サーバーやエージェントを終了させることがよくあります。そのため、「エージェントが壊れた」という症状になります。

Docker 内では、同じイベントがより明確に確認できます。コンテナは終了コード 137 で終了します。これは 128 にシグナル 9 を加えた値です。

docker ps -a
docker inspect "$(docker ps -lq)" | grep -i oomkilled

"OOMKilled": true により、コンテナが自発的にクラッシュしたのではなく、メモリ制限に達したことを確認できます。

対策は、負荷の高いコマンドに専用の上限を設定することです。これにより、エージェントではなくビルドが終了します。

systemd-run --user --scope -p MemoryMax=4G -- npm run build

これでビルドは 4 GB で終了し、エージェントは動作を続けます。原因不明のハングが、終了コードを確認できる通常のコマンド失敗に変わります。これは systemd のユーザーセッションを必要とするため、SSH でのみ接続するサーバーでは loginctl enable-linger $USER を実行してください。MemoryHigh= はプロセスを終了させず、しきい値に達した時点で制限します。ビルドを遅くしてでも完了させたい場合は、こちらの設定が適しています。

Compose でメモリ上限を一度だけ設定する

エージェントのツールをコンテナで実行する場合は、Compose ファイルに上限を設定してください。これにより、実行するたびに適用されます。

services:
  agent:
    image: node:22-bookworm
    deploy:
      resources:
        limits:
          memory: 2g
          cpus: "1.5"

Docker Compose v2 は通常の docker compose up に対して deploy.resources.limits を適用するため、swarm mode は関係しません。古い mem_limit: 2g キーも引き続き使用できます。Compose のメモリ制限に関する完全ガイドでは、予約値とコンテナが上限に達した場合の動作について説明しています。サーバーに Docker がまだインストールされていない場合は、先に VPS に Docker をインストールする を参照してください。

1 つの落とし穴で、半日を失うことがあります。2 GB に制限したコンテナでも、ホストの /proc/meminfo とホストの CPU 数を読み取ります。どちらも名前空間で分離されないためです。CPU 数からワーカー数を決めるテストランナーは、8 vCPU のホスト上で 2 GB のコンテナ内に 8 個のワーカーを起動し、その後 137 で終了することがあります。数値は手動で設定してください。

npx jest --maxWorkers=2
export NODE_OPTIONS=--max-old-space-size=1536

--max-old-space-size の単位は MB で、V8 ヒープの上限を設定します。コンテナの制限より低く設定してください。そうすれば、Node が消失するのではなく、確認可能なエラーを出力します。

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

このメッセージは、どの上限に達したかと、どのプロセスが上限に達したかを示すため、原因の特定に役立ちます。OOM killer はこの情報を出力しません。

1 台のホストで複数のエージェントセッションを実行する

ユーザー単位ではなく、セッション単位で計画します。同じリポジトリで 2 つのセッションを実行すると、言語サーバーが 2 つ、ビルドキャッシュが 2 セット、さらに両方のエージェントが同時に負荷をかければテスト実行も 2 つ必要になります。そのため、チーム行の値は 16 GB まで増えます。

1 つの暴走したセッションでホスト全体が停止しないように、各ユーザーに厳格な上限を設定します。

id -u alice
sudo mkdir -p /etc/systemd/system/user-1001.slice.d
printf '[Slice]\nMemoryMax=6G\n' | sudo tee /etc/systemd/system/user-1001.slice.d/limit.conf
sudo systemctl daemon-reload
systemctl show user-1001.slice -p MemoryMax

1001 を、id -u が出力した UID に置き換えます。ユーザーがログインすると、systemctl show は MemoryMax=6442450944 を返すはずです。そのユーザーのセッション全体が 6 GB を超えると、カーネルはその slice 内のプロセスを終了します。他のセッションはそのまま動作します。ターミナルではなくサービスとして実行するエージェントでは、代わりに unit ファイルへ MemoryMax= を記述します。エージェントを常時稼働するサービスとしてセルフホストする場合は、この方法に従います。

FAQ

コーディングエージェントには 2 GB の RAM で十分ですか？

エージェントプロセスだけなら十分です。しかし、エージェントが実行する作業には、ほとんどの場合不足します。エージェント自体は 250 MB 前後ですが、中規模のリポジトリでは 1 つの TypeScript language server が 2000 MB に達することがあります。それだけで 2 GB のサーバーは swap を使い始めます。設定ファイルの編集や小規模なスクリプトであれば、2 GB で問題ありません。コンパイルやテストスイートの実行を行う場合は、4 GB を最低容量にしてください。

VPS でコーディングエージェントを実行するために GPU は必要ですか？

エージェントが API 経由でクラウドモデルを呼び出す場合は必要ありません。この処理はネットワークがボトルネックになるため、通常の CPU VPS が適しています。GPU は、より高い料金を支払ってもアイドル状態になります。GPU が必要なのは、モデル自体を同じサーバー上で実行する場合だけです。その場合は、RAM ではなく VRAM とモデルサイズが問題になります。

エージェント用 VPS にどの程度の swap を追加すべきですか？

RAM の半分を目安にし、最大で約 4 GB にしてください。swap を使用すると、短時間のメモリ超過から保護できます。カーネルが使用頻度の低いページをディスクへ移動できるため、プロセスを強制終了せずに済みます。ただし、使用可能なメモリが増えるわけではありません。vmstat 1 の si 列と so 列で継続的なトラフィックが確認できる場合、サーバーはスラッシング状態です。並列ワーカーを減らすか、より大きなプランに変更してください。

ビルドの途中でコーディングエージェントが停止するのはなぜですか？

ほぼ確実に、カーネルの OOM killer によってビルドが強制終了されています。OOM killer は SIGKILL を送信するため、何も出力されず、エージェントは決してデータが満たされないパイプを待ち続けます。sudo dmesg -T | grep -i "killed process" を実行し、プロセス名と anon-rss の値を確認してください。systemd-run --user --scope -p MemoryMax=4G でビルドに上限を設定し、ワーカー数を減らすか、RAM の 1 段階上のプランへ変更して対処します。