Query Monitorの使い方｜遅いクエリ・PHPエラー・フック・外部通信の調べ方

Query Monitor は、WordPress のページを表示するときに実行されたデータベースのクエリ、PHP のエラー、フック、外部への HTTP 通信などを、管理バーから確認できる開発者向けのプラグインです。どのプラグインやテーマが原因かを「コンポーネント」ごとに絞り込めるので、表示が遅い原因を探すときに役立ちます。

この記事は、2026年11月時点の Query Monitor 4.1.1 に合わせています。wordpress.org の情報では、動作には WordPress 6.3 以上、PHP 7.4 以上が必要です。

Query Monitor の表示を見られる人

• 初期設定では、単一サイトでは管理者、マルチサイトではネットワーク管理者だけに表示されます。訪問者には表示されません。
• ログアウトした状態や、管理者以外のユーザーで確認したい場合は、Query Monitor の「設定」パネルで「認証 Cookie を設定」をクリックします。そのブラウザでは、ログアウトしても表示されます。
• 公式の説明では、Query Monitor は集めたデータを保存せず、外部にも送りません。

手順1：インストールする

管理画面の「プラグイン」→「新規プラグインを追加」で「Query Monitor」を検索してインストールし、有効にします。WP-CLI では次のようにします。

wp plugin install query-monitor --activate

有効にすると、Query Monitor は wp-content/db.php に自分のファイルへのシンボリックリンクを作ります。これは、クエリについてより詳しい情報を集めるためのデータベースのドロップインです。次の場合は作られません。

• wp-content/db.php がすでにある（ほかのプラグインのドロップインがある場合など）
• wp-config.php で DISALLOW_FILE_MODS が true になっている、または QM_DB_SYMLINK を false にしている
• サーバーでシンボリックリンクが作れない

ドロップインがなくてもクエリの一覧は見られます。単一サイトでは、プラグインを停止すると Query Monitor の db.php は削除されます。

SAVEQUERIES を wp-config.php に書く必要はありません。Query Monitor は、SAVEQUERIES が定義されていなければ自分で true にします。逆に false と書いてあると、クエリを集められません。

手順2：管理バーの数値を読む

Query Monitor を有効にしてページを開くと、管理バーにそのページの概要が出ます。表示されるのは、ページ生成時間（PHP がページを作るのにかかった時間）、最大メモリ使用量、データベースクエリの合計時間とクエリの数です。PHP のエラーがあると、管理バーに警告が表示されます。

管理バーの項目をクリックすると、詳しいパネルが開きます。主なパネルは次のとおりです。

手順3：遅いクエリと原因のプラグインを見つける

1. 遅いと感じるページを開き、管理バーから「コンポーネントごとのクエリー」を開きます。クエリの数や時間が多いプラグイン・テーマが分かります。
2. 「低速なクエリ」を開きます。初期設定では 0.05 秒を超えたクエリが表示されます（wp-config.php で QM_DB_EXPENSIVE を定義すると基準を変えられます）。
3. 「重複クエリ」を開き、同じクエリが何度も実行されていないかを見ます。ループの中で投稿メタを1件ずつ取得しているコードなどで起きます。
4. 「データベースクエリー」で、気になるクエリの「呼び出し元」と「コンポーネント」を見て、どのファイルのどの関数から実行されたかを確認します。

原因が自作のコードの WP_Query なら、必要のない処理を止めると軽くなることがあります。次の引数はどれも WP_Query の公式の引数です。

<?php
$query = new WP_Query( array(
	'post_type'              => 'product',
	'posts_per_page'         => 10,
	// ページ送りを使わないなら、全件数を数えるクエリを省く
	'no_found_rows'          => true,
	// 投稿メタやタームを使わないなら、まとめて読み込む処理を省く
	'update_post_meta_cache' => false,
	'update_post_term_cache' => false,
) );

no_found_rows を true にすると、ページ送り（総ページ数の計算）が使えなくなります。投稿メタやタームを表示で使う場合は、update_post_meta_cache などを false にすると、かえってクエリが増えます。変更の前後で、Query Monitor のクエリ数と時間を比べて確かめます。

遅いクエリの実行計画は、WP-CLI の wp db query で EXPLAIN を付けて確認できます。テーブル名の接頭辞（wp_）は、wp db prefix で確認したものに合わせます。

