問題は性能ではなく責任の空白から始まる
サイトは開くのに決済だけ失敗し、HostはServerが正常と答えます。Plugin更新後に管理画面が壊れても、誰が前のバージョンに戻すか決まっていません。Backup画面には毎日の成功記録があるのに、復元した人はいません。こうした問題は製品の性能より責任の空白から始まることが多いものです。
管理型WordPressホスティングはServerとPlatformの運用負担を減らしますが、Plugin・Theme・Custom Codeや事業機能までHostがすべて責任を負う意味ではありません。VMの自主管理では統制が広がる一方、Guest OSからPHP・DB・WordPress・Backup・Monitoringまで大半を直接担います。管理型インフラは一部を外部に任せられますが、契約にないApplication業務が自動で含まれるわけではありません。
月額Server料金より、Core・Runtime・Database・Plugin・Code・Backup・Restore・Security・Monitoring・Incidentを誰が実行し、最終判断し、支援外の問題を引き継ぐかでモデルを選びます。
「管理型」は一つの責任標準ではない
管理型ホスティングは、更新・Backup・Security・性能をすべて任せられると説明されがちですが、実際の製品はそれほど単純ではありません。
WP EngineはPlatform機能と基本的なWordPress構成を支援する一方、Plugin・Themeの機能バグ、CoreとCustom Codeの競合、Custom Code自体を支援外と明記しています。自動更新と視覚回帰を行うSmart Plugin Managerも、Planにより別購入または特定製品への同梱です。
KinstaはPHP RuntimeとHosting Stackを管理し、PHPのサポート終了時に自動移行します。ただし変更前にTheme・Plugin・Custom Codeの互換性を確認し、Stagingで試験するよう案内しています。Plugin・Themeの自動更新と視覚回帰も別Add-onです。
CloudwaysはOSパッチ、セキュリティ更新、Firewall、Machine OrchestrationをManaged Serverの範囲としています。Application Supportはドメイン接続、Backup・Restore、SSL、基本設定などに分かれ、Core・Plugin・Theme更新の自動化はSafeUpdatesという別機能です。
同じ「管理型」でも実際の責任範囲は違います。製品名よりSupport Scope、Exclusion、Add-on、Incident Escalationを先に読む理由です。
監視から復旧・改善までつながる運用 — サービス指標とアラートを基準に対応し、変更履歴と事後報告を次の改善につなげます。
WordPress運用を4つの責任層に分ける
WordPressを一つのプログラムとして見ると責任が混ざります。運用契約では少なくとも4層を分けます。
Hostが第1・第2層を管理しても、第3層の事業機能を自動的に保証するわけではありません。ServerがHTTP 200を返しても、決済Callback、予約確定、会員登録、管理者Workflowは失敗し得ます。
Site HealthはPHPバージョン、Plugin・Theme状態、設定問題を診断する有用な内部ツールです。[7] ただし外部ユーザーがログイン・決済・問い合わせ送信に成功するかは、この機能だけでは確認できません。これは公式の診断範囲とユーザージャーニー監視の違いから導く運用上の判断です。
- Infrastructure
- Compute、Storage、Network、OS、Firewallを含みます。障害時にサーバーとネットワークが正常かを問う層です。
- Runtime & WordPress Platform
- Web Server、PHP、Database Engine、WordPress Core、Cache、Cronを含みます。WordPressが実行可能かを問う層です。
- Application & Business Function
- Plugin、Theme、MU Plugin、Custom Code、決済・会員・フォーム・外部APIを含みます。ユーザーが実際の業務を完了できるかを問う層です。
- Recovery & Governance
- Backup Policy、Restore Test、Incident Command、顧客告知、復旧承認を含みます。誰が影響を判断し、復旧完了を承認するかを問う層です。
3つの運用モデルを同じ基準で定義する
この記事では記載の3モデルを比較します。Self-managed VMについては、AWSのShared Responsibility Modelも、EC2顧客がGuest OSの更新・セキュリティパッチとApplication Softwareを管理すると区分しています。
Managed InfrastructureはWordPress保守を契約に明記すれば範囲を広げられます。逆にServer管理だけならCore・Plugin UpdateやApplication Incidentが含まれない可能性が高くなります。
- Managed WordPress Hosting
- WordPress向けRuntime、Cache、Backup、Security、Staging、Supportを一つのPlatform製品で提供します。通常Root権限とServer設定の自由度は制限され、禁止Pluginや固有の制約がある場合があります。
- Self-managed VM / Server
- CloudやHosting Providerが物理基盤と仮想化層を運用し、利用者がGuest OSからWeb Server・PHP・Database・WordPress・Applicationまで直接運用します。自動パッチやControl Panelを入れても最終運用責任はProviderへ移りません。
- Managed Infrastructure
- 特定製品名ではなく契約型の運用モデルです。Server・OS・Runtime・Database Engine・Backup実行・基盤監視・一次障害対応を内部Platform Teamや外部Operatorに任せ、Plugin・Theme・Custom Codeと事業機能は別のWordPress Application Ownerが担当します。
19の責任軸：Softwareと変更
ここから3つの表は、19の責任軸を3モデルに当てた一般的な基本モデルです。実際の契約とPlanのSupport Scopeが優先します。最初はSoftwareと変更の6軸です。
WordPressはCore・Plugin・Themeを最新に保つよう勧め、Plugin・Theme別の自動更新を提供しています。[2] ただし自動実行と変更後の機能検証は別の責任です。PHP移行も同じで、事前にPlugin・Theme互換性を確認するよう案内しています。[8] 主要HostもCore更新、Plugin更新、Custom Code支援を別範囲にしています。
責任の軸 | Managed WordPress Hosting | Self-managed VM / Server | Managed Infrastructure |
|---|---|---|---|
| WordPress Core | Hostが自動更新や配布日程を管理する場合があります。Plugin・Theme・Custom Codeの互換性承認はサイト所有者に残ります。 | インストール、更新、緊急セキュリティパッチ、失敗時の復旧をすべて担当します。 | 基本はApplication Ownerの責任です。契約にWordPress運用が含まれる場合はOperatorが実行します。 |
| PHP / Runtime | Hostが提供バージョンとEOL移行を管理します。Applicationの互換性試験は顧客・開発者の責任です。 | PHP、Web Server、Extension、Process Managerのパッチと設定を直接管理します。 | Operatorがパッチと設定を実施し、Application Ownerが互換性を承認します。 |
| Database | HostがEngineを運用しても、Schema、Query、Plugin Table、データ整合性はApplicationの責任です。 | Engine、Backup、権限、性能、Schema、データ整合性をすべて直接管理します。 | 通常、OperatorがEngine・Backup、Application OwnerがSchema・Query・データを担当します。 |
| Plugin / Theme | 基本的に顧客責任の場合が多く、自動更新や回帰検査は別機能の場合があります。 | 選択・License・Update・Compatibility・Rollbackをすべて担当します。 | 別途WordPress保守契約がなければApplication Ownerの責任です。 |
| Custom Code | ほぼ常に顧客・開発者の責任です。Hostの支援はLogやServer-sideの原因確認までの場合があります。 | 全面的に内部の開発・運用責任です。 | Application Ownerの責任です。OperatorはRuntime・Log・デプロイ環境を支援します。 |
| Deployment | Staging・Backup・配布ツールがあっても、変更承認と機能検証はサイト所有者の責任です。 | Pipeline、Credential、Artifact、承認、Rollbackを直接設計します。 | Operatorが配布基盤を管理し、Application OwnerがRelease内容と機能検証を担当します。 |
19の責任軸：保護と運用
第2表はBackup、Restore Test、Security、WAF/CDN、Monitoring、Incident、Performance、Scalingの8軸です。
WordPress公式文書はDatabaseとFilesの両方をBackupし、迅速な復旧方法を把握すべきと説明しています。[1] NISTもファイル作成だけでなく維持と試験を勧めています。[5] Backup提供と、定めた時間内に復旧できることは同じ状態ではありません。
責任の軸 | Managed WordPress Hosting | Self-managed VM / Server | Managed Infrastructure |
|---|---|---|---|
| Backup | 自動Backupが提供される場合が多いものの、保護対象と復旧可能時点は顧客が確認します。 | Files・Database・外部Storage・DNS・Secretなどを特定し、Backup Jobを運用します。 | OperatorがJobと失敗通知を運用し、事業責任者がRPO・保存・隔離方針を承認します。 |
| Restore Test | 復元ボタンやSupportがあっても、定期的な復元試験が保証されるわけではありません。 | 試験環境、復元手順、整合性確認、所要時間測定を直接実施します。 | OperatorとApplication Ownerが共同実施し、事業責任者が復旧完了を承認します。 |
| Security | HostがPlatform・WAF・Malware・Isolationを管理する場合が多く、アカウント・権限・脆弱なPlugin・Custom Codeは顧客責任に残ります。 | OSからWordPressアカウント・Codeまですべて直接管理します。 | OperatorはInfrastructure Security、Application OwnerはWordPress・Code・権限を担当します。 |
| WAF / CDN | 基本機能でもCache例外・Origin・DNS・Business Logic設定は共同確認が必要です。 | 製品選択、DNS、証明書、Origin保護、Cache Ruleを直接運用します。 | 契約範囲に応じてOperatorが設定し、Application Ownerが機能影響を検証します。 |
| Monitoring | PlatformやHTTP Uptime Monitoringがあっても、決済・登録・フォームなどは別途計測が必要です。 | Infra・Log・APM・Uptime・Business Journeyをすべて直接設計します。 | OperatorはInfra・Runtime、Application Ownerはユーザージャーニーと事業結果を観測します。 |
| Incident | Platform IncidentはHostが担当しても、Plugin・Code・事業機能の障害は顧客が引き継ぎます。 | 検出・分類・緩和・復旧・連絡をすべて内部で実施します。 | OperatorがInfrastructure、Application OwnerがApplicationのIncident、事業責任者が対外連絡を担当します。 |
| Performance | Cache・CDN・Runtime最適化があっても、遅いPlugin・Query・Theme・外部APIはApplication責任です。 | Stack全体のボトルネックを直接診断・改善します。 | OperatorがResource・Runtime、Application OwnerがQuery・Plugin・Codeを改善します。 |
| Scaling | Plan・Platformの上限内で拡張します。規模変更と費用承認は顧客が担当します。 | Capacity PlanningとArchitecture変更を直接実施します。 | Operatorが容量計画と変更を提案し、事業責任者が費用・リスクを承認します。 |
19の責任軸：統制と費用
第3表はSupport、Root/Server Access、Portability、Cost Structure、Responsibility Gapの5軸です。
自主管理が常に安くないのは、Server料金と総運用費が違うからです。逆に管理型製品もすべての組織で経済的ではありません。使わないPlatform機能、Traffic課金、Add-on、制約による再開発費用が発生し得ます。
責任の軸 | Managed WordPress Hosting | Self-managed VM / Server | Managed Infrastructure |
|---|---|---|---|
| Support | WordPress専門Supportは利点ですが、Plugin・Code・DNS・メールなどの除外範囲を確認します。 | Providerは物理・仮想化層まで支援し、Application支援者は別途必要です。 | 運用窓口を一本化できますが、Application Developmentを含むかは契約次第です。 |
| Root / Server Access | 通常は制限されるか提供されません。Platformの安定性と標準化を優先します。 | RootとServer設定を直接制御し、誤変更の責任も負います。 | 顧客保有アカウント、制限権限、Operator専用権限など契約構造で変わります。 |
| Portability | Platform固有のCache・MU Plugin・配布機能に依存しやすく、Export範囲の確認が必要です。 | 設定とデータの統制は高いものの、文書・自動化がなければ特定担当者に依存します。 | IaC、Credential所有権、Backup Export、Runbook引き継ぎ条件で変わります。 |
| Cost Structure | Hosting料金にPlatform・Backup・Security・Supportがまとまり、Update Add-onや超過料金が加わる場合があります。 | Server料金は安く見えても、人員・ツール・オンコール・復旧試験の費用は別途必要です。 | Infrastructure費用、管理費用、別途Application保守費用に分かれます。 |
| Responsibility Gap | Hostの支援外のPlugin・Custom Code・事業機能に担当者がいないと生じます。 | 技術を制御できても、実際の担当者・対応時間・復旧手順がないと生じます。 | Infrastructure契約とWordPress Application契約の間で作業が抜けると生じます。 |
WordPress Operations RACI Matrix
RACIは業務ごとに実行者と最終責任者を分けます。Rは実作業を行い、Aは結果を最終的に引き受け承認し、Cは判断前に協議され、Iは結果と状態を通知されます。
表のBはBusiness Ownerで、事業影響、予算、対外連絡、復旧承認を担います。WはWordPress/Application Ownerで、Core・Plugin・Theme・Codeと事業機能を担います。HはManaged WordPress Host、OはInfrastructure Operatorです。Oは自主管理なら内部担当者、管理型インフラなら契約したOperatorです。
これは基本モデルです。Plugin Update、WordPress Maintenance、Application Monitoring、24時間Incident Responseが明記されれば、一部のRとAは変わります。Server管理だけの契約からCore・Plugin・Application業務の移転を読み取ってはいけません。Aは運用上のAccountabilityであり、法的な損害賠償やSLA責任は実際の契約・規約で別途判断します。
責任の軸 | Managed WordPress Hosting | Self-managed VM / Server | Managed Infrastructure |
|---|---|---|---|
| PHP・Web Server・DB Engineのパッチ | A/R: H · C: W · I: B | A/R: O · C: W · I: B | A/R: O · C: W · I: B |
| Core Updateの実行 | A/R: H · C: W · I: B | A: W · R: O · I: B | 基本 A/R: W · C: O · I: B |
| Core Updateの互換性承認 | A/R: W · C: H · I: B | A/R: W · C: O · I: B | A/R: W · C: O · I: B |
| Plugin・Theme Update | A/R: W · C: H · I: B | A/R: W · C: O · I: B | 基本 A/R: W · C: O · I: B |
| Custom Code・Deployment | A/R: W · C: H · I: B | A/R: W · C: O · I: B | A/R: W · C: O · I: B |
| Backup Policy・RPOの承認 | A: B · R: W · C: H | A: B · R: W · C: O | A: B · R: W · C: O |
| Backup Job・失敗通知の運用 | A/R: H · C: W · I: B | A/R: O · C: W · I: B | A/R: O · C: W · I: B |
| Restore Drillの実施 | A: B · R: W+H | A: B · R: W+O | A: B · R: W+O |
| Platform Security・WAF | A/R: H · C: W · I: B | A/R: O · C: W · I: B | A/R: O · C: W · I: B |
| アカウント・Plugin・Codeのセキュリティ | A/R: W · C: H · I: B | A/R: W · C: O · I: B | A/R: W · C: O · I: B |
| Infrastructure・Runtime Monitoring | A/R: H · I: W+B | A/R: O · I: W+B | A/R: O · I: W+B |
| ユーザージャーニーのMonitoring | A: B · R: W · C: H | A: B · R: W · C: O | A: B · R: W · C: O |
| Platform Incident対応 | A/R: H · C: W · I: B | A/R: O · C: W · I: B | A/R: O · C: W · I: B |
| Application Incident対応 | A/R: W · C: H · I: B | A/R: W · C: O · I: B | A/R: W · C: O · I: B |
| 顧客告知・復旧完了承認 | A/R: B · C: W+H | A/R: B · C: W+O | A/R: B · C: W+O |
| Capacity・Scalingの決定 | A: B · R: H · C: W | A: B · R: O · C: W | A: B · R: O · C: W |
| Exit・Export・引き継ぎ | A: B · R: W · C: H | A: B · R: W+O | A: B · R: W+O |
管理型WordPressホスティングが合う場合
一般的なStackとPlatform制約を受け入れ、Rootや別Daemonを必要とせず、Serverよりコンテンツ・事業機能に集中したい場合に適します。Plugin・Theme・Custom Codeの開発者や代理店が別にあり、HostのBackup・Staging・Security・Supportが現在のリスクに十分なことも条件です。
特定Pluginの禁止を受け入れられない、Serverを細かく設定したい、または支援外Application問題の担当者がいない場合は合わない可能性があります。
VM・Serverの自主管理が合う場合
自主管理は安価なVMを選ぶだけではありません。OS・PHP・Database・Web Serverの担当者がいて、Patch・Monitoring・Backup・Restore Testを自動化して失敗を確認する必要があります。障害時のOn-callや担当者が明確で、Rootや設定自由度が実際に必要であり、Platform制約を減らす価値が運用の複雑さを上回ることも条件です。
Serverを設置した経験だけで運用可能とは判断できません。定期パッチが止まったとき、Backup Jobが失敗したとき、新PHPでPluginが壊れたとき、誰が対応するかまで答えられる必要があります。[8]
管理型インフラが合う場合
Server・OS・Runtimeの統制を保ちたいが人員が不足する場合、複数サイトや別Applicationを一つの運用基準で管理する場合に検討します。Backup・Monitoring・Patch・Incidentを外部や別Platform Teamへ統合したい、Hostingの制約より移植性と設定自由度を重視する、WordPressの開発者や代理店が別にいることも条件です。
ただしインフラだけ契約してApplication Ownerを決めないと、新しい空白ができます。OperatorはServer正常と報告し、開発者はServerの問題と考え、事業担当者はどちらに頼むか分からなくなります。
月額Server料金ではなく総運用費で比較する
WordPress総運用費は下記の計算項目で定義します。
自主管理はHosting料金だけなら安く見えますが、パッチ時間、監視ツール、夜間対応、復元試験、文書化が加わります。管理型ホスティングは多くをまとめますが、Traffic・Storage・サイト数・Add-on・Support Planで費用構造が変わります。管理型インフラはServerと運用費を分けられますが、Application保守を含めるには別の範囲と費用が必要です。
どれが安いかは一般化できません。既存のチーム能力、サイトの失敗費用、支援時間、変更頻度、統制要件を合わせて計算します。
- WordPress総運用費
- 下記八費用項目の合計です。
- Hosting・Infrastructure料金
- 総費用へ合算します。
- Managed Service料金
- 総費用へ合算します。
- Update・Compatibility Test時間
- 総費用へ合算します。
- Backup・Monitoring・Securityツール
- 総費用へ合算します。
- On-call・Incident対応
- 総費用へ合算します。
- Restore Drill
- 総費用へ合算します。
- 変更失敗・停止費用
- 総費用へ合算します。
- 運用引継ぎ・Exit費用
- 総費用へ合算します。
契約前に答えを得る12の質問
製品と契約を検討するとき、12の質問への回答を文書で受け取ります。答えのない質問がResponsibility Gapの生まれる位置です。
- WordPress Coreは誰がいつ更新するか？
- Major・Minor・Security Release別の方針、延期可能期間、緊急セキュリティ更新の例外を確認します。
- Plugin・Theme Updateは基本範囲に含まれるか？
- 単なる自動インストールと、Staging Test・視覚回帰・機能検査・自動Rollbackまでの範囲を分けます。
- Plugin・Theme・Custom Codeの競合は誰が解決するか？
- Hosting SupportがLogだけ提供するのか、原因分析までか、Code修正も行うかを確認します。
- PHP・Databaseのサポート終了時に誰が移行計画を立てるか？
- 自動切り替えだけでなく、事前通知、Staging期間、互換性検証、失敗時の復旧方法が必要です。
- Backupには正確に何が含まれるか？
- Database、Plugin、Theme、MU Plugin、Uploads、Custom Code、Config、外部Storage、Secretを分けます。
- Backupの保存期間と保存場所はどこか？
- 同じアカウント・Region・管理権限内にしか存在しないか、ダウンロードや外部Exportが可能かを確認します。
- 誰がRestoreを実行し、誰が成功を判定するか？
- 復元ボタンの有無より、依頼手順、承認権限、予想時間、データ整合性の検証項目が重要です。
- Restore Drillはどの頻度で実施するか？
- 最新試験日、実所要時間、失敗原因、RTO・RPO達成状況をEvidenceとして残せる必要があります。
- Securityは検出だけか、是正も行うか？
- 脆弱なPluginの通知と、更新・無効化・削除・Code修正まで行うことは異なる範囲です。
- Monitoringはどこまで見るか？
- Server・PHP・Database・HTTP Uptimeに加え、ログイン、決済、問い合わせ送信、予約、管理者Workflowを確認するかを問います。
- Incident対応時間とEscalationはどうなっているか？
- 24時間支援は24時間復旧を意味しません。Severity、応答目標、担当者、Application問題の引き継ぎ、顧客告知責任を確認します。
- 終了時に何を持ち出せるか？
- Database・Files・Backup・DNS・SSL・Credential・Log・Configuration・Runbookを、どの形式と期限で受け取れるかを確認します。
最も危険なのは責任者のいない運用
管理型ホスティングはServer負担を減らしますが、Application責任は消えません。自主管理は広い統制を与えても、担当者と復旧体制がなければ低価格は利点になりません。管理型インフラは統制と支援を組み合わせられますが、境界が曖昧ならInfrastructureとWordPressの間に空白が生まれます。
製品選定前に3文書を作ります。業務別RACI Matrix、ProviderとOperatorが行わない仕事の一覧、障害時のPlatform・Application・Business Owner間の連絡と引き継ぎ順序です。
これが定まれば、どのモデルでも運用構造を説明できます。なければ「管理型」の名前や低い月額料金だけでは、誰がサイトを復旧するか分かりません。
