tax_queryとは？カテゴリ・タグ・カスタムタクソノミーで絞り込む方法

tax_queryは何のために指定するのか

WordPressの投稿には、カテゴリやタグのような「分類」を付けられます。さらに、商品ジャンル、イベント地域、制作実績の種類のように、サイト独自の分類を作ることもあります。このような分類の仕組みを、WordPressではタクソノミーと呼びます。

tax_queryは、WP_Queryで「どのタクソノミーの、どのタームに属する投稿を取得するか」を指定するための書き方です。たとえば「newsカテゴリの記事だけ」「beginnerタグの記事だけ」「event_areaがtokyoのイベントだけ」のような絞り込みに使います。

ここで混同しやすいのが、post_typeとの違いです。たとえばeventは取得する投稿タイプ、event_areaは分類の仕組み、tokyoは分類内の具体的なタームです。post_typeで取得する種類を決め、tax_queryでその中を絞ります。最初は1つのタクソノミーと1つのタームだけで試してください。

価格や開催日のように、分類ではなく投稿ごとの保存値で絞り込む場合は、tax_queryではなくmeta_queryの基本を使います。管理画面で似た入力欄に見えても、分類とカスタムフィールドでは確認する場所が違います。

tax_queryの基本構文

tax_queryは、WP_Queryの$argsの中に書きます。重要なのは、tax_queryの中にさらに配列を入れることです。公式リファレンスでも、tax_queryはタクソノミー条件の配列を持つ形として説明されています。

まずは、通常投稿のうちnewsカテゴリだけを取得する形で構造を見ます。taxonomyで分類名、fieldで指定方法、termsで対象タームを指定します。

$args = [   'post_type'      => 'post',   'posts_per_page' => 5,   'tax_query'      => [      [         'taxonomy' => 'category',         'field'    => 'slug',         'terms'    => 'news',      ],   ],]; $query = new WP_Query( $args );

tax_queryそのものが条件の入れ物で、その中の配列1つが「1つのタクソノミー条件」です。配列を読む前に$args全体を確認したい場合は、WP_Queryの基本構文へ戻ってください。

fieldを省略した場合の初期値はterm_id、operatorを省略した場合の初期値はINです。この記事では値の意味が読み取れるようにfield => ‘slug’を明示しています。最小形で動かし、必要になってからNOT INやANDを追加すると、挙動の差を確認しやすくなります。

カテゴリ・タグ・カスタム分類の違い

3つの違いは主にtaxonomyへ書く値です。tagはWP_Queryのタグ専用引数ですが、tax_query内で使う標準タグのtaxonomy名はpost_tagです。カスタムタクソノミーでは、管理画面の表示名やURL用slugではなく、登録時のtaxonomy keyを使います。

カスタム投稿とカスタム分類を組み合わせる

次の例では、カスタム投稿タイプeventの中から、カスタムタクソノミーevent_areaのタームtokyoが付いた投稿を取得します。event、event_area、tokyoは例なので、実際の登録keyとタームスラッグへ置き換えてください。

$args = [   'post_type'      => 'event',   'posts_per_page' => 6,   'tax_query'      => [      [         'taxonomy' => 'event_area',         'field'    => 'slug',         'terms'    => 'tokyo',      ],   ],]; $event_query = new WP_Query( $args ); if ( $event_query->have_posts() ) {   echo '<ul>';    while ( $event_query->have_posts() ) {      $event_query->the_post();       echo '<li><a href="' . esc_url( get_permalink() ) . '">';      echo esc_html( get_the_title() );      echo '</a></li>';   }    echo '</ul>';} wp_reset_postdata();

このコードでは、post_typeとtax_queryを組み合わせています。post_typeでイベント投稿を対象にし、その中からevent_areaがtokyoの投稿だけを絞り込んでいます。

eventは投稿タイプ、event_areaは分類、tokyoはその分類に属するタームです。先ほどの表と同じ3段階で読めば、どこを自分の値へ変えるか判断できます。

複数タームで絞り込む方法

termsには配列も指定できます。ただし、配列にしただけでは全件一致になりません。初期値のoperator => ‘IN’ではどれかに一致、ANDではすべてに一致、NOT INでは指定タームを除外します。

$args = [   'post_type'      => 'post',   'posts_per_page' => 5,   'tax_query'      => [      [         'taxonomy' => 'category',         'field'    => 'slug',         'terms'    => [ 'news', 'column' ],         'operator' => 'IN',      ],   ],]; $query = new WP_Query( $args );

