問い合わせフォームの作り方｜無料ツールから本格導入まで

ホームページに問い合わせフォームを付けたいと思っても、Googleフォームで十分なのか、WordPressで作るべきか、最初から本格的な仕組みが必要なのかで迷いやすいものです。

先に結論を言うと、フォームの完成条件は送信ボタンが動くことではありません。送信内容がどこへ残り、誰が確認し、どう分類して、いつ返信するかまで決めて、初めて運用できます。

少ない件数を一人または少人数で受け、まず公開して確かめたいならGoogleフォーム。WordPress内で見た目・通知・導線を整えたいならフォームプラグイン。複数担当への振り分け、対応履歴、権限、外部連携が必要ならフォームSaaSや個別開発が候補です。

この記事では、次の3点を順に整理します。

1. 自社に合う作り方の選び方
2. GoogleフォームとWordPressでの設置・確認手順
3. 公開前テストから送信後の保存・分類・改善までの運用

問い合わせフォームは3つの作り方から選ぶ

作り方に絶対の優劣はありません。まずは「どこまでを自社で運用したいか」で選ぶと、必要以上に複雑な仕組みを選ばずに済みます。

Googleフォームをホームページへ埋め込む

Googleフォームは、回答者向けに公開したフォームをHTMLでWebサイトやブログへ埋め込めます。回答はフォーム内で確認でき、Googleスプレッドシートにリンクして保存することもできます。Googleの公式ヘルプを見ながら、現行画面で公開範囲を確認してください。

「まず公開して、どんな相談が届くかを確かめたい」「担当が少人数で、回答を一覧に残せればよい」という段階に向きます。一方で、回答を1回に制限する設定やファイルアップロードを使うと、回答者にGoogleアカウントでのログインを求める場合があります。一般のお客様向けなら、ログアウト状態でも使えるかを必ず試しましょう。

WordPressのフォームプラグインを使う

WordPressサイトなら、フォームプラグインでサイトの見た目や送信後の導線に合わせやすくなります。代表例のContact Form 7はWordPress.orgで配布されるオープンソースのプラグインです。

ただし、プラグイン自体の利用と、サーバー・保守・メール配信などを含む運用全体の負担は別です。また、Contact Form 7単体では送信内容をWordPressのデータベースに保存しません。通知メール、保存先、自動返信、スパム対策を別々に設計・テストする前提で選びましょう。

フォームSaaS・CRM連携・個別開発を選ぶ

複数の担当や部署に自動で振り分けたい、対応状況や顧客履歴を追いたい、権限・監査・外部システム連携を管理したい。このような業務要件が出てきたら、フォームSaaSや個別開発を検討するタイミングです。

製品名や料金だけで決めるのではなく、契約終了時のデータ取り出し、障害時の復旧、管理者交代時の権限移管まで確認してください。

選び方の基準は、初期費用だけではありません。公開までの技術負担、保存先、通知と自動返信、担当人数、権限、連携、保守までを一緒に見ます。

作る前に決めたい6つのこと

ツールを開く前に、次の6項目を一枚のメモへ書き出してください。未決定のまま作り始めると、公開後に「誰が見るのか」「どこに残るのか」で止まりやすくなります。

1. 目的と必要項目を絞る

一般問い合わせ、見積もり、予約、資料請求を一つのフォームに無理に混ぜないことが大切です。目的が決まれば、初回返信に必要な項目も見えてきます。

W3C WAIは、手続きに必要な情報だけを尋ね、入力欄の目的が分かるラベルを付けることを案内しています。「あとで使うかもしれない」項目は、まず外せないかを検討しましょう。

2. 保存先・受信先・担当者を決める

送信内容の保存先を、メール、スプレッドシート、WordPressの保存機能、SaaS・CRMのいずれにするか決めます。あわせて、最初に確認する人、担当不在時の引き継ぎ先、返信の目安も決めておきます。

個人のメールアドレスだけを受信先にすると、不在や担当変更で確認が止まるおそれがあります。共有アドレスや、担当者を引き継げる保存先を選ぶと安心です。

リクマ

制作・運用の現場では、フォームが送れた時点より、その内容を一覧で追えて次の対応が決まる状態を完成と考えています。

3. 分類・利用目的・権限を決める

