本文へスキップ
WordPress エラー・不具合対処 ・ 2026年5月27日 ・ 読了11分

Query Monitor と WP Debuggingを徹底比較して選ぶ

WordPressのトラブルシューティングにおいて、Query MonitorとWP Debuggingは人気ですが、その違いを理解していますか?この記事では、最適なツール選びをサポートします。

この記事でわかること

  • Query Monitorの機能と使用方法
  • WP Debuggingの特徴と設定
  • 各ツールの選び方のポイント
  • 具体的な利用シーンでの活用方法

目次

  1. Query MonitorとWP Debuggingの基本機能
  2. Query Monitorの導入と使用法
  3. WP Debuggingの設定と活用
  4. 選び方のポイントと判断基準
  5. 動作確認とトラブルシューティング
  6. 実際のトラブル事例: カスタム投稿タイプの404問題
  7. まとめ

Query MonitorとWP Debuggingの基本機能

WordPressサイトのパフォーマンスを最適化するためには、効果的なデバッグツールが必要です。このセクションでは、多くのお客さまが利用しているプラグイン「Query Monitor」と「WP Debugging」の基本機能を紹介し、それぞれの特徴とメリットを理解していただければと思います。

Query Monitorは、開発者にとっての強力なデバッグツールとして知られています。このプラグインは、実行されたSQLクエリやPHPエラー、テンプレート階層、遅いフック、REST APIコールなど、サイトの内部で何が起きているのかを可視化することが可能です。特に、管理バーから直接性能サマリーを確認できるため、効率的に問題点を把握できます。

一方、WP Debuggingは、デバッグ定数を簡単に切り替えられる小型のプラグインです。通常、wp-config.phpを手動で編集しなければならないWP_DEBUGやWP_DEBUG_LOG、SCRIPT_DEBUG、SAVEQUERIESの定数を、プラグインのインターフェースを通じてオンオフできます。これは特に、コードに直接触れることが難しい方にとって非常に便利です。

両者の具体的な違い

Query MonitorとWP Debuggingの最大の違いは、その機能の範囲とアプローチです。Query Monitorは、サイトのあらゆる面を監視し、詳細な分析データを提供します。一方、WP Debuggingは、主に定数の設定を管理することに特化しています。

これにより、サイトのデバッグ作業がより柔軟に行えるようになります。弊社運用の70サイトのうち、Query Monitorを利用している事例も多く、問題の特定に貢献しています。

以下は、wp-config.phpにおけるWP_DEBUG設定のコード例です。手動で設定する場合、このように記述します。


// Enable WP_DEBUG mode
define('WP_DEBUG', true);

// Enable Debug logging to the /wp-content/debug.log file
define('WP_DEBUG_LOG', true);

// Disable display of errors and warnings 
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);

これらの設定をWP Debuggingを用いて管理すると、wp-config.phpを直接編集する手間を省くことができ、安全性が向上します。どちらのプラグインも、用途やスキルに応じて最適な選択をすることで、WordPressサイトのデバッグがより容易になります。

Query Monitorの導入と使用法

Query Monitorは、WordPressサイトのデバッグに不可欠なツールとして、多くの中級ユーザーに利用されています。このプラグインを使用することで、SQLクエリやPHPエラー、テンプレート階層の詳細などを容易に確認することが可能です。この記事では、Query Monitorのインストールから基本的な使用法までを詳しく説明します。

まずは、Query Monitorのインストール手順について説明します。『ダッシュボード > プラグイン > 新規追加』の順で進み、検索ボックスに「Query Monitor」と入力しましょう。「今すぐインストール」をクリックしてインストールを完了し、有効化します。有効化が完了すると、WordPressの管理バーに性能サマリーが表示されるようになります。

管理バーからの性能サマリーの見方

管理バーに表示される性能サマリーは、サイトのパフォーマンスをリアルタイムで監視するのに役立ちます。管理バーのQuery Monitorアイコンをクリックすると、詳細な情報がパネルとして表示されます。各タブをクリックすることで、『Queries』『PHP Errors』『Hooks』などの詳細情報にアクセスできます。

特に『Queries by Component』タブを利用することで、どのプラグインが遅延の原因となっているかを特定する手助けとなるでしょう。この便利な機能は、弊社が支援しているクライアントサイトでも効果が確認されており、大規模サイトの管理において強力なツールとなっています。

SQLクエリの具体的な確認方法

Query Monitorを使用すると、実行されたSQLクエリを具体的に確認することができます。管理バーのパネルから『Queries』タブを選択し、クエリの詳細を確認しましょう。ここでは、各クエリの実行時間や頻度、影響を受けたコンポーネントを一目で把握することができます。

