記事の概要

質問の詳細

WordPressのサイト制作を外部の業者・フリーランス等に委託するとき、悪質な業者にぶつかってしまい、いざというときに連絡が取れなくなるケースがあります。

質の悪い業者にあたってしまわないようにするにはどうすれば良いでしょうか？ また、運悪くそのような業者に当たった場合、どのようにトラブルを解決すべきでしょうか？

回答の詳細

WordPress制作では「業者への依存」を減らすことが重要

WordPressサイト制作のトラブルというと「悪質な制作会社に騙された」というケースを想像するかもしれません。

しかし、必ずしも悪意があるとは限りません。

例えば、以下のような理由で、突然サポートを受けられなくなることもあります。

• 制作者が病気になった
• フリーランスが廃業した
• 制作会社が倒産した
• 担当者が退職した
• 会社の事業内容が変わった

そのため、業者選びでは、「この会社なら絶対安心だろう」と考えるだけでは不十分です。

むしろ、「明日からこの会社と連絡が取れなくなったとしても、自分のサイトを維持できるだろうか？」という視点を持っておくことが重要です。

WordPressは比較的引き継ぎやすいCMS（Webサイトを管理する仕組み）です。適切に管理されていれば、別の制作会社や制作者へ移管することもできます。

ところが、必要な権限をすべて制作会社側が握ってしまうと、このWordPress本来のメリットを十分に活かせません。

ドメインはできるだけ自分名義で契約する

まず確認したいのが、ドメインの所有者です。ドメインとは、example.comのようなWebサイトの住所にあたるものです。

制作会社によっては、「面倒な手続きはこちらですべて行います」として、制作会社名義でドメインを取得する場合があります。手間がかからないため一見便利ですが、長期的には注意が必要です。

例えば、契約終了後に「ドメインを移管してもらえない」という問題が発生すると、非常に面倒です。サイトのデザインや記事データは作り直せても、長期間使用してきたドメインを失ってしまう影響は小さくありません。

特別な事情がなければ、ドメインはサイト運営者自身の名義・アカウントで契約することをおすすめします。

レンタルサーバーも自分で契約する

ドメインと同じくらい重要なのがレンタルサーバーです。WordPress本体や画像、テーマなどのデータは基本的にサーバー上に保存されています。

そのため、「ドメイン」「サーバー」の両方を業者側が管理していると、トラブルになった際にサイトへアクセスできなくなる可能性があります。

理想的なのは、サイト運営者がレンタルサーバーを契約し、制作会社に必要な作業権限だけを渡す方法です。

こうしておけば、制作会社との契約が終わったとしても、サーバーそのものは手元に残ります。

WordPressの管理者アカウントを必ず持っておく

WordPressには複数のユーザー権限があります。

代表的なものには、「管理者」「編集者」「投稿者」「寄稿者」「購読者」があります（デフォルトではこの5つが設定されています）。このうち、「管理者」はテーマやプラグイン、ユーザー管理などを含め、WordPressサイトのほぼすべてを操作できます。

制作会社へサイト制作を依頼する場合でも、サイト運営者自身の管理者アカウントを1つは確保しておきましょう。

• サイト運営者：管理者
• 制作会社：管理者
• ライター：投稿者

という形にしておけば、一般的には問題ありません。

制作会社との契約終了後は、その会社用の管理者アカウントを削除したり、権限を変更したりできます。

逆に、「セキュリティ上の理由でお客様には管理者権限を渡しません」などと言われた場合は、その理由を詳しく確認した方がよいでしょう。

運営者本人が自分のサイトを管理できない状態には注意が必要です。

契約書や見積書の内容を確認する

制作を依頼するときは、料金だけを見るのではなく、「どこまでやってくれるのか」を確認することが重要です。

最低でも次のような内容は確認しておきたいところです。

• 制作ページ数
• 制作料金
• 納期
• 修正可能回数
• 使用するテーマ
• 使用するプラグイン
• サーバー管理の担当者
• ドメイン管理の担当者
• 保守料金
• 保守内容
• バックアップ方法
• 納品物
• 著作権の扱い
• 契約終了方法
• 契約終了後のデータ引き渡し方法

例えば、「ホームページ制作一式 300,000円」だけでは、具体的に何をしてもらえるのか分かりません。

後になって、「お問い合わせフォームは別料金です」「スマートフォン対応は含まれていません」「修正は1回までです」といった話が出てくる可能性もあります。

契約内容は、できるだけ具体的にしておきましょう。

【雑談】料金表は公開すべきか否か？ メリット・デメリットを解説します

WP Pilot

保守契約を終了するとどうなるか確認する

WordPress制作では、完成後に月額の保守契約を結ぶ場合があります。

保守契約自体に問題はありません。

WordPressは、「WordPress本体」「テーマ」「プラグイン」などを定期的に更新する必要があるため、専門家へ管理を任せるメリットもあります。

注意したいのは、保守契約を終了したらサイトがどうなるのか分からないケースです。契約前に、「保守契約を解除した場合、Webサイトはどうなりますか？」と確認してみましょう。

特に確認したいのは次の点です。

• サイトはそのまま表示できるか
• テーマはそのまま使用できるか
• 有料プラグインは使用できるか
• アップデートできなくなる機能はあるか
• 自分でライセンスを購入すれば継続できるか
• 別の制作会社へ移管できるか

制作会社が複数サイト向けのライセンスを利用している場合、保守契約終了後にそのライセンスが外れること自体は珍しくありません。

重要なのは、そのことが事前に説明されているかどうかです。

制作実績の「デザイン」だけを見ない

制作会社を選ぶとき、多くの人がポートフォリオを確認するでしょう。

もちろん制作実績を見ることは重要です。ただし、「おしゃれなサイトをたくさん作っている」という理由だけで決めるのはおすすめできません。

WordPressサイトでは、見た目以外にも、

• 更新しやすいか
• スマートフォンで見やすいか
• 表示速度に問題がないか
• バックアップが取られているか
• セキュリティ対策が行われているか
• テーマやプラグインが適切に管理されているか
• 別の制作者へ引き継げるか

なども重要です。

完成したサイトの見た目だけでは、こうした部分は分かりにくいものです。

そのため、制作実績を見るときには、「制作後の運用まできちんと考えている会社か」という視点も持っておきましょう。

契約前に少し細かい質問をしてみる

業者選びでは、契約前のやり取りも重要な判断材料になります。

例えば、次のような質問をしてみましょう。

• 契約終了後、別の制作会社へ引き継ぐことはできますか？
• ドメインやサーバーはこちらで契約しても問題ありませんか？
• WordPressの管理者アカウントは受け取れますか？
• 使用予定のテーマやプラグインを教えてもらえますか？
• バックアップはどのように取りますか？
• 保守契約を終了すると使えなくなる機能はありますか？

難しい専門知識を問う必要はありません。重要なのは、質問に対してきちんと説明してくれるかです。

一方、「その辺はこちらに任せてもらえれば大丈夫です」「専門的なことなので説明できません」「契約してから説明します」といった回答ばかりの場合は、少し慎重になった方がよいでしょう。

こんな業者には少し注意しよう

もちろん、一つ当てはまっただけで悪質業者と決めつけるべきではありません。ただし、次のような特徴が複数見られる場合は注意した方がよいでしょう。

• 契約書を作りたがらない
• 見積書の内訳が極端に曖昧
• ドメインを業者名義にしたがる
• サーバーの情報を教えてくれない
• WordPress管理者権限を渡さない
• 使用テーマやプラグインを説明しない
• 解約条件が分からない
• 他社への移管について説明しない
• 契約を急かす
• 即決を条件に大幅値引きをする
• 質問すると態度が急に悪くなる
• 契約終了後にサイトがどうなるのか説明しない

特に、「ドメイン・サーバー・WordPress管理者権限のすべてを制作会社が握っている」という状態は避けたいところです。

優良な業者は「囲い込み」をしない

逆に、信頼しやすい制作会社にはどのような特徴があるのでしょうか。

一つの目安になるのが、「別の会社への引き継ぎを想定しているか」です。

例えば、以下のように進めていただける会社は、比較的安心して付き合いやすいでしょう。

• ドメインは顧客名義
• サーバーも顧客名義
• 管理者アカウントを顧客へ渡す
• テーマやプラグインを説明する
• 操作マニュアルを渡す
• バックアップ方法を説明する
• ライセンス条件を説明する
• 契約終了時の移管にも対応する

良い制作会社とは、「ずっと自社へ依存させる会社」ではなく、「必要であれば他社にも引き継げる状態にしてくれる会社」ともいえます。

すでに怪しい業者と契約してしまったら？

ここからは、すでにトラブルが起きてしまったケースについて考えてみましょう。

まず重要なのは、相手と激しく言い争うことではありません。サイトと証拠を確保することを優先します。

可能であれば、次のものを保存しておきましょう。

• WordPressのバックアップ
• データベース
• 画像
• テーマ
• 子テーマ
• 独自プラグイン
• 契約書
• 見積書
• 請求書
• 支払い記録
• メール
• チャット履歴
• 制作会社から受けた説明資料

制作会社のWebサイトに掲載されている契約条件なども、必要に応じてスクリーンショットを保存しておくとよいでしょう。

管理アカウントやパスワードを確認する

制作会社との契約が終了した場合は、アクセス権限も整理します。

代表的なものとして、以下のようなものがあります（場合によっては使用していないこともあるかと思います）。

• WordPress
• レンタルサーバー
• FTP・SFTP
• ドメイン管理サービス
• Google Analytics
• Google Search Console
• Googleアカウント
• CDNサービス

制作会社用のアカウントが残っている場合は、不要になったタイミングで削除することも検討しましょう。ただし、契約上の争いが続いている途中で一方的にアクセスを遮断すると、新たな問題になる可能性もあります。

特に金額の大きなトラブルである場合や争いが長期化しそうになっている場合は、専門家に相談しながら進めた方が安心です。

連絡はできるだけ記録に残す

業者とトラブルになったとき、電話だけでやり取りするのはおすすめできません。

できるだけ、「メール」「チャット」「書面」など、履歴が残る方法を使用しましょう。

例えば、「○月○日にお願いした○○について、現在まで回答をいただいておりません。○月○日までに状況をご回答ください。」というように、何を・いつ依頼し・いつまでに回答を求めているのかを明確にします。

重要な契約トラブルになっている場合には、内容証明郵便などを検討する場合もあります。

別のWordPress制作者にサイトを見てもらう

技術的な状況が分からない場合は、別のWordPress制作者へ相談する方法もあります。

その際は、「現在の制作会社と連絡が取れなくなっても、このサイトを維持できる状態か確認してください。」とお願いすると分かりやすいでしょう。

以下のような状態であれば、比較的スムーズに別の業者へ引き継げる可能性があります。

• サーバーへアクセスできる
• WordPress管理者権限がある
• ドメインを管理できる
• バックアップを取得できる

一方、以下のような場合には、ライセンスも含めた複雑な移行作業が必要になり、工数がかさむことがあります。

• 独自テーマへ大きく依存している
• 独自プラグインを使用している
• 制作会社独自のシステムと連携している
• 有料プラグインが制作会社のライセンスになっている

お金や契約の問題になったら専門機関へ相談する

料金を支払ったのにサイトが完成しない、契約内容と明らかに違う、ドメインやデータの引き渡しを拒否されている、といったケースになると、WordPressの技術問題だけでは解決できません。

契約や金銭をめぐる問題になった場合は、「弁護士」「自治体などの法律相談」「取引トラブルに関する相談窓口」などへ相談することも検討しましょう。

特に高額な制作費が絡んでいる場合は、自己判断だけで無理に解決しようとしない方が安全です。

WordPress制作を依頼するときの5つの自衛策

さまざまな注意点を紹介しましたが、最低限押さえておきたいのは次の5つです。

1. ドメインを自分名義で契約する
2. レンタルサーバーを自分名義で契約する
3. WordPress管理者アカウントを持つ
4. 契約終了時の引き継ぎ方法を確認する
5. 自分でもバックアップを確保する

この5つを守るだけでも、「制作会社と連絡が取れなくなり、サイトまで動かせなくなった」という最悪の事態を防ぎやすくなります。

「安い業者＝悪い業者」とは限らない

最後に注意したいのが、料金だけで良し悪しを判断しないことです。

個人で活動しているフリーランスでも、非常に丁寧な仕事をする制作者はいます。反対に、有名な制作会社だから絶対に問題が起きないとも限りません。

特に大切なのは、以下のような点です。

• 契約内容をきちんと説明してくれるか
• 質問へ丁寧に答えてくれるか
• 管理権限を明確にしているか
• 過度な囲い込みをしていないか
• 契約終了後まで考えられているか

料金や会社規模よりも、「サイトを誰のものとして扱っているか」を見ると、業者選びの判断材料になりやすいでしょう。

まとめ：良い制作会社は「いつでも引き継げるサイト」を作ってくれる

WordPressサイト制作では、デザインや料金だけに注目しがちです。

しかし、長くサイトを運営するのであれば、管理権限・契約・バックアップ・引き継ぎについても確認しておく必要があります。

特に重要なのは、「この業者がいなくなっても、自分のサイトを維持できるか」という視点です。どれだけ信頼している制作会社でも、将来何が起こるかは分かりません。

ドメインやサーバーを自分で管理し、WordPress管理者権限とバックアップを確保しておけば、万が一のときにも別の制作者へ相談しやすくなります。

良いWordPress制作会社とは、顧客を囲い込む会社ではありません。

必要になったとき、別の制作会社へ問題なく引き継げるWebサイトを作ってくれる会社。この点を一つの判断基準として、安心して長く付き合える制作パートナーを探してみてください。

記事の概要

質問の詳細

WordPressを使い始めたばかりなのですが、管理画面に「WordPressアップデート」のお知らせが出てきました。調べてみると「メジャーアップデート」と「マイナーアップデート」があるようですが、違いがよく分かりません。

新しいバージョンが出たら、すぐにアップデートしてしまって大丈夫なのでしょうか？

回答の詳細

WordPressには「メジャー」と「マイナー」のアップデートがある

WordPressのバージョンは、たとえば次のように表記されます。

• WordPress 7.0
• WordPress 7.0.1
• WordPress 7.0.2
• WordPress 7.1

このうち、大きく分けると次のように考えられます。

WordPressでは、メジャーアップデートでも既存サイトとの互換性をできるだけ維持するように開発されています。そのため、「メジャーアップデートをすると必ずサイトが壊れる」というわけではありません。

一方で、新機能や内部仕様の変更が比較的多く含まれるため、マイナーアップデートより慎重に確認した方がよい場面があります。

マイナーアップデートで気をつけたいこと

まずは「7.0 → 7.0.1」のようなマイナーアップデートから見ていきましょう。

基本的には早めのアップデートがおすすめ

マイナーアップデートには、不具合の修正だけでなく、セキュリティ上の問題を修正する内容が含まれることがあります。

そのため、「不具合が怖いから、しばらくアップデートしないでおこう」と長期間放置するのは、必ずしも安全とはいえません。特にセキュリティリリースとして公開されている場合は、更新しないことで既知の脆弱性が残ってしまう可能性があります。

基本的には、内容を確認したうえで早めにアップデートすることをおすすめします。

マイナーアップデートは自動更新されることもある

WordPressでは、マイナーアップデートやセキュリティアップデートが自動的に適用されることがあります。特に、functions.phpや外部プラグイン等で制限を入れていなければ、マイナーアップデートの自動更新を止めることはできません。そのため、「自分で更新ボタンを押していないから大丈夫」とは限りません。

また、利用しているレンタルサーバーによっては、WordPress本体を自動的にアップデートする独自機能が用意されていることもあります。

「WordPress本体の自動更新設定」「レンタルサーバー側の自動更新設定」「WordPress管理サービスなどの設定」を確認しておくとよいでしょう。

マイナーアップデートでも動作確認はしておこう

マイナーアップデートは比較的小規模な変更が中心ですが、だからといって絶対に問題が起こらないとは限りません。テーマやプラグイン、独自カスタマイズとの組み合わせによって、不具合が表面化することがあります。

更新後には最低限、「トップページ」「投稿・固定ページ」「管理画面」「ブロックエディター」「お問い合わせフォーム」「ログイン画面」などを確認しておくと安心です。

ECサイトの場合は購入処理、会員サイトの場合はログインや会員登録など、そのサイトにとって特に重要な機能も確認しておきましょう。

メジャーアップデートで気をつけたいこと

続いて、「7.0 → 7.1」のようなメジャーアップデートです。

メジャーアップデートでは、新しい機能や仕様変更などが比較的多く含まれます。そのため、マイナーアップデートより少し慎重に進めるのがおすすめです。

まずバックアップを取る

最も重要なのがバックアップです。万が一アップデート後に問題が発生しても、バックアップがあれば以前の状態へ戻せる可能性があります。

ここで注意したいのは、データベースだけをバックアップすれば十分とは限らないことです。

WordPressサイトには、

• 投稿や固定ページなどが保存されたデータベース
• テーマ
• プラグイン
• アップロードした画像
• 各種設定ファイル

など、数多くのファイルによって構成されており、アップデートの前後にデータベース以外のファイルにも不都合が出る場合があります。

できれば、データベースとWordPressのファイルの両方をバックアップしておきましょう。

