問い合わせフォームを作り始めたものの、「氏名や電話番号は必須か」「送信内容はどこに残るのか」「制作会社は閲覧できるのか」といった判断が止まっていないでしょうか。画面だけを先に完成させると、公開直前になって通知先や保存先、削除方法の未決定が見つかりやすくなります。
公開前に決める順番は、フォームの目的、取得項目、利用目的の表示、送信後のデータの流れ、担当者と委託先、入力支援、検収方法の7項目です。プライバシーポリシーへのリンクや同意チェックボックスは、その一部にすぎません。取得する理由や受信後の扱いを決めないまま追加しても、安全な運用にはなりません。
個人情報保護委員会のガイドラインは、利用目的の特定、取得時の表示、安全管理、従業者・委託先の監督を別々の論点として示しています。W3Cのフォームチュートリアルも、項目の絞り込み、ラベル、説明、入力検証、完了・エラー通知を分けて扱っています。この記事では、それらを中小企業が社内と制作会社で決める実務の順序に置き換えます。法的な結論を一律に示すものではなく、業種固有の法令や、健康情報など取扱いに追加条件がある情報を取得する場合は個別の確認も行ってください。
W3C+4PPC+4PPC+4
フォームを作る前に問い合わせの目的を一つ決める
最初に決めるのは項目名ではなく、「誰から、何を相談してもらい、受信後に誰が何を判断するフォームか」です。たとえば法人向けの見積相談なら、営業担当が対応可否と初回返信の担当を判断できることが目的になります。資料請求、採用応募、既存顧客のサポートまで同じフォームに入れると、必要項目も通知先も利用目的もぶれます。
目的は一文にまとめ、社内の共通判断にするのが基本です。対象者、相談内容、受信後の判断者が一文に入らない場合は、フォームを分けるか、最初の選択肢で通知先を切り替える設計を検討します。逆に、受信後の判断に使わない項目は、慣例で置かず削除候補にします。
フォームの中身が整っていても、必要なページから到達できなければ問い合わせには結び付きません。サービス説明や会社情報からの入口は、
フォームに到達するまでの問い合わせ導線で別に確認し、フォーム内部の設計と混同しないようにします。
必須項目と任意項目を分ける
「必須」は、入力してほしい項目ではなく、その情報がなければ受付や初回対応ができない項目です。W3CのForms Tutorialは、手続を完了するために求められる情報だけを入力してもらい、無関係または過剰なデータを求めると離脱しやすくなると説明しています。項目数を減らすことは、入力負担だけでなく、保存・閲覧・削除の対象を減らすことにもなります。
W3C
この表では、各項目を「必須・任意・取得しない」の三択で整理するのが基本です。判断が割れた項目は、「その情報がない問い合わせを受信したとき、誰が何に困るか」を確認すると決めやすくなります。
自由記述欄は柔軟ですが、利用者が業務に不要な情報まで書き込む可能性があります。入力説明には、相談の要点と必要な範囲を示し、秘密情報や取引に不要な個人情報を送らないよう伝える文が必要です。添付も同様に、受け取れる形式や内容を決めてから設けます。
利用目的を具体的な言葉で示す
利用目的は、社内向けの抽象語ではなく、入力する本人が受信後の扱いを予測できる言葉にします。個人情報保護委員会のQ&Aは、単に「サービスの向上」などとするのではなく、どの事業で何に使うかを一般的かつ合理的に予測できる程度に特定する考え方を示しています。ガイドラインでは、ネット上で取得する場合、送信ボタンを押す前に利用目的が目に留まる配置や、1回程度の操作で確認できるリンクを置くことが望ましいとされています。
PPC+1
たとえば、実際の運用が問い合わせ回答、見積書・資料の送付、打ち合わせ日程の調整であれば、その用途を短い文章でフォーム付近に示します。プライバシーポリシーには全社的な取扱いを記載し、フォーム付近では今回の取得に関係する用途を読み取れるようにすると、利用者が送信前に判断できます。
同意チェックボックスを設ける場合も、何に同意するのかを曖昧にしません。チェック欄があること自体は、取得項目の必要性や保存先、閲覧者を決めたことにはならないためです。問い合わせ回答とは別に案内メールを送るなど用途が増えるなら、その用途と選択方法を分けて検討します。
送信後の通知先と保存先を図にする
入力された情報がどこを通り誰へ届くかを理解しやすくするために、利用者の入力、暗号化通信、フォーム処理、メール通知、保存先、担当者確認、削除という流れを示す文字なし情報フローを整理しています。
送信後の情報は、利用者の端末からフォーム処理を通り、メール通知、WordPressのデータベース、外部フォームサービス、顧客管理システム（CRM）など複数の場所へ移ることがあります。画面仕様書とは別に、情報が通る順番、各場所に残る内容、閲覧者、削除方法を矢印でつないだ図を作ります。通信が暗号化されているかも、公開環境で確認する項目です。
通知と保存は分けて考えます。担当者へ届くメールに本文をすべて記載するのか、新着通知だけを送り管理画面で確認するのかでは、メールボックスに残る個人情報の量が変わります。WordPressや外部サービスも、「メールが届くから保存されない」と決めつけず、実際の設定、バックアップ、エクスポート先までが確認対象です。
保存期間は、問い合わせ対応、見積、契約前の検討など利用目的との関係で自社が基準を決めます。個人情報保護委員会のQ&Aは、個人データを利用する必要がなくなったときは遅滞なく消去するよう努める考え方を示していますが、別の法令や契約上の保存が必要な場合もあります。期限だけでなく、誰が定期確認し、どの画面・メール・バックアップから削除するかまで決めます。
PPC
添付ファイルを受け取る場合は、本文より容量が大きく、複製先も増えやすいため、種類、上限、保存場所、削除手順を別に確認します。個別の論点は
問い合わせフォームへファイル添付を追加する前の準備で整理できます。
閲覧できる人と委託先を確認する
閲覧権限は、「営業部」など部署名だけでなく、受付担当、回答担当、管理者、制作・保守会社の役割ごとに分けます。個人情報保護委員会のガイドラインは、個人データを扱う従業者、役割、取り扱う範囲を明確にし、アクセス制御という担当者ごとに閲覧範囲を限定する仕組みや、正当な権限を持つ人の識別・認証を求めています。
PPC+1
実務では、共有IDを避け、個人ごとのアカウントと権限を設定します。異動・退職・契約終了時に誰が停止するかも決めておかないと、公開時には適切だった権限が残り続けます。制作会社が障害調査のため一時的に閲覧する場合は、閲覧範囲、開始・終了条件、作業後の権限解除を記録できる形が適切です。
外部フォームやCRM、保守会社へ取扱いを委託する場合は、サービス名だけでなく役割を確認します。ガイドラインは、委託する業務に不要な個人データを渡さないこと、適切な委託先を選ぶこと、合意した安全管理措置や取扱状況を把握できる内容を契約へ盛り込むことを示しています。利用規約、契約、管理画面の権限設定を突き合わせ、自社の担当と委託先の担当を曖昧にしないようにします。
PPC
ラベル・入力説明・エラー表示を整える
利用者が送信前に迷わない画面は、項目名、必須・任意、入力形式、エラー時の直し方が見える画面です。ラベルは入力欄と対応付け、必須を色だけで示さず文字でも伝えます。電話番号の区切り、文字数、添付形式など制約がある場合は、エラーが出てからではなく入力前に説明します。
W3CのForms Tutorialは、各入力欄を識別するラベル、入力方法の説明、入力検証、成功・エラーの通知をフォーム設計の要素として挙げています。Validationの解説では、必須項目をラベルで明確にすること、画面側の検証だけでは回避され得るためサーバー側でも検証することが示されています。これらは日本の個人情報保護法の解釈ではなく、障害の有無にかかわらず利用しやすく、誤入力を減らすための実装上の指針です。
W3C+2W3C+2
エラー表示では、該当項目と原因を特定し、修正後に入力内容が消えないかを確認します。「入力に誤りがあります」だけでは、利用者が探し直さなければなりません。メールアドレスの形式、未入力、文字数超過など、想定する失敗を意図的に起こして検収します。
送信完了画面と自動返信は、送信できたこと、次に何が起きるかを伝える役割があります。返信時期を明示するなら、社内で守れる条件に限って記載します。PCとスマートフォンの双方で、入力欄の幅、キーボードの種類、長文入力、エラー位置、送信ボタンの押しやすさまで確認します。
制作会社へ渡す公開前確認表
画面・社内運用・制作実装の責任分担を整理するために、利用者、社内担当、制作会社・保守会社の三領域と、項目、表示、保存、権限、テストの関係を示す文字なし確認図を整理しています。
制作会社へ渡す資料は、完成画面の見本だけでは足りません。自社が決める運用、制作会社が確認する実装、公開を承認する検収方法を同じ表に置くと、未決事項を「公開後に考える」状態を避けられます。
この表で判断するのは、誰が決め、誰が実装し、何を見れば完了と認めるかです。「対応済み」という回答だけでなく、画面、管理画面、受信メール、権限一覧、削除結果など確認できる証拠を指定します。
発注・検収資料には、少なくとも次の項目をチェック欄として入れます。
- フォームの目的が一文で決まっている
- 取得項目が目的に照らして絞られている
- 各項目の必須・任意が決まっている
- 実際の利用目的を具体的に記載している
- プライバシー表示とリンクの位置を確認した
- 送信後の通知先が決まっている
- WordPress、メール、外部サービスなど保存先を把握した
- 保存期間と削除の実行者が決まっている
- 社内で閲覧できる人と権限範囲が決まっている
- 制作会社、保守会社、外部サービスの役割を確認した
- ラベルと入力説明をPC・スマートフォンで確認した
- 未入力・形式違い・文字数超過のエラーを確認した
- 完了画面と自動返信の内容を確認した
- PC・スマートフォンで入力から完了まで操作した
- 本番環境で送信、受信、保存、返信、削除をテストした
すべてにチェックが付くことより、各項目に担当者、確認資料、未決時の扱いが付いていることが検収には有効です。判断できない項目は「制作会社に任せる」とせず、選択肢と影響を説明してもらい、自社が承認する形にします。
IPAの「安全なウェブサイトの作り方」は、2021年3月31日最終更新の改訂第7版第4刷で、Webサイト開発者・運営者を対象に、脆弱性対策、運用面の対策、実装チェックリストを示した資料です。この資料を参照しただけで個別フォームの安全性が確認済みになるわけではありませんが、制作会社へ入力処理、メール送信、アクセス制御などの確認内容を尋ねる基準として使えます。
IPA
公開後の障害対応は、公開前検収とは分けて手順を用意します。実際に送れない、届かない事象が起きたときの切り分けは、
公開後に問い合わせフォームが送れない・届かない場合の確認を運用担当へ共有しておくと、画面、メール、サーバーのどこで止まったかを確認しやすくなります。
まとめ
問い合わせフォームの公開前は、同意欄だけを確認して終えるのではなく、目的から検収までを一続きで決めるのが基本です。目的が定まれば項目を減らせます。項目と用途が定まれば、通知・保存・権限を図にでき、制作会社へ具体的な実装とテストを依頼できます。
公開の条件は「画面が完成したこと」ではなく、利用者が迷わず送信でき、自社が受信後の情報を決めた担当・権限・期間で扱えることです。確認表を社内承認と発注・検収に共通利用すると、問い合わせの質と運用上の安全を別々に扱わずに済みます。
参考資料
