実は、WordPressが標準で出力している「不要なもの」を止める、画像を適切に扱う、キャッシュを正しく設定する、といった基本の対策だけで、体感速度は大きく変わります。この記事では、プラグインを増やさずにできる高速化を、チェックリスト形式でまとめます。

高速化に取りかかる前に：現状を計測する

対策の効果を確かめるには、最初に現状の数値を記録しておく必要があります。次のツールを使うと、ボトルネックが分かります。

• PageSpeed Insights：Googleが提供する計測ツール。モバイルとPCの両方でスコアと改善案を確認できる。
• Chromeのデベロッパーツール（Networkタブ）：読み込まれるファイルの種類・サイズ・順序を確認できる。
• Lighthouse：Chromeに内蔵された診断機能。

特に、表示速度の指標であるLCP（最大コンテンツの表示時間）、CLS（レイアウトのずれ）、INP（操作への反応）を意識して見てください。「何が重いか」が分かってから対策すれば、効率よく改善できます。

対策1：不要な標準出力を止める

WordPressは、使っていなくても、多くのスクリプトやタグをページに出力します。これらを無効にすると、読み込むファイルが減ります。mu-pluginまたはfunctions.phpに、次のように記述します。

絵文字スクリプトを停止する

remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'wp_print_styles', 'print_emoji_styles' );
remove_action( 'wp_enqueue_scripts', 'wp_enqueue_emoji_styles' ); // WordPress 6.4以降
remove_action( 'admin_print_scripts', 'print_emoji_detection_script' );
remove_action( 'admin_print_styles', 'print_emoji_styles' );

絵文字を変換するJavaScriptとCSSが不要になります。最近のブラウザは、絵文字を標準で表示できるため、停止しても問題ありません。なお、WordPress 6.4以降は、絵文字CSSの出力が wp_enqueue_emoji_styles に移り、print_emoji_styles は非推奨になっています。そのため、上のコードは両方を記述しています。

embed（埋め込み）機能を停止する

add_action( 'wp_footer', function () {
	wp_dequeue_script( 'wp-embed' );
} );

他のWordPressサイトの記事URLを貼って、カード形式で埋め込み表示する機能を使わない場合は、不要です。

head内の不要なリンクを削除する

remove_action( 'wp_head', 'wp_generator' );          // WordPressのバージョン情報
remove_action( 'wp_head', 'wlwmanifest_link' );      // Windows Live Writer
remove_action( 'wp_head', 'rsd_link' );              // 外部ツール用
remove_action( 'wp_head', 'wp_shortlink_wp_head' );  // 短縮URL

速度への影響は小さく、バージョン情報を隠す効果も限定的ですが、HTMLの出力が整理されます。

ブロックエディターのCSSを外す

クラシックエディターや、独自のレイアウトで運用しているサイトでは、ブロック用のCSSが不要な場合があります。

add_action( 'wp_enqueue_scripts', function () {
	wp_dequeue_style( 'wp-block-library' );
	wp_dequeue_style( 'wp-block-library-theme' );
	wp_dequeue_style( 'global-styles' );
}, 100 );

ただし、ブロックエディターで記事を作成しているサイトでは、レイアウトが崩れる原因になります。外す前に、全種類のページを確認してください。

対策2：画像を最適化する

ページの重さの大半は画像です。画像の対策は、効果が最も大きい項目といえます。

適切なサイズで読み込む

表示サイズが幅600pxなのに、4000pxの画像を読み込んでいるサイトは多くあります。アップロード前にリサイズするか、WordPressが生成する中サイズ・大サイズを使い分けましょう。WordPressは、srcset 属性を自動で出力するため、wp_get_attachment_image() など標準関数で画像を出力すれば、端末に合ったサイズが選ばれます。

WebP形式を使う

WebPは、JPEGやPNGより軽量な画像形式です。WordPress 5.8以降は、WebPのアップロードに標準で対応しています。サーバーが対応していれば、アップロード時にWebPへ変換することもできます。

遅延読み込み（lazy load）を使う

WordPressは、画像に loading="lazy" を自動で付与します。画面に入るまで画像を読み込まない仕組みです。ただし、ファーストビューの画像（メインビジュアルなど）には付けないようにしてください。WordPress 6.3以降は、最初の画像を自動で判定して調整する仕組みも入っていますが、テーマによっては効かないことがあるため、メインビジュアルの出力は自分で確認しましょう。最初に見える画像まで遅延させると、LCPが悪化します。

// ファーストビューの画像は遅延させない
echo wp_get_attachment_image( $id, 'large', false, array(
	'loading'       => 'eager',
	'fetchpriority' => 'high',
) );

幅と高さを指定する

width と height 属性を指定していないと、画像の読み込み後にレイアウトがずれて、CLSが悪化します。標準関数で出力すれば自動で付与されるため、手書きのimgタグを使う場合は注意してください。

対策3：CSS・JavaScriptの読み込みを見直す

不要なプラグインのスクリプトを、必要なページだけにする

お問い合わせフォームのプラグインなどは、サイト全体でCSSとJavaScriptを読み込むことがあります。フォームのあるページ以外では読み込まないようにすると、無駄が減ります。

add_action( 'wp_enqueue_scripts', function () {
	if ( ! is_page( 'contact' ) ) {
		wp_dequeue_style( 'contact-form-7' );
		wp_dequeue_script( 'contact-form-7' );
	}
}, 100 );

ハンドル名はプラグインによって異なります。ページのソースや、デベロッパーツールで読み込まれているファイル名から、確認してください。

JavaScriptをdeferで読み込む

JavaScriptがページの描画をブロックするのを避けるため、defer 属性を付けて読み込みます。WordPress 6.3以降は、wp_enqueue_script() の引数で、読み込み方法を指定できます。

wp_enqueue_script( 'my-script', get_theme_file_uri( '/js/main.js' ), array(), '1.0', array(
	'strategy'  => 'defer',
	'in_footer' => true,
) );

