【解説】脱WordPressは「出口」で選ぶ｜EmDash・Wix・Studio・静的HTML・AI自作CMSのメリットとリスク

WordPressのシェアは2025年12月から毎月下がり、10月末に39.5%になりました。それでも、世界のWebサイトのおよそ4割を支える最大のCMSであることに変わりはありません。PHP2Shellのあと、乗り換え先の候補はいくつも挙がりました。ただ、比べるときに見落とされがちなのは、入るときの手軽さより、いつか出るときの道のほうです。

---

2026年10月のPHP2Shellを機に、WordPressを使い続けるか、別の構成に移るかが改めて問われている。ただしPHP2ShellはPHPそのものの脆弱性で、WordPress.orgは本体の更新を不要としている。一方、W3TechsによるWordPressのシェアは2025年12月の43.2%から2026年10月末の39.5%まで毎月下がり、2026年は本体の重大な脆弱性の修正も相次いだ。

WordPress、静的HTML、EmDash、Wix、Studio、AIで自作したCMSの6つを、入口と出口（ほかから移せるか、ほかへ移せるか）、誰が保守するか、何ができるかの3つの軸で比べると、選び方はサイトの種類と運用の体制で変わる。

10月21日の夜、高市首相がXで対応を呼びかけたと報じられたPHPの脆弱性「PHP2Shell」のあと、私の目に付いた範囲では、日本語圏のXで「WordPressをやめよう」という投稿が増えました。静的HTMLに移した、CloudflareのEmDashに乗り換えた、AIと一緒に数時間で移行できた、という報告も見かけます。英語圏の投稿には、「単純なサイトは離れていくが、複雑なサイトは残る」という、もう少し落ち着いた見方が多いように見えます。

どちらの言い分にも理があります。WordPressをめぐる動きは、innovaTopiaでも個別の記事として伝えてきました。7月のwp2shell（116045）、8月のWordPress 7.1（116525）、EmDashを実際に触った記録（117036）、そして10月のPHP2Shell（119265、119309）。これらを公表資料でつなぎ直し、WordPressと5つの移行先、それぞれのメリットとリスクを整理します。

【参考動画】

11月1日に公開したセキュリティの記事5本を、伊野部トピ子が約8分の動画で整理しました。

この2年あまりに起きたこと

時期	出来事	関連記事／出典
2024年9月	WordPress共同創業者のマット・マレンウェッグ氏が率いるAutomatticとWP Engineの対立が表面化。WP EngineはWordPress.orgの資源にアクセスできなくなる	42343
2025年6月	Linux Foundationが、WordPress向けの分散型の配布の仕組み「FAIR」を発表	57014
2026年4月1日	Cloudflareが「WordPressの精神的な後継」としてEmDashを発表（v0.1.0）	Cloudflareブログ
2026年5月20日	WordPress 7.0。AIのモデルとつなぐ仕組みをコアに。リアルタイム共同編集は見送り	WordPress.org／101621
2026年7月	wp2shell。ログインなしでリモートコード実行に至る本体の脆弱性。7.0.2で修正	116045
2026年8月	Cloudflareの公式ブログがEmDashに移行	Cloudflareブログ
2026年8月19日	WordPress 7.1。リアルタイム共同編集は再び見送り	116525
2026年9月1日	Studioが、既存のサイトをURLから取り込む「Studio.Drop」のクローズドβの事前登録を開始	117456
2026年9月22日	WordPress 7.1.2。約10年分の版に及ぶCriticalの脆弱性を修正	118130
2026年9月	米連邦地裁が、WP Engineの反トラスト法に基づく請求の却下を退け、審理が続くことに	米連邦地裁の命令（CourtListener）
2026年9月28日	EmDash 1.0（安定版）	Cloudflareブログ
2026年10月21日	PHP2Shellの修正版を公開。国内でも多くのサービスが一時停止	php.net／119265

PHP2Shellで問われたのは、PHPを動かし続けること

PHP2Shellは、PHPという言語の処理系そのものにある2件の脆弱性（CVE-2026-109618、CVE-2026-109619）です。PHPの開発チームは10月21日に修正版の8.5.12、8.4.27、8.3.36、8.2.35を公開し、「完全な緩和策はなく、更新が唯一安全な選択」としました。経緯と、サービスが戻ったあとに残る課題は、「PHP2Shell、修正から1日」（119309）で整理しています。

