WordPressの脆弱性が不安な人のための代替CMSと構築方法 - EmDash・静的化・ヘッドレスCMSの選び方

WordPressのプラグインの脆弱性情報が毎週のように流れてきて、更新が追いつかない。PHP本体にも深刻な脆弱性が出た。そんな状況で「そもそもWordPressをやめたほうがいいのでは」と考える人は少なくないはずです。2026年4月には、CloudflareがWordPressの「精神的後継」をうたうCMSのEmDashを発表し、選択肢として話題になりました。

ただ、CMSを乗り換えれば安全になる、という単純な話ではありません。この記事では、WordPressの脆弱性がどこから来ているのかを確認したうえで、代替のCMSや構築方法を「攻撃面をどう減らすか」という軸で整理します。数字や仕様は、Patchstackのレポート、Cloudflareの発表、各プロジェクトのGitHubリポジトリなどをもとにしています。

先に結論

どの方法でも、ソフトウェアの更新という仕事はなくなりません。変わるのは、公開サーバーにどれだけの機能を置くか、誰が更新の責任を持つか、という点です。

WordPressの脆弱性はどこから来ているか

Patchstackの「State of WordPress Security in 2026」（2025年のデータ）によると、WordPressのエコシステムで新たに見つかった脆弱性は11,334件で、2024年より42%増えました。

コアの脆弱性は少なく、問題の大半はプラグインとテーマです。しかも、半数近くは公開時点で修正版がなく、悪用が始まるまでの時間は数時間単位です。「更新を欠かさなければ安全」という前提が成り立たない場面がある、ということです。

もう1つの不安がPHP本体です。2026年にはPHP本体の認証不要のリモートコード実行の脆弱性も出ました（詳細はPHP2Shellの記事）。こちらはWordPressに限らず、PHPで動くすべてのサイトに関わります。

WordPressを使い続ける場合の基本的な対策は、WordPressセキュリティ対策の記事にまとめています。この記事では、その先の「構成ごと変える」選択肢を見ていきます。

攻撃面を減らす3つの方向

代替手段は、大きく3つの方向に分けられます。

1. 公開サーバーでCMSを動かさない: 記事はCMSで書き、公開するのは生成済みの静的ファイルだけにする
2. 拡張機能を隔離する: プラグインが使える権限を絞り、1つの脆弱性がサイト全体に広がらないようにする
3. 運用を任せる: CMS本体の更新やインフラの管理を、SaaSの事業者に任せる

以下の選択肢は、このどれか、または組み合わせです。

選択肢1: WordPressを残して公開側だけ静的化する

既存のWordPressサイトにとって、最も移行コストが低い方法です。WordPressは記事を書くための環境として残し、公開するのはWordPressが出力したページを静的なHTMLに書き出したものだけにします。

閲覧者がアクセスする公開サーバーではPHPもデータベースも動かないため、プラグインに脆弱性があっても、公開側から直接突かれることはなくなります。

代表的なプラグインは2つあります。

注意点もあります。

• WordPress側の更新は引き続き必要です。管理画面をインターネットに公開したままでは、攻撃面はほとんど減りません。IP制限やVPNの内側、あるいはローカル環境に置くことが前提になります
• 問い合わせフォーム、サイト内検索、コメントなど、サーバー側で処理する機能はそのままでは動きません。有料版の機能や外部サービスで置き換えます
• 予約投稿やランキングのように時間で変わる表示は、書き出しのタイミングを決めておく必要があります

選択肢2: プラグインを隔離するCMSのEmDash

EmDashは、Cloudflareが2026年4月1日に発表したオープンソースのCMSです（MITライセンス）。WordPressと同じように管理画面とプラグインの仕組みを持ちながら、TypeScriptとAstroで作り直しています。

プラグインの権限を宣言する仕組み