jQuery Migrateを外す

古いjQueryのコードとの互換性のためのファイルですが、最近のテーマでは不要なことが多いです。

add_action( 'wp_default_scripts', function ( $scripts ) {
	if ( ! is_admin() && isset( $scripts->registered['jquery'] ) ) {
		$scripts->registered['jquery']->deps = array_diff(
			$scripts->registered['jquery']->deps,
			array( 'jquery-migrate' )
		);
	}
} );

外したあとに、スライダーなどのjQuery依存の機能が動くか確認してください。

対策4：キャッシュを正しく設定する

ブラウザキャッシュ

画像・CSS・JavaScriptなどの静的ファイルに有効期限を設定すると、2回目以降の訪問で再ダウンロードが不要になります。Apacheなら、.htaccess に次のように記述します。

<IfModule mod_expires.c>
	ExpiresActive On
	ExpiresByType image/jpeg "access plus 1 year"
	ExpiresByType image/webp "access plus 1 year"
	ExpiresByType text/css "access plus 1 month"
	ExpiresByType application/javascript "access plus 1 month"
	ExpiresByType text/javascript "access plus 1 month"
</IfModule>

レンタルサーバーによっては、管理画面にキャッシュや高速化の設定があります。サーバー側の機能のほうが効率的な場合が多いため、まず確認してみましょう。

圧縮（gzip・Brotli）

テキスト系ファイルを圧縮して転送すると、転送量が大きく減ります。多くのサーバーでは標準で有効ですが、PageSpeed Insightsで「テキスト圧縮の有効化」と指摘されたら、設定を確認してください。

ページキャッシュ

ページキャッシュは、生成済みのHTMLを保存して配信する仕組みです。サーバーが備えるキャッシュ機能（LiteSpeedの機能など）を使えば、プラグインを追加せずに利用できます。会員サイトなど、ログインユーザーごとに内容が変わるページは、キャッシュの対象から外す設定を忘れないようにしましょう。

対策5：データベースとサーバー環境

• リビジョンの数を制限する：wp-config.phpに define( 'WP_POST_REVISIONS', 5 ); と記述すると、保存する履歴の数を抑えられる。
• 不要なデータを削除する：スパムコメント、ゴミ箱の記事、期限切れのトランジェントを定期的に整理する。
• PHPのバージョンを上げる：PHP 8系は、PHP 7系より処理が速い。互換性を確認したうえで更新する。
• 使っていないプラグインを削除する：停止中のプラグインも含め、不要なものは削除する。
• Webフォントを減らす：読み込むフォントの種類や太さを絞り、font-display: swap を指定する。

効果が大きい順の優先度

すべてを一度に行う必要はありません。次の順で取り組むと、効率よく成果が出ます。

1. 画像のサイズ・形式の最適化（効果が最も大きい）
2. ファーストビュー以外の画像の遅延読み込み
3. キャッシュと圧縮の設定
4. 不要なスクリプト・CSSの停止
5. PHPバージョンの更新
6. データベースの整理

まとめ

WordPressの高速化は、プラグインを足さなくても、多くの改善ができます。

• まず計測して、ボトルネックを把握する
• 絵文字・embedなど、使っていない標準出力を止める
• 画像のサイズ・WebP・遅延読み込みを見直す（ファーストビューは遅延させない）
• スクリプトは、必要なページだけで、deferで読み込む
• キャッシュと圧縮は、サーバー機能を優先して設定する

各対策の前後で、必ず表示確認と再計測を行ってください。見た目やフォームの動作が壊れていないことを確認しながら、少しずつ進めるのが、安全に高速化するコツです。

この記事では、ACFの値が出力されないときの原因を、パターン別に整理して解説します。原因が分かれば、ほとんどは数分で解決できます。

まず確認：正しい基本の書き方

最初に、基本の呼び出し方を確認します。

<?php
// 値を取得して変数に入れる
$text = get_field( 'catch_copy' );
if ( $text ) {
	echo esc_html( $text );
}

// その場で出力する
the_field( 'catch_copy' );
?>

get_field() は値を返し、the_field() は値をそのまま出力します。出力前のチェックや加工が必要なときは、get_field()を使うのが基本です。この2つの使い分けを間違えて、echo the_field() と書いてしまうこともありますが、the_field() はそれ自体が出力するため、冗長です。

原因1：フィールド名とフィールドキーの取り違え

ACFには、フィールドの「ラベル」「名前」「キー」という3つの識別子があります。

• ラベル：管理画面に表示される名前（日本語でも可）。コードでは使えない。
• 名前：コードで指定する名前（例：catch_copy）。
• キー：ACFが内部で使うID（例：field_65a1b2c3d4e5f）。

get_field()には、ラベルではなく「名前」を渡します。日本語のラベルを指定していたり、スペルが1文字違っていたりすると、値は取得できません。フィールドグループの編集画面で、名前の欄をコピーして貼り付けるのが確実です。

原因2：投稿IDが合っていない

get_field()は、デフォルトでは「現在のループ中の投稿」の値を取得します。ループの外で使ったり、別の投稿の値が必要だったりするときは、第2引数でIDを指定する必要があります。

// 特定の投稿IDを指定する
$value = get_field( 'catch_copy', 123 );

// 固定ページ「トップ」の値をどこからでも取得する
$front_id = get_option( 'page_on_front' );
$value    = get_field( 'catch_copy', $front_id );

よくあるのが、サブクエリのループ後に、ID指定なしで呼んでいるケースです。wp_reset_postdata() を忘れたままだと、サブクエリの最後の投稿の値が返ってきたり、空になったりします。また、アーカイブページでは、現在のページ自体は「投稿」ではないため、アーカイブ用の値は別途指定が必要です。

タームやユーザーの値を取得する場合

