イベント申込フォームに必要な項目の選び方

申込フォームでは、明確な作業に必要な情報だけを集めます。一般的な『必須項目』をそのまま使うと、誰も利用しないデータが増えます。無料の講座では返信用メールが必要でも電話番号は不要かもしれません。各質問を用途、担当者、保存期限と結び付けてください。

Boletolibre編集部

公開日 2026年10月14日

フォームの目的を決める

席の申請、連絡、受付での照合、食事、参加支援、請求書など、実際の作業を列挙します。回答を誰がどう使うか説明できなければ、その項目は削除候補です。後日しか必要ない情報は後で尋ねる方法もあります。

申請、参加確定、支払いは別の状態です。人が審査する申請を確定席と表示してはいけません。外部サービスで登録するなら、主催者サイトは案内とリンクだけで足りる場合もあります。W3Cは手続きに必要な情報だけを求めるよう勧めています。項目、用途、条件、担当、削除時期を記録します。[1]

決定や変更をメールで送るなら返信先が必要です。名前は受付や名札に必要な範囲で尋ね、戸籍上の氏名を一律に求めません。券種や時間帯の選択は選択肢がある場合だけ必要です。電話は実際に電話やSMSを使う業務がある場合に検討します。

会社名は業務上の請求書では必要でも、地域講座では不要かもしれません。住所、生年月日、職業、SNS、会社規模をテンプレートにあるだけで追加しないでください。表は判断材料であり法律上の結論ではありません。

条件付きの質問は選択に従います。食事を選んだ人には食事の配慮を尋ねられますが、オンライン参加者に移動情報は不要です。アクセシビリティ上の支援は私的に相談できる窓口を設け、診断名を一律に必須にしないでください。一般の名簿に詳細を保存せず対応できるか考えます。

任意なら無回答でも申込が完了します。条件付きなら関連する選択をした人にだけ表示します。用途を説明し、閲覧者を必要な人に限定します。受付担当者に食事や支援の詳細を渡す必要はありません。

有料イベントでは券種と料金を示し、適切な決済サービスへ案内します。カード番号や確認コードを自由記入欄で集めないでください。決済事業者がその情報を扱い、成功・失敗・取消の結果を返す必要があります。決済画面へ進んだだけでは支払い完了ではありません。

申込、支払い、入場の状態を分け、席がいつ確保されるかと問い合わせ先を説明します。請求情報は実際の取引に必要な場合だけ適切なシステムで取得します。無料イベントに決済欄は要りません。法的な要件は地域と事業者により異なります。

適用される参加条件と個人情報の案内を示します。条件への同意、情報提供、宣伝の許可を曖昧な一つのチェック欄にまとめないでください。運営上の連絡と広告は別です。適用法令で宣伝への許可が必要なら、別に示し、あらかじめ選択しません。

EUのGDPR第5条には目的、最小化、保存期間の原則があります。英国の規制当局も英国法のもとで最小化を説明しています。どちらも全地域共通の必須項目一覧ではありません。実際に適用される規則を確認してください。[5][6]

各入力欄に見える明確なラベルを付け、必須・任意と必要な形式を言葉で示します。プレースホルダーだけではラベルになりません。内部データベースの順ではなく、参加者が進む順に並べます。[2][3]

エラーでは修正方法を伝え、ほかの回答を消さないようにします。キーボード、携帯電話、条件分岐、決済への移動を確認します。W3C WAIはラベル、説明、入力検証を案内していますが、それだけで法令遵守を保証するものではありません。[4]

架空のCedar Street講座は無料で30席、人が申請を審査します。結果はメールで送り、入口では希望する表示名を確認します。メールと表示名を尋ね、同時開催の講座がある場合だけ時間帯を選びます。送信時点は申請であって確定ではありません。

お茶だけで食事はないため食事の質問は省きます。参加支援には私的な連絡先を設け、医療情報を必須にしません。電話、雇用先、生年月日、住所、SNSも省きます。将来有料にする場合は別の決済設計が必要です。Boletolibreの機能を示す例ではありません。

公開前に各分岐を試し、担当者には必要な列だけ渡します。入口では表示名と状態が必要でも、メール履歴や私的な相談内容は不要です。訂正窓口も決めます。

開催後は項目ごとに用途と保存期限を見直し、適用される記録義務を考慮して不要な書き出しを消します。一時的な担当者の権限も閉じます。次回は古い質問を全部引き継がず、有効だった判断を引き継ぎます。