イベント前の申込フォーム・事前質問・告知の設計手順

申込フォームは作った。事前アンケートも送った。告知コンテンツも用意した。それなのに、当日の進行は台本通りに進むだけで、参加者が何を期待していたかは反映されず、終わった後に書くレポートも当日の様子を後から思い出しながら書くことになる。原因は、申込フォーム・事前質問・告知コンテンツを「イベント開催までの事務手続き」として個別に処理し、当日どう使うか・記事にどうつなげるかを設計に組み込んでいないことにあります。この記事では、イベント前に集める情報を、当日の対話と事後の記事化に接続する設計手順を、プロンプトつきで実演します。

1. 事前の接点はあるのに、当日にも記事にも活きていない

申込フォームには氏名・メールアドレス・会社名・役職を入れる欄がある。事前アンケートも配信した。告知のSNS投稿や案内ページも用意した。やるべきことはやっている。

それなのに、当日の進行は誰が参加していても同じ台本で進み、質疑応答の時間になって初めて参加者の関心がわかる。イベントが終わってレポートを書く段になると、担当者は「そういえば、あの参加者は何を期待して申し込んだんだっけ」と、事前に聞いていたはずの情報を思い出せない。

よくある光景です。原因は、事前の接点を作っていないことではなく、申込フォーム・事前アンケート・告知コンテンツを、それぞれ別の目的のための別作業として処理していることにあります。申込フォームは受付担当が管理し、事前アンケートは集客担当が別のツールで配信し、告知コンテンツは広報が作る。それぞれは正しくても、集めた情報が「当日の進行台本」や「事後の記事の構成案」に渡される設計になっていないと、事前の接点は申込を受け付けるだけの窓口で終わります。

似たテーマとして、イベント後のお礼メール・アンケート・資料DL設計という記事があります。あちらは、イベントが終わった後、参加者に何をどう届けるかというフォロー施策の設計です。本記事はその手前、イベントが始まる前に集める情報を、当日の対話とその後の記事化にどう橋渡しするかを扱います。

2. 事前の情報が当日・記事に渡らない原因は2つ

原因1：フォームの項目が「集めやすい属性」で止まっている

申込フォームを作るとき、既存のテンプレートをそのまま使うと、氏名・メールアドレス・会社名・役職といった、管理のために必要な属性情報が並びます。これ自体は必要な項目ですが、参加者が何を期待して申し込んだか、何を聞きたいかという関心情報が抜け落ちがちです。属性情報だけでは、当日の進行を参加者の関心に合わせて調整することも、事後にどんな記事を書けば参加者の疑問に答えられるかを判断することもできません。

原因2：集めた情報が申込管理の中に留まり、当日・事後に渡されていない

事前アンケートで関心テーマや質問を聞いていても、その回答が申込管理ツールやスプレッドシートに溜まったまま、当日の進行担当や、事後にレポートを書く担当に共有されていないケースがあります。せっかく聞いた情報が、聞いた本人の手元にしかない状態では、当日の司会が「今日は皆さんこういうことに関心があるようです」と触れることも、記事の構成を「参加者が実際に知りたかったこと」から組み立てることもできません。

この2つが重なると、申込フォーム・事前アンケート・告知コンテンツはそれぞれ完了しているのに、集めた情報は誰にも使われないまま、次のイベントでも同じことが繰り返されます。

3. 実演：申込フォーム・事前質問・告知コンテンツを当日と記事化につなげる

3つを個別に作るのではなく、「集めた情報を誰が・いつ・どう使うか」を先に決めてから、それぞれの文面や項目に落とします。

工程1：申込フォームの項目を「当日どう使うか」から逆算する

項目を先に並べるのではなく、まず使い道を確定させます。

【申込フォーム設計シート】
1. 管理のために必須の項目は何か（例：氏名、メールアドレス、会社名、役職）
2. 当日の運営に使う項目は何か（例：参加希望セッション、参加形態）
3. 参加者の関心・期待を聞く項目を1〜2問だけ入れるとしたら何を聞くか
4. 自由記述の質問欄を設けるか（設ける場合、当日どう扱うかを先に決める）
5. 項目の合計数の上限（多くても8〜10項目までを目安にする）

