この記事には広告を含む場合があります。
記事内で紹介する商品を購入することで、当サイトに売り上げの一部が還元されることがあります。
Elementorで講座一覧を作るとき、「新しい講座だけを上に出したい」「おすすめ講座だけ別枠で見せたい」と思う場面があります。静的ページならカードを手で並べ替えれば作れますが、講座が増えるほど更新作業は重くなります。古い講座が残ったり、受付終了の講座が目立つ場所に出たりすると、読者にも運用担当者にも分かりにくいページになります。
この記事では、JetEngineのQuery Builderを使って、おすすめ講座だけを条件で表示する一覧を作ります。想定するのは、講座CPTに「おすすめ」「開催日」「受付状態」を持たせ、Elementorのトップページや講座一覧ページに、今出したい講座だけを自動表示する構成です。
Query Builderは、一覧に出すデータを条件で選ぶための仕組みです。今回の例では、おすすめ=はい、開催日が今日以降、受付中という条件で講座を絞り込みます。
公式ドキュメントでは、Query Builderは投稿、ターム、ユーザー、コメント、SQLテーブル、Repeater、WooCommerce商品、REST APIで受け取った項目、CCT項目、レビューなどを条件に沿って取得する機能として説明されています。この記事では、まずElementorユーザーが使いやすいPosts Queryに絞り、講座CPTのおすすめ表示を作ります。

この記事で分かること
- Query Builderをどの場面で使うのか
- おすすめ講座表示に必要な入力項目の設計
- Posts QueryでMeta Queryを組む具体例
- ElementorのListing Gridに保存済みクエリを接続する方法
- 運用担当者がどこを更新すれば一覧が変わるのか
- 条件を増やしすぎるときの注意点
まず何を作るのか
今回作るのは、トップページや講座一覧ページに置く「おすすめ講座」ブロックです。すべての講座を出すのではなく、管理画面でおすすめにした講座、開催日がまだ先の講座、受付中の講座だけを表示します。
静的なElementorページでは、おすすめ講座のカードを3件ほど手で並べることがよくあります。見た目は早く作れますが、講座が終了したらカードを消す、次の講座を追加する、開催日順に並べ替える、といった手作業が残ります。担当者が忘れると、終了済み講座がトップに残ることもあります。
JetEngineで作る場合は、講座の情報をデータの箱に持たせ、その値を条件としてQuery Builderで拾います。Elementor側では、見た目のカードを1つ作り、Listing Gridで条件に合う講座だけを表示します。ここでの主役は、ウィジェットの見た目ではなく、どの講座を出すかを決める条件です。
JetEngineでどのデータを持たせるのか
データの箱(CPT)は course とします。講座名は投稿タイトルで管理し、本文には講座説明を書きます。Query Builderで使う値は、文章の中に埋め込まず、入力項目として分けます。

| 画面ラベル | フィールド名 | 型 | サンプル値 | 条件での使い方 |
|---|---|---|---|---|
| おすすめ | is_featured |
Switcher | true | おすすめ枠に出すか判定 |
| 開催日 | course_date |
Date | 2026-06-15 | 今日以降かを判定 |
| 受付状態 | entry_status |
Select | open / full / closed | 受付中だけ表示 |
| 表示優先度 | display_order |
Number | 10 | 同日講座の並び順に使う |
| 対象レベル | course_level |
Select | 初級 | カード内のラベル表示 |
| 申込URL | entry_url |
URL | https://example.com/apply | ボタンのリンク先 |
おすすめはSwitcherにして、管理画面ではオン・オフで切り替えられるようにします。開催日はDate型にします。受付状態はSelectにし、内部値は open、full、closed のように短くしておくと、条件で扱いやすくなります。
避けたいのは、「おすすめ講座です。6月15日開催。受付中です」のように、1つの長文フィールドへまとめて入れることです。表示するだけなら楽ですが、条件で絞る、日付順に並べる、受付終了を外す、といった処理ができません。Query Builderで使う値は、入力項目として分けておくのが基本です。
Query Builderで作る条件
今回作るクエリ名は featured_upcoming_courses とします。Query TypeはPosts Query、Post Typeは course です。公式ドキュメントでは、Posts Query Typeで投稿タイプ、投稿ステータス、検索キーワード、並び順、Meta Query、Tax Query、Date Query、Post & Page、Paginationなどを設定できると説明されています。