タクソノミーのターム、ユーザー、オプションページの値は、第2引数に専用の形式で渡します。

// タームのフィールド
$term = get_queried_object();
$value = get_field( 'term_color', $term );

// 別の指定方法
$value = get_field( 'term_color', 'category_5' );

// ユーザーのフィールド
$value = get_field( 'phone', 'user_1' );

// オプションページのフィールド
$value = get_field( 'footer_text', 'option' );

タームの場合の category_5 のような指定は、「タクソノミー名_ターム ID」の形式です。この形式を間違えると、空になります。

原因3：リピーターフィールドのループの書き方

リピーターフィールドは、通常のフィールドと取得方法が異なります。値を一括で取得するのではなく、行ごとにループします。

<?php if ( have_rows( 'staff_list' ) ) : ?>
	<ul>
	<?php while ( have_rows( 'staff_list' ) ) : the_row(); ?>
		<li>
			<?php the_sub_field( 'name' ); ?>
			（<?php the_sub_field( 'role' ); ?>）
		</li>
	<?php endwhile; ?>
	</ul>
<?php endif; ?>

ここで、次の点に注意してください。

• ループの中では、get_field() ではなく get_sub_field() / the_sub_field() を使う
• 入れ子（リピーターの中のリピーター）では、内側も have_rows() でループする
• ループの外から子の値を取りたいときは、get_field( 'staff_list' ) で配列として取得してから、foreachで処理する

配列として取得する方法も覚えておくと、並べ替えや件数のカウントなど、柔軟な処理ができます。

$rows = get_field( 'staff_list' );
if ( $rows ) {
	foreach ( $rows as $row ) {
		echo esc_html( $row['name'] );
	}
}

原因4：戻り値の形式が想定と違う

画像、ファイル、リンク、投稿オブジェクトなどのフィールドは、「戻り値」の形式を設定できます。この設定と、テンプレートでの扱い方が合っていないと、何も表示されません。

画像フィールドの場合

• 画像配列：配列で返る。$image['url'] のように使う。
• 画像URL：URL文字列で返る。そのまま src に使える。
• 画像ID：数値で返る。wp_get_attachment_image() などと組み合わせる。

戻り値が「配列」なのに <img src="<?php the_field( 'photo' ); ?>"> と書くと、「Array」と出力されてしまいます。逆に、戻り値が「URL」なのに $image['url'] と書くと、PHPの警告やエラー（PHP 8以降は致命的エラー）になります。

$image = get_field( 'photo' ); // 戻り値：画像配列の場合
if ( $image ) {
	echo '<img src="' . esc_url( $image['sizes']['medium'] ) . '" alt="' . esc_attr( $image['alt'] ) . '">';
}

フィールドグループの設定画面で「戻り値」を確認し、書き方を合わせてください。迷ったときは、var_dump( get_field( 'photo' ) ) で中身を見るのが早道です。

リンクフィールドの場合

リンクフィールドは、配列で返る場合は url・title・target の3つを持ちます。新しいタブで開く設定の target を忘れずに出力しましょう。

原因5：フィールドグループの表示条件が合っていない

編集画面で入力欄が表示されなければ、そもそも値を保存できません。フィールドグループの「表示条件」が、対象の投稿タイプ、テンプレート、カテゴリーなどと一致しているか確認してください。

• ページテンプレートを条件にしている場合、テンプレートを選択して保存するまで、入力欄が出ない
• カスタム投稿タイプを追加したのに、条件を更新していない
• フィールドグループが「無効」状態になっている

また、フィールド名を途中で変更すると、既存の投稿には旧名で保存された値が残るため、新しい名前では空になります。既存の投稿の値を入力し直すか、データを移行する必要があります。

原因6：プレビューや下書きで値が出ない

公開前のプレビューでは、保存済みの最新の値が反映されないことがあります。特に、リビジョン機能とACFの組み合わせでは、プレビュー時に過去の値が表示されたり、空になったりすることがあります。

この場合は、プレビューではなく、一度「更新」を押して公開状態で確認するか、ACFのバージョンを最新にして改善されるか試してください。

原因7：キャッシュと出力のエスケープ

最後に、意外と見落とすのがキャッシュです。

• ページキャッシュ系のプラグインが、古い表示を返している
• オブジェクトキャッシュ（Redisなど）が、古い値を保持している

キャッシュをクリアして表示が変わるなら、原因はACFではなくキャッシュです。また、値がHTMLタグを含む場合に esc_html() で出力すると、タグが文字として表示されます。WYSIWYGフィールドの値はHTMLを含むため、wp_kses_post() を通して出力するなど、フィールドの種類に合わせたエスケープを選んでください。なお、the_field() は echo get_field() と同じで、自動ではエスケープされません。

デバッグの進め方

原因が分からないときは、次の順番で確認します。

1. var_dump( get_field( 'フィールド名', 投稿ID ) ) で、実際の戻り値を確認する
2. 値が NULL や false なら、フィールド名・投稿IDを疑う
3. 値が Array なら、戻り値の形式と、書き方が合っているか確認する
4. 管理画面の編集画面で、実際に値が保存されているか確認する
5. キャッシュを無効にして、再度確認する

「何が返ってきているか」を見れば、原因の見当は、ほぼつきます。推測でコードを書き直す前に、まず値の中身を確認する癖をつけましょう。

まとめ

ACFの値が出力されない原因は、次の7つのどれかに当てはまることがほとんどです。

• ラベルではなく、フィールドの「名前」を指定する
• ループの外やサブクエリ後は、投稿IDを明示する（ターム・ユーザー・オプションは専用の形式で指定）
• リピーターは、have_rows()とget_sub_field()でループする
• 画像などは、戻り値の形式に合わせた書き方にする
• フィールドグループの表示条件を確認する
• プレビューでは、最新の値が出ないことがある
• キャッシュと、エスケープ関数の選び方を確認する