WordPress.orgは同じ日に告知を出し、この脆弱性はPHPで動くすべてのサーバーに関わるもので、WordPressの更新は必要なく、予定もないと説明しました。そのうえで、サイトの運営者にはPHPをすぐ更新するよう求めています。通常のセキュリティ更新が終わった8.1以前のPHPを使い、自分でサーバーを管理しているなら、更新の準備が整うまでサーバーをオフラインにすることも検討してほしい、という一文もあります。

ここで効いてくるのが、WordPressサイトのPHPのバージョンです。WordPress.orgの統計では、2026年11月1日に取得したデータで、8.1以前が約33%を占めていました。PHPの開発チームは今回、7.4、8.0、8.1向けに最小限の修正のソースコードも公開しており、ホスティング会社やLinuxの配布元が修正を独自に取り込んでいる場合もあります。この数字だけで、危険なサイトの割合や、保守の担当がいないサイトの割合が分かるわけではありません。それでも、自分のサイトのPHPの更新を誰が引き受けているのかは、確かめておきたいところです。

7月のwp2shellのとき、エックスサーバーは影響を受ける版を使う顧客のWordPressを、事後に案内する形で更新しました（116908）。本体の管理は原則として利用者の側にありますが、実際には誰がボタンを押すかは一律ではありません。PHP2Shellで問われたのも、WordPressという製品より、サーバーでPHPを動かし、更新し続けるという運用のほうでした。

「離れるべき」と「残る」、それぞれの言い分

離れるべきという声

まず数字です。W3Techsによれば、全Webサイトに占めるWordPressのシェアは、毎月少しずつ下がっています。

時点	WordPress	CMSを検出できないサイト（None）
2025年12月1日	43.2%	28.6%
2026年4月1日	42.5%	28.9%
2026年7月1日	41.5%	29.9%
2026年10月1日	40.2%	31.5%
2026年10月31日	39.5%	32.1%

同じ期間に、W3Techsが監視しているCMSを検出できなかったサイト（None）は増えています。ただ、この公開集計だけでは、Noneに含まれるサイトがどんな構成なのか、WordPressから移ったサイトがどこへ行ったのかは分かりません。静的サイトジェネレーターのAstroやHugoも別の項目で数えられており、Noneの増加をそのまま静的HTMLへの移行と読むことはできません。

次に、本体の脆弱性です。Patchstackの年次報告によれば、2025年に見つかったWordPress関連の脆弱性は1万1,334件で、91%がプラグイン、9%がテーマ由来でした。本体は6件で、いずれも優先度の低いものです。ところが2026年は、本体そのものの重大な修正が続きました。7月のwp2shell（116045）、8月のXSS2Shell、9月の7.1.2（約10年分の版に及ぶCritical、118130）、10月の7.1.3（脆弱性7件）。プラグインへの注意は引き続き欠かせませんが、本体もまた、更新を続けなければならないものだということが、2026年ははっきりしました。

そこに、更新の負担が重なります。年に数回しか書き換えないサイトのために、PHP、本体、プラグインの更新を追い続ける。その手間は、移行を考える十分な理由になりえます。AIのコーディング支援で作業を減らせる場面も出てきました。ただし移行の負担は、URL、画像、フォーム、決済などをどこまで移すかで大きく変わります。

残るという声

39.5%に下がったとはいえ、WordPressは今も全Webサイトのおよそ4割、W3TechsがCMSを判別できたサイトに限れば58.2%を占めます。この規模を背景に、制作会社、ホスティング会社、保守の担い手、情報を探しやすいのは大きな強みです。

GPLのオープンソースなので、運用先を自分で選べます。記事などは標準のXML形式（WXR）で書き出せ、サイト全体を別のサーバーへ移す手順も公式に用意されています。プラグインに固有のデータや機能は、移す先で個別に確かめる必要があります。会員管理、継続課金、予約、ECのような仕組みは、プラグインの組み合わせで動いているぶん、ほかの環境に移すと作り直しになりがちです。

本体の側も変わっています。7.0ではAIのモデルとつなぐ仕組みをコアに入れ、10月にはAIエージェントとWordPressをつなぐ公式プラグイン「MCP Adapter」が、公式ディレクトリから入れられるようになりました（118624）。7月の記事（113241）では、AIがサイトを作る時代に、CMSはAIに使われる側へ回ることで生き残ろうとしているという読み方を示しました。7.1.2では、修正を4.7系まで約10年分の版に届けています。守る側の地道な設計も、20年以上続いてきたソフトウエアの強みです。

