# ホームページの問い合わせフォームを改善する方法｜離脱を減らす実践チェックリスト

> 問い合わせフォームの改善を、入力前・入力中・送信後の3段階で点検するチェックリスト。必須項目、エラー表示、WCAG 2.2、スパム対策、CSRF、通知メールが届かなくなる原因と定期の送信テスト、GA4での計測、件数が少ないサイトでの効果の確かめ方までを解説します。

- 公開日: 2026-11-09
- 著者: 友田 陽大
- タグ: Webサイト改善, 問い合わせ, アクセシビリティ, セキュリティ, 計測
- URL: https://tomodahinata.com/blog/website-contact-form-cvr-improvement
- カテゴリ: Web集客・サイト運用
- 総合ガイド: https://tomodahinata.com/blog/website-no-inquiries-causes-solutions

## 要点

- フォームの損失は入力前（項目が多い）・入力中（エラーで詰まる）・送信後（届かない）の3か所で起きる。最後の『届かない』は誰も気づかないので、最初に確かめる
- エラーは該当する項目の近くに文章で示し、直し方も書く。WCAG 2.2 の 3.3.1・3.3.2・3.3.3・3.3.7 は問い合わせフォームにそのまま当てはまる。3.3.8 は認証の基準なので、フォームでは CAPTCHA を選ぶときの考え方として使う
- スパム対策はハニーポット・送信間隔の確認・回数制限を先に入れ、CAPTCHA は最後の手段にする。通知メールの差出人を訪問者のアドレスにすると、DMARC の検査で届かなくなることがある
- GA4 の自動の form_submit は『送信ボタンが押された』ことを示すだけで、受付の成功は分からない。成功はサーバーの応答を受けてから送る generate_lead で数える
- 月の問い合わせが少ないサイトでは、A/B テストは結果が出るまでに何か月もかかる。期間を固定した前後比較と、エラー件数・セッションの確認で判断する

---

問い合わせフォームの改善は、デザインを整える前に「どこで人が止まり、どこで連絡が消えているか」を3か所に分けて点検すると、直す順番が決まります。

| 段階 | 起きる損失 | 気づきやすさ |
|---|---|---|
| 入力前 | 項目の多さや必須の多さを見て、入力を始めない | 計測していれば分かる |
| 入力中 | エラーで詰まる、スマートフォンで入れにくい | 計測と実機の確認で分かる |
| 送信後 | 送信は成功したのに、通知メールが社内に届かない | **誰も気づかない** |

この記事はフォームだけを扱います。表示回数やページの内容など、サイト全体のどこで問い合わせが失われているかの切り分けは[ホームページから問い合わせが来ない7つの原因と改善方法](/blog/website-no-inquiries-causes-solutions)で扱っています。

## 最初の5分：今日、自分で1件送信する

改善の前に、自社のフォームから実際に1件送ってください。スマートフォンと、社外のメールアドレスの両方で試すのが理想です。確かめることは4つです。

- [ ] 送信後の画面に、次に何が起きるか（返信の目安など）が書かれている
- [ ] 社内の通知メールが**受信箱に**届いた（迷惑メールのフォルダではない）
- [ ] 訪問者への自動返信が届いた（設定している場合）
- [ ] 届いた内容に文字化けや欠けがない

ここで届かなければ、項目やデザインを直すより先に送信の仕組みを直します。後半の「通知メールが黙って届かなくなる理由」を読んでください。

## チェックリスト1：項目と入力のしやすさ