まずは var_dump() で中身を見る。この一手が、最短の解決につながります。

代わりに使うのが pre_get_posts というアクションフックです。この記事では、メインクエリを安全に書き換える方法と、query_postsを避けるべき理由、get_postsやWP_Queryとの使い分けを解説します。

メインクエリとは

WordPressは、ページにアクセスがあると、URLをもとに「どの記事を取得するか」を判断して、データベースに問い合わせを行います。このとき自動で実行されるのがメインクエリです。トップページ、カテゴリーアーカイブ、検索結果、投稿の個別ページなど、すべての表示がこのメインクエリを元にしています。

テンプレートで have_posts() と the_post() を使ったループは、このメインクエリの結果を表示しています。つまり、表示件数や並び順を変えたい場合は、メインクエリの条件そのものを変えるのが本来の方法です。

query_postsを使ってはいけない理由

query_posts()は、テンプレートの中でメインクエリを上書きする関数です。手軽に見えますが、次の問題があります。

• クエリが二重に実行される：WordPressが自動で実行したあとに、もう一度クエリを実行するため、無駄な負荷がかかる。
• ページネーションが壊れやすい：件数やページ数の情報が正しく引き継がれず、2ページ目以降が表示されなくなる。
• グローバル変数を書き換える：後続の処理やプラグインに、予期しない影響を与える。
• リセットが必要：wp_reset_query()を忘れると、サイドバーやフッターの表示が崩れる。

WordPressの公式ドキュメントでも、query_postsは「使用を避けるべき」とされています。メインクエリを変更するときは、pre_get_postsを使います。

pre_get_postsの基本

pre_get_postsは、クエリがデータベースに問い合わせを行う直前に呼ばれるフックです。ここでクエリの条件を変更すれば、最初から目的の条件で、1回だけクエリが実行されます。

add_action( 'pre_get_posts', 'my_modify_main_query' );

function my_modify_main_query( $query ) {
	// 管理画面と、メインクエリ以外は対象外にする
	if ( is_admin() || ! $query->is_main_query() ) {
		return;
	}

	// お知らせのアーカイブだけ、表示件数を10件にする
	if ( $query->is_post_type_archive( 'news' ) ) {
		$query->set( 'posts_per_page', 10 );
	}
}

この書き方のポイントは、次の3点です。

1. 関数の引数 $query は、参照渡しのため、set() で変更すればそのまま反映される（return不要）
2. is_admin() で、管理画面のクエリを除外する
3. $query->is_main_query() で、サブクエリ（ウィジェットなど）を除外する

特に2と3の判定は、必ず書いてください。抜けていると、管理画面の投稿一覧や、ウィジェットのクエリまで書き換わり、原因の分かりにくい不具合になります。

よく使うパターン集

表示件数を変える

if ( $query->is_post_type_archive( 'news' ) ) {
	$query->set( 'posts_per_page', 10 );
}

並び順を変える（古い順）

if ( $query->is_category() ) {
	$query->set( 'orderby', 'date' );
	$query->set( 'order', 'ASC' );
}

検索結果の対象を絞る

if ( $query->is_search() ) {
	$query->set( 'post_type', array( 'post', 'news' ) );
}

特定のカテゴリーを除外する

if ( $query->is_home() ) {
	$query->set( 'category__not_in', array( 5 ) );
}

カスタムフィールドで並べ替える

if ( $query->is_post_type_archive( 'event' ) ) {
	$query->set( 'meta_key', 'event_date' );
	$query->set( 'orderby', 'meta_value' );
	$query->set( 'order', 'ASC' );
}

どのパターンも、まず条件分岐で「どのページのクエリか」を限定し、そのうえで set() を呼ぶ形が共通しています。

条件分岐タグの使いどころ

pre_get_postsの中では、is_home() や is_category() などの条件分岐タグを使えます。ただし、実行のタイミングがテンプレート読み込みの前のため、グローバルな条件分岐ではなく、$queryのメソッドを使うのが安全です。

フロントページを固定ページにしている場合は、is_home() の意味が変わる点にも注意が必要です。トップページに最新記事を出したいのか、投稿ページ（ブログ）を指しているのかを、設定画面で確認しておきましょう。

get_posts・WP_Query・pre_get_postsの使い分け

クエリを扱う方法は複数あり、混乱しやすい部分です。目的別に整理します。

判断の基準は、「そのページが本来表示すべき一覧を変えたいのか、それとも別の一覧を追加で表示したいのか」です。前者はpre_get_posts、後者はWP_Queryです。

なお、get_posts()は内部でWP_Queryを使っていますが、デフォルトでは投稿の固定表示（sticky）を無視するなど、細かい挙動の違いがあります。また、suppress_filters がtrueになっているため、多くのフィルターの影響を受けません。ただし、pre_get_posts はこの設定にかかわらず実行されるため、is_main_query() の判定を入れずに書き換えると、get_posts()の結果にも影響します。

ハマりやすいポイント

1. 固定ページでは意味がない

固定ページのクエリは、特定のページを1件取得するものです。件数や並び順を変えても意味がありません。固定ページ内に一覧を出す場合は、WP_Queryを使います。

2. 条件分岐を絞らないと全体に影響する

pre_get_postsは、サイトの全ページで実行されます。条件分岐を書かずに set( 'posts_per_page', 3 ) と書くと、トップページも検索結果もカテゴリーも、すべて3件になります。必ず対象のページを絞りましょう。

3. 優先度とプラグインの影響

プラグインも同じフックで書き換えを行っていることがあります。思った通りにならない場合は、フックの優先度（第3引数）を調整するか、他のプラグインを一時的に停止して確認します。

4. ページネーションの件数が合わない

posts_per_pageを変更しても、WordPress標準の「ブログページに表示する最大投稿数」の設定とは別に動きます。ページ送りのリンクが想定と違うときは、設定値と、pre_get_postsの値の両方を確認してください。

