ブログのお問い合わせフォームの作り方｜項目設計から送信・受信確認まで

お問い合わせフォームは、設置できたら完成ではありません。読者が入力でき、送信結果が分かり、担当者が内容を受け取って対応できるところまで確認する必要があります。ボタンが表示されていても、受信先が古い、送信に失敗している、営業日外の対応が不明といった問題が残ることがあります。

この記事では、ブログやサービスサイトへフォームを設置する際の設計と確認を扱います。特定プラグインのランキングではなく、自分の運営に合う方式を選び、公開前に何を試すかを整理します。既にフォームがある場合も、項目数と送受信の点検に使えます。

受け付ける相談と担当者を決める

最初に、読者からの質問、仕事の依頼、広告掲載、取材など、受け付ける内容を整理します。すべて同じ受信先で対応できるなら、複雑な分岐を作る必要はありません。担当が異なる場合は、問い合わせ種類で振り分ける方法を検討します。

返信担当、確認頻度、休業時の扱いも決めます。フォームに「すぐ返信」と書いても、実際に確認する人がいなければ期待を裏切ります。確実に守れる案内を表示し、急ぎの場合の連絡方法があるなら分かる場所へ置きます。設置作業より先に、受け取った後の運用を決めることが重要です。

必須項目は返信に必要なものから選ぶ

氏名、返信先、相談内容など、対応に必要な項目を選びます。電話を希望しない人にも電話番号を必須にするかは、業務上必要かを検討してください。単に後で使うかもしれないという理由で住所や生年月日まで集めると、入力の負担と管理する情報が増えます。

予算や経験は、相談の振り分けに役立つ場合がありますが、初回時点で答えられない人もいます。「未定」を選べるようにする、任意にするなど、必要性に応じて設計します。必須と任意を明示し、入力例が実際の回答として送信されないよう、初期値と例示の違いにも注意してください。

CMS機能・プラグイン・外部サービスを比べる

利用しているサイトの仕組みに合う方式を選びます。WordPressなら対応するフォーム機能、静的サイトなら外部送信サービスや自社の送信処理などが候補になります。価格だけでなく、受信方法、履歴の確認、迷惑送信対策、利用制限、保守担当を比較します。

外部サービスを使う場合は、入力内容がどこへ送られ、どのように管理されるかを確認します。運営者として必要な説明や管理方法を決め、利用条件に従ってください。無料枠の上限や通知先の制限も、選ぶ時点の公式案内で確認します。将来の件数を理由なく大きく見積もる必要はありませんが、上限時にどうなるかは知っておきます。

入力欄とエラーメッセージを設計する

各入力欄には何を入れるか分かるラベルを付けます。入力例だけを表示すると、文字を入れた後に何の欄か分からなくなることがあります。必須項目が空の場合や、メールアドレスの形式が違う場合に、どの欄を直せばよいか伝わる表示にします。

エラー時にすべての入力内容が消えると、再入力の負担が大きくなります。必要な範囲で入力を保ち、修正すべき箇所へ戻れるか確認します。ただし、画面上の入力確認だけに依存せず、送信を受ける側でも適切に検証する必要があります。具体的な実装は採用する方式の公式手順に従い、不明な部分を見た目だけで代用しないでください。

公式情報：MDN：クライアント側のフォーム検証。

成功表示と失敗表示を分ける

送信中、送信成功、送信失敗の状態を明確にします。ボタンを押した直後に成功と表示するのではなく、送信処理の結果を確認して表示するようにします。通信に失敗した場合は、再試行できる案内と、必要に応じて別の連絡方法を用意します。

同じページ内で完了表示へ切り替える場合は、読者が変化に気付けるかも確認します。画面下に小さく表示されるだけでは、送信できたか分からず繰り返し押す可能性があります。送信中に何度も押せないようにするなど、重複送信を減らす設計も担当者と確認してください。

自動返信には必要な情報だけを載せる

自動返信を使う場合は、受付したこと、今後の対応、返信の目安を伝えます。相談内容の全文を返信する必要があるかも検討してください。入力されたメールアドレスが誤っている場合に、別の人へ内容が送られる可能性を考え、扱う情報に応じて設計します。

