記事の概要

質問の詳細

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サイトを作ってくれる会社。この点を一つの判断基準として、安心して長く付き合える制作パートナーを探してみてください。

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

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?

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を使っていると、ある日突然「表示が崩れた」「編集画面がうまく動かない」「プラグインを入れたらエラーが出た」といった不具合に出会うことがあります。そのようなとき、テーマやプラグインの開発元、WordPress公式フォーラム、サーバー会社などへ相談する場面もあるでしょう。

ただし、不具合報告をするときに、「動きません」「壊れました」「おかしいです」などと書くだけでは、相手も原因を調べることができません。

WordPressの不具合は、WordPress本体だけでなく、テーマ、プラグイン、サーバー、ブラウザ、キャッシュ、設定変更など、さまざまな要素が関係します。そのため、不具合報告をする前には、できる範囲で状況を整理しておくことが大切です。

この記事では、WordPressで不具合報告をする前に確認しておきたい点を、初心者の方にも分かりやすくまとめます。

報告前のチェック事項

不具合報告で最も大切なのは「相手が再現できること」

不具合報告で一番大切なのは、相手が同じ現象を確認できるように伝えることです。これを「再現できる」「再現性がある」などと表現することが多いです。

例えば、「投稿編集画面で画像ブロックを追加し、更新ボタンを押すと、公開画面で画像が表示されません」という報告であれば、相手は同じ手順を試すことができます。

一方で、「画像がおかしいです」だけでは、どの画像なのか、どの画面なのか、何をしたら起きたのかが分かりません。

不具合報告は、単なる不満の表明ではなく、問題を解決するための情報共有です。そのため、できるだけ「何が」「どこで」「どのように」起きているのかを整理して伝えることが重要です。

まず「何が起きているのか」を具体的にする

最初に確認したいのは、発生している現象を具体的に説明できるかどうかです。

例えば、次のように書けると分かりやすくなります。

• 投稿編集画面で画像ブロックを追加すると、保存後に画像が表示されない
• 固定ページを更新しても、公開画面に変更内容が反映されない
• 特定のプラグインを有効化すると、管理画面に入れなくなる
• スマホ表示だけで、見出しの文字サイズが大きく崩れる
• お問い合わせフォームの送信ボタンを押しても反応しない

反対に、次のような書き方では原因を調べにくくなります。

• WordPressが壊れました
• うまく動きません
• 表示がおかしいです
• 何か変です

報告するときは、できるだけ次の3つを意識するとよいでしょう。

• 1つ目は「何をしたか」。
• 2つ目は「何が起きたか」。
• 3つ目は「本来どうなってほしかったか」です。

例えば、以下のように書いていただくと、問題の内容がかなり伝わりやすくなります。

不具合が起きている場所を確認する

次に、不具合がどこで起きているのかを確認します。

WordPressでは、同じ「表示がおかしい」という現象でも、発生場所によって原因が変わります。

例えば、次のような違いがあります。

そのため、報告時には、以下のように、発生場所を具体的に書くとよいでしょう。

• 「投稿編集画面のみで発生しています」
• 「公開画面では正常ですが、編集画面では崩れています」
• 「スマホのSafariでのみ確認しています」

いつから発生したかを思い出す

不具合がいつから起きたのかも重要です。特に、直前に行った操作や変更が原因になっていることがあります。

確認したいのは、次のような点です。

「何もしていないのに壊れた」と感じる場合でも、自動更新が行われていたり、サーバー側で設定変更があったりすることがあります。

特に、次のタイミングでは不具合が起きやすくなります。

• WordPress本体のアップデート後
• テーマのアップデート後
• プラグインのアップデート後
• PHPバージョン変更後
• キャッシュ系プラグインの設定変更後
• セキュリティ系プラグインの導入後
• サーバー側のWAF設定変更後

WAFとは、Web Application Firewallの略です。Webサイトへの攻撃を防ぐ仕組みですが、まれにWordPressの通常操作を誤ってブロックすることがあります。

不具合報告では、以下のように書けると、原因を探しやすくなります。

• 「〇月〇日のアップデート後から発生しています」
• 「プラグインAを有効化した直後から発生しました」
• 「PHPを8.1から8.2に変更したあとに発生しました」

再現手順を整理する

不具合報告で特に大切なのが、再現手順です。再現手順とは、同じ不具合をもう一度起こすための操作手順のことです。

例えば、次のように書きます。

1. WordPress管理画面にログインする
2. 投稿一覧を開く
3. 任意の記事を編集する
4. 画像ブロックを追加する
5. 更新ボタンを押す
6. 公開画面を確認すると、画像が表示されない

このように書くと、報告を受けた側も同じ操作を試すことができます。

もし毎回発生しない場合でも、分かる範囲で構いません。以下のような情報も、原因特定につながることも少なくありません。

• 「毎回ではありませんが、投稿を更新した直後に発生することがあります」
• 「スマホ表示でのみ、数回に1回レイアウトが崩れます」
• 「キャッシュ削除直後は正常ですが、しばらくすると再発します」

完全に再現できない不具合でも、発生しやすい条件が分かれば、調査の助けになります。

WordPress・テーマ・プラグインのバージョンを確認する