今回の条件はMeta Queryで作ります。おすすめがtrue、開催日が今日以降、受付状態がopen。この3つをANDでつなぐと、すべての条件を満たす講座だけが表示されます。
| 条件 | Field key/name | Compare | Value | Type |
|---|---|---|---|---|
| おすすめか | is_featured |
Equal | true |
Char |
| 開催日前か | course_date |
Greater or equal | 今日の日付 | Date |
| 受付中か | entry_status |
Equal | open |
Char |
今日の日付をどう入れるかは、サイトの設定や使うマクロによって変わります。動的タグやマクロを使う場合は、公式ドキュメントの現在の表記を確認してください。記事内では考え方として、開催日フィールドを日付型で保存し、今日以降の講座だけを対象にする、と理解すれば十分です。
並び順は、開催日が近い順にします。Order & Order Byで course_date を基準に昇順に並べる設計です。もし同じ開催日の講座が複数あるなら、2つ目の並び順として display_order を小さい順に使うと、管理画面で微調整できます。
Elementor側ではどう表示するのか
Elementorでは、講座カード用の一覧テンプレートを作ります。カードに入れる情報は、講座タイトル、開催日、対象レベル、料金、受付状態、詳細リンクです。講座名はDynamic Link、開催日や料金はDynamic Field、画像はDynamic Imageで表示できます。

ページ側にはListing Gridを置きます。公式ドキュメントでは、Listing GridのCustom QueryでUse Custom Queryを有効化し、Query Builderで作ったクエリを選ぶ流れが説明されています。今回なら、Custom Queryで featured_upcoming_courses を選びます。
この構成にすると、Elementor上のカードデザインは1つで済みます。講座が3件でも10件でも、条件に合う講座がListing Gridに入ります。表示件数を3件にしたい場合は、クエリ側またはListing Grid側の件数設定で調整します。トップページでは3件、講座一覧ページでは6件のように、ページごとに見せ方を変えることもできます。
運用すると何が楽になるのか
運用担当者は、Elementorのページを毎回開かなくても、講座編集画面で値を直せば一覧を変えられます。おすすめに出したい講座は is_featured をオンにする。受付終了なら entry_status を closed にする。開催日が過ぎた講座は条件から外れる。こうして、表示ルールをデータ側に寄せられます。

静的Elementorページでは、カードを消す、カードを追加する、順番を入れ替える、リンクを直す、日付を直す、という作業がページ編集に集中します。Query Builderを使うと、ページ編集とデータ更新の役割を分けられます。デザイナーは一覧テンプレートを整え、運用担当者は講座データを更新する、という分担がしやすくなります。
また、同じクエリを複数箇所で使えるのも便利です。トップページのおすすめ講座、講座一覧ページの上部、サイドバーのおすすめ枠などに同じ条件を使えば、表示の整合性を保ちやすくなります。ただし、全部を同じクエリにするとページごとの目的がぼやけるため、必要なら「トップ用」「一覧ページ用」のようにクエリ名を分けて管理します。
条件を増やす前に考えること
Query Builderは条件を増やせるので、つい細かく作りたくなります。たとえば、おすすめ、開催日、受付状態、カテゴリー、講師、会員ランク、価格帯、残席数、タグ、表示優先度を全部組み合わせることもできます。しかし、条件が増えるほど「なぜ表示されないのか」が追いにくくなります。
最初は3条件くらいで十分です。今回なら、おすすめ、開催日、受付状態です。これだけでも、トップページに古い講座や受付終了講座を出さない運用は作れます。カテゴリーや講師で絞り込みたい場合は、別のページで必要になってから追加してください。

