共有ホスティングとVPSの違いは？どちらを選ぶべきか徹底解説

共有ホスティングと VPS：簡潔な回答

共有ホスティングと VPS の違いは、速度の問題ではありません。共有ホスティングでは、他者が設定やパッチ適用を行い、数百人の顧客で共有するマシン上のアカウントを借りることになります。一方、VPS（仮想専用サーバー）では、root アクセス権を持つオペレーティングシステム全体を借りるため、必要なソフトウェアをインストールできる反面、自分で壊したものは自分で修復する必要があります。

決定的に異なるのは以下の3点です。root 権限の有無、メモリが専用に割り当てられているか共有プールから借用しているか、そして深夜にサーバーが応答しなくなった際にホスト側が修正するか自分で行うかです。機能比較表に記載されているあらゆる項目は、これら3点に起因します。

サイトが静的ページ、画像、お問い合わせフォームで構成されているなら、共有ホスティングが適切な選択肢であり、コストも抑えられます。一方、訪問者がいない間も実行し続けるプログラムが必要な場合は、VPS が必要です。

共有ホスティングが実際に提供するもの

1台の Linux サーバーで、複数の顧客アカウントを同時に運用します。各アカウントはドキュメントルート、データベース、メールボックスを持つホームディレクトリとして構成され、通常は Apache または LiteSpeed といった単一の Web サーバーがサーバー上の全サイトを処理します。シェルプロンプトの代わりにコントロールパネルが提供されます。root 権限は付与されないため、パッケージのインストール、ポートの開放、バックグラウンドサービスの起動はできません。

多くの共有ホスティングは CloudLinux を採用しています。これは各アカウントを個別のコンテナに隔離し、プロセッサ時間と同時に実行可能なプロセス数に厳格な上限を設ける仕組みです。プロセス数の上限を超えても、サイトの動作が遅くなるわけではありません。サーバーは 508 Resource Limit Is Reached と記載されたエラーページを返します。このページが表示されるのは、隣接するユーザーがリソースを消費しているからではなく、あなたのアカウントが自身の上限に達したことを意味します。

このトレードオフは意図的なものです。ユーザーは制御権を手放す代わりに、ホスティング事業者がカーネルのパッチ適用、PHP の更新、証明書の更新、夜間のバックアップといった管理業務を代行します。多くのサイトにとって、これは合理的な選択です。

VPS が提供するもの

VPS はホストサーバー上で動作する仮想マシンです。Linux VPS プランの多くで採用されているハイパーバイザーである KVM 環境下では、インスタンスは独自のカーネルをブートし、固有の IP アドレス、ファイアウォール、init システムを保持します。sudo は動作します。apt install も動作します。systemd を通じて起動したプログラムは、ログアウト後も実行され続け、クラッシュ時には再起動し、再起動後には自動的に復旧します。

この root アクセス権があるからこそ、マシンのセキュリティはユーザー自身の責任となります。他の誰も監視していません。VPS 上で実行されるものの範囲 が広いのは、まさにこの理由によります。このマシンは、Linux サーバーができることであれば何でも実行可能です。

違い 1: root アクセスとそれが可能にすること

root 権限は、他のすべての違いを生む根本的な要素です。root があれば、ディストリビューションから任意のパッケージをインストールし、任意のポートをバインドし、systemd unit を作成し、マシン上のあらゆるログを読み取り、sysctl でカーネル設定を変更できます。これがない場合、パネルが提供するリスト（PHP バージョンの選択、固定された拡張機能のセット、cron ジョブ用のフォームなど）に制限されます。

VPS では、マシン上で何が待ち受けているかをいつでも確認できます。

ss -ltnp

各行は、プロセスが所有する 1 つのオープンなソケットを表しています。したがって、起動に失敗したサービスは、該当する行が存在しないことで判明します。共有ホスティングでは、この問いに対する答えはありません。80 番ポートと 443 番ポートはホストの Web サーバーが占有しており、ユーザーが何を記述してもそれらを奪うことはできないためです。

違い 2: 割り当てメモリと借用メモリ

共有ホスティングは、複数のアカウントが同時に高負荷になることは少ないという前提で販売されています。マシン上のメモリはプールとして扱われ、アカウントに割り当てられた分量は予約ではなく上限です。上限に達すると PHP プロセスは強制終了され、訪問者には 500 エラーや 508 エラーが返されます。

