WordPressの限界を突破する：`wp_comments` の階層構造を再帰クエリなしで完全制覇する設計論
コードレビューをしていて、次のようなコードに出くわしたことはないだろうか。
// 🚨 絶対にやってはいけないアンチパターン
function get_comment_tree_recursive( $comment_id ) {
$children = get_comments( [ ‘parent’ => $comment_id ] );
foreach ( $children as $child ) {
// ネストの深さに応じて爆発的にクエリが増加する（N+1問題の極み）
$child->children = get_comment_tree_recursive( $child->comment_ID );
}
return $children;
}
コメントのツリー構造（階層返信）を表示したいがために、子コメントを再帰的に取得し、アプリケーション層やデータベース層で無数のクエリを投げる。この実装は、コメント数が数千件を超えた瞬間におそるべきデータベース負荷を引き起こし、MySQLのコネクションプールを枯渇させる。
テックリードとして言わせてもらう。WordPressのデフォルトのコメント機能は、小規模なブログを前提として作られており、大規模な議論やコミュニティサイトのスケールには耐えられない。
今回は、`wp_comments` テーブルの `comment_parent` カラムが持つ階層構造に対し、再帰クエリやN+1問題の呪縛から解放され、O(1)に近いパフォーマンスでツリー構造を構築するための「パス列挙（Path Enumeration）」および「クロージャテーブル（Closure Table）」の実装パターンを、プロダクションコードベースで解説する。
—
なぜWordPressデフォルトのツリー取得はスケールしないのか？
WordPressコアの `Walker_Comment` や `get_approved_comments()` は、全コメントを一度メモリ上にロードし、PHPのメモリ上でツリーを再構築するアプローチをとっている。
これは「コメント数がせいぜい数百件」であれば動く。しかし、数万件規模のデータベースにおいて `SELECT FROM wp_comments` を実行すること自体がメモリ（`memory_limit`）の無駄遣いであり、スケーラビリティの観点から論外だ。
データベースの構造を改変せず、インデックスを最大限に活かしつつ、高パフォーマンスな階層取得を実現するにはどうすればいいのか。答えは「リレーショナルデータベースの弱点である再帰を、アプリケーション層のスマートなデータ構造と適切なスキーマ拡張でバイパスすること」にある。
—
アプローチ1：パス列挙（Path Enumeration）パターン
もっとも手軽かつ効果的なのが、各コメントに「祖先からのパス」を保持させる手法だ。
例えば、ルートコメント（ID: 10）に対する返信（ID: 15）、さらにその返信（ID: 22）がある場合、最下層のコメントのパスは `”/10/15/22/”` のように表現する。
これを実現するために、`wp_commentmeta` を活用するか、カスタムテーブルを導入する。今回は既存のスキーマを汚さずに `wp_commentmeta` を利用した堅牢な実装を見ていこう。
パスを自動計算・保存するフック実装
コメントが挿入された瞬間に、親のパスを取得し、自身のパスをメタデータとして焼き付ける。
/
- コメント挿入時にパス列挙（Path Enumeration）用のメタデータを生成する
/
function wp_advanced_store_comment_path( $comment_id, $comment ) {
$parent_id = (int) $comment->comment_parent;
$path = ‘/’ . $comment_id . ‘/’;
if ( $parent_id > 0 ) {
$parent_path = get_comment_meta( $parent_id, ‘_comment_path’, true );
if ( $parent_path ) {
$path = $parent_path . $comment_id . ‘/’;
} else {
// フォールバック：親のパスが存在しない場合は親IDを起点にする
$path = ‘/’ . $parent_id . ‘/’ . $comment_id . ‘/’;
}
}
update_comment_meta( $comment_id, ‘_comment_path’, $path );
// 階層の深さ（Depth）も同時に保存しておくとUI描画時に極めて有利
$depth = substr_count( $path, ‘/’ ) – 1;
update_comment_meta( $comment_id, ‘_comment_depth’, $depth );
}
add_action( ‘wp_insert_comment’, ‘wp_advanced_store_comment_path’, 10, 2 );
パスを使った特定コメントの子孫一括取得クエリ
この設計にしておけば、あるコメントの「全ての子孫（サブツリー）」を取得したい場合、再帰クエリを使う必要は一切ない。LIKE検索（プレフィックス一致）だけで一撃で取得できる。
/
- 指定したコメントの全子孫を1回のクエリで取得する
- @param int $comment_id 起点となるコメントID
- @return array WP_Commentの配列
/
function wp_advanced_get_comment_descendants( $comment_id ) {
global $wpdb;
$target_path = ‘/’ . $comment_id . ‘/’;
// プレフィックス一致（LIKE ‘…/%’）により、インデックスは効きにくいが
// 再帰クエリやPHP側でのループに比べ、MySQLのC言語レベルの処理で完結するため圧倒的に高速
$sql = $wpdb->prepare(
“SELECT c.
FROM {$wpdb->comments} c
INNER JOIN {$wpdb->commentmeta} m ON c.comment_ID = m.comment_id
WHERE m.meta_key = ‘_comment_path’
AND m.meta_value LIKE %s
AND c.comment_approved = ‘1’
ORDER BY c.comment_date_gmt ASC”,
‘%’ . $wpdb->esc_like( $target_path ) . ‘%’
);
$results = $wpdb->get_results( $sql );
return array_map( function( $comment ) {
return new WP_Comment( $comment );
}, $results );
}
—
アプローチ2：最高峰のパフォーマンスを誇る「クロージャテーブル（Closure Table）」
大規模エンタープライズ向けのシステム開発において、パス列挙の `LIKE` 検索ですらミリ秒単位の遅延が許されない場合がある。そこで登場するのがクロージャテーブル設計だ。
階層関係の「すべての親子ペア」を別テーブルに全列挙する。
例えば、`A -> B -> C` という構造であれば、以下のレコードを交差テーブル（例: `wp_comment_tree_paths`）に保持する。
| ancestor | descendant | depth |
| :— | :— | :— |
| A | A | 0 |
| B | B | 0 |
| C | C | 0 |
| A | B | 1 |
| B | C | 1 |
| A | C | 2 |
この設計の美しさは、「どの階層の取得であっても、結合（JOIN）と単純な等価比較（=`=`）のみで完結し、インデックスが100%機能する」という点にある。
1. 専用クロージャテーブルの定義（アクティベーション時などの処理）
function wp_create_comment_closure_table() {
global $wpdb;
$table_name = $wpdb->prefix . ‘comment_tree_paths’;
$charset_collate = $wpdb->get_charset_collate();
$sql = “CREATE TABLE IF NOT EXISTS {$table_name} (
ancestor bigint(20) unsigned NOT NULL,
descendant bigint(20) unsigned NOT NULL,
depth int(11) unsigned NOT NULL DEFAULT 0,
PRIMARY KEY (ancestor, descendant),
KEY descendant (descendant),
KEY depth (depth)
) {$charset_collate};”;
require_once( ABSPATH . ‘wp-admin/includes/upgrade.php’ );
dbDelta( $sql );
}
2. コメント投稿時のクロージャテーブル更新ロジック
新しいコメントが挿入されたとき、親の全祖先情報を引き継いでレコードを挿入する。
function wp_closure_insert_comment( $comment_id, $comment ) {
global $wpdb;
$table_name = $wpdb->prefix . ‘comment_tree_paths’;
$parent_id = (int) $comment->comment_parent;
// 自分自身の自己参照レコードを挿入 (depth = 0)
$wpdb->insert( $table_name, [
‘ancestor’ => $comment_id,
‘descendant’ => $comment_id,
‘depth’ => 0,
] );
if ( $parent_id > 0 ) {
// 親の全祖先を取得し、新しいコメントへのパスをバルクインサート
$query = $wpdb->prepare(
“SELECT ancestor, depth FROM {$table_name} WHERE descendant = %d”,
$parent_id
);
$ancestors = $wpdb->get_results( $query );
if ( $ancestors ) {
$values = [];
$placeholders = [];
foreach ( $ancestors as $ancestor ) {
$placeholders[] = “(%d, %d, %d)”;
$values[] = $ancestor->ancestor;
$values[] = $comment_id;
$values[] = $ancestor->depth + 1;
}
$sql = “INSERT INTO {$table_name} (ancestor, descendant, depth) VALUES ” . implode( ‘, ‘, $placeholders );
$wpdb->query( $wpdb->prepare( $sql, $values ) );
}
}
}
add_action( ‘wp_insert_comment’, ‘wp_closure_insert_comment’, 10, 2 );
3. クロージャテーブルを用いた爆速ツリー取得
この構造を使えば、特定のコメントのサブツリー全体、あるいは特定の深さ（Depth）までのコメントを、完全なインデックス駆動型クエリで一瞬で取得できる。
/
- クロージャテーブルを使って指定コメントの全子孫を爆速で取得
/
function wp_closure_get_descendants( $comment_id, $max_depth = null ) {
global $wpdb;
$paths_table = $wpdb->prefix . ‘comment_tree_paths’;
$comments_table = $wpdb->comments;
$sql = “SELECT c., p.depth
FROM {$comments_table} c
INNER JOIN {$paths_table} p ON c.comment_ID = p.descendant
WHERE p.ancestor = %d
AND p.descendant != %d”; // 自分自身を除外する場合
$params = [ $comment_id, $comment_id ];
if ( $max_depth !== null ) {
$sql .= ” AND p.depth <= %d";
$params[] = $max_depth;
}
$sql .= " ORDER BY p.depth ASC, c.comment_date_gmt ASC";
$results = $wpdb->get_results( $wpdb->prepare( $sql, $params ) );
return array_map( function( $item ) {
return new WP_Comment( $item );
}, $results );
}
—
テックリードからの実務的アドバイス：キャッシュ戦略の統合
どれほど美しいクエリを書いても、データベースにヒットする回数が多いほど大規模トラフィックには耐えられない。上記のクロージャテーブルやパス列挙とオブジェクトキャッシュ（Redis / Memcached）を組み合わせるのが、プロダクション環境におけるベストプラクティスだ。
1. トランジェント/オブジェクトキャッシュのキー設計:
`”comment_tree_{$post_id}_{$root_comment_id}”` のようなキーで、ツリー構造に整形済みの多次元配列（あるいはフラットな結果セット）をキャッシュする。
2. キャッシュパージ（無効化）のトリガー:
`wp_insert_comment` や `edit_comment`、`delete_comment` のフックをフックし、該当する親ツリーのキャッシュグループ（例: `wp_comment_tree` グループ）を `wp_cache_flush_group()` や `wp_cache_delete()` で確実にパージする。
function wp_clear_comment_tree_cache( $comment_id ) {
$comment = get_comment( $comment_id );
if ( $comment ) {
// 投稿ID単位のコメントツリーキャッシュをクリア
wp_cache_delete( ‘comment_tree_’ . $comment->comment_post_ID, ‘custom_comments’ );
}
}
add_action( ‘wp_insert_comment’, ‘wp_clear_comment_tree_cache’ );
add_action( ‘edit_comment’, ‘wp_clear_comment_tree_cache’ );
add_action( ‘delete_comment’, ‘wp_clear_comment_tree_cache’ );
—
結びにかえて
WordPressは「ブログエンジン」として生まれながらも、適切なアーキテクチャ設計を行えば、大規模なエンタープライズWebアプリケーションのコアとして十分に機能する。
再帰クエリやN+1問題といった「データベースに無駄な思考を強いる実装」は、今日のWebエンジニアリングにおいては技術的負債でしかない。
今回紹介したパス列挙あるいはクロージャテーブルの概念を導入し、DBのポテンシャルを極限まで引き出した堅牢なコードベースを構築してほしい。コードレビューで「なぜこのクエリなのか」と聞かれたとき、システムの裏側にある数学的・構造的優位性をよどみなく語れるエンジニアであれ。