さらに理想的なのは「バックアップを取ったことがある」というだけではなく、「必要になったら実際に復元できる」状態にしておくことです。

レンタルサーバーの自動バックアップを利用している場合も、復元方法まで一度確認しておくと安心です。

テーマとプラグインの対応状況を確認する

WordPress本体だけが動いても、サイト全体が正常に動くとは限りません。

WordPressでは、「WordPress本体」「テーマ」「プラグイン」が組み合わさってサイトが動いています。特にメジャーアップデートの前には、利用しているテーマや主要プラグインが新しいWordPressに対応しているか確認しておくとよいでしょう。

特に注意したいのは、以下のようなWordPressサイトです。

• 長期間アップデートされていないプラグイン
• 開発が終了しているテーマ
• 独自開発したテーマやプラグイン
• functions.phpに多くの独自コードを書いているサイト
• WooCommerceを利用したECサイト
• 会員サイト
• 予約サイト

一般的なブログよりも、多くの機能を組み合わせたサイトほど影響を受ける可能性があります。

WordPress本体だけでなく、テーマ・プラグインも確実にアップデートを行う

意外に見落としやすいポイントです。

WordPressの新しいバージョンが公開される前後には、テーマやプラグイン側でも互換性を確保するためのアップデートが行われることがあります。そのため、「WordPress本体だけ最新」「テーマやプラグインは数年前のまま」といった状態は避けた方がよいでしょう。

WordPress本体だけでなく、サイト全体を定期的にメンテナンスすることが大切です。

メジャーアップデートは公開直後に入れなくてもよい？

これはサイトの性質によります。

個人ブログなど比較的シンプルなサイトであれば、バックアップを取ったうえで比較的早めにアップデートしても問題ないケースが多いでしょう。一方、企業サイトやECサイト、会員サイトなどの場合は、公開直後に本番環境へ適用せず、少し状況を確認してから更新する方法もあります。

新しいメジャーバージョンが公開された直後には、「WordPress本体の不具合」「テーマとの互換性問題」「プラグインとの互換性問題」などが見つかる場合があります。その後、修正版となるマイナーアップデートが比較的早い段階で公開されることもあります。

そのため、「メジャーアップデートは絶対に公開当日に入れなければならない」というものではありません。

ただし、セキュリティに関する重要な修正が含まれている場合などは事情が変わります。単純にバージョン番号だけを見るのではなく、アップデート内容を確認して判断することが重要です。

重要なサイトなら「ステージング環境」で確認しよう

企業サイトやECサイトなど、停止すると大きな影響が出るサイトでは「ステージング環境」を利用する方法もあります。ステージング環境とは、簡単にいえば本番サイトとは別に用意したテスト用のコピーサイトです。

例えば、以下のような手順で確認できます。

1. WordPress 7.0の本番サイト
2. ステージング環境を作成
3. ステージング環境だけWordPress 7.1へアップデート
4. テーマ・プラグイン・各機能を確認
5. 問題なければ本番サイトもアップデート

上記の進め方であれば、不具合が発生しても本番サイトには直接影響しません。重要度の高いサイトほど有効な手法となり得ます。

レンタルサーバーによっては、ステージング環境を簡単に作成できる機能が用意されていることもあります。

【サーバー選び】エックスサーバー系4サービスを比較。WordPress運用の仕組み・料金・強みの違いについて

WP Pilot

アップデート前に確認しておきたいポイント

WordPressをアップデートするときは、少なくとも次のポイントを意識しておくとよいでしょう。

• WordPressの更新内容を確認する
• バックアップを取る
• テーマを最新版にしておく
• プラグインを最新版にしておく
• テーマ・プラグインの対応状況を確認する
• 独自カスタマイズがある場合は注意する
• アップデート後に主要ページを確認する
• フォームやログインなど重要機能を確認する

サイトの規模が大きい場合は、さらにステージング環境で事前確認を行うと安心です。

「マイナーだから安全」「メジャーだから危険」とは限らない

WordPressのアップデートを考えるうえで、特に覚えておきたいのがこの点です。

例えば、「7.1 → 7.1.1だから、たいした更新ではないだろう」とは限りません。マイナーアップデートであっても、重要なセキュリティ修正が含まれることがあります。

反対に、「7.0 → 7.1だから、大きな問題が起こるかもしれない」などと過度に怖がる必要もありません。WordPressは既存サイトとの互換性を重視しながら開発されています。

大切なのは数字だけではなく、「今回のアップデートでは何が変更されたのか」を確認することです。

アップデートしないこと自体が安全とは限らない

WordPressでありがちな誤解として、「動いているサイトには触らない方が安全」という考え方があります。

確かに、更新した直後に不具合が発生する可能性はゼロではありません。しかし、WordPress本体やテーマ、プラグインを長期間アップデートしなければ、今度はセキュリティ上の問題が残ったままになる可能性があります。

古いプラグインが新しいPHPに対応しなくなったり、一気に何年分もの更新をしなければならなくなったりすることもあります。

そのため、「更新しないことでリスクを避ける」のではなく、「安全に更新できる環境を整える」という考え方が重要です。

マイナーアップデートとメジャーアップデートの違いをまとめると

最後に簡単に整理してみましょう。

マイナーアップデート

7.0から7.0.1のように3番目の数値が上がる更新です。不具合修正やセキュリティ修正が中心となるため、基本的には早めの適用を考えます。

ただし、自動更新される場合もあるため、更新後にはサイトの主要部分が正常に動作しているか確認しておきましょう。

「WordPress 7.0.4」セキュリティアップデート――Imagick・Ghostscriptを悪用したRCE脆弱性を修正

WP Pilot

【メモ】WordPress 7.0.2／6.9.5／6.8.6で修正された脆弱性について

WP Pilot

メジャーアップデート

7.0から7.1のように2番目の数値が上がる更新です。

新機能や仕様変更が比較的多いため、「バックアップ」「テーマやプラグインの対応確認」「更新後の動作確認」をより意識して行うことが重要です。

重要なサイトでは、ステージング環境を使って事前確認するとさらに安心です。

WordPress 7.0とは？ 主な変更点を解説します

WP Pilot

WordPress 6.9の主な変更点について

WP Pilot

まとめ

WordPressは定期的にアップデートされ、新機能の追加だけでなく、不具合やセキュリティ上の問題も修正されています。そのため、基本的には最新版へ更新しながら使っていくことが望ましいでしょう。

ただし、マイナーアップデートは比較的早めに対応し、メジャーアップデートはバックアップや互換性を確認しながら慎重に進めるという違いを意識しておくと、より安全に運用できます。

また、重要なのはアップデートそのものを怖がり、更新を止めることではありません。

普段から、「バックアップを取る」「WordPress本体を放置しない」「テーマやプラグインも更新する」「更新後に動作を確認する」といった習慣を身につけておくことが大切です。

WordPressは「アップデートしない方が安全なCMS」ではなく、「安全にアップデートできるように管理しながら使うCMS」と考えると分かりやすいでしょう。

2026年8月12日（米国現地時間）、WordPress 7.0.4が公開されました。

今回の7.0.4は、新機能の追加や一般的な不具合修正を目的としたアップデートではなく、セキュリティ上の問題を修正するためのリリースです。WordPress公式も、セキュリティリリースであることを理由に、サイトを速やかに更新するよう推奨しています。

修正されたのは、特定の環境において、投稿者以上の権限を持つユーザーが悪意のあるファイルをアップロードすることで、リモートコード実行（RCE）につながる可能性がある脆弱性です。

WordPress 7.0.2、7.0.3とセキュリティ関連の更新が続いていることもあり、「7.0系にまた問題が見つかったのか」と感じる方もいるかもしれません。

しかし今回の問題は、WordPress 7.0で新しく発生したものではありません。7.0.3と同様にWordPress 4.7までさかのぼって修正版が提供されており、かなり以前から存在していた問題が新たに発見されたものと考えるのが適切です。

この記事では、WordPress 7.0.4で修正された脆弱性について、できるだけ分かりやすく解説します。

公式情報

英語

• Version 7.0.4 – Documentation – WordPress.org
• WordPress 7.0.4 Release – WordPress News
• Remote code execution vulnerability via malicious file upload by an Author level user or higher · Advisory · WordPress/wordpress-develop · GitHub

従前：WordPress 7.0.2・7.0.3 での修正ポイント

「WordPress 7.0.3」セキュリティアップデート：7.0.2との違いと12件のセキュリティ修正を解説

WP Pilot

【メモ】WordPress 7.0.2／6.9.5／6.8.6で修正された脆弱性について

WP Pilot

WordPress 7.0.4はセキュリティリリース

WordPress 7.0.4は、2026年8月12日に公開されました。

WordPress公式ドキュメントでは、今回のリリースについてセキュリティ修正を含むことが案内されており、サイトを直ちに更新することが推奨されています。

今回公表されている主な問題は、ImagickとGhostscriptを利用しているサイトにおいて、認証済みの投稿者以上のユーザーが悪意のあるファイルをアップロードすることで、リモートコード実行が可能になる問題です。

脆弱性には「CVE-2026-65640」という識別番号が割り当てられています。GitHub Security Advisoryでは深刻度が「High」と評価され、CVSSスコアは8.8 / 10です。

CVSSとは、脆弱性の危険度を数値化するために広く使われている指標です。10に近いほど重大な問題と考えられます。

WordPress 7.0.4での修正ポイント

今回問題になった「RCE」とは？

今回の脆弱性で特に注目しておきたいのが、RCE（Remote Code Execution：リモートコード実行）です。RCEとは、外部からサーバー上で本来想定されていない命令やコードを実行できてしまう問題を指します。

脆弱性を悪用される条件やサーバーの設定によって被害は異なりますが、RCEが成立すると、以下のような被害につながる可能性があります。

• サーバー内のファイルを読み取られる
• ファイルを書き換えられる
• 不正なプログラムを設置される
• 不正経路（バックドア）を設置される
• サイトを改ざんされる
• 情報を盗まれる
• サイトやサーバーを停止させられる

GitHub Security Advisoryでも、今回の脆弱性について「機密性」「完全性」「可用性」のすべてへの影響がHighと評価されています。

つまり、攻撃が成立するためにはいくつか条件が必要なものの、成立した場合の影響は大きい脆弱性と考えてよいでしょう。

ImagickとGhostscriptが関係する脆弱性

今回の脆弱性を理解するうえで重要なのが、「Imagick」「Ghostscript」という2つの仕組みです。

Imagickは、PHPからImageMagickという画像処理ソフトウェアを利用するための拡張モジュールです。WordPressでは画像をアップロードした際に、「サムネイルを生成する」「画像サイズを変更する」「画像を編集する」といった処理で利用される場合があります。

一方、Ghostscriptは、PostScriptやPDFなどのファイルを処理するために広く使われているソフトウェアです。

GitHub Security Advisoryによると、今回問題となっている環境では、ImagickとGhostscriptの両方がサーバーで使用されていることが攻撃成立の前提条件となっています。

さらに、問題そのものについては、Ghostscriptが特定の埋め込みファイルを処理する方法に弱点があると説明されています。

大まかな流れを整理すると、次のようになります。

1. WordPressへ悪意のあるファイルをアップロード
2. WordPressがImagickを使って画像処理
3. ImagickからGhostscriptが呼び出される
4. 細工されたファイルがGhostscriptによって処理される
5. サーバー上で意図しないコードが実行される可能性

WordPress単体の単純なPHPの不具合というよりも、WordPressのファイルアップロード処理と、サーバー側の画像処理ソフトウェアが組み合わさることで成立する問題と見ると分かりやすいでしょう。

悪意のあるPostScriptファイルが利用される

今回のセキュリティ情報では、悪意のあるPostScriptファイルのアップロードが攻撃手段として説明されています。

PostScriptは、ページや印刷データの内容を記述するために使われる言語・ファイル形式です。

一般的なWordPressサイトでは、「JPEG」「PNG」「WebP」「GIF」「AVIF」などと比較すると、PostScript形式のファイルを日常的に扱うことは少ないでしょう。

しかし、「普段PostScriptを使わないサイトなら問題ない」という意味ではありません。攻撃者が意図的に細工したファイルをWordPressへアップロードし、サーバー側に処理させることが問題となります。

そのため、WordPress側でも危険なファイルが処理されないよう対策する必要があります。

誰でも攻撃できるわけではない

今回の脆弱性には、もう一つ重要な条件があります。

攻撃者には、WordPressへファイルをアップロードできる権限が必要です。GitHub Security Advisoryでは、upload_files 権限を持つ悪意のあるユーザーが前提とされています。

WordPress標準の権限では、おおむね次のようになります。

• 購読者： 不可
• 寄稿者： 不可
• 投稿者： 可能
• 編集者： 可能
• 管理者： 可能

つまり今回の脆弱性は、WordPressにアクセスしてきた未ログインの第三者が、いきなり攻撃できるタイプではありません。原則として、投稿者以上の権限を持つ認証済みユーザーが必要です。

この点は、今回の危険度を考えるうえで重要です。

運用状況によって悪用のハードルは異なる

例えば、以下のような一般的な個人ブログの場合、今回の脆弱性を直接悪用するためのハードルは高くなります。

• WordPressユーザーが自分一人しかいない
• 管理者アカウントしか作成していない
• 第三者へ投稿者権限を与えていない

攻撃者がPostScriptファイルをアップロードするためには、まずアップロード権限を持つアカウントを利用できなければならないためです。

一方で、特に注意しておきたいのが複数ユーザーで運用しているWordPressサイトです。

• 複数人で記事を投稿しているサイト
• 外部ライターへ投稿者権限を付与しているサイト
• 会員がコンテンツを投稿できるサイト
• 社内CMSとして使っているWordPress
• ユーザー投稿型サービス
• 不特定多数へ比較的高い権限を付与しているサイト

などでは、個人ブログよりもリスクが高くなります。

また、別の方法で投稿者アカウントが乗っ取られた場合に、今回の脆弱性を組み合わせて攻撃される可能性も考えられます。

何はともあれ、「ログインが必要だから安全」と判断するのではなく、更新できるのであれば修正版へ更新しておくことが基本です。

CVSS 8.8と評価されている理由

今回の脆弱性は、CVSS 3系で8.8と評価されています。

内訳は次のようになっています。

• Attack Vector（攻撃経路）： Network
• Attack Complexity（攻撃難易度）： Low
• Privileges Required（必要権限）： Low
• User Interaction（ユーザー操作）： None
• Confidentiality（機密性への影響）： High
• Integrity（完全性への影響）： High
• Availability（可用性への影響）： High

つまり、低い権限ながら何らかの権限は必要である一方、攻撃成立後の影響は非常に大きいという評価です。

未認証で簡単に攻撃できる脆弱性ほど危険ではありませんが、条件がそろった環境では深刻な被害につながる可能性があります。

WordPress 7.0.4で変更されたファイルは1つだけ

今回の更新で興味深いのが、WordPressコアで変更されたファイルの少なさです。

WordPress 7.0.4で変更されたファイルとして公式ドキュメントに記載されているのは、/wp-includes/class-wp-image-editor-imagick.phpの1ファイルだけです。これは、WordPressでImagickを利用した画像処理を担当しているファイルです。

また、WordPress公式によれば、今回変更されたパッケージはありません。

つまり7.0.4は、WordPressの機能を広く変更するアップデートではなく、Imagick周辺のセキュリティ問題を修正するための非常に限定的な更新と考えられます。

更新による影響範囲という意味では、比較的小さなリリースといえるでしょう。

WordPress 7.0だけの問題ではない

過去バージョンについても修正版が提供されている

今回特に注意したいのが、WordPress 7.0で新しく発生した脆弱性ではないことです。

WordPress公式では、WordPress 6.9、6.8、6.7……と過去のバージョンについても修正版を公開しています。前回同様、WordPress 4.7まで修正がバックポートされています（WordPress 4.6以前については、セキュリティアップデートの対象外です）。

ここからも、今回の脆弱性がWordPress 7.0特有の新しい機能によって発生した問題ではなく、長期間存在していた処理に関係する問題だったことが分かります。

なお、WordPress公式は古いブランチにも修正版を提供していますが、現在積極的にサポートされているのは最新バージョンであることも案内しています（この辺りもいつも通りですね）。

可能であれば、古いWordPressを修正版へ更新するだけでなく、最新系列への移行も検討した方がよいでしょう。

7.0.2・7.0.3の問題とは別物

WordPress 7.0系では、短期間にセキュリティアップデートが続いています。そのため、「7.0.2や7.0.3で修正した問題を、7.0.4でもう一度修正したのでは？」と思われるかもしれません。

しかし、修正された箇所はそれぞれ全く異なります。

例えば、WordPress 7.0.2では、WP_Queryのauthor__not_inパラメータに関係するSQLインジェクションと、REST APIのバッチルートに関係する問題などが修正されました。これらが組み合わさることで、特定のバージョンではRCEにつながる可能性も指摘されていました。

一方、今回の7.0.4は、「悪意のあるファイルアップロード」「Imagick・Ghostscript・PostScript」「投稿者以上の権限」「リモートコード実行」という、まったく異なる経路の脆弱性です。

また、今回の問題も7.0.3と同様にWordPress 4.7まで影響するため、WordPress 7.0で追加された新機能が直接の原因とは考えにくいでしょう。