不具合報告では、環境情報も重要です。最低限、次の情報は確認しておきたいところです。

ここで注意したいのは、「最新版です」とだけ書かないことです。「最新版」という言葉は、見るタイミングによって意味が変わります。報告する時点では最新版でも、数日後には新しいバージョンが出ているかもしれません。

そのため、「WordPress 6.8.2」「テーマ 15.3.1」「プラグイン 2.4.0」のように、具体的なバージョン番号を書く方が親切です。

プラグインの影響を確認する

WordPressの不具合では、プラグイン同士の相性が原因になることがあります。特に影響が出やすいのは、次のようなプラグインです。

キャッシュとは、表示を速くするために保存された一時データのことです。便利な仕組みですが、古いデータが残ることで、変更内容が反映されなかったり、表示崩れの原因になったりすることがあります。

不具合報告前には、可能であれば次のような確認をしておくとよいでしょう。

• 最近追加したプラグインを停止してみる
• 最近更新したプラグインを確認する
• キャッシュ系プラグインを一時停止してみる
• 最適化系プラグインを一時停止してみる
• セキュリティ系プラグインのブロック履歴を確認する
• どのプラグインを停止すると直るか確認する

ただし、公開中のサイトでプラグインを一気に停止すると、表示や機能に影響が出ることがあります。不安な場合は、検証用サイトやステージング環境で試すのが安全です。ステージング環境とは、本番サイトとは別に用意するテスト用サイトのことです。

テーマを変更して再現するか確認する

テーマが原因かどうかを確認するには、一時的にWordPress公式の標準テーマ（「Twenty Twenty-Five」など）に変更してみる方法があります。

標準テーマに変更して不具合が発生しない場合は、現在使っているテーマ側の仕様や不具合、またはテーマとプラグインの相性が関係している可能性があります。

一方で、標準テーマでも同じ不具合が出る場合は、WordPress本体、プラグイン、サーバー、ブラウザなど、別の原因を疑うことになります。ただし、公開中のサイトでテーマを変更すると、デザインや表示が大きく変わります。

本番サイトで試す場合は注意が必要です。できれば、検証用サイトで試しましょう。

キャッシュを削除して確認する

表示崩れや変更内容が反映されない問題では、キャッシュが原因になっていることがあります。確認したいキャッシュには、次のようなものがあります。

CDNとは、画像やCSSなどのファイルを高速に配信する仕組みのことです。便利ですが、古いデータが残っていると、修正内容がすぐに反映されないことがあります。

不具合報告の前には、以下のような確認をしておくとよいでしょう。

• キャッシュプラグインのキャッシュを削除する
• ブラウザのキャッシュを削除する
• シークレットウィンドウで確認する
• 別ブラウザでも確認する
• CDNを使っている場合はCDN側のキャッシュも削除する

報告時には、以下のように書くと、相手が判断しやすくなります。

• 「キャッシュ削除済みです」
• 「シークレットウィンドウでも同じ現象でした」
• 「ChromeとSafariの両方で確認しました」

ブラウザや端末を変えて確認する

不具合がWordPress側ではなく、ブラウザや端末側に関係していることもあります。

例えば、以下のようなケースです。

• Chromeでは発生するが、Safariでは発生しない
• PCでは正常だが、スマホでは崩れる
• 自分の端末だけで発生する
• 通常ウィンドウでは発生するが、シークレットウィンドウでは発生しない

他にも、ブラウザ拡張機能、広告ブロッカー、セキュリティソフト、VPNなどが影響することもあります。具体的には広告ブロッカーがJavaScriptを止めていたり、セキュリティソフトが通信をブロックしていたりする場合があります。

報告時には、以下のように記載いただくと、原因の切り分けに役立ちます。

• 「Chromeでは発生しますが、Safariでは発生しません」
• 「PCでは正常ですが、iPhoneのSafariで崩れます」
• 「シークレットウィンドウでも同じでした」
• 「広告ブロッカーを無効にしても同じでした」

エラーメッセージを確認する

画面にエラーメッセージが出ている場合は、できるだけ記録しておきましょう。

例えば、次のようなものです。

• Fatal error
• Warning
• Notice
• 500 Internal Server Error
• 403 Forbidden
• 404 Not Found
• REST API error
• JavaScript console error

エラーメッセージは、原因を調べるための重要な手がかりです。特に、プラグイン名、テーマ名、ファイル名、行番号が表示されている場合は役立ちます。

ただし、エラー文にはサーバーのパスやユーザー名など、公開したくない情報が含まれることがあります。例えば、次のような表示です。

/home/example/example.com/public_html/wp-content/plugins/sample-plugin/sample.php

公開の場に投稿する場合は、以下のように必要に応じて一部を伏せても構いません。

/home/****/public_html/wp-content/plugins/sample-plugin/sample.php

ただし、原因調査に必要なプラグイン名、テーマ名、ファイル名、行番号は、できる範囲で残しておくとよいでしょう。

開発者ツールも確認できると便利

少し慣れている方であれば、ブラウザの開発者ツールも確認しておくと便利です。開発者ツールとは、WebページのHTML、CSS、JavaScript、通信状況などを確認できるブラウザの機能です。

