WordPress ホスティングで実際に払っているもの

WordPress ホスティングは月額およそ 3 ポンドから数百ポンドまでという価格帯で売られていますが、その両端にあるプランはほとんど同じ言葉で自分を説明します。速い。安全。バックアップ済み。サポート付き。買い手が両者を見分けるために必要な仕様、つまりどの PHP ブランチでサイトが動くのか、その背後にどのデータベースエンジンがいるのか、キャッシュ層はいくつあって、そのうち実際に有効なのはどれなのかは、購入を求められるページにたいてい載っていません。

その欠落は商品の一部です。「マネージド」は技術的な区分ではなくマーケティング上の区分で、これを定義する標準化団体は存在しません。同じ言葉を使う 2 社が、永続オブジェクトキャッシュが動いているか、自前のキャッシュプラグインを使い続けてよいか、バックアップを相手のインフラの外へ持ち出せるか、そもそもシェルを開けるのかという点で食い違うことがあります。

以下は、そうしたページが省いている仕様です。WordPress が何を要求するのか、スタックのどの部分がページ速度を動かすのか、マネージドホスティングは何を足して何を静かに取り上げるのか、そして各ティアの現実的な月額です。

WordPress ホスティングで実際に何を買っているのでしょうか。 4 つです。WordPress 自身が公開している基準を満たす PHP バージョンとデータベースエンジン。自分で入れて調整せずに済むキャッシュ層。更新、ステージング、バックアップ、ファイアウォールといった運用作業。そしてキャッシュできないリクエストのための余力です。パンフレット型のサイトは 4 つ目をほとんど必要としません。ショップや会員サイトは予算の大半をそこに使います。

WordPress ホスティングは仕様ではなくカテゴリ名です

同じカテゴリの中にある価格差がその証拠です。どちらもマネージド WordPress ホスティングと名乗る 2 つのプランが月額 20 ポンドと 250 ポンドに並ぶことがあり、マーケティング文はその差を説明しません。差を作っているものが、その文章に出てこないからです。

安い側で買っているのは、PHP-FPM プールとページキャッシュとコントロールパネルが載った共有マシンの一区画です。高い側で買っているのは、隔離された計算資源、永続オブジェクトキャッシュ、ステージング環境、マネージドファイアウォール、あなたのエラーログを読んでくれるサポートチーム、そしてコア更新でテンプレートが壊れたときに契約上の責任を負う相手です。

どちらも正当な商品です。問題は、目の前にあるのがどちらなのかを買い手が見分けられないことで、結果として決定は価格と、アフィリエイト報酬の順に並ぶレビューサイトに委ねられます。行き着く先は両方向に予測がつきます。パンフレット型のサイトが一生使い切らない 150 ポンドのプランに載り、WooCommerce ストアが最初に混み合った土曜日の決済で倒れる 5 ポンドのプランに載ります。

抜け道は、ティア名ではなく 4 つの問いで買うことです。どの PHP ブランチか。どのキャッシュ層があるか。キャッシュできないリクエストをどれだけ吸収できるか。そして解約したときに自分のデータはどうなるか。

WordPress がサーバーに本当に要求するもの

WordPress は要件ページを公開していて、それは短く、だからこそ読み飛ばされます。これは購買仕様として読むべきです。ここで落ちるプランは、性能を論じる前に失格だからです。

PHP のバージョン

WordPress の要件ページは推奨基準を「PHP バージョン 8.3 以上」と記しています。同じページには、推奨よりも重い警告も並んでいます。WordPress は「PHP 7.4 以上と MySQL 5.5.5 以上でも動作しますが、これらのバージョンは公式にサポート終了を迎えており、サイトをセキュリティ脆弱性にさらす可能性があります」。

罠はこの一文に尽きます。WordPress は古い PHP ブランチで起動を拒否したりしません。動きますし、見た目も普通ですし、何年もセキュリティ修正を受けていないインタプリタの上に静かに座り続けます。

データベース

同じページは「MariaDB 10.11 以上または MySQL 8.0 以上」を求めています。古いエンジンでも動くので、これほど多くのサイトが古いままなのです。WordPress 自身の利用統計では、報告のあるインストールのおよそ 6 件に 1 件が MySQL 5.x 系を報告していて、示された下限を大きく下回ります。MySQL 5.7 だけで報告サイトのおよそ 12 パーセントを占めます。

結果はサイトが壊れることではありません。キャッシュしにくいワークロードにこそ効くエンジン側の改善を取り逃がし、どのみちいつかやることになる移行を抱え込む、ということです。

HTTPS と拡張モジュール

HTTPS は推奨ではなく「すべてのインストールで必須」と書かれています。2026 年になってもまだ証明書を有料オプション扱いしているホストは、プランの残りについても何かを語っています。