比べる前に：共通点と3つの軸

移行先として挙がる5つ（静的HTML、EmDash、Wix、Studio、AIで自作したCMS）には、共通点があります。サイトの運営者がPHPを更新しなくて済むことです。静的HTMLとEmDashはPHPを使わず、WixとStudioはサービスの側がサーバーを保守します。自作のCMSも、PHPを使わない構成を選べます。

そのうえで、違いは3つの軸に表れます。

• 入口と出口：ほかのCMSから移してこられるか（入口）。そして、いつか別の環境に移りたくなったとき、記事や画像を連れて出られるか（出口）
• 誰が保守するか：本体、依存するソフト、サーバーの更新を、自分（または自分が頼む委託先）がするのか、サービスに任せるのか
• 何ができるか：会員、決済、予約、検索、複数人での編集などを、どこまで自前で賄えるか

移行の話になると、目は入口に向きがちです。乗り換えを勧める側は、取り込みの手軽さを前に出します。けれど、より大事なのは出口のほうです。いま選ぶ環境が最後の環境になるとは限りません。数年後に、また別の場所へ移れるかどうか。それが、手綱を自分の手元に残せるかどうかを決めます。

6つの選択肢のメリットとリスク

WordPress

メリット

• 20年以上の実績と最大のシェア。困ったときの情報、制作会社、ホスティング会社が見つけやすい
• プラグインで、会員、決済、予約、ECまで広く賄える
• 入口も出口も広い。BloggerやTumblrなどからの取り込みツールがあり、記事は標準のXML形式で書き出せる。GPLのオープンソースで、運用先や保守の引き受け手も選べる

リスク

• PHP、本体、プラグインの更新を、誰かが続ける必要がある。2026年は本体の重大な修正も相次いだ
• 入れるプラグインが増えるほど、更新の対象も増える
• 運営の権限がマレンウェッグ氏に集まる構造が問われ、WP Engineとの訴訟が続いている

向くサイト：会員、決済、予約などが絡むサイト。技術者ではない書き手が多い体制

静的HTML

メリット

• 閲覧のたびにサーバーの側でCMSやデータベースを動かさず、ファイルを配信するだけなので、公開サイトの攻撃面を減らしやすい
• 高速に配信しやすく、ホスティングは安いか無料。たとえばCloudflare Pagesの無料プランは、1サイト2万ファイル、月500回のビルドまで使える
• データはファイルそのもの。どこへでも移せる

リスク

• 更新の方法は構成次第。静的サイトジェネレーターやGitを使う場合は、その知識と、ツールや依存するパッケージの更新が残る
• フォームや会員機能は、別の仕組みで補う（サイト内検索はブラウザーの中で動かす方法もある）
• 技術者ではない書き手が多い体制では、更新の流れを整えるのに工夫が要る

向くサイト：更新が年に数回の会社案内、LP、ポートフォリオ

EmDash

メリット

• サンドボックス型のプラグインは1つずつ隔離して動かし、宣言して管理者が承認した権限しか使わせない。WordPressの弱点だったプラグインの安全性に、構造で答えた
• MITライセンスのオープンソース。WordPressから記事やメディアを取り込める。EmDash同士では、記事、編集履歴、メディア、一部の設定などをまとめて転送できる（ユーザーアカウントやプラグインの設定・保存データは対象外）
• Cloudflareの基盤なら負荷に強い。Cloudflareは自社の公式ブログを移し、週数百万ページビュー、最大で毎秒5,000リクエストの正規の通信をさばく前提で運用している

リスク

• 方向を決めるのは、Cloudflareが任命するプロジェクトリードである（次の章で詳しく）
• 若い。Cloudflareが1.0を安定版として発表したのは9月28日で、10月29日には1.4.0が出るほど動きが速い。公式プラグインとプラグイン用のツールはまだ0.x
• サイトと同じプロセスで動くネイティブ型のプラグインもあり、こちらには同じ隔離がない。またHyperdriveやWorkers Cacheとの連携、AIサイトビルダーのEmDash Buildなどは、Cloudflareのサービスを使う。CMS本体はNode.jsでも動くが、移しやすさは採用した機能と構成で変わる

