フォーム項目例まとめ -- 必須/任意の決め方と用途別テンプレート

最終更新日: 2026-05-14

フォーム項目は多いほど安心に見えますが、実務では逆で、項目が多いほど入力されにくく、必須が多すぎれば途中離脱が増えます。自由記述が増えれば集計が止まり、電話番号や住所を早く聞きすぎれば警戒されます。

「フォーム 項目 例」で欲しいのは項目名の一覧ではなく判断軸です。問い合わせに何を入れるか、申込で電話番号を必須にするか、予約は第何希望まで聞くか、資料請求で会社名は要るか、採用応募はどこまで踏み込むか、アンケートで自由記述をどれくらい置くか。判断が難しいのは、項目が「入力欄」ではなく「送信後の運用」に直結するからです。

この記事では用途別整理、必須/任意/後で聞くの判断、入力形式、ラベル、アクセシビリティ、ワークフロー実装までまとめます。フォーム全体の作り方はフォームの作り方まとめを先に。

まず結論 -- フォーム項目は「必須」「任意」「後で聞く」に分けます

最初にやるべきは候補を 3 つに分けることです。

W3C Design System は、厳密に必要な質問だけを聞くのがベストプラクティスだと説明しています。「必須にできる」と「必須にすべき」は違います。必須にしてよいのは、会社が欲しい情報ではなく、送信後に本当に使う情報だけです。同じ項目でも用途で重さが変わります。問い合わせはメールとカテゴリが必須になりやすく、予約は希望日時、資料請求は資料送付だけなら会社名や導入時期は任意で成立します。

フィールド型ガイド (全 29 種類)

FORMLOVA は基本 13 種、拡張 13 種、レイアウト 3 種の計 29 種を扱えます。型を間違えると集計や自動化が苦しくなります。

基本フィールド 13 種

拡張フィールド 13 種

レイアウトフィールド 3 種と表示オプション

フィールド型選びの 4 原則

1. 集計したい項目は選択式に。業種、部署、希望日、カテゴリ、満足度はドロップダウン・ラジオ・チェック・スライダー・NPS へ。テキスト入力では表記ゆれで分析が止まる。
2. 入力負担と回答品質はトレードオフ。自由記述は深い情報を取れるが入力と整理の負担が増える。1 フォームに 1-2 箇所まで。
3. 拡張フィールドはアンケートと契約・申込で活きる。NPS、リニアスケール、マトリックス、画像選択、署名は問い合わせフォームでは過剰になりやすい。
4. 隠しフィールドはワークフロー視点で設計する。UTM、リファラー、user_id、spam_label のような「回答者が入力しない情報」は自動キャプチャする (後述)。

用途別フォーム項目例

これは絶対ルールではありません。BtoB なら会社名を必須に、オフラインイベントなら電話番号、匿名アンケートなら氏名とメールを聞かない、といった調整が入ります。「よくあるから入れる」ではなく「後続運用で使うから入れる」で判断します。

同じ項目でも、用途で意味が変わります

会社名は、BtoB の問い合わせでは商談文脈、資料請求ではリード分類、イベントでは受付、採用では応募職種より優先度が下、と重みが変わります。電話番号はメール返信で完結する問い合わせなら任意、当日連絡が要る予約や会場変更があるイベントなら必須が筋です。自由記述は便利ですが、申込やイベントで長文必須にすると入力負担が増えます。「ここでしか取れない情報」だけに使い、目的、回答者負担、送信後の担当者の動きで判断します。

問い合わせフォームの項目例

返信と担当者振り分けが目的です。

氏名
メールアドレス
会社名
問い合わせカテゴリ
問い合わせ内容
個人情報の利用目的への同意

BtoB は会社名を入れ、個人向けや一般相談では任意で構いません。カテゴリは振り分けに使うため選択式に。

サービスについて
料金について
導入相談
サポート
取材・提携
その他

電話番号は、電話折り返し、緊急対応、来店・訪問・予約、メールでは対応できないサービス、のいずれかに当てはまるときだけ必須にします。必須にするなら「折り返しが必要な場合のみ利用します」と使い道を補足します。雛形は問い合わせフォームのテンプレートにあります。

申込フォームの項目例

相手が次のステップへ進む意思を示すフォームです。

氏名
メールアドレス
申込対象
申込内容または参加形式
確認メールの送付先
変更・キャンセル方法の確認
個人情報の利用目的への同意

セミナー、イベント、採用、資料請求を 1 つにまとめると項目が膨れます。最初に「何への申込か」を選ばせ、選択に応じて項目を分岐させると安全です。詳細は申込フォームの作り方、セミナー申込フォームの作り方、イベント受付フォームの作り方にあります。

予約フォームの項目例

