PHPの脆弱性に関する情報を見て、「会社のホームページもWordPressをやめたほうがいいのだろうか」と迷っていませんか。Cloudflareが開発するEmDashを知り、乗り換えを考えている方もいると思います。
私たちは、会社のホームページを選ぶとき、セキュリティの仕組みと、公開後の運用を続けられるかの両方を見る必要があると考えています。EmDashには安全性を高める設計があります。一方、WordPressに慣れたスタッフと保守担当がいる会社なら、継続利用が合理的な場合もあります。
この記事では、公式資料で確認できる違いをもとに、社内で記事を更新する会社がCMSを選ぶときの判断材料を整理します。
PHPの脆弱性だけでWordPressをやめる結論にはならない
脆弱性の情報が出たとき、最初に行うのは、自社サイトへの影響確認と対処です。CMSの乗り換えを検討している間も、現在のサイトの問題は残ります。まず保守担当やサーバー会社へ確認しましょう。
PHPの問題とWordPress本体の問題を区別する
PHPはWordPressを動かすために使われるソフトウェアです。PHPの脆弱性と、WordPress本体の脆弱性は、同じものではありません。
2026年10月22日に公表されたIPAのPHPに関する注意喚起も、PHPの脆弱性への対策を求める情報です。自社が利用するバージョンや構成、修正の適用状況などを確認する必要があります。WordPressを使っているという理由だけで、すべてのサイトに同じ影響があるとは判断できません。
PHPを使わない構成を選べば、その構成では同じPHPの問題を避けられます。ただし、別のソフトウェアやサービス、アカウントの管理は残ります。PHPを使うかどうかだけで、サイト全体の安全性は決まりません。
今回の対処と、長期的なCMS選びを分ける
緊急時の対応と、今後どのCMSを使うかは、時間を分けて考える必要があります。影響のある環境なら、修正やアクセス制限など、その時点で必要な対策を担当者と確認します。一時停止した事実だけで、管理不足や情報漏えいがあったと決めつけることもできません。
そのうえで、今の仕組みを管理し続けられるか、移行によって何が改善するかを検討します。公開後に必要な作業については、ホームページを放置するリスクと、公開後に必要な保守管理で詳しく解説しています。
EmDashの強みはプラグインの権限を制限できること
EmDashを比較するときは、その安全設計の利点をきちんと評価したいところです。特に、追加機能であるプラグインに、必要以上のアクセスを与えない仕組みが用意されています。
隔離された実行環境でアクセス範囲を絞る
CloudflareのEmDash 1.0の発表では、サンドボックス型プラグインを隔離した環境で実行し、追加の権限を宣言・承認する仕組みが説明されています。サンドボックスとは、プログラムが動ける範囲を制限する仕組みです。
たとえば、画像を扱う機能に、その作業とは関係のない情報や外部通信へのアクセスまで無条件に与えない設計です。プラグインに問題があった場合の影響範囲を抑えるうえで、有用な考え方といえます。
通常のWordPressプラグインには、これと同じ実行時の隔離が標準で備わっているわけではありません。WordPressを使い慣れているという理由で、この違いを小さく扱うべきではないと私たちは考えます。
隔離の対象と、実際の設定を確認する必要がある
ただし、「EmDashなら、どんな追加機能も必ず隔離される」という説明は正確ではありません。公式のサンドボックス設定資料では、ネイティブ型プラグインはサーバーのプロセス内で動き、同じ隔離の対象にならないことが示されています。
サンドボックス型を使う場合も、配置先に応じた実行環境や設定が必要です。Cloudflareに配置するか、自社でNode.js環境を用意するかによって条件が異なります。
比較するなら、製品名だけでなく「このサイトでは、どの種類のプラグインを、どの設定で動かすのか」を確認しましょう。権限を制限する仕組みがあっても、何を許可するかという判断は残ります。
EmDashでも作ったまま放置すれば管理の抜けが生まれる
EmDashの安全設計は、保守管理が不要になることを意味しません。AIでサイトを作りやすくなっても、公開後に誰が状態を確認するかは決めておく必要があります。
CMSや関連ソフトの更新・動作確認は残る
EmDashの公式更新手順には、更新内容を確認して適用し、配置後に管理画面や公開ページなどを確認する流れがあります。データの変更を伴う場合などには、復旧できる状態を確保する必要もあります。
これは、更新するたびに必ず難しい作業が発生するという意味ではありません。ただ、サイトの構成を理解し、必要な対応を判断する担当者がいることは前提になります。
Cloudflareなどのサービス側が引き受けるインフラ管理もあります。その分、運用側の負担を減らせる可能性はありますが、CMSや自社で追加した機能まで、すべて自動で管理されるとは限りません。委託先が対応する場合も、契約範囲を確かめておきましょう。
アカウント・顧客情報・復旧手順は自社でも確認する
CMSの種類にかかわらず、管理アカウントを誰が使うのか、問い合わせ内容がどこに保存されるのか、外部サービスに何を渡すのかは確認が必要です。
退職した担当者のアクセスが残ったり、使わなくなった外部連携の権限が残ったりすれば、CMSの安全設計だけでは解決できません。問い合わせフォームがある場合も、顧客情報をサイト内に保存する構成なのか、メールや外部サービスへ送る構成なのかで管理対象が変わります。
「安全だと聞いたので、誰も確認していない」という状態は避けたいものです。更新未適用や不要な権限など、対処できる問題を見落とすおそれがあります。導入前に、更新通知を受け取る人と、問題があったときに相談する先を書き出してください。
社内スタッフが更新する会社でWordPressを選ぶ合理性
社内でお知らせやコラムを更新する会社では、日常の作業を無理なく続けられることも大切です。私たちは、すでにWordPressで更新が定着し、保守体制もある会社なら、その運用を生かす選択には合理性があると考えています。
慣れた編集画面と手順を引き継いで使える
WordPressの標準ブロックエディターでは、段落、画像、見出しなどをブロックとして扱えます。担当者が操作に慣れていて、社内の更新手順も整っているなら、その蓄積は継続利用を判断する材料になります。
新しいCMSに移れば、編集画面の操作だけでなく、公開までの確認や担当交代時の手順も見直すことになります。その負担をかけても得たい改善があるかを考えましょう。
一方で、EmDashにも編集用の管理画面があります。「記事を更新するスタッフが技術者ではないから、EmDashは使えない」とは言えません。両方の画面で、実際に自社が行う文章修正や画像差し替えを試すのが確実です。
記事の更新担当と技術面の保守担当を分けられる
WordPressには、編集者・投稿者などの役割に応じた権限があります。通常の単一サイトでは、編集者は記事を公開・管理できる一方、プラグインの追加などの管理操作とは権限を分けられます。
スタッフは内容の作成と更新、技術担当はソフトウェアの更新や障害対応という分担を設ければ、全員に管理者権限を渡す必要はありません。ここでいう人の操作権限と、EmDashのプラグインの実行権限は、対象が異なります。
もちろん、権限を分けるだけで安全になるわけではありません。WordPress公式のセキュリティ資料でも、更新やバックアップなどが案内されています。記事を投稿できることと、技術面の保守ができることは別です。
自社が続けられる運用を比較する
比較するときは「どちらが高機能か」に加えて、自社に必要な担当者と手順がそろうかを見てください。
| 比較項目 | WordPressで確認すること | EmDashで確認すること |
|---|---|---|
| スタッフの編集 | 現在の画面・手順で更新を続けられるか | 管理画面で自社の編集作業を試せるか |
| 追加機能 | 必要性・提供元・更新状況 | 種類・許可する権限・隔離の設定 |
| 技術面の保守 | PHP・本体・テーマ等の担当範囲 | CMS・依存ソフト・配置先の担当範囲 |
| 障害と担当交代 | 復旧手順と引き継ぎ先 | 復旧手順と引き継ぎ先 |
「WordPressのほうが安心」と感じる理由が、操作に慣れているからなのか、保守を任せられる人がいるからなのかも整理しましょう。後者までそろっていれば、運用上の安心を支える具体的な条件になります。
乗り換える前に運用担当と移行後の費用を確かめる
移行は、今の困りごとを改善するための選択です。新しいCMSを使うこと自体を目的にせず、編集、保守、費用について、現在と移行後を比べると判断しやすくなります。
更新・障害対応・引き継ぎの担当者を決める
WordPressで日常の更新ができ、技術担当が脆弱性対応や復旧を引き受けているなら、まず現在の構成や保守範囲を見直す方法があります。使っていないプラグインや、担当が曖昧な作業を確認することも、その一つです。
EmDashを選ぶ場合は、自社の構成に合った更新手順を扱える担当者や委託先を確保します。技術面を任せる先があり、スタッフも編集を続けられるなら、導入を検討する条件が整います。
どちらも、制作した人がいなくなった後まで考えてください。ソースコード、契約、管理アカウント、復旧方法を会社が把握できるか。困ったときの連絡先が一人にしか分からない状態になっていないか。製品を比較する前に確認できることです。
制作費だけでなく移行と保守の見積もりを比べる
CMS自体を無料で利用できても、会社のサイト全体を無料で運用できるとは限りません。次の項目を分けて見積もりを取り、含まれる作業を確認しましょう。
| 費用項目 | 見積もりで確認する内容 |
|---|---|
| 初期構築・移行 | 記事、画像、デザイン、フォーム等の移行範囲 |
| 編集の習得・引き継ぎ | 操作説明、社内手順の作成、担当変更時の支援 |
| 利用環境 | ホスティング、保存領域、外部サービス等の料金 |
| 継続保守 | 更新、確認、監視、問い合わせ対応の範囲 |
| 障害復旧 | バックアップからの復元、追加料金、対応条件 |
記事を移せることと、今のテーマや追加機能をそのまま再現できることも別です。移行先で必要な機能が実現できるか、URLの変更や転送への対応が必要かも確認します。
私たちは、会社のホームページは、公開した後に情報を更新し、相談につながる内容へ改善していくことが大切だと考えています。CMSの選定も、その運用を続けるための判断です。今の更新や保守に不安があれば、まずホームページの制作・運用について相談するところから始めてください。
よくある質問
Q. EmDashならセキュリティ対策は不要ですか。
A. 不要にはなりません。サンドボックス型プラグインの権限を制限する設計はありますが、CMSの更新やアカウント管理などは残ります。配置先のサービスに任せられる範囲と、自社や委託先が担当する範囲を確認してください。必要な保守がすべて自動化されるとは限りません。
Q. EmDashでは技術者以外は記事を更新できませんか。
A. EmDashにも編集用の管理画面があり、技術者以外のスタッフが内容を管理する使い方が想定されています。ただし、サイト構築や技術的な更新とは別です。自社のサイトで必要な操作ができるか、公開前にスタッフが試し、分からないときの相談先も決めておきましょう。
Q. WordPressの記事をスタッフが更新できれば保守もできますか。
A. 記事を編集できることだけでは、保守までできるとは判断できません。PHPやプラグインの更新、更新後の不具合調査、データの復元には別の知識が必要です。社内で行う作業を決めたうえで、技術面の対応を社内担当者と外部のどちらが引き受けるのか確認してください。
Q. PHPの問題が起きたらすぐにCMSを移行するべきですか。
A. 最初に、自社の環境が影響を受けるかと、必要な対策を確認します。CMSの移行は準備や検証が必要になるため、今ある問題への対処とは分けて考えましょう。緊急の対応を済ませた後、移行先の管理体制や機能、費用まで確認して判断するのが現実的です。
Q. WordPressを使い続ける会社は何を確認すればよいですか。
A. スタッフが更新できるかに加えて、本体や関連ソフトの更新、アカウント管理、バックアップ、障害復旧の担当を確認してください。委託している場合も、契約に含まれる範囲を確認します。「誰かがやっているはず」という作業をなくすことが、継続利用を判断する土台になります。
まとめ
EmDashには、プラグインの権限を制限する安全設計があります。その利点を評価したうえで、自社が公開後の管理を続けられるかを確認することが大切です。
WordPressに慣れたスタッフがいて、技術面の保守担当も決まっている会社なら、継続利用は合理的な選択肢です。EmDashも、編集と保守の体制が確保できれば検討できます。まず、今のホームページで誰が何を管理しているかを確認し、その体制で続けられるCMSを選びましょう。
参考文献
- IPA：PHPの脆弱性対策について — 今回のPHPに関する注意喚起。
- Cloudflare：EmDash 1.0の発表 — 編集機能とプラグインの権限管理。
- EmDash：サンドボックスの設定 — 隔離の対象と環境ごとの条件。
- EmDash：更新手順 — 更新と配置後の確認。
- WordPress：ブロックエディター — 標準の編集機能。
- WordPress：役割と権限 — 編集と管理の操作権限。
- WordPress：セキュリティの強化 — 更新やバックアップの考え方。
