私は 1コア / RAM 約768MB（いわゆる0.75GBクラス）の低スペックサーバーでも Claude Code を動かしています。ところが先日、作業中にサーバーが極端に重くなり、操作不能になって強制リセットする羽目になりました。
原因を調べたら、犯人はメモリ不足による「スワップ・スラッシング」。しかも、いちばんメモリを食っていたのは Claude Code 本体（約300MB）でした。
この記事では、「重い・固まる」の原因の見極め方と、実際に効いた対策（ビフォー：スワップ約1.0GB → アフター：約0.48GB）を、実体験ベースで紹介します。安いVPSでClaude Codeを試している人に役立つはずです。
結論：低スペックで重くなる仕組みと対策の全体像
まず結論から。
- Claude Code 本体だけで約300MBのRAMを使う。768MBの環境では、これだけで約4割。
- 残りのRAMを他のサービス（DB・エディタ・各種デーモン）が奪い合い、あふれた分がスワップ（ディスク）に追い出される。
- 特にデータベースがスワップに落ちると、アクセスのたびに遅いディスクから読み戻して全体が固まる（＝スワップ・スラッシング）。これが「重い」の正体。
対策は4ステップです。
- 原因の見極め（本当にメモリか？何が食っているか）
- 不要なプロセス・サービスを止める
- 残すサービスのメモリを削る・守る（DBチューニング＋保護）
- 重いツールを軽いものに置き換える
順に、実際にやったことを書きます。
まず原因を見極める（ここがいちばん大事）
「重い」と感じても、原因がCPUなのかメモリなのかディスクなのかを切り分けないと対策がズレます。私が使ったコマンドはこれだけです。
① まず全体を見る
free -h
私の環境では、リセット直後にもかかわらずスワップが既に約1.0GB使われていました。これだけで「メモリが恒常的に足りていない」と分かります。
② 何がスワップに追い出されているかを見る
ここが核心です。プロセスごとに「物理RAM（VmRSS）」と「スワップ退避（VmSwap）」を見ると、犯人が分かります。
# プロセスIDを調べて
pgrep -x mariadbd
# その物理常駐量とスワップ退避量を見る
grep -E 'VmRSS|VmSwap' /proc/<PID>/status
私の場合、データベースが「物理RAMにわずか15MB、スワップに約100MB」という状態でした。つまりDBの大半がディスクに追い出されていて、ページを表示するたびにそれを読み戻していた——これが固まりの原因でした。
ポイント：
free -hで「スワップが多い」と分かったら、/proc/<PID>/statusの VmSwap が大きいプロセスを探す。これで「何が追い出されているか」が一発で分かります。
③ メモリ消費の上位を見る
ps aux --sort=-%mem | head
これで上位を見たら、トップが Claude Code 本体（約300MB）、次いでブラウザ版エディタ（約290MB）でした。開発ツール2つでRAMの大半を占め、DBを押し出していたわけです。
実際に効いた対策
原因が「メモリの奪い合い → DBがスワップ送り」と分かったので、RAMの空きを増やし、DBを守る方向で対処しました。
対策1：不要なサービスを止める
開発用・ステージング用など、常時起動している必要のないサービスを停止しました。
sudo systemctl disable --now <不要なサービス名>
これだけで百数十MBが空きます。「とりあえず起動しっぱなし」のものは、低スペック環境では見直す価値大です。
対策2：データベースのメモリを削る＋守る
DBは設定次第でフットプリントを大きく減らせます。私はMariaDB（MySQL系）で、メモリ使用の主因であるバッファプールを縮小しました。
# /etc/my.cnf.d/zz-lowmem.cnf など
[mysqld]
innodb_buffer_pool_size = 64M # 既定128Mから半減
max_connections = 50 # 過剰な上限を下げる
さらに重要なのが、「DBのメモリをカーネルの回収対象から守る」設定です。systemd の MemoryLow を使うと、メモリが逼迫してもそのサービスのRAMが優先的に保護され、スワップに落ちにくくなります。
sudo systemctl set-property mariadb MemoryLow=128M
これで、Claude Code が重くなってもDBは物理RAMに残り続けるようになり、「閲覧のたびに固まる」が解消しました。
対策3：スワップの使いすぎを抑える（swappiness）
カーネルが「どれくらい積極的にスワップを使うか」を下げて、アクティブなデータをRAMに留めます。
echo 'vm.swappiness=10' | sudo tee /etc/sysctl.d/99-lowmem.conf
sudo sysctl -p /etc/sysctl.d/99-lowmem.conf
既定の30から10へ。低スペックでスワップがディスクの場合、効果を体感しやすい設定です。
対策4：重いツールを軽いものに置き換える
私はブラウザからサーバーを触るのに重量級のWebエディタ（約290MB）を常駐させていました。これを、ブラウザでターミナルだけ出す軽量ツールに置き換えたところ、約290MB → 約8MBまで激減しました。Claude Code はターミナルで動くので、これで十分です。
※ この「ブラウザの軽量ターミナル化（ttyd）」は、HTTPS＋認証＋永続化まで含めて別記事【Claude Codeをブラウザから使う：軽量Webターミナル「ttyd」構築【保存版】】にまとめました。
対策5：ログを永続化しておく（次回のため）
低スペック環境の初期設定では、再起動でシステムログが消える（揮発）ことがあります。これだとメモリ不足で強制終了（OOM）が起きても証拠が残りません。次回の原因究明のために永続化しておきます。
sudo mkdir -p /var/log/journal
sudo systemctl restart systemd-journald
ビフォー・アフター（実測の概数）
| 指標 | 対応前 | 対応後 |
|---|---|---|
| スワップ使用量 | 約1.0GB | 約0.48GB（ほぼ半減） |
| 空きメモリ | 約200MB | 約260MB |
| データベース | 大半がスワップ送り（固まる） | RAM常駐・保護（固まらない） |
| 開発ツールの常駐 | 重いエディタ約290MB | 軽量ターミナル約8MB |
体感でも、ブラウザ閲覧時の「一瞬固まる」が解消しました。根本原因だったDBのスワップ・スラッシングが止まったのが大きいです。
それでも足りないなら：素直にRAMを増やす
ここまでやって分かったのは、768MBという容量に対しては、これがほぼ最適化の限界ということです。なにせ Claude Code 本体だけで約300MBを使うので、これを動かしながら他も快適に、となると物理的に厳しい。
- 重い作業が重なったら「使っていないものを一時的に閉じる」で当面はしのげます。
- ただ、本気でClaude Codeを使うなら、RAM 2GB以上のプランにしておくと、こうしたチューニングに悩まされず快適です。
「どのVPS/プランがClaude Code運用に向くか」は、コストと合わせて別記事で比較する予定です（料金の実測はこちらの記事も参考に）。
【関連】各プランの上限・おすすめVPS比較：[ Claude Code/AI運用におすすめのVPS比較（公開予定）]
まとめ
- 低スペックでClaude Codeが重い時、まず疑うべきはメモリ枯渇によるスワップ・スラッシング。
- 診断は
free -h→（スワップ多）→/proc/<PID>/statusの VmSwap で「何が追い出されているか」を特定。 - 効いた対策：不要サービス停止／DB縮小＋
MemoryLowで保護／swappinessを下げる／重いツールを軽量化。 - 結果、スワップがほぼ半減し、固まりが解消。
- とはいえ Claude Code 本体が約300MB食うので、根本的にはRAM 2GB以上が快適。
低スペックでも、原因を正しく見極めれば、かなりのところまで戦えます。
あわせて読みたい：
・Claude Code 1ヶ月のトークンコストを実測｜Max 5xは元が取れるのか？（コストの実測）
・Remote Control を使ってみた感想（スマホ・タブから操作）
・使用量上限・料金が変わった（2026年6月15日〜）（最新の料金事情）
・“メモリ4GB必須”は本当？768MBで動かして検証（動くのか・スペック選び）
コメント