そのため、「7.0.2や7.0.3の修正が不十分だったので7.0.4が必要になった」と理解するのは適切ではありません。むしろ、それぞれ別々に発見されたセキュリティ問題に対して、修正版が順次提供されていると考えた方が実態に近いでしょう。

「WordPress 7.0は不具合だらけ」という意味ではない

7.0.2、7.0.3、7.0.4と短期間にバージョン番号が増えると、「WordPress 7.0は品質に問題があるのではないか」と感じる方もいるかもしれません。

しかし、セキュリティリリースの回数だけを見て判断するのは少し注意が必要です。

今回の脆弱性やWordPress 7.0.3で修正された箇所のように、過去のバージョンにも長期間存在していた問題が、新しいバージョンの公開後に発見されるケースもあります。その場合、現在の最新版だけでなく、影響する旧バージョンにも修正が提供されます。今回もWordPress 4.7まで修正版が用意されています。

したがって、「WordPress 7.0にしたことで脆弱性が増えた」というより、以前から存在していた問題が発見され、現在利用されているWordPressへ修正が適用されたという面が大きいと考えられます。

セキュリティアップデートが公開されること自体は、脆弱性への対応が行われているという意味でもあります。

WordPress 7.0.4には更新した方がよい？

基本的には、7.0.4への更新をおすすめします。WordPress公式も、今回がセキュリティリリースであることから速やかな更新を推奨しています。

特に、以下のような環境では、優先度を高めに考えた方がよいでしょう。

• 複数ユーザーでWordPressを運営している
• 投稿者権限を第三者へ付与している
• 会員投稿機能を設けている
• Imagickを利用している
• サーバーでGhostscriptが利用されている

一方、自分一人だけが管理者として利用している個人ブログでは、攻撃成立の条件を満たしにくいため、今回の脆弱性だけを見ればリスクは比較的低いと考えられます。

それでも、7.0.4で変更されているWordPressコアファイルはImagick関連の1ファイルだけであり、7.0.3へとどまり続ける積極的な理由はほとんどありません。普段どおりバックアップを確認したうえで、7.0.4へ更新しておくのがよいでしょう。

更新後はサイトの基本動作も確認しておこう

今回の変更範囲は限定されていますが、WordPress本体を更新した後は簡単な動作確認をおすすめします。

特に、以下の部分を確認すると安心です。

• 管理画面へログインできるか
• 投稿・固定ページを編集できるか
• 画像をアップロードできるか
• サムネイルが正常に生成されるか
• JPEG・PNG・WebPなどが正常に処理されるか
• フロントページが正常に表示されるか
• エラーログに異常が出ていないか

今回はclass-wp-image-editor-imagick.phpが変更されているため、特に画像アップロードや画像生成周辺を軽く確認しておくとよいでしょう。

まとめ：7.0.4は対象条件が限定されるものの、重要なセキュリティ更新

WordPress 7.0.4では、ImagickとGhostscriptを利用する特定の環境において、投稿者以上のユーザーが悪意のあるファイルをアップロードすることで、リモートコード実行につながる可能性がある脆弱性が修正されました。

今回のポイントをまとめると、以下のような内容になります。

• WordPress 7.0.4は2026年8月12日に公開されたセキュリティリリース
• 悪意のあるPostScriptファイルが攻撃に利用される可能性がある
• ImagickとGhostscriptを利用している環境が前提
• 攻撃にはupload_files権限が必要
• 標準環境では投稿者以上のユーザーが主な対象
• 成立するとRCEにつながる可能性がある
• WordPress 4.7以降の広いバージョンが影響を受ける
• 7.0.4で変更されたWordPressコアファイルはImagick関連の1ファイル
• 7.0.2や7.0.3のセキュリティ問題とは基本的に別件

特に覚えておきたいのは、「WordPress 7.0で新たに生まれた問題ではない」という点です。

WordPress 4.7まで修正版が提供されていることからも分かるように、以前から存在していた処理に関係する脆弱性が新たに発見されたものです。

7.0.2、7.0.3、7.0.4とセキュリティリリースが続いていますが、それぞれを一括して「7.0の品質問題」と見るのではなく、どの機能にどのような脆弱性が発見されたのかを個別に確認することが大切です。

今回については攻撃成立の条件こそ限定されていますが、RCEという性質上、成立した場合の影響は小さくありません。

WordPress 7.0.3以前を利用している場合は、バックアップと基本的な動作確認を行いつつ、WordPress 7.0.4へ更新しておくことをおすすめします。

2026年8月6日（米国現地時間）、WordPress 7.0.3が公開されました。こちらも追加機能の搭載が伴わない「セキュリティアップデート」の位置づけとなっています。

WordPress 7.0.2が公開されたのは2026年7月17日だったため、わずか3週間ほどで再びセキュリティアップデートが行われたことになります。

「7.0.2は重大な脆弱性を修正したばかりなのだから、7.0.3は急いで更新しなくてもよいのでは？」と思う方もいるかもしれません。

しかし、WordPress 7.0.2と7.0.3では修正対象となっている脆弱性がまったく異なります。7.0.2へ更新していても、7.0.3で新たに修正された12件の問題は残ったままです。そのため、WordPress公式も7.0.3について「直ちにサイトを更新すること」を推奨しています。

今回はWordPress 7.0.2との違いを確認しながら、7.0.3で修正されたセキュリティ上の問題をできるだけ分かりやすく解説します。

【追記】追加のセキュリティアップデートが実施されました

2026年8月12日には、WordPress 7.0.4 / 6.9.7 / 6.8.8 などの追加のセキュリティアップデートが実施されました。そのため、早急に現行バージョンにアップデートいただくことをおすすめいたします。

「WordPress 7.0.4」セキュリティアップデート――Imagick・Ghostscriptを悪用したRCE脆弱性を修正

WP Pilot

まずはこちらを：参考リンク

• WordPress 7.0.3リリース – WordPress.org 日本語
• WordPress 7.0.2リリース – WordPress.org 日本語

英語の資料はこちらから

• Version 7.0.3 – Documentation – WordPress.org
• WordPress 7.0.3 Released: 12 Vulnerabilities Found and Fixed – Patchstack
• Ninety minutes: watching attackers weaponize the WordPress core RCE – Patchstack

WordPress 7.0.3は12件のセキュリティ問題を修正したアップデート

WordPress 7.0.3は、新しいブロックや管理画面機能を追加するためのアップデートではありません。セキュリティ問題を修正することを目的としたリリースです。

WordPress公式が公表している修正内容は全部で12件あります。「XSS（クロスサイトスクリプティング）」「権限昇格」「情報漏えい」「CSSインジェクション」「メールアドレス確認処理の回避」「SSRF（サーバーサイドリクエストフォージェリ）」など、多岐にわたります。

特に目立つのがXSSで、ログイン画面から投稿、ブロック、クイック編集まで複数の場所で問題が修正されています。

WordPress 7.0.2とは何が違う？

まず、直前のWordPress 7.0.2との違いを整理しておきましょう。

WordPress 7.0.2は「2件の非常に重大な脆弱性」への対応

7.0.2で修正されたのは主に次の2件でした。1つはSQLインジェクションを容易にする問題。もう1つはREST APIのバッチ処理におけるルートの混同とSQLインジェクションを組み合わせ、最終的にRCE（リモートコード実行）へつながる可能性がある問題です。

RCEとは、離れた場所にいる攻撃者がサーバー上で任意のコードを動かせる状態を指します。

WordPress公式は7.0.2について、1件を「Critical（深刻）」、もう1件を「High（重要）」として扱い、影響を受けるサイトには自動更新システムによる強制更新まで実施しました。Patchstackも、この2件を組み合わせることでサイト全体の乗っ取りにつながることを確認し、実際の悪用も確認されていると報告しています。

つまり7.0.2は「非常に危険な特定の攻撃経路を緊急で塞ぐアップデート」だったと考えると分かりやすいでしょう。

【メモ】WordPress 7.0.2／6.9.5／6.8.6で修正された脆弱性について

WP Pilot

WordPress 7.0.3は「広い範囲のセキュリティ問題」を修正

一方の7.0.3では12件もの問題が修正されています。

対象となる場所も、ログイン画面、投稿、ブロック、コメント、マルチサイト、メールアドレス確認、URL検証など非常に広範囲です。修正の入った箇所もWordPress 7.0.2とは異なります。

そのため、「7.0.2に更新したから安全」ということにはなりません。7.0.2は7.0.1以前で見つかった問題を修正したバージョンであり、7.0.3はさらに別の問題を修正したバージョンです。

WordPress 7.0.3 の修正箇所12点

ここからは、WordPress 7.0.3 で修正された箇所について、それぞれ詳しく見ていきます。

1．ログイン画面の認証前・反射型XSS

今回もっとも注意したい問題のひとつです。

WordPressのログイン画面に、ログインしていない攻撃者でも利用できる反射型XSSが存在していました。XSSとは、Webページ上で本来意図していないJavaScriptなどを実行させる攻撃です。

今回の問題では、攻撃者が細工したURLを用意し、それをWordPress管理者にクリックさせることで、管理者のブラウザ上で不正なスクリプトを実行できる可能性があります。

WordPress公式は、この問題について「PHPコード実行につながる可能性がある」と説明しています。CVE-2026-64638としても登録されています。

ただし、「サイトへアクセスされただけで直ちに乗っ取られる」というタイプではありません。攻撃を成立させるには、攻撃対象となるサイトの管理者に対して細工されたURLを送り、その管理者自身にクリックさせる必要がある、とPatchstackは説明しています。

管理者が攻撃を受けた場合には、そのセッションを悪用してプラグインやコードを追加するなど、最終的にRCEへ発展する可能性があります。つまり、フィッシング攻撃などと組み合わせて管理者を狙う可能性がある脆弱性です。

2．絵文字設定を利用した保存型XSS

投稿内の絵文字設定に関する要素を利用して、保存型XSSを引き起こせる問題も修正されています。こちらはContributor（寄稿者）以上の権限が必要です。

保存型XSSとは、不正なコードが一時的にURLなどへ含まれるだけではなく、WordPress側に保存されてしまうXSSです。その投稿を管理者や他のユーザーが表示した際に、不正なスクリプトが実行される可能性があります。

自分ひとりだけで運営しているブログでは悪用条件が限定されます。一方で、複数ライターを抱えるメディア、外部ライターへ寄稿者権限を与えているサイト、会員が投稿できるサイトなどでは重要度が高くなります。

3．コンテンツ（Post Content）ブロックの保存型XSS

「コンテンツ（Post Content）」ブロックにも、Contributor以上のユーザーが利用できる保存型XSSが存在していました。

「コンテンツ」ブロックは、特にブロックテーマで重要なブロックです。テンプレート内に配置し、「現在表示している投稿や固定ページの本文をここへ表示する」ために使用します。

ブロックが最終的にHTMLを生成するときの処理に不備があると、不正な内容が安全に処理されない可能性があります。一見すると普通の投稿本文に見えるようであっても、不正な内容がそのまま出力されてしまう可能性があります。

現在のWordPressでは多くの画面がブロックによって生成されているため、こうしたブロックの出力時に適切な無害化を行うことは非常に重要です。

4．クイック編集の保存型XSS

投稿一覧画面にある「クイック編集」に関係する保存型XSSも修正されました。こちらもContributor以上の権限が必要ですが、WordPress公式は特にユーザー数が多いサイトで発生する問題として説明しています。

クイック編集は、「タイトル」「スラッグ」「カテゴリー」「タグ」「公開状態」などを投稿一覧から変更できる機能です。多数のユーザーを抱えているニュースサイトや投稿型サービス、大規模なメディアサイトでは、特に更新しておきたい修正です。

5．投稿日（Post Date）ブロックの保存型XSS

投稿日を表示する「投稿日（Post Date）」ブロックにも保存型XSSが存在していました。こちらもContributor以上のユーザーによって悪用できる問題です。

WordPressのブロックは単に文字を表示するだけでなく、HTMLの属性値なども生成します。こうした属性値に想定外のデータを挿入できると、HTML構造から抜け出して別のコードとして扱わせる「属性注入」のような攻撃につながることがあります。

「コンテンツ」と「投稿日」の両方でXSSが修正されている点を見ると、今回の7.0.3ではブロックによって生成されるHTMLの安全性も重点的に見直されたことが分かります。

6．マルチサイトでの権限昇格

マルチサイト機能にも問題が見つかっています。

対象となるのは、ユーザー登録を有効にしているマルチサイトです。一定の条件下で、本来サイトを作成できないユーザーが新しいサイトを作成できてしまう問題でした。このように、本来は使えないはずの高い権限を、普通のユーザーが不正に取得できてしまう欠陥のことを「権限昇格」と呼びます。

なお、通常のWordPressを1サイトだけ運営している場合には、この問題の影響を受けません。

一方、企業、大学、学校、Webサービスなどでマルチサイトを使い、複数ユーザーにアカウントを発行している環境では注意が必要です。Patchstackも、この問題はマルチサイトのみが対象であると説明しています。

7．「最新のコメント」ブロックからパスワード保護投稿のコメントが漏れる問題

「最新のコメント（Latest Comments）」ブロックにも情報漏えいの問題がありました。具体的には、パスワードで保護された投稿につけられたコメントが表示されてしまう可能性があります。

WordPressでは投稿をパスワードで保護できます。当然ながら、その投稿を閲覧できないユーザーに対して、その中身を推測できる情報まで見せてしまうのは望ましくありません。コメントそのものから記事内容を推測できることもあります。

サイト乗っ取りのような問題ではありませんが、「非公開にしたつもりの情報が漏れる」という意味で修正が必要な問題です。

8．投稿スラッグを列挙できる問題

今回の修正には投稿スラッグの列挙（Enumeration）も含まれています。

スラッグとは、例えばexample.com/sample-post/であれば、sample-postの部分です。

本来公開されていない投稿であっても、スラッグの存在を外部から確認できてしまうと、「どのような非公開ページが存在するのか」を攻撃者に推測される可能性があります。

それだけで管理画面へ侵入できるわけではありませんが、攻撃者に余分な情報を渡すことになるため、情報収集の足掛かりとして利用される可能性があります。

9．コメントフィードからNotesが漏れる問題

コメントのフィードから、本来公開することを想定していないNotes（注記情報）が漏れる問題も修正されています。

こちらも直接サイトを乗っ取るタイプではありません。しかし、「データベースに存在している情報」と「外部へ公開してよい情報」は同じではありません。

WordPressではRSSなどのフィードを通して情報を外部へ配信するため、通常のWebページでは表示されていなくても、フィード経由で情報が見えてしまうことがあります。

7.0.3ではその境界も修正されています。

10．Author以上によるCSSインジェクション

Author（投稿者）以上のユーザーが、WordPressの安全なCSS属性フィルターを回避できる問題も修正されました。

CSSインジェクションとは、ページ内へ攻撃者が任意のCSSを挿入できてしまう問題です。JavaScriptを直接実行するXSSとは異なりますが、「表示を隠す」「別の要素を重ねる」「利用者を誤った操作へ誘導する」といった画面改ざんに利用される可能性があります。

特に複数人へ投稿権限を与えているサイトでは無視しにくい問題です。

11．メールアドレス確認処理を回避できる問題

WordPressのメールアドレス確認フローを回避できる問題も修正されています。

WordPressではメールアドレスの変更やユーザー関連処理などで、「本当にそのメールアドレスを所有しているのか」を確認する仕組みがあります。

今回、その確認フローを正常に完了していないにもかかわらず、処理を進められる可能性がある問題が修正されました。

単独で即座にサイト乗っ取りへ直結するとは限りませんが、認証・本人確認に関わる処理はセキュリティ上重要なため、修正しておくべき問題です。

12．URL検証を回避してlink-localアドレスへアクセスできるSSRF

最後はSSRFです。SSRFとは「Server-Side Request Forgery」の略で、簡単にいうと、攻撃者がWordPressサーバーを使って、本来アクセスできない場所へ通信させる攻撃です。

今回の問題では、WordPressのURL検証処理をすり抜けて、link-localと呼ばれるアドレス範囲へリクエストを送れる可能性がありました。

link-localとは、同じネットワークやサーバー内部など、限られた範囲で利用される特殊なIPアドレスです。一般ユーザーのブラウザから直接アクセスできない場所であっても、WordPressが動いているサーバーからならアクセスできる場合があります。

そのためSSRFを悪用すると、「WordPress → 内部ネットワーク → 内部サービス」という形で、WordPressを踏み台として内部システムへアクセスされる可能性があります。

Patchstackも今回のSSRFについて、攻撃対象をWordPressサイトだけでなく内部ネットワーク側へ広げる足掛かりになり得る問題として注意を促しています。

7.0.3では「WordPressの境界部分」が広く修正されている

12件を並べるとバラバラな問題に見えますが、共通点もあります。

今回重点的に修正されているのは、「どこまで信頼してよいのか」を判断する境界部分です。

たとえば、「未ログインユーザーと管理者」「寄稿者と管理者」「非公開情報と公開情報」「外部インターネットと内部ネットワーク」「安全なHTMLと危険なHTML」といった境界です。

7.0.2が「SQLインジェクションからRCEにつながる非常に危険な攻撃経路を緊急で閉じたリリース」だったとすれば、7.0.3は、「WordPressコアのさまざまな部分に残っていた信頼境界の問題を一斉に修正したリリース」と捉えると分かりやすいでしょう。

