Webサイトの置き場所はどう変わったか — 共用サーバーからエッジ配信までの4つの転換点
Webサイトの置き場所は、共用サーバー・仮想サーバー・クラウド・エッジ配信と選択肢が増えてきました。ただし新しい層が古い層を置き換えたわけではありません。いま起きているのは、1つの基盤にすべてを載せる発想から、「静的ファイルの配信」「サーバーサイドの実行」「データの保管」を切り分け、それぞれに適した場所を選ぶ発想への移行です。各段階で何が解決され、何が新しい負担になったのかを順に整理し、最後に自社サイトの基盤を見直す手順にまとめます。
転換点1：共用サーバー — 運用をまとめて借りる
1台のサーバーを複数の契約者で分け合う形態です。OS、Webサーバー、PHP、メール、データベースまで事業者が用意し、利用者はFTPと管理画面だけを扱います。サーバーの保守を事業者に任せられることが最大の価値でした。
代償は構成の自由度です。ミドルウェアのバージョンは事業者が決め、同居するサイトの負荷の影響も受けます。処理能力を上げる手段は実質的に上位プランへの乗り換えしかありません。裏を返せば、更新頻度が低くPHP製のCMSを1サイト動かすだけなら、いまでも合理的な選択です。要件が小さいサイトを無理に新しい基盤へ移す必要はありません。
転換点2：仮想サーバー — 構成の自由と引き換えに運用責任を持つ
仮想化技術によって、物理サーバー1台を論理的に分割し、管理者権限付きのサーバーを安価に借りられるようになりました。Webサーバーの種類、言語のバージョン、キャッシュの構成を自分で決められます。共用サーバーでは不可能だった要件が実現できるようになった段階です。
同時に、OSのアップデート、TLS証明書の更新、監視、バックアップ、障害時の一次対応がすべて自分たちの仕事になりました。ここで実務に入り込んだのが「手で設定した内容をどう残すか」という課題です。構築した人しか中身を知らないサーバーは、担当者の異動と同時に触れない資産になります。この段階以降、構成を手順書ではなくコードとして残す運用が一般的になっていきました。
転換点3：クラウド — 選ばれている理由は安さではない
クラウドでは、サーバーもロードバランサーもストレージもAPIで調達でき、負荷に応じて増減できます。データベースやキャッシュはマネージドサービスとして借りられ、冗長化や自動バックアップが標準で付いてきます。
企業の利用は定着しました。総務省の令和7年通信利用動向調査（2026年5月公表、常用雇用者100人以上の企業が対象）では、クラウドサービスを一部でも利用している企業は83.5%、全社的に利用している企業は60.0%です。注目したいのは利用理由で、「場所、機器を選ばずに利用できるから」が50.7%、「安定運用、可用性が高くなるから」が45.1%と続く一方、「既存システムよりもコストが安いから」は19.4%にとどまります。前年からの伸びが最も大きかったのは「システムの拡張性が高いから」で6.8ポイント増でした。
この数字は、クラウドが安さではなく「変化に追従できること」で選ばれている実態を示しています。Webサイトでも同じで、キャンペーンや報道で一時的にアクセスが跳ねる、年度ごとにコンテンツ量が変わる、といった変動を吸収できることが価値になります。逆にトラフィックが安定している小規模サイトでは、クラウドに移しても請求額が下がるとは限りません。
運用の考え方も変わりました。壊れたサーバーを直すのではなく、同じ構成で作り直す。設定変更は本番サーバーへのログインではなく、コードの変更とデプロイで行う。この前提に合わせてデプロイの自動化とステージング環境の整備が必要になり、制作会社に求められる成果物も「動いているサーバー」から「再現できる構成」へ移りました。
転換点4：エッジ配信 — 配信と実行が分かれた
CDNによる静的ファイルのキャッシュ配信自体は以前からありました。転換点は、キャッシュだけでなくコードがネットワークの末端（エッジ）で動くようになったことです。Cloudflare Workersは、リクエストごとに仮想マシンを立ち上げるのではなく、既存の実行環境の中にisolate（分離された実行単位）を作る方式を採り、仮想マシンモデルのコールドスタートを取り除いています。
その代わりに制約があります。Vercelのドキュメントによれば、Edgeランタイムはファイルシステムの読み書きができず、Node.jsのAPIは一部しか使えません。evalのような動的なコード実行も禁止され、コードサイズの上限はgzip後でHobby 1MB、Pro 2MB、Enterprise 4MBです。重い画像処理やネイティブ依存を持つライブラリは、そもそも載りません。
したがってエッジに置くべきなのは、認証チェック、リダイレクト、地域や言語による出し分け、A/Bテストの振り分け、キャッシュ制御といった軽量で判断が中心の処理です。業務ロジックの本体やデータベースへの複数回アクセスは、別の場所に残すほうが素直です。
「ユーザーに近い＝速い」とは限らない
エッジ化が進んだ結果、近年は揺り戻しも起きています。実行場所の最適解はユーザーの近くとは限らない、という整理です。
Cloudflareのドキュメントは、WorkersやPages Functionsが既定ではリクエストを受け取った場所に最も近いデータセンターで動くと説明したうえで、バックエンドのデータベースやAPIへ何度も往復する処理では、バックエンドの近くで動かすほうが速くなると明記しています。設定としては、traffic を分析して自動配置するSmart Placementのほか、aws:us-east-1のようなクラウドリージョン指定、データベースホストやAPIのホスト名を指定して近い拠点に寄せる方法が用意されています。静的アセットは常にユーザー最寄りから配信される点も重要で、フロント側のWorkerとバックエンド側のWorkerを分け、Service bindingsでつなぐ構成が推奨されています。
Vercelはさらに明確で、公式ドキュメントはEdgeランタイムからNode.jsランタイムへの移行を推奨しており、両者とも同じFluid compute上で動くと説明しています。Next.js 16.3以降はruntime = 'edge'の指定自体がサポートされません。Fluid computeは2025年4月23日以降の新規プロジェクトで既定となり、インスタンスを使い回して複数のリクエストを同時に処理すること、waitUntilでレスポンス送出後にバックグラウンド処理を続けられること、アベイラビリティゾーンやリージョンをまたいでフェイルオーバーすることが特徴です。関数は既定で単一リージョン実行で、必要に応じてリージョンを指定します。
つまり現在の設計判断は「エッジか、サーバーか」ではありません。配信（静的アセットとキャッシュ）はユーザーの近くへ、実行はデータの近くへ、という二軸の配置問題になっています。
自社サイトに合う基盤を見直す手順
- ページを仕分ける。常に同じHTMLを返せるページと、ログインやパーソナライズでリクエストごとの生成が要るページを分け、前者の割合を数える。前者が大半なら、配信をCDNに寄せるだけで体感速度は改善します。
- データの所在を確認する。基幹システム、ヘッドレスCMS、社内APIがどこにあるかを書き出し、1リクエストあたり何回往復するかを数える。往復が多い処理は、ユーザー側ではなくデータ側に寄せる候補です。
- トラフィックの形を見る。国内中心で負荷が安定しているなら、エッジ実行による短縮幅は限定的です。海外からのアクセスや急激なスパイクがあるほど効果が出ます。
- 運用体制を確認する。OS更新と夜間障害の一次対応を誰が担うかを決められないなら、仮想サーバーの自前運用は避け、マネージドな選択肢に寄せます。
- 制約を洗い出す。データの保管場所に関する要件、既存のPHP資産、IP制限や専用線の有無は、技術的な最適解より優先されることがあります。
- 計測してから決める。TTFB、キャッシュヒット率、アプリ内のどの処理に時間を使っているかを実測し、ボトルネックが配信なのか実行なのかデータアクセスなのかを特定します。
移行する場合も、一度に全部を動かす必要はありません。影響が小さく効果が見えやすい順に、静的アセットの配信 → 表示が重いページのキャッシュと生成方法 → 書き込みを伴う処理、と段階を分けるのが安全です。各段階で計測値を残しておくと、次の投資判断の根拠になります。
まとめと相談先
置き場所の歴史は、運用を誰が持つか、構成をどこまで自分で決めるか、処理をどこで動かすかを分解してきた過程でした。いま検討すべきは「最新の基盤へ移るかどうか」ではなく、自社サイトのページ構成・データの所在・運用体制に照らして、配信と実行をそれぞれどこに置くかです。
現行サイトの構成を整理したうえで移行方針を決めたい、エッジ実行やマネージドな構成が自社の要件に合うか判断したい、といった段階でしたら、Webサイト制作・フロントエンド開発を行う chot Inc. のお問い合わせからご相談ください。