| 確認すること | 理由 | 直し方 |
|---|---|---|
| 必須項目は最初の返信に必要なものだけか | 必須が多いほど、入力を始める前に離脱する | 「これがないと返信できないか」で判定し、それ以外は任意か削除 |
| 任意の項目に「任意」と書いてあるか | 何を飛ばしてよいか分からないと全部埋めようとする | 必須と任意の両方を文字で示す（色だけで区別しない） |
| 自由記述欄に何を書けばよいか例があるか | 白紙の欄は書き始めにくい | 「ご相談の内容（例：○○の見積を知りたい）」のように書く |
| 電話番号・郵便番号の形式を厳しく縛っていないか | ハイフンの有無や全角でエラーになると詰まる | サーバー側で整形して受け付ける |
| 入力欄に autocomplete を設定しているか | ブラウザの自動入力が効き、スマートフォンの手間が減る | 氏名・メール・電話・会社名に適切な値を設定する（WCAG 2.2 の 1.3.5） |
| 確認画面が必要か | 1画面増えるごとに離脱の機会が増える | 送信前に内容を見られれば、確認画面は省いてよいことが多い |
| ボタンの文言で何が起きるか分かるか | 「送信」だけでは結果が予想できない | 「この内容で送信する」など |

項目の削減は、最も確実で、作業量も小さい改善です。ただし営業部門が必要とする情報を削ると、問い合わせの数は増えても、最初の電話で聞き直す手間が増えます。**削った項目は、最初の返信で聞けばよい**と社内で合意しておくと揉めません。

## チェックリスト2：エラー表示と WCAG 2.2

WCAG は、W3C（Webの標準を定める団体）が定めるアクセシビリティの基準です。問い合わせフォームに直接関わる基準は次のとおりで、内容は w3.org の WCAG 2.2 の本文で確認しました。

| 達成基準 | レベル | 内容（要旨） | フォームでの意味 |
|---|---|---|---|
| 3.3.1 エラーの特定 | A | 入力エラーを自動で検出したら、エラーの項目を特定し、エラーを文章で説明する | 「入力に誤りがあります」だけでなく、どの項目の何が誤りかを書く。赤枠だけで示さない |
| 3.3.2 ラベル又は説明 | A | 入力を求めるときはラベルか説明を示す | 入力欄の中の薄い例文（プレースホルダー）をラベルの代わりにしない。入力を始めると消えるため |
| 3.3.3 エラー修正の提案 | AA | 修正方法が分かっているなら、安全性や目的を損なわない限り提案する | 「メールアドレスに @ が含まれていません」のように直し方まで書く |
| 3.3.7 冗長な入力 | A（2.2で追加） | 同じ手続きの中で前に入力した情報を再び求めるなら、自動入力か選択できるようにする | 複数画面のフォームや確認画面から戻ったとき、入力が消えないようにする |
| 3.3.8 アクセシブルな認証（最低限） | AA（2.2で追加） | 認証の手順で、記憶やパズルのような認知機能テストを、代替手段などなしに求めない | 認証（ログイン）の基準なので、ログインのない問い合わせフォームには直接は当てはまらない。ただし CAPTCHA を選ぶときの考え方として参考になる |

エラーを示すタイミングにも注意が要ります。入力の途中で一文字ごとに赤くするとかえって邪魔なので、**その欄を離れたとき**か**送信を押したとき**に示すのが一般的です。送信時にエラーがあった場合は、エラーの一覧を画面の上に出し、各項目へ移動できるようにすると、画面の外のエラーに気づかないまま諦める人が減ります。

技術的な落とし穴として、「入力値が規則に合わないのに、画面には何も表示されずに送信だけが止まる」不具合があります。任意の選択肢を何も選ばなかった場合の値の扱いなどで起きやすく、作った人の環境では気づきません。テストでは、**任意の項目を全部空にした送信**と**全部埋めた送信**の両方を試してください。

## チェックリスト3：スパム対策

スパム対策は、利用者に手間をかけない方法から順に重ねます。

| 方法 | 仕組み | 利用者の手間 | 注意点 |
|---|---|---|---|
| ハニーポット | 人には見えない入力欄を置き、そこに値が入った送信を捨てる | なし | 画面読み上げソフトにも見えないようにし、キーボード操作で入らないようにする。見えてしまうと、障害のある利用者がスパム扱いになる |
| 送信までの時間の確認 | ページを開いてから極端に短い時間で送られたものを捨てる | なし | しきい値を厳しくしすぎると、自動入力を使う人を誤って弾く |
| 回数の制限 | 同じ送信元からの短時間の連続送信を止める | なし | 社内の共有回線からのテストで引っかからないようにする |
| サーバー側の入力検証 | 形式や長さを、ブラウザでなくサーバーで確かめる | なし | ブラウザ側の検証は簡単に迂回されるので、必ずサーバー側でも行う |
| CAPTCHA | 人間かどうかを判定する仕組み | ある〜少ない | 下記 |