向くサイト：技術者が関わるブログ、メディア

8月に約1時間だけ触ったときは、v0.35.0でした（117036）。公開されている試用環境では、プラグインの導入が意図的に閉じられていました。WordPressからの取り込みでは、サイトのURLを入れると、項目ごとに移せるかどうかが表示されました。

Wix

メリット

• サーバーの保守はWixが引き受ける。技術の知識がなくても始められる
• ECや予約など、店舗に必要な機能が揃っている。入口は広く、WordPressからは公開済みの記事を1回に最大5,000件取り込める（著者名やタグは引き継がれず、旧URLからの転送は自分で設定する）
• 8月にはGoogleのGeminiとの連携を発表し、会話からサイトの作成や更新、在庫や予約の管理まで扱えるようにした（116870）。ただし、Googleのヘルプにある対応言語に、現時点で日本語は含まれていない

リスク

• 出口は狭い。公式ヘルプによれば、ブログ記事は現時点でほかのサービスへ書き出せない。CMSのデータや商品はCSVで書き出せる
• 独自のコードや外部との連携で拡張できるが、公開や運用はWixの基盤と仕様に従う

向くサイト：社内に技術者がいない店舗、小規模の事業

Studio

メリット

• デザインの自由度が高く、デザイナーが直接サイトを組める。公開サイトは22万件以上（同社発表）
• 国内のサービスで、日本語の情報が得やすい
• サーバーの保守はStudioが引き受ける。9月には、既存のサイトをURLから取り込み、AIとの対話で編集する「Studio.Drop」のクローズドβの事前登録を始めた（117456）

リスク

• 公開できるCMSのアイテム数に上限がある。Enterpriseを除く最上位のBusiness Plusで1万5,000件。記事が増え続けるメディアでは、選ぶ前に確かめておきたい数字
• 入口はWordPressのXMLからの取り込みが用意されている（Studio.DropのβではURLからも）が、出口は狭い。公式ヘルプによれば、デザイン、ページの情報、ソースコード、CMSのデータを書き出す機能は用意されていない（フォームの回答はCSVで書き出せる）。ほかのサービスへ移るときは、移る先で作り直す前提になる

向くサイト：デザインを重視する会社のサイト、ブランドのサイト

AIで自作したCMS

メリット

• CMSの方向を自分で決められる。CMSを提供する他社の方針転換やライセンスの変更に左右されにくい
• 必要な機能だけを作れるので、仕組みを小さく保ちやすい。PHPを使わない構成も選べる
• データの形や編集の流れを、自分の媒体に合わせて設計できる

リスクと備え方

• 認証、権限、秘密情報、バックアップまで含めて、安全性は自分で設計し、確かめる。依存するソフトを絞り、テストと更新の手順を決めておく
• 使うホスティングやライブラリへの依存は残る。作った人が離れたときに備えて、設計を文書にし、設計を理解する人が変更を確かめる体制をつくる。AIはその作業を助ける
• フィード、サイトマップ、OGP、画像の最適化、データの書き出しと復元など、既存のCMSにある機能を自前で揃える

向くサイト：要件がはっきりしていて、長く関わる運営主体がいるサイト。規模の大小では分けない

6つを並べると

	PHPの更新	入口（ほかから移す）	出口（ほかへ移す）	誰が保守するか	何ができるか
WordPress	必要	広い（各種の取り込みツール）	広い（XMLで書き出し、移設の手順あり）	自分、または委託先（ホスティング会社、制作会社）	プラグインで広く賄える
静的HTML	不要	構成次第	広い（ファイルそのもの）	自分、または委託先	配信に特化。動的な機能は別の仕組みで補う
EmDash	不要	WordPressから取り込める	EmDash同士の転送の機能あり	自分、または委託先	CMSとして一通り。拡張はこれから育つ
Wix	不要	広い（WordPressなどから取り込める）	狭い（ブログ記事は書き出せない）	Wix	ECや予約まで、Wixの中で揃う
Studio	不要	WordPressのXMLから取り込める	狭い（デザインやCMSのデータの書き出し機能はない）	Studio	デザインの自由度が高い
AIで自作したCMS	不要にできる	自分で作る	自分で作る（標準の形式に合わせれば広くできる）	自分、または委託先（AIが作業を助ける）	必要なものを、必要なだけ