送信後に、有効な相談、売り込み、迷惑送信、テストをどう分けるかも決めておきます。保存先には、問い合わせ種別、対応状況、次の行動を残すと、重要な相談が埋もれにくくなります。

フォームなどで本人から個人情報を取得する場合は、原則として利用目的をあらかじめ明示する必要があります。フォーム付近または到達しやすいプライバシーポリシーで用途を示し、回答は必要な人だけが見られるようにしてください。通常の問い合わせより配慮が必要な用途は、導入先や専門家へ確認しましょう。

作成前の確認項目は次のとおりです。

• 何の問い合わせを受けるフォームか
• 初回返信に必要な入力項目は何か
• どこを正しい保存先とするか
• 誰が最初に見て、担当不在時は誰が引き継ぐか
• テスト・売り込み・迷惑送信と有効な相談をどう分けるか
• 利用目的、閲覧権限、保存期間・削除方法をどう決めるか

Googleフォームをホームページへ埋め込む手順

Googleフォームは、少ない件数をまず受け始める際の選択肢です。画面や公開方式は更新されるため、古い解説のボタン名ではなく、現行の公式ヘルプと確認結果を基準にしてください。

1. 質問を作り、公開範囲を決める

先ほど決めた目的に沿って、初回対応に必要な質問だけを作ります。作成後は、回答者に向けた公開範囲と回答者アクセスを確認します。

一般のお客様が使う場合は、組織内だけに回答者を限定していないか、ログインが必要になる設定を入れていないかを確認してください。「回答を1回に制限」とファイルアップロードは、Googleアカウントのログインを求める条件になり得ます。

2. HTMLを取得してサイトへ埋め込む

Googleフォームでは、その他メニューからHTML埋め込みを選び、表示されたコードをコピーしてサイトへ貼り付けます。CMSによって貼り付ける場所や権限は異なるため、テーマ固有の画面名までは断定しません。

埋め込み後は、横幅・高さ・スクロールの扱いを確認し、スマホで送信ボタンや入力欄が見切れていないかを見ます。

3. 回答をスプレッドシートへ保存する

回答はフォーム内で確認できますが、リンクしたGoogleスプレッドシートへ保存すれば一覧でも追えます。新規または既存のシートを選べます。

ここで大切なのは権限です。フォームの権限を変更しても、回答シートの権限が自動で同じ状態に保たれ続けるわけではありません。フォームとシートの両方で、誰が見られるかを確認してください。

4. ログアウト状態とスマホでテストする

公開前には、想定する回答者と近いログアウト状態のブラウザとスマホで開きます。必須項目、エラーの説明、送信完了の表示を確認し、管理者通知、回答保存、自動返信を設定した場合はそれぞれ実際に届くかを試します。

テストデータには、名前や本文の先頭などに分かる印を付け、本番の問い合わせと区別できるようにしましょう。

WordPressでフォームを作る手順

WordPress内でデザインや導線を整えたいなら、フォームプラグインが候補です。ここではContact Form 7を例に、設定画面の操作手順ではなく、公開前に確認すべき順番を整理します。

1. 現行要件を確認し、フォームを配置する

導入前に、WordPress.orgでプラグインの現行要件、更新状況、互換性を確認します。権限がない場合は、無理にインストールせず管理者に確認してください。

Contact Form 7では、作成したフォームをブロックまたはショートコードでページへ配置できます。配置後は、問い合わせページの導線とモバイル表示を確認します。

2. 入力項目とラベルを整える

入力欄には、何を書くための欄かが分かるラベルを付けます。必須条件、入力例、エラーが起きた場所・原因・直し方、送信成功の表示も、画面だけで分かる状態を目指します。

入力項目を増やす前には、「初回返信のために本当に必要か」を一つずつ問い直してください。

3. 通知メールと自動返信を分けて設定する

Contact Form 7のメール設定では、Fromにはサイトと同じドメインのアドレスを使い、回答者のアドレスはReply-Toに設定することが推奨されています。宛先の役割を混ぜないことが、トラブルの切り分けに役立ちます。

Mail (2)は自動返信テンプレートとして利用できます。ただし、設定しただけで管理者通知や自動返信の到達が保証されるわけではありません。送信者側、管理者側、保存先の三方向で実際にテストしてください。

4. 保存・スパム対策・プライバシーを確認する

