JetEngineでイベントカレンダーを作る方法と設計のコツ

イベントページをElementorで作っていると、月ごとの予定を手で並べ替える作業が地味に増えていきます。セミナー、相談会、勉強会、店舗イベントのように日付が中心になる情報は、通常のカード一覧だけだと「いつ開催されるのか」が見えにくくなります。今回作るのは、JetEngineでイベント情報を管理し、Elementor側でカレンダー表示に流し込む小さなイベントカレンダーです。

大事なのは、カレンダーの装飾よりもイベントの日付をデータとして分けることです。本文に「5月20日開催」と書くだけでは、今月の予定、来月の予定、終了済みイベントの非表示が扱いにくくなります。JetEngineのDate系フィールドを使い、開始日、終了日、受付状態、会場、申込URLを入力項目として持たせると、Elementorのカレンダー表示に接続しやすくなります。

JetEngine公式ページを見てみる

この記事で分かること

• JetEngineでイベント用のデータの箱（CPT）を作る考え方
• カレンダー表示に必要な日付フィールドの分け方
• Elementor側でイベントカードをカレンダーに配置する流れ
• 今後の予定だけ出すための条件設計
• 繰り返し予定や予約連携を最初から入れすぎない判断軸

まず何を作るのか

サンプルは、地域スクールの「イベントカレンダー」です。月ごとの体験会、オンライン説明会、講師セミナーをイベント投稿として登録し、カレンダー上に表示します。静的ページなら、今月の予定をテキストで並べ、月が変わるたびに手で直す形でも作れます。ですが、開催日が増えたり、終了済みの予定を非表示にしたり、詳細ページへ誘導したりする場合は、データとして管理した方が楽になります。

今回のデータの箱（CPT）は event、表示名は「イベント」とします。1件のイベント投稿に、開始日、終了日、会場、受付状態、申込URLなどを入力します。Elementor側では1件分のイベントカードをListing Itemで作り、JetEngineのDynamic Calendar系の表示に流し込みます。カレンダー上のイベントをクリックしたら、詳細ページや申込導線へ移動できる形にします。

JetEngineで持たせるイベントデータ

イベントカレンダーでは、日付の持たせ方が一番重要です。公式ドキュメントでもDynamic CalendarはListing ItemやDate Fieldと組み合わせて使う流れが説明されています。イベント名、会場、説明文だけではなく、開始日と終了日を別々の項目として用意します。1日だけのイベントでも、将来2日間開催や連続講座を扱う可能性があるなら、終了日を最初から作っておくと後で崩れにくいです。

ここで気をつけたいのは、日付の保存形式です。JetEngine側のDateフィールド設定では、カレンダー表示や比較条件で扱いやすい形式を選ぶ必要があります。timestampで保存する設定を使う場合は、後で「今日以降」などの比較がしやすくなります。ただし既存サイトで途中から形式を変えると、過去データの扱いが面倒になることがあります。公開前にテスト投稿を数件作り、表示と並び順を確認してから本番に入れるのが安全です。

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

Elementor側では、まず1件分のイベントカードを作ります。Listing Itemの中に、イベント名、開始日、会場、受付状態、詳細リンクを配置します。日付はDynamic Fieldで出し、受付状態は「受付中」「満席」「終了」のように短いラベルで見せると読みやすくなります。申込URLを持たせる場合は、Dynamic Linkでボタンに接続できます。

次に、カレンダー表示用のウィジェットにこのListing Itemを指定します。カレンダーは情報量が増えるとすぐ詰まるので、1日セルの中に長い説明文を入れない方がよいです。カレンダー内ではイベント名と短い状態だけを見せ、詳しい説明は詳細ページへ逃がします。スマホでは月表示が窮屈になるため、リスト表示への切り替えや、詳細ページへの導線も確認しておきます。

今後の予定だけを出す条件

イベントカレンダーでよくある失敗は、終了済みイベントがいつまでも目立ってしまうことです。アーカイブとして残したい場合は別ですが、申し込み導線として使うなら、今後の予定を中心に見せる方が親切です。Query Builderや表示条件を使う場合は、post_type = event、event_start_date >= 今日、entry_status = open のような条件を考えます。