特に見ることが多いのは、次の2つです。

Consoleに赤いエラーが出ている場合は、JavaScriptの不具合や読み込み失敗が関係しているかもしれません。Networkで404や403が出ている場合は、必要なファイルが読み込めていない可能性があります。

ただし、開発者ツールの内容は初心者には難しく感じるかもしれません。分からない場合は、エラー画面のスクリーンショットを添付するだけでも十分に役立ちます。

サーバー側の設定も確認する

WordPressの不具合は、サーバー側の設定が原因になることもあります。

確認したい項目は次の通りです。

特に、投稿の保存時に403エラーが出る場合や、特定のコードを入力すると保存できない場合は、WAFが関係している可能性があります。また、画像URLにhttpとhttpsが混在している場合は、SSL設定や過去のURL設定が関係していることもあります。

不具合の内容によっては、テーマやプラグインの開発元ではなく、サーバー会社へ相談した方が早い場合もあります。

それは本当に不具合か、仕様かを確認する

自分では不具合だと思っていても、実はWordPressやテーマの仕様であることもあります。仕様とは、そのように動くことを前提として作られている挙動のことです。

例えば、次のようなケースがあります。

• ブロックテーマでは従来のウィジェット画面が使えない
• クラシックテーマとブロックテーマで編集方法が違う
• 管理者以外には一部メニューが表示されない
• テーマによって画像の回り込み表示が違う
• パスワード保護ページでも一部情報が出力される
• キャッシュが有効な場合、変更内容がすぐ反映されない

WordPressは、テーマやプラグインによってできることが大きく変わります。そのため、報告前に公式ドキュメント、テーマのマニュアル、プラグインの説明、既存のサポート投稿などを確認しておくとよいでしょう。

既知の不具合がないか確認する

すでに同じ不具合が報告されている場合もあります。

確認先としては、次のような場所があります。

GitHubでは、Issueという形で不具合や改善提案が管理されていることがあります。Issueとは、開発者向けの「不具合報告」や「改善提案」の記録のようなものです。

すでに同じIssueがある場合は、新しく報告するよりも、以下のような追加情報を伝える方が役立つこともあります。

• 「自分の環境でも再現しました」
• 「この条件でも発生しました」
• 「このバージョンではまだ発生しています」

スクリーンショットや動画を用意する

文字だけでは伝わりにくい不具合もあります。その場合は、スクリーンショットや短い動画がとても有効です。

特に、次のような不具合では画像や動画が役立ちます。

• レイアウト崩れ
• ボタンが表示されない
• 編集画面の挙動がおかしい
• スクロールすると表示が崩れる
• スマホだけで発生する
• クリックしても反応しない

動画は長くする必要はありません。10〜30秒程度で、操作と現象が分かれば十分です。

ただし、スクリーンショットや動画には、管理画面URL、メールアドレス、ユーザー名、アクセス解析情報などが映り込むことがあります。公開の場に投稿する場合は、個人情報や機密情報が映っていないか必ず確認しましょう。

「試したこと」を整理しておく

不具合報告では、すでに試したことを書くのも大切です。

• キャッシュを削除した
• 別ブラウザで確認した
• スマホとPCの両方で確認した
• シークレットウィンドウで確認した
• プラグインを停止して確認した
• 標準テーマに変更して確認した
• PHPバージョンを確認した
• サーバーのWAFログを確認した
• エラーログを確認した

上記のように試したことを書いておくと、相手が同じ確認を繰り返さずに済みます。

例えば、次のようにまとめると分かりやすいです。ここまで書けると、かなり調査しやすい報告になります。

報告先を間違えないことも大切

WordPressの不具合は、原因によって相談先が変わります。

例えば、特定のテーマでだけ表示が崩れる場合、WordPress本体の不具合として報告しても解決しにくいことがあります。逆に、標準テーマでも発生し、プラグインを停止しても起きる場合は、WordPress本体側の問題かもしれません。

不具合の原因を完全に特定する必要はありませんが、できる範囲で切り分けておくと、適切な相談先を選びやすくなります。

不具合報告に使えるテンプレート（一例）

不具合報告では、次のテンプレートを使うと整理しやすくなります。

悪い報告例と良い報告例

最後に、報告例を見てみましょう。

悪い報告例

悪い報告例は、次のようなものです。

この書き方では、何が起きているのか、どの環境なのか、どの操作で発生するのかが分かりません。

良い報告例

一方で、次のように書くと、相手が調査しやすくなります。

このような報告であれば、開発者やサポート担当者も状況を理解しやすくなります。

POINT: 感情的になりすぎず、事実を中心に伝える

不具合が起きると焦りますし、サイト運営や仕事に影響が出る場合は、困るのも当然です。ただし、報告時にはできるだけ事実を中心に伝える方が、解決につながりやすくなります。

例えば、次のような書き方です。

このように書けば、困っている状況を伝えつつ、冷静な報告になります。

一方で、「最悪です」「ありえません」「すぐ直してください」といった表現だけでは、相手も原因調査に集中しにくくなります。

不具合報告は、相手を責めるためではなく、問題を解決するために行うものです。冷静に、具体的に、事実を整理して伝えることが大切です。

不具合報告前のチェックリスト