例えば、以下のようなSQLが表示されることがあります。この情報は問題のトラブルシューティングに直接活用可能です。

SELECT * FROM wp_posts WHERE post_status = 'publish' AND post_type = 'post' ORDER BY post_date DESC;

このSQLクエリの例では、公開済みの投稿を取得するためのクエリが示されています。こうしたクエリの内容を確認することで、サイトのパフォーマンスチューニングにも役立ちます

WP Debuggingの設定と活用

WP Debuggingは、WordPressのデバッグ作業をシンプルにするための強力なツールです。特にwp-config.phpを直接編集することなく、WP_DEBUGやWP_DEBUG_LOGといった設定を管理しやすくしてくれます。このセクションでは、WP Debuggingをどのように設定し活用するかを詳しく解説します。

まず、WP Debuggingを使うためには、プラグインをインストールし、WP_DEBUGを有効化する必要があります。具体的には『ダッシュボード > プラグイン > 新規追加 > 検索ボックスに「WP Debugging」を入力 > 今すぐインストール → 有効化』と進みます。有効化した時点で、WP_DEBUGが自動的にオンになります。

デバッグ情報は基本的にはwp-content/debug.logファイルに出力されます。これはデバッグ作業を行う上で非常に役立ちます。ログに出力された内容を定期的に確認することで、サイトのパフォーマンスやエラーの原因を迅速に特定することができます

SCRIPT_DEBUGの設定

さらに、WP DebuggingではSCRIPT_DEBUGの切り替えが可能です。この定数をオンにすることで、WordPressが標準で使用する圧縮ファイルではなく、オリジナルのスクリプトファイルを読み込むようになります。これにより、スクリプトのデバッグが容易になります。

以下のようにwp-config.phpに記述することで、SCRIPT_DEBUGを手動でオンにすることもできますが、WP Debuggingを使用することで、これをプラグイン画面で簡単に切り替えることが可能です。

define('SCRIPT_DEBUG', true);

この設定は特に、弊社が支援しているクライアントサイトの多くで、開発環境でのデバッグ作業に利用されています。

WP Debuggingのオプション例

WP Debuggingの設定画面では、各種デバッグ定数をオン/オフに設定できます。以下はそのオプション例です:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

これらの設定により、エラー情報を訪問者に表示することなくログにのみ記録できます。本番環境ではWP_DEBUG_DISPLAYをオフにする設定が推奨されます

選び方のポイントと判断基準

WordPressのデバッグツールを選ぶ際には、運用環境やチームのスキルレベルに適したものを選択することが重要です。まず、自社のサーバー環境が開発環境か本番環境かを確認しましょう。本番環境での実行はパフォーマンスに影響を与えることがあるため、用途に応じて有効化のタイミングを調整する必要があります。特に `query-monitor` については、原因調査時のみ有効化し、調査が終わったら無効化する運用が推奨されます。

次に、チームのスキルレベルに応じた選択も大切です。例えば、SQLやPHPエラーを管理バーからすぐ確認できる `query-monitor` は、開発者や技術者にとって直感的に使いやすい反面、非技術者にとっては過剰な情報となるかもしれません。その場合、設定がシンプルな `wp-debugging` を検討することをお勧めします。このプラグインは `wp-config.php` をハンドリングしやすくし、WP_DEBUGなどの定数切替えを容易に行えます。

プラグインがサイトに与える負荷についても考慮する必要があります。ページロード時に各種情報を収集するプラグインは、それ自体がパフォーマンスに影響を与える可能性があります。そのため、本番環境で利用する際には、プラグインの適用効果と負荷をトレードオフとして慎重に考えるべきです。事前に `health-check` の「Enable Troubleshooting Mode」などで影響を確認すると良いでしょう。

弊社では、これらのプラグインを案件ごとに適切に選定し、導入しています。弊社が支援しているクライアントサイトでは、チームごとの技術レベルに応じた選択が効率的なトラブルシューティングを可能にしています。導入の際は『ダッシュボード > プラグイン > 新規追加 > 検索ボックスに「プラグイン名」を入力 > 今すぐインストール → 有効化』の流れを守り、運用状況に合わせた設定を行ってください。

動作確認とトラブルシューティング

WordPressの運用中に予期せぬエラーに直面することは珍しくありません。こうした状況において、適切なツールを利用することで迅速に原因を特定し、解決へ導くことが可能です。本セクションでは、Query MonitorWP Debuggingを使用した実践的なトラブルシューティング法を紹介します。

