WordPress は、ソフトウェアとしてではなく、自動的な答えとしては死んだのです。
この区別は重要です。「WordPress は死んだ」というのを文字通りの市場主張として言えば、データはそれを否定します。W3Techs によると、2026 年 6 月時点で、WordPress は既知の CMS を持つ Web サイトの 59.2%、すべての Web サイトの 41.5% を動かしています。それを死んでいると呼ぶことはできません。
しかし、2026 年に Web サイトを構築する場合、かつての反射的な選択は誤っていると感じ始めます。クライアントが求めるのは、高速なサイト、カスタムレイアウト、クリーンな SEO、いくつかの統合、そして 10 個ものプラグインを必要としない編集ワークフローです。かつては、カスタムコードは遅く高価だったため、答えは WordPress でした。AI がその計算式を変えたのです。
Cloudflare の EmDash は、この変化を無視することをさらに難しくしています。Cloudflare は WordPress に価値がないと言っているのではありません。次の CMS は TypeScript であり、サーバーレスで、Astro を活用し、プラグインはサンドボックス化され、初日から AI エージェント向けに構築されるべきだと言っているのです。
私は今でも WordPress を尊重しています。適切なプロジェクトであれば、今でも使うでしょう。しかし、もはやそれがデフォルトであるべきだとは思いません。
デフォルトとしての WordPress が死んだ理由
WordPress が勝ったのは、技術者でない人々に公開する力を与えたからです。それは真のブレークスルーでした。テーマをインストールし、ページビルダーを追加し、ブログ記事を投稿し、フォームを追加し、SEO メタデータを追加し、サイトをクライアントに引き渡すことができました。
しかし、その売り文句は多くのビジネスサイトにとって色あせてしまいました。
シンプルなサイトが、しばしばプラグインの山になってしまいます。ページビルダー、キャッシュプラグイン、SEO プラグイン、フォームプラグイン、セキュリティプラグイン、画像プラグイン、Cookie プラグイン、リダイレクトプラグイン、スキーマプラグイン、そして時にはページビルダーの苦痛を和らげるためのカスタムフィールドプラグインです。それぞれの部品が、更新、設定、データベーステーブル、アセット、そして新たな故障点を追加します。
問題は WordPress コアではありません。問題は、多くの WordPress プロジェクトが 1 年後にたどる運命的な形状です。サイトは、クリーンな HTML、小さな CMS、そしていくつかの API コールとして出荷できたはずのページのための、小さなバックエンドシステムになってしまいます。
Patchstack の 2026 年版 WordPress セキュリティレポートは、メンテナンスコストを無視することを難しくしています。レポートによれば、2025 年に WordPress エコシステムで発見された新しい脆弱性は 11,334 件で、2024 年から 42% 増加しました。また、新しい脆弱性の 91% がプラグインで、9% がテーマで見つかり、WordPress コアで報告された脆弱性はわずか 6 件で、すべて優先度が低いものでした。
それが要点です。WordPress 自体が悪者なのではありません。リスクが存在するのはプラグインの表面積です。
EmDash は最もクリーンなシグナル
これは最初から含めるべきだった部分です。Cloudflare は 2026 年 4 月 1 日に EmDash を v0.1.0 プレビューとして導入し、それを WordPress の精神的後継者であると説明しました。
詳細はこの記事の議論と一致しています。EmDash は TypeScript で書かれ、Astro によって動かされ、MIT ライセンスでオープンソース化されており、サーバーレスホスティング向けに設計されています。また、何度も繰り返される WordPress の特定の痛み、つまりプラグインという問題に対処しています。
WordPress では、プラグインはサイトと同じ世界内で実行されます。データベース、ファイルシステム、ランタイムに触れることができ、それには多くの信頼が必要です。Cloudflare の EmDash モデルは、プラグインを隔離された Dynamic Workers 内に押し込み、バインディングを通じて宣言された機能を与えます。プラグインは、コンテンツの読み取りやメールの送信など、必要な作業を行う前に、必要な正確な権限を要求すべきです。
それが現代の CMS のアイデアです。曖昧な信頼を減らし、明示的な権限を増やすことです。
EmDash が重要なのは、AI エージェントをワークフローの一部として扱っているためでもあります。Cloudflare によれば、すべての EmDash インスタンスはリモート MCP サーバー、CLI ツール、およびエージェントスキルを公開できます。つまり、コーディングエージェントは、管理パネルをスクレイピングしたり、データがどこにあるかを推測したりするのではなく、構造化されたツールを通じてコンテンツ、スキーマ、メディア、移行作業を管理できるということです。
私は今日、クライアントに盲目的に EmDash へ移行するよう勧めることはしません。それはプレビュー段階です。重要なのは方向性です。Cloudflare は、私が今 Web サイトに求めているもの、つまりサンドボックス化された拡張機能、クリーンなフロントエンドアーキテクチャ、プログラムによる制御、そしてエージェントが読み取れる操作围绕して、WordPress の代替品を構築しています。
AI がカスタムサイトの計算式を変えた
数年前までは、カスタムとは高価であることを意味しました。開発者にすべてのページとコンポーネントの構築を依頼するか、ページビルダーを使用してその重みを受け入れるかのどちらかでした。
AI は中間の道を現実的なものにしました。レイアウトを説明し、コンポーネントを生成し、間隔を調整し、コピーを書き、構造化されたコンテンツを作成し、小さな管理フローを構築し、必要なサービスを正確に接続することができます。v0、Framer AI、Webflow AI、Lovable 風のアプリビルダー、そして現代のコーディングエージェントなどのツールにより、カスタムインターフェースの生産が速くなりました。
それは、AI が感性、QA、あるいはエンジニアリングの判断を置き換えるという意味ではありません。意味するのは、最初のドラフトがもはや予算全体を消費しないということです。
ここで WordPress はそのデフォルトの地位を失います。ブランドに完全に一致し、高速に読み込まれ、クリーンなスキーマを提供し、重いバックエンドを回避する、カスタムの Next.js、Astro、EmDash、または Webflow の構築物が得られるのであれば、WordPress による妥協を正当化することは難しくなります。
ページビルダーはつまみを提供します。AI 支援型のコードワークフローは、実際のシステム、つまりコンポーネント、コンテンツモデル、ルート、メタデータ、画像処理、フォーム、アナリティクス、デプロイルールを提供します。それを検査でき、バージョン管理でき、テストできます。
それはテーママーケットプレイスよりも重要です。
バックエンドは仕事に合わせるべき
ブロシャーサイトには、デフォルトでデータベース backed の管理パネルは必要ありません。ランディングページには、速く見せるために PHP、MySQL、20 個のオプション画面、そしてキャッシュレイヤーは必要ありません。
プロジェクトが必要とする場合にのみ、バックエンドを使用してください。
テーマがブロックを保存する場所を必要としているからといって、バックエンドを追加してはいけません。
リーンな現代のスタックは、より小さくできます。静的ページ、サーバーレンダリングされたルート、ヘッドレス CMS、Supabase、Git ベースのコンテンツフロー、ホストされたフォーム、Stripe、検索プロバイダー、そして小さな API で、Web サイトの大部分をカバーできます。可動部が減り、パフォーマンスに対する制御が向上します。
これが、私がクリーンな HTML と測定された SEO 作業を重視するのと同じ理由です。私の Lighthouse SEO スコアのケーススタディ→ では、勝利は規律あるマークアップ、スキーマ、速度、アクセシビリティ、そしてキャッシングからもたらされました。サイトビルダーは役立ちますが、最終的な出力は依然としてブラウザ、検索エンジン、AI エージェントによって読み取れるものでなければなりません。
AI により正確なデザインが低コストに
WordPress に対する最も強力な反論は、もはや速度だけではありません。それはデザインの制御です。
ほとんどの WordPress プロジェクトはテーマから始まり、ブランドをそれに合わせるように曲げます。フォント、色、セクション、間隔を変更しますが、テーマはまだ指紋を残します。サイトは、それを構築したツールのように見えます。
AI はそのワークフローを逆転させます。ブランド、オファー、オーディエンス、そして実際のインタラクションモデルから始めることができます。その後、それらの制約围绕してインターフェースを生成します。
それがより良い順序です。
コンサルタントサイトは、必要な正確な証明構造を持つことができます。SaaS ページは、一般的なヒーローではなく、密度の高い製品表面を表示できます。音楽製品ページは、テンプレートではなく、本物のスタジオツールのように感じさせることができます。地元のビジネスページは、テーマのレイアウト仮定と戦うことなく、予約、信頼、場所、サービス情報を可視化できます。
出力仍然としてレビューが必要です。AI は、悪い CSS、弱いアクセシビリティ、膨れ上がった JavaScript、曖昧なコピーを生成する可能性があります。人間仍然としてページを検査し、モバイルをテストし、リンクを確認し、メタデータを検証し、Lighthouse を実行し、執筆を誠実な状態に保つ必要があります。
しかし、AI は「カスタム＝遅い」という言い訳を排除します。
WordPress が依然として勝つ場合
編集ワークフローそのものが製品である場合、私は仍然として WordPress を選択します。
チームが多くの投稿を公開し、既存の WordPress 編集習慣を使用し、WooCommerce に依存し、特定の成熟したプラグインを必要とし、またはすでに安定した WordPress 設定で何年もの SEO 履歴を持っている場合、流行のために再構築するのは悪い動きです。
WordPress は、カスタムフロントエンドよりも馴染みのある管理画面を必要とするチームにとってもうまく機能します。人々がすでに知っているツールには価値があります。
間違いは、サイトは何をする必要があるかを尋ねる前に WordPress を選択することです。
多くの新しい構築において、サイトが必要とするのは速度、構造、カスタムデザイン、制御された統合、そして低いメンテナンスです。WordPress はそれらのことを行うことができますが、しばしば余分なレイヤーを通じてそれらに到達します。AI 支援型のカスタム構築は、それらにより直接的に到達します。
私の実際的なルール
今日 WordPress を選択する前に、3 つの質問をします。
第一に、クライアントは具体的に WordPress の管理画面体験を必要としていますか？
第二に、プラグインは、小さなカスタム統合よりも難しいビジネス問題をよりよく解決しますか？
第三に、12 ヶ月間の更新、マーケティングリクエスト、トラッキングスクリプト、コンテンツ変更の後でも、サイトのメンテナンスは容易でしょうか？
答えがイエスであれば、WordPress が正しい選択となり得ます。
答えがノーであれば、より軽いアーキテクチャから始め、AI を使用して正確なインターフェースを構築します。それは静的サイト、ヘッドレス CMS、React または Astro のフロントエンド、EmDash、Webflow、Framer、または小さなフルスタックアプリを意味する可能性があります。スタックは習慣ではなく、仕事に適合すべきです。
また、ここでも AI エージェントが有用になります。優れたエージェントはサイトを検査し、リンクを確認し、メタデータをチェックし、ビルドをテストし、コンテンツを更新し、痕跡を残すことができます。私はその制御レイヤーについて MCP 開発者ワークフローの記事→ で書きました。同じ考えが Web サイトにも適用されます。ツールは明確なアクションを公開すべきであり、すべてをプラグイン画面の背後に隠すべきではありません。
評決
WordPress は自動的な答えとしては死んだのです。ソフトウェアとして WordPress が死んだわけではありません。
EmDash は初期段階ですが、CMS の会話がどこに向かっているかを示しています。デフォルトでサーバーレス、TypeScript フレンドリー、フロントエンドネイティブ、より安全なプラグインの境界、そして手動の管理作業の代わりに AI エージェントワークフローです。
Web は、より高速なフロントエンド、より小さなバックエンド、AI 支援型デザイン、そして最終出力に対するより明示的な制御に向かって進んでいます。WordPress 仍然として場所を持っていますが、プロジェクトごとにその場所を獲得しなければなりません。
出版マシンが必要であれば、それを使用してください。正確に感じられ、高速に読み込まれ、重いバックエンドを回避するカスタム Web サイトが必要であれば、AI はより良い道を進みやすくしました。