EFOとは?フォーム完了率の測り方と入力離脱を減らす7つの改善

2026年5月30日

著者: 与謝秀作
EFOとは?平均値の目安と改善するための7つの方法を解説

EFO(Entry Form Optimization)は、問い合わせや申込みなどの入力フォームを使いやすくし、必要な情報を正確に送れるようにする取り組みです。項目を減らすだけでなく、入力の説明、エラーからの復帰、送信成功の確認まで含めて改善します。完了率には複数の分母があるため、まず何を測っている数字かをそろえることが出発点です。

EFOは入力フォームを使いやすくする取り組み

入力フォームでは、利用者は「何を入力するか」「なぜ必要か」「この操作で送れたか」を判断しています。EFOでは、この判断に必要な情報を近くに置き、入力や操作の負担を減らします。英語ではform optimizationという表現が自然で、EFOは日本のWebマーケティングで使われる呼称として理解するとよいでしょう。

目指すのは数字の上昇だけではありません。営業が対応できる問い合わせ情報を受け取りつつ、誤送信や重複を減らすことも目的です。必要な本人確認や希望条件まで削ると、入力しやすくなっても、その後の対応が難しくなる場合があります。

フォーム完了率の一律の平均値を目標にする前に、自社の利用目的、必要情報、対象端末を整理してください。設計の基本は、W3Cのフォーム作成チュートリアルでも確認できます。

到達・開始・送信成功を分けて完了率を測る

フォームを表示した段階、入力を始めた段階、システムが送信を受理した段階を別々に記録します。同じ期間・対象・集計単位にそろえた架空例で、フォーム到達500件、入力開始300件、重複を除いた受理成功90件なら、次のようになります。

指標

計算

値

到達から開始

300 ÷ 500

60%

到達から受理成功

90 ÷ 500

18%

開始から受理成功

90 ÷ 300

30%

開始者の未完了

(300 − 90) ÷ 300

70%

この例では、集計対象の開始300件を同じ判定期間で成功・未完了に分類できると仮定しています。未観測の送信、日をまたぐ完了、再訪による重複があると、そのまま70%を離脱率とは呼べません。「1 − 完了率」が成り立つのは分母と判定条件が同じ場合です。

GA4の拡張計測機能にはform_startとform_submitがありますが、実装やフォームの方式によって取得状況は異なります。form_submitをサーバーでの受理成功や登録人数と置き換えず、GA4の拡張計測の仕様と実際の受理記録を照合します。

自社フォームの離脱箇所と入力エラーを調べる

最初に、自分でスマートフォンとパソコンから入力してください。長い選択肢、わかりにくい必須表示、戻ると消える入力内容、画面外のエラーなど、操作で再現できる問題を探します。分析ではフォーム全体の率だけでなく、端末、流入元、フォームの用途ごとに同じ条件で比較します。

エラーは件数と発生箇所、表示したメッセージ、修正後に成功できたかを確認します。必須電話番号で止まる場合でも、入力形式が厳しいのか、利用目的が伝わらないのか、電話連絡を望まないのかで対策は変わります。個々の入力値やメールアドレスを分析ツールへ送って原因を探す方法は避け、必要な集計項目だけを設計します。

入力負担と操作の迷いを減らす7つの改善

以下は、症状に応じて選ぶ7つの改善候補です。すべてを一度に変更せず、再現できた問題に対応するものから試します。

改善

変更候補

手動確認と監視

1. 必須・任意を整理

受理後の対応に使わない項目を任意にし、必要な項目は理由を示す

未入力でも受理できるか/問い合わせ品質

2. ラベルと説明を見える位置に置く

入力後も消えないラベルと、迷いやすい項目の説明を付ける

入力中に項目名がわかるか/同じ質問の件数

3. 入力補助を適切に使う

内容に合うautocompleteやinputmodeを開発担当と確認する

端末のキーボード・補完結果/入力ミス

4. 形式とエラーを見直す

許容できる空白や記号を受け付け、直す箇所を具体的に示す

修正後に進めるか/同じエラーの反復

5. 複数ステップの進捗を示す

現在位置と残る工程、戻る操作をわかりやすくする

戻っても入力が残るか/各工程の完了

6. モバイルとキーボードに対応する

拡大・タブ移動・フォーカス・送信ボタンを点検する

マウスなしで操作できるか/端末別成功

7. 成功状態と再送を整える

受理結果と次の案内を示し、意図しない重複を抑える

二重クリック・再読込/重複受理

入力途中に即座にエラーを出せば常によいわけではありません。まだ入力を終えていない人を遮らず、送信時や適切なタイミングで、何が問題でどう直せるかを伝えます。画面上の検証に加えてサーバー側でも検証する考え方は、W3Cの入力検証ガイドを参照してください。

送信成功・個人情報・アクセシビリティを検証する

確認用の送信を用意し、利用者への表示、受理記録、分析イベントを三つ並べて確認します。下表の期待値は実装に合わせて決めるもので、既存サイトがその動作になっているという意味ではありません。

ケース

利用者への表示

受理・計測の確認

空欄

必須項目と修正方法がわかる

不正な内容が受理されず、成功に数えられない

形式エラー

該当箇所を特定できる

修正後に送信できる

通信失敗

未送信か確認待ちかがわかる

失敗を成功として計測しない

正常送信

受理と次の行動がわかる

受理1件と成功記録を照合する

二重クリック

処理中・完了状態がわかる

重複受理と重複イベントを確認する

再読み込み

不用意な再送を避けられる

同一成功の再計上を確認する

分析への同意拒否

必要な申込み操作ができる

同意に沿う計測になっているか確認する

キーボードのみ

フォーカス・エラー・完了がわかる

一連の操作が完結する

利用規約、個人情報の説明、連絡手段など、判断に必要な情報を単に離脱防止のために隠さないでください。アクセシビリティの初期点検はW3Cの簡易チェックも参考になります。

同じ条件で改善結果と問い合わせ品質を比較する

変更前後は、フォームの対象、完了の定義、期間、端末と流入条件をそろえます。受理成功に加えて、有効な問い合わせ、重複、迷惑送信、対応に必要な情報の不足も見ます。送信だけ増えて有効な相談が減っていれば、目的に合う改善とは限りません。

A/Bテストを行う場合は、無作為な振り分け、主指標、必要なデータ量、終了条件を事前に決めます。件数が少ないときは短期間の割合を勝敗として扱わず、操作テストと実数を中心に確認します。まず一つのフォームで分母を明示した集計と上記8ケースの検証を行い、次の変更を決めてください。

関連記事

関連記事