WordPress公式ロードマップは、WordPress 7.2を2026年12月上旬に公開する計画を示しています。ただし、掲載された作業がすべて最終版に入るとは限りません。sudo modeは特定操作での再認証を目指す計画であり、サイト間の隔離には使えません。まず共有アカウント、コード、データベース、実行環境を点検し、必要な境界に応じて独立インストールや環境分離を選んでください。(公式ロードマップ)
複数の独立したWordPressサイトを運用し、同じサーバー上での管理範囲を決めたい方に向けた内容です。
越境ECの技術担当者は、再認証とサイト分離が別の対策であることを踏まえて権限を見直せます。
複数顧客のサイトを保守する運用チームは、どのサイトをまとめ、どれを分けるべきか判断できます。
sudo modeの目的とサイト隔離は別です
sudo modeは、管理者が高い権限を使う操作の前に、改めて本人確認を行うための仕組みとして検討されています。つまり確認する対象は「操作している人が本人か」であり、「そのサイトが他サイトのファイルやデータに触れられるか」ではありません。(WordPress 7.2開発ページ)
この違いは、ログイン後の事故や権限の悪用を考えると重要です。再認証が導入されたとしても、すでに許可されたプラグインのコードが同じインストール内で動くことや、共通のファイル・実行環境を使う構成まで自動的に分離するわけではありません。
また、現時点でsudo modeは公式ロードマップ上の計画です。WordPress 7.2の確定機能として扱わず、実装範囲や公開状況はリリース時に公式情報で再確認してください。
管理画面の役割とサーバー権限を分けて考えます
WordPressの権限は、サイト内で誰が投稿や設定を操作できるかを管理します。Multisiteではネットワーク管理者がネットワーク全体を管理できる一方、サーバー上のファイル所有者やPHPプロセスの実行権限は、OS側で別に設計する必要があります。(Multisiteの管理手順)
チーム内で確認したいのは、権限の名前だけではありません。共通アカウントを複数人で使っている、退職者や委託先のアカウントが残っている、複数サイトの管理者権限を同じ担当者が持つ、といった状態では、操作履歴や影響範囲を追いにくくなります。
たとえば、社内の日本語サイトと外部顧客のECサイトを同じ管理担当者が保守していても、両者の信頼関係や障害時の責任範囲が同じとは限りません。アカウントを分けるだけで十分か、コードや実行環境まで分けるかを、サイトごとに決めてください。
コードとプラグインの共有範囲を確認します
WordPress Multisiteは、複数サイトを1つのWordPressインストール内で管理する方式です。共通のコアやプラグインを更新しやすい一方で、コードの更新や脆弱性対応が複数サイトに影響する可能性があります。(Multisiteの概要)
サイトごとに独立インストールすると、利用するテーマやプラグイン、更新時期を分けやすくなります。その代わり、更新作業やバックアップの対象も個別に管理する必要があります。プラグインが同じでも、サイト別の設定や更新頻度が違うなら、共通化の利点と一括障害の範囲を比べましょう。
sudo modeの再認証は、このコード共有の問題を解消しません。あるサイトで使うプラグインが共通のWordPress環境に影響する可能性まで考えるなら、インストールを分けるだけでなく、ファイル権限とPHPの実行ユーザーがどう設定されているかも確認が必要です。
データベースを分けても隔離は完了しません
公式資料では、Multisiteは単一のWordPressインストールと単一のデータベースインスタンスを利用する構成として説明されています。一方、複数インスタンスを用意し、各インスタンスに独立したデータベースを持たせる構成も案内されています。(複数インスタンスの構成)
サイトごとにデータベースと接続ユーザーを分ければ、接続情報やデータベース内の権限を管理しやすくなります。しかし、同じOSユーザーがすべてのサイトの設定ファイルを読める場合、データベースの認証情報がまとめて参照される可能性があります。データベースを分けた事実だけを、完全なセキュリティ境界とみなさないでください。
| 確認する境界 | Multisite | 独立インストール | 判断時に見る点 |
|---|---|---|---|
| WordPressコア・プラグイン | 共通 | サイトごとに分けやすい | 更新差やプラグインの信頼度 |
| データベース | 1つのインスタンスを共用 | 個別のDB・ユーザーを設定可能 | 情報の機密度、接続権限 |
| 管理者権限 | ネットワーク管理者の権限に注意 | 管理画面を別々に管理 | 担当者や顧客が共通か |
| ファイル・PHPプロセス | 実際の設定を確認 | 分離できるかはOS設定次第 | 所有者、実行ユーザー、書き込み範囲 |
ファイルとプロセスの境界を実際に点検します
独立インストールを選んでも、ファイルの所有者や書き込み権限が共通なら、サイト間の影響を十分に抑えられない場合があります。WordPressのファイル権限に関する公式資料を参考に、WebサーバーやPHPがどの権限でファイルを読み書きするのか確認してください。(ファイル権限の公式資料)
特に、異なる顧客のサイト、異なる信頼レベルのサイト、停止時の影響が大きく異なる業務サイトは、同じ実行ユーザーや広い書き込み権限を共有していないかを調べます。独立データベースを設定していてもOSアカウントが共通なら、設定ファイルやサイトファイルへのアクセス範囲が残るためです。
次の項目をサイトごとに確認し、未確認の項目が残る場合は、導入前に運用担当者と分離方針を決めてください。
- [ ] サイトごとに管理者アカウントを特定し、共用ログインをなくす
- [ ] Multisiteのネットワーク管理者が操作できる範囲を記録する
- [ ] サイトごとにWordPress本体、テーマ、プラグインの共有状況を確認する
- [ ] データベースと接続ユーザーの権限が必要最小限か確認する
- [ ] ファイル所有者、書き込み権限、PHPの実行ユーザーを調べる
- [ ] バックアップと復旧の単位が、障害の影響範囲に合っているか確認する
運用関係と障害範囲から構成を選びます
単一の方式をすべてのチームに当てはめる必要はありません。管理者やコード更新を共有できる社内サイトはMultisiteが管理しやすい一方、顧客ごとに信頼関係や保守条件が異なるなら、独立インストールや実行環境の分離を優先する判断が現実的です。
| サイトの関係・要件 | 向く構成 | 利点 | 残る確認事項 |
|---|---|---|---|
| 同じ組織で管理者・更新方針が共通 | Multisite | 一元管理しやすい | 共通コードの障害範囲、ネットワーク権限 |
| 顧客や更新時期が異なる | 複数の独立インストール | コードやDBを分けやすい | OSユーザー、ファイル権限、個別バックアップ |
| 信頼度や業務影響が大きく異なる | 実行環境も分ける構成 | 共有する境界を減らしやすい | 構築・更新・監視の運用負担 |
設計前には、サイト名、管理者、顧客、利用プラグイン、データベース、PHP実行ユーザー、障害時の影響を一覧にします。管理者とコードが共通で、停止時の影響も許容できるサイト群なら集約を検討できます。顧客が異なる、認証情報を分けたい、障害の波及を抑えたい場合は、独立インストールを基本に、ファイルとプロセスの境界まで確認してください。
よくある判断質問
sudo modeで別サイトのデータを守れますか？
再認証は、特定操作を行う人の本人確認を追加する目的で検討されているもので、サイトのデータアクセス権を分割する機能ではありません。データベースユーザー、ファイル権限、PHPの実行環境を別々に確認し、必要な境界を構成してください。
独立インストールにすれば、サーバー上でも完全に分離されますか？
自動的には分離されません。インストール先を分けても、同じOSユーザーが各サイトのファイルを読み書きできる場合や、同じPHP実行ユーザーを使う場合は共有範囲が残ります。必要な分離水準に合わせて、実行ユーザーや権限の設計を確認します。
サイトごとにデータベースを分けると何が変わりますか？
データベースの認証情報と操作範囲をサイトごとに管理しやすくなります。誤操作や認証情報の流出が起きた場合の影響を限定できる可能性もあります。ただし、設定ファイルへのアクセスやPHPプロセスの共有は別問題のため、DB分割だけで完了と判断しないでください。
Multisiteを選んでもよいのはどのような場合ですか？
サイトの管理主体、更新方針、利用するコードが共通し、共通環境の障害が複数サイトに及ぶことを許容できる場合に検討できます。顧客ごとに管理権限やデータの扱いが異なるなら、集約の運用効率だけで決めず、独立インストールや実行環境の分離も比較してください。
まず現在の共有境界を一覧にしてください
sudo modeの計画を、サイト隔離の代替策として待つ必要はありません。管理者、コード、データベース、ファイル、PHPプロセスのうち、どこを共有しているかを先に整理し、サイト間の信頼関係や障害時の影響に合わせて構成を選びましょう。
複数サイトを同じサーバーで運用する場合、共有ホスティングやVPSでは他の利用者との資源共有や、OS・実行環境の設計自由度が制約になることがあります。一方、専有のAMD物理サーバーを選んでも、WordPressの権限分離やPHPプロセスの設定が自動で済むわけではありません。AmdMetalのような専有サーバーは、サイト群の資源を他の契約者と共有せずに運用したい場合の選択肢です。(AmdMetalのサーバーサービス) 導入時の料金や契約期間は、AmdMetalの料金と支払い条件で確認したうえで、あなたのサイト構成に必要な分離設定を設計してください。
よくある質問
WordPress 7.2で予定されているsudo modeは、別々のサイトを隔離しますか？
いいえ。公式ロードマップで示されているのは、特定の高権限操作の前に本人確認を追加する方向性です。サイト間でファイル、データベース、プラグインの影響を遮断する仕組みとは目的が異なります。また、ロードマップ上の計画は最終版への搭載を保証するものではありません。
WordPress Multisiteと、サイトごとの独立インストールは何が違いますか？
Multisiteは共通のWordPressインストールを使い、サイトをネットワークとして管理します。独立インストールはコードや設定を分けやすく、データベースや接続ユーザーもサイト別に構成できます。ただし、独立インストールでもOSの実行ユーザーやファイル権限を共用していれば、すべてのリスクが分離されるわけではありません。
1台のサーバーに複数のWordPressサイトを置く場合、権限はどう分けますか？
まず、サイト管理者、ネットワーク管理者、サーバー管理者の担当範囲を分け、共有アカウントを避けます。次にサイト単位でファイル所有者、書き込み権限、PHPの実行ユーザー、データベース接続ユーザーを確認します。異なる顧客や信頼レベルのサイトは、独立インストールに加え、実行環境の分離も検討してください。
WordPressサイトごとにデータベースとデータベースユーザーを分けるべきですか？
サイト間で管理者や顧客、データの機密度が異なるなら、個別のデータベースと接続ユーザーを使うと、認証情報や操作範囲を分けやすくなります。ただし、データベースを分けただけではファイルやPHPプロセスの共有は解消されません。必要な隔離水準に合わせて、OSユーザーや実行環境も点検してください。
サイトごとの運用境界を見直すなら、専有サーバーをご検討ください
AmdMetalの専有物理サーバーなら、CPU・メモリ・ストレージをサーバー全体で専有して運用できます。