さらに WordPress ホスティングハンドブックは、json と mysqli を必須、curl、dom、exif、fileinfo、hash、igbinary、imagick、intl、mbstring、openssl、xml、zip を強く推奨としています。営業担当に名前を出す価値があるのは 2 つです。zip がなければ、プラグインとコアの更新パッケージを展開できません。imagick がなければ、メディアのアップロードは弱い画像ライブラリに落ち、最適化プラグインに触れる前の段階で画像の質が下がります。

PHP のバージョンは請求書で最も効く一行です

ホストが握るもののなかで、PHP ブランチは効果と手間の比が最も良いものです。たいていの管理画面ではドロップダウンです。何も作り直さず、何も移行せず、もともと互換性のあったサイトは、より速くよりサポートされたインタプリタの上でただ動き始めます。

それが何年も変わらない理由は技術ではなく組織にあります。誰も持ち主ではないのです。サイトを作った制作会社はもういないし、ホストは放置されたプラグインの致命的エラーが自社の責任になるので勝手には変えないし、事業側は見せられたこともない数字について考える理由がありません。

だから見込みホストへの最初の質問は速度についてではありません。そのプランが既定でどの PHP ブランチを動かすのか、どのブランチを提供しているのか、そしてチケットを開かずに自分で変更できるのか、です。WordPress がもう推奨していないブランチしか出さないホストは、それ以外の質問にも同時に答えています。

本番では切り替えず、ステージングで試すこと。PHP 7.4 から 8.3 へ移るサイトは、たいてい保守されていないプラグインから 2 つか 3 つの非推奨の警告を出しますし、そこが本当の費用です。半日から 1 日の開発工数を見込んでください。詳しくはWordPress 開発者の料金と確認すべきことで扱っています。

PHP 論争のセキュリティ側の半分

PHP を上げる理由として人が口にするのは性能です。しかし本当に効くのはセキュリティのほうで、しかもこちらは議論ではなく計測の対象です。

PHP は自らサポート対象バージョンの一覧を公開しています。各ブランチはアクティブサポートを 2 年、その後さらに 2 年のセキュリティ修正のみの期間を得ます。2026 年 9 月時点で、PHP 8.2 は 2026 年 12 月 31 日までセキュリティ修正のみ、PHP 8.3 は 2025 年 12 月 31 日にアクティブサポートを終えたあと 2027 年 12 月 31 日までセキュリティ修正のみです。PHP 8.4 は 2026 年 12 月 31 日までアクティブサポートが続き、セキュリティ修正は 2028 年 12 月 31 日まで、PHP 8.5 はアクティブサポートが 2027 年 12 月 31 日まで、セキュリティ修正が 2029 年 12 月 31 日までです。それより古いものは終わっています。PHP 8.1 は 2025 年 12 月 31 日、PHP 8.0 は 2023 年 11 月 26 日、PHP 7.4 は 2022 年 11 月 28 日に終了しました。

これを、WordPress サイトが実際に動かしているものと突き合わせてください。WordPress の統計ページは、インストールのおよそ 38.8 パーセントが完全にサポート終了したブランチの上にあり、およそ 23.2 パーセントがいまだに PHP 7.4 かそれ以前だと報告しています。WordPress が推奨する PHP 8.3 の基準を満たすのはおよそ 36.4 パーセントにとどまり、さらに 24.8 パーセントは今年の年末にセキュリティサポートを失う PHP 8.2 の上にいます。

つまり WordPress サイトの過半数は、セキュリティ修正を受けていないか、あと数か月でその状態になるインタプリタで動いていて、しかもほとんどの場合それは誰も見たことのないホスティングの設定項目です。直す費用はプラグインのライセンス代より安く、だからこそ当社の WordPress セキュリティ強化チェックリストはこれを最初の手順に置いています。

リクエストが出会う順に見るキャッシュ層

ホストが掲げる性能の主張はほぼすべてキャッシュについての主張で、そしてほぼすべての買い手はそれを一つの区別のない約束として受け取ります。層は 4 つあり、決まった順に並んでいて、それぞれ別の種類の仕事を省きます。以下の順序は 1 本のリクエストが通る順序で、手前の層が答えたリクエストは奥の層に届きません。

エッジ、つまり CDN キャッシュ

リクエストが最初に出会うのは、あなたのサーバーの外、訪問者に近い拠点のネットワークにあるキャッシュです。応答がすでにそこに置かれていれば、ホストはそのリクエストを一度も見ません。

この層は計算だけでなくネットワークの距離も省きます。マンチェスターの訪問者がロンドンのエッジに当たれば、大西洋を往復せずに済みます。静的ファイルにとってはほぼ無料で、常に持つ価値があります。HTML にとっては強力ですが条件付きで、どの応答が個人向けで共有してはいけないのかをエッジに教える必要があります。

