問い合わせフォームの項目をAIと削る：必須・任意・不要を分ける判断表

判断は2つの質問だけでいい

項目ごとに次の2つを書き出します。

1. 使う場面：この情報を受け取った後、誰がいつ使うか（例：返信の宛名、当日の連絡、日程調整）
2. なければ困るか：空欄で届いたとき、返信や対応が止まるか

この2つから、次のように分けます。

• 言える、なければ困るか：困る（返信・対応が止まる）、判断：必須
• 言える、なければ困るか：困らない（あれば早い、程度）、判断：任意
• 言えない／今は使う予定がない、なければ困るか：—、判断：不要（削除）
• 言えるが、フォームで聞く必要はない、なければ困るか：—、判断：後で聞く（返信時などに確認）

四つ目が見落とされやすい区分です。たとえば住所は、教材を郵送する段階で初めて必要になります。その段階で聞けば足りるなら、最初のフォームには要りません。

説明用の例：15項目のフォームを判断表にかける

ここからの例は、記事用に作った架空のケースです。「週末だけ開く手作りアクセサリー教室」が、体験参加の問い合わせを受けるフォームを想定しています。返信はメールのみ、会場は1か所、郵送は行いません。実際の運用や測定結果ではありません。

削減前の項目と判断表

• お名前、使う場面：返信の宛名、参加者の識別、なければ困るか：困る、判断：必須
• フリガナ、使う場面：使う場面がない（返信は漢字のままで足りる）、なければ困るか：困らない、判断：不要
• メールアドレス、使う場面：返信、なければ困るか：困る、判断：必須
• メール確認用（再入力）、使う場面：入力ミスの防止、なければ困るか：困らない、判断：不要（※下記）
• 電話番号、使う場面：当日の連絡（運用はメールのみ）、なければ困るか：困らない、判断：不要
• 郵便番号、使う場面：使う場面がない（郵送なし）、なければ困るか：困らない、判断：不要
• 住所、使う場面：同上、なければ困るか：困らない、判断：不要
• 生年月日、使う場面：年齢制限なし、なければ困るか：困らない、判断：不要
• 性別、使う場面：使う場面がない、なければ困るか：困らない、判断：不要
• 職業、使う場面：使う場面がない、なければ困るか：困らない、判断：不要
• 希望日、使う場面：日程の調整、なければ困るか：困らない（返信で相談できる）、判断：任意
• 参加人数、使う場面：席と材料の準備、なければ困るか：困らない（返信で確認できる）、判断：任意
• 何で知ったか、使う場面：宣伝の振り返り（返信には不要）、なければ困るか：困らない、判断：不要（必要なら参加後に聞く）
• 問い合わせ種別（プルダウン）、使う場面：内容を見れば分かる、なければ困るか：困らない、判断：不要
• 問い合わせ内容、使う場面：返信の本題、なければ困るか：困る、判断：必須

※メール確認欄は、入力ミスを防ぐ目的で置かれることがあります。ここでは、メール欄を type="email" にして形式の誤りを減らし、送信後の画面に「入力したアドレス宛に返信します」と表示する方向で代替する、という編集上の提案です。確認欄を残すかは、誤入力で困った経験があるかで決めてください。

削減後

• 必須（3）、項目：お名前（ニックネーム可）／メールアドレス／問い合わせ内容
• 任意（2）、項目：希望日／参加人数

15項目が5項目になりました。入力する側の手間は減りますが、減らしたから問い合わせが増える、という保証はありません。公開後に、フォームを開いた人のうち何人が送信したかを自分で見て判断してください。web.devのサインインフォーム解説では、サインインの流れに分析や操作状況の計測を組み込むことが勧められています（Sign-in form best practices）。

AIに渡す依頼文

AIには、「足す」役ではなく「削る理由を説明する」役を頼みます。目的と運用を先に渡し、項目の追加を禁止するのがコツです。

問い合わせフォームの項目を見直したいです。

【フォームの目的】体験参加の問い合わせを受けて、メールで返信する
【返信の方法】メールのみ。電話や郵送はしない
【受け取った後の流れ】私が1人で内容を読み、2営業日以内に返信する
【現在の項目】
お名前、フリガナ、メールアドレス、メール確認用、電話番号、
郵便番号、住所、生年月日、性別、職業、希望日、参加人数、
何で知ったか、問い合わせ種別、問い合わせ内容

【お願い】
1. 項目ごとに「使う場面」と「空欄だと返信や対応が止まるか」を書く
2. 「必須／任意／不要／後で聞く」のどれかに分類し、理由を一文で添える
3. 新しい項目は提案しない
4. 使う場面を私が答えられなさそうな項目は「要確認」にして、
   何を決めれば分類できるかを書く
5. 結果は表で出す

ポイントは、4番の「要確認」です。AIは判断に迷う項目でも、それらしい理由をつけて「必須」にしがちです。迷いを隠さず出してもらえば、人が決めるべき点が見えます。

実在のお客様の名前や過去の問い合わせ文は貼らず、項目名と運用の説明だけを渡せば足ります。

AIの表を受け取ったら、人が確認すること

AIが返した表は、そのまま採用せず次を確認します。

• 「使う場面」を自分の言葉で言えるか：AIの理由が自分の運用と合っているかを見ます。「分析に役立つ」のような曖昧な理由は、具体的な使い道に書き直せなければ削ります。
• 必須が増えていないか：必須は、空欄だと返信できない項目だけです。
• 任意の項目の扱い：空欄で届いたとき、返信文でどう聞き返すかを決めておきます。
• 個人情報の保管と扱い：残した項目の保管場所と、誰が見られるかを確認します。日本の個人情報保護法などの扱いは、自分の事業の状況に応じて確認してください。この記事では個別の適法性は判断しません。

実装時の確認点

項目が決まったら、HTMLに反映します。以下は説明用の例で、実際に動かして検証したものではありません。

<form action="/contact" method="post">
  <p>「必須」と書かれた項目は入力してください。</p>

  <label for="name">お名前（必須・ニックネーム可）</label>
  <input id="name" name="name" type="text" required>

  <label for="email">メールアドレス（必須）</label>
  <input id="email" name="email" type="email" required>

  <label for="date">希望日（任意）</label>
  <input id="date" name="date" type="text">

  <label for="message">お問い合わせ内容（必須）</label>
  <textarea id="message" name="message" required></textarea>

  <button type="submit">送信する</button>
</form>

確認する点は次のとおりです。

• 必須の示し方：MDNによると、required は値が空のまま送信されるのを防ぐ属性で、input の多くの型と select、textarea で使えます（MDN: required）。ただし画面上の印にはならないので、ラベルに「必須」と書くなど、色だけに頼らない示し方を併用します。
• 事前の説明：W3CのWAIは、必須項目の示し方をフォームの冒頭で説明することを勧めています。形式などの案内はプレースホルダに頼らず、ラベルに含めるほうが確実です（W3C WAI: Form instructions）。
• ラベルと入力の対応：web.devのサインインフォーム解説では、label を入力欄に対応させることが勧められています。for と入力欄の id を結び付け、メール欄には type="email" を使います。

required が確認するのは空欄かどうかだけです。メールアドレスが本当に届くか、内容が適切かまでは分かりません。そのため、返信が届かなかったときの連絡手段も決めておくと安心です。

次に項目を足したくなったとき

後から「やはり電話番号も」と足したくなったら、最初の2つの質問に戻ります。使う場面を一言で言えるなら、任意項目として足せます。言えないなら、足す前に、返信メールの中で聞けないかを考えてみてください。