この記事には広告を含む場合があります。
記事内で紹介する商品を購入することで、当サイトに売り上げの一部が還元されることがあります。
料金表や比較表をElementorで静的に作ると、最初はきれいに見えます。問題は、コース名、価格、対象者、特典が変わるたびに、複数ページの表を手作業で直す必要が出てくることです。
今回はJetEngineのTables Builderを使い、スクール料金比較表をデータから自動表示する構成で考えます。作るのは、英会話スクールや講座サイトでよくある「ライト」「スタンダード」「プロ」の比較表です。
静的な表をすべて否定する必要はありません。コースが3つだけで変わらないなら、Elementorの表でも十分です。ただ、コースの追加、価格改定、表示条件、絞り込みを考えるなら、表をデータとつなげて管理した方が修正漏れを減らせます。
この記事で作るもの
- スクール料金を比較する動的な表
- コース情報を管理するデータの箱と入力項目
- Query Builderで公開中のコースだけを取得する考え方
- Tables Builderで列を作り、Elementorに表示する流れ
- 表を便利にしすぎて複雑になる境界線
まず何を作るのか
例として、オンラインスクールの料金比較表を作ります。比較するコースは3種類です。ライトプラン、スタンダードプラン、プロプランを用意し、それぞれ月額料金、対象者、受講回数、サポート内容、申込リンクを表に出します。
静的なElementor表なら、1つのページ内に直接テキストを入力します。これでも公開はできますが、価格改定が起きたときに、トップページ、料金ページ、キャンペーンページ、講座詳細ページの表を全部直す必要が出ます。JetEngineでコース情報をデータとして持たせると、管理画面のコース情報を直すだけで、表示側を揃えやすくなります。
Tables Builderは、JetEngineの中で動的な表を作る機能です。公式ドキュメントでは、Query Builderで取得したデータを元に表を作り、Elementor、ブロックエディター、Bricksなどに表示できる流れが案内されています。この記事では、Elementorユーザー向けに必要な部分へ絞ります。
JetEngineでどのデータを持たせるのか
まず、コース情報を school_course というデータの箱（CPT）で管理します。各コースを1件の投稿として登録し、料金や対象者を入力項目として分けます。表に出したい情報を1つの長い本文に入れるのではなく、並べ替えや表示に使いやすい形で分けるのが大切です。
| 項目 | フィールド名 | タイプ | サンプル値 |
|---|---|---|---|
| コース名 | course_name |
Text | スタンダード |
| 月額料金 | monthly_price |
Number | 12800 |
| 受講回数 | lesson_count |
Number | 月4回 |
| 対象者 | target_level |
Select | 初心者 / 中級者 / 仕事向け |
| おすすめ表示 | is_recommended |
Switcher | true |
| 受付状態 | plan_status |
Select | 公開中 / 停止中 |
料金をTextではなくNumberにしておくと、並び順や条件指定に使いやすくなります。対象者を自由入力にすると表記ゆれが起きやすいので、Selectで選択肢を固定します。比較表で重要なのは、見た目より先に比べる軸を決めることです。
Query Builderで表に出すデータを決める
Tables Builderでは、先にQuery Builderで表の元になるデータを用意します。ここでは、school_course の中から公開中のコースだけを取得する想定にします。
| 設定 | 値の例 | 理由 |
|---|---|---|
| Query Type | Posts Query | CPTのコース情報を取得するため |
| Post Type | school_course |
料金比較用のデータの箱 |
| Meta Query | plan_status = active |
停止中のコースを表に出さないため |
| Order By | menu_order または monthly_price |
表示順を安定させるため |
| Posts Per Page | -1 または必要件数 |
比較対象をすべて表示するため |
公式のTables Builder概要でも、まずQuery Builderでカスタムクエリを作り、そのクエリを表のデータ元として選ぶ流れが説明されています。ここを曖昧にすると、表の列を作っても「何のデータを表示しているのか」が分かりにくくなります。
Tables Builderで列を作る
次に、Tables Builderで新しい表を作ります。名前は course_price_table としておきます。Data Queryには、先ほど作ったコース取得用のQueryを選びます。データを取得したら、表の列を追加します。
| 列名 | Column Content | Data Source | 表示例 |
|---|---|---|---|
| コース | Raw Value | course_name |
スタンダード |
| 月額 | Raw Value | monthly_price |
12,800円 |
| 回数 | Raw Value | lesson_count |
月4回 |
| 対象者 | Raw Value | target_level |
仕事向け |
| 申込 | Template | 申込ボタン用テンプレート | 申込ボタン |
Tables Builderでは、列の内容としてRaw ValueやTemplateを使えます。シンプルな文字や数値はRaw Valueで十分です。画像、ボタン、装飾を含めたい列は、一覧テンプレート（Listing template）を使う考え方になります。最初から全列をテンプレート化すると管理が重くなるため、必要な列だけに絞ります。
Elementor側ではどう表示するのか
Elementor側では、料金ページにDynamic Tableウィジェットを置き、作成した表を選びます。表のヘッダーを表示するか、フッターにも列名を出すか、横スクロールを許可するかを確認します。料金比較表はスマホで横幅が足りなくなりやすいので、公式設定にある横スクロール系のオプションをまず使うのが自然です。
料金ページの構成としては、表の前に「各コースの違い」、表の後に「選び方」と「相談導線」を置くと読みやすくなります。表だけを置くと、初心者にはどのコースが合うのか判断しにくいからです。
おすすめコースを強く見せたい場合も、表の全体を派手にするより、is_recommended を使っておすすめ行だけラベルを付ける程度にします。ここで複雑な装飾を作り込みすぎると、あとで価格改定や行追加をしたときに崩れやすくなります。
運用すると何が楽になるのか
動的な比較表にすると、管理者はコース情報を1か所で直せます。月額料金が変わったとき、静的な表を各ページで探して直す必要が減ります。コースを一時停止したい場合も、plan_status を停止中にすれば、Query Builderの条件から外せます。
特に、キャンペーンや季節講座があるサイトでは効果が出ます。新しいコースを追加し、必要な入力項目を埋めるだけで、同じ表のルールに沿って表示できます。表の見た目とデータの管理を分けられるため、編集担当者がテキストを直接触って表を壊すリスクも減ります。
絞り込み検索を足すときの考え方
比較表に条件を足したくなることがあります。たとえば「初心者向けだけ」「仕事向けだけ」「月額1万円以下だけ」のような絞り込みです。この場合、絞り込み検索用のプラグインであるJetSmartFiltersと組み合わせる選択肢があります。Tables Builderの公式ページでも、表のフィルタリングにはJetSmartFiltersが関係することが案内されています。
ただし、最初から絞り込み検索まで入れる必要はありません。比較対象が3〜5件なら、表を見れば十分です。10件以上になり、対象者や価格帯で探したい読者が増えてから、絞り込み検索を検討します。プラグインを増やすほど設定箇所も増えるため、読者にとって本当に必要な条件から始めます。
絞り込みを入れるなら、target_level や monthly_price のように、最初からデータとして分けておいた項目が役立ちます。自由入力の長文にしてしまうと、あとから絞り込みに使いにくくなります。
どこから複雑になりすぎるのか
複雑になりすぎる境界は、表を見る読者が比較できなくなるところです。制作者側は多くの情報を入れたくなりますが、列が多すぎるとスマホで読みにくくなります。料金、回数、対象者、主要サポート、申込ボタンくらいから始めるのが現実的です。
次の状態になったら、表ではなく別の見せ方を考えます。
- 列が8個以上になり、スマホで横に長くなりすぎる
- 1つのセルに長文説明を入れている
- 料金条件が複雑で、表だけでは誤解される
- 申込可否、在庫、権限、会員状態まで同じ表で制御している
- 表示速度に影響するほどデータ件数や条件が増えている
JetEngineは動的な表を作る土台になりますが、料金体系の設計、法務表記、個人情報、決済、会員権限、パフォーマンス調整まで自動で解決するものではありません。大きな比較サイトや会員別価格を扱う場合は、権限設計やキャッシュ、検索条件も含めて慎重に見ます。
公開前に確認すること
公開前には、コースを追加、編集、停止するテストをします。新しいコースを追加したときに表へ出るか。停止中にしたコースが出なくなるか。料金を変更したときに表の表示も変わるか。スマホで横スクロールが使えるか。申込ボタンのリンク先が正しいか。これらを確認します。
また、価格表示は特に注意が必要です。税込か税別か、月額か一括か、初期費用があるかを本文で説明します。表の中にすべて詰め込まず、表の前後で補足する方が読みやすくなります。
バックアップも忘れないでください。既存サイトでCPTや入力項目を変えると、表示側の表に影響します。まずテスト環境で作り、運用担当者が管理画面から安全に更新できるかを見てから本番へ反映します。
この構成が向いているケース
- コース、料金、プラン、スペックなどを比較したいサイト
- 価格や表示状態を管理画面から更新したいサイト
- 同じ比較表を複数ページで使い回したいサイト
- 将来的に絞り込み検索や並び替えを足したいサイト
逆に、1ページだけの簡単な料金表なら、Elementorの静的な表で十分な場合もあります。JetEngineで作る価値が出るのは、データの更新回数、使い回し、条件表示、管理者の修正負担が増えてきたときです。
まとめ
JetEngineのTables Builderを使うと、コース情報や料金情報をデータとして管理し、比較表としてElementorページへ表示できます。今回の例では、school_course というデータの箱を作り、monthly_price、target_level、plan_status のような入力項目を用意しました。
Query Builderで公開中のコースだけを取得し、Tables Builderで列を作り、ElementorのDynamic Tableウィジェットで表示する。この流れにすると、静的な表を何度も直す作業を減らせます。最初は列数を絞り、絞り込み検索や複雑な条件は必要になってから足すのが安全です。
