EFOとは？入力フォーム最適化の進め方と、改善前に決める計測項目

EFOは、問い合わせや購入のフォームを使いやすくし、入力から送信完了まで進めるように改善する取り組みです。

項目を減らすことだけでなく、入力方法の説明、エラーの直しやすさ、スマートフォンでの操作も見直します。

ただし、使いやすそうなフォームに変えただけでは、効果は分かりません。

送信に成功したか、届いた内容が業務に使えるかまで確認して、改善を評価します。

この記事では、計測項目を決めるところから、入力欄の棚卸し、スマホでの点検、施策の比較まで順に整理します。

自社のフォームをひとつ開き、表の確認項目を埋めながら進めてください。

EFOとは何を改善する取り組みか

入力支援と計測を分ける

EFOは「Entry Form Optimization」の略で、日本語では入力フォーム最適化と呼ばれます。

問い合わせ、資料請求、会員登録、購入手続きなどが対象です。

入力支援には、住所の補完や適切なエラー表示などがあります。

一方、計測では、どこで入力を始め、どの段階で止まり、送信に成功したかを調べます。

たとえばSiTestは、入力支援とフォームレポートを別の機能として案内しています（SiTestのEFO機能）。

入力を助ける機能と、その結果を確かめる機能は役割が違います。

役割	実施することの例	確認すること
入力を助ける	入力例・補完・キーボードの調整	操作しやすくなったか
失敗から戻れるようにする	エラー箇所と直し方の表示	自分で修正できるか
完了を伝える	送信成功のメッセージ	受け付けられたと分かるか
効果を測る	到達・開始・成功の計測	同じ条件で結果が変わったか

ツールを選ぶ前に、どの役割が不足しているかを整理します。

フォーム自体は使いやすくても、成功した送信が計測できていなければ、改善の判断を誤るためです。

項目を減らすだけで判断しない

不要な項目を減らすことは、入力の負担を見直す方法のひとつです。

ただし、必要な情報までなくすと、送信後に確認の連絡が増える場合があります。

たとえば、訪問見積もりの依頼で対応地域を判断する情報がなければ、受付後に調べ直す必要が出るかもしれません。

反対に、資料をメールで送るだけなら、最初から詳しい住所が必要とは限りません。

項目の数ではなく、その時点で本当に必要な情報かを確認します。

項目を残す理由	見直しの問い
連絡するため	希望する連絡手段に必要な情報か
対応できるか判断するため	最初の受付で判断が必要か
提案内容を決めるため	初回のやり取り後に聞けないか
社内の管理用	訪問者に入力してもらう必要があるか

入力を短くする案と、受付後の業務を進めやすくする案を、同じ表で検討すると判断しやすくなります。

EFOの成果指標を決める

フォーム到達と送信成功を分ける

最初に、フォームのどの段階を数えるか決めます。

ページを開いたこと、入力を始めたこと、送信を試したこと、正常に受け付けられたことは別です。

段階	計測する内容	間違えやすい点
到達	対象フォームが表示された	ページ表示だけではフォームが見えたとは限らない
開始	対象フォームへの入力や操作が始まった	再操作をどう数えるか決めておく
送信操作	送信処理を開始した	エラーや通信失敗を含む場合がある
送信成功	サイト側で正常に受け付けた	ボタンクリックだけで代用しない

GA4の拡張計測には、フォーム操作の form_start と form_submit があります。

前者はセッション内で初めてフォームを操作したとき、後者はフォームを送信したときのイベントです（Googleの拡張計測機能イベント）。

ただし、イベント名だけを見て、自社の受け付け成功と一致すると判断しないでください。

実際に送信し、受付側の結果とイベントを照合して、どの動作が記録されるかを確かめます。

フォームの完了率は、たとえば「入力を開始したセッションのうち、同じフォームの送信に成功したセッションの割合」と定義できます。

架空の例として、入力開始があった200セッションのうち、送信成功があったセッションが50なら、50 ÷ 200 × 100 = 25%です。

これは説明用の計算であり、目標値や他社の平均ではありません。

サイト全体のセッションを分母にした率とは別なので、表の名前にも分母を書いておきます。

指標の違いは、コンバージョン率の計算方法で具体例を整理しています。

問い合わせ品質も確認する

EFOの評価では、送信件数だけでなく、受け付けた後の結果も確認します。

件数が増えても、連絡先の不備や対象外の依頼が増えていれば、対応の負担が大きくなるためです。

はじめに、担当者と「有効な問い合わせ」の条件をそろえておきましょう。

確認する項目	記録方法の例
有効な問い合わせ	対応条件に合い、連絡できる依頼として区分
情報の不足	追加確認が必要になった内容を分類
対象外の依頼	対応地域やサービス条件との不一致を分類
受付後の進行	商談・予約・購入へ進んだかを確認

「有効」の判定を途中で変えると、改善前後の比較が難しくなります。

