VPSスペックの選び方｜メモリは何GB必要？用途別の目安と実測法

【PR】この記事にはアフィリエイトリンク（ConoHa VPS・XServer VPS）が含まれます。

VPSの申し込み画面まで来て、最後に手が止まるのがプラン選びです。512MB・1GB・2GB・4GB……と並んでいるけれど、自分の用途にどれが要るのかは誰も教えてくれません。検索すると「とりあえず4GB」「最低でも2GB」といった相場観だけが出てきて、なぜその数字なのかの根拠がありません。

先に結論だけ書くと、Bot・常駐スクリプトなら512MB〜1GB、WordPress 1サイトなら1〜2GB（1GBならswap必須）、複数サイトやメールサーバーなら2〜4GB、Dockerやビルドを回す開発環境なら4GB以上が出発点です。

この記事では、メモリ・vCPU・SSDのそれぞれについて 「何がどれだけ使うから、この容量が要る」という積み上げで目安を出します。そのうえで、いま動いているサーバーが実際にどれだけ使っているかを測るコマンドと、プランを上げるべきタイミングの判断基準まで書きます。

筆者（Michi）は ConoHa VPS を3年ほど実運用しており、数値は基本的にその環境で ps aux や free -h を見た目安です。設定・バージョン・載せるアプリで大きく変わるので、最後は必ず自分の環境で測ってください。

なお、この記事が担当するのはスペックの決め方だけです。各社のプランの刻み・料金は扱いません（改定が早く、横並び比較は別記事の担当だからです）。「どの会社でいくらで契約するか」は個人向けVPS比較2026（ConoHa・さくら・XServer VPS・KAGOYA）、「OSを何にするか」はVPSのOSはどれを選ぶ？に役割を分けています。

⚠️ スペックの話に入る前に1つだけ。WordPressを1つ動かしたいだけで、OSのアップデートやセキュリティ設定を自分でやる気がないなら、多くの場合は共用レンタルサーバーのほうが安く、OSやミドルウェアの管理を事業者に任せられる分だけ運用上のリスクも小さくなります。VPSは「サーバー管理を自分でやる代わりに自由が手に入る」サービスなので、管理をしないなら値段以外のメリットがほぼ残りません。この判定を先にやっておかないと、スペック表を眺めている時間が丸ごと無駄になります。

あわせて読みたい

VPSとレンタルサーバーの違いを図解で比較｜どっちを選ぶ？【2026年版】 VPSと共用レンタルサーバーの違いを、料金・root権限・保守の時間で図解比較。ConoHa VPSを実運用するエンジニアが「どっちを選ぶべきか」を判断フローで整理します。保守の時間＝機会費用という視点で選び方を解説（2026年版）。

「自分で構築したい」「共用では入らないミドルウェアを動かしたい」——ここが確定している人だけ、以下を読み進めてください。

VPSスペックの選び方は「メモリ」から決める

メモリ・CPU・SSDのうち、最初に決めるのはメモリです。理由は単純で、足りなかったときの壊れ方が違うからです。

メモリが足りない

Linuxカーネルの OOM Killer が、メモリを多く使っているプロセスを強制終了します。MySQLやPHP-FPMが落ち、サイトが500エラーになります。しかも「重いな」という前兆なしに、いきなり止まります。

CPUが足りない

処理が遅くなります。ページの表示に3秒かかる、ビルドに10分かかる——つらいですが、止まりはしません。

SSDが足りない

書き込みができなくなり、ログもDBも書けなくなります。こちらも止まりますが、df -h で事前に気づける分だけ予防しやすい種類の障害です。

つまり メモリだけが「予告なくサービスを落とす」リソースです。だからメモリから決めます。

公式のシステム要件はどうなっているか

判断の下限として、OS側の公式要件を押さえておきます。Ubuntu Server のドキュメントに記載されているシステム要件は、確認した時点で次のとおりでした（2026年8月19日確認）。なお公式ページ自身が「以下の数値は Ubuntu 24.04 LTS（amd64） についてのもので、他のリリースやアーキテクチャでは多少異なることがある」と注記しているので、24.04 基準の数値として読んでください。

VPSで提供されるOSイメージはクラウドイメージ相当なので、見るべきは下の行です。メモリ1GB・ストレージ4GBが最小、推奨は3GB以上・25GB以上。

ここで気づくと思いますが、各社が用意している512MBクラスのプランは、この最小要件を下回っています。実際には動きますが、「公式が想定している最小を割っている構成」だという自覚は持っておくべきです（後述のswapが必須になる理由もここです）。