最後に、不具合報告前に確認したい項目をまとめます。

基本情報

• WordPressのバージョンを確認した
• テーマ名とテーマバージョンを確認した
• 子テーマの有無を確認した
• PHPバージョンを確認した
• サーバー名を確認した
• ブラウザと端末を確認した

現象の整理

• 何が起きているか説明できる
• 期待していた動作を書ける
• 発生場所を確認した
• 発生頻度を確認した
• 再現手順を書ける

切り分け

• キャッシュを削除した
• 別ブラウザで確認した
• スマホとPCで比較した
• シークレットウィンドウで確認した
• 関係しそうなプラグインを停止した
• 標準テーマで確認した
• サーバー側のWAFやPHP設定を確認した

証拠の用意

• エラーメッセージを控えた
• スクリーンショットを用意した
• 必要であれば動画を用意した
• 個人情報が映っていないか確認した

まとめ：不具合報告は「原因探しを助けるための情報共有」

WordPressで不具合が起きたときは、すぐに報告したくなるかもしれません。

もちろん、深刻な不具合であれば早めに相談することも大切です。ただ、その前に少しだけ状況を整理しておくと、解決までの時間を大きく短縮できます。

不具合報告で大切なのは、次の3つです。

• 何が起きているのかを具体的に書く
• どの環境で起きているのかを書く
• どうすれば再現できるのかを書く

この3つがそろっているだけで、報告の質は大きく上がります。

WordPressの不具合は、WordPress本体、テーマ、プラグイン、サーバー、ブラウザ、キャッシュなど、さまざまな要素が関係します。だからこそ、落ち着いて情報を整理することが大切です。

丁寧な不具合報告は、開発者やサポート担当者にとっても大きな助けになります。そして結果的に、自分自身の問題解決も早くなります。

不具合報告は、クレームではなく、問題を解決するための共同作業です。相手が調べやすい形で情報を伝えることを意識して、落ち着いて報告していきましょう。

WordPress 7.0では、新しいリビジョン画面である「ビジュアルリビジョン」が導入されました。従来のテキスト中心のリビジョン画面とは異なり、実際の投稿に近い見た目で変更点を確認できる機能として期待されています。

しかし、開発中に見つかったある不具合により、一部の環境ではビジュアルリビジョンが自動的に無効化される仕様となりました。一見すると「新機能を制限しただけ」のようにも見えますが、実際にはユーザーのデータを守るための重要な設計判断でした。

この記事では、実際のGitHub上のやり取りをもとに、WordPress開発者が知っておきたいポイントを整理します。

「ビジュアルリビジョン」とは（おさらい）

WordPressにおいてはリビジョン機能がありますが、従来はテキスト中心の比較でした。クラシックエディター時代はそれでも十分だった時期もあったようです。

ブロックエディター（Gutenberg）時代になると、画像やブロック構造等の視覚的変更の度合いが圧倒的に増えていきました。一方で、従来のリビジョン比較では、コードばかりが表示され、変更点が分かりにくいことがありました。

7.0では「ビジュアルリビジョン」の仕組みが導入され、視覚的な差分確認がしやすくなり、誤編集の発見が容易になりました。

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

WP Pilot

本題：バグ報告と対策の顛末

GitHub上の記録

• Visual Revisions fail to restore meta controlled by Classic Meta Boxes · Issue #78130 · WordPress/gutenberg
• Editor: Disable Visual Revisions when classic meta boxes are present by ellatrix · Pull Request #78249 · WordPress/gutenberg

Issue #78130 で見つかった問題

問題となったのは、ビジュアルリビジョンから投稿を復元した際の挙動です。

例えば、投稿に次のような情報が保存されていたとします。

• 投稿本文
• ブロックの内容
• ブロックエディターのサイドバーで管理しているメタデータ
• 旧仕様のメタボックスで管理しているカスタムフィールド

ビジュアルリビジョン経由で過去のリビジョンへ戻すと、以下のような結果になっていました。

つまり、「投稿本文は昔の状態なのに、カスタムフィールドだけ最新のまま」という、一部だけ復元されない状態になってしまいます。これはユーザーから見ると非常に分かりにくく、データの整合性を損なう恐れがあります。

PR #78249 で行われた対応

この問題に対し、今回のPRでは復元処理そのものを修正するのではなく、ビジュアルリビジョンを無効化するという対応が採られました。

具体的には以下のようなフローになっています。

旧仕様のメタボックスが存在するか確認
        │
        ├─ ない
        │      ↓
        │  ビジュアルリビジョンを使用
        │
        └─ ある
               ↓
      従来のRevision画面へ切り替える

つまり、旧仕様のメタボックスが一つでも登録されている投稿では、新しいビジュアルリビジョンは利用されません。

開発チームが優先したもの

今回のPRでは、開発チームが最優先したのは「新機能」ではなく「データの安全性」でした。

もしビジュアルリビジョンをそのまま公開すると、利用者は「リビジョンを復元した」と思っていても、実際には「SEO設定」「カスタムフィールド」「独自プラグインの設定」などが最新値のまま残る可能性があります。これは非常に危険です。

