SSD Nodes Learn Hosting plans →
ガイド Matt Connor著者 Matt Connor ・更新日 2026-11-06

共有ホスティングとVPSの違いと選び方

共有ホスティングとVPSの違いは速度だけではありません。rootアクセスの有無と障害対応の担当を軸に、共有ホスティングが向くケースと移行すべき4つのサインを解説します。

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

共有ホスティングとVPSの違いは、速度だけの問題ではありません。共有ホスティングでは、他者が構成、パッチ適用、顧客間での共有を行うマシン上のアカウントを借ります。アンマネージドVPS(virtual private server)では、root アクセス付きのオペレーティングシステム全体を借りるため、必要なものを自分でインストールできます。その一方で、自分で壊したものも自分で修復します。

大きく異なる点は3つです。root を使えるかどうか。メモリの割り当てと保証がプランによってどう定められているか。そして、深夜にサーバーが応答しなくなったとき、ホスティング事業者が修復するのか、自分で修復するのかです。機能一覧にある内容は、すべてこの3点から決まります。

サイトがページ、画像、問い合わせフォームで構成されているなら、多くのサイトでは共有ホスティングが適切です。誰もアクセスしていない間も動作し続けるプログラムが必要な場合は、VPSを選ぶ前に、利用中の共有ホスティングが常駐サービスをサポートしているか確認してください。

共有ホスティングで実際に提供されるもの

1 台の Linux サーバー上で、多数の顧客アカウントが同時に稼働します。各アカウントには、ホームディレクトリ、ドキュメントルート、データベース、メールボックスがあります。通常は Apache または LiteSpeed の単一の Web サーバーが、そのサーバー上のすべてのサイトにサービスを提供します。コントロールパネルを利用でき、ホストによっては shell prompt も提供されます。root は利用できません。ただし、ホームディレクトリへのソフトウェアのインストール、許可されたポートの使用、バックグラウンドサービスの実行を認めるプロバイダーもあります。

多くの共有ホストでは CloudLinux が動作しています。CloudLinux は各アカウントを軽量コンテナに分離し、CPU 時間、メモリ、ディスク I/O、プロセス数、entry process 数に上限を設定します。上限に達した場合の影響は、それぞれ異なります。CPU または I/O の上限に達すると、サイトの応答は遅くなりますが、サイト自体は停止しません。メモリまたはプロセス数の上限に達すると、通常は 500 エラーや 503 エラーとして現れます。Apache では、508 Resource Limit Reached というタイトルのエラーページが entry process の上限に達したことを示します。LiteSpeed では entry process の処理方法が異なります。いずれの場合も、上限に達しているのは自分のアカウントです。近隣のアカウントが自分の割り当てを奪っているわけではありません。

これは意図的なトレードオフです。自由な制御を手放す代わりに、ホストがカーネルにパッチを適用し、サポート対象のソフトウェアを保守します。証明書の更新とバックアップのスケジュールは、契約プランによって異なります。非常に多くのサイトにとって、これは適切な選択です。

VPS で実際に利用できるもの

VPS は、ホストサーバー上で動作する仮想マシンです。KVM では、インスタンスが独自のカーネルで起動し、独自の IP アドレス、ファイアウォール、init システムを持ちます。root アクセスが可能な管理対象外の Linux VPS では、sudo が動作します。Debian または Ubuntu のインストール環境では、apt install が動作します。systemd で起動したプログラムはログアウト後も動作し続けます。適切な再起動設定とブート設定を行えば、クラッシュ後に再起動し、リブート後にも復旧します。

同じ root アクセスがあるため、マシンのセキュリティは自分で管理する必要があります。監視してくれる人はいません。VPS で実行されるものの範囲が広いのは、まさにこのためです。そのサーバーは、Linux サーバーで可能なことを実行できます。

違い 1: root アクセスと、それによって可能になること

root によって、オペレーティングシステムを制御できます。ディストリビューションの任意のパッケージをインストールし、任意のポートをバインドし、systemd の unit を作成し、マシン上のすべてのログを読み取り、sysctl でカーネル設定を変更できます。root がなくても、パネルが常に上限になるとは限りません。alwaysdata では、ad_install_pecl を使用して追加の PHP 拡張機能をインストールできます。

VPS では、どのプロセスが待ち受けているかをいつでもマシンに確認できます。

ss -ltnp

各ソケット行には TCP の待ち受けが表示されます。プロセスの詳細は権限によって異なるため、TCP で待ち受けるはずのサービスが起動に失敗すると、その行が表示されません。共有ホスティングでは、ソケット情報へのアクセスと独自の待ち受けを実行する権限はプロバイダーによって異なります。ただし、ポート 80 と 443 はホスト側が管理します。

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

