セミナーや体験会の日程をAI検索で誤案内されないための情報の整え方

セミナーや体験会を公式サイト、SNS、予約サービスで告知していると、日程変更後も古い案内だけが残ることがあります。読者が迷うだけでなく、検索サービスや生成AIが参照できる情報にも食い違いが生まれます。

最初に「公式イベントページ」を決める

まず、日程や会場を確認するときの基準となるURLを1つ決めます。SNS投稿や予約サービスだけに情報を置くと、変更後にどこが最新なのか判断しにくくなります。自社が継続して管理できる公式サイトのページを基準にし、ほかの告知からそのURLへ案内すると整理しやすくなります。

ここからはAI BRAND CHECK運営者による実務上の提案です。公式ページの冒頭付近に、少なくとも次の項目を文章として表示することを推奨します。

• イベントの正式名称
• 開始日時と終了日時、必要に応じてタイムゾーン
• 会場名、住所、入場方法。オンライン併用なら参加方法の区別
• 主催者名と問い合わせ先
• 対象者、定員、料金、申込期限、キャンセル条件
• 「予定どおり」「中止」「延期」「日程変更」など現在の状態
• 最終更新日

料金や申込条件は、税の扱い、材料費の有無、同伴者の条件など、誤解が起きやすい範囲まで書きます。未定の項目を推測で埋めず、「決まり次第このページで案内」と範囲を限定することも大切です。

1開催1URLで日時と会場を明確にする

GoogleのEvent構造化データの公式資料では、イベントごとに固有のURLを用意し、そのページを1つのイベントに集中させることが技術要件として示されています。また、日を分けて個別に販売する複数公演は、それぞれ別のEventとして扱うよう案内されています。

これらを踏まえ、本記事では、同じ講座を毎月開く場合でも「講座一覧」だけで済ませず、各開催回の詳細ページを作る方法を推奨します。例えばページタイトルを「○○講座｜2026年10月15日開催」のようにし、URLも開催回を区別できる形にします。過去ページの日時だけを新しい日付へ上書きすると、以前の申込者が参照していた内容や外部リンクとの関係が分かりにくくなるためです。

公式資料では、イベント名、開始日時、会場が正確であることが求められています。構造化データだけでなく、人が読む本文にも年月日、曜日、開始・終了時刻、会場名、住所を省略せず表示します。「次の日曜」「駅前会場」のように時期や文脈で意味が変わる表現は、補助的な案内に留めると安全です。

中止・延期・日程変更ではページを消さない

変更が発生したときにページを削除すると、古いSNS投稿やメールから訪れた人が、イベントがなくなったのか、URLが変わったのかを判断できません。実務上は元のページを残し、冒頭に現在の状態、変更内容、更新日、申込者への対応窓口を明記すると整理しやすくなります。

Googleの公式資料では、イベント状態が変わっても、識別に必要な元の開始日時や会場を安易に削除しないよう説明しています。中止時は元の情報を保って EventCancelled を設定し、延期先が未定なら元の開始日時を残して EventPostponed を使います。新しい日程が決まった場合は開始・終了日時を更新し、EventRescheduled と previousStartDate で変更前の日付を示せます。

状態	読者に見せる案内	構造化データの整理例
予定どおり	開催日時と会場を最新状態で表示	EventScheduled
中止	中止、更新日、申込者への対応を冒頭に表示	元の日時・会場を保ち EventCancelled
延期・新日程未定	延期と未定であることを明示	元の開始日時を保ち EventPostponed
新日程へ変更	新旧の日程と更新日を表示	新しい日時、EventRescheduled、必要に応じて previousStartDate

表の構造化データ欄はGoogle公式資料をもとにした整理です。実際の本文ではコード値だけを置かず、「中止」「新日程は○月○日」のように、読者がすぐ理解できる表示を優先してください。

これらの状態値の語彙は、Schema.orgのEventStatusTypeにも定義されています。Googleのイベント機能へ実装する場合は、Schema.orgの定義だけで判断せず、Google側の対象地域、対応状態、個別ガイドラインも併せて確認します。

