EFO改善の進め方｜フォーム離脱を減らす計測・入力・送信のチェックリスト

EFOを優先するかは、フォーム前後の数字で決める

フォームに人が来ていないなら、先に広告とLPの内容、CTAへの導線を見直します。一方、入力を始めた人が多いのに受付成功が少ないなら、EFOを優先する理由があります。LP全体のCVRだけでは、フォームのどこに問題があるかは分かりません。

以下は診断方法を示す架空の数字です。全て同じ期間・流入条件のフォーム到達セッションを対象に、同一セッション内の重複を除いて数えたとします。業界平均や改善実績ではありません。

この例では、入力開始前と入力開始後の両方に確認の余地があります。ただし割合だけで原因は断定できません。スマートフォンとPC、広告と自然検索などに分け、実際の操作で止まる箇所を再現します。LP全体の優先順位はLP改善の進め方、集客自体が少ない場合はホームページの問い合わせ改善も参照してください。

GA4のフォーム操作と、実際の受付成功を照合する

GA4の拡張計測機能には、最初のフォーム操作を捉えるform_startと、フォーム送信を捉えるform_submitがあります。取得するパラメータはGoogle公式の拡張計測機能イベントで確認できます。しかし、管理画面にイベントが出たことだけでは、自社のフォーム処理やCRM登録が正しく完了したかまでは確認できません。

フォーム到達、入力開始、受付成功をそれぞれ定義し、送信テストの結果と照合します。たとえば受付成功の独自イベントを設ける場合は、サーバーの正常な受付応答を確認した時点を条件にします。form_successなどの名前は設計例であり、GA4の自動収集イベント名ではありません。サンクスページの再読込や戻る操作で重複しないかも調べます。

• フォームID：資料請求と相談フォームを区別する識別子
• 段階：到達・開始・受付成功などの定義と発火条件
• エラー：入力値ではなく、必須未入力・形式不一致・通信失敗などの分類
• 照合先：受付システムの件数と、担当者へ届いた件数
• 集計単位：ユーザー、セッション、送信件数のどれを使うか

名前・メールアドレス・自由記述の内容を、解析イベントやURLに送らないでください。GoogleのPIIに関するポリシーも確認します。問い合わせ内容の確認は、必要な担当者だけがアクセスできる受付・顧客管理側で行い、分析用には件数や理由区分を使います。同意状態や計測拒否による欠損があるため、解析と受付データの完全一致を無理に目指しません。

項目を減らす前に「何のために聞くか」を整理する

入力負担を減らす基本は、目的に不要な質問を外すことです。ただし、資料請求と個別見積もりでは必要な情報が違います。「項目数は必ず何個以下」と決めるより、初回対応で使う理由を一つずつ書き出します。

これは汎用的な記入例で、Sunday Parkの受付条件や確定したフォーム仕様ではありません。たとえば配送が必要なサンプル請求では住所が必要ですし、電話で予約を調整するサービスでは電話番号が重要です。業務上の要件と利用者の手間を一緒に整理しましょう。

自由記述は「お問い合わせ内容」だけより、「制作したいもの、今困っていることをお書きください。未定の部分は空欄でも構いません」のように答え方を補うと、何を書くか判断しやすくなります。ただし、実際には必須の項目を任意のように説明しないことが前提です。

スマホの入力とエラー復帰を、実際の操作で直す

フォームの不便さは、完成した見た目より入力中に現れます。プレースホルダーだけを項目名にすると、入力した瞬間に説明が消えます。入力欄の外にラベルを残し、必須・任意、入力例、エラーの理由をそれぞれ区別します。W3Cのフォームラベルの解説では、ラベルと入力欄を適切に関連付ける方法が示されています。

メール欄ならメールに適した入力形式、電話欄なら用途に適したキーボード、自動入力には項目に合ったautocompleteの設定を検討します。住所や会社名の表記揺れを過度に制限せず、全角・半角などを受け付けられるかはサーバー側を含めて確認してください。

