WooCommerce更新後に注文編集ができない場合の権限設定と解決手順
WooCommerce のアップデート後に、注文の編集やステータス変更ができなくなった場合は、該当するユーザーロールに WordPress の基本的な権限である edit_posts を割り当てることで解決する。WooCommerce 9系と HPOS の組み合わせでは、カスタム権限だけでは注文管理画面を表示できなくなる仕様変更が起きている。
WooCommerce アップデート後に注文を編集できなくなった原因
WooCommerce 10.9.4 以降、特に HPOS（高パフォーマンス注文ストレージ）を有効にし、互換性モードを無効化している環境でこの問題が発生しやすい。これまでは edit_shop_order や edit_others_shop_orders といった WooCommerce 固有の権限だけで注文管理ができていた。だが、内部的な権限チェックが強化され、注文画面を表示するために汎用的な edit_posts 権限も必須になった。
この変更は、WordPress のコア機能と WooCommerce の注文データの整合性を高めるためのものだ。「このサイトで重大なエラーが発生しました」といったメッセージではなく、単に「権限がありません」と表示されたり、注文一覧ページ自体が空欄になるといった症状が現れる。PublishPress Capabilities や User Role Editor などのプラグインで、注文管理だけに特化したカスタムロールを作成している場合に特に影響を受ける。
– edit_shop_order
– edit_others_shop_orders
– edit_posts なし
– edit_shop_order
– edit_others_shop_orders
– edit_posts（新たに追加）
edit_posts 権限を追加して問題を解決する具体的な手順
解決策はシンプルだ。注文管理を担当するユーザーロールに edit_posts 権限を付与する。この操作によって、注文以外の「投稿」や「固定ページ」へのアクセス権も与えたくない場合は、後続の「より厳密な権限制御を行うための注意点」のセクションで紹介する追加の調整が必要になる。
現在のユーザーロールの権限を確認する
まず、どのロールに問題が起きているのかを特定する。ユーザーが複数のロールを持っている場合、権限は加算される仕組みだ。管理者権限で問題が起きている場合は、プラグインの競合など別の原因を疑う必要がある。
PublishPress Capabilities の無料版を使っていれば、管理画面の「Capabilities」メニューから各ロールの権限一覧を確認できる。画面上部の「Select Role to View / Edit」ドロップダウンで、問題のロールを選択し、権限の一覧を表示させよう。
edit_posts 権限を該当ロールに割り当てる
権限の一覧画面で「Core」タブを開き、「Posts」セクションを探す。その中にある「edit_posts」のチェックボックスにチェックを入れ、画面下部の「変更を保存」ボタンをクリックする。これで、指定したロールに汎用的な投稿編集権限が付与され、WooCommerce の注文画面にもアクセスできるようになる。
User Role Editor を使っている場合も手順はほぼ同じだ。管理画面の「ユーザー」→「User Role Editor」を開き、対象ロールを選択して、権限リストから「posts」をフィルタリングし、「edit_posts」にチェックを入れて保存する。
より厳密な権限制御を行うための注意点
edit_posts を付与すると、デフォルトでは「投稿」と「固定ページ」の編集画面にもアクセスできるようになる。これは、WordPress の権限システムが投稿タイプごとに細かく権限を分けていないことに起因する。注文だけを管理させたいロールには、これは望ましい状態ではないだろう。
投稿や固定ページへのアクセスを制限するには、別の方法で管理画面メニューを非表示にする必要がある。よく使われるのは「Admin Menu Editor」プラグインだ。このプラグインを使えば、特定のユーザーロールに対して不要なメニュー（投稿、固定ページ、コメントなど）を非表示にできる。メニューを隠すだけでは直接URLを入力されるとアクセスできてしまうため、完全にブロックしたい場合は、current_user_can() 関数を使ったカスタムコードを functions.php に追加する方法もある。
よくある質問
管理者権限でも注文を編集できなくなった場合はどうするのか
管理者はデフォルトで edit_posts を含むすべての権限を持っているため、今回の原因とは別の問題だ。まずはすべてのプラグインを停止し、テーマをデフォルトに戻して競合の有無を確認する。HPOS 互換モードを一時的に再有効化して症状が改善するかもテストする価値がある。
edit_posts を追加してもアクセスできない場合は他に何を確認すべきか
WooCommerce の注文には、edit_shop_orders や view_admin_dashboard といった権限も必要になる。後者が不足していると、管理画面自体へのアクセスが制限される可能性がある。また、キャッシュ系プラグインやセキュリティプラグインが権限チェックに干渉しているケースもあるため、これらの設定も見直す。
HPOS の互換モードを再有効化すれば解決するのか
一時的な回避策としては機能する可能性が高い。しかし、HPOS の互換モードは将来的に廃止される予定の過渡的な機能だ。根本解決のためには、ここまでに説明した権限の適切な設定を行い、HPOS を有効化した状態で動作させることが推奨される。
コードを使って権限を自動付与する方法はあるか
特定のロールに対してテーマやプラグインの有効化時に権限を追加したい場合、WP_Role クラスの add_cap() メソッドを使う。たとえば、functions.php やカスタムプラグイン内で、get_role('shop_manager')->add_cap('edit_posts') のように記述する。このコードは一度だけ実行すればよいが、権限の変更を明確にするために、プラグインのアクティベーションフックで実行することが望ましい。
この記事のポイント
- WooCommerce の更新後、注文の編集ができない原因は
edit_posts権限の不足にある - 権限管理プラグインで該当ロールに
edit_postsを割り当てるだけで問題は解決する - 不要な投稿画面へのアクセスは、Admin Menu Editor などのプラグインで個別に制限する必要がある
- 管理者権限での同様の症状は、プラグイン競合といった別の原因を疑う
- HPOS 互換モードの再有効化は一時しのぎに過ぎず、権限設定による根本解決が推奨される
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
ManageWP でサイトがオフラインエラーになる All-In-One Intranet 競合の直し方
ManageWP のダッシュボードでサイトが「オフライン」表示になり Worker プラグインの再接続に失敗するエラーが出る場合、All-In-One Intranet プラグインの強制ログイン機能が外部通信をブロックしている可能性が高い。プラグインを最新版にアップデートするか、提供されているフィルターフックで ManageWP のアクセスだけを許可すれば直ちに解決する。
なぜ ManageWP が All-In-One Intranet 導入後に接続不能になるのか
All-In-One Intranet は WordPress サイト全体を非公開化するプライバシー保護プラグインだ。設定を有効にすると、訪問者がログインしていない限り、あらゆるページへのアクセスを遮断する。この制御は WordPress のリクエスト処理そのものにかかり、人間のブラウザアクセスだけでなく、バックグラウンドで動作する管理ツールの通信も一律に弾いてしまう。
ManageWP はサイトで ManageWP Worker プラグインを経由して、ダッシュボードからの一括更新や監視を実現している。この通信は非ログイン状態の外部リクエストとして届くため、All-In-One Intranet の「未ログインユーザーをブロック」のルールに引っかかり、結果として「Worker プラグインがアクティブでない」という誤ったエラーを ManageWP 側に返してしまう。
このデモは、All-In-One Intranet が ManageWP の通信を遮断する流れと、除外設定後の正常な通信を示している。
アップデートで競合を根本解決する
プラグイン開発元がこの競合を把握しており、バージョン 1.10.0 で ManageWP をはじめとする外部管理ツール（MainWP、WP Umbrella など）との通信が復旧する修正が行われた。古いバージョンを使い続けているなら、まずは All-In-One Intranet を最新にアップデートするだけで問題が解消する。
アップデート前のキャッシュとバックアップ
プラグインの更新前に、サイト全体のバックアップを取得しておく。管理画面から「ダッシュボード」→「更新」を開き、「プラグイン」セクションで All-In-One Intranet の新しいバージョンの有無を確認する。
更新が完了したら、サーバーキャッシュや CDN キャッシュをすべてクリアする。ManageWP 側のキャッシュもリセットするために、対象サイトの「サイトを再接続」を一度だけ実行し、オフライン表示が消えるか確認する。
フィルターフックで ManageWP を手動除外する
プラグインを何らかの理由で最新版にできない場合や、最新版でも何かしらの要因で競合が続くなら、All-In-One Intranet が用意している aioi_allow_public_access フィルターフックで ManageWP Worker のアクセスだけ許可する方法がある。このフックを使うと、サイトの他のプライバシー設定を維持したまま、特定のエンドポイントやリクエストを認証不要で通過させられる。
子テーマの functions.php にコードを追加する
フィルターフックは、利用している子テーマの functions.php にコードを追記して適用する。FTP やホスティングのファイルマネージャーで直接編集するか、管理画面の「外観」→「テーマファイルエディター」から functions.php を開く。
add_filter( 'aioi_allow_public_access', function( $allow ) {
// ManageWP Worker の要求を常に許可する
if ( defined( 'MWP_ACTION' ) || isset( $_GET['mwp_action'] ) ) {
return true;
}
return $allow;
});上記のコードは、ManageWP Worker プラグインがリクエストの際に内部でセットする定数やクエリパラメータを目印にしている。もし Worker プラグインが異なるパターンのリクエストを送っていたとしても、フック内の条件を適宜拡張すればよい。
コードを追加したらファイルを保存し、ManageWP ダッシュボードで対象サイトを再接続する。このタイミングでオフラインエラーが出なくなり、正常に一覧に戻ってくるはずだ。
この STEP 図は、フィルターフックでアクセスを許可し、ManageWP の接続を復旧するまでの一連の流れを視覚化したものだ。
回避策が効かない場合の追加切り分け
ごく稀に、All-In-One Intranet のバージョンアップやフィルター適用後もエラーが消えないケースがある。その場合は、他のセキュリティプラグインが重複して通信を遮断していないか確認する。
プラグインの競合を最小構成で検証する
一時的に全プラグインを無効化し、All-In-One Intranet と ManageWP Worker だけを有効化する。この状態で ManageWP が接続できるなら、ほかのプラグインに問題を起こしているものがあると判断できる。1つずつ有効化していき、再発タイミングを特定する。
ファイアウォールとサーバー設定の二重ブロックに注意する
Wordfence などの WAF（ウェブアプリケーションファイアウォール）が ManageWP の IP アドレスをブロックしている可能性もある。プラグインの設定や cPanel の IP ブロック機能で、ManageWP の公式 IP アドレス帯域が許可リストに入っているか確認する。また .htaccess にリダイレクトや BASIC 認証をかけている場合、一時的に解除して影響を切り分ける。
よくある質問
All-In-One Intranet を無効化したくないが、セキュリティは維持できるか
フィルターフックによる除外は、ManageWP Worker が利用する特定のリクエストに絞って施せる。サイトの他の全ページは引き続きログイン必須の状態を保つため、セキュリティレベルを落とすことなく管理だけを外部から行える。コードの条件式を Worker 限定にすることで、意図しない一般リクエストの流入は防がれる。
ManageWP 以外の管理ツールでも同じ問題は起きるのか
MainWP、WP Umbrella など、サイトに Worker 的なプラグインを入れて外部から操作する仕組みの管理ツール全般で発生する可能性がある。All-In-One Intranet のバージョン 1.10.0 ではこれらツールとの互換性も修正されているため、最新版で問題が起きることはほぼない。
アップデート後に ManageWP がまだオフライン表示のままだがどうすればいいか
まず ManageWP のダッシュボードで該当サイトを明示的に「再接続」させる。続いてサーバー側のキャッシュ（プラグインベースのキャッシュやホスティングのサーバキャッシュ）を完全にクリアする。それでも反映されない場合、Worker プラグイン自身をいったん削除し、ManageWP ダッシュボードから新規にインストールし直すと設定がリフレッシュされる。
functions.php を直接編集するのに抵抗がある。安全な方法はあるか
必ず親テーマではなく子テーマの functions.php を編集する。編集前にファイルをダウンロードしてバックアップし、テーマファイルエディターを使う場合は保存前にコードの誤字を確認する。それでも不安なら、Code Snippets プラグインを導入し、管理画面からスニペットとして同じコードを追加する方法もある。
数か月前から Worker の再接続に失敗していたが、データは失われるか
ManageWP 側の管理データ（サイトの追加設定や監視ログなど）は失われない。再接続が成功すれば、プラグインやテーマの更新状況はそのまま引き継がれる。ただし、オフライン期間中にあったサイト側の変更は、再接続後に初めて ManageWP 側で認識される。
この記事のポイント
- ManageWP のオフラインエラーは All-In-One Intranet のプライバシー保護が原因
- プラグインの 1.10.0 へのアップデートで競合は根本的に解決する
- すぐ対応したい場合は
aioi_allow_public_accessフィルターで手動除外 - コード追加は子テーマの functions.php に限定しバックアップを取る
- キャッシュクリアと再接続の実行を必ず忘れずに行う
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WordPress複数サイト管理を効率化するModular DSの実力——AIリスク判定と安全な自動更新を徹底解説
WordPressサイトの保守管理は、管理するサイト数が増えるほど指数関数的に複雑さを増していく。個別のサイトにログインして更新を確認し、バックアップを取り、不具合が起きないか怯えながらアップデートボタンを押す作業は、多くの制作者にとって大きな負担だ。
Modular DSは、こうした煩雑な作業を1つのクラウド型ダッシュボードに集約するプラットフォームだ。複数のクライアントサイトを一括管理し、更新からセキュリティ、バックアップ、レポート作成までを自動化できる。本記事では、Modular DSの具体的な機能や導入のメリット、そして実務での活用シーンについて深掘りしていく。
特に注目されるのは、AIを活用したアップデートのリスク評価機能だ。単なる一括更新ツールにとどまらない、プロフェッショナル向けの保守管理ソリューションとしての実力を検証する。
Modular DSの概要と解決する課題
WordPressの運用において、保守作業は避けて通れない。しかし、手動での管理には限界がある。Modular DSは、制作会社やフリーランスが抱える「管理コストの増大」という課題に対して、中央集権的なアプローチで解決を図るツールだ。
複数サイト管理の「煩雑さ」を解消する
通常、30〜40件のクライアントサイトを管理する場合、それぞれのサイトに個別にログインして状況を確認する必要がある。これは膨大な時間を浪費するだけでなく、更新の見落としといったヒューマンエラーの原因にもなる。
元記事の著者によれば、Modular DSを導入することで、すべての管理サイトを1つの画面で可視化できるようになる。各サイトの更新状況、稼働時間（アップタイム）、セキュリティアラートが一覧で表示されるため、管理者は一目で優先順位を判断できる。この「一元化」こそが、保守業務の効率化における最大の鍵だ。
クラウドベースのダッシュボードで完結する効率性
Modular DSはクラウド型のプラットフォームであり、管理用の専用サーバーを自前で構築する必要はない。管理画面にアクセスするだけで、接続されたすべてのWordPressサイトを操作できる。これには、プラグインやテーマの更新だけでなく、データベースの最適化やスパムコメントの削除といった細かなメンテナンスも含まれる。
特定のサイトで問題が発生した際も、ダッシュボードから即座に詳細を確認できる。複数のタブを切り替えて各サイトを行き来する手間がなくなることで、作業のコンテキストスイッチが減り、集中力を維持したまま保守業務を完結させることが可能だ。
安全なアップデートを実現する「Update Copilot」と自動化機能
WordPressのアップデートは、サイトを最新の状態に保つために不可欠だが、同時に「表示崩れ」や「致命的なエラー」のリスクも孕んでいる。Modular DSは、このリスクを最小化するための独自の仕組みを備えている。
AIによるリスク判定で不具合を未然に防ぐ
Modular DSの最大の特徴の一つが「Update Copilot」だ。これはAIを活用したリスクスコアリング機能で、保留中のアップデートに対してリスクレベルを判定する。具体的には、コードの変更内容やプラグインの信頼性の履歴、他のユーザーにおける動作状況などを分析し、安全性を数値化する仕組みだ。
管理者は、ルーチンとして更新して良いものと、慎重に手動で確認すべきものを事前に見分けることができる。著者は、この機能によってアップデート作業に伴う心理的なストレスが大幅に軽減されると指摘している。闇雲に「すべて更新」ボタンを押すのではなく、データに基づいた判断を下せるようになるからだ。
賢い自動アップデート設定とセーフアップデート
「Smart Automated Updates」機能を使えば、特定の条件下でのみ自動更新を実行するルールを設定できる。例えば、「Update Copilotのリスクスコアが一定以上の場合のみ更新する」といった設定や、「リリースから数日が経過してから実行する」といった遅延設定が可能だ。
さらに、更新前には自動的に復元ポイント（リストアポイント）が作成される。更新前後のスクリーンショットを比較し、もし予期しない変化があれば即座にロールバック（元の状態に戻すこと）できる仕組みも提供されている。深夜にプラグインを更新してサイトが真っ白になり、朝まで復旧作業に追われるといった悲劇を防ぐための強力なガードレールと言える。
セキュリティとパフォーマンスを支える高度な機能
保守の役割はアップデートだけではない。外部からの攻撃に対する防御や、サイトの表示速度を維持するためのメンテナンスも重要だ。Modular DSは、これらの領域でも高度なツールを統合している。
脆弱性スキャンと仮想パッチによる保護
Modular DSは、セキュリティプラットフォームであるPatchstackと連携し、サイト内の脆弱性をリアルタイムでスキャンする。特筆すべきは、公式の修正版がリリースされる前に脆弱性を防ぐ「仮想パッチ（Virtual Patching）」の仕組みだ。
仮想パッチとは、アプリケーションのコードを直接書き換えるのではなく、外部のフィルター層で攻撃コードを遮断する技術を指す。これにより、プラグインの開発者が修正版を公開するまでの「空白期間」であっても、サイトを安全に保つことができる。著者は、追加コストはかかるものの、この「Patch and Protect」機能の導入を強く推奨している。
データベースの最適化と死活監視
サイトのパフォーマンスを維持するために、Modular DSはデータベースのクリーンアップ機能を提供している。投稿のリビジョン（編集履歴）やスパムコメント、不要なテーブルなどを、追加のプラグインをインストールすることなくダッシュボードから削除できる。サイトを「軽量」に保つことは、SEOやユーザー体験の向上に直結する。
また、24時間体制の死活監視（アップタイムモニタリング）機能も備わっている。サイトがダウンした際には、SlackやDiscordを通じてリアルタイムで通知を受け取ることが可能だ。クライアントから「サイトが見られない」と連絡が来る前に、制作者側で問題を把握し、迅速に対応を開始できる体制を整えられる。
クライアントワークを加速させるレポート機能と柔軟な料金体系
保守業務の難しさは、その成果がクライアントに見えにくい点にある。Modular DSは、制作者が行っている「目に見えない努力」を可視化するための機能も充実している。
信頼を構築するブランドレポート
Modular DSでは、更新履歴、バックアップの実施状況、セキュリティスキャンの結果などをまとめたレポートを自動生成できる。このレポートは自社ブランドのロゴを入れるなどのカスタマイズが可能で、定期的にクライアントへ送信するようスケジュール設定ができる。
Google AnalyticsやSearch Console、WooCommerce、PageSpeed Insightsとの連携も可能だ。保守内容だけでなく、アクセス数や売上推移、表示速度の改善結果も一つのレポートに集約できる。これにより、クライアントに対して「保守費用を支払う価値」を明確に提示でき、信頼関係の構築に寄与する。
成長に合わせて柔軟に拡張できる価格プラン
料金体系は、管理するサイト数やユーザー数に応じて「Freelance」「Starter」「Business」「Enterprise」の4つのティアに分かれている。すべてのプランに14日間の無料トライアルが用意されており、最初からすべての有料機能を試すことが可能だ。
Modular DSのユニークな点は、プランの制限を超えた場合でも、上位プランへ強制的にアップグレードされるのではなく、超過分をサイト単位で支払う「柔軟な超過料金（Flexible Overage）」モデルを採用していることだ。管理サイトが急激に増えた際も、コストを最適化しながら運用を続けられる点は、成長過程にあるフリーランスや小規模な制作会社にとって大きなメリットと言える。
導入手順と運用のしやすさ
新しいツールの導入において、設定の難易度は大きな障壁となる。Modular DSは、既存のサイトを接続するプロセスが非常にシンプルに設計されている。
2つの接続方法と直感的なUI
サイトを接続する方法は2つある。1つは、WordPress公式ディレクトリにある専用のコネクタープラグインをインストールする方法だ。もう1つは、WordPressのログイン情報を入力してModular DSに自動接続を任せる方法である。どちらも数分で完了する作業であり、技術的なハードルは極めて低い。
接続が完了すると、メインダッシュボードに各サイトの「健康状態」を示すインジケーターが表示される。UI（ユーザーインターフェース）は直感的で、説明を読み込まなくてもどこに何があるかが把握しやすい構成になっている。著者は、ダッシュボードでの滞在時間が数秒で済むほど効率的であり、これがツールとしての高い完成度を示していると評価している。
独自分析：Modular DSは日本の制作者にとって「買い」か？
ここまでModular DSの機能を見てきたが、日本のWeb制作現場においてどのような立ち位置になるかを分析してみたい。結論から言えば、特に「保守契約を標準化したい」と考えている制作者にとって、非常に強力な武器になるだろう。
外部ストレージへのバックアップ未対応という懸念点
元記事でも指摘されている通り、現時点での大きな欠点は「Google DriveやDropboxといった外部ストレージへのバックアップ書き出し」に対応していない点だ。バックアップデータはModular DSが管理するクラウド（EU圏内のサーバー）に保存される。日本のクライアントの中には、データを国内サーバーや自社のアカウントで管理したいという要望を持つケースもあり、この点は導入前に確認が必要だ。
ただし、EUのサーバーはGDPRなどの厳しいデータ保護規則に準拠しているため、セキュリティレベル自体は高い。外部書き出しができない不便さを、管理の簡便さと天秤にかけることになるだろう。
「Update Copilot」がもたらす日本流の丁寧な保守
日本の制作会社は、アップデート後の表示確認を非常に丁寧に行う傾向がある。Modular DSのAIリスク判定と、更新前後のスクリーンショット比較機能は、この「丁寧な保守」を自動化するのに適している。単に更新するだけでなく、「安全性を確認した上で更新した」という証跡を残せることは、クライアントへの説明責任を果たす上で大きな強みになる。
また、日本語のサポートはないものの、UIがシンプルであるため英語が苦手なユーザーでも運用は難しくない。むしろ、国内のレンタルサーバーが提供する簡易的な管理機能とは一線を画す、高度なセキュリティ対策（仮想パッチなど）を安価に導入できる点に価値を見出すべきだ。保守業務を「労働集約型」から「自動化による高利益型」へ転換したいのであれば、Modular DSは検討に値する選択肢となる。
この記事のポイント
- Modular DSは、複数サイトのWordPress保守を1つのダッシュボードで完結させるクラウドプラットフォームだ。
- AIを活用した「Update Copilot」により、アップデートのリスクを事前に把握し、安全な運用が可能になる。
- 脆弱性スキャンや仮想パッチ、死活監視など、エンタープライズレベルのセキュリティ機能が統合されている。
- ブランド化された自動レポート機能により、保守業務の価値をクライアントへ視覚的に伝えることができる。
- 外部ストレージへのバックアップ出力には未対応だが、柔軟な料金体系と高い操作性が魅力だ。
出典
- WP Mayor「Modular DS Review: The All-in-One WordPress Maintenance Platform for Agencies and Freelancers」（2026年3月17日）
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験