更新の重要性について

WordPress 7.0.2を使っていても7.0.3へ更新する必要がある

ここが今回もっとも重要なポイントです。WordPress 7.0.2と7.0.3は、同じ問題を二度修正したわけではありません。

7.0.2で修正されたのは、以下の2点です。

• SQLインジェクションを容易にする問題
• REST APIのバッチ処理とSQLインジェクションを組み合わせたRCEにつながる問題

7.0.3では、それとは別に今回紹介した12件の問題が修正されています。

したがって、WordPress 7.0.2を利用していても、7.0.3の脆弱性に対して安全になったわけではありません。WordPress公式も7.0.3について即時更新を推奨しています。

旧バージョンを使っている場合も更新が必要

今回の問題はWordPress 7.0だけのものでもありません。

公式HelpHubによると、影響する脆弱性の数は次のようになっています。

• WordPress 7.0： 12件
• WordPress 6.9： 11件
• WordPress 6.8 ～ 5.8： 8件
• WordPress 5.7 ～ 4.7： 7件

WordPress 6.9では6.9.6、6.8では6.8.7など、各ブランチ向けの修正版も公開されています。さらに4.7系についても4.7.34まで修正がバックポートされています。

つまり今回の脆弱性には、最近追加されたWordPress 7.0固有の機能だけでなく、かなり以前から存在するWordPressの仕組みに関係する問題も含まれていると考えられます。

ただし、古いWordPressを使い続けることが推奨されているわけではありません。WordPress公式は、積極的にサポートしているのは最新バージョンのみであることも明記しています。

特に更新を急いだ方がよいサイト

7.0.3は基本的にすべてのWordPressサイトで適用しておきたい更新ですが、特に、以下のようなWordPressサイトでは優先度が高くなります。

• 複数のライターへWordPressアカウントを発行している
• 寄稿者・投稿者権限を外部ユーザーへ与えている
• 会員制サイトを運営している
• マルチサイト機能を利用している
• パスワード保護投稿を利用している
• WordPressサーバーが社内・クラウドの内部ネットワークへアクセスできる

今回の保存型XSSはいずれもContributor以上の権限が攻撃条件となっています。Patchstackも、ゲストライターやフリーランス、制作会社などへContributor権限を渡しているサイトでは特に注意すべきとしています。

一方、ログイン画面の反射型XSSやSSRFなどは、単純に「投稿者アカウントを発行していないから関係ない」と言い切れる問題ではありません。

まとめ：7.0.2で安心せず7.0.3まで更新しておこう

WordPress 7.0.2は非常に重大なSQLインジェクションやRCEにつながる問題を修正した重要なアップデートでした。

しかし、7.0.3は7.0.2の補足修正ではありません。新たに12件のセキュリティ問題を修正した独立したセキュリティアップデートです。

ログイン画面の認証前XSSをはじめ、4件の保存型XSS、マルチサイトの権限昇格、情報漏えい、CSSインジェクション、メール確認の回避、SSRFなど、修正範囲はWordPress全体に及んでいます。

そのため、「7.0.2へ更新済みだから急ぐ必要はない」ではなく、「7.0.2で前回の脆弱性を塞ぎ、7.0.3で今回判明した別の12件も塞ぐ」と考えるのが適切です。特に今回の脆弱性はWordPress 6.xや5.x、さらには4.7系にまで影響するものが含まれています。

WordPress 7.0系を利用している場合は7.0.3へ、旧ブランチを事情があって継続利用している場合も、それぞれのブランチで提供されている最新のセキュリティ修正版へ早めに更新しておきましょう。

エックスサーバー株式会社は、一般的なレンタルサーバーである「エックスサーバー」だけでなく、WordPress専用サービスや、比較的新しい技術を積極的に採用するサービスも提供しています。

今回比較するのは、次の4つです。

• エックスサーバー
• XServer for WordPress
• シンレンタルサーバー
• wpX Speed

いずれもWordPressを運用できますが、サービスの考え方は同じではありません。

この記事では、2026年8月1日時点の公式情報をもとに、料金だけでなく、WordPressがどのような仕組みで動くのか、それぞれ何を重視しているのかまで解説します。

まずは4サービスの違いを一覧で比較

料金だけを見ると、エックスサーバーとシンレンタルサーバーが比較的安く、XServer for WordPressは高めです。

ただし、XServer for WordPressにはステージング環境やWordPressの基本操作サポート、復旧支援などが含まれています。単純にサーバー容量と料金だけが全てではなく、手厚いサポートも込みでの料金設定となっています。

「共用サーバー」「専用サービス」「クラウド」の違い

それぞれのサービスを比較する前に、WordPressを動かす仕組みの違いを確認しておきましょう。

共用レンタルサーバーとは

エックスサーバーとシンレンタルサーバーは、基本的には共用レンタルサーバーです。

共用レンタルサーバーとは、1台の大きなサーバーを複数の利用者で共有する仕組みです。ただし、利用者ごとに領域が分けられているため、通常はほかの利用者のファイルを見たり、直接操作したりすることはできません。

料金が比較的安く、サーバー会社がOSやサーバーソフトウェアを管理してくれるため、個人ブログや中小規模の企業サイトに向いています。

また、WordPressだけでなく、通常のHTMLサイト、PHPプログラム、メールサーバーなどにも利用できます。

WordPress専用ホスティングとは

XServer for WordPressは、WordPressの運用に必要な機能をまとめた専用サービスです。

単にWordPressをインストールできるだけでなく、次のような運用支援機能が用意されています。

• ステージング環境の作成
• 本番サイトとの同期
• WordPress本体・テーマ・プラグインの管理
• WordPressリカバリー
• 自動バックアップと復元
• WordPressの基本操作サポート
• 専門スタッフによる技術支援

ステージング環境とは、本番サイトとは別に作る検証用サイトです。テーマやプラグインを更新する前に、不具合が起きないか確認できます。

XServer for WordPressには共有サーバープランと仮想専用サーバープランがあり、大規模サイト向けの上位プランでは、ほかの利用者の影響を受けにくい独立した環境を利用できます。

クラウド型とは

wpX Speedは、WordPress専用のクラウド型レンタルサーバーです。

一般的なレンタルサーバーは、3か月、12か月、36か月といった期間を選び、料金を前払いします。一方、wpX Speedは1時間単位で料金が発生し、プランごとに月額料金の上限が設定されています。

さらに、サーバーに一定以上の負荷がかかったとき、設定した予算の範囲内で自動的に上位プランへ変更する「オートスケール」を利用できます。突然アクセスが集中する可能性があるサイトと相性のよい仕組みです。

エックスサーバーの特徴

国内シェアNo.1レンタルサーバー【エックスサーバー】

・運用サイト数250万件で国内シェアNo.1 ・初期費用無料、月額990円から、大容量500GBからの高コストパフォーマンス ・安定のサーバー稼働率99.99％以上 ・世界最高クラスの第5世代 AMD EPYC™とオールNVMe環境を採用 ・.com .netなどから選べる！独自ドメインが永久無料 ・マルチドメイン、メールアドレス無制限！独自SSLを無料で利用可能！

公式サイトをチェック

法人向けプランはこちら

ポチップ

安定性と使いやすさを重視した定番サービス

エックスサーバーは、個人ブログ、企業サイト、ECサイトなど、幅広い用途に使える総合型のレンタルサーバーです。

WordPress専用サービスではありませんが、WordPress簡単インストール、WordPress簡単移行、キャッシュ機能、無料SSL、自動バックアップ、WordPressリカバリーなど、WordPress向けの機能が豊富です。

WordPressだけに利用方法を限定されないため、次のような使い方もできます。

• WordPressを複数設置する
• HTMLで作ったサイトを公開する
• PHPで独自プログラムを動かす
• 独自ドメインのメールアドレスを作る
• サブドメインごとに異なるシステムを設置する

「WordPressを中心に使う予定だが、将来ほかのシステムも置くかもしれない」という場合にも対応しやすいサービスです。

エックスサーバーの料金

2026年8月1日時点の通常料金は次のとおりです。

初期費用は無料です。支払いは契約期間分の一括前払いとなります。

エックスサーバーの強み

最大の強みは、性能、安定性、料金、機能、情報量のバランスです。

スタンダードプランでも500GBのNVMeストレージ（SSD）が用意され、WordPressリカバリーや過去14日分の自動バックアップを利用できます。

利用者が多いため、設定方法やトラブルの解決事例をインターネット上で見つけやすい点もメリットです。

特定の機能に極端に特化するのではなく、さまざまなサイトを無理なく運用できるように設計されています。

WordPressの一部テーマの割引特典

WordPressで利用できる定番テーマについて、以下のとおり割引価格で購入することが可能です。（価格は2026年8月1日現在。割引施策は終了となる可能性があります）

• Xwrite（エックスサーバー自社開発テーマ）： 19,800円 → 15,840円（買い切り価格）
  ※プレミアムプラン以上をご契約中の場合に限り、無料で利用可能です
• SWELL： 17,600円 → 16,720円（買い切り価格）
• Snow Monkey： 16,500円 → 15,675円 ※年額サブスクリプション
• Emanon Business： 12,800円 → 10,230円（買い切り価格）
• LIQUID INSIGHT： 16,200円 → 15,180円（買い切り価格）
• Nishiki Pro： 17,800円 → 16,910円（買い切り価格）

WordPressに定評のある「エックスサーバー」の公式テーマ「Xwrite」

WP Pilot

エックスサーバーが向いている人

• 初めてレンタルサーバーを契約する人
• 個人ブログや一般的な企業サイトを運営する人
• WordPress以外のサイトやメールにも使いたい人
• 長期的な安定性や情報量を重視する人
• 特別な事情がなく、無難で失敗しにくいサービスを選びたい人

多くの個人サイトや中小規模サイトでは、まずスタンダードプランから検討すれば十分でしょう。

XServer for WordPressの特徴

高いセキュリティと手厚いサポートのWordPress専用ホスティングサービス 『XServer for WordPress』

・国内シェアNo.1「エックスサーバー」が提供するWordPress専用ホスティング ・サイト分離の高セキュリティ設計と、安心の稼働率99.99%以上保証 ・WordPress専門チームが対応！トラブル調査から技術的な作業代行まで実施 ・面倒な他社からのサイト移転も、専門スタッフが無料で代行 ・「.co.jp」も選択可能！ご契約中は独自ドメインの取得・更新が無料 ・複数サイトの更新・管理を効率化！クライアントへの権限付与も可能

公式サイトをチェック

料金やプランもこちらから

ポチップ

WordPressの保守・管理まで支援するサービス

XServer for WordPressは、WordPress専用のプレミアムホスティングサービスです。

一般的なレンタルサーバーでは、サーバー会社のサポート対象はサーバー機能が中心です。WordPressのテーマ設定やプラグインの不具合については、原則として利用者自身で調べる必要があります。

一方、XServer for WordPressでは、WordPressの基本操作も標準サポートの対象です。例えば、パーマリンクの変更、テーマの変更、パスワードの変更などを相談できます。

個別のテーマやプラグインのカスタマイズは対象外ですが、通常のレンタルサーバーよりWordPress側に踏み込んだ支援を受けられます。

WordPressごとに資源を割り当てる

XServer for WordPressでは、WordPressサイトごとに容量、メモリ、vCPUなどを割り当てます。

vCPUとは、仮想的に割り当てられるCPUの処理単位です。ベーシックプランとスタンダードプランでは、1サイトにつき最低でも容量10GB、メモリ1GB、vCPU 1コアを割り当てる仕組みになっています。

一般的な共用レンタルサーバーでは、契約全体のサーバー領域に複数のWordPressを設置します。一方、XServer for WordPressは、サイト単位で使える資源を意識して管理する仕組みです。

そのため、複数の顧客サイトを管理する制作会社や、社内で複数のWordPressサイトを運用する企業にも向いています。

ただし、資源割り当ての最低条件を確保するため、1契約ごとに設置・運用できるWordPressサイト数には制限がございます（制限数はプランにより異なります）。エックスサーバーやシンレンタルサーバーのように無制限に設置できるわけではないため、注意が必要です。

XServer for WordPressの料金

2026年8月1日時点の通常料金は次のとおりです。

ベーシックとスタンダードは共有サーバー、プレミアムとエンタープライズは仮想専用サーバーです。

プレミアムとエンタープライズには、17,600円の初期費用が別途かかります。

XServer for WordPressの強み

XServer for WordPressの最大の強みは、サーバー性能そのものよりも「運用時の失敗を防ぎ、問題が起きたときに戻しやすいこと」です。

テーマやプラグインを更新する前にステージング環境で確認し、問題がなければ本番環境に反映できます。

また、次の機能も利用できます。

• 過去14日分の自動・遠隔地バックアップ
• 任意のタイミングで作成できる手動バックアップ
• WordPressリカバリー
• WordPress向けセキュリティ自動最適化
• WordPress本体・テーマ・プラグインの一括管理
• WordPressの基本操作サポート
• 専門スタッフによるトラブル調査

WordPressの更新による不具合や、管理画面に入れなくなるトラブルに備えたい企業には、料金差に見合う価値があります。

XServer for WordPressが向いている人

• 企業の公式サイトを運営する人
• サイト停止による影響が大きい事業者
• 複数の顧客サイトを管理する制作会社
• ステージング環境を簡単に使いたい人
• WordPressの保守に詳しい担当者が社内にいない企業
• 料金よりも復旧性やサポートを重視する人

個人ブログで使えないわけではありませんが、一般的なブログには機能が過剰になりやすく、料金も高めです。

シンレンタルサーバーの特徴

自由と先進性を兼ね備えた新世代レンタルサーバー『シンレンタルサーバー』

・オールNVMe RAID10を採用した超高性能サーバー 　・サイトパフォーマンスを向上させる「Xアクセラレータ Ver.2」搭載 　・.com .netなどから選べる！独自ドメインが永久無料 　・初心者でも安心の24時間365日メールサポート！ 　・アダルトコンテンツを含む幅広い用途で利用可能

公式サイトをチェック

料金やプランもこちらから

ポチップ

新しい技術を積極的に取り込むサービス

シンレンタルサーバーは、エックスサーバーのシステムを土台としながら、新しい技術を迅速かつ積極的に取り込むことを掲げたサービスです。

基本的な管理方法や機能はエックスサーバーに近く、WordPress以外のHTMLサイトやPHPプログラム、メールにも利用できます。

一方で、安定性を最優先して慎重に新機能を導入するエックスサーバーに対し、シンレンタルサーバーは性能向上につながる新しい仕組みを比較的早く導入する立場です。

シンレンタルサーバーの料金

2026年8月1日時点の通常料金は次のとおりです。

シンレンタルサーバーの強み

シンレンタルサーバーでは、全ストレージにNVMe方式のSSDを採用し、RAID10構成を採用しています。RAID10とは、複数のストレージにデータを分散して高速化しながら、同じデータを複製して障害にも備える構成です。

また、公式サイトでは次のような設備や機能が案内されています（2026年8月1日時点）。おおむねエックスサーバーと同等の構成となっています。

• 第4世代AMD EPYC
• 256コアvCPU、1.5TBメモリのサーバー
• nginx
• Xアクセラレータ Ver.2
• XPageSpeed
• 10Gbps接続
• MCP対応の管理機能

なお、コンテンツの制限についても、エックスサーバーに比べると緩やかとなっています（当然のことながら日本の法令をいただく必要がございますが）。

新技術を採用することは不安定という意味ではない

シンレンタルサーバーは「新しい技術を取り込むサービス」ですが、常に不安定という意味ではありません。

エックスサーバーと同じ会社が運営し、基本的なサーバーパネルやサポート体制も整っています。

ただし、長期間の運用実績や慎重な変更方針を最優先するならエックスサーバー、新しい機能や性能、料金とのバランスを重視するならシンレンタルサーバーという違いがあります。

シンレンタルサーバーが向いている人

• サーバー性能と料金のバランスを重視する人
• 新しい技術や機能を試したい人
• 複数のWordPressサイトを低コストで運営したい人
• WordPress以外のサイトやメールも利用したい人
• サーバーの設定や不具合をある程度自分で調べられる人

初心者でも利用できますが、「迷ったら定番を選びたい」という人にはエックスサーバーのほうが分かりやすいでしょう。

また、WordPressの一部テーマ（SWELLやSnow Monkeyなど）について、エックスサーバーでは割引価格で購入できるという施策があります（上述のとおり）。一方で、シンレンタルサーバーではXwrite以外は対象外となっています。

wpX Speedの特徴

WordPress専用の高速クラウド型レンタルサーバー『wpX Speed』

・初期費用無料、1時間2円・月額1,320円(税込)〜 　・ピュアSSDの16倍以上高速！オールフラッシュNVMe RAID10構成 　・リソース使用量に応じて自動的に上位プランに移行し、 　　サイトのダウンを防ぐ「オートスケール設定」機能 　・他サーバーからの移転を手助けする「WordPress簡単移行」機能 　・「ダッシュボードへの不正ログイン防止」機能、 　　「国外アクセス遮断」機能、「WAF設定」機能等、充実のセキュリティ 　・自動バックアップ機能＆無料復元機能

公式サイトをチェック

料金やプランもこちらから

ポチップ

WordPress専用の時間課金型クラウド