フルページキャッシュ

2 つ目の層は、完成した HTML を保存して PHP とデータベースを二度と走らせないようにします。WordPress ホスティングハンドブックは NGINX や Varnish のようなリバースプロキシを勧め、それは「出力をサーバーのメモリまたはハードディスクへ直接保存する」と説明したうえで、この層が機能するかどうかを決める規則を添えています。「ログイン中のユーザーはすべてキャッシュから除外するのがよい。彼らはパーソナライズされた内容を見るはずだからだ」。

安いホスティングをよく見せるのがこの層です。うまく働いているとき、訪問者にはファイルが返され、PHP のバージョンもデータベースエンジンもプラグインの数も、そのリクエストに関しては意味を失います。どれ一つ実行されないからです。

オブジェクトキャッシュ

3 つ目の層は、個々のデータベースクエリの結果や計算済みの値をキャッシュします。WordPress はこれを既定で備えていますが、永続的ではありません。WP_Object_Cache のドキュメントは明確です。「既定ではオブジェクトキャッシュは非永続である。つまりキャッシュに保存されたデータはメモリ上にのみ、しかもそのリクエストの間だけ存在する」。

永続化するとは、ドロップインを介して Redis や Memcached を背後に置くことで、ページ読み込みのたびに作り直されるキャッシュを、リクエストと訪問者をまたいで共有されるキャッシュに変えます。ページ全体をキャッシュできなくなったときに効いてくる層であり、安いプランで最も欠けている層でもあります。

オペコードキャッシュ

4 つ目の層は OPcache で、PHP ファイルをコンパイルしたバイトコードを共有メモリに置き、リクエストのたびに解析とコンパイルをやり直さずに済ませます。ハンドブックは「本番の WordPress 環境では、ウェブリクエストに対して OPcache を有効にし、サイトやホスティング基盤に合わせてサイズを設定することを推奨する」と述べています。

ここには配信上の帰結があります。OPcache はコンパイル済みコードを保持するので、デプロイのたびにリセットするか変更されたファイルを無効化しなければ、サーバーは前のバージョンを動かし続けます。OPcache がどう無効化されるのか答えられないホストは、プラグインを更新しても数分間なにも起きないように見えるホストです。

パンフレット型サイトがほぼどのホストでも速い理由

4 つの層をたどると、ホスティング業界にとって居心地の悪い結論に着きます。訪問者が全員匿名で、全ページがキャッシュ可能なら、フルページキャッシュがほぼすべてのトラフィックに答え、その後ろにあるマシンの仕様はほとんど関係しなくなります。

だから、まともなページキャッシュを積んだ 4 ポンドのプランに載る 5 ページの会社サイトが、200 ポンドのプランに載る肥大したサイトより良いサーバー応答時間を出せるのです。安いほうはファイルを配っていて、高いほうは PHP を走らせています。

見るべき数字は最初のバイトまでの時間で、これ自体は Core Web Vitals ではありません。Google の Web Vitals 概説はこれを補助指標に分類し、サーバー応答の遅さに由来する「LCP の問題を診断する」のに役立つとしています。それこそがホストの支配下にあるページ速度の一部です。

WordPress もほぼ同じ考えで、それをコアに書き込みました。WordPress 6.1 で加わった Site Health のフルページキャッシュ検査は「サイトがフルページキャッシュを使っているか、そして応答時間が許容範囲かどうか」を調べ、既定のしきい値は 600 ミリ秒です。ページキャッシュが有効なはずなのにそれを超えるなら、キャッシュは働いておらず、CPU を足しても隠せません。

ですからパンフレット型のサイトにとって、ホスティングの格上げはたいてい間違った買い物です。遅さの原因はむしろ、大きすぎるヒーロー画像、数百キロバイトの CSS を送り出すページビルダー、6 種類のフォントウェイトで、これはElementor とカスタムテーマの比較で述べた通りです。

ログイン済みトラフィックと WooCommerce がモデルを壊す

ここまでの話は、ページキャッシュが答えられることを前提にしています。訪問者がログインした瞬間にその前提は崩れ、ホスティングの経済も反転します。

WooCommerce はこれを明示しています。そのキャッシュに関する指針は、カート、マイアカウント、決済をページキャッシュから除外するよう指示します。これらのページは「現在の顧客とそのカートに固有の情報を表示するので、動的なままである必要がある」からです。さらにキャッシュを迂回させるべき Cookie として woocommerce_cart_hash、woocommerce_items_in_cart、wp_woocommerce_session_ を挙げ、データベースキャッシュからは _wc_session_ を除外するよう勧めています。

