WordPressの隠れたボトルネック：`wp_options`の`autoload=yes`が引き起こす初期化フェーズのメモリ枯渇と制圧手法
テックリードの私たちが大規模なWordPress案件のパフォーマンスチューニングに入る時、まず最初に疑うべきは重いプラグインでも複雑なクエリでもない。`wp_options`テーブルの`autoload = ‘yes’`が引き起こす、リクエスト初期化フェーズでのメモリ枯渇だ。
今回は、WordPressの起動メカニズムの核心にメスを入れ、なぜこの問題が起きるのか、そしてシステムを破綻させずにどう制圧すべきか、実務レベルのコードと共にロジカルに解説する。
—
1. 内部コアの仕組み：なぜ `autoload = ‘yes’` は悪魔の機能なのか？
WordPressがリクエストを受け付け、`wp_loaded`フックに至るまでの初期化シーケンス（Bootstrap Phase）を思い出してほしい。この極めてクリティカルなフェーズの最中、`WPانات`（WordPressのコア機能）はデータベースから何をしているのか。
答えは `wp_load_alloptions()` の実行である。
// wp-includes/option.php の内部挙動の概念
function wp_load_alloptions() {
global $wpdb;
// autoload = ‘yes’ のレコードをすべてメモリ（オブジェクトキャッシュ）にロードする
$alloptions = $wpdb->get_results( “SELECT option_name, option_value FROM $wpdb->options WHERE autoload = ‘yes'” );
// …
}
ここで致命的な問題が発生する。
`autoload = ‘yes’`が付与されたレコードは、アクセスされたページがトップページであろうが、REST APIのエンドポイントであろうが、管理画面の奥深くであろうが、例外なくすべてメモリ上に展開される。
プラグイン開発者が「設定値だからとりあえずautoloadしておこう」という安易なコード（例：`add_option( ‘my_plugin_setting’, $huge_array, ”, ‘yes’ );`）を書き続けた結果、どうなるか。
数メガバイトに及ぶシリアライズされた巨大なJSON、外部APIのキャッシュ、使われなくなったトランジェントの残骸が、毎リクエストのPHPメモリ（`memory_limit`）を無情にも圧迫する。OOM（Out of Memory）エラーの温床は、まさにここにある。
—.
2. 診断：肥大化したAutoloadオプションの特定クエリ
まずは、現在のデータベースがどれほど汚染されているかを定量的に測定する。以下のSQLを直接データベースに対して実行し、`autoload`領域の総容量と、犯人となっている個別オプションを特定せよ。
— 1. autoload全体の合計サイズ（KB / MB）を確認する
SELECT
ROUND(SUM(LENGTH(option_value)) / 1024 / 1024, 2) AS autoload_size_mb,
COUNT() AS total_autoload_options
FROM wp_options
WHERE autoload = ‘yes’;
— 2. 容量を圧迫している上位20件のオプションを特定する
SELECT
option_name,
ROUND(LENGTH(option_value) / 1024, 2) AS size_kb,
SUBSTRING(option_value, 1, 100) AS value_preview
FROM wp_options
WHERE autoload = ‘yes’
ORDER BY LENGTH(option_value) DESC
LIMIT 20;
もしここで、総容量が 1MBを超えている なら、あなたのWordPressはすでに黄信号だ。3MBを超えている場合、明らかに設計上の欠陥（Technical Debt）が存在する。
—
3. 解決策：不適切なautoloadの動的除外とデータ構造の適正化
根本的な解決策は2つある。
1. データベースレベルで `autoload = ‘no’` に変更する
2. コード側で不要なロードを防ぐ設計にリファクタリングする
特に、サードパーティ製プラグインが勝手に `autoload = ‘yes’` で巨大なデータを保存している場合、プラグインのアップデートで設定が上書きされるリスクがある。そのため、デプロイメント時やテーマの初期化フックで、これを強制的に無効化する防御的コードが有効だ。
プロダクションコード：特定の巨大学習データを自動的に `autoload = ‘no’` へ強制変更するスニペット
以下のコードは、特定の重いオプション名を監視し、意図せず `yes` に設定された場合に自動で `no` へ降格させる堅牢な実装である。`functions.php` やMU-Plugins（Must-Use Plugins）に配置せよ。
/
- Class AutoloadSanitizer
- 特定の重いオプションが自動ロードされるのを防ぎ、メモリ枯渇を未然に防ぐ防衛クラス。
/
class AutoloadSanitizer {
/
- 強制的に autoload = ‘no’ にすべきオプション名のホワイトリスト（またはブラックリスト）
- @var array
/
private static $target_options = [
‘some_heavy_plugin_cache’,
‘external_api_response_log’,
‘action_scheduler_logs’, // 例：肥大化しやすいログ系
];
/
- 初期化
/
public static function init() {
add_action( ‘updated_option’, [ __CLASS__, ‘check_and_demote_autoload’ ], 10, 3 );
add_action( ‘added_option’, [ __CLASS__, ‘check_and_demote_autoload_on_add’ ], 10, 2 );
}
/
- オプション更新時にautoloadステータスを監査・修正
- @param string $option_name
- @param mixed $old_value
- @param mixed $value
/
public static function check_and_demote_autoload( $option_name, $old_value, $value ) {
if ( in_array( $option_name, self::$target_options, true ) ) {
self::force_autoload_no( $option_name );
}
}
/
- オプション追加時にautoloadステータスを監査・修正
- @param string $option_name
- @param mixed $value
/
public static function check_and_demote_autoload_on_add( $option_name, $value ) {
if ( in_array( $option_name, self::$target_options, true ) ) {
self::force_autoload_no( $option_name );
}
}
/
- データベースを直接叩いて autoload を ‘no’ に書き換える
- ※ wp_load_alloptions のキャッシュクリアも同時に行う
- @param string $option_name
/
private static function force_autoload_no( $option_name ) {
global $wpdb;
// すでに ‘no’ ならクエリを発発行しない
$current_autoload = $wpdb->get_var(
$wpdb->prepare( “SELECT autoload FROM {$wpdb->options} WHERE option_name = %s”, $option_name )
);
if ( $current_autoload === ‘yes’ ) {
$wpdb->update(
$wpdb->options,
[ ‘autoload’ => ‘no’ ],
[ ‘option_name’ => $option_name ],
[ ‘%s’ ],
[ ‘%s’ ]
);
// コアのオプションキャッシュをクリアして整合性を保つ
wp_cache_delete( ‘alloptions’, ‘options’ );
wp_cache_delete( $option_name, ‘options’ );
}
}
}
// 実行のフック
AutoloadSanitizer::init();
—
4. テックリードからの設計上の教訓とベストプラクティス
コードを書くだけがエンジニアリングではない。今後、このようなパフォーマンス劣化を二度と引き起こさないために、チーム全体で以下の開発規約を徹底してほしい。
1. `add_option()` の第4引数に無頓着にならないこと
新規にオプションを追加する際、第4引数（`$autoload`）を省略するとデフォルトで `’yes’` になる場合がある。数キロバイトを超えることが予想されるデータ（配列、オブジェクト、HTMLスニペットなど）を保存する場合は、必ず明示的に `’no’` を指定せよ。
// 良い例：大きなデータはautoloadさせない
update_option( ‘my_custom_large_setting’, $data, false ); // 第3引数はdeprecatedだが互換性のために空文字、第4引数にfalse(no)
※正しくは `update_option( $option, $value, $autoload )` のシグネチャ（WordPress 4.2以降）を意識し、第3引数に明示的に `false` または `’no’` を渡そう。
2. Transient APIの正しい理解
一時的なキャッシュデータを保存する際、Transient API（`set_transient`）は内部的に `wp_options` にデータを格納する。古いWordPressのバージョンや一部の設定では、これも `autoload = ‘yes’` になる挙動があった（※近年のコアでは自動的に `’no’` またはサイトビルトインのオブジェクトキャッシュへフォールバックするよう改善されているが、DBストレージエンジンを使用している場合は注意が必要）。
3. 外部オブジェクトキャッシュ（Redis / Memcached）の導入
どれだけ `autoload = ‘no’` に最適化しても、頻繁に参照されるオプションが多い場合、データベースへのヒット数は増える。Persistent Object Cacheを導入し、`wp_load_alloptions()` 自体のコストをメモリ上にバイパスするアーキテクチャこそが、真のモダンWordPressインフラストラクチャである。
結び
「動けばいい」というコードの積み重ねが、ピークタイムのデータベースを窒息させる。
コアの内部挙動――この場合、`wp_load_alloptions()` がブートストラップ時に何を引き受けているかを知る者だけが、真にスケーラブルなWordPressシステムを構築できる。
今すぐ本番環境の `wp_options` を確認し、不要な肥大化を断ち切れ。