なお、WordPress側の要件（wordpress.org）にはサーバー全体として必要なメモリ量の記載はありません。推奨されているのは PHP 8.3以上、MariaDB 10.11以上または MySQL 8.0以上、そして全インストールでHTTPS必須、という内容です（WordPress自身がPHPプロセスに割り当てるメモリの上限は WP_MEMORY_LIMIT という別の設定で、既定は40M・マルチサイトは64Mです）。つまり「このVPSに何GB積めばいいか」は公式には定義されておらず、自分の構成から積み上げるしかないということになります。

（そもそもなぜUbuntuを勧めるのかは、Ubuntu VPSを初心者に勧める理由に書いています）

メモリの目安は「常駐プロセスの積み上げ」で決まる

では積み上げます。Nginx＋PHP-FPM＋MariaDB という、WordPressでいちばん一般的な構成の場合、常駐しているプロセスのメモリ使用量（RSS）の目安は次のくらいです。

⚠️ この数値は筆者の環境（ConoHa VPS・Ubuntu・Nginx＋PHP-FPM＋MariaDB）で ps aux --sort=-%mem を見たときの目安です。バージョン・設定・プラグイン数で変わるので、そのまま自分の環境に当てはめないでください。測り方は後述します。

もう1点、RSS（表に載せた実メモリ使用量）を単純に足し算すると、実際より多めに出ます。子プロセスは親とのコピーオンライトや opcache の共有領域を持っているため、共有分を二重に数えてしまうからです。安全側に外れる（多めに見積もる）ので目安としては使えますが、正確に見たいときは PSS（/proc/<pid>/smaps_rollup の Pss、または smem -tk）を使ってください。

1GBプランでWordPressを動かすと、どうなるか

上の表を1GBプランに当てはめてみます。PHP-FPMの子プロセスを3つ動かす想定です。

合計はおよそ 660MB。一方、1GBプランで free -h を叩くと total は 0.9Gi 前後と表示されます（カーネルやファームウェアが確保する分があるので、1.0Giぴったりにはなりません）。

つまり 常時の空きは300MB弱。ここが分かれ目です。平常時はこれで十分回りますが、次のような一瞬のピークで足りなくなります。

• WordPressのプラグインを一括更新する（PHPのプロセスが一時的に膨らむ）
• composer install や npm install を実行する
• バックアッププラグインでサイト全体をZIP圧縮する
• アクセスが集中してPHP-FPMの子プロセスが増える

この「一瞬」でOOM Killerが発動します。だから1GB以下のプランでは、後述のswapが実質的に必須になります。

逆に、静的サイトならメモリはほとんど要らない

同じ「Webサイトを公開する」でも、PHPとDBを使わない静的サイトなら話はまったく変わります。筆者は駆け出しのころ、1コア・メモリ512MBの最小構成のVPS（当時は ConoHa ではなく別会社のVPSです）にNginxを載せて、キャッシュを詰めた状態で1日13.9万アクセスを捌いたことがあります（この話はVPSのOSはどれを選ぶ？に詳しく書いています）。

メモリを食うのはWebサーバーではなく、PHPとデータベースです。ここを理解しておくと、「静的サイトジェネレータで書き出したサイトを置くだけ」なら512MBで十分、という判断が自分でできるようになります。

【用途別】VPSのメモリ目安・vCPUコア数・SSD容量

積み上げの考え方が分かったところで、代表的な4用途に落とします。すべて「まずここから始める」ための目安であって、上限ではありません。

なお、以下の表の SSDは「使う量（必要量）」 です。実際に選べるディスク容量は会社とプランで刻みが違うので、そこはVPS比較2026で確認してください。

WordPress を1〜数サイト動かす

1サイトなら 1GB＋swap 2GB が現実的な入口です。実際、前述の積み上げで660MB。動きます。ただし快適かと言われると微妙で、記事数が増えてDBが育つとMariaDBの使用量が上がっていきます。「動く」と「余裕がある」は別なので、収益サイトなら最初から2GBを選ぶのは合理的な判断です。

複数サイトを1台に載せる場合、増えるのは主にPHP-FPMとMariaDBです。サイトごとにPHP-FPMのプールを分けるなら、その分だけ子プロセスが増えます。ざっくり「1サイト増えるごとに300〜500MB」を見ておくと大きく外しません。