これをホスティング仕様として読むと、身も蓋もないことを言っています。ショップでは、売上を生むページが、まさにページキャッシュの触れないページなのです。カタログと商品ページは匿名の閲覧者向けにキャッシュできます。カートと決済は、誰に対しても、決してできません。

会員サイト、学習プラットフォーム、フォーラム、顧客ポータルを持つあらゆるサイトでも同じです。セッション Cookie がひとたび設定されると、多くのキャッシュプラグインはその訪問者にキャッシュ済み HTML を返すのをやめるので、クリックのたびに PHP が走りデータベースが叩かれます。ここでオブジェクトキャッシュは最適化ではなく構造材になり、安いプランが、合成的なトップページ計測では決して見えない形で痛みます。詳しくはWooCommerce ストアが遅い理由をご覧ください。

マネージド WordPress ホスティングに実際に含まれるもの

形容詞を剥がすと、マネージドホスティングはかなり一貫した運用作業の束に落ち着きます。その作業を正直に値付けする価値はあります。技術者のいない事業にとっては、自前でやるより買ったほうが安いことが多いからです。

更新

マネージドのプランはたいていコアの更新を自動で当て、プラグインの更新まで面倒を見ることもあり、ときには前後で視覚的な回帰チェックまで行います。ここで知っておくと役に立つのは、WordPress がすでに無料でやっている範囲です。

WordPress は何年も前からマイナーなコアリリースと翻訳ファイルを既定で自動更新していますし、5.6 以降は新規インストールで自動更新が有効になっていて、バージョン管理下のチェックアウトが検出されない限りマイナーとメジャーの両方が対象です。既存のインストールは以前の挙動のままです。ですから有料の部分はコアのマイナー更新ではありません。プラグインの更新と、壊れたときの切り戻しと、壊れたことに気づく人です。

ステージングとバックアップ

ワンクリックのステージング環境は本当に価値があり、自分で作るのは本当に面倒です。あるかないかではなく 2 点で判断してください。ステージングを本番へ戻すときに本番のデータベースを上書きするのかどうか。上書きするなら、コピー以降に入った注文やコメントは消えます。そしてステージングサイトが検索エンジンから遮断され、メール送信も止められているかどうかです。

ファイアウォールとマルウェアスキャン

マネージドのプランの多くは、エッジのウェブアプリケーションファイアウォールと何らかのマルウェアスキャンを含みます。ファイアウォールは実際に価値があります。ネットワーク層での仮想パッチが、プラグインの脆弱性が公表されてからあなたが更新するまでの時間を稼いでくれるからです。

スキャンは響きほど強くありません。たいていは既知の悪性ファイルの署名を検出するもので、つまり出来合いの感染は捕まえ、狙い撃ちの侵入は取り逃がします。錠前ではなく煙感知器として扱い、堅牢化の作業は自分の側に残してください。

マネージドホスティングが取り上げるもの

制約は誰も読まない側の半分で、たいてい機能よりも影響が大きいものです。制約には筋の通った理由がありますが、その理由はあなたのものではなく提供者のものです。

公開されている最も明快な例は WP Engine の禁止プラグイン一覧で、個々の悪者ではなくカテゴリごと禁じています。キャッシュプラグインは「当社基盤に組み込まれたキャッシュ構造と競合しうる」ので禁止です。バックアップ系のプラグインは「サイトを無用に肥大させる」という理由で禁止です。関連記事系のプラグインは「きわめてデータベース負荷が高い」として禁止です。既知の脆弱性を抱えるプラグインは全面禁止で、基盤の機能と重複するプラグインも同様です。

一つひとつは妥当な技術判断です。しかし全体としては、あなたのサイトが思っていたほど可搬ではないという意味になります。特定のキャッシュプラグインの設定に構成が依存しているなら、その設定はあなたと一緒には動きません。

シェルアクセスも、よく欠けているものです。マネージドのプランには SSH をまったく提供しないものや、WP-CLI のない制限付きシェルしか提供しないものが少なくなく、ドメイン変更後の一括置換のような定型作業がサポートチケットに変わります。ほかに 2 つ、人が引っかかる点があります。長時間動くプロセスに上限が設けられていることが多く、50,000 点の商品のインポートは分割しなければなりません。そして送信メールは、乗っ取られたサイトが迷惑メールに使われるという前提で、遮断または流量制限されていることがよくあります。

テストに耐えない性能の主張

ホスティングのマーケティングは、何を測ったのかと問うた瞬間に崩れる少数の主張で回っています。

「20 倍速い」はほぼ必ず比較対象を明かしません。何より速いのか。どのページで。どのプラグイン構成で。どれだけの同時実行のもとで。この 4 つがなければ、その数字は名前のない 2 つの量の比にすぎません。