3番目が要点です。「聞けることは全部聞いておこう」と項目を増やすと、入力の手間が増えて離脱が起き、しかも聞いた情報の大半は使われずに終わります。関心・期待を聞く項目は1〜2問に絞り、その回答を当日と事後のどちらで使うかを先に決めてから、次の工程に進みます。

工程2：事前質問・関心テーマの収集を設計する

以下の情報をもとに、申込フォームに入れる事前質問の設問を設計してください。

【イベント名・テーマ】
【想定する参加者層】
【この設問で何を判断したいか】（例：当日の質疑応答の時間配分を決めたい、
記事化する際にどの論点を厚く書くか決めたい、のいずれか1つに絞って明記する）

【出力形式】
| # | 設問 | 回答形式（選択／自由記述） | この回答を当日・事後のどちらで、誰が使うか |

【条件】
・設問は1〜2問に収める。自由記述は1問までにする
・選択肢を作る場合は、当日のセッション構成や扱うテーマから作る
  （一般的な業界用語の選択肢にしない）
・「この回答を当日・事後のどちらで、誰が使うか」を必ず埋める。
  使い道が書けない設問は削除する

「使い道が書けない設問は削除する」という条件が要点です。事前アンケートの回収率を上げる工夫は世の中に多くありますが、回収率を上げても、その回答を誰も見ない設計であれば意味がありません。使い道が明確な設問だけを残すと、聞く数は減っても、当日・事後で実際に使われる情報だけが集まります。

工程3：告知コンテンツで事前情報を段階的に引き出す

告知は開催までの期間で内容を変えるのが一般的です。この段階でも、参加者の関心を引き出す機会として設計します。

以下の情報をもとに、開催までの告知コンテンツの構成案を作成してください。

【イベント名・開催日】
【登壇者・扱うテーマ】
【告知開始から開催日までの期間】

【出力】
1. 告知初期（開催の1〜2ヶ月前を目安）に発信する内容
   （開催概要・登壇者・テーマの基本情報）
2. 告知中期に発信する内容
   （登壇者の見どころ、扱うテーマの一部を小出しに紹介）
3. 告知直前に発信する内容
   （参加を後押しする情報。緊急性を煽る文言だけで終わらせない）
4. 各フェーズの投稿・案内文に、「事前に聞きたいことがあれば申込フォームで
   教えてほしい」という一文を自然な形で入れる案

【条件】
・登壇者やテーマについて、貼っていない情報を新しく作らない
・緊急性を煽る表現（「残席わずか」等）だけの投稿を作らない。
  必ず内容面の情報とセットにする

4番目の条件が、事前接点としての告知の役割です。告知は「申し込んでもらう」ためだけでなく、「申込フォームで事前質問を聞いている」ことを参加者に知らせる機会でもあります。ここを入れておくと、工程2で設計した事前質問の回収率にも波及します。

工程4：集めた情報を当日の進行台本と記事の構成案に渡す

申込フォーム・事前アンケートで集めた情報を、当日と事後のそれぞれの担当者が使える形に整えます。

以下は、申込フォーム・事前アンケートで集めた参加者の関心・質問の一覧です。

【集めた関心テーマ・事前質問の一覧】（工程2で集まった回答を貼る）
【当日のセッション構成】

【出力】
1. 当日の進行担当に渡す一言メモ
   （「今回は〜という関心を持つ参加者が多い」という形で、
   質疑応答の時間配分や触れるべき論点を示す）
2. 事後のレポート・記事の構成案
   （集まった関心テーマのうち、当日のセッションで実際に触れられた
   論点を軸に見出し案を作る）

【条件】
・貼っていない回答内容を新しく作らない
・関心が集中したテーマと、少数だが具体的な質問があったテーマを
  分けて扱う（多数決だけで構成を決めない）

ここまで来ると、申込フォーム・事前アンケート・告知コンテンツは、受付のための別々の事務作業ではなく、「参加者が何を求めているかを当日と記事に届ける」ための一続きの設計になります。

4. それでも残る限界

この4工程を回せば、申込フォーム・事前アンケート・告知コンテンツの設計自体は汎用LLMだけでも組み立てられます。ただし、次のことはAIの外側に残ります。

