WordPressについて、AIの広がりで立場が弱くなるという見方が出ています。
WordPressは、全Webサイトの4割という大きなシェアを持つものの、構築と管理の負荷が重いからです。
とくに、更新時にプラグインが不具合を起こすことがある、ということが大きいです。
1. WordPressの課題は運用の難しさ
WordPressの公式サポートには、トラブル時の基本手順として、テーマを切り替え、すべてのプラグインを停止し、1つずつ戻して原因を切り分ける流れが示されています。
これは、プラグイン競合が実運用で起こりうる問題だと示しています。
同じく公式サポートでは、不要なプラグインを削除すると、セキュリティと速度、競合回避に役立つと説明されています。
Patchstackの2025年レポートでも、脆弱性の多くがプラグイン由来という傾向が示されています。
2. Sanity移行で何が変わるか
WordPressの移行先の一つに、SanityというヘッドレスCMSが取り上げられることがあります。
Sanity は ヘッドレスCMS（headless CMS） と呼ばれる種類のコンテンツ管理システムです。
ヘッドレスCMS とはコンテンツの保存・管理だけを行い、表示（フロントエンド）部分は別で用意したアプリやウェブサイト側で行う方式です。
伝統的な CMS がコンテンツと表示を一体で扱うのに対して、ヘッドレスCMS は API 経由でデータを取り出して表示側で自由に構築できる点が特徴です。
SanityのContent Lakeは、構造化したデータの保存と再利用を前提にしています。
クエリはGROQとGraphQLに対応し、リアルタイム配信も扱えます。
さらに、WordPressからSanityへの移行コースが公式に用意されています。
ただし料金は座席課金と従量課金の組み合わせです。
Growthプランは1席あたり月15ドルなので、規模が大きくなるほどコスト管理が必要になります。
3. ヘッドレスCMSと生成AIの相性
WordPress は従来型の CMS で、コンテンツの管理と表示が一体 になっており、管理画面からテーマやプラグインで簡単にサイト構築ができます。
一方で Sanity はコンテンツを 構造化データとして扱い、API 経由で利用する ため、サイトやアプリ、モバイルなど複数の表示先へ柔軟に配信できます。
コンテンツと表示を分離するヘッドレス設計のため、モダンな JavaScript フレームワークと連携した開発や、複雑なデータモデルの構築がしやすい点が特長です。
この設計は、AI活用との相性が良いと一般に言われます。
LLMは、意味単位に整理されたデータを扱う方が処理しやすい傾向があります。
Sanityでは「タイトル」「本文」「著者」「カテゴリ」などが明確に分かれており、検索・要約・分類・推薦などに活用しやすいです。
RAG（Retrieval-Augmented Generation：検索拡張生成）は、外部データを検索してから生成を行う手法です。SanityはAPI経由でコンテンツを取得できるため、ベクトル検索基盤やLLMと接続しやすい設計です。
4. AIはWordPressを置き換えるだけではない
一方で、WordPressが不利という意味ではありません。WordPressもREST APIを備えており、ヘッドレス構成にすることも可能です。ただし標準的な使い方では「表示前提のHTML中心データ」になりやすく、AI向けの再利用設計は追加設計が必要になることが多い、という違いがあります。
また、WordPress.com側もAI Website Builderを提供しており、数分でサイトを生成できる案内があります。
つまり、AIがWordPressを押し出す流れだけでなく、WordPress自身がAIを取り込んでいる流れも同時に進んでいます。
焦点は、WordPressが終わるかどうかの二択ではありません。
どの案件で選ばれにくくなるかを見たほうが実務に役立ちます。
短納期で小規模な案件では、AIサイトビルダーに置き換わる場面が増えます。
逆に、既存資産と運用ノウハウがある案件では、WordPressが引き続き有力です。