日時と確定条件が要点です。

氏名
メールアドレス
電話番号
予約したいサービス
第1希望日
第1希望時間帯
第2希望日
第2希望時間帯
オンライン/来店/電話などの希望
相談内容または補足
変更・キャンセル条件への同意

希望日時は自由記述ではなく日付と時間帯に分けると管理が楽になります。リアルタイムの空き枠表示や即時確定が要件なら予約ツールを検討します。詳細は予約フォームの作り方にあります。

資料請求フォームの項目例

資料を送るだけなら短くできます。

氏名
メールアドレス
希望資料
個人情報の利用目的への同意

営業フォローまで考えるなら、会社名、部署名、役職、会社規模、導入時期、現在の課題、相談希望、を任意または選択式で足します。資料請求と商談申込を混ぜると、資料だけ欲しい人にはフォームが重くなります。まず資料を届けてから興味度の高い人を見つける設計が現実的です。詳細は資料請求フォームの作り方にあります。

採用応募フォームの項目例

選考に必要な情報だけを集めます。

氏名
メールアドレス
応募職種
職務経歴の概要
履歴書または職務経歴書の提出方法
ポートフォリオURL
希望連絡方法
個人情報の利用目的への同意

初回応募で聞くのは選考判断と次の連絡に必要な情報だけです。詳細な住所、扶養状況、家族構成、健康情報は初回フォームで聞きません。必要な場合でもタイミングと利用目的を分けます。避ける質問の一覧は採用応募フォームの作り方にあります。

アンケートフォームの項目例

集計できる設問と自由記述のバランスが重要です。

回答対象または利用経験
満足度
評価理由
改善してほしい点
今後利用したいか
個別連絡を希望するか
連絡先（希望者のみ）

満足度、利用目的、参加区分、改善カテゴリは選択式に、理由や具体例だけ自由記述にすると集計と深掘りの両方ができます。匿名アンケートでは氏名やメールアドレスを聞きません。個別フォローしたい場合は「連絡を希望する場合だけメールアドレスを入力してください」と分けます。詳細はアンケートフォームの作り方にあります。

必須項目を決める 5 つの質問

必須にするか迷ったら、次の 5 つを順に確認します。

1. その項目がないと返信できないか。メールアドレスは多くのフォームで必須になる。
2. その項目がないと分類できないか。問い合わせカテゴリ、応募職種、希望資料、予約対象は後続運用に直結する。
3. その項目がないと約束を守れないか。予約日時、参加人数、希望サービス、参加形式は受付や当日対応に必要。
4. 回答者が入力理由を理解できるか。電話番号や会社名を必須にするなら、何に使うかを短く書く。説明できない項目は必須にしない。
5. 後で聞いても間に合うか。詳細住所、請求情報、長いヒアリング、追加資料は初回送信後に聞ける。

この 5 問に答えると、必須項目は自然に減ります。

入力形式の選び方

項目名と同じくらい入力形式も重要です。

MDN は、HTML の入力型、required、pattern 属性でブラウザ側の入力補助ができることを説明しています。ただしクライアント側だけに頼らず、サーバー側でも確認します。

メールはメール項目に、日付は日付項目に、カテゴリは選択式に、自由記述は最後に。この 4 つを徹底するだけで、回答一覧、CSV、Google Sheets 連携が扱いやすくなります。

ラベルと補足文の書き方

W3C WAI は、全てのフォームコントロールに目的を示すラベルを付けることを推奨しています。ラベルは短く具体的に書きます。

• 悪い例: 内容 / 情報 / 希望 / その他
• 良い例: お問い合わせ内容 / 希望する資料 / 第1希望日 / 参加人数 / 応募職種

補足文は、入力ミスが起きやすい項目だけに使います。

電話番号（当日の変更連絡にのみ使用します）
会社名（法人でのお問い合わせの場合のみ）
第1希望日（予約はまだ確定しません）
自由記述（200文字以内で、現在困っていることを書いてください）

補足を長くしすぎると読まれません。注意事項が多い場合は規約ページや確認メールに分けます。エラー文の具体例と NG パターンはフォームのエラーメッセージガイドにあります。

アクセシビリティを項目設計の段階で組み込む

ラベル・補足・エラー文の見せ方でアクセシビリティの 8 割が決まります。項目を作る段階で組み込みます。

Label と placeholder

W3C WAI は <label> で関連付けるのを基本としています。placeholder だけに頼ると入力途中で表示が消え、コンテキストが失われます。color contrast も合わせて確認します。

WCAG 2.2 と Error Suggestion

WCAG 2.2 はエラー特定 (Error Identification) で「どの項目がエラーか」を明示し、エラー提案 (Error Suggestion) で「どう直せばよいか」を伝えることを求めています。