このコードでは、termsにnewsとcolumnを指定しています。operatorがINなので、どちらかのカテゴリに属している投稿が対象になります。

複数タームでは「どれか」「すべて」「除外」のどれかを日本語で決めてからoperatorへ置き換えます。条件が増えるほど0件の原因を追いにくくなるため、最初はINと1タームで動作を確認してください。

複数の分類条件はrelationでつなぐ

relationは、複数のtaxonomy clause同士をANDまたはORでつなぐ指定です。1つのclause内で複数のtermsをどう判定するかはoperatorの役割であり、relationとは別です。

まずカテゴリだけ、次にタグだけで取得できるかを確認してから組み合わせてください。2条件やネストを含む完成コードは、次の専用記事へ分けています。

詳しく確認tax_queryのrelation AND / ORの違いAND / ORの組み方を見る →

値の指定方法と取得範囲

fieldはslugから始めると分かりやすい

fieldは、termsに書いた値を何として解釈するかを指定します。公式リファレンスでは、term_id、name、slug、term_taxonomy_idなどが選択肢として示されています。

初心者向けには、まずslug指定がおすすめです。タームの表示名は後から変わることがありますが、スラッグはURLや管理上の識別子として扱いやすく、コード上でも意味が読み取りやすいからです。

注意したいのは、fieldとtermsの組み合わせです。fieldがslugならtermsにはタームスラッグ、fieldがterm_idならタームIDを書きます。この組み合わせが逆だと意図した結果にならないため、表示されないときは最初に確認してください。

include_childrenは階層タクソノミーで意識する

カテゴリのような階層を持てるタクソノミーでは、親タームと子タームの関係があります。tax_queryには、子タームを含めるかどうかを指定するinclude_childrenがあります。

include_childrenの初期値はtrueです。親タームだけへ限定する要件なら、同じ条件配列に’include_children’ => falseを加えます。「親カテゴリを指定したのに子カテゴリの記事も出る」場合は、taxonomyが階層型か、この値が要件に合うかを確認してください。

category_nameやtagとの使い分け

カテゴリやタグだけの簡単な絞り込みなら、必ずしもtax_queryを使う必要はありません。WP_Queryにはカテゴリ用、タグ用の専用引数も用意されています。短く読みやすいコードにしたい場合は、それらで十分なこともあります。

しかし、カスタムタクソノミーを使う場合や、カテゴリとタグをAND / ORで組み合わせたい場合は、tax_queryの方が適しています。条件が増えても同じ形で整理できるため、後から読み返したときに意図を追いやすくなります。同じ分類へ専用引数とtax_queryを重ねると条件が厳しくなるため、どちらか一方へそろえてください。

専用引数とtax_queryの選び方は、比較記事が公開された後に次の案内から確認できます。

tax_queryで表示されないときの確認順

tax_queryでよくあるトラブルは、「エラーは出ないのに記事が表示されない」というものです。この場合、コード全体を一気に疑うより、条件を1つずつ確認した方が早く原因に近づけます。

特に多いのは、taxonomy名の間違い、fieldとtermsの組み合わせ違い、タームスラッグの間違い、relationやoperatorで条件が厳しくなりすぎているケースです。

複数条件のまま調べると、どの条件で外れたのか分かりません。1条件、1タームで対象IDを確認し、条件を1つずつ戻します。

公式資料で確認したいポイント

tax_queryはWP_Queryの「Taxonomy Parameters」に含まれる指定です。使えるキーやoperator、relationの意味は公式リファレンスで確認できます。

また、内部的にはタクソノミー条件を扱うWP_Tax_Queryというクラスもあります。通常の記事実装ではWP_Queryのtax_queryとして書くことが多いですが、仕様の理解を深めたい場合はWP_Tax_Queryのリファレンスも参考になります。

tax_queryは分類条件を整理するための書き方

tax_queryは、カテゴリ、タグ、カスタムタクソノミーで投稿を絞り込むための重要な指定です。最初は配列の入れ子が難しく見えますが、taxonomy、field、termsの3つを押さえると基本形は読みやすくなります。

実装では1つのタクソノミー条件で動作確認し、operator、relation、include_childrenを必要に応じて追加します。表示されないときは最小条件へ戻せば、どの追加条件で0件になったかを追えます。