共有ホスティングは、同じタイミングで負荷の高いアカウントが少ないことを前提に提供されています。サーバーのメモリは共有プールであり、アカウントに割り当てられる量は予約ではなく上限です。CloudLinux では、物理メモリの上限に達するとプロセスが終了し、訪問者に 500 または 503 が返ることがあります。

VPS では、free -m が報告するのはゲストから認識できるメモリであり、物理メモリが取り消し不能な形で予約されていることの証明ではありません。ホストは ballooning によってゲストのメモリを回収できます。これが許可されるかどうかは、契約プランのリソース保証によって決まります。

共有 CPU 型の VPS プランでは、プロセッサ時間も共有リソースです。steal time は自分で測定できます。

vmstat 1 5

st 列は steal time です。これは、仮想プロセッサが実行可能な状態だった時間のうち、物理コアが別のゲストに割り当てられていた割合を示します。過剰割り当てを証明する普遍的な正常値やしきい値はありません。steal time が継続して高い場合は、サポートチケットに記載できる測定値になります。vmstat は通常の読み取りに root 権限を必要としませんが、関連する /proc ファイルへのアクセスが必要です。共有ホストでは、その情報が制限されることがあります。ストレージも確認すべきリソースです。そのため、VPS プランで使用されるディスクの種類が重要になります。また、販売ページの説明をそのまま信頼せず、最初の 1 週間に新しい VPS を自分で測定する価値があります。

障害発生時の責任者

共有ホスティングでは、ホスト側がオペレーティングシステム、Web サーバー、サポート対象の PHP ビルドを管理します。証明書とバックアップの対象範囲は、プランによって異なります。マシンが応答しなくなった場合はチケットを起票します。対応内容は、ホストのサポート体制によって異なります。この制約に伴うコストは、同じルールの裏側にあるものです。サポート対象外のソフトウェアは、ホストのインストール方針とサービス方針に適合させる必要があります。

管理対象外の VPS では、プロバイダーがハイパーバイザー、ネットワーク、電源を管理します。カーネルより上の層は、すべて利用者の管理範囲です。セキュリティ更新、ファイアウォール、バックアップ、証明書の更新、監視はすべて利用者の作業です。サポート担当者がログインして Web サーバーの設定をデバッグすることもありません。初日からその前提で計画します。まずは 新しい VPS で最初の 10 分に行う作業、次に 内容を理解しているファイアウォール、自動セキュリティ更新、そして 少なくとも 1 回はリストアしたバックアップを準備します。

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

パンフレット型サイトは、最も分かりやすい例です。数ページのコンテンツ、画像、問い合わせフォーム、場合によってはキャッシュプラグインを使用した WordPress があり、トラフィックがプランのリソース制限内に収まる構成です。バックグラウンドジョブはありません。特殊なランタイムもありません。リクエスト間でメモリに保持し続ける必要があるものもありません。共有ホスティングはこのようなサイトに適しており、サーバーの保守を専門の担当者に任せられます。ただし、すべての VPS より安いとは限らないため、料金を比較してください。VPS に移行しても得られるものはなく、これまでなかった作業が増えるだけです。

もう 1 つ、あまり注目されないケースがあります。自分の側にログファイルを読んだり apt upgrade を実行したりする人がいない場合は、共有ホスティングの方が安全です。データベースポートを開放したままパッチが適用されていない VPS は、専門家が最新の状態に保守する共有アカウントより悪い結果を招きます。制御できることは、誰かが実際に利用する場合にのみ利点になります。

兆候 1: 継続して実行するプログラムが必要

デーモンはメモリ上で動作し続け、処理を待機するプログラムです。API、チャットボット、キューワーカー、ゲームサーバーなどが該当します。共有ホスティングの規則はサービスごとに異なります。DreamHost は共有プランで永続プロセスを禁止していますが、alwaysdata は有料プランで監視対象のカスタムサービスを提供しています。

VPS では、同じプログラムが systemd の unit になります。

sudo systemctl enable --now myapp
systemctl status myapp

systemctl status はプロセス ID を含む Active: active (running) を出力するはずです。Active: failed (Result: exit-code) が出力された場合は、journalctl -u myapp -n 50 に停止した時点でのプログラム自身の出力が記録されているため、そこに理由があります。unit ファイルの Restart=always はクラッシュ後にプログラムを再起動し、enable は再起動後にプログラムを起動します。systemd サービスとタイマーの作成 は、VPS で最初にきちんと身につける価値のあるスキルです。

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