CAPTCHA については、W3C の文書「Inaccessibility of CAPTCHA」が、文字や画像を読ませる方式は視覚・認知に障害のある人にとって障壁になること、そして自動化の技術によって突破されやすくなっていることを指摘しています。操作の少ない判定型のサービスもありますが、外部のスクリプトが訪問者の情報を送信するので、プライバシーポリシーでの告知が必要になります。**上の4つで防げない量が来たときに初めて検討する**のが妥当です。

もう一つ見落としやすいのが、訪問者への自動返信です。自動返信の宛先は入力されたアドレスなので、第三者のアドレスを入れて送信を繰り返されると、自社のフォームが迷惑メールの発射台になります。自動返信の本文に入力内容をそのまま載せない、回数制限をかける、といった対策を入れてください。

## チェックリスト4：CSRF を平たく言うと

CSRF（クロスサイト・リクエスト・フォージェリ）は、利用者が別のサイトを見ている間に、本人の知らないところで、あなたのサイトへの送信をさせる攻撃です。ログインが必要な管理画面では、本人の権限で設定を変えられてしまうので重大です。ログインのない問い合わせフォームでは被害は小さめですが、OWASP は、データを登録・変更する送信にはトークンなどの対策を入れ、フレームワークに組み込みの対策があればそれを使うよう示しています。

オーナーが外注先に確認するのは、次の1つで足ります。

> 「フォームと管理画面の CSRF 対策は何で行っていますか。フレームワークやプラグインの標準の対策を無効にしていませんか」

## チェックリスト5：通知メールが黙って届かなくなる理由

フォームの送信が成功しても、通知メールが社内に届かなければ、その問い合わせは存在しなかったのと同じです。しかも訪問者には「送信しました」と表示されているので、誰も気づきません。

Gmail の送信者ガイドラインは、**すべての送信者**に SPF か DKIM による認証を求め、1日5,000通を超える送信者には SPF・DKIM・DMARC のすべてを求めています。

| 用語 | 何をするものか |
|---|---|
| SPF | 「このドメインのメールを送ってよいサーバー」を DNS に公開する |
| DKIM | メールに電子署名を付け、受信側が送信元のドメインと改ざんの有無を確かめる |
| DMARC | SPF や DKIM に通らないメールを受信側がどう扱うかを、ドメインの持ち主が指定する |

フォームの通知メールでよくある失敗は次のとおりです。

| 症状 | 原因 | 直し方 |
|---|---|---|
| 特定の訪問者からの問い合わせだけ届かない | 差出人（From）を訪問者のアドレスにしている。他社ドメインや Gmail のアドレスを名乗るメールになり、認証に通らないことがある | From は自社ドメインの送信用アドレスに固定し、訪問者のアドレスは Reply-To に入れる |
| ある日から全部届かない | サイトの移転やサーバーの変更で、送信元が SPF に含まれなくなった | 送信元を SPF に追加するか、自社ドメインで認証済みの送信サービスに切り替える |
| 迷惑メールのフォルダに入る | DKIM の署名がない、または送信サーバーの評判が悪い | DKIM を設定する。Gmail は個人の Gmail 宛てに 1024 ビット以上の鍵を求め、2048 ビットを推奨している |
| 社内の一部の人に届かない | 受信側の振り分けルール、共有アドレスの転送設定、容量超過 | 通知先を個人でなく共有の受付アドレスにし、転送の設定を記録しておく |

設計で対策すべきことが2つあります。**問い合わせをメールだけに頼らない**こと（データベースやスプレッドシートにも記録し、メールが失われても内容が残るようにする）と、**届いていることを定期的に確かめる**ことです。

### 定期の送信テスト