まとめ

メインクエリの変更は、pre_get_postsで行うのが現在の正しい方法です。

• query_postsは、二重クエリやページネーション崩れの原因になるため、使わない
• pre_get_postsは、is_admin() と is_main_query() の判定を必ず入れる
• 対象ページを $query->is_xxx() で絞ってから、set() で条件を変更する
• 別枠の一覧はWP_Query、配列だけ欲しいときはget_posts()を使う

古い記事を参考にすると、query_postsが登場することがあります。そのまま真似せず、pre_get_postsに置き換えて実装するようにしてください。

原因は、実は数パターンに絞られます。この記事では、WP_Queryで記事が表示されないときに確認すべき7つのポイントを、切り分けやすい順に解説します。

まず基本形を確認する

切り分けの前に、正しい書き方の基本形を確認しておきます。

<?php
$args = array(
	'post_type'      => 'news',
	'posts_per_page' => 5,
	'post_status'    => 'publish',
);
$query = new WP_Query( $args );

if ( $query->have_posts() ) :
	while ( $query->have_posts() ) :
		$query->the_post();
		?>
		<h2><?php the_title(); ?></h2>
		<?php
	endwhile;
endif;
wp_reset_postdata();
?>

ポイントは、ループの中では $query->have_posts() と $query->the_post() のように、変数に入れた自分のクエリを使うことと、最後に wp_reset_postdata() を呼ぶことです。これを踏まえて、原因を順に見ていきます。

ポイント1：post_typeの指定が間違っている

最も単純で、最も多い原因です。post_type を指定しないと、デフォルトの post（通常の投稿）だけが対象になります。カスタム投稿タイプの記事を出したいのに指定を忘れると、0件になります。

• カスタム投稿タイプの「スラッグ」と完全に一致しているか（大文字小文字、ハイフン、アンダースコア）
• 登録時の register_post_type の第1引数と同じ文字列か
• 管理画面のURL（edit.php?post_type=○○）で、正しいスラッグを確認する

日本語の「お知らせ」ではなく、あくまで登録時の英数字のスラッグを指定します。複数のタイプを対象にしたい場合は、配列で array( 'post', 'news' ) のように指定します。

ポイント2：post_statusと公開日時を確認する

WP_Queryは、デフォルトでは「公開済み」の記事だけを取得します。ログインしている場合は、非公開の記事も含まれることがあるため、ログイン中と未ログインで表示が違うという現象が起こります。

次の記事は、一覧に出ません。

• 下書き、承認待ち、非公開の記事
• 予約投稿（future）で、まだ公開日時が来ていない記事
• ゴミ箱に入っている記事

予約投稿の見落としは特に多く、「公開したはずなのに出ない」と思ったら、公開日時が未来になっていた、というケースがあります。管理画面の記事一覧で、ステータスと日時を確認してください。

ポイント3：pre_get_postsでクエリが書き換えられている

自分のWP_Queryには問題がないのに、アーカイブページなどで件数や並びがおかしい場合は、pre_get_posts フックによるメインクエリの書き換えが原因かもしれません。

functions.phpやmu-plugin、プラグインのどこかで、次のような処理が書かれていないか検索してみましょう。

add_action( 'pre_get_posts', function ( $query ) {
	if ( ! is_admin() && $query->is_main_query() ) {
		$query->set( 'posts_per_page', 3 );
	}
} );

この例は、管理画面とメインクエリ以外は除外していますが、対象のページを絞っていないため、フロント側のすべての一覧が3件になります。書き換えが意図しないページにまで及ぶ場合は、is_home() や is_post_type_archive( 'news' ) のように、条件で対象を絞り込む必要があります。is_admin() と is_main_query() の判定が抜けていると、管理画面や、サブクエリにまで影響が出ます。

ポイント4：ページネーションが動かない

2ページ目以降を開いても、1ページ目と同じ内容が出る。このトラブルは、WP_Queryに paged を渡していないことが原因です。2ページ目以降が404になる場合は、メインクエリ側の投稿数や表示件数とずれていないかを確認してください（pre_get_postsで件数をそろえる方法は、次の記事で解説します）。

$paged = get_query_var( 'paged' ) ? get_query_var( 'paged' ) : 1;

$args = array(
	'post_type'      => 'news',
	'posts_per_page' => 10,
	'paged'          => $paged,
);
$query = new WP_Query( $args );

注意したいのは、固定ページをフロントページに設定している場合です。この場合は paged ではなく page というクエリ変数が使われるため、get_query_var( 'page' ) を参照する必要があります。

また、ページ送りのリンクは、メインクエリの総ページ数をもとに出力されます。メインクエリが1ページ以下だと、the_posts_pagination() は何も出力しないため、サブクエリでは paginate_links() に、'total' => $query->max_num_pages と 'current' => max( 1, $paged ) を渡して出力します。

それでも404になる場合は、パーマリンク設定の再保存（設定 > パーマリンク設定で「変更を保存」）を試してください。リライトルールが更新され、直ることがあります。

ポイント5：wp_reset_postdata()を忘れている

サブクエリのループを使ったあと、wp_reset_postdata() を呼ばないと、グローバルな投稿データが書き換わったままになります。その結果、ループの後ろで使う the_title() や get_the_ID()、サイドバーの表示が、おかしくなります。

• ページの本来のタイトルではなく、サブクエリの最後の記事のタイトルが出る
• 後続のウィジェットやフッターで、別の記事の情報が表示される

サブクエリを使ったら、必ずループの直後に wp_reset_postdata() を呼ぶ。これは習慣にしておくと安心です。なお、query_posts() を使った場合は wp_reset_query() が必要ですが、そもそも query_posts() は使わないほうがよい関数です（詳しくは次回以降の記事で解説します）。

ポイント6：tax_query・meta_queryの条件が厳しすぎる

