JetEngine Relationsで講師と講座を関連づける方法

Elementorで講師紹介ページと講座紹介ページを別々に作っていると、「この講師が担当する講座を、講師ページにも出したい」という場面が出てきます。静的ページなら、講師ページの下に講座カードを手で並べれば一応は作れます。ただ、講座が増えたり担当講師が変わったりすると、講師ページ、講座一覧、個別講座ページをそれぞれ直す必要があります。

この記事では、JetEngineの関連づけ（Relations）を使って、講師と講座をつなぐミニ講座サイトを作る考え方を解説します。作るのは、講師詳細ページに「この講師の担当講座」を自動表示する構成です。データの箱（CPT）を2つ用意し、親子関係を決め、Elementor側では関連講座だけを一覧テンプレートで表示します。

公式ドキュメントでは、JetEngineのRelationsはCPT投稿、CCT項目、タクソノミー、ユーザーなどを関連づけられる機能として説明されています。Relation typeには一対一、一対多、多対多があり、関連した項目はQuery BuilderやListing Gridと組み合わせてフロント側に表示できます。この記事では、まずElementorユーザーが理解しやすい「講師CPTと講座CPTの一対多」に絞ります。

JetEngine公式ページを見てみる

この記事で分かること

• JetEngine Relationsをどの場面で使うのか
• 講師CPTと講座CPTを一対多でつなぐ考え方
• Relationの親、子、向きの決め方
• Elementorの講師詳細ページに関連講座を表示する流れ
• 手入力の講座リンクと、関連データ表示の違い
• 関連づけが複雑になりすぎる境界線

まず何を作るのか

今回作るのは、講師一覧と講座一覧を持つ小さな学習サイトです。講師はプロフィールを持ち、講座は開催日や料金を持ちます。そして、講師詳細ページの下部に「この講師の担当講座」を自動表示します。

静的なElementor運用では、講師ページの本文内に講座名やリンクを手入力しがちです。最初は速いのですが、講座タイトルが変わる、受付状態が変わる、講座が終了する、担当講師が増える、といった変更が起きるたびに、複数ページの整合性を確認する必要があります。

JetEngineで作る場合は、講師と講座を別々のデータとして管理します。講座側の情報を直せば、講座一覧にも、講座詳細にも、講師ページ内の関連講座一覧にも同じ情報が反映されます。ここで重要なのは、見た目を先に作り込む前に、どの情報を別データとして持つかを決めることです。

JetEngineでどのデータを持たせるのか

データの箱（CPT）は2つ作ります。1つ目は teacher、2つ目は course です。講師ページと講座ページを別々に持つことで、それぞれの一覧、詳細、検索、関連表示を作りやすくなります。

講師名や講座名は投稿タイトルで管理できます。料金はTextではなくNumberにしておくと、後から価格順に並べる、条件で絞る、といった拡張がしやすくなります。開催日もDate型にしておく方が安全です。「6月20日開催」のような文章で保存すると、表示はできますが、日付順の並び替えや期限判定がしにくくなります。

ここでRelationに持たせる情報も検討できます。公式ドキュメントでは、RelationそのものにText、Date、Time、Datetime、Textarea、Checkbox、Media、Radio、Select、Numberなどのメタフィールドを持たせられると説明されています。たとえば、講師と講座の関係に role_note を持たせ、「メイン講師」「ゲスト講師」のような関係ごとの補足を保存できます。ただし最初から入れすぎると管理が難しくなるので、最初は講師と講座の接続だけで十分です。

Relationの親と子をどう決めるか

今回のRelation名は teacher_to_course とします。親オブジェクトは講師 teacher、子オブジェクトは講座 course、Relation typeは一対多です。1人の講師が複数の講座を担当する想定だからです。

親と子は、どちらのページを起点に表示したいかで決めると分かりやすいです。今回の目的は「講師ページに担当講座を出す」ことなので、講師を親、講座を子にします。逆に「講座ページに担当講師を複数出す」ことが主目的なら、多対多や逆向きの表示も検討します。

Elementor側ではどう表示するのか