「無制限の帯域」は、同じ表の中で月間訪問数の上限の隣に座っています。そもそも WordPress サイトの制約が帯域であることはめったにありません。制約は PHP の同時実行数で、それはたいていプランに書かれていません。

「稼働率 99.9 パーセント」は絶対的に聞こえますが、そうではありません。30 日の月なら約 43 分の停止を許します。九が 3 つは共有ホスティングでは普通の水準で、九が 4 つなら月に約 4 分、その差は不便と誰も気づかない障害との差です。約束が守られなかったときにクレジットが実際にいくら払うのかを読んでください。これは意味のある稼働率 SLAで別に扱いました。

最後の主張が最もよくあり、最も誤解を招きます。キャッシュ済みのトップページで撮った速度計測のスクリーンショットです。それが測っているのはページキャッシュであってホストではなく、しかもページキャッシュはどこでもだいたい同じ部品です。

ホストを正しくテストする方法

ホスティングのテストは難しくありませんが、サーバーを実際に働かせる経路でやる必要があります。順に 5 つです。

1 つ目、キャッシュされない経路をテストします。一意のクエリ文字列を付けてページキャッシュを外すか、カートやアカウントのような決してキャッシュされないページを要求します。PHP を走らせるリクエストを作れないなら、あなたが測っているのはファイルサーバーです。

2 つ目、それを繰り返します。1 回のリクエストはばらつきについて何も語らず、そのばらつきこそ安いホスティングの正体が出るところです。少なくとも 20 回のサンプルを取り、Google がフィールドデータで使う統計値である 75 パーセンタイルを読んでください。

3 つ目、訪問者のいる場所からテストします。サーバーの隣のデータセンターで測った応答は、リーズにいる顧客が受け取る応答ではありません。

4 つ目、同時実行のもとでテストします。キャッシュ不能なリクエストを 10 本か 20 本同時に流します。PHP ワーカーの枯渇を明らかにする唯一のテストがこれで、そしてワーカーの枯渇こそ、販促の最中にストアを落とすものです。

5 つ目、条件をそろえて比べます。同じ PHP ブランチ、同じプラグイン構成、同じテーマ、同じコンテンツ量です。ホストと同時にプラグイン構成まで変えた移行は、どちらについても何も証明していません。候補のホストではなく実在のサイトに対してこれを走らせたいなら、それがWordPress パフォーマンス監査の仕事です。

ホスティングが実際に動かす Core Web Vitals はどれか

Core Web Vitals は、ホスティングの主張と検索順位が混同されやすい場所なので、サーバーがどの指標に影響できるのかを正確にしておく価値があります。

指標は 3 つあり、ページ読み込みの 75 パーセンタイルで評価され、モバイルとデスクトップで分けられます。Largest Contentful Paint は読み込みを測り、2.5 秒以下で良好、2.5 秒から 4.0 秒で要改善、4.0 秒を超えると不良です。Interaction to Next Paint は応答性を測り、200 ミリ秒以下で良好、500 ミリ秒までが要改善、それを超えると不良です。Cumulative Layout Shift は視覚的な安定性を測り、0.1 以下で良好、0.25 までが要改善、それを超えると不良です。First Input Delay は廃止されて INP に置き換わり、INP は 2024 年に正式な Core Web Vital になりました。

ホスティングが直接動かせるのはこのうち 1 つだけです。サーバー応答時間は LCP の一部なので、そこから 400 ミリ秒を削るホストは、すべての訪問者の LCP から 400 ミリ秒を削ります。遅いホストでは、それが合格と不合格の差になりえます。

CLS にはほとんど効きません。あれは寸法のない画像と遅れて読み込まれるフォントから生まれます。INP にもごくわずかしか効きません。あれはメインスレッド上の JavaScript に支配されています。規則はこうです。LCP が不良で、キャッシュされない応答が WordPress の示す 600 ミリ秒の線を超えているなら、ホスティングは問題の一部です。応答に余裕があるのに LCP がまだ不良なら、原因はページの中にあり、当社の2026 年に Core Web Vitals を通す方法のほうが予算の使いどころとして適切です。

バックアップと、誰も確かめない部分

いちばん安いプランを除けば、どのプランもバックアップを宣伝します。しかし、そのバックアップに価値があるかどうかを決める問いを、買う側はほとんど誰も尋ねません。

誰かが一度でも復元したことがあるか

NCSC は小規模組織向けの手引きではっきり述べています。バックアップを取ったら「それをどう復元するかを知っておくこと、そして重要なデータがすべて含まれているかを確認することが大切だ」。試していないバックアップは統制ではなく信念です。