個人情報の取り扱いは人が確認する必要があります。 申込フォームや事前アンケートで氏名・会社名・関心といった個人情報を扱う場合、プライバシーポリシーの明示と同意取得の設計は、法務・コンプライアンスの観点から人が確認する必要があります。AIに任せられるのは設問の文面や構成であって、同意取得の要否そのものの判断ではありません。

当日、実際に何が起きるかはAIには分かりません。 工程4で作った進行メモは、あくまで事前情報からの予測です。当日の質疑応答で事前アンケートにはなかった質問が出ることは普通にあり、進行担当がその場で判断する部分は残ります。

フォーム・アンケートの配信や回収状況の管理は、設計の外にある実行の話です。 どのツールでフォームを作るか、回答をどう集計するかは、工程1〜4で決めた設計を、実際のフォーム作成ツールや配信ツールで運用する段階が別に必要です。この記事が扱っているのは「何を・どう聞き、どう渡すかの設計」までで、ツールの実装や運用そのものではありません。

事前情報の使い道は、イベントのたびに作り直しになります。 工程2〜4で使う関心テーマやセッション構成は、そのイベントの内容に依存するため、テンプレート化できる部分と、毎回作り直す部分が混在します。ここを省略すると、どのイベントでも同じ項目を使い回すことになり、事前に聞く意味が薄れます。

5. 当日以降の工程は、すでに別に書いています

ここまでの4工程は、イベントが始まる前に集める情報の設計です。申込フォーム・事前アンケートで集めた関心テーマは、イベントが終わった後、Q&Aの記録やアンケートの自由記述と合わせて社内向けのレポートに統合する段階に進みます。この工程はQ&Aと参加者アンケートの統合方法で実演しています。また、イベント終了後に参加者へお礼メール・アンケート・資料DLをどう届けるかはイベント後のお礼メール・アンケート・資料DL設計で扱っています。

sonataは、音声のアップロードから事前のWeb調査・企画・文字起こし・構成・記事生成までを一連の流れとして扱うサービスです。イベント前に集めた関心テーマや、当日の音声・Q&Aの記録が手元にあれば、事前の期待と当日の対話をつなげて記事の素材を組み立てる工程を整理できます。特許出願中の独自ワークフロー（特願2025-146411号）として、音声から記事化までの一連の工程を扱います。

無料で試せます。

• sonataを無料で試す

まずは次のイベントで、工程1の申込フォーム設計シートだけ埋めてみてください。「関心・期待を聞く項目を1〜2問だけ入れるとしたら何を聞くか」に迷わず答えられるかどうかで、そのイベントで何を明らかにしたいかが、事前の時点で定まっているかが分かります。

6. よくある質問

申込フォームの項目はどのくらいの数に抑えるべきですか？

多くても8〜10項目までを目安にしてください。管理のために必須の項目（氏名・メールアドレス等）を優先し、関心・期待を聞く項目は1〜2問に絞ることをおすすめします。項目数を増やすほど入力の負担が増え、離脱につながります。

Q. 事前アンケートと申込フォームは分けるべきですか、同じフォームに入れるべきですか

同じフォームに入れて構いません。ただし、事前アンケート部分の設問は1〜2問に絞り、「この回答を当日・事後のどちらで、誰が使うか」が説明できる設問だけを残してください。使い道が説明できない設問は、フォームを分けても意味が薄れます。

Q. 事前に集めた関心テーマは、当日の進行にどこまで反映すべきですか

多数決だけで進行を決めるのではなく、関心が集中したテーマと、少数でも具体的な質問があったテーマを分けて扱うことをおすすめします。進行担当への共有は「時間配分の参考情報」として渡し、当日の判断そのものは進行担当に委ねる設計が現実的です。

Q. 告知コンテンツで事前質問を呼びかけても、実際には集まらないことがあります

告知の投稿・案内文に、事前質問を聞いている旨の一文を入れているかを確認してください。申込フォームに事前質問の欄があるだけでは気づかれにくく、告知の段階で「聞きたいことがあれば教えてほしい」と一言添えることで気づいてもらいやすくなります。

Q. この記事と、イベント後のお礼メール・アンケート設計の記事は、どちらを先に読むべきですか

時間軸としては本記事が先です。本記事はイベントが始まる前に何を集めるかという設計、イベント後のお礼メール・アンケート・資料DL設計は、イベントが終わった後に参加者へ何を届けるかという、次の段階の話です。