# 実行計画を確認する
wp db query "EXPLAIN SELECT meta_value FROM wp_postmeta WHERE post_id = 123 AND meta_key = '_price'"

# wp_postmeta のインデックスと件数を確認する
wp db query "SHOW INDEX FROM wp_postmeta"
wp db query "SELECT COUNT(*) FROM wp_postmeta"

EXPLAIN の読み方とインデックスの考え方は、MySQLのEXPLAINでWordPressの遅いクエリを調べる方法 で詳しく説明しています。プラグインが原因の場合は、プラグインの設定を見直すか、作者に報告するか、代わりのプラグインを検討します。

手順4：PHP のエラーを確認する

「PHP エラー」のパネルには、警告・通知・非推奨（Deprecated）などのエラーが、ファイル名・行番号・コンポーネント・呼び出し履歴とともに表示されます。WordPress の関数の誤った使い方（Doing it Wrong）や、非推奨の関数の使用も表示されます。

パネルが表示されない Ajax や REST API のリクエストでは、Query Monitor が応答のヘッダーに情報を付けます（jQuery から送られた Ajax と、Query Monitor を見られるユーザーで認証された REST API のリクエストが対象です）。ブラウザの開発者ツールの「ネットワーク」タブで、該当のリクエストのヘッダーを確認します。

エラーをファイルに残して後から見たい場合は、開発環境で WordPress のデバッグログを有効にします。WP-CLI では次のようにします。

wp config set WP_DEBUG true --raw --type=constant
wp config set WP_DEBUG_LOG true --raw --type=constant
wp config set WP_DEBUG_DISPLAY false --raw --type=constant

ログは wp-content/debug.log に書かれます。本番サイトでは、確認が終わったら false に戻します。詳しくは WordPressのデバッグモードを有効にする方法 を参照してください。

手順5：フックと外部への通信を確認する

フックとアクション

「フックとアクション」のパネルには、そのページで実行されたアクションと、それぞれに登録されたコールバック（関数）、優先度、コンポーネントが表示されます。「自分の関数が呼ばれていない」「ほかのプラグインが同じフックで処理を上書きしている」といった問題の確認に使います。

このパネルには、フックごとの実行時間は表示されません。時間を測りたい場合は、手順6の方法を使います。

HTTP API 呼び出し

「HTTP API 呼び出し」のパネルには、WordPress の HTTP API（wp_remote_get() など）で行われた外部への通信が、URL・応答コード・コンポーネント・かかった時間とともに表示されます。失敗した通信やエラーになった通信には警告が出ます。ページを表示するたびに外部の API を呼んでいるプラグインは、表示が遅くなる原因になります。

手順6：自分のコードの処理時間を測る

自作のコードのどこに時間がかかっているかを測るには、Query Monitor のアクションで計測を始めて止めます。結果は「タイミング」のパネルに表示されます。

<?php
do_action( 'qm/start', 'my_heavy_task' );

// 計測したい処理
my_heavy_task();

do_action( 'qm/stop', 'my_heavy_task' );

途中の時点を記録するには、同じ名前で qm/lap を呼びます。値を確認したいときは、do_action( 'qm/debug', 'メッセージ' ); で「ログ」のパネルに書き出せます。qm/info、qm/warning、qm/error なども使え、warning 以上は管理バーでも知らせます。

Query Monitor を停止しても、これらは do_action() なので、エラーにはなりません。

注意点

• 公式の説明では、Query Monitor がページの生成時間に与える影響は小さいものの、クエリが数百件あるページではメモリを多く使います。調査が終わったら停止します。
• 本番サイトでも管理者にしか表示されませんが、調査はできるだけステージング環境で行います。
• バックアップや大量のインポートのように、クエリが非常に多い長い処理では、do_action( 'qm/cease' ); を呼ぶと、その処理の残りの間は Query Monitor がデータを集めるのをやめます。

まとめ

• 管理バーでページ生成時間・メモリ・クエリの時間と数を見て、パネルで詳しく調べる
• 遅いページは「コンポーネントごとのクエリー」「低速なクエリ」「重複クエリ」で、原因のプラグインと呼び出し元を特定する
• SAVEQUERIES は自分で書く必要はなく、false にすると集められない
• 「フックとアクション」に実行時間は出ないので、時間は qm/start と qm/stop で測る
• 調査が終わったら Query Monitor を停止する