wpX Speedは、WordPress専用に最適化されたクラウド型レンタルサーバーです。

料金は1時間単位で計算されますが、各プランには月額上限が設定されています。また、初期設定費は無料です。

例えば、W1を1か月使い続けても、料金は1,320円を超えません。一方で、基本料金が1時間単位の計算となっているため、月の途中で解約した場合や、月の途中でプランを変更した場合は計算が異なります。

オートスケールが大きな特徴

wpX Speedでは、サーバーに一定以上の負荷がかかった場合、設定した予算の範囲内で自動的に上位プランへ変更できます。例えば、普段はW1で運用し、アクセスが集中したときだけW2やW3へ引き上げるといった使い方ができます。

このような仕組みから、テレビや大手ニュースサイトで紹介される可能性があるサイト、期間限定キャンペーン、イベントサイトなどに向いています。

ただし、オートスケールは無制限に性能を上げる機能ではありません。どのプランまで引き上げるか、予算上限を事前に決めておく必要があります。

wpX SpeedのWordPress向け機能

wpX Speedには、次のような機能があります。

• WordPress簡単インストール
• WordPress簡単移行
• サーバーキャッシュ
• ブラウザキャッシュ
• WAF
• 国外アクセス制限
• ログイン試行回数制限
• 自動バックアップ
• 無料SSL
• PHP-FPM
• NVMe
• nginx
• RAID10

自動バックアップは過去7日分です。エックスサーバーやXServer for WordPressの14日分より保存期間が短いため、この点は注意が必要です。

wpX Speedの強み

最大の強みは、アクセス数に合わせてプランを柔軟に変更しやすいことです。

通常のレンタルサーバーでは、上位プランへの変更が月単位であったり、反映まで時間がかかったりすることがあります。wpX Speedは、急激な負荷への対応を前提とした設計です。

一方、通常のブログや法人コーポレートサイトではアクセスが急増する機会が少なく、オートスケールを必要としないこともあります。その場合、エックスサーバーやシンレンタルサーバーのほうが、料金や機能を理解しやすいでしょう。

wpX Speedが向いている人

• アクセス数の変動が大きいWordPressサイト
• テレビ、SNS、ニュースなどからアクセスが集中する可能性があるサイト
• 期間限定のキャンペーンサイト
• 月の途中だけサーバーを利用したい人
• サーバー負荷に応じて性能を変更したい人
• WordPress以外の用途を必要としない人

エックスサーバーとシンレンタルサーバーの違い

この2つは管理画面や機能が似ているため、もっとも迷いやすい組み合わせです。

大まかな違いは次のように考えられますが、迷ったらエックスサーバーを選んでおくので全く問題ありません（アダルトコンテンツ等、エックスサーバー側で禁止されており、シンレンタルサーバー側である程度認可されているコンテンツが含まれている場合を除きます）。

エックスサーバーは安定性と実績を重視

エックスサーバーは、幅広い利用者が安心して使えることを重視しています。長年の運用実績があり、利用者や解説情報も多いため、困ったときに情報を探しやすいのが特徴です。

初めて契約する人や、企業サイトを長期間安定して運営したい人に向いています。

シンレンタルサーバーは新技術と性能を重視

シンレンタルサーバーは、エックスサーバーの基盤を利用しつつ、新しい技術を積極的に採用します。料金も比較的抑えられているため、コストパフォーマンスを重視する利用者にも向いています。

どちらが常に高速であるかは、サイト構成、テーマ、プラグイン、キャッシュ、アクセス状況によって変わります。公式サイトの速度比較だけを見て決めるのではなく、運用方針も含めて選ぶことが大切です。

エックスサーバーとXServer for WordPressの違い

エックスサーバーでもWordPressを簡単に運用できます。そのため、「XServer for WordPressを選ぶ必要があるのか」と疑問に思うかもしれません。

両者の違いは、WordPressを動かせるかどうかではなく、WordPressの保守・管理をどこまでサーバー会社に支援してもらうかです。

エックスサーバーでは、WordPressのテーマやプラグインの更新、検証、トラブル対応は基本的に利用者が行います。

XServer for WordPressでは、ステージング、手動バックアップ、復旧、一括管理、基本操作サポートなどが用意されています。

自分で保守できる個人や技術者にはエックスサーバー、保守の負担やトラブル時のリスクを減らしたい企業にはXServer for WordPressが向いています。

wpX SpeedとXServer for WordPressの違い

どちらもWordPress専用ですが、目的が異なります。

wpX Speedが重視しているのは、サーバー負荷に応じた性能変更です。急激なアクセス増加への対応に強みがあります。

XServer for WordPressが重視しているのは、日常的な保守、更新、検証、復旧、サポートです。

そのため、アクセス負荷への柔軟な対応を重視するならwpX Speed、更新作業やトラブル対応の安全性を重視するならXServer for WordPressといった使い分けが考えられます。

結局どのサービスを選べばよいのか

一般的な個人ブログや汎用性を選ぶならエックスサーバー

初めてWordPressブログを作る場合や、安定性と使いやすさを重視する場合は、エックスサーバーがもっとも無難です。

WordPress以外にも使えるため、将来的な用途変更にも対応できます。

コストパフォーマンス重視ならシンレンタルサーバー

料金を抑えながら、高性能な環境や新しい機能を利用したい場合は、シンレンタルサーバーが候補になります。

ある程度自分で設定や検証ができる利用者とは、特に相性がよいでしょう。

企業サイトの保守を重視するならXServer for WordPress

ステージング環境や復旧機能、WordPressの操作サポートが必要な場合は、XServer for WordPressが適しています。

サーバー料金だけを見ると高額ですが、保守担当者の作業時間や、サイト停止による損失を減らせる可能性があります。

アクセス急増への対応ならwpX Speed

SNSやテレビ、広告などによって短時間に大量のアクセスが発生する可能性があるサイトには、wpX Speedが向いています。

時間課金とオートスケールを利用できるため、アクセス状況に応じた柔軟な運用が可能です。

まとめ

エックスサーバー系の4サービスは、同じ会社が運営していても、想定している利用者や運用方法が異なります。

迷ったときは、次の基準で考えると選びやすくなります。

• 安定性、実績、汎用性を重視するならエックスサーバー
• WordPressの保守、検証、復旧、サポートを重視するならXServer for WordPress
• 新技術、性能、料金のバランスを重視するならシンレンタルサーバー
• アクセス急増と柔軟な性能変更を重視するならwpX Speed

一般的な個人ブログや中小規模のWebサイトでは、エックスサーバーまたはシンレンタルサーバーで十分なことが多いでしょう。WordPress以外の用途に利用できるのも大きな強みです。

XServer for WordPressとwpX Speedは、WordPress専用である代わりに、それぞれ「運用支援」と「負荷への柔軟な対応」という明確な強みがあります。

単純な月額料金だけでなく、サイト停止時の影響、更新作業を担当する人の知識、アクセス数の変動、WordPress以外のシステムを使う可能性まで考えて選ぶことが重要です。

2026年7月、WordPress本体に関する深刻な脆弱性「wp2shell」が公表されました。

wp2shellは、第三者がWordPressの管理画面にログインしていない状態でも、条件を満たすサイトを外部から攻撃できる可能性がある脆弱性です。

WordPress本体の更新によって問題は修正されていますが、「実際に被害は発生しているのか」「具体的に何をされたのか」が気になる方も多いのではないでしょうか。

結論から言うと、wp2shellを悪用した実際の侵入や、不正なプログラムの設置はすでに確認されています。

一方で、本日2026年7月30日時点では、被害を受けた企業や団体の名前、個人情報の漏えい件数、金銭的な被害額などを明らかにした事例は、ほとんど公表されていません。

この記事では、セキュリティ企業などから公表されている代表的な攻撃事例を、できるだけ分かりやすく紹介します。

wp2shellとは？

wp2shellは、WordPress本体に見つかった複数の問題を組み合わせることで、外部の攻撃者がWordPressサイトを乗っ取れる可能性がある脆弱性です。

主に、次の2件の脆弱性が関係しています。

• CVE-2026-60137
• CVE-2026-63030

これらを組み合わせることで、攻撃者がWordPressの管理者権限を取得し、最終的にはサーバー上で不正なプログラムを動かせる可能性があります。このように、離れた場所からサーバー上でプログラムや命令を実行できる問題を「リモートコード実行」、略してRCEと呼びます。

wp2shellが特に深刻なのは、特定のプラグインやテーマを導入していなくても、WordPress本体だけで影響を受ける可能性がある点です。

発見者であるSearchlight Cyberは、初期の案内において、プラグインを追加していない標準的なWordPress環境でも、ログインしていない第三者から攻撃できる問題だと説明しています。

wp2shellによる攻撃はすでに確認されている

wp2shellは、単に「理論上は攻撃できる」という段階ではありません。

クラウドセキュリティ企業のWizは、2026年7月20日、実際のWordPress環境に対してwp2shellが悪用されていることを確認したと発表しました。

Wizの調査では、複数の攻撃者がクラウド上で運用されているWordPressサイトへの侵入に成功し、その後、不正なプラグインやWebシェルを設置していたとされています。Webシェルとは、攻撃者が外部からサーバーを操作するために設置する、不正なプログラムの一種です。

簡単に表現すると、WordPressの玄関から侵入した攻撃者が、その後も自由に出入りできるよう、サーバー内に別の裏口を作るようなものです（一般にこの「不正に設置された裏口経路」のことを「バックドア」と言います）。

被害事例1：不正なプラグインを設置された

Wizが確認した代表的な事例の一つが、不正なWordPressプラグインの設置です。

攻撃者はWordPressのプラグインアップロード機能を利用し、不正なプログラムを含むプラグインをサイトに追加していました。

通常、WordPressの管理者は、管理画面の「プラグイン」からZIP形式のプラグインをアップロードできます。

wp2shellによって管理者権限を取得されると、この正規の機能が攻撃者に悪用される可能性があります。

不正なプラグインが設置されると、攻撃者はWordPressの脆弱性を修正した後も、別に作られた裏口から再びサーバーを操作できるおそれがあります。

そのため、wp2shellの影響を受ける期間にサイトを公開していた場合は、WordPressを更新するだけでなく、身に覚えのないプラグインが追加されていないかも確認する必要があります。

被害事例2：簡単なPHP製のバックドアを設置された

Wizは、非常に短いPHPコードで作られたWebシェルの設置も確認しています。PHPとは、WordPressを動かすために使われているプログラミング言語です。

確認されたWebシェルは、攻撃者から特定の命令を受け取ると、その命令をサーバー上で実行する仕組みになっていました。

また、通常のアクセスに対しては「ページが見つからない」という404エラーを返すことで、不正なファイルの存在を隠そうとしていたとされています。

このようなWebシェルは非常に短いコードで作れるため、ファイルの名前や保存場所によっては、目視だけで発見することが難しい場合があります。

被害事例3：「CMSmap」を装った大規模な攻撃ツール

Wizが確認した中には、「CMSmap」という名前を使用した、約150KBの不正なWebシェルもありました。

CMSmap自体は、WordPressなどのCMSを調査するために使われる正規のセキュリティツールです。しかし、今回発見されたものは、正規のツールやプラグインに見せかけながら、内部に本格的な攻撃機能を備えていました。

具体的には、次のような機能が含まれていたと報告されています。

• サーバー内のファイルを閲覧・変更する
• WordPressのデータベースへアクセスする
• ネットワーク上のポートを調べる
• 複数のファイルへ一括で不正なコードを埋め込む
• サーバー内でより強い権限を取得しようとする

さらに、不正なコードは圧縮や文字列の変換によって読みにくくされていました。これは、不正なプログラムであることを管理者やセキュリティ製品から見つかりにくくするための処理と考えられます。

単なる実験的な攻撃ではなく、侵入後にさまざまな操作を行うための本格的な攻撃ツールが持ち込まれていたことが分かります。

被害事例4：攻撃者専用のREST APIを作られた

別の事例では、不正なプラグインによって、攻撃者専用のREST APIがWordPress内に追加されていました。

REST APIとは、外部のプログラムとWordPressがデータや命令をやり取りするための仕組みです。

正しく使用すれば便利な機能ですが、不正なプラグインによって攻撃者専用の入口を作られると、外部から自由に命令を送れるようになります。

Wizが確認した不正プラグインでは、攻撃者が特定のURLへ命令を送ることで、サーバー上のコマンドを実行し、その結果を受け取れる仕組みが作られていました。

つまり、WordPressの管理画面へログインしなくても、攻撃者が外部からサーバーを操作できる状態になっていたということです。

被害事例5：管理者のユーザー名やメールアドレスを収集された

wp2shellによる侵入後、WordPressのユーザー情報を取得するREST APIへアクセスする動きも確認されています。攻撃者は、WordPressの管理者ユーザー名やメールアドレスを収集しようとしていました。

管理者のユーザー名やメールアドレスが知られただけで、すぐにサイトへ侵入されるとは限りません。しかし、次のような別の攻撃に利用される可能性があります。

• 管理者を狙ったフィッシングメール
• パスワードの総当たり攻撃
• 他のサービスで使い回しているパスワードの悪用
• 本物の管理会社を装った偽メール
• WordPressの更新通知を装った詐欺

特に、管理者メールアドレスが一般に公開されていない場合は、攻撃によって取得された情報が、その後の標的型攻撃に利用される可能性があります。

被害事例6：wp-config.phpを狙った攻撃

攻撃者が、WordPressの重要な設定ファイルであるwp-config.phpを読み取ろうとした動きも報告されています。

wp-config.phpには、一般的に次のような重要情報が記載されています。

• データベース名
• データベースのユーザー名
• データベースのパスワード
• データベースサーバーの情報
• WordPressの認証用キー

Wizが確認した攻撃では、別のファイルを読み込む仕組みを悪用し、wp-config.phpの情報を取得しようとする試みが行われていました。これらの情報を取得されると、WordPressの投稿やユーザー情報が保存されているデータベースへ、直接アクセスされる可能性があります。

ただし、Wizは2026年7月20日の報告時点で、実際のデータ流出や他のサーバーへの侵入拡大までは確認していないと説明しています。

したがって、「設定ファイルを狙う攻撃は確認されたものの、情報が実際に持ち出されたことまで確認されたわけではない」という点には注意が必要です。

Wordfenceでも公表直後から攻撃を観測

WordPress向けセキュリティプラグインを提供するWordfenceも、wp2shellの公表直後から攻撃とみられる通信を確認しています。

Wordfenceによると、WordPressの修正版が公開された2026年7月17日のうちに、REST APIのバッチ処理機能を調査するようなアクセスが始まりました。

その後、同日のうちにSQLインジェクションを試みる明確な攻撃が確認されたとされています。

SQLインジェクションとは、データベースへの命令を不正に操作し、本来は取得できない情報を読み取ったり、データを書き換えたりする攻撃方法です。

Wordfenceの報告では、次のような流れが示されています。

• 2026年7月17日：WordPressの修正版を公開
• 同日中：REST APIのバッチ処理機能を調べる通信を確認
• その約13分後：SQLインジェクションを狙う通信を確認
• 7月18日から19日：脆弱性を再現するコードが広まり始める
• 7月20日：詳しい技術情報や確認用ツールが公開される

WordPressの修正版が公開されてから、非常に短い時間で攻撃が始まっていたことが分かります。

被害を受けた企業やサイトの実名は公表されている？

2026年7月30日時点では、wp2shellによって被害を受けた企業、自治体、学校、個人サイトなどの具体的な名前は、広く公表されていません。

また、次のような情報も、現時点では確認できる範囲が限られています。

• 個人情報が何件漏えいしたのか
• クレジットカード情報が盗まれたのか
• サイトが改ざんされた具体的な件数
• 金銭的な被害額
• ランサムウェア攻撃につながった事例
• 日本国内で発生した具体的な被害

そのため、「○○社で何万人分の情報が漏れた」というような、社会的に広く知られた被害事例は、まだ表に出ていない状況です。

ただし、被害者の名前が公表されていないからといって、被害が発生していないわけではありません。

セキュリティ企業の監視データでは、実際の侵入、不正プラグインのアップロード、Webシェルの設置、管理者情報の収集などがすでに確認されています。

サイト訪問者にも影響する可能性がある

wp2shellによってWordPressサイトが乗っ取られると、被害はサイト管理者だけにとどまらない可能性があります。

攻撃者がサイトの内容を自由に変更できるようになった場合、次のようなことが行われるおそれがあります。

• 不正なサイトへ自動転送する
• 偽のログイン画面を表示する
• マルウェアをダウンロードさせる
• 詐欺広告や偽の警告画面を表示する
• 投稿本文やリンクを書き換える
• 通販サイトの決済画面へ不正なコードを入れる

ただし、これらはWordPressサイトが完全に乗っ取られた場合に起こり得る被害です。

2026年7月30日時点では、「wp2shellによって侵害された特定のサイトから、多数の閲覧者がマルウェアに感染した」といった具体的な事例は、広く公表されていません。

Malwarebytesも、侵害されたWordPressサイトを訪問した利用者に起こり得る危険を説明していますが、すべてが実際に確認されたwp2shellの被害事例というわけではありません。

WordPressを更新すれば、それだけで十分なのか

wp2shellへの基本的な対策は、WordPress本体を修正版へ更新することです。

【メモ】WordPress 7.0.2／6.9.5／6.8.6で修正された脆弱性について

