幽霊カラムの覚醒：`post_content_filtered` を利用した検索アーキテクチャの再定義
WordPressのコアデータベース、特に `wp_posts` テーブルを眺めたとき、多くの開発者がその存在を無視し、あるいは用途を見出せずに放置しているカラムがある。
`post_content_filtered` だ。
このカラムは、歴史的にはMarkdownからHTMLへの変換プロセスや、Gutenbergにおける「生のブロックデータ」の退避場所として予約されている側面があるが、標準のWordPressコアでは実質的に「未使用の広大な LONGTEXT 領域」として鎮座している。
我々シニアアーキテクトが直面する「数百万件のレコードにおける全文検索の劣化」という課題に対し、このカラムを「検索専用の正規化済みマテリアライズド・ビュー」として再定義することで、RDBMSの負荷を劇的に抑え、外部検索エンジン（Elasticsearch等）との同期効率を極限まで高める手法を詳説する。
—
1. 物理構造の視点：なぜ `post_content` への `LIKE` 検索は破綻するのか
MySQL（InnoDB）において、`post_content` に対する `LIKE ‘%query%’` は、インデックスを一切利用できないフルテーブルスキャン（Full Table Scan）を強制する。
- B+Treeインデックスの限界: `post_content` は通常 `LONGTEXT` であり、B+Treeのリーフノードに収まるサイズを遥かに超える。
- Buffer Poolの汚染: 数万行の `post_content` をメモリ（Buffer Pool）にロードし、CPUが正規表現や文字列照合を繰り返すことで、他の重要なクエリのキャッシュが追い出され、システム全体のスループットが低下する。
- ノイズの介在: `post_content` には “ といったブロックデリミタ、HTMLタグ、ショートコードが含まれる。これらは検索エンジンにとってはノイズであり、照合精度を著しく下げる。
ここで `post_content_filtered` を
「前処理済みプレーンテキスト・ストレージ」 として活用する戦略が浮上する。
—
2. アーキテクチャ：`post_content_filtered` を検索キャッシュ層として再定義する
この設計の肝は、
「書き込み時に計算コストを支払い、読み取り時のI/Oを最小化する」 ことにある。
実装戦略：保存時の正規化パイプライン
投稿が保存（`wp_insert_post_data`）される際、以下の処理をバックグラウンドまたは保存プロセス中に実行する。
1.
タグの完全除去: `strip_tags()` およびブロックデリミタの削除。
2.
ショートコードの展開（必要に応じて）: 検索対象に含めるべき動的コンテンツを静的文字列化。
3.
トークナイズ準備: 日本語であれば形態素解析（MeCab等）を通した分かち書きの適用、あるいは不要なストップワードの除去。
/
- post_content_filtered を検索最適化済みバッファとして活用する
- システムアーキテクトによる高度なフック実装
/
add_filter(‘wp_insert_post_data’, function( $data, $postarr ) {
// 自動保存やリビジョン生成時はスキップし、I/Oを節約
if ( defined(‘DOING_AUTOSAVE’) && DOING_AUTOSAVE ) return $data;
if ( $data[‘post_status’] === ‘inherit’ ) return $data;
// 1. 原典データの抽出
$raw_content = $data[‘post_content’];
// 2. 検索ノイズの除去
// GutenbergブロックのコメントアウトやHTMLタグを排除
$filtered_content = strip_tags( preg_replace(‘//’, ”, $raw_content) );
// 3. ショートコードの展開 (パフォーマンスと相談)
// 外部APIを叩くような重いショートコードがある場合は慎重に。
// ここでは純粋なテキスト抽出に留める。
$filtered_content = do_shortcode( $filtered_content );
// 4. 正規化 (Unicode NORMALIZE等)
if ( class_exists(‘Normalizer’) ) {
$filtered_content = Normalizer::normalize( $filtered_content, Normalizer::FORM_C );
}
// 5. カラムへの格納
// このデータは表示用ではなく、検索および外部エンジン同期専用である。
$data[‘post_content_filtered’] = mb_convert_kana($filtered_content, “rnsk”);
return $data;
}, 10, 2);
—
3. 外部検索エンジン（Elasticsearch/Algolia）との同期効率化
大規模システムにおいて、WordPressのDB自体に検索を負わせるのは下策だ。通常は Elasticsearch や OpenSearch を利用する。しかし、その同期プロセス（Indexing）がボトルネックになることが多い。
従来の課題
`wp_posts` からデータを抽出して外部に送る際、`post_content` をその場でパースすると、同期バッチの実行ごとに膨大なCPUリソースを消費する。
`post_content_filtered` による解決
このカラムに既に「検索されるべき純粋なテキスト」が格納されていれば、同期プロセスは
「単なる文字列コピー」 に昇華される。
— 外部エンジンへの同期クエリ
— 複雑なパースをSQL層やApp層で一切行わず、準備済みデータを抜くだけ
SELECT ID, post_title, post_content_filtered
FROM wp_posts
WHERE post_status = ‘publish’ AND post_modified_gmt > ‘2023-10-01 00:00:00’;
—
4. 低レイヤでのメリット：ストレージ・局所性の最適化
InnoDBのレコードフォーマット（Compact/Dynamic）において、`post_content` と `post_content_filtered` が共に大きくなれば、データはオフページ（Off-page storage）に溢れる。しかし、検索クエリが `post_content_filtered` のみを参照する場合、MySQLの内部オプティマイザは、インデックススキャンからプライマリキー経由で特定のカラムのみをフェッチする際のシーク時間を最適化できる。
また、`WP_Query` を拡張し、`posts_where` フックを利用して検索対象を `post_content` から `post_content_filtered` に差し替えることで、既存のプラグインとの互換性を保ちつつ、検索クエリの劇的な高速化が可能になる。
/
- 標準の検索クエリを post_content_filtered 狙い撃ちに書き換える
/
add_filter(‘posts_search’, function( $search, $wp_query ) {
if ( ! $wp_query->is_main_query() || ! $wp_query->is_search() || is_admin() ) {
return $search;
}
global $wpdb;
// post_content への参照を post_content_filtered へ置換
$search = str_replace(
“.post_content LIKE”,
“.post_content_filtered LIKE”,
$search
);
return $search;
}, 10, 2);
—
5. 結論：デッドスペースを「戦略的資産」へ
`post_content_filtered` カラムの活用は、単なるコードのハックではない。それは、WordPressというアプリケーション層が持つ「柔軟性」と、RDBMSが持つ「物理的な制約」の間にある摩擦を解消するための
アーキテクチャ・パターン である。
1.
書き込み時パース: 参照頻度が低い「保存」の瞬間に計算リソースを集中させる。
2.
検索時ノイズレス: インデックス効率を最大化し、MySQL Buffer Poolの無駄な消費を抑える。
3.
外部連携の高速化: 外部検索エンジンとのデータ同期パイプラインを「軽量なI/O」に変貌させる。
この「幽霊カラム」を使いこなすことこそ、数百万PVを捌く大規模エンタープライズ・システムにおける WordPress 最適化の極致といえる。我々エンジニアの仕事は、用意された箱にデータを入れることではない。箱の性質を理解し、システムの限界を突破するためにその再定義を行うことにある。