一番確実なのは、決まった時刻にテスト用の問い合わせを1件送り、受信箱に届いたかを確認することです。自動化できるなら、外部の監視サービスや定期実行の仕組みでフォームを送信し、通知が一定時間内に来なければ担当者に知らせます。自動化しない場合でも、毎週月曜の朝に1件送る、と決めて記録するだけで、「数か月気づかなかった」は防げます。テストの問い合わせは件名に `[TEST]` を付け、計測から除外できるようにしておきます。

## チェックリスト6：個人情報の利用目的を送信前に示す

個人情報保護委員会のガイドライン（通則編）は、自社のホームページの入力画面から本人の個人情報を直接取得する場合を、利用目的を**あらかじめ本人に明示しなければならない**例として挙げています（法第21条第2項。ガイドライン 3-3-4）。そのうえで、ネットワーク上で取得するときは、送信ボタンを押す前に利用目的（または1回程度の操作で利用目的のページへ移れるリンク）が本人の目に留まるよう配置することが望ましい、としています。

実務では、送信ボタンの近くに「入力いただいた情報は、お問い合わせへの回答とご連絡のために利用します。詳しくはプライバシーポリシーをご覧ください」のような文とリンクを置きます。CAPTCHA や計測のツールで外部に情報を送る場合は、その説明もポリシーに含めます。自社の取扱いに当てはまるかの判断は、専門家に確認してください。

## 計測：GA4 の自動イベントだけでは「成功」が分からない

GA4 の拡張計測機能には、フォームのイベントが2つあります。Google のヘルプによると、`form_start` はセッション内で初めてフォームを操作したとき、`form_submit` はフォームが送信されたときに記録されます。

注意すべきは、`form_submit` が**送信の操作**を記録するだけで、サーバーが受け付けたかどうかは示さない点です。サーバーの障害や検証エラーで受付に失敗した送信と、成功した送信を区別する情報は含まれていません。自動のイベントがどの操作で記録されるかは、GA4 の DebugView などで自社のフォームを実際に操作して確かめてください。

確実に数えるには、自社でイベントを設計します。

| イベント | 種類 | 送るタイミング | 分かること |
|---|---|---|---|
| form_start | GA4 の自動（拡張計測） | セッション内で初めてフォームを操作したとき | どのフォームでも、操作を始めた人の数 |
| form_submit | GA4 の自動（拡張計測） | フォームが送信されたとき | 送信を試みた人の数（成功かどうかは含まない） |
| contact_form_start | 独自 | 問い合わせフォームの最初の入力欄に触れたとき | 問い合わせフォームに限った入力開始の数 |
| contact_form_error | 独自 | 検証で止まったとき（項目名をパラメータに。入力値は送らない） | どの項目で詰まっているか |
| generate_lead | GA4 の推奨イベント名で独自に送る | サーバーから受付成功の応答が返ったとき | 実際に受け付けた件数 |

独自のイベントに `form_start`・`form_submit` と同じ名前を付けないでください。自動のイベントと混ざり、どちらの数字か分からなくなります。筆者は、自動の2つは参考値として残し、判断には独自の3つを使うことをおすすめします。自動のイベントはサイト内のすべてのフォームを対象にし、受付の成功を区別しないため、問い合わせの件数を読む目的には向かないからです。`generate_lead` は GA4 が推奨イベントとして定めている名前なので、意味の分かる共通の名前で成功を記録できます。

GA4 の数字は、届いた問い合わせの実数と必ず突き合わせます。`generate_lead` が10件で、受信箱には7件しかなければ、どこかで通知が失われています。計測の全体の設計は[Search ConsoleとGA4で自社サイトの集客と問い合わせを可視化する方法](/blog/search-console-ga4-b2b-lead-tracking)で扱っています。

## 件数が少ないサイトで、改善の効果をどう確かめるか

「A/B テストで確かめましょう」という助言は、月に数件しか問い合わせがないサイトでは機能しません。必要な人数を計算すると分かります。

**仮想例**：フォームを開いた人のうち20%が送信している状態から、改善で30%にできたかを確かめたいとします。一般的な設定（有意水準5%・両側、検出力80%）で2つの割合を比べると、必要な人数は次のとおりです。