タクソノミーやカスタムフィールドで絞り込むと、条件の書き方ひとつで0件になります。

tax_queryでよくあるミス

• field の指定（term_id、slug、name）と、terms に渡す値の種類が一致していない
• スラッグの代わりに、日本語のタームの名前を渡している
• 複数の条件があるのに、relation が AND のままで、同時に満たす記事がない

'tax_query' => array(
	array(
		'taxonomy' => 'news_cat',
		'field'    => 'slug',
		'terms'    => 'important',
	),
),

meta_queryでよくあるミス

• キー名のスペルミス、大文字小文字の違い
• 数値を比較するのに、type を NUMERIC にしていない（文字列として比較されて順序がずれる）
• 日付の比較で、保存形式（Ymd か Y-m-d）と比較する値の形式が違う
• メタ値が存在しない記事は、条件によって除外される

原因の切り分けには、条件をひとつずつコメントアウトして、どの条件で0件になるか確認するのが確実です。

ポイント7：実際に発行されるSQLを確認する

ここまで確認しても原因が分からないときは、WP_Queryが実際に発行したSQLを見ましょう。

$query = new WP_Query( $args );
echo '<pre>' . esc_html( $query->request ) . '</pre>';
echo '見つかった件数：' . $query->found_posts;

request プロパティには、実際に実行されたSQLが入っています。WHERE句に、意図しない条件（post_type、post_status、タームの絞り込み）が入っていないか確認してください。「想定していたクエリ」と「実際のクエリ」の差が、原因そのものです。

デバッグ用の表示は、確認が終わったら必ず削除しましょう。本番サイトにSQLを出したままにするのは危険です。また、プラグイン「Query Monitor」を使うと、ページで実行されたクエリを管理バーから確認でき、開発中は大変便利です。

チェックリスト

記事が表示されないときは、次の順で確認してください。

1. post_typeのスラッグは、登録時のものと一致しているか
2. 記事のステータスと公開日時は、公開済みになっているか
3. pre_get_postsで、クエリが書き換えられていないか
4. pagedを渡しているか。パーマリンクを再保存したか
5. wp_reset_postdata()を呼んでいるか
6. tax_query・meta_queryの条件が厳しすぎないか
7. $query->requestで、実際のSQLを確認したか

まとめ

WP_Queryで記事が出ない原因は、ほとんどが「指定の間違い」「条件の見落とし」「リセットの忘れ」のいずれかです。焦って全体を書き直す前に、上の7つを順番に確認すれば、たいていは数分で原因が見つかります。

とくに、post_typeのスラッグ、公開ステータス、pre_get_postsの影響は、見落としやすいポイントです。トラブルの際は、最後に実際のSQLを見て、想定との差を確かめる習慣をつけておきましょう。

そこで有効なのが、mu-plugin（Must Use Plugins）という仕組みです。この記事では、サイト固有の処理をfunctions.phpから切り出すべき理由と、mu-pluginの作り方・使い分けの基準を解説します。

functions.phpに書き続けるとどうなるか

functions.phpは、テーマの一部として読み込まれるファイルです。つまり、ここに書いた機能は「そのテーマが有効な間だけ」動くことになります。次のような場面で問題が出ます。

• テーマを変更・リニューアルしたとき：カスタム投稿タイプやショートコードが突然消え、記事の表示が崩れる。
• 親テーマを更新したとき：子テーマを使っていない場合、編集内容が上書きされて消える。
• コードが肥大化したとき：数百行〜数千行になり、どこに何があるか分からなくなる。
• 構文エラーを入れたとき：1文字のミスでサイト全体が止まる。

ここで重要なのは、「見た目に関する処理」と「サイトのデータや機能に関する処理」は、本来は寿命が違うということです。デザインを作り直しても、カスタム投稿タイプや独自のルールは残したいはずです。この寿命の違いを分けて管理するのが、mu-pluginの役割です。

mu-pluginとは

mu-pluginは、wp-content/mu-plugins/ フォルダに置いたPHPファイルを、WordPressが自動的に読み込む仕組みです。通常のプラグインとの違いは次のとおりです。

「管理画面から無効にできない」ことは、欠点にも見えますが、クライアントが誤って機能を止める事故を防げるという利点になります。サイトの根幹となる処理を守るのに向いています。

mu-pluginの作り方

作り方はとても簡単です。wp-content の下に mu-plugins フォルダがなければ作成し、その中にPHPファイルを置くだけです。

wp-content/
  ├─ themes/
  ├─ plugins/
  └─ mu-plugins/
       └─ site-functions.php

ファイルの先頭には、通常のプラグインと同じくヘッダーコメントを書いておきます。

<?php
/**
 * Plugin Name: サイト固有の機能
 * Description: このサイト専用のカスタム投稿タイプや共通処理をまとめる
 * Version: 1.0.0
 */

// 直接アクセスを防ぐ
if ( ! defined( 'ABSPATH' ) ) {
	exit;
}

// 例：カスタム投稿タイプの登録
add_action( 'init', function () {
	register_post_type( 'news', array(
		'label'       => 'お知らせ',
		'public'      => true,
		'has_archive' => true,
		'supports'    => array( 'title', 'editor', 'thumbnail' ),
		'show_in_rest' => true,
	) );
} );

保存して管理画面を開くと、「プラグイン」画面に「Must-Use」というタブが追加され、そこに表示されます。確認できれば有効化は完了です。

mu-pluginに入れるべきものと、入れないもの

何でもmu-pluginに入れればよい、というわけではありません。判断の基準は「テーマを変えても必要か」です。

mu-pluginに向いているもの

• カスタム投稿タイプ・カスタムタクソノミーの登録
• カスタムフィールドの定義
• 管理画面の制限（不要メニューの非表示、権限の調整）
• ショートコードのうち、データに関するもの
• パーマリンクやリライトルールの設定
• REST APIの拡張、独自のエンドポイント
• セキュリティ関連の設定（XML-RPCの停止、不要な出力の削除など）