VPS では、プランに含まれるメモリは自身のインスタンス専用です。free -m で確認でき、仮想マシン外のプロセスがメモリを奪うことはありません。

プロセッサ時間については例外です。ほとんどの VPS プランでは物理コアを他のゲストと共有しており、以下のコマンドで測定可能です。

vmstat 1 5

st 列は steal time を示します。これは、仮想プロセッサが実行可能状態であったにもかかわらず、物理コアが他のゲストに割り当てられていた時間の割合です。数パーセント程度の安定した値であれば正常です。二桁の数値が継続する場合はホストが過剰に詰め込まれている状態であり、サポートチケットに記載すべき指標となります。共有ホスティングにはこれに相当する指標はありません。なぜなら、それを表示するために必要なツールには root 権限が必要だからです。ストレージも同様の性質を持つため、VPS プランの背後にあるディスクタイプが重要であり、販売ページを鵜呑みにせず、最初の 1 週間で 自ら新しい VPS を測定する価値があるのです。

違い 3: 障害発生時の責任の所在

共有ホスティングでは、OS、Web サーバー、PHP ビルド、証明書、および夜間のバックアップの管理責任はホスト側にあります。サーバーが応答しなくなった場合、チケットを発行すれば、すでに誰かが対応を開始しています。その代償として、ホストがサポートしていないソフトウェアのインストールを依頼することはできません。

アンマネージド VPS では、プロバイダーの責任範囲はハイパーバイザー、ネットワーク、電源のみです。カーネルより上のすべてはユーザーの責任となります。セキュリティアップデート、ファイアウォール、バックアップ、証明書の更新、監視はすべて自分で行う必要があり、サポートが Web サーバーの設定をデバッグするためにログインしてくれることはありません。初日から計画を立ててください。まずは 新しい VPS での最初の 10 分間、次に 理解可能なファイアウォール、自動セキュリティアップデート、そして 少なくとも一度は復元テストを行ったバックアップが必要です。

共有ホスティングが適している場合

パンフレットサイトは最も明確な例です。数ページのコンテンツ、画像、問い合わせフォーム、あるいはキャッシュプラグインを導入した WordPress で、1 日数千程度のアクセスがあるサイトが該当します。バックグラウンドジョブや特殊なランタイムは不要で、リクエスト間でメモリ上に保持すべきデータもありません。このようなサイトには共有ホスティングが適しており、VPS よりも安価で、専門スタッフが保守を代行してくれます。VPS への移行はメリットがなく、本来不要な管理業務を増やすだけです。

あまり注目されていませんが、もう一つのケースがあります。もしチーム内にログファイルの確認や apt upgrade の実行を望む人がいないのであれば、共有ホスティングの方が安全な選択肢です。パッチが適用されずデータベースのポートが開放されたままの VPS は、専門家が最新の状態に保っている共有アカウントよりも危険です。管理権限は、それを行使する人がいて初めてメリットとなります。

兆候 1: 実行し続けるプログラムが必要である

デーモンとは、メモリ上に常駐して処理を待機するプログラムのことです。API、チャットボット、キューワーカー、ゲームサーバーなどがこれに該当します。共有ホスティングではリクエストが到達した時のみコードが実行されます。SSHセッションから実行したままのプロセスは、アカウントのプロセス数制限に抵触するため、セッション終了時に強制終了されます。

VPS上では、同じプログラムを systemd ユニットとして実行します。

sudo systemctl enable --now myapp
systemctl status myapp

systemctl status を実行すると、プロセスIDとともに Active: active (running) が表示されるはずです。もし Active: failed (Result: exit-code) と表示される場合は、journalctl -u myapp -n 50 に原因が記録されています。ここにはプログラムが停止した瞬間の出力が記録されています。ユニットファイル内の Restart=always はクラッシュ後の自動再起動を可能にし、enable は再起動後の自動起動を可能にします。systemd サービスとタイマーの作成 は、VPS運用において最初に習得すべき重要なスキルです。

兆候 2: パネルが提供していないランタイムが必要

コントロールパネルは利用可能な言語バージョンのリストを提供します。もしアプリケーションがそのリスト外のバージョンを必要とする場合、あるいはコンパイルが必要なライブラリ、ffmpeg、ヘッドレスブラウザ、MySQL以外のデータベースなどが必要な場合、共有ホスティング環境ではそれらを導入できません。ソフトウェアのインストールには root 権限が必要ですが、共有アカウントにはコンパイラや開発用ヘッダーが含まれていないため、ビルドを実行しても何も生成されずに失敗します。

