WordPress で「ちょっとした処理」を追加したいとき、書ける場所が3つあります。

どれに書いても動くことが多いので、なんとなく functions.php に書き続けているという方は少なくないはずです。筆者もそうでした。

この記事では、この3つをどう使い分けるかを整理します。結論から言うと、判断の軸は 「寿命」 と 「読み込み順」 の2つです。

先に結論：判断フロー

迷ったら、上から順に答えていけば決まります。

以下、それぞれの根拠を説明します。

mu-plugins にしかできないこと

先に、いちばん誤解されやすい点をはっきりさせておきます。

「管理画面から止められない」という特徴は有名ですが、それは運用上の都合であって、技術的な制約ではありません。多くの処理は通常のプラグインでも書けます。

ただし、原理的に mu-plugins にしかできないことが1つだけあります。読み込み順です。

WordPress の起動順を見てみる

WordPress のコアファイル wp-settings.php を読むと、順番がはっきり書かれています。

mu-plugins は、通常のプラグインが1つも読み込まれていない時点で動きます。

この順番はプラグインの優先度設定では変えられません。「通常プラグインの中でいちばん先に動かす」ことはできても、「通常プラグインが読み込まれる前に動く」ことはできないからです。

具体例：プラグインの読み込み自体を止める

「このプラグインを、管理画面以外では読み込ませたくない」——表示速度のために、こうしたいことがあります。

<?php
/**
 * Plugin Name: 条件付きプラグイン読み込み
 */

add_filter('option_active_plugins', function ($plugins) {
    // 管理画面以外では重いプラグインを読み込まない
    if (!is_admin()) {
        $target = 'heavy-plugin/heavy-plugin.php';
        $key = array_search($target, $plugins, true);
        if ($key !== false) {
            unset($plugins[$key]);
        }
    }
    return $plugins;
});

<?php
/**
 * Plugin Name: 条件付きプラグイン読み込み
 */

add_filter('option_active_plugins', function ($plugins) {
    // 管理画面以外では重いプラグインを読み込まない
    if (!is_admin()) {
        $target = 'heavy-plugin/heavy-plugin.php';
        $key = array_search($target, $plugins, true);
        if ($key !== false) {
            unset($plugins[$key]);
        }
    }
    return $plugins;
});

この処理は 通常のプラグインにも functions.php にも書けません。「どのプラグインを読み込むか」を決める処理そのものに割り込む必要があるため、その判断が終わったあとに動くコードでは手遅れなのです。

同じ理由で、次のようなケースも mu-plugins の出番です。

• 早い段階で定数を定義したい（WP_CACHE など、後から定義しても効かないもの）
• 他のプラグインより先にフックを登録しておきたい
• 他のプラグインの動作そのものを制御したい

配布プラグインを mu-plugins に入れられるか

ここで多くの方が一度考えることに触れておきます。

「公開されているプラグインを mu-plugins に入れて、止められないようにできないか？」

まず構造の問題

配布プラグインは plugins/akismet/akismet.php のようにフォルダに入っています。mu-plugins が自動実行するのは直下の PHP だけなので、フォルダごと置いても読み込まれません。

これはローダーを1枚置けば回避できます。

<?php
// mu-plugins/load-example.php
require WPMU_PLUGIN_DIR . '/example-plugin/example-plugin.php';

<?php
// mu-plugins/load-example.php
require WPMU_PLUGIN_DIR . '/example-plugin/example-plugin.php';

……が、本当の問題はここからです。

動かない・危険な3つの理由

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

例外的に成立するケース

ひとつだけ、本来の設計意図に沿う用途があります。マルチサイトで全サイトに強制適用したい場合です。

マルチサイトでは各サイトの管理者がプラグインを停止できますが、mu-plugins に置けば停止という選択肢自体がなくなります。mu が本来 “multi-user”（現在の multisite）の略だったことからも、ここが出発点だと分かります。

「止められたくない」だけなら、こう書く

単一サイトで「顧客に停止されたくない」という目的なら、プラグインは通常の場所に置いたまま、停止リンクだけを消すほうが安全です。

<?php
/**
 * Plugin Name: プラグイン停止の防止
 */

add_filter('plugin_action_links', function ($actions, $plugin_file) {
    $protected = ['contact-form-7/wp-contact-form-7.php'];
    if (in_array($plugin_file, $protected, true)) {
        unset($actions['deactivate']);
    }
    return $actions;
}, 10, 2);

<?php
/**
 * Plugin Name: プラグイン停止の防止
 */