Contact Form 7単体は送信内容をデータベースに保存しません。メールだけで足りるのか、別の保存手段が必要なのかを先に決め、保存するなら閲覧権限と保持期間も決めます。

reCAPTCHAなどの外部サービスを使う場合も、迷惑送信がゼロになるとは考えず、現行の料金・規約・外部へ送信され得るデータを確認してください。スパム対策と、届いた内容を分類する運用は別々に必要です。

本格導入へ切り替える判断基準

問い合わせ件数だけが切り替えの基準ではありません。次のような要件があれば、SaaSや個別開発を比較する価値があります。

Googleフォームや単体プラグインを超えるサイン

• 複数の担当・部署へ自動で振り分けたい
• 対応中、返信済み、保留などの状態を共有したい
• 問い合わせから商談・顧客履歴までつなげたい
• 条件分岐、予約、見積もり、決済、本人確認などの業務ロジックがある
• 保存期間、アクセス権、監査ログ、外部連携を管理したい
• ファイルや機微な情報を扱う

SaaS・個別開発を選ぶ前の確認質問

製品別の料金や保存上限は契約・仕様で変わるため、未確認の数値を比べるより、次の質問に答えられるかを確認します。

• 管理者は誰で、異動・退職時に権限を引き継げるか
• データはどこに保存され、保持・削除・出力はどう行えるか
• 障害時に問い合わせ内容を復旧できるか
• 既存の顧客管理、予約、メール配信とどう連携するか
• 契約終了時にデータを取り出せるか
• サポート範囲、追加費用、利用上限は何か

個別開発で外せないセキュリティ要件

個別開発では、ブラウザ側の入力チェックだけでなく、サーバー側でも入力を検証する必要があります。Cloudflare Turnstileなどを採用する場合も、クライアント側のウィジェットだけでは完結せず、サーバー側の検証が必要です。

ファイルアップロードには、許可する拡張子、実際のファイル種別、ファイル名、サイズ、保存先、権限、マルウェア対策など、多層の対策が必要です。初回問い合わせに不要なら、付けずに後工程で安全な受け渡し方法を案内する選択肢を検討してください。

公開前に確認する10項目

公開前は、回答者側と受信・管理側を分けて確認します。画面上で送信できても、メールや保存が失敗していれば運用できません。

回答者側の確認

1. フォームの目的が冒頭で分かるか
2. 初回対応に不要な項目を求めていないか
3. ラベル、必須、入力形式が文字で分かるか
4. ログアウト状態とスマホで開けるか
5. エラー箇所・原因・直し方、送信成功が明確か

受信・管理側の確認

6. 管理者通知が実際に届くか
7. 自動返信が実際に届き、返信先が正しいか
8. 送信内容が決めた保存先に残り、必要な人だけが見られるか
9. 利用目的・プライバシーポリシーへ到達できるか
10. テスト送信と本番問い合わせを見分けられるか

リクマ

公開前テストには、名前や本文の先頭に「テスト」と入れておくのがおすすめです。本番の問い合わせ数へ混ざると、改善判断までずれてしまいます。

項目数の絞り方や、途中で離脱されにくいフォームの細かな見直しは、問い合わせフォームの離脱を防ぐチェックポイントで補えます。

送信後の管理まで作って初めて完成

フォームの価値は、送信された後に初めて出ます。保存・分類・担当・返信をばらばらにせず、一つの流れとして決めましょう。

保存・分類・担当を一つの流れにする

送信日時と本文だけでなく、問い合わせ種別、対応状況、担当、次の行動を残します。テスト、売り込み、迷惑送信、有効な相談を分けると、全送信数だけでは見えない状況を判断しやすくなります。

分類を自動化する場合も、誤った判定を後から見直せるようにしてください。保存先を一つの正本に決め、メールや各種通知は補助として位置付けると、確認漏れを減らしやすくなります。

リクマ

送信日時だけでは優先順位を付けにくいので、私は「問い合わせ種別・対応状況・次の行動」まで一緒に残す設計を優先します。

返信漏れを防ぐルールを決める

誰が最初に見るか、休業日をどう扱うか、担当が不在なら誰が引き継ぐかを決めます。返信目安は、自社で守れる範囲にしてください。守れない時間を表示するより、社内の確認ルールを先に整える方が安全です。

件数と有効問い合わせを分けて見る

