2026年は、WordPressを使っている人にとってなかなか心臓に悪い年になりました。7月にはWordPressコアの「wp2shell」、10月にはPHP本体の「PHP2Shell」と、認証なしで遠隔コード実行につながる深刻な脆弱性が立て続けに公表されています。「もうWordPressをやめて、もっと安全なCMSに移った方がいいんじゃないか」と考え始めた方も多いのではないでしょうか。今回はWordPressの代替CMS候補と、移行前に押さえておきたい判断基準をまとめてみます。
2026年、WordPressとPHPに何が起きたのか
まずは「なぜ今、WordPressの代替CMSを探す人が増えているのか」を整理しておきます。きっかけは単発のニュースではなく、PHP本体、WordPressコア、そしてプラグインという3つのレイヤーで、深刻な脆弱性が同じ年に重なったことです。どれか1つなら「アップデートしておけばOK」で済む話なのですが、全部の層で穴が開くと、さすがに構造そのものを見直したくなりますよね。
ここで大事なのは、ニュースの見出しだけで判断しないことです。「PHPが危ない」「WordPressが危ない」とひとくくりにされがちですが、実際にはそれぞれ原因も対策もまったく違います。代替CMSを選ぶ前に、何が怖くて、何から逃げたいのかを言語化しておくと、移行先の候補がグッと絞りやすくなります。
PHP本体の脆弱性「PHP2Shell」
2026年10月に公表されたのが、PHP本体の2つの脆弱性（CVE-2026-109618、CVE-2026-109619）、通称「PHP2Shell」です。どちらもCVSS v4.0で9.2という高い評価で、ログインなしに攻撃者がサーバー上でコードを実行できる可能性があるというものでした。しかも予定されていた公開日の前日に情報が漏れて出回ってしまい、PHPの開発チームが緊急でセキュリティリリースを出すという、なかなかバタバタした展開でした。
修正版はPHP 8.2.35、8.3.36、8.4.27、8.5.12として公開されています。厄介なのは、PHP 8.1以前はすでに公式サポートが終了していて、PHP 8.2も2026年12月末でサポート終了を迎える予定だという点ですね。古いバージョン向けにはソースレベルのバックポートも用意されたそうですが、古いレンタルサーバーや放置気味の社内サーバーのPHPがすぐ更新されるかというと……正直かなり怪しいところです。修正版への更新だけでなく、この先もセキュリティ更新を受けられるバージョンへの移行計画まで立てておきたいですね。
WordPressコアの脆弱性「wp2shell」
PHP2Shellの少し前、2026年7月にはWordPressコアで「wp2shell」と呼ばれる脆弱性の組み合わせ（CVE-2026-60137、CVE-2026-63030）が公表されています。SQLインジェクションとREST APIのバッチ処理まわりの問題が組み合わさることで、標準構成のままでも管理者権限なしに遠隔コード実行に至る可能性がある、というものでした。
2つの脆弱性の組み合わせで遠隔コード実行に至る可能性があるのは、WordPress 6.9.0〜6.9.4と7.0.0〜7.0.1です。また、CVE-2026-60137単体は6.8.0〜6.8.5にも影響します。修正版は6.8.6、6.9.5、7.0.2以降です。WordPress.org側が強制的な自動更新を有効化したのは心強いのですが、自動更新を切っている環境や、プラグインの互換性の都合でバージョンを固定している現場もまぁまぁありますよね。IPAも、自動更新されているかを確認して、されていなければ手動更新を検討するよう呼びかけていました。
実は一番怖いのはプラグイン
コアやPHP本体の脆弱性はニュースとして目立ちますが、数で見ると圧倒的に多いのはプラグインです。Patchstackのレポートによると、2025年にWordPressのエコシステムで新たに見つかった脆弱性は11,334件で、前年から約42%増えたそうです。そのうち約91%がプラグイン、約9%がテーマ由来とされています。
さらに怖いのが、報告された脆弱性の4割を超えるものが、公開時点で開発者による修正版が確認されていなかったという点です。つまり、アップデートが大前提なのは変わりませんが、修正版が出るまでの間は「こまめにアップデートしているから大丈夫」とは言い切れない期間がある、ということですね。プラグインを20個も30個も入れているサイトは、それだけ攻撃面を背負っていると考えた方がいいでしょう。
「PHPをやめれば安全」は半分正解で半分ハズレ
ここで一度、冷静になっておきたいところです。WordPressの代替CMSを探している方の中には「PHPじゃなければ安全」と考えている方もいると思いますが、ぶっちゃけそれは半分しか合っていません。Node.jsで動くCMSやフレームワークにも、当然ながら脆弱性は出ます。言語を変えれば穴がゼロになる、という魔法はないんですよね。
たとえばJavaScriptの世界では、npmのサプライチェーン攻撃がここ1〜2年でかなり深刻になっています。2025年9月には、週に何十億回もダウンロードされる定番パッケージが乗っ取られる事件があり、2026年に入ってからも「Shai-Hulud」系のワームによる攻撃が何度も報告されています。2026年7月にリリースされたnpm 12では、依存パッケージのインストールスクリプトがデフォルトで実行されなくなるなど、仕組みの側での対策も進んでいる状況です。
じゃあ何を軸に考えればいいのかというと、「言語」ではなく「公開サーバー上で動いているものの量」を減らす、という考え方です。PHP2Shellとwp2shellは原因こそ違いますが、公開サーバー上で動くソフトウェアの脆弱性が深刻な侵入経路になり得る、という点は共通しています。公開側を静的なHTMLの配信に限定すれば、サーバー上で動的に処理するアプリケーションに由来する攻撃面は大きく減らせます。
ただし、攻撃面を減らすのはあくまでリスクを下げる手段で、安全を保証するものではありません。それでも、代替CMS選びの軸をここに置いておくと、比較するときに一番ブレないと思います。
WordPressの代替CMS候補5選【2026年版】
ここからは、WordPressからの移行先として現実的な候補を5つ紹介します。「安全性」「運用の手間」「書きやすさ」のバランスがそれぞれ違うので、自分のサイトの規模や、誰が記事を書くのかをイメージしながら読んでみてください。なお、料金や仕様は変わることがあるので、最終的には公式サイトで確認するのがおすすめです。
①Astro＋ヘッドレスCMS（microCMSなど）
個人的に一番バランスが良いと感じているのが、Astroのような静的サイトジェネレーターと、ヘッドレスCMSを組み合わせる構成です。記事の管理はヘッドレスCMSの管理画面で行い、公開時にAstroが静的なHTMLを書き出して配信します。静的生成・静的配信で組む限り、公開サーバーではPHPもデータベースも動かないので、PHP2Shellやwp2shellのようなタイプの攻撃の入口はぐっと減ります。なお、AstroでもSSR（サーバーサイドレンダリング）やサーバー機能を使う構成にすると、そのぶん動的な攻撃面が生まれる点は覚えておきましょう。
Astroは2026年1月にCloudflareが開発元を買収したことでも話題になりましたが、オープンソースのまま開発を続けると明言されています。ヘッドレスCMSは国産のmicroCMSなら管理画面もサポートも日本語なので、非エンジニアのメンバーに渡しても困りにくいですね。無料のHobbyプランから試せて、チーム向けのTeamプランは月額4,900円からとなっています。
②Ghost
「ブログやメディアとして書くこと」に集中したいなら、Node.js製のCMSであるGhostも有力な候補です。エディターがシンプルで書き心地が良く、会員機能やニュースレター配信も最初から入っています。2025年に出たGhost 6では、Cookieを使わない独自のアクセス解析や、ActivityPubを使ったソーシャルWeb連携も追加されました。
注意点としては、Ghostはサーバー上でNode.jsが常時動く構成なので、静的サイトほど攻撃面は小さくないことです。Ghost 6の本番運用向けの公式推奨スタックはNode.js 22で、セルフホストならDocker Composeでの運用が推奨されています。サーバーの面倒を見たくない場合は、公式のマネージドホスティング（Ghost(Pro)）を使う方が気楽かもしれません。
③Hugoなどの静的サイトジェネレーター単体
エンジニアが1人で運用する技術ブログなら、HugoやAstroなどの静的サイトジェネレーターを単体で使い、記事はMarkdownで書いてGitで管理する、という割り切った構成もアリです。サイト本体に管理画面がないので、WordPressのログイン画面のような入口はそもそも存在しません。ホスティングもCloudflare PagesやNetlifyなどの静的ホスティングに置くだけで済みます。ただし、Gitリポジトリやデプロイ用のトークン、CI/CD、ホスティングのアカウントは引き続き狙われるので、二要素認証などでしっかり守っておく必要があります。
その代わり、Markdownとgitに慣れていない人にとっては、記事を1本公開するだけでもハードルが高くなります。「書くのは自分だけ」「VSCodeで記事を書くのも苦じゃない」という方向けの選択肢ですね。逆に、社内の広報担当さんに渡すサイトでこれを選ぶと、たぶん一週間で文句が出ます。（経験則というより想像です）
④Strapi・Payloadなどのセルフホスト型ヘッドレスCMS
「SaaSにデータを預けたくない」「コンテンツの構造を細かく自分で設計したい」という場合は、StrapiやPayloadのようなセルフホスト型のヘッドレスCMSが候補になります。どちらもNode.js製で、管理画面とAPIを自分のサーバーで動かし、フロントはAstroやNext.jsなどで静的に書き出す、という構成がよく使われます。
この構成の良いところは、管理画面を社内ネットワークやIP制限の内側に置いて、公開側には静的ファイルだけを出すという設計がしやすい点です。ただし、社内ネットワークに置けば自動的に安全になるわけではなく、認証やアクセス制御、APIの公開範囲、バックアップの設計は別途必要です。フロントを静的化してもCMSの管理API自体は動的なままですし、管理側のサーバーやnpmの依存パッケージも自分でアップデートし続けることになります。WordPressの「プラグイン地獄」が「npm依存地獄」に変わるだけ……とならないよう、運用体制は事前に考えておきたいところです。
⑤SaaS型のサイトビルダー
最後に、技術的な運用をまるごと手放したい場合は、サーバー管理込みで提供されるSaaS型のサイトビルダーを使う手もあります。サーバーやPHPのバージョン管理はサービス提供側の責任になるので、今回のような脆弱性騒ぎで自分が夜中にアップデート作業をする必要はなくなります。とはいえ、「運用を手放せる」と「セキュリティ管理が不要になる」は別の話です。サービス側の脆弱性やアカウントの乗っ取り、権限設定のミス、サービス終了といったリスクは残ります。
ただ、デザインや機能の自由度はサービスの仕様に縛られますし、将来別のサービスに引っ越すときにデータをきれいに持ち出せるかどうかも要確認です。フロントエンドを自分でゴリゴリ書きたい人には物足りないかもしれませんが、小規模な店舗サイトやコーポレートサイトなら十分すぎる選択肢でしょう。
タイプ別：どのWordPress代替CMSを選ぶべきか
5つも並べると逆に迷ってしまうので、ざっくりタイプ別に整理してみます。判断のポイントは「誰が記事を書くのか」と「サーバーの面倒を誰が見るのか」の2つです。この2つが決まると、だいたい候補は1つか2つに絞れます。
- 非エンジニアが記事を書く企業サイト・オウンドメディア → Astro＋microCMS
- 書くことに集中したい個人ブログ・メディア → Ghost（できればマネージド）
- エンジニアが1人で運用する技術ブログ → Hugo・Astro単体＋Markdown
- データを自社管理したい中〜大規模サイト → Strapi・Payload＋静的書き出し
- 技術的な運用を手放したい小規模サイト → SaaS型サイトビルダー
ちなみに、ECサイトのように動的な処理が多いサイトは、CMSだけ差し替えても解決しないことが多いです。カートや会員機能はShopifyなどのEC専用サービスに任せて、記事コンテンツだけをヘッドレスCMSで管理する、という切り分けの方が現実的ですね。全部を1つのCMSでまかなおうとするから、プラグインが雪だるま式に増えていくわけです。
WordPressから移行する前にやっておきたいこと
移行先が決まったら、いきなり記事をコピペし始める前に準備をしておきましょう。CMSの移行で起きがちな大きな失敗の一つが、SEOへの影響です。何年もかけて積み上げた検索順位が、URLの変更ミスひとつで一気に落ちる、というのはよくある話なんですよね。
URL設計と301リダイレクトを最優先で決める
まず決めるべきは、新しいサイトのURL設計です。可能なら今のURLをそのまま維持するのがベストで、変える場合は旧URLから新URLへ、1対1で301リダイレクトを設定します。トップページにまとめてリダイレクトするような雑な設定は、評価の引き継ぎがうまくいかない原因になるので避けましょう。Googleは、リダイレクトを少なくとも1年間は維持することを推奨しています。
ちなみに、ドメインもURLも変えずにCMSだけを差し替えるケースなら、Search Consoleの「アドレス変更ツール」を使う必要はありません。あれはドメインを変えるときのためのツールです。自分の移行がどちらのケースなのかは、最初に整理しておくと迷いません。
当ブログでも以前、WordPressのディレクトリを移動したときの手順や、Search Consoleでsitemap.xmlが取得できなくなったときの確認ポイントを記事にまとめています。CMSの移行は、これらをもっと大規模にやるイメージです。移行後はSearch Consoleでサイトマップを再送信し、カバレッジのエラーをしばらく監視しておくと安心です。
コンテンツと画像のエクスポート
WordPressには標準のエクスポート機能（WXR形式のXML）があるので、記事本文やカテゴリ、タグはこれで取り出せます。ただし、ショートコードやページビルダー独自のブロックはそのまま移行先で使えないので、変換スクリプトを書くか、手作業で整える必要があります。ここが地味に一番時間を食うポイントです。
画像についても、記事内のパスが「/wp-content/uploads/」から始まっているはずなので、移行先での置き場所と合わせて一括置換が必要になります。alt属性やタイトル、メタディスクリプションなど、SEOに効いている情報が移行で抜け落ちていないかも、移行前と移行後で必ず突き合わせておきましょう。
見落としがちなのが、canonical、構造化データ、内部リンク、robots.txt、noindexの設定です。WordPressではSEOプラグインが自動で出力してくれていたものが、移行先では何も出ていない……というのはよくある落とし穴です。移行後にページのソースを開いて、ひとつずつ確認しておくとインデックスのトラブルを減らせます。
移行しないという選択肢：WordPressを続けるなら最低限やること
ここまで代替CMSの話をしてきましたが、正直なところ、すべてのサイトがWordPressをやめるべきだとは思っていません。移行にはコストも時間もかかりますし、WordPressには今でも圧倒的なエコシステムと情報量があります。「すぐには移行できない」という方は、少なくとも次のポイントだけは押さえておきたいところです。
まず、PHPを公式サポート中のバージョン（PHP2Shellの修正版以降）に上げること。次に、WordPressコアの自動更新を有効にしておくこと。そして使っていないプラグインは「無効化」ではなく「削除」すること、最終更新が何年も前のプラグインは代替を探すこと。最後に、管理画面へのアクセスをIP制限や二要素認証で絞ることですね。地味ですが、これだけでもかなり攻撃面は減らせます。
また、ヘッドレスWordPressという中間的な選択肢もあります。管理画面としてのWordPressは残しつつ、公開側はAstroなどで静的に書き出す構成です。書き手の慣れた管理画面を変えずに、公開サーバーからPHPを追い出せるので、段階的な移行の第一歩としてはかなり現実的だと思います。
まとめ
2026年はPHP2Shellやwp2shellといった深刻な脆弱性が続き、WordPressの代替CMSを検討するきっかけとしては十分すぎる年になりました。ただ、PHPからNode.jsに乗り換えれば安全、という単純な話ではありません。npmのサプライチェーン攻撃のように、JavaScriptの世界にも別の種類のリスクはしっかり存在しています。
代替CMS選びで一番ブレない軸は、「公開サーバー上で動くプログラムをどれだけ減らせるか」です。その意味で、Astroなどの静的サイトジェネレーターとヘッドレスCMSを組み合わせる構成は、安全性と運用のしやすさのバランスが取れた有力な選択肢だと思います。書き手が誰か、サーバーの面倒を誰が見るのか、この2つを決めれば候補はおのずと絞れるでしょう。
そして移行するなら、セキュリティと同じくらいSEOの引き継ぎに気を配ってください。URLの維持か1対1の301リダイレクト（最低1年は維持）、メタ情報やcanonicalの移行チェック、Search Consoleでの監視。この辺りをサボると、安全にはなったけど誰も来ないサイトになってしまいます。それはそれで、ある意味最強のセキュリティかもしれませんが……。
すぐに移行できない場合でも、PHPとWordPressのアップデート、不要なプラグインの削除、管理画面のアクセス制限は今日からでもできます。焦って乗り換えるより、まずは足元の攻撃面を減らしつつ、自分のサイトに合った移行先をじっくり選んでいきましょう。
【参考文献】
- IPA「【事前準備のお願い】PHPのセキュリティリリース公開予定について」https://www.ipa.go.jp/security/security-alert/2026/pre-alert20261021.html
- Help Net Security「PHP2Shell: Critical PHP vulnerabilities patched, update now!」https://helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619
- BleepingComputer「PHP warns admins of two critical flaws, emergency patches coming tomorrow」https://bleepingcomputer.com/news/security/php-warns-admins-of-two-critical-flaws-emergency-patches-coming-tomorrow
- IPA「WordPressの脆弱性対策について（CVE-2026-60137、CVE-2026-63030：wp2shell）」https://www.ipa.go.jp/security/security-alert/2026/alert20260722.html
- INTERNET Watch「『WordPress』に管理者権限なしで遠隔でのコード実行が可能になる深刻な脆弱性」https://internet.watch.impress.co.jp/docs/news/2126952.html
- SWIF「WordPress Security Statistics for 2026」https://www.swif.ai/blog/wordpress-security-statistics
- web60「WordPress Plugin Vulnerabilities Surged 42% Last Year」https://web60.ie/blog/wordpress-plugin-vulnerabilities-surge-2026
- Unit 42「Monitoring npm Supply Chain Attacks」https://unit42.paloaltonetworks.com/monitoring-npm-supply-chain-attacks.md
- The Hacker News「npm 12 Disables Install Scripts by Default」https://thehackernews.com/2026/07/npm-12-disables-install-scripts-by.html
- PHP「Supported Versions」https://www.php.net/supported-versions.php
- Google検索セントラル「URL の変更を伴うサイト移転」https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes
- Business Wire「Cloudflare Acquires Astro to Accelerate the Future of High-Performance Web Development」https://www.businesswire.com/news/home/20260116386991/en
- Bright Themes「Ghost 6.0 — Social Web and Native Ghost Analytics」https://brightthemes.com/blog/ghost-v6
- microCMS 料金プラン https://microcms.io/pricing
- eSEOspace「WordPress to Headless CMS: Why & How to Make the Switch」https://eseospace.com/blog/migrate-wordpress-to-headless-cms/