• ラベルに * を置くのではなく 必須 バッジを使う (FORMLOVA は requiredBadgeText で文言を変更可能)
• エラー時はフィールド近傍に短い理由を置く (例: 「メールアドレスを入力してください。例: name@example.com」)
• 色だけでエラーを示さない (赤枠 + テキストの併用)

拡張フィールド型の a11y

隠しフィールド、署名、ファイルアップロード、NPS、スライダー、マトリックスは設計が難しい型です。

アクセシビリティは障害がある人のためだけではなく、スマホで急ぐ人、母語でない回答者、高齢の管理者など、多くの場面で品質に効きます。

ワークフロー実装視点 -- 項目はデータの入り口です

項目を決める時点で回答後のワークフローを意識すると、自動化が楽になります。

隠しフィールドで自動キャプチャする情報

FORMLOVA は URL クエリパラメータからの自動取得に対応します。UTM が入れば広告経由とオーガニック経由を分けて分析できます。

条件分岐で「後で聞く」を実装する

初回送信を軽くしつつ詳細を取りたいときは、条件分岐とワークフローを組み合わせます。

初回フォーム: 氏名、メール、希望サービス、同意
回答後ワークフロー:
  - 自動返信メールを送る
  - 「詳細ヒアリングフォーム」の URL を 24 時間後に送る
  - 回答者は時間ができたタイミングで詳細を入力する

初回 CVR を落とさず必要な情報を後追いで揃えられます。詳細はフォーム自動化まとめにあります。

テキスト入力と営業メール自動検知

テキスト入力があるフォームには営業メールが届きやすくなります。FORMLOVA は回答を legitimate / sales / suspicious に分類します。項目設計時点では、問い合わせカテゴリに「営業・提案」を置く、自由記述近くに「営業のご提案はメールで」と補足する、隠しフィールドで spam_label を保存する、の 3 つで対処します。入口で完全に止めず届いた後で分類します。詳細は営業メール対策、CAPTCHA 比較、ハニーポット対策にあります。

動的選択肢の効果と限界

前の選択に応じて後の選択肢を変える設計は、条件分岐とフィールド可視性で実現できます。ただし分岐が増えると認知負担が上がり、ルールが複雑だと運用変更が難しく、途中離脱時に未完了データが残ります。最初は固定選択肢で始め、必要な分岐だけ足します。

スマホ入力で見直す

PC で短く見えるフォームでも、スマホでは長く感じられます。公開前にスマホで次を確認してください。

1画面目に何を入力するフォームか分かるか
必須項目が多すぎないか
メールアドレス入力でキーボードが適切に出るか
電話番号入力で数字を入れやすいか
選択肢が長すぎないか
自由記述の入力が重すぎないか
エラー時にどこを直すべきか分かるか

Microsoft Forms の公式ヘルプもプレビューで PC とモバイルを両方確認するよう案内しています。FORMLOVA でも公開前レビューでスマホ表示と送信テストを必ず通します。

FORMLOVA で項目例からフォームを作る手順

最初から完璧な項目表は要りません。用途と運用を伝えるところから始めます。

問い合わせフォームを作ってください。
必須項目は氏名、メールアドレス、問い合わせカテゴリ、問い合わせ内容、個人情報同意です。
会社名と電話番号は任意にしてください。
問い合わせカテゴリで担当者を振り分けたいです。

予約フォームならこう。

無料相談の予約受付フォームを作ってください。
送信時点では確定しません。
必須項目は氏名、メールアドレス、電話番号、相談テーマ、第1希望日、第1希望時間帯、第2希望日、第2希望時間帯です。
補足事項は任意にしてください。

資料請求ならこう。

資料請求フォームを作ってください。資料送付だけなので入力を短くしたいです。
必須項目は氏名、メールアドレス、希望資料、個人情報同意です。
会社名、会社規模、導入時期、相談希望は任意にしてください。

下書きが出たら、必須は送信後に必ず使うものだけか、任意の理由を説明できるか、後で聞ける項目を初回で聞いていないか、自由記述が多すぎないか、選択式にできる項目を自由記述にしていないか、ラベルだけで分かるか、スマホで最後まで送信できるか、を確認します。

項目が決まったら送信後の運用へ。自動返信メール例文集、回答一覧の絞り込みとステータス管理、CSV 書き出しと Google Sheets 自動連携 へ進みます。

項目から関連記事への引き継ぎ表

この表に沿って次の記事へ進むと、フォームが「箱」ではなく「業務の入口」になります。

よくある失敗

