入力フォームの改善｜どこで止まっているかを切り分けてから直す

問い合わせフォームを直してほしいと頼まれたとき、最初に出てくる案はたいてい「入力項目を減らす」です。ただ、項目の数に手を付ける前に、確かめておくことがあります。フォームにたどり着いたが入力を始めなかった人と、入力を始めたが送信までいかなかった人は、どちらも「送信が少ない」として同じ数字に溶けますが、直す場所はまったく別です。前者で入力欄を削っても、数はほとんど動きません。この記事では、入力フォームの改善を、止まっている箇所の切り分け、ブラウザの自動入力に乗せる書き方、ラベルとエラーの要件、直した結果の数え方という順で整理します。

扱うのは、公式ドキュメントと仕様で裏の取れる範囲だけです。項目をいくつにすれば送信がどれだけ増えるかという数値は、集客の経路、扱っている商材、相手が法人か個人かで変わるため、ここでは出しません。出せるのは、ブラウザと支援技術がその入力欄の意味を読み取れる形になっているかという判定基準と、自分のサイトのデータでどこが詰まっているかを見る手順です。

項目を減らす案から始めると、何が効いたのか残らない

入力欄を削る改修は、たいてい他の変更と同時に行われます。欄を減らし、見出しの文言を変え、ボタンの色を変え、ついでにスマートフォンでの表示も直す。これをまとめて出すと、送信数が動いたときに理由が特定できません。次に別のフォームを作るときも、何を再現すればよいのか分からないままになります。

もうひとつの落とし穴は、削った項目が営業側で必要だった場合です。社名や予算の欄を外すと送信は増えますが、そのあとの確認の往復が増え、商談にならない問い合わせも混じります。フォームの改善は、送信数を増やす作業ではなく、送信された内容で次の仕事が進む状態を保ちながら、途中で止まる原因を取り除く作業です。コンバージョンを何として定義するかの整理は、CROの考え方をまとめた記事の側で扱っています。

そこで手順を逆にします。先にどこで止まっているかを測り、止まっている箇所に対応する直し方だけを当てる。入力欄の数は、入力の最中で止まっていると分かったときに、他の原因と並べて検討する候補のひとつに下がります。

止まっている箇所は、2つのイベントで切り分ける

Google アナリティクス ヘルプは、拡張計測機能で収集されるイベントとしてフォームの操作を挙げ、2つのイベント名と発生の条件を示しています。form_start は、ユーザーがセッションで初めてフォームを操作したときに発生します。form_submit は、ユーザーがフォームを送信したときに発生します。

この2つがあると、ページの表示数との組み合わせで状態が3通りに分かれます。表示そのものが少ないなら、フォームへ送り込む前の問題です。表示はあるのに form_start が増えないなら、フォームの前で判断が止まっています。form_start は出ているのに form_submit が少ないなら、入力の最中で止まっています。

フォームの前で止まっている場合に直すのは、入口の位置、そこで何が始まるのかの説明、料金や対応範囲の提示です。入力欄の仕様をいくら整えても、ここでは効きません。この側の手当ては、CTAの作り方と改善の手順と、サイト全体のCVRを段階ごとに見る記事に分けて書いています。以降の節は、入力の最中で止まっているほうを扱います。

計測の前提として、拡張計測機能と制約を確認する

form_start と form_submit は、拡張計測機能が有効になっていて初めて集まります。ヘルプの手順では、管理のデータ ストリームでデータストリーム名を選び、拡張計測機能のスイッチをオンにします。設定アイコンから個々のオプションを編集できるとも記載されているため、スイッチがオンでも、フォームの操作だけが外れている状態はあり得ます。計測されている前提で話を進める前に、画面を開いて確かめてください。

制約も先に押さえておきます。form_start では form_id、form_name、form_destination が、form_submit ではこれに form_submit_text を加えたパラメータが収集されます。ただしヘルプは、これらのパラメータをレポートで使用できるのは、レポート用のカスタム ディメンションを作成する場合のみだと記載しています。フォームが1ページに複数ある場合、どのフォームの数字なのかを分けて見るには、この設定が前提になります。1つしかないなら、イベントの数だけで足ります。

手で入力させない形にする

入力の最中で止まっているとき、最初に見るのは項目の数ではなく、ブラウザが代わりに埋められる状態になっているかどうかです。MDN Web Docs は autocomplete 属性について、ウェブ開発者は入力欄にどの種類の情報が期待されているかをブラウザーに示唆することができるのに加え、ユーザーエージェントがフォーム入力欄の値を埋めるための自動支援を提供する必要があることを指定することができると説明しています。提案値の元になる情報は通常はブラウザーに委ねられ、ブラウザーはユーザーの名前、住所、電話番号、メールアドレスを自動入力用に保存することがあるとも書かれています。