WP Pilot

WordPressでは、2026年7月17日に次の修正版が公開されました。

• WordPress 7.0.2
• WordPress 6.9.5
• WordPress 6.8.6

WordPress 6.9系と7.0系では、wp2shellの完全な攻撃経路につながる問題が修正されています。

WordPress 6.8系では、完全なRCEにつながる条件は異なるものの、関連するSQLインジェクションの問題が修正されているため、6.8.6への更新が必要です。

ただし、脆弱な期間中にすでに侵入されていた場合は、更新しただけでは不十分な可能性があります。

攻撃者が不正なプラグインやWebシェルを設置していた場合、WordPress本体を更新しても、設置された裏口はそのまま残ることがあるためです。

サイト管理者が確認したいポイント

WordPress 6.8系、6.9系、7.0系を使用しているサイトでは、まず修正版への更新が完了しているか確認しましょう。

そのうえで、次のような点も確認することが推奨されます。

管理者ユーザーを確認する

「ユーザー」画面を開き、身に覚えのない管理者アカウントが追加されていないか確認します。

攻撃者が管理者アカウントを作成した場合、WordPressを更新した後も、そのアカウントから再びログインされる可能性があります。

不審なプラグインを確認する

最近追加されたプラグインや、名前に覚えのないプラグインがないか確認します。

ただし、見覚えがないという理由だけで、すぐに削除するのは避けた方がよいでしょう。制作会社や管理担当者が導入している可能性もあるため、必要に応じてバックアップを取得し、担当者へ確認してください。

最近変更されたPHPファイルを確認する

テーマやプラグインのPHPファイルが、管理者の操作なしに変更されていないか確認します。

特に、通常は使用していない場所に新しいPHPファイルが作られている場合は注意が必要です。

アクセスログを確認する

サーバーのアクセスログで、次のようなURLへの不審なアクセスがないか確認します。

• /wp-json/batch/v1
• ?rest_route=/batch/v1
• /wp-admin/update.php?action=upload-plugin
• /wp-json/wp/v2/users?context=edit

ただし、これらのURLへのアクセスがあるだけで、必ず侵入されたとは限りません。

セキュリティ調査や単なるスキャンでもアクセスされる可能性があるため、前後の通信内容や応答結果も含めた確認が必要です。

セキュリティスキャンを実施する

Wordfenceなどのセキュリティプラグインや、サーバー会社が提供するマルウェアスキャンを利用する方法もあります。

ただし、スキャンですべての不正ファイルを必ず発見できるとは限りません。

不審な管理者アカウントやファイルが見つかった場合は、制作会社、サーバー会社、セキュリティ専門業者への相談も検討しましょう。

まとめ

wp2shellについては、実際のWordPressサイトに対する攻撃がすでに確認されています。

公表されている代表的な事例には、次のようなものがあります。

• 不正なWordPressプラグインのアップロード
• 簡単なPHP製Webシェルの設置
• CMSmapを装った本格的な攻撃ツールの設置
• 攻撃者専用REST APIの作成
• 管理者のユーザー名やメールアドレスの収集
• wp-config.phpを狙った情報取得の試み
• WordPress管理画面への不正アクセス

一方で、被害を受けた企業やサイトの実名、情報漏えい件数、被害金額などは、2026年7月30日時点ではほとんど公表されていません。

つまり、現在の状況は次のように整理できます。

脆弱なバージョンを公開状態で使用していた場合は、直ちに最新バージョンへ更新してください。また、そこで安心せず、不審な管理者、不正なプラグイン、最近変更されたファイルなども確認しておくことが大切です。

参考情報

日本語の情報

• IPA：WordPressの脆弱性対策について（CVE-2026-60137、CVE-2026-63030）
• WordPress 7.0.2リリース – WordPress.org 日本語

海外の情報（英語）

• Version 7.0.2 – Documentation – WordPress.org
• wp2shell: Pre Authentication RCE in WordPress Core › Searchlight Cyber
• Exploitation in the Wild of wp2shell | Wiz Blog
• wp2shell Aftermath: The First Critical Unauthenticated WordPress Core RCE in Nearly a Decade
• Malwarebytes：What happens if you visit a WordPress site hacked through wp2shell?

記事の概要

質問の詳細

WordPressの管理画面で「設定 → 表示設定」を開いても、本来あるはずの「ホームページの表示」が見つかりません。

「最新の投稿」と「固定ページ」のどちらをトップページに表示するか選びたいのですが、設定項目そのものが表示されていない状態です。テーマやWordPressの不具合なのでしょうか？

回答の詳細

「ホームページの表示」が出てこない場合は、最初に固定ページが1件も作成されていないことを疑ってみましょう。

WordPressでは、ホームページとして選択できる固定ページが存在しない場合、「設定 → 表示設定」にある「ホームページの表示」が表示されないことがあります。

これはテーマやWordPressが壊れているわけではなく、選択対象となる固定ページがないため、設定欄を表示する必要がないと判断されている状態です。

固定ページを1件作成して確認する

次の手順で確認してみましょう。

1. 管理画面の「固定ページ → 固定ページを追加」を開きます。
2. 「ホーム」などのタイトルを入力します。
3. 固定ページを下書きではなく「公開」します。
4. 「設定 → 表示設定」を開き直します。

公開済みの固定ページが作成されると、「ホームページの表示」が再び表示される可能性があります。

表示された場合は、次のどちらかを選択できるようになります。

• 最新の投稿
• 固定ページ

「固定ページ」を選択すると、作成したページをホームページとして指定できます。

下書きの固定ページでは表示されないことがある

固定ページを作成していても、次のような状態では選択対象にならない場合があります。

• 下書きのままになっている
• ゴミ箱に入っている
• 公開状態になっていない
• 固定ページではなく、通常の投稿として作成している

確認用の固定ページは、いったん「公開」状態にしてみるのが確実です。

固定ページがなくてもトップページが表示されることはある

「固定ページがないのに、サイトのトップページには画像や文章が表示されている」という場合もあります。これは、テーマにトップページ専用のテンプレートが用意されているためかもしれません。

例えば、テーマには次のようなファイルやテンプレートが含まれていることがあります。

• クラシックテーマの front-page.php
• ブロックテーマの front-page.html
• テーマ独自のトップページ設定
• デモ用のトップページレイアウト

このような仕組みがあると、ホームページ用の固定ページを作成していなくても、テーマ側で用意された内容がトップページに表示されます。

そのため、「トップページに何か表示されているから、固定ページも存在するはず」とは限りません。

ブロックテーマの場合はテンプレートも確認する

ブロックテーマを使用している場合は、管理画面の次の場所も確認してみましょう。

「外観 → エディター → デザイン → テンプレート」

その中に「フロントページ」というテンプレートがある場合、現在のトップページは固定ページではなく、そのテンプレートによって作られている可能性があります。

「FSEテーマ」（ブロックテーマ）導入ポイントを解説

WP Pilot

固定ページを公開しても表示されない場合

公開済みの固定ページを作成しても「ホームページの表示」が現れない場合は、別の原因も考えられます。

例えば、次のような可能性があります。

• プラグインが管理画面や固定ページの取得処理を変更している
• テーマや独自コードが管理画面を変更している
• WordPressのファイルが不足または破損している
• データベースに問題が起きている
• 操作している管理画面と、実際に表示しているサイトが別になっている

ただし、これらは最初から疑う必要はありません。

まずは「固定ページ → 固定ページ一覧」を開き、公開済みの固定ページが存在するか確認するのがよいでしょう。

まとめ

「設定 → 表示設定」に「ホームページの表示」が出てこない場合は、まず公開済みの固定ページが1件もないことを確認してみましょう。

WordPressでは、ホームページとして選べる固定ページがないと、設定項目自体が表示されない場合があります。

最初に「ホーム」などの固定ページを1件作成して公開し、その後に「設定 → 表示設定」を開き直してみてください。

固定ページを公開したことで設定欄が現れた場合は、不具合ではなく、固定ページがなかったことが原因だったと判断できます。

WordPressについて調べていると、ときどき「WordPressはセキュリティに問題があるから使わないほうがいい」「もう古い技術だから時代遅れだ」といった意見を見かけます。

もちろん、WordPressにも弱点はありますし、すべてのWebサイトにWordPressが向いているわけでもありません。

ただ、「WordPressだから危険」「新しい技術ではないからダメ」と単純に決めつけてしまうのも、少し違うのではないでしょうか。

Webサイトを作るうえで本当に大切なのは、使っている技術の新しさだけではありません。「何を作りたいのか」「誰が運営するのか」「何年間使うのか」「誰が保守するのか」といったことまで含めて考える必要があります。

今回は、WordPressをめぐって起こりがちな議論について、少し落ち着いて考えてみたいと思います。

「WordPressに脆弱性がある」ことと「WordPressは危険」は同じではない

WordPressでは、ときどきセキュリティ上の問題、いわゆる「脆弱性」が発見されます。脆弱性とは、簡単に言えば、攻撃などに悪用される可能性のあるソフトウェア上の弱点のことです。

そのため、「WordPressでは脆弱性が見つかることがある」という指摘自体は間違っていません。しかし、「脆弱性が見つかることがあるからWordPressは危険だ」というところまで話を広げると、少し慎重に考える必要があります。

脆弱性はWordPressだけに存在するものではありません。Webサイトで使われるさまざまなCMS、プログラム言語、フレームワーク、JavaScriptライブラリ、Webサーバーなどでも、セキュリティ上の問題が発見されることがあります。

重要なのは、脆弱性が一度も発見されないことではなく、問題が見つかったときに適切に修正され、それを利用者側でもきちんと更新できるかということです。

本当に注意したいのは「WordPress」より「管理されていないWordPress」

実際にWordPressサイトを運営するうえで注意したいのは、WordPressそのものよりも運用方法です。

例えば、以下のような状態の場合、当然セキュリティ上のリスクは高くなります。

• WordPress本体を何年も更新していない
• 古いプラグインを放置している
• 開発が終了したテーマを使い続けている
• 不要なプラグインを大量に残している
• 管理者パスワードが簡単すぎる
• バックアップを取っていない
• 制作会社から納品されたあと、誰も保守していない

これはWordPressに限った話ではありません。どのようなシステムであっても、長期間更新せずに放置すれば安全性は下がっていきます。

そのため、より正確に表現するなら、「WordPressは危険」ではなく、「適切に管理されていないWordPressは危険」と考える方が良いでしょう。

もちろんWordPressは世界中で広く使われているため、攻撃者から狙われやすいという面もあります。だからこそ、アップデートやバックアップ、不要なプラグインの整理など、基本的な管理を続けることが大切です。

【メモ】WordPress 7.0.2／6.9.5／6.8.6で修正された脆弱性について

WP Pilot

「WordPressは時代遅れ」という言葉にも注意したい

もう一つよく聞くのが、「WordPressは古い」「今ならもっとモダンな技術を使うべきだ」という意見です。これについても、一部には理解できる部分があります。

Web開発の世界では新しい技術が次々と登場しています。ReactやNext.jsなど、新しい設計思想を持った技術を使うことで、WordPressより適切に開発できるサービスもあります。

しかし、ここで考えたいのは、「新しい技術を使うこと」と「良いWebサイトを作ること」は必ずしも同じではないという点です。

例えば、会社のWebサイトを作る場合を考えてみましょう。

利用する企業にとって重要なのは、「最新のJavaScriptフレームワークで作られていること」でしょうか。

それよりも、

• 社内担当者が自分でお知らせを更新できる
• ページを追加できる
• 問い合わせフォームを設置できる
• 検索エンジンから見つけてもらいやすい
• 数年間安定して運営できる
• 担当者が変わっても引き継げる

といったことのほうが重要な場合が多いでしょう。

技術は目的ではありません。目的を実現するための道具です。

新しい技術だから優れている、とは限らない

Web制作では「モダン」という言葉がよく使われます。新しい設計や新しい開発手法には多くのメリットがありますし、それ自体を否定する必要はありません。

ただし、新しい技術を採用すると、以下のような別の課題が生まれることもあります。

• 開発できる人が限られる
• 制作担当者が辞めると引き継ぎが難しい
• ビルド環境など専門的な知識が必要になる
• 数年後に依存しているライブラリの更新が必要になる
• 小さな修正でもエンジニアに依頼しなければならない

一方、WordPressにも、下記のような弱点があります。

• プラグイン同士の相性問題
• アップデートによる不具合
• セキュリティ管理
• プラグインを増やしすぎることによる複雑化

つまり、どちらにもメリットとデメリットがあります。

大切なのは、「どちらの技術が上か」ではなく「どちらが今回の目的に合っているか」を考えることです。

【雑談】「業界内で有名＝世間でも高評価」とは限らない。評価軸の違いを理解して、自分に合った選択をしよう

WP Pilot

WordPressが向いていないWebサイトもある

ここまで読むと、WordPressを全面的に肯定しているように感じるかもしれません。

しかし、そういう話でもありません。WordPressが向いていないケースも当然あります。

例えば、以下の目的の場合、別の仕組みを使ったほうがよい場合があります。

• 高度なリアルタイム処理を行うサービス
• 複雑な業務システム
• 大規模なWebアプリケーション
• WordPressの投稿や固定ページという仕組みと相性が悪いサービス

反対に、以下のような目的であれば、WordPressが有力な選択肢になることがあります。

• ブログ
• 企業サイト
• 店舗サイト
• オウンドメディア
• ニュースサイト
• コンテンツを定期的に更新するWebサイト

そのため、「WordPressは良いCMSなのか、悪いCMSなのか」という問いよりも、「今回作るWebサイトにWordPressは合っているのか」と考えるほうが、ずっと実践的です。

Webサイトは「作った後」のほうが長い

技術を選ぶときに忘れられやすいのが、運用です。

Webサイトは完成したら終わりではありません。むしろ公開してから何年も使い続けることになります。

そのため、以下のようなことまで検討する必要があります。

• 誰が記事を更新するのか
• 誰がプログラムを更新するのか
• 不具合が起きたとき誰が直すのか
• 制作者がいなくなったら誰が引き継ぐのか
• 数年後にも運営を続けられるのか

どれだけ技術的に美しいWebサイトでも、「この開発者しか直せません」という状態であれば、企業にとって大きなリスクになることがあります。

WordPressの場合、利用者や開発者が比較的多く、インターネット上にも多くの情報があります。そのため、担当者が変わった場合でも比較的引き継ぎ先を探しやすいことは、一つのメリットといえるでしょう。これは技術的な新しさとは別の価値です。

「WordPress vs ○○」という話にしなくてもよい

技術の世界では、以下のように、どちらが優れているかという議論が起こることがあります。

• 「WordPress vs 静的サイト」
• 「WordPress vs Next.js」
• 「PHP vs JavaScript」
• 「クラシックテーマ vs ブロックテーマ」

もちろん、それぞれを比較すること自体には意味があります。ただ、それがいつの間にか、「こちらを使う人は分かっていない」「こちらの技術は古いから使う価値がない」という話になってしまうと、本来の目的から離れてしまいます。

工具に例えるなら、ハンマーとドライバーのどちらが優秀かを争っているようなものです。使う場所が違えば、必要になる工具も違います。Web技術も同じです。

ブロックテーマ時代だからこそ見直したい、クラシックテーマの魅力

WP Pilot

技術選定では「目的」から考えてみよう

Webサイトを作るときは、最初に技術を決めるのではなく、まず目的を考えることが大切です。

例えば、「会社のお知らせを社員が簡単に更新したい」という目的があるなら、その目的を実現できるCMSを考えます。

次に、「予算はいくらか」「誰が管理するのか」「どのくらいアクセスがあるのか」「どの程度のセキュリティが必要なのか」といった条件を整理します。

そして最後に、「それならWordPressがよさそうだ」「今回は別の仕組みのほうがよさそうだ」と判断します。

理想的なのは、「目的 → 要件 → 運用 → コスト → セキュリティ → 技術選定」という順番でしょう。

ところが技術論争では、ときどきこの順番が逆になります。「私はこの技術が好きだからこれを使う」「この技術は古いから使わない」となってしまうのです。

技術へのこだわりを持つこと自体は悪いことではありません。ただ、Webサイトを利用する人にとって何が一番大切なのかは、忘れないようにしたいところです。

終わりに：WordPressを無理に擁護する必要も、否定する必要もない

WordPressには長所があります。同時に短所もあります。新しい技術にも長所があり、短所があります。

そのため、「WordPressは最高だから全部WordPressで作ればいい」と考える必要もありませんし、「WordPressは古いから使ってはいけない」と考える必要もありません。大切なのは、そのサイトの目的に合っているかどうかです。

技術は競わせるものではなく、使い分けるものです。そして、Webサイトの価値を決めるのは、「何の技術で作られているか」だけではありません。

訪問者にとって使いやすいか、運営者が更新しやすいか、安全に管理できるか、数年後も維持できるか――本当に考えたいのは、そういった部分ではないでしょうか。

「WordPressは危険」「WordPressは時代遅れ」――そんな言葉を見かけたときも、すぐに賛成したり反論したりするのではなく、「それは、どのようなWebサイトを作る場合の話だろう？」と一度立ち止まって考えてみる。それくらいの距離感で技術と付き合うほうが、結果としてより良いWebサイトを作れるのではないかと思います。