エラーの要約から該当欄へ移動できるか、キーボードだけでも修正・送信できるかも確認します。W3Cの通知ガイドを参考に、成功と失敗のどちらも利用者が認識できる設計にします。途中入力の保持は便利ですが、個人情報を不用意に端末へ長期保存する実装は避け、保持する場所と期間を設計担当者と確認します。

送信テストは「完了画面が出る」だけで終えない

受付成功の表示が出ても、通知メールやCRMへの連携に失敗していれば、問い合わせが放置されるかもしれません。見た目の改善と同時に、受付後の担当者までたどって確認します。本番テストを行うときは、担当者と日時・テストデータの扱いを決めてください。

• 正常送信：完了表示、受付記録、担当への通知が対応している
• 未入力・形式不一致：送れず、理由と修正箇所が分かる
• 通信失敗：受付成功と誤表示せず、再試行方法を伝える
• 連打・再読込：同じ依頼が不要に重複登録されない
• 確認画面から戻る：意図せず入力が失われず、修正が反映される
• スマホの自動入力：メール、電話、会社名が正しい欄に入る
• 同意状態の違い：フォーム利用と、許可された解析の動作をそれぞれ確認する
• 受付後：自動返信だけでなく、実際に対応する担当者が確認できる

送信ボタンの文言も結果に合わせます。相談を受け付けるだけなら「購入を確定」のような誤解を招く表現は使いません。返信時期を書く場合は、自社で守れる運用に基づく目安にします。確約していない「即日返信」などを、安心感のためだけに追加しないでください。

フォーム完了率と「有効問い合わせ単価」をセットで評価する

入力が簡単になって件数が増えても、対象外の相談ばかりになれば営業の負担が増えます。「有効」の定義を、対象サービスへの相談、連絡可能、重複でない、など具体的にそろえます。判定前の問い合わせを無効として数えないよう、比較期間後に同じ確認猶予を置きます。

架空例として広告費10万円、受付成功50件、有効な相談20件なら、受付単価は2,000円、有効問い合わせ単価は5,000円です。変更後が同じ広告費で受付成功70件、有効な相談18件なら、受付単価は約1,429円に下がりますが、有効問い合わせ単価は約5,556円に上がります。フォーム完了率の上昇だけを、事業成果の改善と呼ばないことが大切です。

検証では、対象端末・流入・期間・変更項目を残します。電話を任意化したのと同時に広告の対象も変えたなら、どちらの影響かは分けにくくなります。比較条件や必要なデータ量の考え方はLPのA/Bテストの進め方を参照し、小さな件数差を早急な勝敗判定に使わないようにします。

改善を依頼するときは、観察・変更・合格条件を渡す

制作会社へ「フォームのCVRを上げてほしい」とだけ伝えるより、現象と確認条件をそろえると具体的な改修につながります。

対象

スマホの資料請求フォーム。対象URL、端末、ブラウザ、フォームIDを記載

確認できた現象

電話番号の形式エラー後、再送信時に会社名も消える。検証日時と画面記録を添付

希望する変更

誤りの箇所だけを修正できるようにし、何を直せばよいか本文で案内する

合格条件

入力保持、エラー復帰、受付成功、通知到達、解析の重複防止を各テストで確認

公開後の確認

同じ流入条件の入力完了率と、有効問い合わせ数を継続比較する

費用はフォームの仕組み、外部システム連携、計測の改修範囲によって変わります。ツール導入、デザイン修正、サーバー処理の変更を分けて見積もり、誰がどこまで検証するかを確認しましょう。LPや広告からフォームまでの改善を相談したい場合は、現在の状況をお問い合わせください。対応範囲と進め方を個別に確認します。

参考情報・出典

• Google｜拡張計測機能イベントform_start・form_submitの定義と取得パラメータ／確認：2026-10-05
• Google｜個人を特定できる情報を送信しないためのヒントURL・入力値・解析イベントへの個人情報混入の注意／確認：2026-10-05
• W3C WAI｜Labeling Controls入力欄とラベルの関連付け／確認：2026-10-05
• W3C WAI｜User Notificationsフォームのエラーと完了通知／確認：2026-10-05