VPS であれば apt install を使用してインストールするか、コンテナ内で実行してホスト環境をクリーンに保つことができます。アプリケーションの構成要素が複数になる場合は、VPS 上での Docker Compose を利用するのが一般的な手法です。

兆候 3: cron ジョブが時間通りに実行される必要がある

共有ホストでは、フォーム経由で cron ジョブを受け付け、最小実行間隔（通常は 5 分または 15 分）を設けています。アカウントのプロセッサ制限を超えて実行されたジョブは途中で強制終了されますが、ユーザーが閲覧可能なログに書き込まれないため、静かに失敗します。

VPS 上では crontab -e が記述したあらゆるスケジュールを受け入れますが、systemd timer を使用する方がさらに優れています。

systemctl list-timers
journalctl -u cron -n 20

list-timers はすべてのタイマーの次回実行予定と前回の実行結果を表示し、cron ログには各コマンドの実行状況が記録されます。ジョブが実行されなかった場合、開始されなかったのか、開始後に失敗したのかを判別できます。この区別こそが、スケジュールされたタスクのデバッグにおける大半を占めます。

兆候 4: 近隣ユーザーがレスポンス時間を悪化させている

この症状は特有のものです。コードを一切変更していないにもかかわらず、同じページが夜間には高速に応答し、午後 7 時には低速になるという現象です。誰かを責める前に、まずは自分のマシンから測定してください。

for i in $(seq 1 20); do curl -o /dev/null -s -w '%{time_starttransfer}\n' https://example.com/; sleep 5; done

time_starttransfer は、レスポンスの最初のバイトが届くまでの時間（秒単位）です。20 個の数値が近い値で並んでいる場合、サーバー側に問題はなく、修正すべき箇所はコードやデータベースクエリにあります。もし午前 3 時には安定しているのに、ピーク時には数百ミリ秒単位で変動する場合、目に見えない他のアカウントと混雑したマシンを共有しています。これはコードを改善しても解決できない唯一のトリガーです。原因がアカウントの境界線の向こう側にあるためです。

移行の実際のコスト

これらは 2026 年 8 月時点における、各カテゴリの最小プランの一般的な広告価格です。これらは見積もりではなく目安として捉え、購入前に最新の価格を確認してください。

[
  {
    "plan": "Shared hosting",
    "first_term_usd": 3,
    "renewal_usd": 12
  },
  {
    "plan": "VPS, 1 vCPU 1 GB",
    "first_term_usd": 5,
    "renewal_usd": 6
  },
  {
    "plan": "VPS, 2 vCPU 4 GB",
    "first_term_usd": 12,
    "renewal_usd": 15
  },
  {
    "plan": "Managed VPS, 2 vCPU 4 GB",
    "first_term_usd": 25,
    "renewal_usd": 30
  }
]

提示価格の差は月額 3 から 5 米ドルですが、この数字だけで判断してはいけません。共有ホスティングは通常 1 年から 3 年分の一括払いを条件とした初回契約時の価格を広告しており、更新時には 12 ドル前後になります。更新価格同士を比較すると状況は一変し、共有アカウントの 12 ドルに対し、エントリーレベルの VPS は 6 ドルとなります。

ただし、この比較には注意が必要です。スペックが同等ではないためです。1 vCPU、1 GB の VPS は Web サーバーとデータベースを 1 台の小さな箱で動かすことになり、WordPress では実際のトラフィックが発生すると厳しくなります。更新後の共有プランと公平に比較するなら、2 vCPU、4 GB のプラン（約 15 ドル）が妥当です。つまり、実際のコスト差は数倍ではなく、月額数ドル程度に過ぎません。

より大きなコストは請求書には現れません。VPS にはセットアップに 1 時間、毎月のアップデートに数分、そして何らかのトラブルが発生した際の対応に一晩を費やすことになります。これを自身の時給に換算すれば、価格差はすぐに埋まります。VPS の実質的なコストでは、各サイズについてより詳細に解説しています。

トラフィックを維持したまま共有ホスティングからサイトを移行する