パネルには一覧が表示されます。アプリケーションに、その一覧にない言語バージョン、コンパイルが必要なライブラリ、ffmpeg、ヘッドレスブラウザー、またはパネルが提供していないデータベースが必要な場合は、プロバイダーのインストール規則を確認してください。cPanel は MySQL に対応しており、ホスティング事業者が有効にしている場合は PostgreSQL にも対応します。ホームディレクトリへのソフトウェアのインストールに、常に root 権限が必要とは限りません。DreamHost では、共有サーバー上で zlib とカスタム Python バージョンをコンパイルする方法を案内しています。

VPS では apt install でインストールするか、コンテナで実行してホスト環境をクリーンに保ちます。アプリケーションが複数の構成要素で動作するようになったら、通常は VPS 上の Docker Compose を使用します。

兆候 3: cron ジョブが予定どおりに実行される必要がある

共有ホストでは、フォームから cron ジョブを登録します。ホスト側で独自の最小実行間隔が設定されている場合もあります。CloudLinux では、アカウントの processor limit に達したジョブは強制終了されず、処理速度が低下します。そのため、次の実行時刻になっても前のジョブが実行中のままになることがあります。アカウントがすでに process cap に達している場合、ジョブは新しいプロセスをまったく起動できません。状況の一部は確認できます。cPanel の Cron Email 設定を有効にすると、各ジョブの出力がメールで届きます。対応している CloudLinux ホストでは、パネルの Resource Usage ページに、アカウントが到達した制限と fault の件数が表示されます。システムログへのアクセス権と制限値を引き上げる権限はホスト側にあります。ただし、一部のプロバイダーでは、開始時刻と終了時刻を含むタスクログを提供しています。

VPS では、crontab -e により、インストールされている cron 実装がサポートするスケジュールを設定できます。systemd timer のほうがさらに適しています。

systemctl list-timers
journalctl -u cron -n 20

list-timers は、現在メモリ上にある timer の次回および前回の実行時刻を表示します。timer が起動するサービスの終了結果を表示するものではありません。cron の journal は、インストールされている 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 年 11 月 4 日に確認した掲載価格の例です。カテゴリ全体の平均価格や、利用可能な最安プランではありません。共有ホスティング、4 GB VPS、マネージドサービスの例は、年額請求の DreamHost Web Hosting Launch、Stack 4、Managed VPS Business です。1 GiB VPS は、月額上限で利用する DigitalOcean の通常の Basic Droplet です。購入前に現在の価格を確認してください。

グラフAdvertised monthly price examples in US dollars, November 4, 2026
このグラフのデータ
[
  {
    "plan": "Shared hosting, DreamHost",
    "first_term_usd": 2.89,
    "renewal_usd": 10.99
  },
  {
    "plan": "VPS, 1 vCPU 1 GiB, DigitalOcean",
    "first_term_usd": 6,
    "renewal_usd": 6
  },
  {
    "plan": "VPS, 2 vCPU 4 GB, DreamHost",
    "first_term_usd": 6.99,
    "renewal_usd": 11.99
  },
  {
    "plan": "Managed VPS, 2 cores 2 GB, DreamHost",
    "first_term_usd": 13.75,
    "renewal_usd": 31.99
  }
]

表示上の価格差は、月額 2.89 米ドルから 6 米ドルまであります。ただし、これだけで判断することはできません。共有ホスティングの例では、1 年分を前払いする必要があり、更新後は月額 10.99 米ドルです。更新後の料金同士で比較すると、状況が変わります。共有アカウントは月額 10.99 米ドル、エントリー向け VPS は 6 米ドルです。DigitalOcean の 2 つの価格が同じなのは、この例に初回割引がないためです。

この比較では、サイズが同じではない点に注意してください。1 vCPU、1 GB の VPS で Web サーバーとデータベースを 1 台の小さなサーバー上で動かす構成は、実際のトラフィックが発生すると WordPress には厳しくなります。2 vCPU、4 GB の例は更新後に月額 11.99 米ドルですが、共有アカウントの制限と VPS の容量は単純に置き換えて比較できません。この例では、共有ホスティングに対する更新後の追加料金は月額 1 ドルです。

より大きなコストは請求書には現れません。VPS では、初期設定に 1 時間、毎月の更新に数分、そして初めて問題が発生したときの対応に夜の時間が必要になります。自分の時間単価で計算すると、価格差はすぐに縮まります。VPS の実際の費用では、サイズごとの違いをさらに詳しく説明しています。