入口が広いのは、乗り換え先として選ばれたいサービスにとって自然なことです。比べるときに差が出るのは出口のほうです。

誰に手綱を預けるか

EmDashのリスクに挙げた「誰が方向を決めるか」は、オープンソースのCMSを選ぶときに見落とされやすい論点です。

EmDashはMITライセンスなので、誰でもコードを使い、改変し、別のプロジェクトとして続けられます。ただし、コードを使う自由と、プロジェクトの方向を決める権限は別のものです。EmDashの運営規則（GOVERNANCE.md）では、通常の判断はメンテナーが担い、方向性や合意できない問題は、協議を経てプロジェクトリード（現在はマット・ケイン氏）が最終的に判断します。そのプロジェクトリードを任命するのはCloudflareです。運営規則が定めているのは現在の体制で、財団のような中立的な運営体制への移行は、これからの論点です。プラグインの登録簿は、作者が自分のアカウントで署名して公開する分散型の設計で、仕組み自体もオープンソースにしていますが、既定の目録はEmDashの側が運営しています。

同じ問いは、WordPressにも向きます。WordPress.orgの運営はマレンウェッグ氏に権限が集まる形で、2024年からのWP Engineとの対立では、その構造そのものが問われました（42343）。2025年には、Linux FoundationがWordPress向けに、1か所に頼らない配布の仕組みを立ち上げています（57014）。

違いがあるとすれば、WordPressには20年以上の実績があり、運用先や保守を頼む事業者を選べることです。EmDashには、Cloudflare以外のNode.jsのサーバーでも動かせるという保険があります。その保険がどこまで効くかは、使いたい機能がCloudflareのサービスに頼っているかどうかで変わります。

どのCMSを選ぶにしても、見ておきたいのは、誰が手綱を握っているのか、そしてその会社や人が手を引いたとき、自分のサイトがどうなるのかです。

AIで自作するという選択肢

手綱を誰かに預けるのではなく、自分で握る。それが、AIで自作するという選択肢です。

CMSの自作には、これまでも設計と開発、そして継続的な保守を担う技術が欠かせませんでした。AIのコーディング支援は、その作業の多くを助けるようになっています。作るときだけでなく、保守を続けるときにも効くことが大きな変化です。汎用のCMSが持つ機能の大半を使っていないサイトほど、自分の用途に合わせて作る意味は大きくなります。

成り立つ条件は、4つに整理できます。

• 要件がはっきりしている：何を載せ、誰が書き、どう見せるかが決まっている
• 長く関わる運営主体がいる：作った人や組織が、サイトと一緒に歩み続ける
• 保守の備えがある：設計の文書、テスト、更新の手順、そして設計を理解する人とAIの分担
• 出口を用意してある：記事や画像を、ほかのCMSが読める標準の形式で書き出せるようにしておく。自作をやめる日が来ても、データは連れて出られる

これらがそろえば、自作のCMSは、ほかの5つでは得にくい「自分の媒体に合った形」と「CMSの方向を自分で決められる手綱」を手に入れる道になります。

選び方の目安と、残る問い

データを持ち出せるかどうかと、保守を誰に頼むかは、別々に選べます。WordPressでも自作のCMSでも、データを手元に置いたまま保守を委託することはできます。さらに、公式プロジェクトの方向を決める権限と、自分のサイトの実装を変える自由も、別のものです。WordPressやEmDashは、公式版をそのまま使うこともできれば、フォークして独自の方向を選びながら、上流の修正を取り込むこともできます。

そこで最後に、6つの選択肢を「共通の仕組みに頼る部分」と「自分たちで担う部分」に分けて並べてみます。どの選択肢でも、独自のコードや外部との連携を加えれば、その管理は自分たちに残ります。表は保守の分担を整理したもので、自由度や保守の手間の順位ではありません。

	共通の仕組みに頼る部分	自分たちで担う部分
Wix、Studio	基盤全体（各社が保守）	コンテンツと設定、追加した独自のコードや外部連携の管理。書き出せる範囲を確かめておく
WordPress、EmDash（公式版）	本体の修正（開発コミュニティや公式プロジェクトが届ける）	更新の適用と動作の確認、テーマ・プラグイン・連携するサービスの選択と管理、独自に作った部分の保守
WordPress、EmDash（フォーク）	上流の修正	独自の変更、上流との差分の統合とテスト
静的HTML	生成ツールや配信基盤の修正（使う場合）	サイトそのもの、ツールの更新
AIで自作したCMS	使うライブラリやホスティングの修正	自分たちで作った部分すべて

