WordPressのプラグイン競合は、プラグインを止めて1つずつ戻し、症状が出た時点のプラグインを探すと特定できます。
公開中のサイトでは、訪問者に影響させず自分の画面だけで全プラグインを止めるトラブルシューティングモードが安全です。
プラグインが多いなら、半分ずつ戻すと試す回数を減らせます。
対象は、プラグインの追加や更新の後に、サイトの動きがおかしくなった方です。
画面は、当方の検証用WordPress(WordPress 7.1.4、PHP 8.3、2026年10月30日)で試しました。
「重大なエラー」でサイトが開けない場合は、先に「重大なエラー」を直す手順をご覧ください。
プラグインの競合が疑われる症状と最初にやること
競合のように見える症状でも、最初にやることは症状によって違います。
| 出ている症状 | 考えられる状態 | 最初にやること |
|---|---|---|
| 有効化したら「重大なエラーを引き起こしたため、プラグインを有効化できませんでした。」と出た | 有効化の検査で止まった。サイトは動いている | そのプラグインは有効にせず、更新や代わりのプラグインを探す |
| 表側に「このサイトで重大なエラーが発生しました。」と出る | 動いている途中のエラーで、サイトが止まっている | リカバリーモードかFTPでプラグインを止める |
| 特定のページだけ表示が崩れる、ボタンが動かない | CSSやJavaScriptのぶつかり合い | トラブルシューティングモードで切り分ける |
| エディターで「返答が正しい JSON レスポンスではありません。」と出る | プラグインの出力がREST APIの応答を壊している | 応答の中身を見て、ファイルの場所からプラグインを絞る |
| メールが届かなくなった | 送信経路を変えるプラグインが重なっている | SMTP系のプラグインが1つだけかを確かめる |
| 更新した直後からおかしい | 更新したプラグインと他のプラグインの組み合わせ | 更新したものから順に試す |
まずキャッシュを消して同じ症状が出るか確かめる
キャッシュ系のプラグインとブラウザーのキャッシュを消し、別のブラウザーでも同じ症状が出るかを先に確かめます。
表示の崩れは、キャッシュに古いCSSが残っているだけのこともあるからです。
いつから、何をした後かを書き留める
症状が出始めた日時と、その前に入れたプラグイン・更新したプラグイン・変えた設定を書き出してください。
心当たりのあるプラグインがあれば、そこから試すと早く終わります。
プラグインの競合はなぜ起きるか
競合とは、2つのプラグインが同じ名前や同じ場所を使おうとして、ぶつかる状態です。
同じ名前の関数を2つのプラグインが定義する
PHPでは、同じ名前の関数を2回定義すると、重大なエラーになります。
検証では、どちらもlab_share_button()という関数を定義する2つのプラグインを作りました。
<?php
/**
* Plugin Name: 検証用:シェアボタンA
*/
function lab_share_button() {
return '<a class="share-a">シェア</a>';
}
// プラグインBにも、同じ名前の関数 lab_share_button() がある実際のプラグインでは、関数名の前に固有の文字を付けたり、すでに定義されていないかを確かめたりして、ぶつからないように作るのが一般的です。
有効化のときはWordPressが止めてくれた
プラグインAを有効にした状態でBを有効にすると、「重大なエラーを引き起こしたため、プラグインを有効化できませんでした。」と表示されました。

Bは有効にならず、サイトの表側も管理画面も普段どおりに動いていました。
WordPressが有効化の前にプラグインを読み込んで試し、エラーになったものを有効にしなかったためです。
動いている途中で起きる競合は止まらない
有効化の検査で見つかるのは、読み込んだ時点で起きるエラーだけです。
特定のページを開いたときや、特定の操作をしたときにだけ起きる競合は、有効化のときには見つかりません。
CSSやJavaScriptのぶつかり合いは、エラーの表示も出ないことが多く、画面の崩れや動かないボタンとして現れます。
調べる前に準備すること
プラグインを止めたり戻したりするので、元に戻せる状態を作ってから始めましょう。
バックアップを取る
ファイルとデータベースのバックアップを取っておきます。
プラグインの中には、停止したときに設定を消すものもあるためです。
できればステージング環境で試す
本番と同じ内容の複製(ステージング環境)があれば、そちらで切り分けると訪問者への影響を気にせずに済みます。
ステージングが無い場合は、次の節のトラブルシューティングモードを使います。
トラブルシューティングモードで自分だけプラグインを止める
Health Check & Troubleshootingは、WordPress.orgが配布している無料のプラグインです。
公式の説明では、トラブルシューティングを有効にすると、全プラグインを止めて既定のテーマを使う状態になり、それは自分のユーザーだけで、無効にするかログアウトするまで続くとされています。
出典:WordPress.org「Health Check & Troubleshooting」(2026年10月30日確認、検証は1.7.1)
プラグインを入れてタブを開く
「プラグイン」→「新規追加」で「Health Check & Troubleshooting」を探して、インストールして有効にします。
当方の環境では、プラグインを入れた直後は画面が英語で、日本語の翻訳を別に入れてから日本語の表示になりました。
有効にすると、「ツール」→「サイトヘルス」に「トラブルシューティング」というタブが増えます。

タブには、トラブルシューティングモードは自分にだけ効き、ほかのユーザーにはいつものサイトが表示されると書かれていました。
MUプラグイン(wp-content/mu-pluginsに置くプラグイン)は、この仕組みでは止められないとも書かれています。
トラブルシューティングモードを有効にする
「トラブルシューティングモードを有効化」を押すと、管理画面の上の管理バーに「トラブルシューティングモード」というメニューが出ました。