そこで、「完全に対応できるまでビジュアルリビジョンは使わせない」という方向性で進められることとなりました。品質を重視した決断と言えるでしょう。

なぜ「修正」ではなく「無効化」だったのか

一見すると「そのままバグを修正すればよいのでは？」と思うかもしれません。

しかし、この問題は見た目以上に難しいものです。

投稿本文とメタデータは別管理

WordPressでは、投稿本文とpost_metaは別々に保存されています。さらに、旧仕様のメタボックスは、save_postなどPHP側の処理で自由に保存できます。

一方、ブロックエディター側のメタは「REST API」を通して管理されています。

つまり、旧仕様のメタボックスは「PHP」ベース、ビジュアルリビジョンは「REST API」ベース、という異なる仕組みの上で動いています。

保存処理がプラグインごとに異なる

さらに難しいのは、旧仕様のメタボックスでは、以下のような様々な処理が実現できるという点です。

• 独自バリデーション
• 独自保存処理
• 独自の権限チェック
• 独自フック

つまり、旧仕様のメタボックスと一言で言っても、実際には何千通りもの保存方法があります。あまりに複雑すぎるため、ビジュアルリビジョン側ですべて再現するのは容易ではありません。

補足：なぜ従来のリビジョン画面なら動くのか

従来のリビジョン画面では、WordPressコアが以前から提供している「メタデータの復元処理」「リビジョン管理API」が利用されています。

長年運用されてきた仕組みであり、旧仕様のメタボックスとの互換性も考慮されています。そのため、従来のリビジョンでは問題なく復元できます。

今後の開発における影響など

プラグイン開発への影響

今回の変更で影響を受ける可能性があるのは、1つには、旧仕様のメタボックスを利用しているプラグインです。

例えば、「SEOプラグイン」「カスタムフィールド系プラグイン」「独自管理画面を持つプラグイン」などを有効化している場合、ビジュアルリビジョンではなく従来のリビジョン画面が表示される場合があります。

これは不具合ではなく、安全のための仕様です。

テーマ開発への影響

テーマでも、functions.phpなどでadd_meta_box()を利用している場合は同様です。

例えば、「SEO入力欄」「OGP設定」「サムネイル補助設定」「ランディングページ用設定」などを旧仕様のメタボックスとして実装している場合、ビジュアルリビジョンは利用できません。

将来的にはどうなるのか

WordPressは現在、REST APIを中心としたデータ管理へ少しずつ移行しています。

カスタムフィールドもregister_post_meta()で登録し、show_in_rest => trueを設定することで、ブロックエディターとの親和性が高まります。

もちろん、旧仕様のメタボックスがすぐに廃止されるわけではありません。しかし、今後の新機能はREST APIを前提に設計されるケースが増えると考えられます。

そのため、特に新規の開発においては、「REST API」「ブロックエディター（Gutenberg）」「Entity API」などを意識した設計が望ましいでしょう。

このPRから学べること

「PR #78249」は単なるバグ修正ではありません。WordPressコア開発チームが「新機能よりもデータの正確性を優先する」という姿勢を示した事例と言えます。

開発者としては、次のような点を意識するとよいでしょう。

• ビジュアルリビジョンは、旧仕様のメタボックスとの完全な互換性が保証されるまでは利用が制限される場合がある。
• 旧仕様のメタボックスを使用している場合、従来のリビジョン画面へ自動的に切り替わるのは正常な挙動である。
• 新規開発では、register_post_meta()やshow_in_restを活用し、REST APIを前提とした設計を検討すると将来の互換性を高めやすい。
• 新しいエディター機能を利用する際は、「投稿本文だけでなくメタデータも正しく保存・復元されるか」という観点でテストを行うことが重要である。

おわりに

WordPressは後方互換性を非常に重視するCMSですが、新しいブロックエディター関連機能の開発では、従来の仕組みとの橋渡しが大きな課題となっています。

「PR #78249」は、その橋渡しが完全に実現するまでの「安全策」として実装されたものです。新機能を無理に提供するのではなく、データの信頼性を最優先に考えるというWordPressコアチームの設計思想を理解するうえで、非常に参考になる事例と言えるでしょう。

参考情報：事象が起こるプラグイン・テーマ（一例）

プラグインの一例

• SEO SIMPLE PACK
• Easy Table of Contents
• Snow Monkey Blocks

テーマの一例

• Xwrite
• echo（旧THE SONIC）
• Cocoon

WordPressを使っていると、やがて「PHP（ピーエイチピー）」という言葉を目にするようになります。

• functions.php にコードを追加する
• テーマをカスタマイズする
• プラグインを開発する
• エラー内容を確認する

こうした場面ではPHPの知識が役立ちます。

しかし、WordPressユーザーの中には「PHPってプログラマー向けの難しいものでは？」と感じる方も少なくありません。

確かにPHPはプログラミング言語ですが、一般の利用者にとってはWordPressを利用する上で必要なのは専門家レベルの知識ではありません。

まずは、「WordPressはPHPで動いている」ということを理解するだけでも十分なスタートです。

この記事では、WordPress初心者向けにPHPの基礎中の基礎知識を分かりやすく解説します。

PHPとは何か

PHPはWebサイトを動かすためのプログラミング言語です。