復元をどう始めるのか、あなたの規模のサイトでどれくらい時間がかかるのか、データベースを戻すとアップロードのディレクトリも戻るのかを提供者に尋ねてください。そして必要になる前に、ステージングで一度やっておくことです。探すべき失敗の形は、ファイルは戻るがデータベースは戻らない復元か、成功したように見えてコピー以降に作られたものを静かに失う復元です。

保持期間と頻度

7 日保持の日次バックアップは、WordPress サイトが実際にどう壊れるかを考えるまでは十分に見えます。改ざんされたサイトは数時間で気づかれます。古い記事に迷惑リンクを静かに注入する侵害は数週間かかり、そのころには残っているコピーのすべてに注入が含まれています。

商用のものなら 30 日がより実用的な下限で、月次の別コピーは安い保険です。ストアではさらに、注文量に見合ったデータベースのバックアップ間隔が要ります。4 時間分の注文を失うことは、4 時間分のブログ編集を失うのとは問題の種類が違うからです。

コピーの置き場所と形式

NCSC のもう一つの指摘は、稼働中のシステムにつながったままのバックアップは分離されていない、というものです。バックアップを保持する装置は「使っていないときは端末につないだままにしないこと」で、元を侵すものはそこにも届くからです。ホスティングに当てはめれば、同じアカウントに保存され同じ管理画面からしか復元できないバックアップは、守るはずの対象と運命を共にします。

形式は同じ問題のもう少し見えにくい版です。バックアップを読む唯一の方法が提供者の復元ボタンなら、それは可搬なコピーではなく便利機能です。判定基準は、素の SQL ダンプとファイルのアーカイブを今日ダウンロードでき、まともな開発者ならどこででも立ち上げられるかどうかです。できないなら、移行は技術的な決定であることをやめて交渉になります。

データがどこにあるか、そして英国の買い手になぜ重要か

ホスティングの決定はデータ保護の決定でもあり、英国の事業にとっての問いは会社がどこで登記されているかではなく、個人データがどこに置かれ誰が手を伸ばせるかです。

ICO の国際移転の手引きは 3 段階の判定を示しています。あなたの処理に英国 GDPR が適用され、移転を始めるのがあなたであり、受け取る組織が別の法人であるなら、それは制限付き移転です。ICO は規則が「すべての制限付き移転に適用され、小規模で頻度の低いものも含む」と明言し、「個人事業主や自営業者を含む」個人データを扱うあらゆる組織を対象にすると述べています。

何が移転にあたるかにも注意してください。ICO は個人データを送ることだけでなく、英国外の組織がそれに「アクセスできるようにすること」も含めています。海外のサポートチームがあなたの管理画面に入れることも、別のリージョンへ複製されたオフサイトのバックアップも、それぞれこの定義を満たしえます。

すべての制限付き移転は 3 つのいずれかで覆われていなければなりません。移転先についての英国の十分性規則、国際データ移転契約や付属書や拘束的企業準則といった適切な保護措置、または例外です。保護措置に頼る場合、ICO は移転後も保護が実質的に下がらないことを示す移転リスク評価も求めます。これらは海外のホストを使えなくする話ではありません。文書化が必要な決定になる、という話であり、文書化は移転してからでも情報開示請求の最中でもなく、移転する前のほうがはるかに安く済みます。

処理者契約に書かれているべきこと

ホストは処理者で、あなたは管理者ですから、書面の契約は任意ではありません。ICO は契約に含めるべき事項を列挙していて、そのうち 4 つはそのままホスティングへの質問として読めます。

まず再委託先です。第 28 条 (3)(d) により、処理者はあなたの承認なく別の処理者を使ってはならず、変更の予定を知らせて異議を述べる機会を与えなければならず、連鎖の先にも同等の義務を課さなければなりません。ホスティングで言えば、CDN、バックアップの保存先、メールのリレー、基盤となるクラウド事業者のことです。一覧を求めてください。

次に安全性です。第 28 条 (3)(c) は第 32 条を満たす措置を要求し、ICO はその中身をこう説明します。暗号化と仮名化、処理システムの回復力、「インシデントの際に個人データへのアクセスを復旧できる能力」、そして「措置の有効性を定期的に試験し評価するプロセス」です。これは復元テストが、ベストプラクティスの記事ではなく法に書き込まれているということです。

3 つ目は出口です。第 28 条 (3)(g) により、処理者は契約の終了時にあなたの選択に従ってすべての個人データを削除するか返却し、既存の複製を削除しなければなりません。バックアップを自社基盤の外へ出せない提供者は、実務上の問題だけでなく契約上の問題も抱えています。4 つ目は監査で、第 28 条 (3)(h) により、遵守を示すために必要な情報と、認証や報告書の提供を受ける権利があります。