送信成功数には、テスト、売り込み、迷惑送信も含まれ得ます。有効問い合わせの定義を社内で決め、総送信数とは分けて見ることが大切です。

問い合わせを記録として残す考え方は、問い合わせを資産に変えるには、リスト化の一手を忘れないでも紹介しています。

計測して一箇所ずつ改善する

公開後は、数だけでなく中身を見ながら改善します。短期間の変化を過大に解釈せず、変更内容と条件を記録しておくことが基本です。

送信成功と有効問い合わせを別に計測する

GA4には、フォーム利用などの見込み顧客獲得を測る推奨イベント generate_lead があります。ただし、イベント名だけで有効な問い合わせかどうかを自動判定するわけではありません。どの送信完了を記録対象にするかは、自社で計測条件を設計します。

フォーム表示、送信成功、有効問い合わせを分けて見ます。可能なら、入力開始、エラー、初回返信までの時間も、自社の運用に合う指標として検討してください。

改善は一度に一箇所へ絞る

入力項目、案内文、CTAなど、変える仮説は一つに絞ります。変更前後の期間と条件を記録し、送信数だけでなく有効問い合わせの変化も確認しましょう。

リクマ

改善点を一度に増やすと、何が効いたか分からなくなります。まず一箇所だけ変え、次のログで前後を見るくらいが実務では扱いやすいです。

問い合わせフォームの作り方でよくある質問

Googleフォームをホームページに埋め込むと、回答者のGoogleアカウントは必要ですか？

通常の公開範囲だけで、回答者にGoogleアカウントが一律必要になるわけではありません。ただし、「回答を1回に制限」やファイルアップロード、組織のアクセス設定ではログインを求めることがあります。一般のお客様向けなら、ログアウト状態で開けるかを実際に確認してください。

Contact Form 7を入れれば、問い合わせ内容はWordPressに保存されますか？

Contact Form 7単体では保存されません。メールだけでよいか、別の保存手段が必要かを先に決め、保存するなら権限と保持期間も確認してください。

自動返信が届けば、管理者にも必ず届いていますか？

いいえ。自動返信と管理者通知は別のメールです。管理者通知、自動返信、保存先をそれぞれ実際にテストしてください。

どの段階でフォームSaaSや個別開発を検討すべきですか？

複数担当、対応履歴、権限、監査、業務連携、機微な情報の取り扱いが必要になったときです。問い合わせ件数だけではなく、受信後の業務要件から判断してください。

問い合わせフォームにファイル添付は付けた方がよいですか？

初回対応に本当に必要な場合だけ検討してください。Googleフォームではログインが必要になる場合があり、個別開発では追加の安全対策が必要です。不要なら、後工程で安全な受け渡し方法を案内する方が管理しやすい場合があります。

まとめ｜フォームは受信後の流れまで作る

少ない件数をまず受けるならGoogleフォーム、WordPress内の見た目や通知を整えたいならフォームプラグイン、複数担当・履歴・連携・権限が必要ならSaaSまたは個別開発を検討します。

選ぶ基準は無料か有料かだけではありません。保存、担当、分類、返信、権限、テストがつながっているかで決めます。

まずは、次の3つから始めてください。

1. 目的・必要項目・保存先・担当・分類・利用目的と権限を書き出す
2. 最小限の方法を一つ選ぶ
3. ログアウト状態、スマホ、受信先、保存先でテストする

出典

• Googleフォームを公開して回答を受け取る（Google ヘルプ）
• フォームの回答を確認・保存する（Google ヘルプ）
• フォームのファイルアップロードについて（Google ヘルプ）
• フォームの公開と回答者アクセスの新しい仕組み（Google ヘルプ）
• Contact Form 7（WordPress.org）
• Save submitted messages with Flamingo（Contact Form 7）
• Best practice to set up mail（Contact Form 7）
• FAQ（Contact Form 7）
• reCAPTCHA（Contact Form 7）
• Forms Tutorial（W3C WAI）
• Labeling Controls（W3C WAI）
• Validating Input（W3C WAI）
• User Notifications（W3C WAI）
• 個人情報の保護に関する法律についてのガイドライン（通則編）（個人情報保護委員会）
• Input Validation Cheat Sheet（OWASP）
• File Upload Cheat Sheet（OWASP）
• GA4 推奨イベント（Google for Developers）
• Turnstileのサーバー側検証（Cloudflare）