WP_Queryの深淵：`fields => ‘ids’` vs `get_posts()` のメモリ実測と低レイヤ最適化
WordPressの拡張において、数万件以上の投稿（Post）を扱うデータセットに直面した瞬間、多くの開発者はパフォーマンスの壁に突き当たる。
特に `WP_Query` のインスタンス生成、あるいはそれを内包するラッパー関数 `get_posts()` の無思慮な呼び出しは、PHPランタイムのメモリリミットを容易に食潰し、MySQLサーバへの過大なI/O負荷を引き起こす。
本稿では、オブジェクト生成コスト、MySQLのクエリプラン、そしてPHPのガベージコレクション（GC）の挙動という低レイヤの視点から、`WP_Query( array( ‘fields’ => ‘ids’, … ) )` と `get_posts()` の実態を徹底的に解剖し、大規模データセットにおける真の最適解を導き出す。
—
1. `get_posts()` の正体とメモリバーストのメカニズム
多くの初中級プログラマは、`get_posts()` が軽量なユーティリティ関数であると誤認している。しかし、その内部実装を覗けば、それが `WP_Query` クラスの単なるシンタックスシュガーに過ぎないことが即座に判明する。
// wp-includes/post.php の簡略化された実体
function get_posts( $args = null ) {
$defaults = array(
‘suppress_filters’ => false,
‘posts_per_page’ => 5,
// … 他のデフォルト値
);
$r = wp_parse_args( $args, $defaults );
if ( empty( $r[‘posts_per_page’] ) ) {
$r[‘posts_per_page’] = -1;
}
$my_query = new WP_Query();
return $my_query->query( $r );
}
問題の根源は、`$my_query->query()` が最終的に `WP_Post` オブジェクトの配列を生成する点にある。
デフォルトの挙動において、`WP_Query` はデータベースから取得した行データを基に、`WP_Post::get_instance()` を介してインスタンスのキャッシュプール（`$wp_object_cache`）を汚染しながら、メモリ上に重厚なオブジェクト構造を展開する。
オブジェクト1つあたりのメモリフットプリント
1つの `WP_Post` オブジェクトは、データベースの `wp_posts` テーブルのカラム群（約50個のプロパティ）に加え、動的に追加されるカスタムメタデータやタクソノミ情報のプレースホルダを保持する。
さらに、PHPのオブジェクトオーバーヘッド（Zend Engineにおける `_zval_struct` と `zend_object` の構造体サイズ）を考慮すると、1つの投稿オブジェクトはおおよそ 15KB 〜 30KB のメモリを消費する。
もし `posts_per_page => 1000` でこれを実行した場合、クエリ結果だけで 15MB〜30MB のメモリが即座に割り当てられ、他のプラグインやコアの処理と合算されることで、あっさり `memory_limit` の閾値を超えることになる。
—
2. `fields => ‘ids’` の内部挙動とSQLレベルでの最適化
このメモリ枯渇問題に対する最初の処方箋が、`’fields’ => ‘ids’` の指定である。
$post_ids = get_posts( array(
‘post_type’ => ‘post’,
‘posts_per_page’ => 1000,
‘fields’ => ‘ids’,
) );
このパラメータを指定した場合、`WP_Query` が発行するSQLクエリの `SELECT` 句は、劇的な変化を遂げる。
生成されるSQLの比較
デフォルト状態 (`fields` 未指定):
SELECT wp_posts. FROM wp_posts WHERE 1=1 AND wp_posts.post_type = ‘post’ AND wp_posts.post_status = ‘publish’ ORDER BY wp_posts.date DESC LIMIT 0, 1000
全てのカラムデータを転送し、PHP側で `WP_Post` インスタンスへマッピングする。
`fields => ‘ids’` 指定時:
SELECT wp_posts.ID FROM wp_posts WHERE 1=1 AND wp_posts.post_type = ‘post’ AND wp_posts.post_status = ‘publish’ ORDER BY wp_posts.date DESC LIMIT 0, 1000
低レイヤにおけるメリット
1. ネットワーク帯域とI/Oの削減: MySQLサーバからPHPランタイムへ転送されるデータ量が、行全体（数百バイト〜数KB）からプライマリキーのID（整数値）のみへと極小化される。
2. PHPメモリの劇的節約: `WP_Post` オブジェクトの生成が完全にバイパスされ、返り値は単なる整数値の配列（`array of integers`）になる。Zend Engineの配列構造は、オブジェクト構造と比較して圧倒的にメモリ効率が良い。
3. オブジェクトキャッシュの非汚染: `WP_Post` インスタンスが生成されないため、オブジェクトキャッシュのメモリ領域を不必要に圧迫しない。
—
3. さらなる極限：直接SQLを発行するアプローチとの比較
ここまで読んだシニアエンジニアであれば、「そもそも `WP_Query` を使う必要はあるのか？ `$wpdb->get_col()` で直接SQLを叩いた方が速いのではないか？」という疑問を持つはずだ。
確かに、極限のパフォーマンスを追求する場合、`WP_Query` が内部で行う複雑なパース処理（フックの実行、SQLの構築、キャッシュの検証）はオーバーヘッドになり得る。
global $wpdb;
$post_ids = $wpdb->get_col(
“SELECT ID FROM {$wpdb->posts} WHERE post_type = ‘post’ AND post_status = ‘publish’ ORDER BY post_date DESC LIMIT 1000”
);
`WP_Query( fields => ‘ids’ )` vs `$wpdb->get_col()` のトレードオフ
| 評価軸 | `WP_Query( ‘fields’ => ‘ids’ )` | `$wpdb->get_col()` (直接SQL) |
| :— | :— | :— |
| 拡張性 / フィルタリング | `posts_where` や `posts_clauses` などのフックが完全に機能する。 | フックをバイパスするため、サードパーティ製プラグインの介入を無視する。 |
| セキュリティ | `$wpdb->prepare()` を意識せずとも、コア側で適切にエスケープされる。 | 開発者が自前で `$wpdb->prepare()` を用いてSQLインジェクションを防ぐ必要がある。 |
| 実行速度 | フックの処理コスト分、わずかに遅い。 | 最速。データベースに直接最小限のクエリを投げる。 |
| 保守性 | WordPress標準の作法に則っており、将来のコアアップデートに強い。 | スキーマ変更やWordPressのクエリキャッシュ機構の変更に影響を受けやすい。 |
ビジネスロジックやプラグインの互換性を担保する必要がある環境において、`WP_Query` の `fields => ‘ids’` は、「安全性とパフォーマンスの最も美しい妥協点」と言える。
—
4. 実務におけるベストプラクティス：ID取得後の効率的なデータロード
IDだけを取得したものの、最終的にその投稿のデータを処理しなければならないケースがほとんどだろう。ここで全てのIDに対して `get_post( $id )` をループで呼び出すのは、最悪のアンチパターン（N+1問題の発生）である。
// ❌ 絶対にやってはいけないアンチパターン (N+1問題)
$ids = get_posts( array( ‘fields’ => ‘ids’, ‘posts_per_page’ => 100 ) );
foreach ( $ids as $id ) {
$post = get_post( $id ); // ループ内で毎回キャッシュ/DBを参照、場合によってはクエリ発火
// 処理…
}
正解：一括キャッシュウォーミングとバッチ処理
WordPressには、複数IDの投稿データを一括してメモリ上にロードし、オブジェクトキャッシュを効率的に満たす関数 `_prime_post_caches()` が存在する。
// ⭕ 推奨される極限最適化アプローチ
$post_ids = get_posts( array(
‘post_type’ => ‘post’,
‘posts_per_page’ => 500,
‘fields’ => ‘ids’,
‘no_found_rows’ => true, // ページネーション用のSQL_CALC_FOUND_ROWSを無効化し、クエリを高速化
) );
if ( ! empty( $post_ids ) ) {
// キャッシュを一度にプライミング（ウォームアップ）する
_prime_post_caches( $post_ids );
// 関連するメタデータも一括プリロードする場合
update_meta_cache( ‘post’, $post_ids );
foreach ( $post_ids as $id ) {
// すでにキャッシュ上に存在するため、DBアクセスは発生しない
$post = get_post( $id );
// メモリ効率を意識したデータ処理
process_heavy_payload( $post );
}
// 大規模データ処理の鉄則：メモリリークを防ぐため、ループごとに明示的に参照をクリア
unset( $post_ids );
}
さらに、`no_found_rows => true` を指定している点に注目してほしい。デフォルトの `WP_Query` は、総ヒット数を計算するために内部で `SQL_CALC_FOUND_ROWS` を付与したクエリを発行するが、これは大規模なインデックスを持つテーブルにおいてMySQLのクエリパフォーマンスを著しく低下させる元凶となる。IDのリストを取得してバッチ処理を行う文脈においては、ページネーションの総数カウントは不要であることが多いため、このフラグは必ず立てるべきである。
—
5. 結論
WordPressの内部構造を熟知したエンジニアにとって、パフォーマンスチューニングとは「無駄なレイヤを剥ぎ取り、リソースのボトルネックを最小化する作業」に他ならない。
1. `get_posts()` は万能のナイフではない。 大規模データセットにおいてデフォルトのオブジェクト生成を行うべきではない。
2. `’fields’ => ‘ids’` と `no_found_rows => true` の組み合わせにより、MySQLのI/OとPHPのメモリ割り当てを極限まで抑制せよ。
3. データを一括処理する際は、`_prime_post_caches()` を用いてN+1問題を回避しつつ、オブジェクトキャッシュをスマートに制御せよ。
この鉄則を胸に刻み、フレームワークの甘美な隠蔽背後に隠された「真のシステム挙動」をコントロールすることこそが、真のWordPressアーキテクトの仕事である。