1. 移行の1日前に、ドメインの DNS (domain name system) TTL (time to live) を 300 秒に下げます。これにより、切り替えが数時間ではなく数分で反映されるようになります。
2. 新しいサーバーを構築し、DNS を変更する前にその IP アドレスでサイトが動作することを確認します。
3. ファイルをコピーし、データベースをダンプして新しいサーバーに復元します。
4. ノート PC の hosts ファイルを編集してドメインを新しい IP に向けることで、手元の環境のみでテストを行います。
5. 新しいサーバーで TLS (transport layer security) 証明書を発行し、A レコードを変更します。その後、共有ホスティングのアカウントは 1 週間維持してください。

dig example.com A +noall +answer
rsync -avz ~/public_html/ deploy@203.0.113.10:/srv/www/example.com/
mysqldump --single-transaction -u dbuser -p dbname > site.sql

dig は回答の 2 列目に TTL を表示するため、切り替え前に低い値が反映されているかを確認できます。--single-transaction はテーブルをロックせずに一貫性のあるスナップショットを取得します。これは、作業中も旧サイトで注文を受け付けている場合に重要です。新しいサーバーでは、同じ日のうちに証明書を有効にしてください。Ubuntu 上の nginx での Let's Encrypt は、DNS レコードがサーバーを向いていれば数分で完了します。

責任を伴わないリソース

4つの兆候が自身のサイトに当てはまるものの、メンテナンスに魅力を感じない場合は、マネージド VPS が中間の選択肢となります。割り当てられたメモリと root 権限はそのまま維持しつつ、パッチ適用や監視、多くの場合管理パネルの提供をプロバイダーに任せることができます。上記の表では、同規模のアンマネージド VPS が 15 ドルであるのに対し、マネージド VPS は約 30 ドルとなっています。この差額は、夜間にサーバーが応答しなくなった際に、誰かが対応してくれるための費用です。

もしこの選択肢が自分に適していると思われるなら、マネージド VPS とアンマネージド VPS の比較が次に読むべき記事です。すでに稼働中の VPS があり、ピーク時に依然として steal time が高い場合は、その次のステップとして 隣接するユーザーが一切存在しない専用サーバーを検討してください。

FAQ

VPS は共有ホスティングより高速ですか？

必ずしもそうとは限りません。負荷の低い共有サーバーの方が、1 vCPU の VPS よりも WordPress のページ表示が速い場合があります。VPS が提供するのは一貫性です。プランに含まれるメモリは専有できるため、応答時間は他のユーザーの負荷ではなく、自身のコードに依存します。午前3時でも午後7時でもページが遅い場合、原因はコードやデータベースクエリにあります。同じコードを VPS に移行しても、問題はそのまま残ります。

共有ホスティングで Node.js や Python アプリを動かせますか？

可能な場合もありますが、厳しい制限があります。一部の管理パネルは Passenger を介してアプリケーションを起動し、リクエストに応じて実行します。ホスト側の Web サーバーが 80 番と 443 番ポートを占有しているため、自分でポートをバインドすることはできません。また、アカウントごとのプロセス制限により長時間実行されるプロセスは終了させられるため、リクエスト間でワーカーをメモリに常駐させることもできません。ボット、キューワーカー、WebSocket サーバーには VPS が必要です。

VPS を運用するには Linux の知識が必要ですか？

アンマネージド VPS の場合は必要です。SSH キー、ファイアウォール、アップデート、バックアップの管理、そしてログを読む習慣が求められます。初期設定に1時間、その後は毎月数分程度の時間を確保してください。そのような作業を望まない場合は、リソースはそのままにメンテナンスをプロバイダーに委託するマネージドプランを選択してください。これについては マネージド VPS とアンマネージド VPS の比較 で解説しています。

共有ホスティングから VPS への移行中にサイトは停止しますか？

DNS の TTL を事前に下げ、両方のアカウントを稼働させておけば停止しません。移行の1日前に TTL を 300 秒に設定し、ファイルとデータベースをコピーします。次に、PC の hosts ファイルを使用して新しいサーバーで動作確認を行い、最後に A レコードを書き換えます。切り替え後数分間は、古いサーバーにアクセスする訪問者と新しいサーバーにアクセスする訪問者が混在するため、共有ホスティングのアカウントは1週間ほど維持してください。最終的なデータベースダンプ中はサイトを読み取り専用モードにするか、その間に発生した書き込みデータが失われることを許容する必要があります。