ティアと、英国での費用

ほぼすべての WordPress サイトは 4 つのティアで説明でき、その境界はトラフィックではなくキャッシュ不能な負荷で決まります。下の帯は英国の買い手が月にたいてい払う額です。特定ベンダーの価格表ではなくカテゴリの目安なので、見積もりそのものではなく見積もりの妥当性を確かめる物差しとして使ってください。

共有ホスティング、月額 3 ポンドから 15 ポンド

キャッシュ可能なパンフレット型サイトには申し分なく、誰かがログインするなら本当に割の悪い買い物です。PHP の容量を見えない隣人と分け合うので、効いてくるのは平均ではなく負荷時のばらつきです。まず PHP ブランチを確認してください。サポート終了のインタプリタが集中しているのはこのティアです。

マネージド WordPress、月額 20 ポンドから 400 ポンド

コンテンツサイトと小規模ショップにとって正しい既定です。買っているのは更新、ステージング、ファイアウォール、永続オブジェクトキャッシュ、そしてサポートチームで、その代金として上に挙げた制約を受け入れます。20 ポンドから 100 ポンドの帯は、そこそこのトラフィックの 1 サイトを賄います。それ以上は、たいていサイト数か訪問数か PHP ワーカー数のための支払いです。

VPS またはクラウドで自前スタック、15 ポンドから 120 ポンドに運用費

そこそこのクラウドインスタンスは月に 15 ポンドから 120 ポンドですが、安いのはマシンのほうです。誰かが OS にパッチを当て、リバースプロキシを調整し、オブジェクトキャッシュを運用し、バックアップを扱わねばならず、それを買うとさらに月 150 ポンドから 600 ポンドかかります。キャッシュ不能な負荷が現実にあるとき、あるいはマネージド基盤が禁じる要件がスタックにあるときに価値があります。

専用インフラ、月額 400 ポンド以上

マルチリージョンの配置、高い同時実行が起きるイベント、厳しいデータ所在地の要件、あるいは WordPress が複数の構成要素のうちの一つでしかない設計です。ホスティングは商品選びであることをやめて構築の一部になり、それは当社がウェブサイト開発の仕事の中で扱う考え方です。

ページビューではなくキャッシュ不能リクエストで見積もる

ホスティングのプランが月間訪問数で売られるのは、それが買い手に馴染みのある数字だからです。容量計画にはほとんど役に立ちません。キャッシュ済みの匿名ページビューが 10 万回あってもほぼ費用はかからず、ログイン済みのものが 1 万回あれば小さなサーバーを飽和させうるからです。

意味のある数字は同時のキャッシュ不能リクエスト数で、計算は単純です。1 つの PHP ワーカーは一度に 1 本のキャッシュ不能リクエストを扱います。必要なワーカー数はおおよそ、ピーク時の毎秒キャッシュ不能リクエスト数に、平均 PHP 応答時間を秒で表した値を掛けたものです。毎秒 20 本のキャッシュ不能リクエストがそれぞれ 400 ミリ秒なら、追いつくのに約 8 ワーカーが要り、その半分以上を余力として上乗せしておきたいところです。

ですからプランのページが答えていない 2 つの問いを投げてください。このプランはいくつの PHP ワーカーを動かすのか、そしてプロセスあたりのメモリ上限はいくつか。どちらの数字も存在しますが、たいてい公開されていません。直接尋ねれば普通は答えてくれますし、その答えはページに並んだどのベンチマークよりもプランについて多くを語ります。

そのうえで自分の側も正直に見積もってください。ログイン済みのセッションの割合、平均ではなく最も混む 1 時間の決済とアカウントのトラフィック、そしてプラグインが裏で発生させる admin-ajax や REST のトラフィックです。最後のものは解析ツールには映らず、サーバーログにはよく映ります。

プラグイン数と編集量はホスティングの決定です

サイトの内側にある 2 つのものが、必要なホスティングの量を決めます。そしてどちらもたいてい、請求書を見ることのない人が下すコンテンツ上の決定として扱われています。

1 つ目はプラグイン構成です。有効なプラグインはどれも、リクエストのたびに読み込まれる自動読み込みオプションと、WordPress の cron が本物の cron ではないために訪問者のリクエストで発火する予約イベントと、ページ生成あたりのクエリを増やします。キャッシュされたパンフレット型サイトなら 30 個のプラグインでも生きていけます。何もキャッシュされないショップでの 30 個は、決済の各段階で 30 個が実行されるという意味です。WordPress のコアはこれがいつ効き始めるかについて大まかな見解を持っていて、永続オブジェクトキャッシュの Site Health 検査は、投稿 2,000 件、ユーザー 2,000 人、自動読み込みオプション 600 件といった水準を超えたらオブジェクトキャッシュを使うよう促します。