もちろん、満席イベントを完全に消すのか、「満席」として残すのかは運用次第です。人気感を見せたいなら満席表示は意味があります。ただし、申込ボタンが押せる状態のまま残ると問い合わせ対応が増えます。表示条件でボタンだけ非表示にする、またはボタン文言を「キャンセル待ち」に変えるなど、運用ルールと画面の動きを合わせておく必要があります。

JetEngineのDynamic Visibilityを使えば、受付状態によってボタンやラベルを出し分けられます。たとえば entry_status が open のときだけ申込ボタンを表示し、full のときは「満席」ラベルだけ出す形です。ここでも、英語の機能名を覚えることより、どの状態で何を見せるかを先に決める方が大事です。

運用すると何が楽になるのか

静的なElementorページでは、イベントが増えるたびにカレンダー風の表を手で直したり、終了した予定を消したり、詳細ページへのリンクを差し替えたりします。JetEngineでイベント投稿を中心にすると、更新担当者は「イベント」を1件追加するだけで済みます。開始日、会場、受付状態、申込URLを入力すれば、カレンダーと詳細ページの表示が同じ情報を参照します。

この形にすると、イベントが毎月増えるサイトほど管理が楽になります。講師が変わった、会場が変わった、受付終了にしたい、といった修正もイベント投稿に集まります。デザインを編集する人と、イベント情報を更新する人を分けられるため、Elementorのレイアウトをうっかり崩す事故も減らせます。

管理画面で迷わない入力ルールを作る

イベントカレンダーは、入力する人が複数になるほど表記ゆれが出ます。「6/12」「2026年6月12日」「六月十二日」のように本文へ手入力していると、見た目は似ていても並び替えや条件判定には使えません。JetEngineで開始日を日付フィールドとして分けるのは、この表記ゆれを避けるためでもあります。管理画面では、イベント名、開始日、終了日、会場、受付状態、申込URLを埋める順番を決めておくと運用が安定します。

フィールド説明も入れておきます。event_start_date には「カレンダーに配置される日付です」、event_end_date には「1日開催でも開始日と同じ日を入れてください」、entry_status には「受付中のときだけ申込ボタンを出す設定にしています」と書く。こうした短い説明があるだけで、担当者がElementorの画面を触らずに更新しやすくなります。

イベント画像を使うなら、画像の有無も運用ルールに含めます。カレンダーのセル内では画像を出さず、詳細ページや下部の一覧だけ画像を出す方が読みやすいこともあります。カレンダーの1日セルは狭いので、見た目を盛り込みすぎるとスマホで読みにくくなります。まずは日付、イベント名、受付状態だけをカレンダー上に出し、詳細情報は詳細ページへ逃がすのが扱いやすいです。

静的な予定表との違い

静的なElementorページで予定表を作る場合、月が変わるたびに手で行を入れ替えたり、終了したイベントを消したりします。数件なら問題ありませんが、毎月のイベントがあるサイトでは、過去の予定が残ったり、申込リンクだけ古いままだったりしがちです。しかも同じイベントを「トップページ」「イベント一覧」「詳細ページ」に書いていると、修正漏れが起きます。

JetEngineでイベント投稿を中心にすると、イベント情報を1件ずつ管理し、Elementorはその情報を表示する役になります。イベントを追加すればカレンダーに出る。受付状態を変えればボタンやラベルの出し方が変わる。終了済みにすれば一覧から外せる。こうした流れを作れるのが、静的な予定表との大きな違いです。ただし、設定した条件が間違っていると必要なイベントまで消えてしまうため、テスト投稿での確認は必須です。

実装前のチェックリスト

• イベントは単発だけか、複数日開催もあるか
• 終了済みイベントを非表示にするか、アーカイブとして残すか
• 満席イベントを消すか、満席ラベルとして残すか
• 申込URLは外部フォームか、WordPress内のフォームか
• スマホでは月表示とリスト表示のどちらを優先するか
• 担当者がイベント投稿だけで更新できる状態になっているか