共有ホスティングからサイトを移行してもトラフィックを失わない方法

  1. 1 日前に、ドメインの DNS(domain name system)TTL(time to live)を 300 秒に下げ、切り替える前に以前の TTL が期限切れになるまで待ちます。ローカルキャッシュの更新には、それより長くかかる場合があります。
  2. DNS に触れる前に、新しいサーバーを構築し、その IP アドレスでサイトが動作することを確認します。
  3. ファイルをコピーし、データベースをダンプして、新しいサーバーにリストアします。
  4. ノート PC の hosts ファイルを使ってテストします。このファイルは、そのマシン上でのみドメインを新しい IP アドレスに割り当てます。
  5. A レコードを変更する前に、DNS 検証または既存の有効な証明書を使って、新しいサーバーで TLS(transport layer security)証明書を発行します。共有ホスティングのアカウントは 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 は、テーブルをロックせずに InnoDB テーブルの一貫したスナップショットを取得します。非トランザクションテーブルや同時に行うスキーマ変更には、別途注意が必要です。また、そのスナップショットには後から行われた注文は含まれません。新しいサーバーでは、同じ日に証明書を使用できる状態にします。DNS レコードがサーバーを指すようになれば、Ubuntu で nginx に Let's Encrypt を設定する の手順は数分で完了します。

責任を負わずに利用できるリソース

4 つの兆候がサイトに当てはまるものの、保守作業を自分で担いたくない場合は、マネージド VPS が中間的な選択肢です。プロバイダーが合意した保守を担当しますが、root アクセスと管理範囲はプランによって異なります。DreamHost のマネージド VPS には root アクセスが含まれません。上の表では、2 GB のマネージド構成の例を 31.99 ドル、4 GB のアンマネージド構成の例を 11.99 ドルとしているため、同じ規模同士の比較ではありません。この差額により、夜間にサーバーが応答しなくなったときに、他者の対応を受けられます。

マネージド VPS とアンマネージド VPS の選択が当てはまる場合は、次に読むべき内容です。一方、すでに負荷の高い VPS を運用していて、ピーク時間帯の steal time も依然として大きい場合は、その次の選択肢として他の利用者がまったくいない専用サーバーがあります。

FAQ

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

必ずしもそうではありません。負荷の少ない共有サーバーのほうが、1 vCPU の VPS より単一の WordPress ページを高速に返すこともあります。割り当てられたメモリがあっても CPU の競合はなくなりません。共有 CPU の VPS では、近隣のインスタンスが応答時間に影響することがあります。また、メモリの保証内容はプロバイダーによって異なります。3am だけでなく 7pm にもページが遅い場合は、コード、データベースクエリ、ホスティングのリソース制限を確認してください。時刻だけでは原因を特定できません。

共有ホスティングで Node.js または Python アプリを実行できますか?

プロバイダーの制限内であれば、実行できる場合があります。一部のコントロールパネルでは、Passenger を通じてアプリケーションを起動できます。この場合、リクエストを受けたときにアプリケーションが実行されます。ホストが 80 番ポートと 443 番ポートを管理していても、他の許可されたリスナーまで妨げられるわけではありません。alwaysdata の Public Cloud では、IPv6 上の 8300 から 8499 ポートでカスタムサービスを利用できます。永続プロセスに関する規則もホストによって異なります。そのため、bot、キューワーカー、websocket サーバーには、それを明示的にサポートするプランが必要です。必ずしも VPS が必要とは限りません。

VPS の運用に Linux の知識は必要ですか?

unmanaged VPS では必要です。SSH key、ファイアウォール、更新、バックアップに加え、ログを読む習慣が必要です。初期設定には 1 時間、その後は毎月数分を見込んでください。それが自分で行いたい作業でない場合は、managed plan を選ぶことで、合意した保守作業をプロバイダーに任せられます。これは managed VPS と unmanaged VPS のホスティングの違いで説明するトレードオフです。

共有ホスティングから VPS へ移行するとき、サイトは停止しますか?

DNS TTL を短くし、両方のアカウントを稼働させておくと、停止を避けやすくなります。ただし、移行が完全にシームレスになるとは限りません。1 日前に TTL を 300 秒に設定し、以前の TTL が期限切れになるまで待ちます。次に、ファイルとデータベースをコピーし、ノートパソコンの hosts ファイルを使って新しいサーバーをテストしてから、A レコードを変更します。切り替え中は、一部の訪問者が旧サーバーに到達し、他の訪問者が新しいサーバーに到達します。また、キャッシュの更新には 5 分を超えることがあるため、共有アカウントは 1 週間維持してください。最終的なデータベースの dump と restore の間は書き込みを停止します。その後の書き込みが失われないように、旧サイトを読み取り専用にするか、旧サイトへのリクエストを新しいサーバーへ送信します。

この記事は役に立ちましたか?

#vps#shared-hosting#hosting-comparison#beginners