結論
EFO（入力フォーム最適化）は、フォームに入力し始めた人が送信を終えられるよう、項目の数、入力欄の作り、誤りの示し方、送信ボタンのまわりを整える改善です。まずGA4のフォームのイベントで入力開始と送信の差をつかみ、項目は最初の返信に必要なものに絞り、誤りは欄の隣に直し方を文字で示します。効果は送信数だけでなく商談数でも比べます。
この記事でわかること
EFOで直す範囲と、GA4の拡張計測機能で入力開始と送信の差を測る方法 項目ごとに「必須で残す」「選択式で残す」「外す」を決める判断と点検表 スマホで入力しやすくするラベル・type・autocompleteの指定とボタンの大きさ エラー表示の時点と場所、送信ボタンの前に個人情報の利用目的を置く理由 業態別に残す項目の例と、直した後に送信数と商談数で比べる方法 EFO（Entry Form Optimization。エントリーフォーム最適化、入力フォーム最適化とも呼ばれます）とは、問い合わせ・資料請求・予約などのフォームで、入力を始めた人が送信まで進めるように、項目・入力欄・エラー表示・送信ボタンを直すことです。
問い合わせフォームの改善は、GA4（Google アナリティクス 4）で入力を始めた人数と送信した人数の差を確かめたうえで、①項目を「最初の返信に必要か」で絞る、②入力欄にラベルと内容に合った種類を付ける、③誤りを欄の隣で直し方とともに示す、④送信ボタンの前に個人情報の利用目的を示す、の順で進めます。
web.dev（Googleが運営するウェブ制作者向けのサイト）は、求めるデータはできるだけ少なくし、フォームの項目を減らすとフォームが複雑でなくなって入力しやすくなり、離脱率を下げられる可能性があるとしています（web.dev：Learn Forms「セキュリティとプライバシー」 ）。入力欄のラベルやエラーの示し方には、W3C（ウェブの標準を定める団体）のウェブアクセシビリティの指針 WCAG 2.2 にも基準があります（W3C：WCAG 2.2 ）。
「項目を1つ減らすと完了率が◯%上がる」「フォームの離脱率の平均は◯%」のような数値は、公的な統計で確認できなかったため使わず、自社のフォームの変更前後の数字で比べます。2026年10月19日時点の公式情報に基づきます（web.dev、アナリティクス ヘルプ、個人情報保護委員会、W3C）。
EFOは、入力を始めた人が送信まで進む割合を上げる改善 EFO（入力フォーム最適化）は、フォームを開いて入力を始めた人のうち、送信まで進む人の割合を上げる改善で、フォームまで来る人を増やす導線やページの改善とは直す場所が違います。web.dev は、フォームを適切に設計すると離脱率を大幅に減らせることがあるとしています（web.dev：Learn Forms「デザインの基本」 ）。
この記事では、フォーム完了率を「送信した人数÷入力を始めた人数」と定義します（公式の用語ではありません）。LPO（ランディングページ最適化）やCVR改善（CVR：訪問のうち問い合わせなどの成果に至った割合）がページ全体を扱うのに対し、EFOはフォームの中だけを扱います。
フォームまでの導線や信頼の材料を含めた全体の点検は、ホームページの問い合わせを増やす方法（導線とフォームの改善手順） の手順に沿って進め、この記事はその中のフォームの点検を項目ごとに掘り下げます。EFOで直すのは入力を始めてから送信するまでの間で、その手前は導線とページ、その後は計測と受信の問題です。
図1 EFOで直す範囲と、この記事でのフォーム完了率の定義。アナリティクス ヘルプ「拡張計測機能イベント」のform_start・form_submitをもとに作成（Framework作成） フォームの改善は、GA4で入力開始と送信の差を測ってから始める 問い合わせフォームの改善は、GA4の拡張計測機能で、入力を始めた人数（form_start）と送信した人数（form_submit）を測り、どこで減っているかを確かめてから始めます。
拡張計測機能の「フォームの操作」を有効にすると、form_start はユーザーがセッションで初めてフォームを操作したとき、form_submit はフォームを送信したときに記録され、サイトのコードを変える必要はありません。
設定は、［管理］の［データの収集と修正］にある［データ ストリーム］で対象のストリームを開き、［拡張計測機能］で確かめます（編集者以上の権限が必要。アナリティクス ヘルプ：拡張計測機能イベント ）。
form_submit の件数は、実際に届いた問い合わせの件数と同じ期間で突き合わせ、合わなければフォームより先に計測と受信の設定を直します。どの行動をキーイベント（成果）として数え、商談・成約をどこで記録するかはコンバージョン計測の設計 で整理しています。
どの項目で止まっているかまでは、form_start と form_submit だけでは分かりません。web.dev は、特定の入力欄に入力されたときに記録するカスタムイベントを作れるとしつつ、カスタムイベントは少ない数から始め、フォームの問題を見つけるのに詳しい情報が必要になったときだけ増やすほうがよいとしています（web.dev：Learn Forms「データを集めています」 ）。
入力開始と送信の数字の組み合わせで先に直す場所が決まり、入力を始めた人の送信が少ないときがEFOで直す場面です。
図2 入力開始・送信・届いた件数・商談の組み合わせで、先に直す場所を決める。アナリティクス ヘルプ「拡張計測機能イベント」、web.dev「データを集めています」をもとに、確かめる順に並べたもの（Framework作成） 送信は多いのに商談にならない場合は、担当の振り分けや優先度の判断に使う情報が足りていない可能性があるため、次の節の点検表で「選択式で残す」項目を見直します。
項目は「最初の返信に必要か」で残すかを決める 問い合わせフォームの項目は、1つずつ「これがないと最初の返信ができないか」で判定し、返信に要らない項目は外すか任意にします。
web.dev は、必要のないデータを求めず、求めるデータがすべて必要かを常に問い直すことを勧め、データが少ないほどリスク・費用・責任も小さくなるとしています（web.dev：セキュリティとプライバシー ）。住所・支払いフォームの資料でも、フォームを簡単にする最も簡単な方法は不要な項目を削ることだとしています（web.dev：お支払いフォームと住所フォームのベスト プラクティス ）。
Metaはインスタントフォーム（Facebook・Instagramの中で入力するフォーム）について、多肢選択式の質問を少なくすると送信数が多くなり、多くすると通常は質の高いリードをより多く獲得できると説明しています（Meta：リード獲得広告作成のベストプラクティス ）。
自社サイトのフォームについての説明ではありませんが、項目を減らすと件数が、選択式の質問を足すと振り分けの情報が増えるという関係は、問い合わせフォームの項目を選ぶときにも当てはめて考えられます。インスタントフォームとLPのどちらで受けるかはMeta広告のリード獲得広告の記事 で比べています。
項目ごとの判定は、2つの問いで「必須で残す」「選択式で残す」「外す」の3つに分かれます。
図3 項目を残すかどうかの2つの問い。web.dev「セキュリティとプライバシー」「お支払いフォームと住所フォームのベスト プラクティス」の「必要なデータだけを求める」をもとに、判定の順に並べたもの（Framework作成） 問い合わせフォームによく置かれる項目に当てはめると、メールアドレスの確認用の再入力欄は外し、氏名は1つの欄にまとめ、住所は訪問・郵送・見積もりに使う場合だけ残せます。
項目 残す条件 外す・変える判断 氏名 返信の宛名に使うので残す 姓と名を分けて保存する理由がなければ1つの欄にする ふりがな 電話で名前を呼ぶ場合 メールだけで返信するなら任意にする 会社名 法人向けで、見積もりや返信先に使う場合 個人のお客様が中心なら外すか任意にする メールアドレス メールで返信する場合は必須 確認用にもう一度入力させる欄は置かない 電話番号 電話で返信する場合は必須 メールで返信するなら任意にする 住所 訪問・郵送・見積もりに使う場合 最初の返信には市区町村までで足りるかを確かめる 問い合わせの種類 担当の振り分けに使う場合（選択式） 選択肢が1つしかないなら外す 予算・希望時期 優先度の判断に使う場合（選択式） 使わないなら外し、返信で聞く 問い合わせ内容 自由に書ける欄として残す 種類の選択で足りるなら任意にする 知ったきっかけ 電話・紹介など計測できない経路を知りたい場合（任意） GA4で流入元が分かる範囲なら外す
表のうち氏名・ふりがな・メールアドレスの行はweb.devの資料、それ以外の行は「最初の返信に必要か」から整理した、この記事の判断基準です。
web.dev は、姓・名・敬称などを分けて保存する十分な理由がない限り氏名は1つの欄で入力できるようにし、日本の名前については電話で名前を伝えるために読みの欄を設けることを検討するよう書いています（web.dev：お支払いフォームと住所フォームのベスト プラクティス ）。連絡先を確かめるために入力欄を二重にしないこと、二重にすると入力が遅くなり自動入力した場合には意味がないことも挙げています（web.dev：登録フォームのベスト プラクティス ）。
入力欄は、ラベルを上に置き、内容に合った種類を指定する 入力欄は、すべてにラベル（項目名）を付けて入力欄の上に置いて1列で並べ、メールアドレスなら type="email"、電話番号なら type="tel" のように内容に合った種類（HTMLのtype属性）と、自動入力のための autocomplete 属性の値を指定します。
web.dev は、調査ではラベルを入力欄の上に置くのが最もよく、1列だけで並べるのが最適だとしています。入力欄の中の薄い文字（プレースホルダ）は入力するデータのヒントを示すもので、ラベルとして使わないよう注意しています（web.dev：デザインの基本 ）。プレースホルダは入力を始めると消えるため、何の欄かを忘れやすく、日付などの形式をプレースホルダで示した場合も同じだとしています（web.dev：お支払いフォームと住所フォームのベスト プラクティス ）。
検索上位の記事の中には、プレースホルダに入力例を書くことを勧めるものもあります。入力例を書く場合も、ラベルは別に残し、「半角数字で入力」のような形式の説明は欄の近くに常に見える文字で置きます。
内容に合った type と autocomplete を指定すると、スマホのキーボードと自動入力の候補がその項目に合ったものになります。
項目 要素・type autocomplete スマホで起きること 氏名 input（type は既定のtext） name 保存済みの名前を自動入力できる メールアドレス type="email" email メール入力向けのキーボード。形式もブラウザが確かめる 電話番号 type="tel" tel 電話番号に必要な文字だけのキーボード 問い合わせ内容 textarea — 複数行を入力できる
根拠：デザインの基本 （type と画面のキーボード、複数行は textarea）、web.dev：Learn Forms「自動入力」 （autocomplete の働き）、登録フォームのベスト プラクティス （autocomplete="email"・"tel"）、お支払いフォームと住所フォームのベスト プラクティス （autocomplete="name"、type="email" の形式チェック）。
お支払いフォームと住所フォームのベスト プラクティスは、電話番号に type="number" を使うと数を増減する矢印が付いて意味をなさないため、type="tel" を使うよう書いています。
押しやすさについて、web.dev はボタンのタップ領域を48ピクセル以上にし、入力欄どうしの間隔を十分にとることを勧め、入力欄の文字の大きさを1rem（多くのブラウザで16ピクセル）以上にすると iOS の Safari で入力欄を選んだときにページが拡大されないとしています（デザインの基本 ）。
WCAG 2.2 の達成基準2.5.8（レベルAA）は、押す対象の大きさを最低24×24 CSSピクセルとしています（例外あり。W3C：WCAG 2.2 ）。
キーボードだけでもフォームを操作できるか、Tabキーで移る順番が見た目の順番と同じかも確かめます（デザインの基本 ）。誰でも使えるフォームにする観点（ウェブアクセシビリティ）は、日本では JIS X 8341-3:2016 が規格として参照されることが多く、デジタル庁が事業者向けの入門資料を公開しています（デジタル庁：ウェブアクセシビリティ導入ガイドブック ）。
エラーは入力欄の隣に、直し方を文字で示す 入力の誤りは、送信ボタンを押した後にまとめて示すのではなく、値を入力した直後にその欄の隣で、何が誤りでどう直せばよいかを文字で示します。
web.dev は、送信ボタンを押したときに誤りの一覧を出すのではなく、入力している間にその場で検証して知らせることを勧めています。
送信後にサーバーで検証する場合は、見つかった問題をすべて示し、誤りのある欄をすべて目立たせたうえで、それぞれの欄の隣に何を直すかを書くとしています（お支払いフォームと住所フォームのベスト プラクティス ）。送信時に誤りを示すときは、最初の誤りの欄に移動させること（デザインの基本 ）、欄を離れたときに検証する方法（web.dev：Learn Forms「ユーザーがフォームに適切なデータを入力できるようにする」 ）も示しています。
WCAG 2.2 では、誤りのある箇所を特定して誤りを文字で説明すること（達成基準3.3.1、レベルA）、直し方が分かっている場合はそれを示すこと（達成基準3.3.3、レベルAA）、色だけで情報を伝えないこと（達成基準1.4.1、レベルA）が基準になっています（W3C：WCAG 2.2 ）。web.dev も、赤と緑の枠線の違いを見分けにくい人がいるため、誤りや成功を伝えるときに色だけに頼らず文字やアイコンを足すよう書いています（ユーザーがフォームに適切なデータを入力できるようにする ）。
誤りを知らせる時点と場所は、欄を離れた直後、その欄の隣、送信したときは最初の誤りの欄、の3つです。
図4 誤りを知らせる時点と場所。web.dev「デザインの基本」「お支払いフォームと住所フォームのベスト プラクティス」、W3C「WCAG 2.2」の達成基準3.3.1・3.3.3・1.4.1をもとに、入力の流れに並べたもの（Framework作成） web.dev は、利用者が「間違えた」と叱るのではなく、問題をその場で直せるよう手助けすることを勧め、名前の検証でラテン文字だけを受け付けるような制限をしないよう注意しています（お支払いフォームと住所フォームのベスト プラクティス ）。日本のフォームに当てはめると、全角と半角の違いや電話番号のハイフンの有無を受け取る側で整えられるなら、その違いはエラーにしない、というのがこの記事の判断基準です。
すべて正しく入力されるまで送信ボタンを押せない状態にしておくことも、web.dev は勧めていません。押せないボタンは壊れていると受け取られることがあるため、押されたら何が誤りでどう直すかを示します（お支払いフォームと住所フォームのベスト プラクティス ）。
送信ボタンの前に、個人情報の利用目的と押した後の結果を示す 送信ボタンは押した後に起きることが分かる文言にし、その手前に個人情報の利用目的（またはそれを示したページへのリンク）を、押す前に目に入る位置に置きます。
個人情報保護委員会のガイドラインは、ユーザー入力画面への打ち込みなどで本人から直接個人情報を取得する場合、あらかじめ本人に利用目的を明示しなければならないとし（法第21条第2項）、自社のホームページの入力画面での申込みを例に挙げています。
ネットワーク上で取得する場合は、送信ボタンなどをクリックする前に、利用目的（1回程度の操作で利用目的のページに移るリンクやボタンを含む）が本人の目に留まるよう配置に留意することが望ましいとしています（個人情報保護委員会：個人情報の保護に関する法律についてのガイドライン（通則編） ）。何を利用目的として書くかは自社の個人情報の扱いによるため、この記事では扱いません。
web.dev も、個人データを扱うフォームのあるページにはプライバシーポリシーへのリンクを置くこと、フォームのあるページでは必ずHTTPS（通信を暗号化する仕組み）を使うことを勧めています（セキュリティとプライバシー ）。
ボタンの文言について web.dev は、送信ボタンには押すと何が起きるかを表す文言を付けるよう勧め、押された後はボタンを無効にして二重の送信を防ぐことを検討するよう書いています（お支払いフォームと住所フォームのベスト プラクティス ）。問い合わせフォームに当てはめると、「送信」より「無料で見積もりを依頼する」「資料を請求する」のように、押した後に起きることが分かる文言になります。
送信ボタンのまわりには、手前に利用目的、ボタンに押した後の結果、押した後に二重送信の防止、の3つを置きます。
図5 送信ボタンのまわりの配置。個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」3-3-4、web.dev「お支払いフォームと住所フォームのベスト プラクティス」をもとに作成。利用目的の文面は例（Framework作成） 確認画面を置くかどうかは、送信の取り消しが利かない手続きかで決められます。WCAG 2.2 の達成基準3.3.4（レベルAA）は、利用者に法的な約束や金銭の取引が生じるページなどについて、送信を取り消せる、入力の誤りを確かめて直す機会がある、確定前に見直して直せる仕組みがある、のどれかを求めています（W3C：Understanding SC 3.3.4 ）。
相談や見積もりの依頼のように契約や支払いが生じない問い合わせは、この基準が挙げる対象に当たらないため、確認画面を置かず入力中のその場の検証で誤りを防ぐ形も選べる、というのがこの記事の判断基準です。
確認画面を残す場合は、入力画面に戻ったときに内容が消えないかを確かめます。WCAG 2.2 の達成基準3.3.7（冗長な入力、レベルA）は、同じ手続きの中で前に入力した情報を再び求める場合、自動で入れておくか利用者が選べるようにすることを求めています（例外あり。W3C：Understanding SC 3.3.7 Redundant Entry ）。確認画面から戻ると入力が消えるフォームは、この基準に当てはめると同じ情報をもう一度入力させる状態です。
ネットショップの購入手続きの画面には特定商取引法第12条の6（特定申込みを受ける際の表示）の定めがあり（e-Gov法令検索：特定商取引に関する法律 ）、この記事の対象外です。
業態で変わるのは、残す項目と必須にする項目 問い合わせ型は見積もり・相談に必要な情報、予約・来店型は希望日時と連絡先、EC型は注文に関する問い合わせの情報というように、業態によって最初の返信に必要な項目が変わるので、必須にする項目も変わります。
業態 最初の返信に使う項目の例 外す・任意にできる候補 確かめること 問い合わせ型（工務店・リフォーム） 氏名、連絡先、工事の種類、所在地（市区町村） 番地までの住所、予算 対応エリアの外かを最初に判断できるか 問い合わせ型（士業） 氏名、連絡先、相談の分野（選択式） 相談内容の詳細（返信で聞く） 相談の分野で担当を振り分けられるか 問い合わせ型（BtoBサービス） 会社名、氏名、メールアドレス、相談の種類 部署・役職、従業員数 資料請求と相談で項目を分けるか 予約・来店型（店舗・クリニック） 氏名、連絡先、希望日時 来店のきっかけ 症状など病歴に当たる情報を聞くか EC型（ネットショップ） 注文番号、メールアドレス 住所・電話番号（注文の情報で分かる場合） 購入手続きのフォームと分けて考える
表は、各業態で最初の返信に何を使うかから整理した例で、この記事の判断基準です。業態ごとのフォーム完了率の目安は一次資料で確認できないため入れていません。
クリニックなどで症状を書いてもらう欄を置く場合は、病歴が要配慮個人情報に当たることを確かめます。個人情報保護委員会のガイドラインは、要配慮個人情報を取得する場合はあらかじめ本人の同意を得なければならないとしています（個人情報保護委員会：ガイドライン（通則編） ）。予約の段階で症状の詳細まで必要かどうかと同意の取り方は、自院の個人情報の扱いの担当者や専門家に確認してください。
予約システムやフォームの作成サービスを使っている場合は、項目の追加・削除、必須・任意の切り替え、type や autocomplete の指定を、そのサービスの管理画面でどこまで変えられるかを先に確かめます。
直したら、同じ日数の前後でフォーム完了率と商談数を比べる フォームを直した効果は、変更前と同じ日数の期間で、フォーム完了率（送信÷入力開始）と、届いた件数・商談数を並べて比べます。web.dev は、フォームの問題を直して新しい版を公開したら、数日後に変更の効果を測り、必要に応じて段階を見直してまた分析することを勧めています（データを集めています ）。
変更前の数字を残す ：変更前の一定期間（例：直近4週間）の form_start・form_submit・実際に届いた件数・商談数を記録します。1回に変える場所を絞る ：複数の場所を同時に変えると、どの変更で数字が動いたかを分けられません。Metaもインスタントフォームについて、質問の数を変えて完了率や単価を比べるA/Bテストを勧めています（Meta：リード獲得広告作成のベストプラクティス ）。スマホとパソコンで実際に送信する ：web.dev は、利用者が多い環境で、さまざまなブラウザ・端末でフォームを試すよう勧めています（登録フォームのベスト プラクティス ）。届いた内容と、GA4に記録されたかも確かめます。同じ日数で比べる ：変更後も変更前と同じ日数がたってから、4つの数字を並べます。項目を減らして送信が増えても、商談化率（送信された問い合わせのうち商談になった割合）が下がれば、商談数は減ることがあります。
図6 送信数と商談数の試算。商談数＝入力開始×フォーム完了率×商談化率の計算で、数値はすべて説明のための仮定（Framework作成） 図の数値はすべて仮定で、入力開始200人のまま、フォーム完了率が30%から40%に上がると送信は60件から80件に増えますが、商談化率が50%から35%に下がると商談は30件から28件に減ります（200×30%×50%＝30、200×40%×35%＝28）。逆に、選択式の項目を1つ足して送信が少し減っても、商談化率が上がって商談数が増えることもあるため、判断は商談数で行います。
Frameworkでは、効果検証で見つかった課題を改善の仮説と検証計画にまとめる改善提案 で、広告・LP・フォーム・問い合わせ後の対応から変更の候補を整理しています。フォームを含むLPの制作はLP制作 の支援内容にまとめています。
まとめ まず GA4 の［管理］から［データ ストリーム］を開き、［拡張計測機能］の「フォームの操作」が有効かを確かめ、直近4週間の form_start と form_submit、実際に届いた件数を並べてください。入力を始めた人の送信が少なければ、項目の点検表で各項目を「必須で残す」「選択式で残す」「外す」に分け、スマホで実際に1回入力して、誤りの示され方と、送信ボタンの手前の利用目的の表示を確かめます。直した後は同じ日数で、送信数と商談数の両方を比べます。
よくある質問
問い合わせフォームの確認画面は、なくしたほうがよいですか？ 問い合わせフォームの確認画面を置くかどうかは、送信が取り消せない手続きかどうかで決められます。W3CのWCAG 2.2の達成基準3.3.4は、法的な約束や金銭の取引が生じるページなどに、取り消し・入力の確認・確定前の見直しのどれかを求めています。相談や見積もりの依頼はこの対象に挙がっていないので、入力中のその場の検証で誤りを防げるなら確認画面を省く形も選べます。確認画面を残す場合は、戻ったときに入力が消えないようにします。
メールアドレスを2回入力させる確認用の欄は必要ですか？ メールアドレスの確認用の再入力欄は、web.devの「登録フォームのベスト プラクティス」では勧められていません。同じ資料は、連絡先を確かめるために入力欄を二重にすると入力が遅くなり、自動入力で入れた場合には意味がないとし、代わりに入力されたあてに確認のコードを送る方法を挙げています。問い合わせフォームでは、type="email"でブラウザに形式を確かめさせ、自動返信メールで受け付けを知らせる形にできます。
プレースホルダに入力例を書けば、ラベルは省いてもよいですか？ プレースホルダ（入力欄の中の薄い文字）は、ラベルの代わりに使わないようweb.devの「Learn Forms：デザインの基本」で注意されています。プレースホルダは入力を始めると消えるため、何の欄かや入力の形式を忘れやすくなると、web.devの「お支払いフォームと住所フォームのベスト プラクティス」は説明しています。入力例を書く場合も、項目名のラベルは入力欄の上に残し、形式の説明は欄の近くに常に見える文字で置きます。
EFOツールを入れないと、どの項目で離脱しているか分かりませんか？ GA4の拡張計測機能で分かるのは、フォームの入力を始めた人数（form_start）と送信した人数（form_submit）までで、どの項目で止まったかは分かりません。web.devの「Learn Forms：データを集めています」は、特定の入力欄に入力されたときに記録するカスタムイベントを作れるとし、カスタムイベントは少ない数から始めて、問題を見つけるのに必要になったときだけ増やすほうがよいとしています。項目ごとの数字が必要になった段階で、カスタムイベントか専用のツールを検討します。 