正式には「PHP: Hypertext Preprocessor」という名称ですが、覚える必要はありません。重要なのは、「WordPressを動かしている言語」であることです。

例えば、あなたが投稿した記事は、単なるHTMLファイルとして保存されているわけではありません。

WordPressは、大まかには以下のような流れで動作しています。

1. データベースから記事情報を取得
2. PHPが内容を組み立てる
3. HTMLを生成
4. ブラウザへ表示

つまりPHPは、WordPressの裏側で働くエンジンのような存在です。

WordPressとPHPの関係

WordPressはPHPで作られています。

コアファイルを見ると、

• index.php
• wp-config.php
• functions.php
• single.php
• archive.php

など、多くのPHPファイルが存在します。

例えば、以下のようなコードがあります。

<?php the_title(); ?>

これは「記事タイトルを表示する」という意味です。

記事タイトルが「WordPress初心者ガイド」となっている場合、ブラウザ上では、例えば以下のように表示されます。

WordPress初心者ガイド

つまり、PHPが実際に見える内容を生成・出力しているということです。

PHPを学ぶと何ができるのか

処理内容を理解できる

WordPressのカスタマイズ記事でよく登場するのがadd_action()やadd_filter()です。

PHPの基礎が分かれば、「なぜこのコードを書くのか」を理解しやすくなります。

エラーの意味が分かる

WordPressでは時々、Fatal errorやParse errorなどのエラーが表示されます。

PHPを全く知らないと、何が起きているのか分かりません。

しかし基本を知っていれば、

• セミコロン忘れ
• 括弧の閉じ忘れ
• スペルミス

などを見つけやすくなります。

テーマをカスタマイズできる

例えば、

• 記事下に広告を表示
• カテゴリーごとに表示変更
• 特定ページだけデザイン変更

などもPHPで制御できます。

プラグイン開発・ブロック作成の第一歩になる

初心者のうちは不要ですが、将来的に「自分専用の機能を作りたい」と思ったときにPHPの知識が役立ちます。

また、WordPress 7.0 以降では、PHPの知識のみで独自ブロックを作成することも可能になっています。

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

WP Pilot

PHPとHTMLの違い

初心者が混乱しやすいポイントです。

HTML

ページの構造を主に担当しています。

<h1>タイトル</h1>
<p>本文</p>

以下の記事でも詳しく紹介しています。

WordPress初心者が知っておきたいHTMLタグまとめ

WP Pilot

PHP

WordPress上での実際の処理を行っています。

<?php
echo "タイトル";
?>

WordPress上での扱い

WordPressでは両方が混在しています。

例えば、以下の記述があったとします。

<h1><?php the_title(); ?></h1>

これは以下のような内容を生成しています。

<h1>記事タイトル</h1>

PHPにおける初歩の初歩

ここからは初心者向けに最低限知っておきたい内容を紹介します。

PHP開始・終了タグ

PHPは<?phpから始まります。

<?php
echo "Hello";

なお、終わりは ?> となっております。文末までPHPの記述が続く場合のみ、終わりの記号は省略可能です（初心者の方は、このような例外はあまり気にする必要はありません）。

echo

文字等を表示します。WordPressでも頻繁に登場します。

echo "こんにちは";
// 「こんにちは」と出力されます。

セミコロン

PHPでは命令の最後にセミコロン記号「;」を付けます。

echo "Hello";

この「;」の記述を忘れるとエラーになります。

変数

変数とは、データを入れておく箱です。

$name = "田中";

上記のように記載することで$nameに「田中」が保存されます。

表示するには以下のように記載します。

echo $name; // 「田中」と出力されます。

条件分岐（if文）

「もし○○なら」という処理です。

if ( 1 == 1 ) {
	echo "正しい";
}
// 上記の例では、「正しい」と出力されます。

WordPressではよく使われます。例えば、以下の例ではトップページにおいて「トップページです」と表示されます。

if ( is_home() ) {
	echo "トップページです";
}

繰り返し処理（ループ）

同じ処理を何度も実行します。

for ( $i = 1; $i <= 5; $i++ ) {
	echo $i;
}
// 上記の例では、「12345」と出力されます。

配列

複数のデータをまとめて保存します。

$fruits = array(
	"りんご",
	"みかん",
	"バナナ"
);

// 実行例。「りんご」という文字が出力されます。
echo $fruits[0];

関数

処理をひとまとめにしたものです。

function hello() {
	echo "こんにちは";
}

// 実行例。「こんにちは」という文字が出力されます。
hello();

WordPressは関数の集合体とも言えます。例えば、以下の1つ1つも関数です。

the_title()
the_content()
get_header()

WordPressで特によく見るPHP

add_action()

処理を追加します。以下の例では、フッターに「テスト」の文字が表示されます。

add_action(
	'wp_footer',
	function() {
		echo 'テスト';
	}
);

add_filter()

データを加工します。以下の例では、タイトルの前に★を付与できます。

add_filter(
	'the_title',
	function( $title ) {
		return '★' . $title;
	}
);

get_template_part()

テンプレート等の部品を読み込みます。テーマ開発でよく使われます。

get_template_part( 'template-parts/content' );

PHPを学ぶなら何を優先すべきか