Elementor側では、まず講座カード用の一覧テンプレートを作ります。Listing sourceはPosts、From post typeは course です。カード内にはDynamic FieldやDynamic Linkを使い、講座タイトル、開催日、料金、対象レベル、詳細リンクを置きます。

次に、講師詳細ページのテンプレートを作ります。上部には講師の写真、肩書き、プロフィールを表示し、下部にListing Gridを置きます。ただし、Listing Gridで全講座を出してしまうと意味がありません。ここでQuery Builderを使い、現在表示している講師に関連した講座だけを取得します。

公式チュートリアルでは、Query BuilderでPosts Queryを作り、Post & Page内のPost InにRelated itemsマクロを使う流れが紹介されています。From Relationで作成したRelationを選び、From Objectで子オブジェクト、Initial Object ID FromでCurrent Object IDを選ぶ考え方です。これにより、現在開いている講師ページのIDを起点に、その講師に関連する講座だけを取得できます。

最後に、講師詳細テンプレートのListing GridでUse Custom Queryを有効にし、保存した courses_by_current_teacher を選びます。これで、同じ講師テンプレートを使っていても、A講師のページではA講師の講座、B講師のページではB講師の講座が表示されます。

管理画面での運用フロー

運用では、どちらの編集画面から関連づけるかを決めておきます。講師ページを中心に管理したいなら、講師編集画面で担当講座を選ぶ方が分かりやすいです。講座登録時に担当講師を決めたいなら、講座編集画面にも親を選ぶコントロールを出します。

小さなチームなら、講座を登録したあとに講師編集画面へ移動し、担当講座を追加する運用で十分です。講座数が多い場合は、講座編集画面から講師を選べるようにした方が入力漏れを減らせます。ただし、両方の編集画面で自由に作成や削除を許可すると、担当者がどこで何を変更したのか追いにくくなります。

「Require at least one child」のような必須設定は便利ですが、最初から強くしすぎない方が安全です。下書きの講師ページを作っている途中で講座が未登録の場合、保存できずに困ることがあります。公開運用が固まってから必須化する、またはチェックリストで管理する方が実務では扱いやすいです。

静的Elementorページとの違い

静的ページでは、講師ページごとに講座カードをコピーして配置します。見た目は早く整いますが、講座情報の更新が分散します。講座タイトル、開催日、料金、受付状態を直すたびに、関連する講師ページも確認する必要があります。

Relationsを使う構成では、講座情報は講座CPTに集約されます。講座の開催日を直せば、講座詳細、講座一覧、講師ページ内の関連講座カードが同じ情報を参照します。運用面では、情報の置き場所を1つに寄せられることが大きなメリットです。

ただし、Relationsは「情報の関係」を管理する仕組みであって、すべての運用を自動化するものではありません。受付数の自動更新、申込フォーム、決済、会員権限、メール通知は別の設計です。JetFormBuilderを使えば申し込みフォームや送信後アクションを組み立てられますが、この記事の範囲では、講師と講座を正しくつなぐところに集中します。

よくある設計ミス

1つ目のミスは、講師名を講座のTextフィールドに直接入れてしまうことです。たとえば講座CPTに teacher_name というTextフィールドを作り、「山田太郎」と入力する方法です。表示だけならできますが、講師プロフィールにリンクできませんし、講師名の表記ゆれも起きます。講師を独立したデータの箱にするなら、Textで名前を保存するよりRelationでつなぐ方が後から拡張しやすいです。

2つ目のミスは、何でも多対多にすることです。多対多は柔軟ですが、運用担当者が関係を把握しにくくなります。今回のように「1人の講師が複数の講座を持つ」だけなら、一対多で始める方が分かりやすいです。ゲスト講師や共同講師が増える段階で、多対多やRelationメタフィールドを検討すれば十分です。

3つ目のミスは、Relationを表示条件や検索条件まで一気に広げることです。最初は「講師ページに担当講座を出す」だけで構いません。その後、講座一覧に担当講師フィルターを付ける、講師別の人気講座を出す、会員向け講座だけを表示する、と段階的に広げる方が安全です。