2026年7月17日（米国現地時間）、「WordPress 7.0.2／6.9.5／6.8.6」が緊急リリースされました。

今回のWordPress 7.0.2／6.9.5／6.8.6は、通常の小さな不具合修正ではなく、優先して適用すべきセキュリティ更新です。

特にWordPress 6.9以降では、2つの問題が組み合わさることで、最終的にサーバー上で不正なコードを実行される可能性があります。WordPress.orgは問題の重大性から、影響を受けるサイトに対して自動更新システムによる強制更新も有効にしています。

以下に詳細をまとめますので、ご参考いただけますと幸いです。

【追記】追加のセキュリティアップデートが実施されました

2026年8月6日には、WordPress 7.0.3 / 6.9.6 / 6.8.7 などの追加のセキュリティアップデートが実施されました。そのため、早急に現行バージョンにアップデートいただくことをおすすめいたします。

「WordPress 7.0.3」セキュリティアップデート：7.0.2との違いと12件のセキュリティ修正を解説

WP Pilot

公式情報

• WordPress 7.0.2リリース – WordPress.org 日本語
• WordPress 7.0.2 Release – WordPress News

強制自動更新について

WordPress.orgは今回、影響を受けるバージョンに対して、自動更新システムによる強制更新を有効にしています。

このリリースはセキュリティアップデートのため、サイトをできるだけ早く更新することを推奨します。また、影響を受けるバージョンを使用しているサイトについては、問題の重大性を考慮し、WordPress.org チームが自動更新システムによる強制更新を有効にしています。

WordPress 7.0.2リリース – WordPress.org 日本語

これは、通常の自動更新設定とは別に、重大なセキュリティ問題が発生した際、WordPress.org側が修正版の配信を強く促す仕組みです。

ただし、次のような環境では自動更新が失敗したり、実行されなかったりする可能性があります。

• WordPressからファイルを書き換える権限がない
• 自動更新関連の定数やフィルターで更新を止めている
• サーバー側で外部通信が制限されている
• WordPress.orgへの接続に失敗している
• ディスク容量やファイル数が不足している
• コアファイルを独自に変更している
• 管理型サーバー独自の更新システムを使っている

したがって、「強制更新があるから放置してよい」ということではなく、管理画面で実際のバージョンを確認することが重要です。

今回の重要ポイント

今回修正された問題は2件です。

修正版は、7.0系が7.0.2、6.9系が6.9.5、6.8系が6.8.6です。WordPress 6.8より前のバージョンは、今回の2件の問題については影響を受けないと公式に案内されています。

• WordPress 6.9は、今回の2件の脆弱性の影響を受けます。両方の修正を含む WordPress 6.9.5をリリースしました。
• WordPress 6.8は、1件目の脆弱性のみ影響を受けます。この修正を含む WordPress 6.8.6をリリースしました。
• WordPress 7.1 Beta 版は、今回の2件の脆弱性の影響を受けます。両方の修正を含む WordPress 7.1 Beta 2をリリースしました。
• WordPress 6.8より前のバージョンは、この問題の影響を受けません。

WordPress 7.0.2リリース – WordPress.org 日本語

1件目：SQLインジェクションを容易にする問題

1件目は、WordPressの投稿取得に使われるWP_Queryのauthor__not_inというパラメーターに関係する問題です。

author__not_inは、特定の投稿者が書いた投稿を検索結果から除外するために使用します。

通常は、次のように投稿者IDを整数で指定します。

$query = new WP_Query(
	array(
		'author__not_in' => array( 3, 5, 8 ),
	)
);

ところが、修正前のWordPressでは、この部分に渡される値の処理が十分に厳しくなく、テーマやプラグインなどが外部入力を不適切に渡した場合、SQLインジェクションを成立させる余地がありました。

GitHubの公式セキュリティ情報では、この問題はWP_Queryのauthor__not_inパラメーターに存在するSQLインジェクションとして説明されています。影響範囲はWordPress 6.8.0以降で、7.0.2、6.9.5、6.8.6で修正されています。

SQLインジェクションとは

SQLインジェクションとは、データベースへ送る命令文に、不正な文字列を混ぜ込む攻撃です。

成立した場合、状況によっては次のような被害につながります。

• 投稿やユーザー情報の読み取り
• データベース内容の改ざん
• 管理者情報や設定情報の取得
• 本来表示されない情報へのアクセス
• 他の脆弱性と組み合わせた攻撃

ただし、今回の1件目だけで、すべてのWordPressサイトから無条件にデータベースを操作できるという意味ではありません。公式がfacilitated SQL injection、日本語では「SQLインジェクションを容易にする脆弱性」と表現している点が重要です。

つまり、WordPressコアの問題だけでなく、プラグインやテーマなどが外部入力をWP_Queryへ渡す処理と組み合わさることで、攻撃が成立しやすくなる問題と考えられます。

2件目：REST APIのバッチルート混同

2件目は、WordPress REST APIのバッチリクエストにおける「ルートの混同」です。

WordPress 6.9以降でこの問題が存在し、1件目のSQLインジェクションと組み合わさることで、リモートコード実行（Remote Code Execution、RCE）につながる可能性があります。

REST APIとは

REST APIは、WordPressの情報を外部のアプリケーションやJavaScriptから取得・更新する仕組みです。

例えば、次のような処理で使われます。

• ブロックエディターから投稿を保存する
• 投稿一覧を外部アプリに表示する
• ユーザーやコメント情報を取得する
• プラグインが管理画面と通信する
• ヘッドレスWordPressとして使用する

REST APIそのものが危険なのではありません。WordPressの標準機能として広く使われています。

今回問題になったのは、その中でも複数のAPI処理をまとめて送信する「バッチリクエスト」です。

バッチルートの混同とは

REST APIでは、リクエストされたURLやルートを見て、実行する処理を決定します。

例えば、投稿を取得する処理と、ユーザーを取得する処理は、それぞれ別のルートとして登録されています。

/wp-json/wp/v2/posts
/wp-json/wp/v2/users

バッチリクエストでは、複数のルートを一度に処理できます。

今回の問題では、バッチ内部のサブリクエストについて、WordPressが認識したルートと、実際に実行するルートの扱いに混同が生じる可能性がありました。

分かりやすく言えば、次のような問題です。

入力内容を確認したときの処理先と、実際に実行するときの処理先が一致しなくなる可能性があった。

これにより、本来適用されるべき入力値の検査、権限確認、エラー処理などが、正しい経路で行われない可能性があります。

リモートコード実行とは

リモートコード実行（Remote Code Execution、RCE）とは、攻撃者がインターネット経由でサーバー上のプログラムを実行できる状態です。

WordPressでRCEが成立すると、理論上は次のような被害につながります。

• 不正な管理者アカウントの作成
• プラグインやテーマの改ざん
• 不正なPHPファイルの設置
• 広告や別サイトへの不正転送
• 投稿内容の書き換え
• 個人情報や会員情報の取得
• 他サイトへの攻撃の踏み台化
• バックドアの設置

バックドアとは、攻撃者が後から再び侵入できるように設置する、隠れた侵入口のことです。そのため、RCEにつながる脆弱性は、一般的に非常に危険度が高いものとして扱われます。

2つの脆弱性が組み合わさる点が重要

今回の問題は、2件を完全に別々に考えるよりも、組み合わせて悪用できる可能性があることが重要です。

大まかな流れは次のように考えられます。

REST APIのバッチリクエストを送信
        ↓
ルートの認識や処理経路を混同させる
        ↓
WP_Queryへ不正な値を到達させる
        ↓
SQLインジェクションを成立させる
        ↓
データベースを書き換える
        ↓
WordPressが後から実行するデータや設定を改ざんする
        ↓
PHPコードなどの実行につながる

ただし、この流れは公表情報から整理した一般的な説明です。実際の攻撃手順については以下の記事にて詳しく解説しています。

【セキュリティ】WordPressの脆弱性「wp2shell」について、公表された攻撃事例を分かりやすく解説

WP Pilot

バージョンごとの影響範囲

今回の公式発表で特に重要なのは、バージョンごとに影響が異なる点です。

WordPress 7.0.0～7.0.1

2件とも影響を受けます。

• SQLインジェクションを容易にする問題
• REST APIのバッチルート混同
• 2件を組み合わせたリモートコード実行の可能性

更新先はWordPress 7.0.2です。

WordPress 6.9.0～6.9.4

7.0系と同様に2件とも影響を受けます。更新先はWordPress 6.9.5です。

WordPress 6.8.0～6.8.5

1件目のSQLインジェクションのみ影響を受けます。

REST APIのバッチルート混同はWordPress 6.9以降の問題であるため、6.8系では今回公表された組み合わせによるRCEの対象には含まれていません。

更新先はWordPress 6.8.6です。

WordPress 6.7以前

今回の2件については影響を受けないと公式発表されています。

ただし、これは「WordPress 6.7以前が安全」という意味ではありません。

古いバージョンには、過去に修正された別の脆弱性が残っている可能性があります。また、WordPress公式は最新バージョンのみを積極的にサポートすると案内しています。

As a courtesy, these fixes are also available in older affected branches of WordPress. As a reminder, only the most recent version of WordPress is actively supported.（注：強調は原文）

Version 7.0.2 – Documentation – WordPress.org

サイト運営者が行うべきこと

1．現在のWordPressバージョンを確認する

管理画面の「ダッシュボード → 更新」を開きます。

次のいずれかであれば、今回の修正は適用済みです。

• WordPress 7.0.2
• WordPress 6.9.5
• WordPress 6.8.6

2．未更新ならすぐ更新する

7.0.1以前の場合、6.9.4以前、6.8.5以前になっている場合は、更新前にバックアップを取り、現在使用中の系列の修正版へ更新します。

• 7.0.0～7.0.1 → 7.0.2
• 6.9.0～6.9.4 → 6.9.5
• 6.8.0～6.8.5 → 6.8.6

セキュリティ対応のために、7.0系から6.9系以前へ戻す必要はありません。

3．自動更新後も動作確認する

更新後は、例えば次のような事項の確認を行います。

• トップページが表示されるか
• 投稿や固定ページが表示されるか
• 管理画面へログインできるか
• ブロックエディターで保存できるか
• お問い合わせフォームが送信できるか
• 会員登録や決済が動作するか
• REST APIを使う機能が動作するか
• エラーログに新しいエラーがないか

4．不審な変更がないか確認する

未更新の状態でしばらく公開されていた場合は、念のため次も確認します。

• 身に覚えのない管理者ユーザー
• 不明なプラグインやテーマ
• 最近変更されたPHPファイル
• wp-content/uploads内のPHPファイル
• 不審なリダイレクト
• 投稿や固定ページの改ざん
• .htaccessの不審な変更
• wp-config.phpの不審な追記
• サーバーのアクセスログやエラーログ

ただし、公式発表では、現時点で実際の悪用が確認されているかどうかや、具体的な侵害の痕跡は明示されていません。更新が遅れたからといって、必ず侵入されたという意味ではありません。

対応の緊急性と対応方法について

「深刻」と「重要」の意味

日本語公式発表では、今回の2件について次のように説明されています。

• 深刻な脆弱性：1件
• 重要な脆弱性：1件

英語版ではone critical and one high severity security issueと表現されています。

ただし、GitHubの個別アドバイザリでは次の評価になっています。

この違いは、一見すると少し分かりにくい部分です。

考えられる整理としては、1件目のSQLインジェクション単体では成立条件が限定されるためModerateと評価される一方、WordPressのリリース全体としては、2件を組み合わせた攻撃や影響の大きさを考慮し、「CriticalとHigh」として強く注意を促している可能性があります。

ただし、公式発表とGitHubアドバイザリで評価表現が完全には一致していないため、現時点では無理にどちらか一方へ統一して説明しない方が適切です。

実務上は、RCEにつながるCritical相当の問題を含むため、緊急度の高い更新と考えればよいでしょう。

ログインしていない攻撃者でも悪用できるのか

現時点の公式発表だけでは、次の条件は明確ではありません。

• 未ログインでも攻撃できるか
• 購読者などのユーザーアカウントが必要か
• 特定のプラグインが必要か
• REST APIが通常どおり有効なら成立するか
• 特定のREST APIルートが必要か
• マルチサイトでも同様に成立するか

そのため、現段階で「誰でもログインなしで全サイトを乗っ取れる」と断定することはできません。

一方、WordPress.orgが強制自動更新を有効にしたことから、攻撃条件が完全に公開されていなくても、WordPress側は非常に高い優先度で対応すべき問題と判断していることが分かります。

REST APIを無効化すれば更新しなくてもよいのか

REST APIを制限しているサイトでも、更新は必要です。

理由は3つあります。

• 1件目のSQLインジェクションはREST APIだけに限定された問題ではありません。WordPress 6.8系も影響を受けていることから、REST APIのバッチルート混同がなくても、別のテーマやプラグインの処理から問題が利用される可能性があります。
• REST APIを完全に無効化すると、ブロックエディターやプラグイン、管理画面の一部が正常に動作しなくなる可能性があります。
• REST API制限プラグインを使用していても、すべてのルートや内部サブリクエストが完全に遮断されるとは限りません。

したがって、REST APIを止めることは、今回の正式な対策にはなりません。正式な対策はWordPressコアを修正版へ更新することです。

WAFやセキュリティプラグインがあれば大丈夫か

WAFやセキュリティプラグインの導入は、攻撃リクエストを遮断する補助策として有効な場合があります。ただし、これらが導入されていても、WordPressの更新を省略すべきではありません。

今回のような複数の処理を組み合わせる脆弱性では、既知の攻撃パターンだけを遮断するWAFでは、すべての変形パターンに対応できない可能性があります。

また、強制自動更新を有効にするほどの問題ですので、WAFはあくまで追加防御と考え、WordPress本体の更新を優先してください。

更新後にパスワード変更は必要か

通常は、更新しただけで全ユーザーのパスワードを変更する必要はありません。

ただし、次のような兆候がある場合は、パスワード変更や2段階認証導入のご検討をおすすめします。

• 不審な管理者アカウントがある
• ログイン履歴に不明なアクセスがある
• ファイルが改ざんされている
• 不審なプラグインが追加されている
• データベースが書き換えられた形跡がある
• セキュリティ製品が侵入を検知した

更新後も6.8.6や6.9.5を使い続けてよいか

今回の脆弱性への対応という意味では、それぞれの修正版で問題ありません。ただし、WordPress公式は、古い影響対象ブランチへの修正提供は便宜上のバックポートであり、積極的にサポートされるのは最新バージョンだけだと説明しています。

互換性の問題などで6.8系や6.9系を一時的に使用することはできますが、長期的には次の対応が望まれます。

• テーマやプラグインを最新版にする
• PHPの対応状況を確認する
• 検証環境でWordPress 7.0系を試す
• 問題がなければ最新系列へ移行する

今回のリリースをどう評価すべきか

今回の更新は、WordPressコアのセキュリティリリースとしても緊急度が高い部類です。

理由は次のとおりです。

• 公式がCriticalとHighの問題として発表している
• 2つの問題を組み合わせるとRCEにつながる
• WordPress.orgが強制自動更新を有効にしている
• 6.9系と7.0系が両方影響を受ける
• CVE番号とGitHub Security Advisoryが公開されている
• 7.1 Betaも修正版が再リリースされている

一方で、現時点では攻撃成立条件のすべてが公開されていません。そのため、「すべてのサイトが無条件に遠隔操作される」と過度に不安をあおるのも適切ではありません。

実務上の捉え方は、次のようになります。

まとめ

WordPress 7.0.2／6.9.5／6.8.6では、WP_Queryのauthor__not_inに関するSQLインジェクションと、REST APIのバッチルート混同が修正されました。

WordPress 6.9以降では、この2件を組み合わせることで、サーバー上のコード実行につながる可能性があります。WordPress 6.8系は1件目だけが対象で、6.8より前のバージョンは今回の問題の影響を受けません。

対象サイトでは、次の更新を速やかに行ってください。

• WordPress 7.0.0～7.0.1 → WordPress 7.0.2
• WordPress 6.9.0～6.9.4 → WordPress 6.9.5
• WordPress 6.8.0～6.8.5 → WordPress 6.8.6

WAFやセキュリティプラグイン、サーバー運営側の対応だけに頼らず、WordPressコア自体を修正版に更新することが、今回の正式かつ最も確実な対策です。

WordPress 7.0では、ブロックエディターに新しく「高度な設定＞追加CSS」という機能が追加されました。これにより、投稿や固定ページに配置した特定のブロックだけに、直接CSSを設定できるようになっています。

例えば、ページ内に複数の見出しブロックがある場合でも、その中の一つだけ色を変えたり、枠線を付けたり、余白を調整したりできます。

これまでは、特にプラグインやテーマの機能に頼らなければ、ブロックにCSSクラス名を付けたうえで、テーマのCSSファイルや追加CSS欄にコードを書く必要がありました。WordPress 7.0では、簡単な装飾であれば、ブロックの設定画面だけで完結させることができます。

この記事では、WordPress 7.0で追加されたブロック機能「追加CSS」について、基本的な使い方、従来の機能との違い、便利な使用例、利用時の注意点まで詳しく解説します。

WordPress 7.0の「高度な設定＞追加CSS」とは