WordPressユーザーの場合、すべてを学ぶ必要はありません。

まず始めに覚えておくべきものとしては、以下の7点で十分です。

1. 変数
2. 配列
3. if文
4. 関数
5. ループ
6. add_action
7. add_filter

何よりもまず、コードの意味を読めるようになることを目標にしましょう。

初心者がやりがちな失敗例

親テーマのfunctions.phpを編集する

親テーマのfunctions.phpを直接編集すると、テーマ更新時に消える可能性があります。

基本的には「子テーマ」や「Code Snippetsなどのプラグイン」などを利用しましょう。

コピペだけで理解した気になる

ネット上には大量のPHPコードがあります。当ブログでもサンプルコードがしばしば掲載されております。しかし、add_filter()やreturnなどの意味を理解せずに貼り付けるとトラブルになります。

最低限、「何をするコードか」「どこに影響するか」は確認しましょう。

セミコロンの付け忘れ・括弧の閉じ忘れ

セミコロンの付け忘れがエラーの原因になる旨については上記で説明しましたが、それ以外にも括弧の閉じ忘れもよくあるエラー要因でございます。

いざ記述する際は、丁寧かつ正確に進めることを心がけましょう。

本番環境で試す

PHPの記述ミスはサイト停止につながる場合があります。

可能であれば「テストサイト」や「ローカル環境」で試すことをおすすめします。

【余談】AI時代でもPHPを学ぶ価値はあるのか

昨今は生成AIの発達により、「コードを書けなくても大丈夫では？」と言われることがあります。

確かにAIはPHPコードを生成できます。しかし、以下のような対応を行おうと思えば、基礎知識が必要です。

• コードが正しいか判断する
• セキュリティ上問題ないか確認する
• エラーを修正する

特にWordPress運営者の場合、PHPを深く極める必要はありませんが、「コードを読める」状態になっておく価値は非常に高いでしょう。

【雑談】生成AIを使った「パイプコーディング」の是非を問うのではなく、その姿勢こそ大事

WP Pilot

まとめ

PHPはWordPressの心臓部とも言える存在です。

初心者のうちはプログラマーになる必要はありませんが、少なくとも以下の点を理解しておくと、WordPressの理解が大きく深まります。

• PHPはWordPressを動かしている言語
• HTML（ひいてはページ）を生成する元になる
• functions.phpでよく使われる
• add_action()やadd_filter()が重要
• まずはコードを読めるようになることが目標

WordPressを長く使う予定であれば、PHPは避けて通れない知識です。しかし、最初から難しい参考書を読む必要はありません。まずは簡単なコードを読みながら、「この処理は何をしているのだろう？」と考える習慣を付けることから始めてみましょう。それだけでも、テーマやプラグインのカスタマイズに対する理解が大きく変わってくるはずです。

WordPressを使い始めたばかりの方の中には、「英語が苦手だから海外の情報は難しい」と感じている方も多いのではないでしょうか。

実際、WordPressそのものは日本語化されていますが、テーマやプラグインの開発、公式ドキュメントの閲覧、不具合調査などを行うようになると、英語に触れる機会が一気に増えてきます。

しかし安心してください。WordPressで必要になる英語は、英会話のような高度な英語力ではありません。むしろ「よく使われる単語の意味を知っているかどうか」の方が重要です。

この記事では、WordPressの開発や公式マニュアルを読む際によく登場する英単語や表現を、初心者にも分かりやすく解説します。

なぜWordPressでは英語が重要なのか

WordPressは世界中で利用されているCMS（コンテンツ管理システム）です。

そのため、

• 公式ドキュメント
• GitHub
• プラグインの開発資料
• エラーメッセージ
• ソースコードのコメント
• 海外フォーラム

など、多くの情報が英語で提供されています。特に不具合対応では、日本語情報よりも英語情報の方が早く公開されることも珍しくありません。

また、WordPressの関数名や設定項目も英語ベースで作られているため、単語の意味が分かるだけで理解しやすさが大きく変わります。

一般利用者でも知っておきたい単語

基本的なコンテンツ関連用語

テーマ関連でよく見る単語

ブロックエディター関連用語

開発者が必ず覚えたい英単語

ここから先は、開発やカスタマイズで特に重要な単語です。

テーマ・プラグイン開発時にも頻出

データベース関連

エラー対応で覚えておきたい単語

セキュリティ関連で重要な単語

WordPress公式ドキュメントで頻出する表現

まずはこの20語から覚えよう

すべてを一度に覚える必要はありません。まずは以下の20語を理解するだけでも、WordPress公式ドキュメントや海外記事の理解度は大きく向上します。

• Post / Page / Category / Tag
• Theme / Plugin / Block / Template
• Register / Enqueue / Hook / Action
• Filter / Query / Retrieve / Output
• Render / Sanitize / Escape / Deprecated

特に抑えておきたい7単語

特に以下の7語は、WordPressのソースコードや開発資料を読む際に何度も登場します。

• Register
• Enqueue
• Query
• Retrieve
• Render
• Sanitize
• Escape

これらの意味を覚えるだけでも、英語のドキュメントに対する苦手意識はかなり減るでしょう。

まとめ

