WordPressで不具合報告をする前に確認しておきたいこと

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

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

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

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

報告前のチェック事項

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

発生場所	考えられる例
管理画面	投稿編集画面、外観、プラグイン一覧など
公開画面	訪問者が見る記事ページやトップページ
特定の記事だけ	ある投稿だけ表示が崩れる
固定ページだけ	トップページやお問い合わせページだけおかしい
スマホだけ	PCでは正常だが、スマホで崩れる
特定ブラウザだけ	Chromeでは正常だが、Safariで崩れる

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

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

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

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

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

確認項目	例
発生時期	今日から、昨日から、アップデート後から
直前の作業	プラグインを入れた、テーマを変更した
WordPress本体の更新	WordPressを新しいバージョンにした
テーマの更新	親テーマや子テーマを更新した
プラグインの更新	SEO、キャッシュ、セキュリティ系などを更新した
サーバー設定の変更	PHPバージョン、WAF、SSL設定などを変更した

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

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

• 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本体	WordPress 6.8、6.9、7.0など
使用テーマ	Lightning、SWELL、Cocoon、Twenty Twenty-Fiveなど
テーマのバージョン	15.0.0など
子テーマの有無	子テーマあり／なし
PHPバージョン	PHP 8.1、8.2、8.3など
サーバー	Xserver、ConoHa WING、ロリポップなど
ブラウザ	Chrome、Safari、Edge、Firefoxなど
端末	Windows PC、Mac、iPhone、Androidなど

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

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

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

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

プラグインの種類	影響しやすい理由
キャッシュ系	古いCSSやJavaScriptが残ることがある
最適化系	CSSやJavaScriptを圧縮・結合するため
セキュリティ系	通信や管理画面操作を制限することがある
ブロック追加系	編集画面や表示に影響することがある
SEO系	metaタグ、canonical、OGPなどに影響する
会員制・閲覧制限系	表示条件や権限に影響する

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

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

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

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

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

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

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

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

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

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

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

キャッシュの種類	例
ブラウザキャッシュ	ChromeやSafariに残る古いデータ
WordPressプラグインのキャッシュ	WP Fastest Cache、LiteSpeed Cacheなど
サーバーキャッシュ	レンタルサーバー側の高速化機能
CDNキャッシュ	Cloudflareなど
最適化プラグインのキャッシュ	Autoptimizeなど

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.phpCode language: PHP (php)

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

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

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

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

タブ	確認できること
Console	JavaScriptのエラー
Network	CSS、JavaScript、画像などの読み込み失敗

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

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

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

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

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

項目	影響すること
PHPバージョン	テーマやプラグインの動作
PHPメモリ上限	管理画面のエラー、処理失敗
WAF	投稿保存や通信のブロック
SSL設定	https/http混在、画像読み込み失敗
ファイル権限	アップロードや更新の失敗
データベース	保存や取得の不具合
サーバーキャッシュ	表示反映の遅れ

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

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

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

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

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

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

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

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

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

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

確認先	内容
WordPress公式フォーラム	WordPress本体やプラグインの相談
テーマ公式サイト	テーマ固有の不具合や仕様
プラグイン公式ページ	更新履歴やサポート情報
GitHub	開発中のIssueやPull Request
Xや個人ブログ	同じ現象の報告が見つかる場合もある

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

原因の可能性	主な相談先
WordPress本体	WordPress公式フォーラム、Core Trac、GitHub
テーマ	テーマ開発元、テーマ公式フォーラム
プラグイン	プラグイン開発元、WordPress公式サポート
サーバー	レンタルサーバーのサポート
ブラウザ	ブラウザ側の問題、拡張機能の確認
自作コード	制作者、開発者、制作会社

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

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

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

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

悪い報告例と良い報告例

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

悪い報告例

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

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

良い報告例

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

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

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

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

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

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

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

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

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

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

基本情報

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

現象の整理

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

切り分け

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

証拠の用意

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

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

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

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

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

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

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

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

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

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