「高度な設定＞追加CSS」とは、投稿や固定ページに配置した一つのブロックに対して、CSSを直接入力できる機能です。CSSとは、文字の色や大きさ、背景色、余白、枠線など、Webページの見た目を調整するための仕組みです。

WordPress 7.0以前でもCSSによる調整は可能でしたが、一般的には次のような手順が必要でした。

1. ブロックにCSSクラス名を付ける
2. テーマのCSSファイルや追加CSS欄を開く
3. クラス名を指定してCSSを書く

例えば、ブロックの「追加CSSクラス」に次の名前を入力します。

special-heading

続いて、テーマやサイト全体のCSSに次のようなコードを書きます。

.special-heading {
	color: blue;
}

WordPress 7.0では、このようなクラス名の設定を行わなくても、選択したブロックの設定欄に直接CSSを書けるようになりました。

color: blue;

入力したCSSは、そのブロックだけに適用されます。同じページ内に同じ種類のブロックが複数あっても、ほかのブロックには基本的に影響しません。

追加CSSはどこにあるのか

ブロックごとの「追加CSS」は、投稿または固定ページの編集画面から設定します。基本的な手順は次のとおりです。

1. 投稿または固定ページの編集画面を開く
2. CSSを設定したいブロックを選択する
3. 画面右上の「設定」を開く
4. 右側のブロック設定を表示する
5. 「高度な設定」を開く
6. 「追加CSS」にCSSを入力する

なお、管理画面を英語で使用している場合は、次のような表示になります。

Advanced → Additional CSS

「追加CSS」と「追加CSSクラス」の違い

ここで注意したいのが、従来からある「追加CSSクラス」と、WordPress 7.0で追加された「追加CSS」は別の機能である点です。

「追加CSSクラス」には、notice-boxやspecial-headingなどの名前を入力します。一方、「追加CSS」には、colorやpaddingなどのCSSそのものを入力します。

名前がよく似ているため、間違えないように注意しましょう。

基本的なCSSの書き方

ブロックごとの追加CSSでは、通常のCSSのように対象を指定するセレクターを書く必要はありません。セレクターとは、CSSをどの要素に適用するのかを指定する部分です。

通常のCSSでは、次のようにクラス名や要素名を指定します。

.special-heading {
	color: red;
}

しかし、ブロックごとのCSSでは、すでに対象となるブロックを選択しています。

そのため、中かっこの内側に書く部分だけを入力します。

color: red;

背景色や余白を設定する場合は、次のように書きます。

background-color: #fff5f5;
padding: 20px;

枠線や角丸を追加することもできます。

border: 1px solid #dddddd;
border-radius: 8px;
padding: 20px;

なお、複数のCSSを入力するときは、基本的に各行の最後へセミコロンを付けます。セミコロンが抜けると、後ろに書いたCSSが正しく反映されないことがあります。

color: #333333;
background-color: #ffffff;
padding: 20px;

設定例①

border: 1px solid #dddddd;
border-radius: 8px;
padding: 20px;

セレクターを書かなくてよい理由

通常のCSSでは、どの部分を装飾するのかを指定しなければなりません。

例えば、次のCSSでは、special-headingというクラスが付いた要素を対象としています。

.special-heading {
	color: blue;
}

しかし、ブロックごとのCSSでは、WordPressが対象のブロックを自動的に識別します。そのため、利用者は次のようにCSSの内容だけを書けばよい仕組みです。

color: blue;

内部的には、WordPressが対象ブロックに専用のクラスを追加し、そのクラスに対するCSSを生成します。

概念的には、次のようなHTMLになります。

<h2 class="wp-block-heading wp-custom-css-xxxxxxxx">
	見出し
</h2>

さらに、WordPress側で次のようなCSSが作られます。

:root :where(.wp-custom-css-xxxxxxxx) {
	color: blue;
}

wp-custom-css-xxxxxxxxの部分は、WordPressが自動的に作る識別用のクラスです。利用者が自分で入力したり管理したりする必要はありません。

ブロックの中にある要素を指定する方法

ブロックごとの「高度な設定＞追加CSS」では、ブロック本体だけでなく、ブロック内にあるリンクや画像などを指定することもできます。

ブロック内の要素を指定したい場合は、&という記号を使用します。&は、現在選択しているブロック自身を表します。

ブロック内のリンク色を変更する

選択したブロック内にあるリンクだけを変更する場合は、次のように書きます。

& a {
	color: #007070;
}

リンクにマウスを重ねたときの色を変更する

& a:hover {
	color: #004c4c;
}

通常のCSSに置き換えると、次のような意味になります。

対象のブロック a:hover {
	color: #004c4c;
}

ブロック内の画像を調整する

& img {
	border-radius: 8px;
}

この場合は、選択したブロックの中にある画像へ角丸が適用されます。ただし、ブロックによって内部のHTML構造は異なります。

CSSを書いても反映されない場合は、ブロック本体ではなく、内部にある別の要素を指定しなければならないことがあります。

設定例②

& {
  border: 1px solid #dddddd;
  border-radius: 8px;
  padding: 20px;
}

& a {
	color: #007070;
}
& a:hover {
	color: #004c4c;
}

「高度な設定＞追加CSS」の使用例

ここからは、実際に利用しやすいCSSの例を紹介します。

特定の見出しだけ装飾する

特定の見出しに左側の線と背景色を追加する例です。

border-left: 5px solid #007070;
padding-left: 15px;
background-color: #f2fafa;

ページ内にほかの見出しブロックがあっても、CSSを入力した見出しだけに適用されます。記事内で特に重要な見出しを目立たせたい場合などに利用できます。

特定の段落を注意書き風にする

background-color: #fffbea;
border: 1px solid #e5d48a;
padding: 16px;
border-radius: 6px;

補足説明や注意事項を囲む場合に便利です。ただし、同じ注意書きを何度も使用する場合は、後述する追加CSSクラスなどで共通管理した方がよいでしょう。

特定の画像だけ影を付ける

box-shadow: 0 4px 15px rgba(0, 0, 0, 0.15);
border-radius: 8px;

画像の周囲へ薄い影を付け、角を丸くできます。記事内のスクリーンショットや紹介画像を少し目立たせたい場合に使いやすい設定です。

グループブロックをカード風にする

padding: 24px;
border: 1px solid #dddddd;
border-radius: 10px;
background-color: #ffffff;
box-shadow: 0 3px 12px rgba(0, 0, 0, 0.08);

「グループ」ブロックに設定すると、囲まれた内容をカードのように見せることができます。関連情報やサービス紹介、プロフィール欄などに利用できます。

ボタンの色を変更する

ボタンブロックでは、外側のブロックではなく、内部のリンク要素に背景色が設定されている場合があります。

そのため、次のように& aを使います。

& a {
	background-color: #007070;
	border-radius: 6px;
	padding: 12px 24px;
}

マウスを重ねたときの色も設定できます。

& a:hover {
	background-color: #004c4c;
}

テーマやプラグインによってはCSSが競合し、指定どおりに反映されないことがあります。

従来の「追加CSSクラス」との違い

WordPress 7.0のブロックごとのCSSと、従来の追加CSSクラスは、どちらが優れているというものではありません。

用途が異なるため、目的に応じて使い分けることが重要です。

追加CSS

ブロックの設定欄に直接CSSを書きます。

color: blue;
padding: 10px;

CSSを入力したブロックだけに適用されます。一回だけ使用する装飾や、そのページ固有の調整に向いています。

追加CSSクラス

ブロックにクラス名を入力します。

notice-box

その上で、テーマやサイト全体のCSSにコードを書きます。

.notice-box {
	padding: 20px;
	border: 1px solid #dddddd;
	background-color: #ffffee;
}

クラス名を付けたすべてのブロックに同じデザインを適用できます。複数の記事やページで同じ装飾を繰り返し使う場合に向いています。

使い分けの目安

ブロックごとのCSSは手軽ですが、同じCSSを何度もコピーすると管理が難しくなります。繰り返し使用するデザインは、追加CSSクラスでまとめて管理するのがおすすめです。

仕様の制約について

サイトエディターのブロック別CSSとの違い

ブロックテーマでは、サイトエディターの「スタイル＞ブロック」から、ブロックの種類ごとにCSSを設定できる機能があります。

この機能とWordPress 7.0の「高度な設定＞追加CSS」は、適用される範囲が異なります。

例えば、サイト内のすべての見出しブロックを変更したい場合は、ブロックごとのCSSを一つずつ設定する方法は効率的ではありません。その場合は、サイトエディター、theme.json、テーマのCSSなどを使用する方が管理しやすくなります。

一方、特定の記事にある一つの見出しだけを調整したい場合は、ブロックごとに細かく設定できる「高度な設定＞追加CSS」が便利です。

すべてのユーザーが利用できるわけではない

ブロックごとのCSSは、WordPressの管理画面を利用できるすべてのユーザーに表示されるわけではありません。

利用するには、edit_cssという権限が必要です。これは、サイトのCSSを編集するための権限です。

一般的なWordPressの単独サイトでは、管理者がこの権限を持っています。一方、編集者、投稿者、寄稿者などには表示されない可能性があります。また、権限管理プラグインなどによって設定が変更されている場合は、通常とは異なる表示になることもあります。

CSSを編集すると、サイトのデザインを大きく崩したり、要素を非表示にしたりすることも可能です。そのため、一定の権限を持つユーザーだけが利用できる仕組みになっています。

一部のブロックでは表示されないことがある

「高度な設定＞追加CSS」は多くのブロックで利用できますが、すべてのブロックに必ず表示されるわけではありません。

例えば、通常のブロックとはHTMLの出力方法が異なるブロックや、外側に専用のクラスを付けにくいブロックでは、利用できない場合があります。また、プラグインが提供する独自ブロックでは、ブロックの開発者がこの機能を無効にしていることがあります。

ブロック開発者は、block.jsonに次のような設定を書くことで、ブロックごとのCSSを無効にできます。

{
	"supports": {
		"customCSS": false
	}
}

そのため、特定のブロックだけ「追加CSS」が表示されなくても、必ずしもWordPressの不具合とは限りません。ブロック側の仕様として無効化されている可能性があります。

CSSはどこに保存されるのか

「高度な設定＞追加CSS」に入力した内容は、テーマのstyle.cssへ保存されるわけではありません。投稿や固定ページのブロック情報として保存されます。

コードエディターで確認すると、概念的には次のような形になります。

<!-- wp:heading {"style":{"css":"color: blue;\n"}} -->
<h2 class="wp-block-heading">見出し</h2>
<!-- /wp:heading -->

CSSは、対象ブロックの属性として投稿本文内に保存されています。そのため、テーマを変更してもCSSの入力内容自体は基本的に残ります。

ただし、テーマを変更すると、もともとの文字サイズ、余白、色、HTML構造などが変わることがあります。CSSが残っていても、テーマ変更前とまったく同じ見た目になるとは限りません。

ブロックごとのCSSを使うメリット

ブロックごとのCSSの大きなメリットは、特定のブロックだけを手軽に調整できることです。

例えば、次のような場面に向いています。

• 特定の注意書きだけ枠で囲みたい
• 一つの画像だけ角を丸くしたい
• 特定の記事にあるCTAだけ目立たせたい
• 一つのグループブロックだけ背景色を変えたい
• テーマの設定では対応できない部分を微調整したい
• CSSクラスを作るほどではない一回限りの装飾をしたい

CTAとは、「お問い合わせ」「購入」「会員登録」など、読者に次の行動を促すための案内やボタンのことです。

これまでは、ちょっとした変更でもCSSクラスを追加し、別の画面でCSSを書く必要がありました。「高度な設定＞追加CSS」なら、編集画面内で作業できるため、手順を減らせます。

「高度な設定＞追加CSS」を使う際の注意点

便利な機能ですが、使いすぎには注意が必要です。

CSSが記事内に分散する

ブロックごとのCSSは、CSSを設定したブロックの中に保存されます。そのため、多くのブロックにCSSを設定すると、どこに何を書いたのか分かりにくくなります。

例えば、記事内の20個のブロックに個別のCSSを設定した場合、後からデザインを変更するときに、対象のブロックを一つずつ探さなければなりません。

CSSの一覧を一か所で確認できるわけではないため、長期的な管理には向かない場合があります。

同じCSSを何度も書かない

同じデザインを複数のブロックで使用したい場合に、各ブロックへ同じCSSをコピーする方法はおすすめできません。

例えば、10個の注意書きに同じCSSを書いた場合、背景色を変更するだけでも10か所を修正する必要があります。このような場合は、適用したいブロックに共通のクラス名を付けます。

notice-box

その上で、サイト全体のCSSにまとめて記述します。

.notice-box {
	padding: 20px;
	border: 1px solid #dddddd;
	background-color: #ffffee;
}

これなら、CSSを一か所変更するだけで、同じクラスを付けたすべてのブロックをまとめて変更できます。

CSSの知識は必要

入力欄が追加されたからといって、CSSを自動的に作ってくれるわけではありません。CSSのプロパティ名や書き方が間違っていると、正しく反映されません。

例えば、文字色を変える基本的な書き方は次のとおりです。

color: red;

背景色の場合は次のように書きます。

background-color: yellow;

入力欄が空欄のままになったり、コードの書き方を間違えたりすると、表示は変わりません。

!importantの多用は避ける

テーマ側のCSSが優先され、入力したCSSが反映されない場合があります。そのようなとき、次のように!importantを付ける方法があります。

color: red !important;

ただし、!importantを多用すると、後から別のCSSで上書きしにくくなります。将来的な修正が難しくなるため、できるだけ安易に使用しない方がよいでしょう。

CSSが反映されない場合は、次の順番で確認することをおすすめします。

1. CSSの書き方が間違っていないか
2. 対象となる要素が正しいか
3. & aや& imgなど、内部要素の指定が必要ではないか
4. テーマやプラグインのCSSと競合していないか
5. 最終手段として!importantを検討する

画面幅による見え方にも注意する

パソコンでは問題なく見えても、スマートフォンでは余白が広すぎたり、文字が大きすぎたりすることがあります。

たとえば、次のように左右へ大きな余白を設定するとします。

padding: 40px;

パソコンでは適切でも、画面の狭いスマートフォンでは、内容を表示できる幅がかなり小さくなる可能性があります。「高度な設定＞追加CSS」を設定した後は、パソコンだけでなく、タブレットやスマートフォンでの表示も確認しましょう。

使い分けについて

「高度な設定＞追加CSS」が適しているケース

次のような場合は、「高度な設定＞追加CSS」が使いやすいでしょう。

• 一つのページだけで使用するデザイン
• 一つのブロックだけの微調整
• 一時的なキャンペーン用の装飾
• ほかの場所では再利用しないデザイン
• テーマの設定では対応できない細かな変更

たとえば、期間限定のお知らせや、その記事だけに必要な注意書きなどには向いています。

追加CSSクラスが適しているケース

次のような場合は、「追加CSSクラス」で管理する方が適しています。

• 複数の記事で同じ装飾を使用する
• 注意書きや補足欄を繰り返し使用する
• 後からまとめてデザインを変更したい
• サイト内で共通の部品として管理したい
• CSSを一か所にまとめて確認したい

デザインを再利用する可能性があるなら、最初からクラス名を付けて管理した方が効率的です。

theme.jsonが適しているケース

theme.jsonは、WordPressテーマの色、文字サイズ、余白、レイアウトなどを設定するためのファイルです。

WordPress初心者が知っておきたい「theme.json」とは？ 基本から使い方まで分かりやすく解説

WP Pilot

次のような場合は、ブロックごとのCSSではなく、theme.jsonでの設定を検討した方がよいでしょう。

• サイト全体の色を統一したい
• ブロックの標準デザインを設定したい
• 編集画面と公開画面の表示をそろえたい
• 利用できる色や文字サイズを管理したい
• テーマとして体系的にデザインを整えたい

「高度な設定＞追加CSS」は、サイト全体のデザインを設計するための機能というより、例外的な部分を調整するための機能と考えると分かりやすいでしょう。

まとめ

WordPress 7.0では、投稿や固定ページに配置した特定のブロックへ、直接CSSを書ける機能が追加されました。

WordPress 7.0とは？ 主な変更点を解説します

WP Pilot

CSSを設定したいブロックを選択し、ブロック設定の「高度な設定」にある「追加CSS」へコードを入力します。

基本的には、次のようにCSSの宣言だけを書きます。

color: #007070;
padding: 20px;
border: 1px solid #dddddd;

ブロック内のリンクや画像などを指定したい場合は、&を使います。

& a:hover {
	color: #004c4c;
}

ブロックごとのCSSは、一回限りの装飾や、特定のブロックだけを微調整する場合に便利です。一方、同じデザインを複数の場所で使う場合は、追加CSSクラスやテーマのCSSで共通管理した方が、後から修正しやすくなります。サイト全体のデザインを整える場合は、theme.jsonやサイトエディターを使用する方法が適しています。

基本的には、次のように使い分けるとよいでしょう。

• 例外的な一つのブロックには「追加CSS」
• 繰り返し使う装飾には「追加CSSクラス」
• サイト全体のデザインには、theme.jsonやテーマCSS

WordPress 7.0の「高度な設定＞追加CSS」は便利な機能ですが、何でも個別に設定すると管理が難しくなります。手軽さだけでなく、後から修正しやすいかどうかも考えながら、ほかのCSS設定方法と使い分けることが大切です。