自分の媒体に合わせて変えられる範囲と、自分たちで担う保守の量は、選択肢の名前だけでは決まりません。自由と保守の共有は二者択一ではなく、どこまでを共通の仕組みに頼り、どこからを自分たちで担うかの選択です。

目安としては、次のように考えられます。

• 更新が年に数回の会社案内やLPなら、静的HTML
• 記事を継続的に出すブログやメディアで、技術者が関われるなら、EmDashやAIで自作したCMSが有力な候補。EmDashは若さとCloudflareのサービスへの依存を、自作は保守の体制を見極める
• 会員、決済、予約などが絡むなら、WordPress（またはそれに相当する成熟したCMS）を続け、PHPとプラグインの更新の体制を整える
• 社内に技術者がいない小規模の事業なら、WixやStudio。保守を任せる代わりに、出口の狭さを受け入れる
• どれを選ぶ場合も、入る前に出口を確かめる。何を、どの形式で書き出せるのかを、移る前に一度試しておく

その選択で鍵になるのは、作り変えた部分を、共通の仕組みからどれだけ切り離しておけるかです。WordPressのフックや子テーマのような拡張の仕組みを使えば、本体の修正を受け取りやすく保てます。一方、本体を直接大きく変える場合は、上流の修正を取り込むたびの確認と統合が重くなりやすく、その作業を自分たちと委託先のどちらが担うかも決めておく必要があります。

自分の媒体に合った形と、共通の修正の受け取りやすさを、どう両立させるか。これは、6つのどれを選んでも残る問いです。

PHP2Shellを通じて、私が改めて考えたのは、「どのCMSが安全か」と同じくらい、「このサイトの更新を、誰が、いつまで引き受けるのか」という問いでした。CMS選びとあわせてこの役割分担を決めておくことが、次の緊急対応への何よりの備えになるはずです。

【関連記事】

WordPress vs WP Engine：オープンソースの未来を揺るがす対立

Linux Foundation、WordPress論争に終止符？「FAIRパッケージマネージャー」で分散型エコシステム構築へ

WordPress 7.0 RC3公開、目玉機能「リアルタイム共同編集」は土壇場で見送りへ

WordPress 7.1、AIに読まれるCMSへ ─ シェア41.5%が問う「エージェント時代の生き残り方」

WordPress、守る場所は管理画面からAPIへ｜wp2shellが示したもの

WordPress 7.1が固めた足回り｜共同編集は今回も見送り

WixとGeminiが連携｜AIとの会話からWebサイト作成・更新・運営まで可能に

エックスサーバー、wp2shell対応で顧客のWordPressを更新

EmDashを1時間だけ触ってみた｜本文欄のないCMS

Studio.Drop、狙いは新規制作でなく更新の止まったサイト

WordPress 7.1.2、Critical脆弱性を修正｜「条件付き」の中身を読む

MCP Adapter配布開始、WordPress公式ディレクトリから導入可能に

【解説】PHP2Shell、AIが見つけたPHPの重大脆弱性　CVE番号の流出で公開を前倒し

PHP2Shell、修正から1日｜「被害は確認されていない」をどう読むか？サービスは戻っても残る3つの宿題

【編集部後記】

記事は連れて出られても、URLまで連れて出られるとは限りません。WixのヘルプにはWordPressから記事を取り込む手順が丁寧に書かれていますが、旧URLからの転送は自分で設定するよう求めています。

何年も前の記事に、外のサイトから張られたリンク。検索で見つけて、ブックマークしてくれた読者。それもまた、サイトが積み上げてきた財産です。乗り換え先を比べるとき、そのURLを次の場所でも生かせるかどうかを、一度確かめてみてはいかがでしょうか。

---

【用語解説】

PHP
Webサーバーの側で動くプログラミング言語。WordPressをはじめ、多くのCMSや業務システムがPHPで書かれている。サポートが終わった版には、通常のセキュリティ更新が届かない。

CMS（コンテンツ管理システム）
記事や画像を、HTMLを直接書かずに管理・公開するためのソフトウエア。WordPress、EmDashなどがこれにあたる。

静的サイトジェネレーター
記事などの原稿から、あらかじめHTMLファイルを生成しておく道具。AstroやHugoが代表例。閲覧のたびにサーバーでページを組み立てる必要がない。