WordPressを使い続けていると、いずれ英語のドキュメントやエラーメッセージに触れる機会がやってきます。

とはいえ、必要なのは高度な英語力ではありません。まずはWordPressで頻繁に登場する単語の意味を理解し、「この単語は何を指しているのか」を把握することが大切です。

英単語が分かるようになると、公式ドキュメント、GitHub、海外フォーラムなどから情報を収集できるようになり、WordPressの理解がさらに深まります。

WordPressをより便利に活用するためにも、少しずつ英語表現に慣れていきましょう。

最近は、「note」「はてなブログ」「Wix」「STUDIO」「Shopify」など、手軽にWebサイトを作れるサービスが増えました。

そんな時代、「WordPressは難しそう」「もう時代遅れでは？」と思う方もいるかもしれません。

しかし実際には、多くの企業サイトやメディアサイトでWordPressが利用され続けています。それは、便利なサービスが増えた現代だからこそ、WordPressの強みがより際立っているからです。

WordPressをオススメする理由

1. 自分の資産としてサイトを持てる

最大の魅力はここです。

SNSや無料ブログは運営会社のサービスを借りています。そのため、「サービス終了」「規約変更」「アカウント停止」「広告表示の変更」などの影響を受ける可能性があります。

一方、WordPressは自分で契約したサーバー上で運営できます。つまり、「サイトそのものが自分の資産」になります。

家を借りるのではなく、自宅を持つイメージです。

注意

上記はあくまでもWordPress.comを利用しない場合においてです。

一般的なWordPressと「WordPress.com」の違いは以下の記事をご覧ください。

WordPress.com と WordPress.org の違いとは

WP Pilot

2. ブログから企業サイトまで対応できる

多くのサービスは、以下のように用途が決まっています。

• note・はてなブログ → 記事投稿向け
• Shopify → EC向け
• Wix・STUDIO → （どちらかと言えば）ランディングページ向け

しかしWordPressは、「ブログ」「コーポレートサイト」「オウンドメディア」「採用サイト」「会員サイト」「ネットショップ」など様々な用途に対応できます。

将来的な拡張性が非常に高いのです。

3. サービスの乗り換えが比較的自由

意外と見落とされるメリットです。

特定サービスでは、「データ移行が難しい」「デザイン・機能が引き継げない」「URLが変わる」という問題があります。

一方、WordPressは世界標準のCMSです。そのため、サーバー移転・プラグイン変更などが比較的容易です。長期間運営するほど、このメリットは大きくなります。

4. SEO・検索エンジンとの相性が良い

SEOとは、検索エンジンで見つけてもらいやすくする取り組みのことです。

WordPressは元々コンテンツ管理を目的として作られているため、「記事管理」「カテゴリー管理」「タグ管理」「URL管理」などが行いやすくなっています。また、多くのSEO関連ツールやプラグインも利用できます。

検索からの集客を考える場合、非常に有力な選択肢です。

5. 世界中の開発者・利用者が支えている

WordPressは一企業の商品ではありません。オープンソース環境のもと、世界中の開発者や企業が開発に参加しています。そして、多くの利用者からのフィードバックにより日夜改善が図られています。

このように開発者や利用者が多いので、「情報量が多い」「解説記事が豊富」「学習しやすい」などのメリットもあります。

困ったときに調べやすいのは大きな強みです。

6. AI時代との相性も良い

最近は生成AIの進化によって、「記事作成」「画像生成」「コード作成」が容易になりました。

実のところ、AI時代だからこそWordPressとの相性は良くなっています。なぜなら、AIで作ったコンテンツを公開する「土台」が必要だからです。

WordPressは、「自由に記事を掲載できる」「デザインを変更できる」「機能を追加できる」などの特徴を持つため、AIを活用した情報発信の拠点として優秀です。

さらに、先月正式公開された WordPress 7.0 では、「ChatGPT」や「Gemini」などの生成AIとのコラボレーションも行いやすくなりました。これからは更にAI機能の強化も予定されています。

参考

WordPress 7.0で搭載された新機能については、以下の記事でまとめています。

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

WP Pilot

7. 「簡単さ」ではなく「自由度」が魅力

WordPressは確かに最も簡単なサービスではありません。サーバー契約や初期設定が必要です。

しかし、その一手間によって、「制限が少ない」「カスタマイズできる」「将来の選択肢が広い」などの大きなメリットを得られます。

どんなサービスでも言えることですが、いざ使い始めてみれば、案外取り越し苦労に終わることも少なくありません。WordPressのように幅が広く選択肢の豊富なシステムであれば、尚更です。

まとめ

便利なCMSやサイト作成サービスが増えた今でも、WordPressが選ばれ続ける理由は明確です。以下のメリットだけでも、選んでいただく価値があります。

• 自分の資産として運営できる
• 自由度が高い
• 将来の拡張性がある
• SEOに強い
• 情報が豊富
• AI時代とも相性が良い

もちろん、「とにかく簡単に始めたい」という方には、noteやWixのように他のサービスが向いている場合もあります。

しかし、「長く運営したい」「将来的に成長させたい」「自分の資産を作りたい」などとお考えの方にとって、WordPressは今なお有力な選択肢といえるでしょう。