もう1つ大切なのは、パフォーマンスです。件数が少ないうちは問題になりにくいですが、講座、物件、求人、商品、会員データのように件数が増えるサイトでは、複雑なMeta Queryや複数条件の並び替えが重くなることがあります。表示件数、キャッシュ、ページ分割、フィールド設計を確認し、必要ならサーバー側の性能やカスタム実装も検討します。
JetSmartFiltersとの違いも整理する
ここで混同しやすいのが、絞り込み検索(JetSmartFilters)です。JetSmartFiltersは、読者が画面上で条件を選んで絞り込むためのプラグインです。たとえば、価格帯、開催エリア、対象レベルを読者が選ぶ検索UIを作るときに使います。
今回のQuery Builderは、管理者が決めた条件で一覧に出す講座を選ぶ仕組みです。読者に選ばせる前に、そもそも一覧の対象を決める役割です。おすすめ講座だけをトップに出すならQuery Builder、読者が自分で初級講座やオンライン講座を絞り込むならJetSmartFilters、という分け方で考えると分かりやすいです。
両方を組み合わせることもできます。ただし、初心者が最初からQuery BuilderとJetSmartFiltersを同時に複雑にすると、原因調査が難しくなります。まずはQuery Builderで表示対象を決め、一覧が安定してから、必要に応じて絞り込み検索を追加するのがおすすめです。
安全面と運用面の注意
Query Builderは表示する投稿を選ぶ機能です。会員限定情報や個人情報を「条件に合わなければ表示しない」だけで守る設計にはしないでください。会員ページ、申込履歴、購入者向け資料のような情報は、表示条件だけでなく、ページ自体のアクセス制御、ユーザー権限、保存先、ログ、バックアップ、プライバシーポリシーを別途確認します。
また、Query Builderの条件は管理画面で見える形に残るため、命名が重要です。query_1、test_query のような名前にすると、半年後に何の条件か分かりません。featured_upcoming_courses のように、対象と目的が分かる名前にしてください。説明欄がある場合は、「トップページおすすめ講座。おすすめ=true、開催日>=今日、受付中のみ」と残しておくと、引き継ぎが楽になります。
どこから複雑になりすぎるのか
Query Builderが向いているのは、一覧に出すデータの条件が明確な場面です。おすすめ講座、受付中イベント、公開中の制作事例、特定カテゴリーの商品、今月のセミナーなどです。どの入力項目を見れば表示対象を判断できるかが明確なら、Query Builderで管理しやすくなります。
逆に、条件が運用担当者の判断に強く依存する場合は、無理に自動化しない方がいいこともあります。たとえば、「今週の戦略的に見せたい講座」は、数値や日付だけでは決まりません。その場合は is_featured のような手動スイッチを残し、完全自動ではなく、担当者が意思決定できる余地を残す方が実務的です。
さらに、外部API、在庫、決済、会員ランク、地域別価格のような条件まで入ると、JetEngineの標準設定だけで完結しない可能性があります。必要に応じてカスタム開発、サーバー側の処理、専用プラグイン、キャッシュ設計を組み合わせます。JetEngineやCrocoblockは便利ですが、すべての業務システムやパフォーマンス設計を代替するものではありません。
公開前にテストする順番
Query Builderの記事で見落としやすいのは、条件そのものよりテスト順です。まず、条件に合う講座、条件に合わない講座、境界線にある講座を最低1件ずつ用意します。たとえば、おすすめがオンで開催日が未来の講座、おすすめがオフの講座、開催日が昨日の講座、受付状態がclosedの講座です。この4種類を作っておくと、一覧に出るべきものと出ないべきものを確認しやすくなります。
is_featured、course_date、entry_status をそれぞれ変える[/ti]
[ti label=”3″]Query BuilderのプレビューやListing Gridで表示結果を確認する[/ti]
[ti label=”4″]表示件数、並び順、空データ時の表示を調整する[/ti]
[ti label=”5″]本番と同じタイムゾーン、キャッシュ、スマホ表示で確認する[/ti]
日付条件では、WordPressのタイムゾーン設定も確認してください。日本向けサイトなら、管理画面の一般設定でタイムゾーンが東京になっているかを見ます。開催日が今日か明日かで表示が変わる一覧では、タイムゾーンのズレがあると、夜間や早朝に意図しない表示になることがあります。Query Builderの条件が合っているのに結果が変に見える場合は、日付フィールドの保存形式、比較タイプ、サイトのタイムゾーン、キャッシュを順番に確認します。
空データ時の見え方も決めておきます。おすすめ講座が0件になったとき、見出しだけ残るとページが不自然です。Listing Gridの空表示メッセージを使う、セクションごと非表示にする、代わりに通常の講座一覧へ誘導するなど、サイトの目的に合わせて決めます。最初から複雑な出し分けにする必要はありませんが、0件の状態を放置しないことは実務ではかなり重要です。
運用担当者向けには、どの入力項目を触れば一覧が変わるのかを短くメモしておくと安心です。「トップに出したい講座はおすすめをオン」「受付終了時は受付状態をclosed」「開催日を変えたら一覧順も変わる」の3つだけでも、ページ編集を開かずに更新できます。Query Builderは制作者だけが理解していればよい設定ではなく、運用担当者が迷わずデータを直せるようにして初めて効果が出ます。公開後の確認担当も決めておくと、古い講座の残りっぱなしを減らせます。月初や新講座公開前に一覧を確認する日を決めておくと、サイト全体の見え方も安定します。管理者が交代しても迷わない形にしておくことが大切です。ここまで確認します。
この作り方が向いている人・向いていない人
向いているのは、Elementorで一覧ページを作っていて、出すカードを手作業で選ぶ運用から抜け出したい人です。講座、イベント、制作事例、求人、物件、スタッフ紹介など、一覧の条件をデータで決められるサイトに向いています。
向いていないのは、投稿数が少なく、1ページだけ手で並べれば十分なサイトです。また、条件が頻繁に変わり、担当者が毎回判断して見せたいものを選ぶ場合は、Query Builderだけで自動化するより、手動スイッチを組み合わせる方が自然です。
まとめ
JetEngine Query Builderを使うと、ElementorのListing Gridに出す講座を条件で選べます。今回の例では、course という講座CPTに、おすすめ、開催日、受付状態、表示優先度を持たせ、featured_upcoming_courses というPosts Queryでおすすめ講座だけを取得しました。
Elementor側では、講座カードの一覧テンプレートを作り、Listing GridのCustom Queryで保存済みクエリを選びます。これにより、ページを手で直さなくても、講座編集画面の値を変えるだけでおすすめ一覧を更新できます。
最初は、おすすめ、開催日、受付状態の3条件くらいから始めてください。条件を増やすほど便利になりますが、原因調査や表示速度の確認も必要になります。静的Elementorページから一歩進めるなら、まずは小さなおすすめ講座ブロックでQuery Builderの考え方をつかむのが分かりやすいです。
