この記事の目次
EFOは、必要な入力を迷わず完了できるようにする1．必須項目と成果の意味を決める2．ラベルと入力支援を整える3．失敗時にも完了へ戻れるか試す4．フォーム完了率を正しく集計するAIと照合し、改善を完了するEFOは、必要な入力を迷わず完了できるようにする
EFOは入力フォームの最適化です。項目数を減らすだけでなく、必要性・入力形式・エラー・送信後の案内を整えます。短くした結果、営業や配送で必要な情報が欠ける場合もあるため、受付後の品質を一緒に確認します。以下は架空の問い合わせフォームの設計例です。
1．必須項目と成果の意味を決める
フォーム仕様、受付側の要件、GA4イベント、テスト環境を用意します。「開始」「送信クリック」「受付成功」を分け、成果はサーバーが受け付けた状態とします。自動収集イベントが受付成功を表すとは限りません。
| 項目 | 確認する問い | 架空の判断 |
|---|---|---|
| 電話番号 | 初回回答に必須か | メールで回答できるなら任意化を検討 |
| 会社名 | 受付の選別に使うか | 法人対象という目的と照合 |
| 自由記述 | 何を書くか分かるか | 入力例と必要な範囲を示す |
| 同意 | 必要な説明にたどれるか | 説明を読めるリンクを付ける |
項目を削除する前に利用担当へ確認し、削除理由と代替手段を記録します。初期チェックによる同意の誘導や分かりにくい取消し導線で数値を上げようとしません。
2．ラベルと入力支援を整える
- 各入力に表示ラベルを付け、labelのforと入力のidを一致させる。
- 必須・任意と形式を入力前に示す。プレースホルダーだけに説明を置かない。
- 適切なtypeとautocompleteを選び、スマートフォンの入力を確認する。
- 入力の形式を過度に制限せず、サーバー側でも妥当性を確認する。
<label for="contact-email">返信先メールアドレス（必須）</label>
<p id="email-help">回答を受け取れるアドレスを入力してください。</p>
<input id="contact-email" name="email" type="email"
autocomplete="email" required aria-describedby="email-help">
これは項目の表示例で、送信処理は含みません。W3Cのラベルと入力検証を照合し、実フォームの受付・エラー処理と接続してください。
3．失敗時にも完了へ戻れるか試す
| 操作 | 期待する状態 |
|---|---|
| 必須を空欄で送信 | 対象項目と直し方が分かり、成功扱いにならない |
| メール形式を誤る | 色だけでなく文章で理由が伝わる |
| 通信が失敗する | 入力を不要に消さず、再試行方法が分かる |
| Tabで順に移動 | 順序・フォーカスが分かり、送信まで操作できる |
| 成功後にリロード | 同じ受付を新たな成果として重複しない |
スクリーンリーダーでラベル・エラー・成功通知が伝わるかも確認します。テスト入力は架空の値と専用の受付先を使い、実顧客へ通知を送らない設計にします。フォーム点検票に期待・実測・修正担当を記録してください。
4．フォーム完了率を正しく集計する
架空例：フォーム開始のあるセッション200、同じセッションで受付成功80なら40%。開始イベント300回で割った値とは別です。同じ期間・フォーム・端末・セッションの集合で比較してください。エラー率や無効受付の増加も確認します。
入力内容を分析用パラメータへ送らず、必要なら field_type や固定した error_type を設計します。自由記述やメールアドレスを録画・AIへ渡しません。Clarityのマスキングも設置前に確認します。
AIと照合し、改善を完了する
フォームの目的、必要項目の理由、匿名化した操作結果、受付成功の定義を渡します。
必須項目の削除を勝手に決めず、操作上の障害と確認担当を表にしてください。
入力内容やユーザーの心理を推測せず、正常・エラー・再送のテストを提案してください。
AIの案は受付担当の要件とW3Cの説明に照合します。正常・失敗・重複・キーボード・スマートフォンの確認が終わり、計測と受付記録の対応を説明できれば公開へ進めます。実機テストや改善効果は本記事では未確認です。比較設計はABテストへ進みます。
AI支援で制作。資料確認日：2026年10月6日。次回確認予定：2027年1月6日。Clarityの実アカウント操作・設置・録画受信、ABテストと実サイトの改善効果測定、実務者監修、第三者再現は未実施です。記入例・数値例は架空の教材です。改善効果を保証するものではありません。