EmDashの特徴は、プラグインが使う権限を最初に宣言させる点です。READMEに載っている例では、公開時に編集者へメールを送るプラグインが、コンテンツの読み取りとメール送信の2つだけを宣言しています。

export default () =>
  definePlugin({
    id: "notify-on-publish",
    capabilities: ["content:read", "email:send"],
    hooks: {
      "content:afterSave": async (event, ctx) => {
        if (event.content.status !== "published") return;
        await ctx.email.send({
          to: "editors@example.com",
          subject: `New post: ${event.content.title}`,
        });
      },
    },
  });

WordPressのプラグインは、データベース、ファイル、ユーザー情報のすべてにアクセスできます。EmDashでは、このプラグインは宣言した2つのこと以外はできません。スマートフォンのアプリが権限を求める仕組みや、OAuthのスコープに近い考え方です。

EmDashの注意点

• WordPressのプラグインやテーマは動きません。READMEには、移植をAIエージェントのスキルで手伝う旨が書かれていますが、作り直しが前提です
• 本体のパッケージはセマンティックバージョニングに従いますが、公式プラグインやプラグイン用のツールはまだ 0.x で、マイナーリリースで変わる可能性があるとされています
• 隔離が守るのはプラグインの範囲です。宣言して許可した権限は使えますし、CMS本体やAstroに脆弱性があれば隔離の外の問題になります（後者は仕組みからの推測です）
• GitHubで公開されているセキュリティアドバイザリは0件ですが、公開から半年あまりのプロジェクトなので、安全性の根拠にはなりません
• CMSWireの報道によると、WordPressの共同創設者のMatt Mullenweg氏は自身のブログで「精神的後継」という位置付けを否定しました。一方で、エンジニアリングは「very solid」と評価しつつ、管理画面のUIは「uncanny valley」だと評しています
• 同じ記事は業界の反応を「Right Architecture, Empty Ecosystem」（設計は正しいが、エコシステムが空っぽ）とまとめています

選択肢3: Git管理と静的サイト生成

記事をMarkdownなどのファイルとしてGitで管理し、AstroやNext.jsの静的出力でHTMLを生成する方法です。本番サーバーにはデータベースも管理画面も置かないため、公開側の攻撃面は最も小さくなります。

実はこのブログもこの構成です。記事はMDXファイルとしてGitで管理し、Next.jsの静的エクスポートで生成したファイルを、ApacheがWebサーバーとして配信しているだけです。本番でNode.jsのプロセスは動いていません。

非エンジニアがGitを直接触るのは難しいので、管理画面を足すツールがあります。

注意点は次のとおりです。

• 更新のたびにビルドとデプロイが必要です。CIで自動化しておくのが前提になります
• 編集画面のプレビューや画像の扱いは、WordPressほど手軽ではありません
• ビルドに使うnpmのパッケージは、サプライチェーン攻撃の対象になり得ます（例: TanStackの乗っ取り事件）。攻撃の場所が本番サーバーからビルド環境に移る、と考えておくべきです

Astroの最新動向はAstro 7の記事で紹介しています。

選択肢4: SaaS型ヘッドレスCMS

管理画面とAPIをSaaSとして提供するヘッドレスCMSを使い、表示側はAstroやNext.jsで静的に生成する方法です。Sanity、Contentful、国内ならmicroCMSなどがあります。

CMS本体のパッチ適用やサーバーの管理を事業者に任せられるのが最大の利点です。非エンジニアでも管理画面から更新でき、プレビューや権限管理の機能も揃っています。

一方で、利用者の責任として残る部分もあります。

• APIキーの管理（公開してよい読み取り用のキーと、書き込みもできるキーを分ける）
• 編集者のアカウントの管理（多要素認証、退職者のアカウントの削除）
• Webhookでビルドを起動する場合の、その経路の保護
• 料金体系の変更や、サービス終了のリスク

選択肢5: セルフホスト型ヘッドレスCMS

ヘッドレスCMSを自分のサーバーで動かす方法です。データを手元に置け、業務システムとの連携もしやすくなります。