つまり、同じ10項目でも、ブラウザが9項目を埋められる形と、全部を手で打たせる形があります。MDN は、適切な autocomplete 値を使用することで、認知障碍や運動機能障害、その他の状態にあるユーザーが、情報を入力したり記憶したりする手間を減らし、フォームをより迅速かつ正確に記入できるようになると記載しています。手が震える環境、片手でスマートフォンを持っている状況、画面の文字を拡大している状況は、どれも特別な例ではありません。

web.dev の自動入力の解説は、ブラウザは値を name 属性の値とともに保存し、一部のブラウザではデータの保存と入力の際に id 属性も確認すると説明しています。autocomplete=“off” については、自動入力を防ぐことができるとしたうえで、ワンタイムコードやハニーポットフィールドなど、一回限りの値が必要な場合に限定すべきだと述べています。過去に慣例で付けた off が残っていないかは、既存フォームで必ず確認する箇所です。

入力欄	autocomplete の値	MDN の説明
氏名を1欄で受ける	name	人の氏名
姓	family-name	苗字（ファミリーネーム）
名	given-name	名（ファーストネーム）
メールアドレス	email	メールアドレス
電話番号	tel	国番号を含む、完全な電話番号
郵便番号	postal-code	郵便番号
都道府県	address-level1	都道府県など最上位の行政レベル
市区町村	address-level2	市区町村など第2の行政レベル
番地・建物名	street-address	住所
会社名	organization	企業または団体の名前
部署・役職	organization-title	職名や肩書

法人向けのフォームでよく使う欄は、この表の範囲でほぼ指定できます。web.dev は、input、select、textarea に適切なオートコンプリート値がある場合は、それを使用する必要があると明記しています。複数の値を並べる書き方もでき、autocomplete=“billing postal-code” のような例が示されています。

キーボードと入力の種類を合わせる

autocomplete が効かない場面でも、打ちやすさは属性で変わります。web.dev は、メールアドレスには type=“email”、電話番号には type=“tel” を使用し、支払いカード番号など、インクリメントを意図していない数値には type=“number” を使用しないよう求めています。代わりに type=“text” と inputmode=“numeric” を使う形が示されています。数値を増減させるための欄ではないものに type=“number” を当てると、矢印や丸めの挙動が邪魔になります。

入力する内容	指定	web.dev の記載
メールアドレス	type="email"	メールアドレスには type=“email” を使用する
電話番号	type="tel"	電話番号には type=“tel” を使用する
カード番号など増減を意図しない数値	type="text" と inputmode="numeric"	支払いカード番号など、インクリメントを意図していない数値には type=“number” を使用しない
複数ページのフォームの途中の欄	enterkeyhint="next"	モバイル キーボードの Enter キーのラベルを設定する
最後の入力欄	enterkeyhint="done"	同じ属性で、最終入力では done を指定する

住所の分割についても、web.dev は単一の textarea を使用することを検討してくださいという案を示しています。国や地域によって住所の構造が違うため、欄を細かく割るほど合わない人が出ます。あわせて、名前が「無効」と言われるのは失礼だとして、ラテン文字のみに一致する正規表現の使用は避けるよう書かれています。姓名の欄に半角英字しか通らない検証が残っているフォームは、この指摘がそのまま当てはまります。

ラベルはプレースホルダで代用しない

欄の中に薄い文字で項目名を出す形は、画面上はすっきり見えます。しかし web.dev は、ラベルの代わりにプレースホルダを単独で使用しないよう求めています。理由も示されていて、入力欄にテキストを入力し始めると、プレースホルダが非表示になるためです。入力の途中で何の欄だったか分からなくなり、見直しのときにも確認できません。

ラベルの付け方は、label 要素を使い、for 属性に、入力の id と同じ値を指定して、ラベルを入力に関連付けると説明されています。1つのラベルで複数の入力にラベルを付けようとせず、1つの入力に1つのラベルを使うことも示されています。関連付けができていると、ラベルをタップまたはクリックしたときに対応する入力へフォーカスが移り、スクリーンリーダーはラベルまたはラベルの入力がフォーカスを得たときにラベルのテキストを読み上げます。

必須の示し方については、必須フィールドのラベルにアスタリスクを追加し、フォームの先頭にアスタリスクの意味を説明するメモを追加する形が示されています。色だけで必須を区別すると、色の違いが分からない環境では伝わりません。

送信ボタンについては、ユーザーが送信ボタンをタップまたはクリックしたら、そのボタンを無効にすることを検討してくださいと書かれています。二重送信は、読者にとっては「反応がないのでもう一度押した」という体験であり、こちら側では同じ問い合わせが2件届く形で現れます。