運用上の都合で変えた場合は、条件を変えた日も残します。

フォームの負担を減らした結果と、受付後に増えた作業を合わせて見ることが、EFOを継続する判断につながります。

入力項目と説明を見直す

必要な項目と任意項目を分ける

フォームの全項目を一覧にし、必須、任意、後から聞くものに分けます。

担当者の好みではなく、情報を使う場面から判断してください。

入力項目	使う場面	最初の受付で必要か	見直し案
返信先メール	受付後の連絡	メール返信なら必要	必須である理由が分かるラベルにする
電話番号	電話での確認	連絡方針による	電話が必要な場合だけ求める案を検討
詳細な住所	訪問・配送	サービスによる	地域だけで判断できないか確認
自由記述	要件の把握	内容による	何を書けばよいか短い例を置く

これは設計を検討するための例であり、すべてのフォームで同じ設定にするものではありません。

必須項目は、利用者が入力前に見分けられるようにします。

赤色だけに頼らず、ラベルに「必須」や「任意」の文字を付けると、意味を伝えやすくなります。

HTMLの required は必須入力を機械にも伝える方法ですが、画面上の説明も用意します（W3Cの必須入力と検証の解説）。

変更するときは、画面の必須表示、ブラウザ側の検証、サーバー側の受付条件が一致するかを確認します。

画面で「任意」と書いてあるのに、空欄で送るとエラーになる状態を残さないようにしましょう。

ラベルと入力例を整える

ラベルは、入力欄が何を求めているかを示す名前です。

入力欄の中に薄く表示するプレースホルダーだけでは、入力後に説明が消えてしまいます。

入力中も確認したい条件は、欄の近くに残してください（W3Cのフォーム説明の解説）。

状態	見直し案
「番号」とだけ書かれている	電話番号・注文番号など、目的が分かる名前にする
入力形式が送信後に分かる	入力する前に、受け付ける形式を示す
自由記述の内容を想像する必要がある	相談したいことの短い記入例を添える
エラーが「入力内容が不正です」だけ	どの項目をどう直せばよいか伝える

ラベルと入力欄は、見た目だけでなくHTML上でも関連付けます。

たとえば、label の for と入力欄の id を一致させると、対応関係をブラウザや支援技術に伝えられます（W3Cのラベル付けの解説）。

制作担当者へ渡すときは、「文言を変える」だけでなく、表示する位置と対象の入力欄も指定します。

エラー文は、入力を責める表現ではなく、次の操作が分かる内容にしてください。

たとえばメールアドレスの形式エラーなら、「メールアドレスを確認してください」と項目を示し、必要に応じて形式の例を添えます。

送信後にエラー一覧を出す場合も、該当する欄へ戻れるようにすると修正しやすくなります（W3Cのエラー通知の解説）。

スマホのフォームを点検する

キーボードと入力補助を確認する

スマートフォンでは、表示されるキーボードや自動入力の動作が、入力の手間に関わります。

PCで画面を細くするだけでなく、実際のスマートフォンでも入力して確認します。

入力欄の種類と目的に合わせて、HTMLの属性を制作担当者に確認してもらってください。

項目	実装で確認する例	操作で確かめること
メール	type="email"・autocomplete="email"	メール入力や補完が使えるか
電話番号	type="tel"・autocomplete="tel"	電話番号を入力しやすいか
郵便番号	autocomplete="postal-code"	保存した住所から適切に補完されるか
数字中心の項目	用途に合う inputmode	必要な文字を入力できるか

autocomplete は、項目の目的をブラウザに伝え、自動入力を助けるために使えます（W3Cのautocomplete解説）。

電話番号には type="tel"、数字中心の入力には用途に応じた inputmode を検討できます（web.devの入力フォーム設計）。

ただし、数字キーボードを出せば、その項目で必要な文字がすべて入力できるとは限りません。

国番号や区切り文字など、受け付ける形式も含めて試してください。

自動入力についても、候補を選ぶだけでなく、入力後に修正して送れるかまで確かめます。

画面の上下移動を確認する

入力中はキーボードが画面の一部を覆うため、普段のページ表示と使い勝手が変わります。

固定されたチャットボタンや下部の案内が、入力欄や送信ボタンに重ならないか点検してください。

次の順で試すと、入力の途中にある問題を見つけやすくなります。

1. 最初の欄から順番に入力し、次の項目へ移動する。
2. 必須項目をひとつ空欄にして送信を試す。
3. エラーの説明が見え、該当する欄に戻れるか確かめる。
4. 入力を修正したとき、ほかの値が消えていないか確認する。
5. 正常に送信し、受け付け成功の表示まで確認する。

テストには、社内で決めた架空の入力データや検証環境を使います。

エラーが出た後に何も反応がないように見えるなら、表示位置やフォーカスの移動が調査対象になります。

W3Cは、送信の成否を分かりやすく通知し、入力欄の近くにも具体的なフィードバックを示す方法を説明しています（W3Cの通知設計）。

