WordPress の管理画面で「プラグイン」を開くと、インストールしたプラグインが一覧で表示されます。有効化したもの、停止しているもの。ここに出ているものがすべて——と思っていませんか。

実は、この一覧に出てこないまま動いているプラグインを置ける場所が WordPress にはあります。mu-plugins というフォルダです。

正直に書くと、私もつい先日までこの仕組みを知りませんでした。WordPress を数年触っていても、意識する機会がないまま過ごしてしまう領域です。同じ方も多いのではないかと思い、この記事を書きました。

まず、自分の管理画面を見てみる

WordPress の管理画面で 「プラグイン」 を開いてください。一覧の上のほうに、こんなタブが並んでいます。

mu-plugins が無い環境。「すべて／使用中／停止中」などが並びます。

ここに 「必須」 というタブが混ざっていないか見てください。英語表示の場合は 「Must-Use」 です。

mu-plugins がある環境。「必須 (1)」 が増えています。この1件が、通常の一覧には出てこないプラグインです。

「必須」タブが無い場合

「必須」タブがある場合

こちらも、それだけで異常というわけではありません。

制作会社が設定を入れていたり、レンタルサーバーが管理用のコードを入れていたりと、正規の理由で使われていることがよくあります。まずは心当たりを確認してみてください。

タブをクリックすると、中身が一覧で表示されます。ここで気づくことがあるはずです——「有効化」「停止」のリンクがありません。名前と説明が並んでいるだけです。

「必須」タブの中身。/wp-content/mu-plugins ディレクトリ内のファイルは自動的に実行されます——と WordPress 自身が書いています。プラグイン名の下に「有効化」「停止」のリンクがありません。

なぜそうなっているのか、次で説明します。

mu-plugins とは何か

mu-plugins は 「Must Use（必ず使う）プラグイン」 の略で、wp-content/mu-plugins/ に置かれたファイルを指します。通常のプラグインとの違いを並べると、性格がはっきりします。

ひとことで言えば 「置いたら勝手に動く、止められないプラグイン」 です。

WordPress の公式ドキュメント Must-use Plugins（WordPress Developer Resources） にも、こう明記されています。

Loaded by PHP, in alphabetical order, before normal plugins, meaning API hooks added in an mu-plugin apply to all other plugins.

（アルファベット順に、通常のプラグインより先に読み込まれる。つまり mu-plugin で追加したフックは他のすべてのプラグインに適用される）

出典: https://developer.wordpress.org/advanced-administration/plugins/mu-plugins/

何のためにある仕組みなのか

「止められない」と聞くと不便に思えますが、これが必要になる場面は実際にあります。

つまり mu-plugins 自体はまっとうな仕組みで、それがあること自体は異常ではありません。 ここは誤解しないでいただきたい点です。

ではなぜ、セキュリティの話で名前が挙がるのか

検索すると、mu-plugins はしばしばセキュリティ記事に登場します。ここを正確に理解しておきましょう。

「置くと動く」ことが危険なのではない

まず前提として——攻撃者が wp-content に PHP ファイルを設置できる時点で、すでに何でもできる状態です。

mu-plugins に置かなくても、テーマの functions.php に1行足す、plugins/ に本物らしい名前のフォルダを作る、といった方法で同じことができてしまいます。mu-plugins だけが特別に危険な入口、というわけではありません。

本当の入口はどこか

セキュリティ企業 Patchstack が公開したレポート State of WordPress Security In 2026（2025年1年間のデータを集計）には、こんな数字が並んでいます。

出典: Patchstack「State of WordPress Security In 2026」（2026年2月公開／集計対象は2025年）

実際の玄関はここです。更新の止まったプラグイン、そして管理者アカウントのパスワード流出や使い回し。mu-plugins を心配する前に、こちらを閉めるほうが順番として先です。

それでも mu-plugins が厄介な理由

危険度ではなく、「気づきにくさ」と「消しにくさ」 です。

• 気づけない — プラグイン一覧を見て「怪しいものは入っていない」と確認したつもりになれてしまう
• 止められない — 見つけても管理画面から無効化できず、ファイルを直接消すしかない
• 消しても戻ることがある — 隠し管理者アカウントを再生成するコードが仕込まれていると、ユーザーを削除しても復活する
• 名前は自由に付けられる — 一覧に表示される名前や説明文はファイル内のコメントを読んでいるだけなので、「WordPress Core Cache」のような、それらしい名前を名乗れます

つまり mu-plugins は 「攻撃されやすくする」のではなく「攻撃されたことに気づきにくくし、居座られやすくする」。リスクの種類が違う、と理解しておくと正確です。

管理画面のタブだけでは足りない理由

ここからが、この記事でいちばんお伝えしたい部分です。先ほど「必須」タブで中身が確認できるとお伝えしました。ですが、このタブに出てこないファイルが存在します。