functions.php（テーマ側）に置くもの

• CSS・JavaScriptの読み込み（wp_enqueue_scripts）
• アイキャッチやメニューなどのテーマサポートの宣言
• 画像サイズの追加（デザインに依存するもの）
• ウィジェットエリアの登録

つまり、データと機能はmu-plugin、見た目はテーマと考えれば迷いません。たとえば、カスタム投稿タイプを登録する処理がテーマ内にあると、テーマを変えた瞬間に過去の投稿が管理画面から見えなくなります。データは残っているのに、操作できなくなるのです。

ファイルが増えたときの整理方法

mu-pluginsフォルダは、直下にあるPHPファイルしか自動で読み込みません。サブフォルダ内のファイルは読み込まれないため、ファイルを分割したい場合は、直下のファイルから読み込む必要があります。

wp-content/mu-plugins/
  ├─ loader.php          // 直下：各ファイルを読み込む
  └─ site/
       ├─ post-types.php
       ├─ shortcodes.php
       └─ admin.php

<?php
/**
 * Plugin Name: サイト固有の機能ローダー
 */
if ( ! defined( 'ABSPATH' ) ) {
	exit;
}

$files = array( 'post-types', 'shortcodes', 'admin' );
foreach ( $files as $file ) {
	require_once __DIR__ . '/site/' . $file . '.php';
}

機能ごとにファイルを分けておけば、修正箇所をすぐ見つけられます。また、不具合が出たときに、特定のファイルの読み込みだけを一時的に外して原因を切り分けることもできます。

注意点とよくある失敗

1. 読み込み順に注意する

mu-pluginは、通常のプラグインやテーマより先に読み込まれます。そのため、他のプラグインが提供する関数やクラスを、ファイルの直下でいきなり呼び出すとエラーになります。必ず add_action( 'init', ... ) や plugins_loaded のようなフックの中に処理を書いてください。

2. 更新通知が出ない

mu-pluginは更新の対象外です。サードパーティ製のプラグインをmu-pluginとして置くと、脆弱性が見つかっても更新に気づけません。自作のコード専用にし、配布されているプラグインは通常の場所に入れましょう。

3. 構文エラーの影響が大きい

「管理画面から誤って止められない」ことは利点ですが、裏を返せば、壊れたときはFTPなどでファイルを直すしかないということです。mu-pluginの構文エラーは、管理画面から無効化できません。そのため、サイト全体が止まったときはFTPでファイルを直すか、削除する必要があります。本番サーバーで直接編集せず、ローカルで動作確認してからアップロードしましょう。

4. 本番とローカルで構成を合わせる

mu-pluginsフォルダは、データベースではなくファイルとして管理されます。サイトを移転するときは、wp-content/mu-plugins もコピーし忘れないようにしてください。コピーを忘れると、カスタム投稿タイプなどが消えたように見えます。

5. バージョン管理に含める

GitやSVNでサイトを管理している場合は、mu-pluginsフォルダもリポジトリに含めておきます。サイト固有の資産として、履歴を残せるようになります。

6. 有効化フックは使えない

mu-pluginには「有効化」の概念がないため、register_activation_hook() は動きません。有効化時に1回だけ実行したい処理は、別の方法で行う必要があります。また、has_archive を指定したカスタム投稿タイプを追加した直後は、管理画面の「設定 > パーマリンク設定」を開いて保存し、リライトルールを更新しないと、アーカイブが404になることがあります。

既存のfunctions.phpから移行する手順

すでにfunctions.phpにコードが溜まっている場合は、次の手順で少しずつ移すのがおすすめです。

1. functions.phpのバックアップを取る
2. コードを「見た目に関するもの」と「データ・機能に関するもの」に仕分けする
3. データ・機能のコードを、mu-pluginの新しいファイルに貼り付ける
4. functions.php側の同じコードを削除する（二重定義でエラーになるため、必ず消す）
5. サイトの表示と管理画面を確認する

一度に全部移すと、問題が起きたときに原因が分かりにくくなります。機能ごとに1つずつ移して、そのたびに動作確認をしましょう。

まとめ

functions.phpは手軽な反面、テーマに依存するという弱点があります。サイト固有の処理をmu-pluginに切り出すと、次の利点が得られます。

• テーマを変更しても、カスタム投稿タイプや独自機能が消えない
• 置くだけで有効になり、管理画面から誤って停止されない
• 機能ごとにファイルを分けて、保守しやすくなる
• テーマは見た目だけを担当し、役割がはっきりする

「データと機能はmu-plugin、見た目はテーマ」。この線引きを覚えておくだけで、長期運用するサイトの安定度が大きく変わります。次にカスタム投稿タイプを追加するときは、ぜひmu-pluginに書いてみてください。

基本構文

query_posts( array|string $query ): WP_Post[]|int[]

引数

• $query：クエリの条件（配列または文字列）

戻り値

投稿の配列。

使い方（サンプル）

query_posts( 'posts_per_page=3' );
while ( have_posts() ) {
	the_post();
}
wp_reset_query();

注意点

• メインクエリを上書きするため、二重にクエリが実行され、ページ送りが、壊れやすくなります。
• 使ったあとは、wp_reset_query() で、元に戻す必要があります。
• 新しく書くコードでは、使いません。

実務での使いどころ

• 古いテーマの、コードを理解・修正するとき。

よくあるミスと対策

• 新しいコードで、使っている。メインクエリの変更は、pre_get_posts フックを使う。
• wp_reset_query() を、呼んでいない。
• サブの一覧を作りたいだけなのに、使っている。サブの一覧は、WP_Query を使う。

NG例

query_posts( 'posts_per_page=3' ); // 元に戻していない。二重にクエリが実行される

OK例