見た目の配置に加え、キーボード操作や読み上げでも、その状態が伝わるかを確認します。

「エラーは表示されている」という実装側の認識だけで、点検を終わらせないようにしましょう。

EFO施策を比較する

一つの仮説から試す

変更前に、観察した事実と、改善の仮説を書き分けます。

たとえば、電話番号の欄でエラーが繰り返し出ているなら、受け付ける形式が分かりにくいという仮説を立てられます。

そこで入力例とエラー文を見直し、同じ項目でのエラーと送信成功を確認します。

このように、何を直し、何を見れば効果を判断できるかを対にしてください。

観察した事実の例	施策の候補	評価するもの
同じ欄で形式エラーが続く	入力例・受け付ける形式を見直す	エラーがあったセッション・完了率
任意の説明を必須と受け取られている	必須・任意の表示を整える	入力開始・完了・情報不足
スマホで送信ボタンが隠れる	固定要素や余白を調整する	操作の再現確認・送信成功
補完後に値を何度も直している	補完対象と形式を調整する	修正の様子・受付内容の不備

比較するときは、対象ページ、流入、端末、期間の条件を記録します。

同時に広告や料金も変わった場合、フォームの変更だけで結果が動いたとは断定できません。

A/Bテストを行う場合も、評価指標と判断の方法を先に決めておきます。

一度に複数の要素を変えるなら、個々の効果ではなく、その変更の組み合わせを比べていると説明してください。

再現できる不具合は、改善幅を測るために残すのではなく、修正して正常に動くかを確認します。

自動支援の副作用を確認する

住所補完や自動変換を入れたら、正常な入力ができなくなるケースがないか確認します。

補完した内容が正しくても、利用者が別の住所に直したいことはあります。

編集できることと、編集後の値が正しく送られることを、セットで試してください。

支援機能	点検すること
住所の自動補完	建物名の追記・手動修正・候補がない場合
文字の自動変換	名前や会社名など、変えてはいけない値への影響
リアルタイムのエラー表示	入力途中に警告が出続けないか
次の欄への自動移動	修正しようとした操作を妨げないか
送信中のボタン制御	通信失敗後にやり直せるか

ブラウザの自動入力も、項目に合った autocomplete の値が設定されているかで扱いが変わります（web.devの自動入力解説）。

新しいEFOツールを加えた場合は、既存フォームの検証や自動入力と重複して動いていないかも確認します。

また、画面側の入力チェックだけで受け付けを完結させず、サーバー側の検証も必要です（W3Cの入力検証の解説）。

公開前に、通常の入力、誤入力、修正、自動入力、通信失敗時の復帰をひと通り試してください。

EFOの効果を評価する

完了率と不備率を並べる

変更後は、送信成功が増えたかと、情報の不備が増えていないかを並べて確認します。

次の表は、EFOの施策と評価項目をつなぐための記録用ひな形です。

施策	主に見る指標	合わせて確認するもの
項目の削除・任意化	入力開始後の完了率	有効な依頼数・追加確認の件数
入力例の改善	形式エラーの発生状況	誤解したまま送られた内容
エラー表示の改善	エラー後に送信成功した割合	修正できずに終わった操作
スマホの配置改善	スマホの完了率	ボタンや欄の操作性
自動入力の改善	入力開始後の完了率	補完値の誤り・修正の負担

「エラー率」などの名前を使う場合も、イベント件数なのか、エラーがあったセッションの割合なのかを明記します。

SiTestのフォームレポートでも、入力開始、入力完了、入力中断にはそれぞれ定義があります。

たとえば同社の項目別「入力完了数」は、入力状態の項目からフォーカスを外した数であり、フォーム全体の送信成功数とは別です（SiTestのフォーム統計）。

同じ「完了」という言葉でも、ツールと指標によって意味が違います。

画面に出ている数値を、そのまま問い合わせ成功の件数に読み替えないようにしましょう。

録画の詳しい調査へつなぐ

集計で問題のある段階が分かったら、該当する条件の録画で動作を確かめます。

たとえば、スマホのエラー後の完了率に課題があるなら、その端末とフォームに対象を絞って見ます。

一件だけの動きを全員の行動と考えず、似た動きが複数あるか、実機でも再現するかを確認してください。

記録するのは、入力し直した箇所、エラーの見え方、操作後の反応など、改善に必要な事実です。

入力内容そのものを広く収集するのではなく、録画のマスキングや対象範囲を確認して調査します。

フォームの表示と受付結果を照合する具体的な点検手順は、「送信したつもり」を減らす問い合わせフォームの直し方に分けて紹介しています。

EFOを始めるなら、まずひとつのフォームで、到達・開始・送信成功の定義をそろえてください。

次に、必要な入力項目を棚卸しし、スマホで送信完了まで操作します。

その結果から、直す箇所と評価する指標を一組選ぶと、変更後の判断まで進めやすくなります。