自動返信が届くことと、担当者への通知が届くことは別です。両方をテストします。また、受信メールから返信した時に、正しい相手へ送れるかも確認します。メール送信の設定は利用サービスによって異なるため、差出人や返信先を自己判断で入れ替えるのではなく、公式案内に従ってください。

迷惑送信対策と入力のしやすさを両立する

フォームには迷惑送信が届く可能性があります。採用するサービスの対策機能を確認し、必要な範囲で導入します。ただし、確認操作が多すぎたり、特定の端末で動かなかったりすると、本来の相談も妨げます。対策を入れた後に、通常の利用者として操作してください。

機械的な送信の検知だけでなく、短時間の大量送信、内容の確認、受信後の取り扱いも運営上の課題です。公開してよい設定値と秘密にする認証情報は区別し、秘密情報をブラウザーへ配るコードに埋め込まないようにします。実装担当者へ任せる場合は、この区別を確認項目に含めます。

テスト項目を一覧にして実行する

通常入力、必須項目の未入力、メール形式の誤り、長い相談文、スマートフォン、送信失敗時の表示を確認します。キーボードだけでも入力欄を移動できるか、ラベルが分かるかも見ます。実際の通信失敗を試す場合は、管理下の検証環境で行い、本番の正常利用を妨げないようにします。

テストは受信担当者へ事前に伝え、必要な少数の送信で行います。件名や内容にテストと分かる印を付け、終了後の扱いも決めます。受信までの流れが確認できなければ、フォーム画面だけ正常でも公開完了にはしません。迷惑メールフォルダやサービス側の履歴も、権限のある担当者が確認します。

公開場所と案内文を確認する

フッターやサービス案内からフォームへ到達できるようにします。読者が相談を考えた時に見つけられる位置へ置き、リンク名も「お問い合わせ」など内容が分かるものにします。記事末尾のCTAでサービス紹介へ誘導している場合は、そこからフォームまでの流れも確認します。

フォームの直前には、相談できる内容と、その後どう連絡するかを短く説明します。契約申込なのか、相談の受付なのかが曖昧なボタンは避けます。個人情報の取り扱いについて必要な案内を整え、運用実態と異なる説明を置かないようにしてください。専門的な判断が必要な場合は適切な確認を行います。

受信担当者との確認シナリオ

テスト前に、送信する時刻、使う返信先、入力する問い合わせ種類を担当者へ伝えます。送信者側では成功表示を確認し、受信者側では通知が届いた時刻と内容を確認します。自動返信を使う場合は、それも別に確認します。三つの結果を一つの記録へ残すと、どの段階で止まったかを切り分けられます。

例えば送信者には成功と表示されたが通知メールがない場合は、フォーム側の受信履歴とメール通知の設定を確認します。すぐに同じ内容を何度も送信せず、問い合わせが保存されているかを権限のある担当者が調べます。通知だけが失敗しているのか、受け付け自体が失敗したのかで対応が変わります。

正常に受け取れたら、担当者が返信操作を行うところまで確認します。誤った返信先が設定されていないか、送信者が返事を受け取れるかを見ます。テストに使った情報は決めた方法で管理し、本当の相談件数と区別します。送信画面だけでなく、最初の返信まで通すことで運用上の抜けを見つけやすくなります。

公開後も受信できる状態を点検する

フォーム機能、サイト、メール設定を変更した後は、送受信を再確認します。問い合わせが急に減った場合も、需要の変化だけでなく、フォームの動作や通知先を確認してください。表示されていることと、受信できていることを分けて点検します。

対応履歴には受付日、種類、担当、対応状況を必要な範囲で残します。解析で送信成功を測る場合も、受信記録と整合しているかを確認します。フォームの品質は設置時の見た目だけでなく、読者が迷わず送り、担当者が漏れなく対応できる運用によって決まります。

送信成功を解析でも把握したい場合は、GA4でCTAクリックを計測する方法｜記事からサービスへの移動と問い合わせを分けるでクリックとの区別を確認してください。

記事からサービス紹介、問い合わせまでを一つの流れとして整えたい方は、収益導線を含むサイト構築の内容をご確認ください。

参考資料・公式情報

• MDN：クライアント側のフォーム検証

公式情報の確認日：2026年9月12日。サービスの仕様・掲載条件は変更されるため、実行時は最新の公式案内を確認してください。