DirectusのライセンスはOSSのライセンスではなく、Directusの有償提供と競合する使い方を禁じる独自ライセンスで、一定期間後にGPL-3.0で使えるようになる条項があります。導入前にライセンス本文を確認してください。

注意したいのは、CMS本体の更新という責任は自分に残ることです。プラグイン中心の構成からは離れられますが、管理画面を公開すればそこが攻撃面になります。管理画面とAPIは公開側と分け、静的生成と組み合わせて、閲覧者のリクエストをCMSに届かせない構成が理想です。

なお、WordPressをヘッドレスCMSとして使う方法もあります。既存の編集体験を残しつつ公開側を分離できますが、WordPressのプラグインの問題はそのまま残ります（詳細はWordPressをヘッドレスCMSとして使う記事）。

選択肢6: Ghost

ブログ、ニュースレター、有料会員制のメディアが中心なら、Node.jsで動くGhost（MIT）も候補です。必要な機能が最初から揃っているので、WordPressのように多くのプラグインを足す必要がありません。拡張が少ないことは、そのまま攻撃面の小ささにつながります。用途が限られる点と、自分で運用する場合は本体の更新が必要な点は、ほかのセルフホスト型と同じです。

PHPをやめても脆弱性はなくならない

PHPから離れても、脆弱性と無縁にはなりません。各プロジェクトがGitHubで公開しているセキュリティアドバイザリの件数を、2026年11月11日時点で調べました。

この件数は、脆弱性の多さよりも、開示に積極的かどうかを反映している面があります。件数が多いから危険、少ないから安全、とは読めません。分かるのは、どのプロジェクトでも脆弱性は見つかっていて、更新が必要だということです。

Node.jsの世界に移ると、npmの依存パッケージという別の更新対象も増えます。npmのインストールスクリプトをめぐる動きはnpm v12の記事、フレームワーク本体の例はNext.jsのセキュリティリリースの記事で紹介しています。

方式ごとの比較

攻撃面の評価は構成から考えた筆者の整理で、製品を同じ条件で比較検証したものではありません。

状況別の選び方

1. 既存のWordPressサイトで、動的機能が少ない: まず公開側の静的化を試すのが、手間に対して最も効果的です。管理画面を非公開にすることまでセットで行います
2. 新規サイトで、更新するのがエンジニア: Git管理と静的生成がおすすめです。サーバー側の運用がほぼなくなります
3. 新規サイトで、更新するのが非エンジニア: SaaS型ヘッドレスCMSと静的生成の組み合わせが現実的です
4. 業務アプリと一体で作る: Payloadなどのセルフホスト型が向いています。ただし、本体と依存パッケージの更新を続けられる体制が前提です
5. WordPressのような拡張性を保ちたい: EmDashは、プラグインを隔離するという設計そのものに価値があります。プラグインの選択肢はまだ少ないので、まず小規模な新規サイトで試すのがよいでしょう

まとめ

WordPressの脆弱性の大半はプラグインとテーマから来ています。そのため、効く対策はPHPをやめること自体より、公開サーバーでCMSを動かさないこと、プラグインを隔離すること、運用を任せることのいずれかです。

どの方法を選んでも、更新という仕事は残ります。乗り換えを考えるときは「何が安全か」より「この体制で誰が何を更新し続けられるか」を基準にすると、後悔の少ない選択になります。

参考資料

• Patchstack「State of WordPress Security in 2026」
• Cloudflare Blog「EmDash」
• EmDash（GitHub）
• CMSWire「Right Architecture, Empty Ecosystem: Verdicts on EmDash」
• Simply Static
• Staatic（WordPress.org）
• Decap CMS（GitHub）
• TinaCMS（GitHub）
• Payload（GitHub）
• Strapi（GitHub）
• Directus（GitHub）
• Ghost（GitHub）
• Astro（GitHub）