• テンプレートをそのまま全部入れる。後続運用で使わない項目は削る。
• 電話番号を何となく必須にする。電話対応がないなら必須にしない。必須にするなら使い道を補足する。
• 自由記述に頼りすぎる。カテゴリ、希望資料、参加形式、予約時間帯は選択式に。
• 同意チェックが曖昧。「同意する」だけでは不十分。利用目的、営業連絡、イベント後案内を分ける。
• 回答を誰が見るかを決めずに項目を作る。営業・採用・サポート・イベント運営・マーケのうち誰が見るかを先に決める。
• 業種、導入時期、会社規模をテキストにする。表記ゆれで集計が止まる。ドロップダウンへ変えるだけで CVR と分析が改善する。
• 隠しフィールドを使わない。UTM、リファラー、user_id は自動取得する。流入元別 CVR 分析、新規と既存の判別、A/B 比較に必須。

参考にした公式情報

• W3C Design System: Forms
• W3C WAI: Labeling Controls
• MDN Web Docs: Client-side form validation
• MDN Web Docs: Forms and buttons in HTML
• Google Docs Editors Help: Edit your form
• Microsoft Support: Create a form with Microsoft Forms

FAQ

フォームの必須項目は何個までがよいですか？

固定の正解はありません。必須は「送信後に必ず使うもの」だけに絞ります。問い合わせなら氏名・メール・カテゴリ・内容・同意、資料請求なら氏名・メール・希望資料・同意、予約はこれに希望日時と連絡先を加えます。

電話番号は必須にするべきですか？

当日連絡、緊急連絡、予約変更、電話折り返しがある場合だけ必須にします。メールで十分な問い合わせ、資料請求、アンケートでは任意で構いません。必須にするなら使い道を補足文で説明します。

会社名は必須にするべきですか？

BtoB の問い合わせ、資料請求、イベント受付では入れる価値があります。個人向けサービスや匿名アンケートでは必須にしません。会社名がないと対応できないのか、あると便利なだけなのかで判断します。

自由記述はどれくらい入れるべきですか？

問い合わせ内容や評価理由など、文脈を知るために 1〜2 箇所が目安です。カテゴリ、希望資料、参加形式、希望日時のように分類したい情報は選択式にします。

同意チェックには何を書けばよいですか？

何のために個人情報を使うのかを書きます。問い合わせ返信、資料送付、予約調整、採用選考、イベント運営など利用目的に合わせます。営業メールやイベント後案内の同意は、受付に必要な同意と分けます。文言と法的観点は問い合わせフォームの個人情報同意ガイドにあります。

拡張フィールドと隠しフィールドの使い分けは？

拡張フィールドは「数値や視覚で評価したい設問」、隠しフィールドは「回答者に入力させない運用データ」に使います。NPS は推奨意向の単一質問 (0-10)、星評価は満足度、リニアスケールは独自範囲、マトリックスは同じ尺度で複数項目 (3 × 3 超は分割)、画像選択はデザイン提案や商品比較で活きます。隠しフィールドは UTM、リファラー、user_id、form_version、client_timezone を自動キャプチャでき、流入元別 CVR 分析、既存と新規の分離、A/B 比較で必須です。詳細はアンケートフォームの作り方、NPS フォームの作り方、フォーム自動化まとめにあります。

署名フィールドは法的効力がありますか？

署名フィールドは「描画入力による同意の意思表示」を記録します。法的効力の有無は契約の種類と所轄法令によります。重要書類は、署名フィールドだけでなく同意確認 (legal) や別の電子契約サービスと組み合わせます。描画入力が困難な利用者向けに代替手段も並置します。

同じ項目を複数フォームで使い回せますか？

FORMLOVA はフォームごとに項目を独立して持ちます。テンプレート保存して別フォームに適用できますが、フォーム間で値を共有する動きはありません。複数フォームを跨いだヒアリングは、メールアドレスや user_id をキーに条件分岐や自動返信メールで誘導します。

関連する記事

• FORMLOVAでフォームを作る方法まとめ -- 用途別テンプレートと公開後運用の選び方
• 入力フォーム最適化（EFO）とは -- 離脱を減らす項目設計・エラー表示・送信後導線
• NPSフォームの作り方 -- CSATとの違い・計算方法・低評価フォローまで
• フォームのサンクスページの作り方 -- 完了画面・次アクション・計測まで
• フォームのエラーメッセージ例 -- 入力エラーで離脱させない文言と表示位置
• 問い合わせフォームの個人情報同意文言 -- チェックボックス・利用目的・例文

執筆・確認情報

筆者は FORMLOVA の開発者です。W3C Design System、W3C WAI、WCAG 2.2、MDN、Google Forms、Microsoft Forms の公式情報を 2026 年 5 月 13 日に確認し、29 フィールド型の参照ガイドとして再構築しました。個人情報、採用、医療、金融、法務の項目は各社規程と専門家の確認に合わせてください。