WordPress only looks for PHP files right inside the mu-plugins directory, and (unlike for normal plugins) not for files in subdirectories.

（WordPress は mu-plugins フォルダの直下にある PHP ファイルだけを見る。通常のプラグインと違い、サブフォルダの中は見ない）

出典: https://developer.wordpress.org/advanced-administration/plugins/mu-plugins/

自動で実行されるのは直下のファイルだけで、サブフォルダの中身は読まれません。そして管理画面の一覧も、同じく直下しか表示しません。ここに抜け道が生まれます。

実際に試してみました

ローカル環境で、こういう構成を作ってみました。

mu-plugins/
├── test-mu.php       ← 単独で動く
├── loader.php        ← test-sub/inner.php を読み込む
└── test-sub/
    └── inner.php     ← 単独では動かない

loader.php の中身はこれだけです。

<?php
/**
 * Plugin Name: 【検証用】ローダー
 */

// サブフォルダの中身は自動実行されないため、ここから明示的に読み込む
require __DIR__ . '/test-sub/inner.php';

<?php
/**
 * Plugin Name: 【検証用】ローダー
 */

// サブフォルダの中身は自動実行されないため、ここから明示的に読み込む
require __DIR__ . '/test-sub/inner.php';

この状態で管理画面を開くと、3つのファイルすべてが動作します。 inner.php も、loader.php に読み込まれてしっかり実行されました。ところが「必須」タブを見ると——

上の通知は inner.php（サブフォルダ）と test-mu.php の両方から出ています。それでも一覧は 「必須 (2)」の2件だけ。test-sub/inner.php はどこにも出てきません。

一覧には2つしか出ていないのに、実際は3つが動いている。

これが、管理画面だけを見て安心できない理由です。サブフォルダにファイルを置き、直下の小さなファイルから読み込ませれば、一覧に名前を出さないまま処理を実行できてしまいます。

ファイルを直接確認する手順

管理画面のタブは当たりを付けるのに便利ですが、確実なのはファイルを見ることです。

wp-content/mu-plugins/

不審なファイルが見つかったときは

明らかに身に覚えのないコードだった場合、順番が大切です。

消す前にバックアップを取る

サイト全体（ファイルとデータベースの両方）のバックアップを取ってください。証拠を残す意味もあります。どこから侵入されたのかを後から調べる手がかりになります。

消して終わりにしない

冒頭で触れたとおり、削除しても復活するタイプがあります。復活するということは、生成元のコードが別の場所にまだ残っているということです。mu-plugins だけを見ていても解決しません。あわせて次を確認してください。

• 管理者ユーザーの一覧 — 見覚えのないアカウントがないか
• すべてのパスワード変更 — 管理者、FTP、データベース
• wp-config.php の認証キー再発行 — 公式のジェネレーターで新しい値を生成して差し替えると、盗まれたログインセッションを無効化できます
• プラグインとテーマの更新状況 — 侵入経路になった可能性が高い場所です

もうひとつ知っておきたいこと：更新されません

セキュリティとは別に、運用上の注意点があります。公式ドキュメントにはこう書かれています。

Plugins in the must-use directory will not appear in the update notifications nor show their update status on the plugins page.

（must-use ディレクトリ内のプラグインは、更新通知に表示されず、プラグイン画面で更新状況も表示されない）

出典: https://developer.wordpress.org/advanced-administration/plugins/mu-plugins/

つまり mu-plugins に置いたコードは、新しいバージョンが出ても知らせてくれません。手動で確認して入れ替える必要があります。

便利さと引き換えに、管理の手間を引き受ける仕組みだということです。制作会社として使う場合は、何を入れたかを記録しておかないと、後任者が困ることになります。

まとめ

• mu-plugins は WordPress の正規の仕組み。あること自体は異常ではない
• 置くだけで動き、管理画面からは停止できない
• 通常のプラグイン一覧には出ないが、「必須」タブで確認できる
• ただし サブフォルダの中身はタブにも出ない。ファイルを直接見るのが確実
• 攻撃の入口ではなく 「侵入されたあとに気づきにくくする場所」。
  玄関にあたるのは、更新の止まったプラグインとパスワード管理
• 更新通知は出ないので、使うなら手動管理が前提

まずは管理画面を開いて、「必須」タブがあるかどうかだけでも見てみてください。無ければ、それが正常です。1分もかかりません。

知らない場所があると気になるものですが、仕組みを理解してしまえば、確認は難しくありません。

実践編へGO！

自分で mu-plugins を使う側になると、次はこんな疑問が出てきます。

「この処理、mu-plugins に書くべき？ 通常のプラグイン？ それとも functions.php？」

実は「mu-plugins でなければできないこと」は、ほとんどありません。ただし1つだけ、原理的に代替できないものがあります。