この状態で症状が消えれば、原因はプラグインか使っているテーマにあります。
症状が残るなら、疑う先はプラグインではなく、MUプラグインやサーバー側の設定です。
プラグインを1つずつ戻して症状を見る
管理バーの「トラブルシューティングモード」→「プラグイン」から、プラグインを1つずつ有効にします。
1つ戻すたびに、症状が出ていたページを開いて確かめてください。
症状が戻った時点で、最後に有効にしたプラグインが原因の候補です。
同じメニューの「テーマ」から、使っているテーマに切り替えて試すこともできます。
使うときの注意
- トラブルシューティングモード中に変えた設定は、モードを抜けても残る(画面の説明に記載)
- 独自のキャッシュの仕組みは、手で止める必要がある場合がある(画面の説明に記載)
- ログアウトするとモードは終わる
- タブには、この機能は将来、単独のプラグインとして配布される予定だという告知があった
WordPress.orgのプラグインの情報では、最終更新は2024年7月25日でした(2026年10月30日確認)。
抜けるときは、管理バーの「トラブルシューティングモードを無効化」を押します。
半分ずつ戻して原因を絞る
プラグインが多いと、1つずつ戻すのは時間がかかります。
その場合は、半分ずつ戻して、原因が含まれる側を絞っていきます(二分探索)。
半分ずつ戻す手順
- 全プラグインを止めた状態で、症状が消えることを確かめる
- プラグインの一覧の上から半分を有効にして、症状が出るか見る
- 症状が出たらその半分に原因があり、出なければ残りの半分にある
- 原因がある側だけをさらに半分に分けて、同じことを繰り返す
- 1つに絞れたら、そのプラグインだけを止めて、症状が消えるかを確かめる
手順3で症状が出なかったときは、有効にした半分はそのまま残して、残りの半分を試します。
試す回数の目安
1つずつ戻す場合と半分ずつ絞る場合で、試す回数を比べました。
| プラグインの数 | 1つずつ戻す(最大) | 半分ずつ戻す(目安) |
|---|---|---|
| 10個 | 10回 | 4回 |
| 20個 | 20回 | 5回 |
| 40個 | 40回 | 6回 |
2つそろったときだけ起きる場合
競合は、AとBの両方が有効のときだけ起きることがあります。
半分に分けた結果、どちらの半分だけでも症状が出ないときが、この形です。
見つけた1つ目を有効にしたまま、残りのプラグインを半分ずつ戻すのが、相手のプラグインを探す方法です。
トラブルシューティングモードが使えないとき
止め方は、管理画面に入れるかどうかで分かれます。
管理画面に入れる場合
ステージング環境なら、「プラグイン」の一覧で全部を選び、一括操作の「無効化」でまとめて止められます。
本番でこれを行うと訪問者にも影響するため、アクセスの少ない時間に短く終わらせてください。
管理画面に入れない場合
FTPでwp-content/pluginsのフォルダー名を変えて止める方法は、「重大なエラー」を直す手順にまとめています。
サーバーでWP-CLIが使えるなら、コマンドで止めたり戻したりするのも手です。
wp plugin list --status=active
wp plugin deactivate --all
wp plugin activate プラグインのフォルダー名全部を止める書き方と、一部を残して止める書き方は、WP-CLIの公式ドキュメントに載っています。
出典:WP-CLI Commands「wp plugin deactivate」(2026年10月30日確認)
止める前に、wp plugin listの結果を保存しておくと、元の状態に戻すときに迷いません。
原因のプラグインがわかった後にすること
更新するか、代わりを探すか、作者に知らせる
- どちらかのプラグインに更新があれば、更新してから試し直す
- 同じ機能を持つ別のプラグインに替える
- WordPress.orgのプラグインのページにあるサポートフォーラムで、作者に知らせる
作者に知らせるときは、WordPressとPHPのバージョン、ぶつかる相手のプラグイン、症状が出る手順を書きます。
これらの情報をまとめて確かめられるのは、「ツール」→「サイトヘルス」の「情報」タブです。
同じ役割のプラグインを重ねない
キャッシュ、SMTP、セキュリティ、SEOのように、同じ役割のプラグインを2つ入れると、ぶつかりやすくなります。
たとえばWP Mail SMTPの公式ドキュメントは、ほかのSMTP系のプラグインが有効だとWP Mail SMTPが働かなくなることがあると案内しています。
出典:WP Mail SMTP「Troubleshooting WP Mail SMTP」(2026年10月30日確認)
→ 関連:入れるべきプラグイン/入れてはいけないプラグイン/SWELLと相性の良いプラグイン
まとめ
WordPressのプラグイン競合は、全部止めて症状が消えるかを確かめ、1つずつか半分ずつ戻して原因を絞ります。
公開中のサイトなら、トラブルシューティングモードで、訪問者に影響させずに自分の画面だけで試すのが安全です。
有効化の時点で起きる競合はWordPressが止めてくれますが、動いている途中の競合は自分で探す必要があります。
エディターで保存できない症状はREST APIエラーの直し方、表示の崩れはSWELLの表示が崩れる原因と直し方もあわせて確かめてください。
自分で切り分けても原因がわからない場合は、WordPressの保守・運用改善のご相談(MOTOKI)も承っています。