エラーと再入力は、達成基準に合わせて直す

ここまでの指定は、アクセシビリティの達成基準とも重なります。W3C の WCAG 2.2 は2024年12月に勧告となった版で、日本語訳はウェブアクセシビリティ基盤委員会が公開しています。フォームに直接関わる基準は次の5つです。

達成基準 3.3.2 ラベル又は指示（レベル A）は、コンテンツが利用者の入力を要求する場合、ラベル又は指示が提供されていることを求めます。達成基準 1.3.5 入力目的の特定（レベル AA）は、利用者の情報を集めるそれぞれの入力フィールドの目的が、プログラムによる解釈が可能であることを求めます。MDN も、有効な自動補完トークンを提供することは、この達成基準の要件と同時に満たせると書いています。autocomplete の指定は、入力の手間を減らす施策と、達成基準への対応が同じ作業になる数少ない箇所です。

エラーの側は2つに分かれます。達成基準 3.3.1 エラーの特定（レベル A）は、入力エラーが自動的に検出された場合に、エラーのある項目が特定され、そのエラーがテキストで利用者に説明されることを求めます。達成基準 3.3.3 エラーの修正提案（レベル AA）は、修正の提案が分かっている場合に、その提案が利用者に提供されることを求めます。枠が赤くなるだけの表示は前者を満たしません。何の欄が、なぜ通らなかったのかを文字で出し、分かるなら直し方まで出します。

残る1つが、確認用のメールアドレス欄のような重複入力に関わるものです。達成基準 3.3.7 冗長な入力項目（レベル A）は、以前入力された情報の再入力が必要な場合は自動入力されるか、利用者が選択可能であることを求めます。同じ情報を2回打たせる設計を見直す根拠は、ここにあります。

達成基準は、読みやすさや使いやすさの判定を、担当者の感覚から外に出せる道具です。社内で意見が割れたときに、どちらが好みかではなく、どちらが基準を満たすかで決められます。入力以外の使いやすさの論点は、サイトの使いやすさを改善する手順の側にまとめています。

直した結果を、成果として数えられる状態にする

直したあとに効果を見るには、送信が成果として数えられている必要があります。GA4では、集まっているイベントに印を付けて初めて成果の列に入ります。ヘルプは、既存のイベントにキーイベントとしてマークを付ける手順を、管理のデータの表示でイベントをクリックし、イベント名の横にあるスターアイコンをクリックする、と示しています。この操作にはマーケティング担当者以上の権限が必要です。

反映の仕方には注意点があります。ヘルプは、イベントにキーイベントとしてマークを付けると、作成時点以降のレポートに反映されますが、過去のデータは変更されませんと明記しています。標準レポートに表示されるまでは最大24時間かかり、リアルタイム レポートはユーザーがキーイベントをトリガーしてから数分後に更新されます。つまり、フォームを直した日に印を付けても、比較できる期間はそこから先だけです。改修の前後を比べたいなら、印を付けるのは改修よりも前です。設定の手順そのものは、GA4のキーイベント設定を扱った記事で画面の順に追っています。

比べるときは、変える箇所を1つに絞る

ここまでの直し方のうち、autocomplete の指定、label の関連付け、エラーのテキスト化、重複入力の廃止は、比較実験の対象ではありません。基準を満たしていない状態を残す理由がないため、そのまま直します。迷うのは、入力欄をいくつにするか、確認画面を挟むか、フォームを複数ページに分けるかといった、どちらにも理屈が立つ選択です。

この種の選択を数字で決めるなら、変える箇所を1つに絞ってから出します。同時に複数を変えると、form_submit が増えても減っても、どの変更の結果なのか分かりません。検索結果への影響を抑える設定を含めた進め方は、A/Bテストの実施手順をまとめた記事に分けて書いています。

着手の順番

1. 拡張計測機能のフォームの操作が有効か確認し、form_start と form_submit が集まっている状態にする
2. ページの表示数と2つのイベントを並べ、フォームの前で止まっているのか、入力の最中で止まっているのかを決める
3. 入力の最中なら、autocomplete、input type と inputmode、label と for、必須の示し方を上から順に直す
4. エラー表示と重複入力を、達成基準 3.3.1、3.3.3、3.3.7 で点検する
5. ここまでを直し終えてから、入力欄の数や分割の是非を、1つずつ比べて決める

この順番にする理由は、1から4が基準で判定できる作業で、5だけが判断を伴う作業だからです。判断を伴う部分に最初から手を付けると、基準を満たしていない状態のまま数字を比べることになり、どちらの結果も信用できなくなります。