イベントの中止・延期だけでなく、終了したサービスやキャンペーンのURLをどう扱うかは、終了したサービスページの整理手順でも詳しく整理しています。

構造化データは見えている本文と一致させる

GoogleのEvent仕様では、検索のイベント機能に必要な項目として、会場、イベント名、開始日時が示されています。終了日時、状態、主催者、申込先なども、該当する場合は適切なプロパティで補えます。Schema.orgのEvent定義には、イベントを表す各プロパティの意味が掲載されています。

重要なのは、コードだけを正しくすることではありません。Googleの構造化データ一般ガイドラインでは、マークアップする内容を読者にも見える状態にし、ページ本文を正確に表すこと、時間に依存する情報を最新に保つことが求められています。本文が「10月15日」、構造化データが「10月22日」なら、どちらか一方だけを直しても整合しません。

これらを踏まえ、本記事では、CMSやプラグインでEventを出力する場合も、保存後に本文と出力内容を照合することを推奨します。確認対象は、名称、開始・終了日時、タイムゾーン、会場名、住所、開催状態、料金、申込URLです。日程変更のたびに同じチェックを行えるよう、担当者と確認欄を運用表に用意しておくと漏れを減らしやすくなります。

なお、Googleは構造化データが正しくても検索結果への表示を保証しないと明記しています。構造化データの導入自体を、AI回答の修正や検索順位上昇と結びつけて断定しないようにします。

外部の告知は公式ページを基準に揃える

イベント情報は、公式サイト以外にもSNS、予約サービス、地域ポータル、メール、印刷物などへ広がります。すべてを同時に更新できない場合は、まず公式ページを更新し、その後に申込経路と閲覧数の多い告知先から順に修正します。これは公式資料に定められた順位ではなく、AI BRAND CHECK運営者による実務上の提案です。

1. 公式イベントページの本文と更新日を直す
2. 予約・決済ページの日程、会場、受付状態を直す
3. 構造化データの出力を確認する
4. SNSの固定投稿やプロフィールリンクを直す
5. 地域ポータルなど自社で修正できる掲載先を直す
6. 申込済みの人へ、契約や運用に沿った方法で個別連絡する

古いSNS投稿を削除できないときは、訂正投稿を出して公式ページへ誘導します。画像の中だけに変更情報を入れず、投稿本文にも新しい日時と公式URLを書くと、人にも機械にも内容が伝わりやすくなります。

公開前と変更時の確認手順

公開前は、担当者が次の順番で確認すると整理しやすくなります。

1. 本文：名称、年月日、曜日、開始・終了時刻、会場、住所、申込条件を声に出して照合する
2. 申込先：予約枠、料金、定員、締切、受付状態が本文と同じか確認する
3. 検索向け設定：ページが公開後にクロール可能か、Eventを使うなら本文と一致しているか確認する
4. 外部告知：主要なSNSや掲載先が公式ページへつながっているか確認する
5. 変更手順：中止・延期時に誰がどこを更新し、申込者へ連絡するか決めておく

構造化データを実装した場合、Google公式資料ではリッチリザルト テストやURL検査ツールで確認する手順が案内されています。ただし、ツールでエラーがないことは、特別表示やAI回答の正確性を保証するものではありません。実務上は、技術テストと人による本文確認を別々の工程として残すことを推奨します。

まとめ

イベント情報では、構造化データを追加する前に、最新情報を確認できる公式ページを決めることが出発点です。1開催1URLで日時・会場・申込条件を明示し、変更時にはページを残して現在の状態と更新日を伝えます。そのうえで、本文、Event構造化データ、予約ページ、外部告知を同じ内容へ揃えます。

この整備はAIでの表示を約束するものではありませんが、読者と検索サービスが同じ公式情報を確認できる状態を保つための基礎になります。まずは次回開催する1件について、公式URLと更新担当者を決めるところから始めてください。