add_action( 'pre_get_posts', function ( $query ) {
	if ( ! is_admin() && $query->is_main_query() && $query->is_home() ) {
		$query->set( 'posts_per_page', 3 );
	}
} );

使い分け早見表

関連項目

wp_reset_query()、get_posts()

公式リファレンス：query_posts() | WordPress Developer Resources

基本構文

add_rewrite_rule( string $regex, string|array $query, string $after = 'bottom' ): void

引数

• $regex：URLにマッチする、正規表現
• $query：対応するクエリ（index.php?... の形）
• $after：top か bottom（ルールを置く位置）

戻り値

戻り値はありません。

使い方（サンプル）

add_action( 'init', function () {
	add_rewrite_rule( '^shop/([0-9]+)/?$', 'index.php?post_type=product&p=$matches[1]', 'top' );
} );

注意点

• init フックの中で、呼びます。
• 追加したあとは、ルールを、一度だけ更新します（flush_rewrite_rules()、またはパーマリンク設定の保存）。
• 独自のクエリ変数を使うときは、query_vars フィルターで、登録します。

実務での使いどころ

• カスタムのURL（/shop/123/ など）を、投稿や、クエリに、結びつけるとき。

よくあるミスと対策

• init フックの外で、呼んでいる。
• 追加しただけで、ルールを更新しておらず、404になる。
• ルールの更新（flush_rewrite_rules()）を、毎回のリクエストで呼んでいる。
• 独自のクエリ変数を、登録していない。値が、取得できない。

NG例

add_action( 'init', function () {
	add_rewrite_rule( '^shop/([0-9]+)/?$', 'index.php?shop_id=$matches[1]', 'top' );
	flush_rewrite_rules(); // 毎回のリクエストで、実行される
} );

OK例

add_action( 'init', function () {
	add_rewrite_rule( '^shop/([0-9]+)/?$', 'index.php?shop_id=$matches[1]', 'top' );
} );
add_filter( 'query_vars', function ( $vars ) {
	$vars[] = 'shop_id';
	return $vars;
} );
// ルールの更新は、有効化時などに、一度だけ

使い分け早見表

関連項目

flush_rewrite_rules()、get_query_var()、register_post_type()

公式リファレンス：add_rewrite_rule() | WordPress Developer Resources

基本構文

get_allowed_mime_types( int|WP_User $user = null ): string[]

引数

• $user：ユーザーのIDまたはオブジェクト（省略すると、現在のユーザー）

戻り値

「拡張子（正規表現）=> MIMEタイプ」の配列。

使い方（サンプル）

$mimes = get_allowed_mime_types();
if ( isset( $mimes['pdf'] ) ) {
	// PDFが許可されている
}

注意点

• 配列のキーは、jpg|jpeg|jpe のように、複数の拡張子を、正規表現で並べた形です。
• 一覧は、upload_mimes フィルターで変更できます。

実務での使いどころ

• アップロードを受け付ける前に、許可された種類かを、確認するとき。
• 許可されている種類の一覧を、画面に表示するとき。

よくあるミスと対策

• 配列のキーを、1つの拡張子だと考えている（jpg|jpeg|jpe の形）。
• 一覧を、自分で決め打ちしている。

NG例

if ( isset( $mimes['jpg'] ) ) { // キーは jpg|jpeg|jpe のため、一致しない
	// ...
}

OK例

$type = wp_check_filetype( $name, get_allowed_mime_types() );
if ( $type['type'] ) {
	// 許可された種類
}

使い分け早見表

関連項目

wp_check_filetype()、wp_handle_upload()

公式リファレンス：get_allowed_mime_types() | WordPress Developer Resources

基本構文

wp_get_audio_extensions(): string[]

引数

引数はありません。

戻り値

拡張子の配列。

使い方（サンプル）

$ext = strtolower( pathinfo( $file, PATHINFO_EXTENSION ) );
if ( in_array( $ext, wp_get_audio_extensions(), true ) ) {
	// 音声ファイル
}

注意点

• 一覧は、wp_audio_extensions フィルターで変更されることがあります。
• 動画の拡張子は、wp_get_video_extensions()。

実務での使いどころ

• アップロードされたファイルが、音声かを、拡張子で判断するとき。

よくあるミスと対策

• 一覧を、自分で決め打ちしている。
• 拡張子だけで、音声かどうかを判断している。

NG例

if ( in_array( $ext, array( 'mp3', 'wav' ), true ) ) { // 一覧を、決め打ちしている
	// ...
}

OK例

if ( in_array( $ext, wp_get_audio_extensions(), true ) ) {
	// ...
}

使い分け早見表

関連項目

wp_get_video_extensions()、wp_check_filetype()

公式リファレンス：wp_get_audio_extensions() | WordPress Developer Resources

基本構文

sanitize_title_with_dashes( string $title, string $raw_title = '', string $context = 'display' ): string

引数

• $title：整える文字列
• $raw_title：使われない引数
• $context：display か save

戻り値

整えられた文字列。

使い方（サンプル）

$slug = sanitize_title_with_dashes( 'Hello World' ); // hello-world

注意点

• 通常は、sanitize_title() を使えば足ります。
• 日本語などの、英数字以外は、そのまま残らず、パーセントエンコードされた文字列になることがあります。

実務での使いどころ

• 独自の処理で、スラッグ（URL用の文字列）を、作るとき。

よくあるミスと対策

• 日本語の文字列に使い、期待した結果にならない。
• 通常は sanitize_title() で足りるのに、直接使っている。

NG例

$slug = sanitize_title_with_dashes( '日本語のタイトル' ); // 期待した結果にならない場合がある

OK例

$slug = sanitize_title( 'Hello World' ); // hello-world
// 日本語だけのタイトルは、パーセントエンコードされた文字列になる

使い分け早見表

関連項目

sanitize_title()、sanitize_key()

公式リファレンス：sanitize_title_with_dashes() | WordPress Developer Resources