お問い合わせフォーム設置の基本と失敗しやすい点

1. サイトの作り方に合う方法を選ぶ

スマホでは表を横にスクロールできます。

HTMLだけを置くサーバーではPHPの送信処理をそのまま動かせません。機能が足りないときも、先に外部フォームで足りるかを確認し、サーバー変更を急がないようにします。必要機能の整理はサーバーの選び方が参考になります。

2. 最初の相談に必要な項目だけを必須にする

制作の相談なら、名前・返信先メール・相談内容から始める構成が考えられます。予算や希望時期が未定でも相談できるようにすると、分からない項目で入力を止めずに済みます。これは入力設計の提案で、必須項目は業務に合わせて決めてください。

• 必須と任意をラベルで明示する。
• エラーになった項目と修正方法を示す。
• 入力内容をできるだけ保ち、全項目を最初から書き直させない。
• パスワード・秘密鍵・カード情報を送らないよう案内する。
• 利用目的や取り扱いの案内を、入力前に確認できるようにする。

3. 送信処理と、実際のメール受信を分けて確認する

1. フォームの送信先に、処理プログラムやサービス指定のURLを設定する。
2. 受信先・送信元・返信先の役割を分けて設定する。
3. サーバー側でも入力形式・必須項目を確認する。
4. 処理が受け付けられた場合だけ、完了画面へ進める。
5. 自分で管理する受信箱で、通知メールと返信先を確認する。

PHPのmail()が成功を返しても、受信箱への配送成功を保証するものではありません。PHP公式のmail()の説明にもこの区別があります。迷惑メールへの振り分けやメール送信側の設定を含めて確認します。

送信元は利用するサーバーやメールサービスの案内に従い、訪問者のメールアドレスを無条件に送信元へ使わないようにします。返信先として使う場合も入力検証が必要です。自動返信は任意の設計であり、付けるなら第三者への迷惑メール送信に悪用されないかも考えます。

4. 公開前にこのテスト表で確認する

テストには自分で管理するメールアドレスを使い、受信担当者へ事前に伝えます。大量送信や障害を起こすテストは公開環境で行わず、テスト環境で確認してください。

「届かない」ときに見る順番

エラー表示、送信先URL、サーバー側の処理結果、宛先設定、受信箱と迷惑メール、メールサービスの制限の順に切り分けます。ログに問い合わせ本文や認証情報を不用意に残さないようにしてください。

5. CSRF対策とスパム対策は役割が違う

CSRF対策は、意図しない外部サイトからのリクエストなどへの備えです。ボットは自分でフォームを開いてトークンを取得できるため、CSRFトークンだけを迷惑送信対策とは考えません。設計の基礎はOWASPのCSRF対策資料を参照できます。

• サーバー側で必須項目・形式・長さを検証する。
• ハニーポットや送信間隔の制限を、通常利用を妨げない範囲で組み合わせる。
• セッションを切り替える送信にも備える必要があるか、運用状況を見て判断する。
• 被害が続く場合は、追加のレート制限やボット対策サービスを検討する。

当サイトのセッション単位の制限は、送信者全体に対する制限ではありません。対策を入れた後も、正当な相談が送信できるかを確認しながら運用します。

6. 問い合わせ件数と、フォームへの移動を分けて見る

相談ボタンが押された回数と、実際に送信が完了した回数は別です。GA4を使うなら、記事から相談ページへの移動と、受付完了のイベントを分けます。名前・メールアドレス・相談本文をアクセス解析へ送らないようにしてください。

当サイトではservice_cta_clickとcontact_submitを分けていますが、計測イベントはメール配送の保証でも売上の証明でもありません。設定の入口はAnalyticsとSearch Consoleの基本にまとめています。

7. 届いた相談は、次の対応と一緒に記録する

フォームを受信した後は、誰がいつ何を返すかを決めます。相談中の案件にもIDを付け、案件名・進捗・次の行動・行動期限を記録すると、受信箱を開くだけでは分かりにくい対応待ちを確認できます。

記録例：「INQ-001／資料整理の相談／相談中／件数と納期を確認する／9月25日」。受注が決まるまでは見込額と売上を分けます。請求した後は、請求日・入金期日・累計入金額を書き込みます。フォームの受信だけで入金済みにしないでください。