add_filter('plugin_action_links', function ($actions, $plugin_file) {
    $protected = ['contact-form-7/wp-contact-form-7.php'];
    if (in_array($plugin_file, $protected, true)) {
        unset($actions['deactivate']);
    }
    return $actions;
}, 10, 2);

これなら更新は普通に届き、有効化フックも正常に動きます。目的だけを達成できます。

そしてこれは、mu-plugins の正しい使い方の好例でもあります。自作の小さなコードを置いて、他のプラグインの挙動を制御する——先ほどの「通常プラグインより先に動く」性質が活きる場面です。

つまり mu-plugins は「自作コード置き場」

ここまで見ると、性格がはっきりします。

mu-plugins のデメリット（更新されない・有効化フックが動かない）は、そのほとんどが配布プラグイン固有の問題です。自作の小さなコードなら、

• 更新 → 自分で管理しているので通知は不要
• 有効化フック → テーブル作成などしていないので使っていない

どちらも無害になります。

だから mu-plugins は「配布プラグインを入れる場所」ではなく、「自作の制御コードを置く場所」として使うのが本筋です。次に挙げる例がすべて自作の小さなコードなのは、偶然ではありません。

「できるが、mu-plugins のほうが確実」なこと

実務では、こちらが大半を占めます。技術的には他でも書けますが、止められると困るから mu-plugins に置く、という判断です。

<?php
/**
 * Plugin Name: 環境別メール制御
 */

// ステージング環境ではメールを送信しない
add_filter('pre_wp_mail', function ($return) {
    if (defined('WP_ENVIRONMENT_TYPE') && WP_ENVIRONMENT_TYPE === 'staging') {
        return false; // 送信をキャンセル
    }
    return $return;
});

<?php
/**
 * Plugin Name: ログイン失敗の記録
 */

add_action('wp_login_failed', function ($username) {
    $log = sprintf(
        "[%s] ログイン失敗: %s / IP: %s\n",
        current_time('Y-m-d H:i:s'),
        $username,
        $_SERVER['REMOTE_ADDR'] ?? 'unknown'
    );
    error_log($log, 3, WP_CONTENT_DIR . '/login-failed.log');
});

<?php
/**
 * Plugin Name: 管理バー制御
 */

add_action('after_setup_theme', function () {
    if (!current_user_can('administrator')) {
        show_admin_bar(false);
    }
});

ここから本題に入ります。

判断の軸は「寿命」

3つの置き場所は、処理が生き続ける条件が違います。

functions.php はテーマの一部です。テーマを切り替えた瞬間、そこに書いた処理はすべて止まります。ここから、判断の軸が導けます。

先ほどの例に当てはめてみる

functions.php はいちばん最後に読まれる

先ほどの起動順を思い出してください。

1. mu-plugins          （498行）
2. 通常のプラグイン     （574行）
3. functions.php       （739行）  ← いちばん最後
4. init                （771行）

functions.php は最後です。プラグインより後に読まれるので、「プラグインの読み込みに割り込む」ような処理は書けません。間に合わないのです。

逆に言えば、functions.php はすべてが揃った状態で動きます。プラグインが提供する関数を安心して使えるので、テーマの表示に関わる処理を書くには最も自然な場所です。

functions.php が向いているもの

そのテーマの見た目・構造に紐づくものです。

• アイキャッチ画像のサイズ指定（add_image_size）
• メニューやウィジェットの登録
• テーマ専用のショートコード
• CSS / JavaScript の読み込み

これらは「テーマが変われば意味を失う」処理なので、テーマと一緒に消えるのが正しい挙動です。プラグインに書くと、テーマを変えたときに不要な処理が残り続けてしまいます。

早見表

それぞれの「代償」

どれを選んでも、引き換えに失うものがあります。ここを知らずに選ぶと後で困ります。

まとめ

• mu-plugins にしかできないのは「通常プラグインより先に動く」ことだけ。それ以外は他でも書ける
• functions.php はテーマの一部。テーマを変えると消える。だから「テーマに紐づくもの」を書く
• functions.php はいちばん最後に読まれる。プラグインの読み込みには割り込めないが、すべて揃った状態で動く
• 使い分けは 「テーマを変えても残るべきか」→「止められると困るか」 の順で判断する
• 通常プラグインで足りるならそれが基本。mu-plugins は明確な理由があるときだけ

「なんとなく functions.php」から抜け出すと、後任者にも説明できる構成になります。なぜそこに書いたかを説明できることが、いちばん実用的な基準かもしれません。