WordPressのアーキテクチャ問題を改めて考える

以前、このブログでWordPressのセキュリティ崩壊とガバナンス危機について書いた。AIによる攻撃の質的変化、プラグインの脆弱性爆増、Matt Mullenweg氏の「焦土作戦」によるコア開発者の大量離脱——それらが重なり合い、WordPressが「崩壊の分岐点」に立っているという話だ。

今回はその続きとして、より根本的な問いに向き合いたい。なぜWordPressはここまで「ツギハギ」になってしまったのか。そして、そのアーキテクチャの問題は本当に解決できるのか。

WordPressは今もウェブの中心にいる——それが問題を複雑にする

W3Techsの2026年3月時点のデータによると、WordPressはウェブ全体の42.6%を支えている。無数の個人・企業サイトが今日もWordPressで動いている。

この圧倒的なシェアは、WordPressの強みであると同時に、進化を妨げる最大の枷でもある。コードベースを抜本的に変えれば、無数のサイトが壊れる。古いプラグインが動かなくなり、古いテーマが使えなくなる。だからWordPressは、レガシーなコードパターンを抱えたまま走り続けるしかない。

LAMPスタックという「2003年の設計」

WordPressが最初にリリースされたのは2003年だ。当時のウェブはブログが主流で、サーバーサイドレンダリングが当たり前だった。WordPressのアーキテクチャはLAMPスタック——Linux、Apache（またはNginx）、MySQL、PHPで構成されている。

この設計の本質的な問題は、ページが表示されるたびにPHPが実行され、MySQLにクエリを投げ、結果をHTMLに変換して返すという「毎回の動的生成」にある。キャッシュが正しく機能していれば省略できるが、ログインユーザーがいる場合、WooCommerceのカートが存在する場合、パーソナライズされたコンテンツがある場合——これらはキャッシュが効かない。毎回PHPが走り、毎回DBに問い合わせる。

これは2003年には合理的な設計だった。しかし現代のウェブはそれを前提としていない。ShopifyやDudaがエッジキャッシングをデフォルトで持ち、最初からパフォーマンスを念頭に置いて設計されているのと対照的だ。

Core Web Vitalsで最下位というファクト

Googleが定めるCore Web Vitals（CWV）は、ウェブパフォーマンスのSEO指標として今や無視できない。LCP（最大コンテンツの描画時間）、INP（次の描画までのインタラクション）、CLS（累積レイアウトシフト）の3つで構成され、2025年12月のGoogleコアアップデートではページエクスペリエンスシグナルの重みがさらに増した。

そのCWVのCMSランキングで、WordPressは最下位だ。

HTTP Archiveのデータによると、2025年時点でCWVの基準をクリアしているWordPressサイトは43〜44%にとどまる。1位のDudaは83%超、2位のShopifyは75%超。しかもWordPressの改善率は月間0.9%と、他のCMSの中で最も低い。

ここで冷静に考えてほしいのは、Shopifyが2位という事実だ。ECサイトは画像も多く、JavaScriptも重くなりがちなのに、なぜWordPressより速いのか。答えは単純で、Shopifyはパフォーマンスを設計の中心に据えたプラットフォームだからだ。WordPressはそうではなかった。

wp_optionsテーブルという時限爆弾

WordPressのアーキテクチャ問題の中で特に語られることが少ないのが、wp_optionsテーブルの問題だ。

wp_optionsはWordPressのあらゆる設定を格納するテーブルで、サイトのURL、テーマ設定、プラグインの設定、キャッシュデータなどが詰め込まれている。そこにautoloadというカラムがある。autoload='yes'に設定されたレコードは、WordPressが起動するたびに——つまり全ページの読み込みのたびに——まとめてSELECTされる。

理論上は合理的な設計だ。しかし現実はこうなる。プラグインを入れると設定がwp_optionsに書き込まれる。多くはautoload='yes'で。プラグインをアンインストールしても、行儀の悪いプラグインはデータを消してくれない。使われなくなったデータが延々と残り、毎回のページ読み込みで不要なデータをサーバーが引っ張ってくる。

あるケースでは、このautoloadデータが137MBに膨れ上がり、1秒間に1リクエストしか処理できなくなった。対処後は15リクエスト/秒まで回復したが、これは設計の問題だ。wp_optionsは「数千行を想定して設計されたテーブル」であり、プラグインが独自のテーブルを作らずwp_optionsに押し込む文化と相まって、時間の経過とともに肥大化する宿命にある。

理想のautoloadデータサイズは300KB〜1MB程度とされているが、運用年数が長いWordPressサイトほどこの上限を超えやすい。

プラグイン依存体質という構造問題

WordPressの強みはエコシステムだ。やりたいことがあればプラグインを探せばいい。しかしこれは同時にアーキテクチャの弱点でもある。

プラグインには品質基準の強制がない。コーディングスタンダードは存在するが、守らないプラグインも多数公開されている。インデックスのないDBクエリ、すべてのページで不要なアセットを読み込む処理、巨大なautoloadデータ——これらを持ち込むプラグインが野放しになっている。