| 改善前 → 改善後（仮想例） | 片側に必要な人数 | 合計 | フォーム閲覧が月100人の場合 | 月300人の場合 |
|---|---:|---:|---:|---:|
| 20% → 30% | 294 | 588 | 約5.9か月 | 約2.0か月 |
| 20% → 25% | 1,094 | 2,188 | 約21.9か月 | 約7.3か月 |
| 10% → 15% | 686 | 1,372 | 約13.7か月 | 約4.6か月 |

改善の幅が小さいほど、必要な人数は急に増えます。何か月も待つ間に、季節・広告・営業の動きなど別の要因が混ざり、仮に差が出ても改善のおかげとは言い切れません。

上の数字は、次の短いスクリプトで計算したものです（Python 標準ライブラリだけで動きます）。

```python
from math import ceil, sqrt
from statistics import NormalDist

def visitors_per_arm(p_before, p_after, alpha=0.05, power=0.8):
    """2つの割合の差の両側検定（正規近似）で、片側に必要な人数"""
    z_a = NormalDist().inv_cdf(1 - alpha / 2)
    z_b = NormalDist().inv_cdf(power)
    p_bar = (p_before + p_after) / 2
    num = z_a * sqrt(2 * p_bar * (1 - p_bar)) + z_b * sqrt(
        p_before * (1 - p_before) + p_after * (1 - p_after)
    )
    return ceil(num**2 / (p_before - p_after) ** 2)

for before, after in [(0.20, 0.30), (0.20, 0.25), (0.10, 0.15)]:
    n = visitors_per_arm(before, after)
    print(f"{before:.0%} -> {after:.0%}: {n} per arm, {2 * n} total")
```

### 代わりにやること

1. **期間を固定した前後比較**：改善前の4週間と改善後の4週間のように、同じ長さ・同じ曜日の構成で比べます。期間中に広告やキャンペーンを変えたら記録しておきます。これは因果の証明ではなく、「悪化していないか」「大きく変わったか」を見るためのものです。
2. **エラーの件数を見る**：`contact_form_error` の項目別の件数は、少ない件数でも「どこで詰まっているか」を直接教えてくれます。特定の項目に集中していれば、そこを直すだけです。
3. **セッションの記録を見る**：録画型の分析ツールで、フォームを開いて送信しなかった人の操作を10件ほど見ると、項目の分かりにくさや、スマートフォンで押しにくいボタンが見つかります。導入する場合は入力欄の内容を記録しない設定（マスク）にし、プライバシーポリシーで告知します。
4. **人に頼んで入力してもらう**：社外の知人に、スマートフォンで実際に入力してもらい、迷ったところを聞くのも有効です。

一度に変えるのは1〜2か所にしておくと、悪化したときに戻す箇所が分かります。

## 外注が必要になる作業：SPF/DKIM設定・サーバー側の検証・成功イベント

**自社でできること**：今日の送信テスト、項目の見直し、エラー文言の書き直し、利用目的の文とリンクの追加は、WordPress などのフォームプラグインの設定だけでできることが多いです。

**既製のサービスで足りる場合**：フォーム作成サービスを使えば、スパム対策や受信データの保存が最初から付いていることがあります。サイトに埋め込む形でも、送信データがサービス側に残り、通知メールが届かなくても内容を確認できる点が利点です。

**外注を考える場合**：通知メールの認証（SPF・DKIM・DMARC）の設定、サーバー側の検証と回数制限、成功イベントの実装、送信テストの自動化は、設定画面だけでは済まないことが多い作業です。費用は、フォームの数、既存のシステムとの連携、計測の範囲、テストの自動化をどこまで行うかで決まります。依頼の範囲と費用の考え方は[部分改修・小規模制作・保守](/services/website-development)にまとめています。

## 通知が受信箱に届くまでの時間を測る

まず自分のスマートフォンから1件送信し、通知が受信箱に届くまでの時間を測ってください。届かなかった、または迷惑メールのフォルダに入ったなら、それが最初に直す場所です。