⚠️ ハマりどころ：PHP-FPMの pm.max_children は子プロセス数のハード上限で、pm = dynamic でも ondemand でもこの値を超えて子は増えません（PHP公式マニュアルでも必須項目とされています）。危ないのは「増えすぎる」ことではなく、max_children × 子プロセス1つあたりのメモリが物理メモリを超える値に設定されている状態です。この場合、アクセスが増えたときにOOMまで届きます。1GBプランなら pm = ondemand にして pm.max_children を5前後に絞るのが無難です（逆に絞りすぎると、メモリではなく503側に倒れます）。「メモリを増やす」より先に、まずここを見てください。

# いまの設定を確認（プール設定ファイルの場所はPHPのバージョンで変わる）
grep -E "^pm|max_children" /etc/php/*/fpm/pool.d/www.conf

# 変更したら反映（バージョン部分は自分の環境に合わせる）
sudo systemctl reload php8.3-fpm

# 実際の子プロセス数と1つあたりのRSSを見る＝これが本当の反映確認
ps -o rss=,cmd= -C php-fpm8.3

開発・検証環境として使う

ここは素直に4GB以上を推奨します。理由は2つあります。

1つ目は Dockerイメージがディスクを食うこと。イメージを何個かpullして、ビルドキャッシュが溜まると、あっという間に数十GBになります。docker system prune を忘れる前提で容量を積んでおくべきです。

2つ目は ビルドがメモリとCPUを両方使うこと。特にフロントエンドのビルド（Vite・webpack・vue-tsc の型チェックなど）はメモリを一気に持っていきます。当サイトの /tools/ は Quasar（Vite）で作っていますが、型チェック込みのビルドはローカルPCでも数GB使います。1〜2GBのVPS上で同じことをやると、まずビルドがKilledで落ちます。

Bot・常駐スクリプトを動かす

VPSでいちばん安く上がるのがこの用途です。定期実行のスクレイパー、SNS bot、cronで回すバッチ、Webhookを受けるだけの小さなAPI——これらは常駐しても数十〜150MB程度なので、512MBプランでも十分収まります。

ただし条件が3つ。swapを確保すること、ログを垂れ流さないこと、そして その最小プランが上位へ変更できるかを契約前に確認することです。会社によっては最小プランをスケールアップの対象外にしており、その場合「試してから上げる」ができません（詳しくは後述）。なお小さいプランで一番多い事故は、実はメモリではなく「ログでディスクが埋まる」ほうだったりします。

メールサーバーを立てる

メールは「立てるだけ」なら軽いのですが、スパムフィルタを入れた瞬間にメモリを使い始めます。筆者が Rspamd を Postfix と連携させたときは、Rspamd関連のプロセスだけで数百MBを使っていました（構築手順はRspamd＋Postfixでスパム対策を組む手順にあります）。

メールサーバーはメモリよりもディスクの読みが難しい用途でもあります。メールボックスの容量は使う人数と添付ファイル次第で青天井なので、「今の必要量×3年分」くらいで見積もっておくと安心です。

vCPUのコア数はどう考える？（実は悩まなくていい）

ここが本記事でいちばん言いたいことかもしれません。主要なVPSは、メモリを決めるとvCPUのコア数もセットで決まります。コア数だけを選ぶことは基本的にできません。

2026年8月19日に主要各社の公式サイトを確認したところ、4GBクラスはどこも4コアで横並びでした。つまり「コア数で会社を選ぶ」という発想自体が、少なくともこのクラスでは成立しません。メモリを決めた時点でCPUは決まると考えて大丈夫です。

ただし、メモリの刻み方とコア数の割り当ては会社ごとに違います（たとえば2GBクラスは3コアの会社もあれば2コアの会社もあります）。また、会社によってはCPUを個別に選べるプランを用意している場合もあります。どの会社にどの刻みのプランがあるかは改定も多いので、本記事では扱わずに比較記事へ送ります。

差が出るのはむしろディスクのほうです。同じメモリでもSSD容量は会社によって大きく違い、しかも「メモリを増やしてもディスクは増えない」設計の会社と、「メモリに比例してディスクも増える」設計の会社があります。ここは後の章で詳しく扱います。

CPUが効いてくるのはこういう作業

とはいえ、CPUを気にすべき場面もあります。

• ビルド・コンパイル（npm run build、composer、型チェック）：コア数がそのまま時間に効く
• 画像・動画の変換（ImageMagick、ffmpeg）：1コアだと変換中にサイトが重くなる
• 暗号処理（SSL/TLSの初回ハンドシェイクが大量に発生する場合）

逆に、PHPでページを1枚返す程度の処理はCPUをほとんど使いません。「サイトが遅い＝CPU不足」と決めつけて上位プランに行く前に、後述の uptime でロードアベレージを見てください。だいたいの場合、遅い原因はCPUではなくDBのクエリかキャッシュ設定です。

プランの刻み（どのメモリ帯に何コア・何GBのSSDが付くか）と料金・課金方式の横並び比較は、購買ハブ記事にまとめています。この記事で「大きさ」を決めたら、次は「どこで借りるか」です。

あわせて読みたい

VPS比較2026｜個人向けおすすめ4社をコスパと使い勝手で選ぶ VPS比較2026｜ConoHa・さくら・XServer VPS・KAGOYAを更新時の月額で横並び。4GBクラスは1,617〜3,227円、試すコストは数十円から。キャンペーン価格の注意点と目的別の選び方を公式情報ベースで解説します。

SSD容量も積み上げで見積もる（OS＋アプリ＋ログ＋バックアップ）

メモリと違って、SSDは忘れたころに埋まります。しかも埋まると、ログもDBも書けなくなってサイトが止まります。こちらも積み上げで見ておきましょう。

WordPress 1サイトを運用する場合の内訳の目安です。

合計すると、WordPress 1サイトなら10GB前後。バックアップを外に置くなら、最小クラスのプラン（SSD 30GB前後）でも十分に余裕があります。ただし右側の棒を見てください。同じサーバーにバックアップを世代で置くと、一気に2〜3倍になります。30GBのディスクでバックアップ3世代を持とうとすると、そこで詰まります。

対策は2つです。バックアップは外（オブジェクトストレージや手元のPC）に逃がすか、最初からSSDの大きいプランを選ぶか。前者のほうが安全ですし安上がりですが、手間はかかります。

ディスク重視ならプランの選び方が変わる

ここで効いてくるのが、前の章で触れた会社ごとの設計の違いです。ConoHa VPS は本体のSSDが100GB固定（最小プランのみ30GB）で、メモリの上位プランに行ってもディスクは増えません。一方 XServer VPS はメモリに比例してNVMe SSDが増えていく設計です。

つまり、「メモリは4GBで足りるけどディスクを大量に使う」という用途では、同じ4GBでも選ぶ会社が変わります。動画やメディアファイルを扱う、ログを長期保存する、Dockerイメージを大量に持つ——この場合はディスク側から逆算してプランを決めてください。

なお ConoHa VPS には追加ストレージ（本体とは別に、時間課金でアタッチできるSSD）が用意されているので、100GBが絶対の上限というわけではありません。ただし追加分は別料金なので、「本体100GB＋追加ストレージ」と「最初からディスクが大きいプラン」を総額で比べるのが正しい判断になります。

【PR】以下は XServer VPS の広告リンクです。プランの受付状況・料金は必ず公式サイトでご確認ください。

⚠️ XServer VPS は公式のお知らせで、2026年7月14日17:00をもって2GBプランの新規受付を停止したこと、および4GB以上のメモリ無償増量の新規提供を終了したことを告知しています（2026年8月19日確認）。受付状況や増量の扱いは変わるので、申し込み前に必ず公式ページで現在の状態を確認してください。

「SSD容量の大きさ」を最優先するなら、当サイトが提携していない会社も含めた4社の実数値を個人向けVPS比較2026（ConoHa・さくら・XServer VPS・KAGOYA）で横並びにしています（提携していない会社にはアフィリエイトリンクを掲載していません）。

2GB未満のプランは、swapを必ず確保する

ここは実体験からの警告です。小さいプランを選ぶなら、swapの確保は「やったほうがいい」ではなく「やらないと落ちる」と考えてください。

筆者は1GBプランのサーバーで、WordPressのプラグインをまとめて更新している最中にサイトが500エラーになったことがあります。ログを見るとPHP-FPMのプロセスがカーネルに強制終了されていました。平常時のメモリ使用率は60%程度だったので、監視のグラフを見ていても予兆はほぼ分かりません。ピークが一瞬なので、平均値には出ないのです。

swapが無いと何が起きるのか

Linuxはメモリが枯渇すると、OOM Killer が「いま一番メモリを使っているプロセス」を選んで殺します。WordPress構成なら、たいていの場合その候補は MariaDB か PHP-FPM です。つまりサイトの心臓部が落ちます。

swapがあると、あふれた分がディスクに退避されるので、遅くはなりますが、すぐには落ちません。もちろん万能ではなく、swapまで使い切れば結局OOM Killerが動きますし、使い切る前でもスワップの読み書きが止まらない状態（スラッシング）になれば実質的にサービス停止です。それでも「一瞬のピークを吸収して落ちずに済む」効果は大きく、「遅い」と「止まる」の差は運用上とても大きいです。

swapがちゃんと効いているかの確認

作成手順そのものは初期設定の記事に譲ります（この記事はスペックの決め方が担当なので）。ここでは「本当に有効になっているか」の確認だけ置いておきます。設定したつもりで効いていない、が一番怖いパターンです。

# swapが有効か（何も出力されなければ swap は無い）
swapon --show

# free の Swap 行に容量が入っているか
free -h

# swappiness の現在値
sysctl vm.swappiness

swapon --show が何も出力しない場合、swapは存在しません。/etc/fstab に書いたつもりでも、再起動後に有効になっていないケースがあるので、再起動したあとにもう一度このコマンドを叩くのが確実です。

過去にOOM Killerが発動していたかどうかも、あわせて見ておきます。ここでやりがちな失敗が journalctl -k だけで済ませることです。-k は --boot=0（＝今回のブート）を含意するため、OOMで落ちて再起動したあとに叩くと何も出ません。「OOMは起きていない」と誤読する典型パターンです。

# 何回再起動しているか（ブートの一覧）
journalctl --list-boots

# 1つ前のブートのカーネルログを見る（落ちた回のログはここにある）
sudo journalctl -k -b -1 | grep -iE "out of memory|oom-kill|killed process"

# 期間で横断的に探す
sudo journalctl --since "7 days ago" | grep -iE "out of memory|oom-kill"

oom-kill: という行や Killed process ... が出てきたら、すでに一度落ちています。プランかチューニングを見直すサインです。

swappiness は「再起動しても効く」形で入れる

sudo sysctl -w vm.swappiness=10 で入れると、sysctl vm.swappiness は 10 を返します。ところがこれは再起動で 60 に戻ります。ここも「確認は通るのに効いていない」が起きる場所なので、設定ファイルで永続化してください。

echo 'vm.swappiness = 10' | sudo tee /etc/sysctl.d/99-zz-swappiness.conf
sudo sysctl --system
sysctl vm.swappiness      # 再起動したあとにもう一度叩く

⚠️ ハマりどころ：/etc/sysctl.d/ は「ファイル名の辞書順で、後ろに来たファイルが勝ちます」。sshd のドロップイン（00- のように若い番号を勝たせる）とは逆なので、同じ感覚でファイル名を付けると負けます。Ubuntu では /etc/sysctl.d/99-sysctl.conf が /etc/sysctl.conf へのシンボリックリンクとして存在するため、99-swappiness.conf という名前だと 99-sysctl.conf より前に並んで上書きされる可能性があります。上の例で 99-zz- にしているのはそのためです。最後は必ず sysctl vm.swappiness の実測で確認してください。

swapファイルの作成手順（fallocate から /etc/fstab への追記まで）は、Ubuntuの初期設定記事にコマンド付きで載せています。

あわせて読みたい

Ubuntu 26.04 LTSのインストールと初期設定｜VPSで最初にやること ConoHa VPSでUbuntu 26.04 LTS（Resolute Raccoon）を立てて、最初にやるべき初期設定を手順どおりに解説します。作業用ユーザーの作成、SSH鍵認証、rootログイン停止、ufw、自動更新、swapまで。コピペで進められるコマンド付きで、初めてのVPSでも安全なサーバーに仕上げます。

「今どれだけ使っているか」を測る4つのコマンド

目安の話はここまでです。すでにサーバーが動いているなら、推測せずに測ってください。プランを上げるかどうかは、この数字だけで判断できます。

① メモリの空きを見る：free -h

free -h

               total        used        free      shared  buff/cache   available
Mem:           956Mi       612Mi        84Mi        12Mi       380Mi       344Mi
Swap:          2.0Gi       128Mi       1.9Gi

見るのは available の列です（free ではありません。free が少なくてもキャッシュは回収できるので問題ありません）。

• available が total の 20%以上：余裕あり
• available が total の 10〜15%を常に下回る：プランを上げる検討時期
• Swap の used が増え続けている：すでにメモリが足りていない

② 何がメモリを食っているかを見る：ps aux --sort=-%mem

ps aux --sort=-%mem | head -n 10

メモリ使用量の多い順に並びます（head -n 10 なので、1行目のヘッダを含めて上位9プロセスが出ます）。これで犯人がはっきりします。上位が php-fpm ばかりなら pm.max_children を見直す、mariadb が突出しているなら innodb_buffer_pool_size を見直す——プランを上げる前にやれることが見つかることも多いです。

もう少し読みやすくしたいなら、RSS（実メモリ使用量）だけをMB単位で並べる書き方も便利です。rss= comm= と = を付けてヘッダ行を抑止しているのがポイントで、これを忘れるとヘッダを数値として食って先頭に 0.0 MB COMMAND が出ます。

ps -eo rss=,comm= --sort=-rss | head -n 10 | awk '{printf "%8.1f MB  %s\n", $1/1024, $2}'

③ ディスクの残量を見る：df -h / df -i と du -sh

# パーティションごとの使用率
df -h /

# inode の使用率（容量が空いているのに書けない、はたいていこれ）
df -i /

# ディレクトリ単位で「何が太っているか」を探す
sudo du -sh /var/log /var/lib/mysql /var/www 2>/dev/null

df -h の Use% が 80%を超えたら片付けどきです。心当たりがないのに減っている場合、たいていは /var/log（ログのローテート漏れ）か /var/lib/docker（イメージとビルドキャッシュ）です。

もう1つ、df -h に余裕があるのに書き込みエラーが出るときは df -i を見てください。inode（ファイルの管理領域）を使い切っているケースがあります。小さいファイルを大量に作るキャッシュやセッションファイルで起きがちで、容量表示だけ見ていると永久に原因にたどり着けません。

④ CPUが足りているかを見る：uptime / nproc と vmstat

nproc          # 使えるコア数
uptime         # ロードアベレージ（1分・5分・15分）
vmstat 1 5     # 1秒おきに5回。wa（I/O待ち）の列を見る

判定の出発点は、ロードアベレージ（15分値）がコア数を継続的に超えていたら要注意です。2コアなら「2.00」が満杯の目安。一瞬超えるのは問題ありませんが、常時超えているなら上位プランを検討してください。

ただし、Linuxのロードアベレージには「ディスクI/O待ち（D状態）」のプロセスも含まれます。つまりCPUが暇でもディスクが遅いだけで数字は上がります。そこで vmstat の wa（または top の %wa）を併せて見ます。

• load が高く、wa が低い → 本当にCPUが足りていない。上位プランを検討
• load が高く、wa も高い → 犯人はCPUではなくI/O（重いクエリ・スワップ・大量のログ書き込み）

逆に、ロードアベレージが低いのにサイトが遅いなら、原因はCPUではありません。DBのクエリ、外部APIの待ち、キャッシュ未設定のいずれかを疑うべきで、そこでプランを上げてもお金が減るだけです。

小さく始めて、足りなくなったら上げる（ただし「下げる」は難しい）

ここまでの内容を、判断の順番に並べ替えます。

上げるのは比較的簡単、下げるのは難しい

VPSのプラン変更には、上下で非対称性があります。会社ごとに条件は違いますが、共通しているのは「大きくするのは歓迎、小さくするのは制限あり」という設計です。2026年8月19日に公式サイトで確認した範囲では、次のような制約がありました。

上げる方向

上位プランへの変更は、日割りの差額支払いなどで受け付けている会社が多いです（ConoHa VPS もこの方式）。

下げる方向

下位プランへ変更しても差額が返金されない、ストレージ容量を小さくする変更ができないといった制約が各社にあります。長期割引を一括前払いしている場合、期間中の途中解約ができないと明記している会社もあります（ConoHa VPS の「VPS割引きっぷ」は公式に「ご利用期間中の途中解約を承る事はできません」と記載）。

そもそも変更できないプランがある

ConoHa VPS は公式に「512MBプランではスケールアップ・ダウン機能をご利用いただけません」と記載しています。最小プランは上位に上げられないわけです。他社にも同種の制約がある場合があるので、「あとで上げればいい」を前提にするなら、契約前にここを必ず確認してください。

つまり、最初から大きいプランを長期契約で買うのは、いちばん損をしやすい買い方です。逆に「安いから」と最小プランを選ぶと、上げられずに作り直しになることがあります。あとから拡張する予定があるなら、最小プランではなく1つ上から始めるのが安全です。

各社の具体的な条件・料金・プランの刻みは改定が早いので、横並びの一覧はVPS比較2026にまとめてあります。

プランを上げるときの実際の手順（ダウンタイムは出る）

操作画面は会社ごとに違いますが、流れはおおむね共通です。

1. バックアップ（またはイメージ保存）を取る 2. VPSを停止する（多くの会社でプラン変更は「停止中のサーバーのみ」＝ここでダウンタイムが発生します） 3. コントロールパネルでプランを変更する（差額を支払う） 4. 起動して free -h / nproc / df -h で反映を確認する

注意点は2つ。変更中はサービスが止まるので、アクセスの少ない時間帯にやること。そしてIPアドレスやディスクの扱いが会社によって違うので、DNSやファイアウォールの設定に影響が出ないかを事前に確認しておくことです。手順とダウンタイムの長さは各社のマニュアルで確認してください。

順番はこうする

1. 用途から目安を決める（この記事の早見表） 2. 時間課金・日額課金・無料お試しがある会社で、まず小さめのプランを1〜2週間動かす（ただし最小プランが上位に上げられない会社では、1つ上のプランで試す） 3. free -h と df -h で実測する 4. 足りなければ上げる／足りていれば、そのプランで長期契約に切り替える

時間課金や日額課金のある会社なら、1週間動かしても数百円規模で済みます（単価は会社・プランで違うので公式サイトで確認してください）。この数百円をケチって36か月分を先に払うほうが、よほどリスクがあります。

※ ConoHa VPS の料金体系・割引の条件・実際に使ってみた感想は、別途まとめた指名レビュー記事で詳しく扱っています（公開後にここからリンクします）。

【PR】以下は ConoHa VPS の広告リンクです。プラン構成・料金・キャンペーンの適用条件は、申し込み前に必ず公式サイトでご確認ください。

サーバー代は経費になる（が、上げすぎても意味はない）

事業に使っている分は、VPSの料金を経費に計上できます（私用と兼用なら家事按分が必要です）。月1,000円のプラン差なら、年間で12,000円。手取りへの影響は思っているより小さいので、「必要なら迷わず上げる」でいいというのが実感です。

とはいえ、使っていないリソースにお金を払っても手取りが減るだけなのも事実です。経費を増やしたときに手取りがどう変わるかは、当サイトのツールで試算できます。

勘定科目や按分の考え方はレンタルサーバー代の勘定科目と経費計上が担当なので、詳しくはそちらへどうぞ。なお税額・控除の扱いは条件で変わります。最終的な判断は最新の情報（国税庁など）と、必要に応じて税理士への確認をおすすめします。

プランを決めたら、次は初期設定

スペックが決まったら、あとは借りて安全な状態にするだけです。ここは各社共通の話なので、既存記事に役割を分けています。

• 最初にやることの全体像 → VPS初期設定のやることリスト（作業用ユーザー・SSH鍵認証・ufw など7ステップ）
• Ubuntu 26.04 のコマンド通し手順（swapファイルの作成含む） → Ubuntu 26.04 LTSのインストールと初期設定
• OSをまだ決めていない → VPSのOSはどれを選ぶ？

あわせて読みたい

VPS初期設定のやることリスト｜Ubuntuで最初にやる7つ【2026年版】 VPS 初期設定でまず何をやるかをリスト化。ConoHa VPS＋Ubuntu前提で、更新・作業ユーザー・SSH鍵認証・ufw・自動更新までの全体像を要点で解説します。環境別の通し手順への進み方もわかる2026年版のハブ記事です。

特に、小さいプランを選んだ人はswapの確保を初期設定の段階でやってしまうのをおすすめします。あとから「落ちてから入れる」より、最初に入れておくほうが圧倒的に楽です。

まとめ｜VPSスペックの選び方

スペック表とにらめっこしている時間は、正直あまり生産的ではありません。時間課金や日額課金のある会社なら、数百円規模で1週間試せます。目安で当たりをつけて、実際に動かして測る——これが最も無駄の少ない決め方だと考えています。

VPSのメモリは何GBあれば十分ですか？

用途によります。目安としては、Python/Node の常駐スクリプトやBot（DBなし）なら512MB〜1GB、WordPress 1サイトなら1〜2GB、WordPressを複数サイトやメールサーバーを動かすなら2〜4GB、Dockerやフロントエンドのビルドを回す開発環境なら4GB以上です。根拠は常駐プロセスの積み上げで、Nginx＋PHP-FPM＋MariaDB の構成だとOS本体100〜200MB・Nginx 20〜40MB・PHP-FPM 1プロセス40〜80MB・MariaDB 200〜400MB あたりが目安になります（設定やバージョンで変わります）。なお Ubuntu Server の公式システム要件（24.04 LTS・amd64 基準）は、クラウドイメージで最小1GB・推奨3GB以上と記載されています。

512MBのプランでWordPressは動きますか？

動きますが、条件付きです。PHP-FPMの pm.max_children を小さめに設定する、MariaDBのバッファを小さくする、キャッシュを効かせる、といったチューニングが前提になります。また、Ubuntu Server の公式システム要件（クラウドイメージで最小1GB）を下回る構成なので、swapの確保は必須と考えてください。プラグインの一括更新やバックアップのように一瞬メモリを使う操作でOOM Killerが発動し、MariaDBやPHP-FPMが強制終了することがあります。加えて、最小プランを上位プランへ変更できない会社がある点にも注意してください（ConoHa VPS は公式に「512MBプランではスケールアップ・ダウン機能をご利用いただけません」と記載しています）。逆に、PHPとDBを使わない静的サイトなら512MBでも十分に動きます。

vCPUのコア数は多いほうがいいですか？

多いに越したことはありませんが、主要なVPSではメモリを決めるとコア数もセットで決まるので、コア数だけを選ぶことは基本的にできません（2026年8月19日確認時点で、主要各社とも4GBクラスは4コアでした。メモリの刻み方とコア数の割り当ては会社ごとに違います）。コア数が効くのはビルド・コンパイル・画像や動画の変換といった計算量の多い処理で、PHPでページを1枚返す程度の処理ではほとんど使いません。サイトが遅いときは、まず uptime のロードアベレージ（15分値）がコア数を超えているか、vmstat 1 5 の wa（I/O待ち）が高くないかを確認してください。load が高くても wa が高いなら、原因はCPUではなくI/OやDB・キャッシュ設定の可能性が高いです。

あとからプランを上げられますか？下げるのは？

上げるのは比較的簡単ですが、下げる方向は各社とも制限があります。ConoHa VPS の場合、上位プランへの変更は日割りの差額支払いで可能な一方、下位プランへ変更しても差額は返金されず、長期割引の「VPS割引きっぷ」は利用期間中の途中解約ができないと公式に明記されています。さらに512MBプランはスケールアップ・ダウンの対象外とされており、「小さく始めてあとで上げる」ができません。条件は各社で異なり変更もされるので、契約前に必ず公式サイトで確認してください（各社の条件の横並びはVPS比較2026にまとめています）。安全な順番は「時間課金や日額課金で1〜2週間動かして実測 → 必要なプランを確定 → そのプランで長期契約」です。

—

出典（すべて 2026年8月19日 確認）

• Ubuntu Server システム要件（最小メモリ・最小ストレージ・推奨値。24.04 LTS・amd64 基準の注記あり）：https://ubuntu.com/server/docs/reference/installation/system-requirements/
• WordPress 動作要件（PHP 8.3以上・MariaDB 10.11以上／MySQL 8.0以上・HTTPS必須。サーバー全体のメモリ要件の記載なし）：https://wordpress.org/about/requirements/
• PHP マニュアル：FPM の設定（pm.max_children は必須項目で、子プロセス数の上限）：https://www.php.net/manual/en/install.fpm.configuration.php
• man journalctl(1)（-k は --boot=0 を含意する）：https://man7.org/linux/man-pages/man1/journalctl.1.html
• man sysctl.d(5)（設定ファイルはファイル名の辞書順で、後ろのファイルが優先される）：https://man7.org/linux/man-pages/man5/sysctl.d.5.html
• ConoHa VPS 料金・プラン構成（メモリ／CPUコア数／SSD容量）：https://vps.conoha.jp/pricing/
• ConoHa VPS プラン変更（512MBプランと1GB以上のプランの間で変更できない旨の記載）：https://support.conoha.jp/v/changeplan/
• ConoHa VPS スケールアップ機能（「512MBプランではスケールアップ・ダウン機能をご利用いただけません」の記載）：https://vps.conoha.jp/function/scaleup/
• ConoHa VPS 追加ストレージ（本体とは別に時間課金でアタッチできるSSD）：https://www.conoha.jp/vps/function/additionaldisk/
• ConoHa VPS 割引きっぷ（利用期間中の途中解約不可の記載）：https://vps.conoha.jp/discountticket/ver2.0/
• XServer VPS 料金一覧（プランごとのvCPU・NVMe SSD容量）：https://vps.xserver.ne.jp/price.php
• XServer VPS お知らせ（2026年7月14日17:00での2GBプラン新規受付停止・メモリ無償増量の新規提供終了）：https://vps.xserver.ne.jp/support/news_detail.php?view_id=18920

※本文中のメモリ使用量・SSD使用量の数値は、断りのない限り筆者環境（ConoHa VPS・Ubuntu・Nginx＋PHP-FPM＋MariaDB）で確認した目安です。設定・バージョン・載せるアプリケーションによって大きく変わるため、実際の判断は本文の実測コマンドで自分の環境を測ったうえで行ってください。料金・プラン構成・受付状況は変更されます。申し込み前に各社公式サイトで最新をご確認ください。

更新日：2026年8月20日