この問題が前回の記事で書いたセキュリティ問題と直結している。2025年に発見されたWordPressエコシステムの新規脆弱性は1万1334件で、前年比42%増。そのうち96%がプラグイン・テーマ由来だ。Ultimate MemberのCVE-2023-3460（CVSSスコア9.8）に代表されるような「認証なしに管理者アカウントを作成できる」致命的な欠陥が、次々と発見されている。

パフォーマンスの問題とセキュリティの問題は、同じ根っこから生えている。「誰でもプラグインを作れる、品質の担保がない」という設計思想だ。

ページビルダーも同様だ。ElementorやDiviといったビジュアルエディターは、インストールするだけで膨大なHTML・CSS・JavaScriptをすべてのページに付加する。Elementorだけで解凍後20MB超のコードがWordPressに追加されるという報告もある。これがLCPやINPに直撃する。

「解決策」がすべてパッチワークである

WordPressのパフォーマンス問題への答えとして、よく語られるのはこんなセットだ。

キャッシュプラグイン（WP Rocket、LiteSpeed Cache）の導入、Cloudflare等のCDN活用、Redisによるオブジェクトキャッシュ、軽量テーマへの乗り換え、プラグインの精査と削減、wp_optionsのクリーンアップ、マネージドWordPressホスティング（Kinsta、WP Engine）への移行——これらは確かに効果がある。

しかしこれらはすべて「WordPressが本来持つ問題を補う」ための措置だ。ShopifyやDudaがデフォルトでエッジキャッシングを持ち、最初からCWVを念頭に置いたアーキテクチャで構築されているのに対して、WordPressは「何もしなければ遅い」が前提になっている。

しかも最適化の努力は簡単に破壊される。パフォーマンスを丁寧にチューニングしても、プラグインのアップデートひとつで元に戻ることがある。構造上、避けがたい問題だ。

後方互換性という呪縛、そして誰もそれを解けない

なぜWordPressはこの問題を根本から解決しないのか。答えのひとつは後方互換性の維持だ。ウェブの43%を支えるコードベースを抜本的に変えれば、無数のサイトが壊れる。

だが今は、それ以上の問題がある。「解決しようとする人間がいなくなった」という問題だ。

前回の記事で書いた通り、Mullenweg氏の「焦土作戦」によりAutomatticのコア貢献時間は週3,988時間からわずか45時間に削減された。削減率は約99%だ。さらに159人がアライメント・オファーで退職し、2025年4月には約280人が予告なしレイオフされた。コア開発を支えてきた人材が、一気に消えた。

WordCamp EU 2025では、コントリビューターのバーンアウトが深刻な問題として取り上げられた。そしてWordPress.orgアカウントの強制停止による恐怖が蔓延したコミュニティでは、「地雷原を歩きたくない」という空気が支配的になっている。

これが何を意味するか。脆弱性の発見ペースは42%増で加速しているのに、技術的負債を返済できる開発者が減り続けている。パフォーマンスの問題もセキュリティの問題も、「わかっているのに解決できない」状態が固定化しつつある。

ブロックエディターは「解」になり得るか

WordPressが「モダンなアーキテクチャ」へシフトしようとしている試みが、ブロックエディター（Gutenberg）とフルサイト編集だ。クラシックテーマがPHPテンプレートに依存するのに対し、ブロックテーマはより効率的なレンダリングを実現できる可能性がある。

ただしその移行は緩やかで、既存のエコシステムとの共存が前提になっているため、抜本的な変化にはほど遠い。何より、その開発を推進してきた人材が大量に離脱している今、移行のペースが上がる理由がない。

では、どう向き合うべきか

「WordPressをやめるべきだ」という結論は簡単だが、現実はそう単純ではない。既存のサイト資産、クライアントとの契約、運用チームのスキルセット——様々な制約がある。

ただ、新規プロジェクトについては明確にこう言える。今から新しいサイトを作るなら、WordPressを「デフォルト選択」にする時代は終わった。AstroのようなフロントエンドフレームワークとヘッドレスCMSの組み合わせは、パフォーマンス・セキュリティ・開発体験のすべてにおいてWordPressを上回る。静的HTMLをCDNから配信する構成は、PHPの脆弱性をそもそも持ち込まない。Mullenweg氏の「裁判所命令」や「アカウント強制停止」に一喜一憂するリスクとも、構造的に無縁になれる。

既存サイトを引き続きWordPressで運用するなら、最低限の覚悟が必要だ。プラグインの更新は「週次」ではなく「当日対応」に切り替えること。脆弱性公開から攻撃開始までの中央値はわずか5時間だ。WAFの導入、使っていないプラグインの即時削除、wp_optionsの定期的なクリーンアップ——これらは「やった方がいい」ではなく「やらなければ危険」になっている。

おわりに

WordPressのアーキテクチャ問題は、技術的な話であると同時に、「大規模なオープンソースプロジェクトが時代の変化にどう対応するか」という問いでもある。

後方互換性という制約、プラグイン文化という遺産、そしてガバナンス危機による人材流出——これらが重なった今、WordPressのアーキテクチャ問題が「自然に解決される」シナリオを描くのは難しい。

ひび割れたロゴに絆創膏を貼り続けることはできる。しかしその絆創膏を貼る人間が減り、ひびが増えるペースが上がっているとしたら、その先に何があるかは想像に難くない。

惰性でWordPressを選ぶのをやめることが、最初の一歩だと思っている。