Query Monitorは、実行されたSQLやPHPエラーを確認するのに非常に役立ちます。管理バーから直接、問題の詳細を確認できるため、開発者や担当者は効率的に原因を見つけることができます。一方、WP Debuggingはwp-config.phpを手動で編集することなくデバッグログを出力する手段として活用できます。

予期せぬエラーの特定

まず、Query Monitorを使用してエラーログを確認します。有効化した後、『管理バー > Queries by Component』を選び、どのプラグインやテーマが問題を引き起こしているのか特定します。一方で、WP Debuggingを用いればwp-content/debug.logに出力される詳細なログを解析し、問題の原因や発生タイミングを捕捉できます。

ログからの問題抽出

記録されたログから問題を抽出する際は、WP Debuggingの出力をもとに次の行動を検討できます。エラーの発生箇所や原因を示すフィールドを注意深くチェックしましょう。特に、頻繁に発生するエラーコードは修正の優先度を示唆するため重要です。

修正後の再確認方法

エラーを修正した後、再度ログを確認して問題が解決したかどうかを確かめます。以下に修正後のログ確認例を示します:


# WP-CLI でデバッグログを表示
$ wp log tail --lines=10 wp-content/debug.log

このコマンドにより、直近のエラーログを確認し、問題が再発していないことを迅速に確認できます。弊社が支援しているクライアントサイトでも、このプロセスを経ることで安定稼働を実現しています。

実際のトラブル事例: カスタム投稿タイプの404問題

中小企業の運用案件で、カスタム投稿タイプのURLがサイトで404エラーを返すという問題が発生しました。この問題は、特にSEOにも影響を与えるため、速やかな修正が求められました。

最初に行ったのは、Query Monitorを使用して問題を特定する作業です。このプラグインはWordPressのデバッグにおいて非常に強力なツールで、SQLクエリやPHPエラーを細かく確認することができるため、問題の根本原因を迅速に把握する手助けとなります。

具体的には、Query Monitorで表示された『Queries』タブを確認しました。ここで、カスタム投稿タイプに関連するリクエストが正しく実行されていないことを確認し、さらに『PHP Errors』タブでテンプレートファイルの問題があることが判明しました。

問題特定の手順

問題を特定するために、以下の手順を踏みました。

  • 『Queries by Component』でカスタム投稿タイプに関連する遅延クエリを確認
  • 『PHP Errors』でテーマファイルのエラーを洗い出し
  • パーマリンク設定の再保存によるリライトルールの更新

これにより、投稿タイプのスラッグ設定やリライトルールの誤りが原因であると特定し、問題の修正に繋げました。

解決への具体的アプローチ

まず、カスタム投稿タイプの登録時に使われていたスラッグを修正しました。続いて、WordPressのダッシュボードから『設定 > パーマリンク』にアクセスし、何も変更せずに『変更を保存』をクリックしました。これにより、リライトルールが更新され、正常な状態に戻ったことを確認しました。

弊社が支援する他のクライアントサイトでも同様の問題が発生するケースがあり、Query Monitorの導入は70サイト中37件のカスタムポストタイプにおいて有益であると確認されています。問題解決に苦慮している場合は、このプラグインの導入を検討してみてください。

まとめ

今回、Query MonitorとWP Debuggingという二つのプラグインを比較し、それぞれの利点についてご紹介しました。Query Monitorは実行されたSQL、PHPエラー、遅いフックなどを視覚的に確認できる強力なツールです。一方、WP Debuggingは設定を簡素化し、デバッグモードを手軽に切り替えることができるプラグインです。

選び方のポイントとしては、開発環境における詳細なデバッグ情報を一変に把握したい方にはQuery Monitorが適しています。逆に、設定の手軽さや普段の管理での負担軽減を重視する方にはWP Debuggingが最適です。これらの選択肢は、お客さまの環境やニーズに応じた最適なツールを選ぶためのヒントになるでしょう。

さらに深く検討したい場合や、お客様のサイトに最適な構成についての具体的なアドバイスが必要な場合は、どうぞWordPressドクターへ気軽にご相談ください。私たちは、皆さまのWordPressサイトの運用サポートを全力で支援いたします。

この記事の内容でお困りなら

WordPressドクターでは、不具合の調査・改善対応を初回診断20,000円から承っています。費用感だけ知りたい方もお気軽にどうぞ。

無料相談する

この記事をシェアする

← 記事一覧へ戻る

まずは無料相談から

現状の診断のみのご相談も承っております。
無理な営業はいたしませんので、お気軽にお問い合わせください。

無料相談する
PAGE TOP