このチェックをせずにカレンダーを作り始めると、あとから条件分岐が複雑になります。特に「終了済みだけどレポート記事として残したい」「満席だけどキャンセル待ちは受けたい」のような運用は、単純な表示条件だけでは足りないことがあります。最初は小さく、単発イベントと受付状態の出し分けまでに絞る方が安全です。

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

イベントカレンダーは、最初は単発イベントだけに絞ると分かりやすいです。繰り返し予定、複数日イベント、会員別表示、申込フォーム連携、残席管理まで同時に入れると、カレンダーの見た目より運用ルールの方が難しくなります。公式ドキュメントにも複数日表示や繰り返しイベントに関する説明がありますが、最初の1本目から全部入れる必要はありません。

特に予約や個人情報を扱う場合は慎重です。JetEngineで表示の土台を作ることはできますが、セキュリティ設計、個人情報の保管、通知メール、キャンセル対応、決済処理まで自動で完成するわけではありません。必要であれば、申し込みフォーム（JetFormBuilder）などを別記事の範囲として検討し、フォーム送信後の保存先や通知先も分けて設計します。

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

向いているのは、イベントが毎月増え、開催日を中心に見せたいサイトです。セミナー、スクール、店舗イベント、相談会、オンライン説明会などは相性がよいです。1年に数回しか開催しないイベントなら、通常の投稿一覧や固定ページで十分なこともあります。動的化するほど更新が楽になるかを先に見てください。

また、複数スタッフがイベントを登録する場合は、入力ルールを決める必要があります。イベント名の書き方、開始日と終了日の入れ方、満席時の処理、申込URLの確認、公開前チェック。ここを決めずに項目だけ増やすと、カレンダーは作れても運用が荒れます。最初は項目を少なくし、実際に2か月分くらい登録してから広げるのがおすすめです。

公開前に確認したい表示崩れ

イベントカレンダーは、サンプルデータが少ない状態だと問題が見えにくいです。1日に複数イベントが入る日、イベント名が長い日、満席イベント、終了済みイベント、会場名が長いイベントをテスト投稿として入れてください。カレンダーセルの中で文字が詰まる場合は、セル内の情報を減らし、詳細ページへ移動させる方が読みやすくなります。

スマホでは月表示がかなり狭くなります。カレンダーをそのまま表示するより、直近イベントだけを下に一覧で出す方が使いやすいケースもあります。JetEngineで作ったイベントデータは、カレンダーだけでなく通常のListing Gridにも使えるので、PCではカレンダー、スマホでは直近一覧を強める、という設計もできます。ここまで考えると、単なるデザインではなく運用に合わせた動的サイトになります。

イベント運用では、日付変更の扱いも先に決めてください。開催日が変わったとき、古い日付のイベントを複製して新しい日付を作るのか、同じ投稿の日付だけを直すのかで、過去の案内や検索結果の見え方が変わります。告知済みのイベントなら、本文内に「日程変更のお知らせ」を残した方がよい場合もあります。単に日付フィールドだけを直せば十分なケースと、参加者への案内が必要なケースを分けておくと、更新担当者が迷いにくくなります。

納品時には、開始日、終了日、受付状態、申込URLがどの表示に使われているかをメモしておくと後の保守が楽です。「開始日はカレンダー配置」「受付状態はボタン表示」「申込URLは詳細ページの導線」という対応表があれば、別の担当者が引き継いでも壊しにくくなります。JetEngineの設定は便利ですが、運用メモがないと数か月後に意味が分からなくなりがちです。小さな保守メモが、公開後の混乱をかなり減らします。

まとめ

JetEngineでイベントカレンダーを作るなら、まずイベントのデータ構造を決めます。event というデータの箱を作り、開始日、終了日、会場、申込URL、受付状態を分けて持たせる。Elementor側では1件分のイベントカードを作り、カレンダー表示に接続する。この流れにすると、静的な予定表を毎月手で直す作業から抜け出しやすくなります。

最初から予約管理や繰り返し予定まで広げる必要はありません。まずは単発イベントを正しく出し、終了済みや満席の扱いを決める。ここまで整うだけでも、Elementorサイトのイベント運用はかなり管理しやすくなります。

JetEngine公式ページを見てみる