2 つ目は編集量です。リビジョンは既定で上限なく積み上がり、メディアライブラリはそれぞれ複数の生成サイズを持つ数万のファイルへ育ち、どちらもデータベースとバックアップの所要時間を膨らませます。5 年間毎日公開してきたサイトは、同じデザインで月に一度公開するサイトとは物理的に別のホスティング問題で、それはプランのページのどこにも反映されません。プランではなく構築物を調べることこそ、WordPress 開発者が移行を見積もる前にやるべきことです。

選ぶ順序

この順番で進めれば、決定はたいてい自ずと決まります。トラフィックのうちキャッシュできない割合を確かめてください。その一つの数字がティアを決めます。PHP ブランチとデータベースのバージョンが公開された基準を満たすか確認してください。ここで落ちるプランは価格に関係なく失格です。どのキャッシュ層が含まれ、どれを自分で用意するのかを確かめてください。バックアップがどこにどんな形式で置かれ、今日 1 本ダウンロードできるかを尋ねてください。そのうえで処理者としての条項を、再委託先、データの所在、契約終了時の削除について読んでください。価格に意味が出てくるのはそのあとです。それまで比べているのは、同じ商品ですらないものだからです。

Mecanik はこれを、移行の前に行う定額の作業として、たいていはウェブサイト開発の案件と並行して実施し、その後はWordPress 開発者の代行のサービスとして継続的に引き受けます。プラットフォーム自体がどこへ向かっているのかを検討しているなら、WordPress 7.0 とコアに入る AI クライアントについての記事が、この記事のよい相棒になります。

よくある質問

英国で WordPress ホスティングはいくらかかりますか。 ほぼすべては、トラフィックのどれだけをキャッシュできるかで決まります。匿名の訪問者だけのパンフレット型サイトなら、共有ホスティングの月額 3 ポンドから 15 ポンドで十分です。コンテンツサイトや小規模ショップはたいていマネージド WordPress ホスティングの月額 20 ポンドから 100 ポンドが妥当で、繁忙またはマルチサイトのプランでは 100 ポンドから 400 ポンドに上がります。ログイン済みトラフィックの多いストアや会員サイトは、通常マシンに 15 ポンドから 120 ポンドの VPS またはクラウドスタックが必要で、運用を任せるなら月に 150 ポンドから 600 ポンドが加わります。

マネージド WordPress ホスティングは追加の費用に見合いますか。 運用担当がいないなら見合います。更新、ステージング、バックアップ、ファイアウォール、そして本来なら自分で設定する永続オブジェクトキャッシュを買っているからです。代償は本物の制約です。提供者はキャッシュプラグイン、バックアップ系プラグイン、データベース負荷の高いプラグインを日常的に禁じ、シェルアクセスを与えず、長時間動くプロセスに上限を設け、送信メールを遮断することがよくあります。契約してからではなく、契約する前に自分の構成と照らしてください。

2026 年に WordPress はどの PHP バージョンを必要としますか。 WordPress は PHP 8.3 以上を推奨しています。PHP 7.4 以上でも動きますが、それらのブランチはサポート終了でセキュリティ修正を受けません。PHP 8.1 は 2025 年 12 月 31 日、PHP 8.0 は 2023 年 11 月 26 日、PHP 7.4 は 2022 年 11 月 28 日に終了し、PHP 8.2 は 2026 年 12 月 31 日までセキュリティ修正のみの状態です。WordPress インストールのおよそ 38.8 パーセントは、いまも完全にサポート終了したブランチを報告しています。

ホスティングを良くすると Core Web Vitals は改善しますか。 3 つのうち 1 つだけ、しかも間接的にです。サーバー応答時間は Largest Contentful Paint の一部なので、速いホストはすべての訪問者の LCP を下げます。Cumulative Layout Shift にはほとんど効きません。あれは寸法のない画像と遅れて読み込まれるフォントから生まれます。Interaction to Next Paint にもごくわずかしか効きません。あれはメインスレッド上の JavaScript に支配されています。サーバー応答にすでに余裕があるなら、残る問題はページの中にあります。

速いと書かれたプランなのに WooCommerce ストアが遅いのはなぜですか。 大事なページがキャッシュできないからです。WooCommerce はカート、マイアカウント、決済が動的であることを求め、ログイン中の買い物客に対してはページキャッシュを迂回するセッション Cookie を設定します。トップページの速度計測が測っているのはキャッシュ済みのファイルで、その間に決済はリクエストごとに PHP を走らせデータベースを叩いています。ストアが本当に買っているのは、キャッシュ済みトップページの数字ではなく、キャッシュ不能なリクエストのための容量です。