どこから複雑になりすぎるのか

Relationsが向いているのは、別々の投稿タイプやデータを自然につなぎたい場面です。講師と講座、店舗とスタッフ、物件と担当者、サービスと事例、メーカーと商品などです。これらは、ページごとに手入力するより、データ同士をつなぐ方が運用が楽になります。

逆に、個人情報を含む申込履歴、会員ごとの閲覧権限、決済後のコンテンツ開放、外部システムとの同期までRelationsだけで処理しようとすると危険です。表示上は作れても、権限、ログ、バックアップ、削除フロー、プライバシーポリシー、問い合わせ対応まで設計しないと実務では使いにくくなります。

また、Relationが3段階以上になると、管理画面で何をどこに紐づけたのか分かりにくくなります。公式ドキュメントには親、子、孫の関係を扱う考え方もありますが、初心者が最初に作るなら、2つのデータの箱を一対多でつなぐところから始めるのが現実的です。

公開前に確認したい実装チェック

Relationsを使ったページは、見た目だけを確認しても不十分です。公開前には、管理画面の入力、Relationの選択、Query Builderの取得、Elementorの表示、空データ時の見え方まで順番に確認します。特に講師ページでは、関連講座が0件の講師、1件だけの講師、複数件ある講師をそれぞれ用意してテストしてください。

関連講座がない場合の表示も大切です。「担当講座はありません」と出すのか、セクションごと非表示にするのかを決めます。JetEngineの表示条件（Dynamic Visibility）を組み合わせれば、関連講座があるときだけセクションを出す設計もできます。ただし、最初から複雑な条件を入れるより、まずは関連講座の表示が正しく動くことを優先してください。

また、講師と講座を削除するときの運用も決めておきます。講座を非公開にするだけでよいのか、Relationから外すのか、完全に削除するのかで、フロント側の見え方が変わります。既存講座を削除する前にはバックアップを取り、下書きや非公開でどう表示されるかを確認します。運用担当者が複数いる場合は、「講座終了時は受付状態をclosedにする」「過去講座として残す」「講師ページには今後開催分だけ出す」のように、更新ルールを短く共有しておくと安全です。

この段階で、講師別の講座数を見せたい、講座ページに担当講師を出したい、講師一覧で担当講座数順に並べたい、といった追加要望が出ることもあります。全部を同時に作るとテスト範囲が広がります。まずは講師ページに担当講座を出すという最小構成を完成させ、そのあと逆方向の表示やフィルターを足す方が、トラブルの原因を切り分けやすくなります。小さく動かしてから広げる方が、後で説明もしやすいです。

この作り方が向いている人・向いていない人

向いているのは、Elementorで作ったページに、別データの一覧を自動表示したい人です。講師紹介、講座一覧、制作実績、店舗スタッフ、サービス別事例など、同じ情報を複数ページで使い回すサイトに向いています。

向いていないのは、1ページだけの小さなLPで、関連情報をほとんど更新しないケースです。ページ数が少なく、運用担当者が手で直しても問題ないなら、Relationsまで入れると設定の方が重く感じることがあります。JetEngineは便利ですが、設計なしで入れればすべてが楽になるわけではありません。

まとめ

JetEngine Relationsを使うと、講師と講座のような別々のデータを関連づけ、Elementor側で関連講座だけを表示できます。今回の例では、teacher と course を作り、teacher_to_course という一対多のRelationでつなぎました。講師詳細ページにはListing Gridを置き、Query BuilderのRelated itemsマクロで現在の講師に紐づく講座だけを表示します。

最初に考えるべきなのは、親子の向きです。どのページを起点に、どのデータを出したいのかを決めてからRelationを作ると、後のテンプレートやQuery Builder設定が整理しやすくなります。運用面では、講座情報を1回更新するだけで関連ページにも反映しやすくなるため、手入力の更新漏れを減らせます。

まずは講師と講座の一対多から小さく試してください。関連づけが安定してから、受付状態、フィルター、申込フォーム、会員向け表示へ広げる方が、静的Elementorページから無理なく一歩進めます。

JetEngine公式ページを見てみる