GPL／MITライセンス
オープンソースソフトウエアの利用条件。GPLは改変して配布する場合に同じ条件での公開を求め、MITはより緩やかな条件で利用・改変・再配布を認める。WordPressはGPL、EmDashはMITで公開されている。

フォーク
オープンソースのコードを複製し、別のプロジェクトとして独自に開発を続けること。元のプロジェクト（上流）の修正を取り込み続けることもできる。

サンドボックス
プログラムを隔離した環境で動かし、あらかじめ許した範囲の操作しかできないようにする仕組み。

WXR
WordPressが記事、固定ページ、カテゴリーなどを書き出すときのXML形式。ほかのCMSへの移行でも、取り込みの入口として広く使われる。

フック／子テーマ
WordPressの本体や親テーマを直接書き換えずに、機能や見た目を変えるための仕組み。本体の更新を受け取りやすい形で手を加えられる。

MCP（Model Context Protocol）
AIエージェントが外部のツールやデータにアクセスするための共通の手順。

OGP
SNSでページが共有されたときに表示されるタイトルや画像を指定する仕組み。

【参考リンク】

Critical PHP Security Release｜WordPress.org（外部）
PHP2ShellはWordPress固有の問題ではなく本体の更新は不要とし、サイトの運営者にPHPの即時更新を呼びかけた公式の告知。

PHP: News Archive – 2026（外部）
PHP2Shellの修正版（8.5.12、8.4.27、8.3.36、8.2.35）の公開と、8.1以前の扱いを伝えるPHP公式の告知。

Historical trends in the usage statistics of content management systems｜W3Techs（外部）
全Webサイトに占めるWordPressのシェアと、CMSを検出できないサイトの割合を、月ごとの推移で示すW3Techsの統計ページ。

State of WordPress Security in 2026｜Patchstack（外部）
2025年に見つかったWordPress関連の脆弱性1万1,334件を、プラグイン、テーマ、本体に分けたPatchstackの年次報告。

EmDash 1.0: the stable CMS with a secure plugin registry｜Cloudflare Blog（外部）
EmDash 1.0を安定版として発表し、作者が署名して公開する分散型のプラグイン登録簿も紹介したCloudflareの公式ブログの記事。

GOVERNANCE.md｜emdash-cms/emdash（GitHub）（外部）
EmDashの運営規則。通常の判断はメンテナー、最終判断はプロジェクトリードが担い、そのリードをCloudflareが任命すると定める。

Wix Blog: Importing Blog Posts from WordPress to the Wix Blog｜Wix（外部）
WordPressから公開済みの記事をWixのブログへ取り込む手順と、件数の上限や引き継がれない項目などの条件を説明する公式ヘルプ。

Wix Blog Request: Exporting Blog Posts to Other Platforms｜Wix（外部）
Wixのブログ記事を、現時点ではほかのプラットフォームへ書き出せないことを示す公式ヘルプ。乗り換えを考える前に確かめたい一文。

他のプラットフォームへ移行するため、Studioのサイトデータをエクスポートしたい｜Studio Help（外部）
Studioにはデザインやページ情報、CMSのデータを書き出す機能がなく、フォームの回答だけはCSVで出せると説明する公式ヘルプ。

【参考記事】

EmDash 1.0 Challenges WordPress Freedom With Cloudflare Lock-In｜Search Engine Journal（外部）
EmDash 1.0の新機能の多くがCloudflareの基盤を前提にしており、利用者がロックインされる懸念があると論じた解説記事。

Automattic & Matt Mullenweg Fail To Dismiss WP Engine Antitrust Claims｜Search Engine Journal（外部）
WP Engineの反トラスト法に基づく請求が却下されず、Automatticなどとの訴訟の審理が続くことを伝えた記事。

Cloudflare’s new CMS is not a WordPress killer, it’s a WordPress alternative｜Computerworld（外部）
EmDashをWordPressを倒す存在ではなく選択肢の一つと位置づけ、強みと限界を整理したComputerworldの分析記事。

PHPの2件の深刻な脆弱性(CVE-2026-109618、CVE-2026-109619)についてまとめてみた｜piyolog（外部）
PHP2Shellの時系列、影響を受ける条件、IPAやJPCERT/CCなど国内の対応、サービスを一時停止した組織をまとめた記事。