Webフォームの入力体験はどう変わったか — 自由記述から段階入力までの4つの変化
Webフォームの設計思想は、紙の申込書を画面に写すところから始まり、入力支援の委譲、段階表示、状況に応じた項目提示へと移ってきました。この流れを一言でまとめると「人に書かせる前提から、書かせずに済ませる前提へ」の移行です。いま入力負担と必要情報のバランスを取る近道は、項目を美しく並べ直すことではなく、①使い道のない項目を削る → ②ブラウザや前工程に埋めさせる → ③残った質問だけを分割・分岐させるという順番で考えることです。以下、4つの変化を背景とともに整理し、最後に判断手順に落とします。
変化1：紙の申込書を画面に写した段階
初期のWebフォームは、紙の申込書のレイアウトをそのまま画面化したものでした。1画面にすべての項目が並び、備考欄のような自由記述が多く、「私の名前は◯◯です」のような穴埋め文章型の入力もありました。紙の様式が持っていた制約（全角カナ指定、ハイフンなし、マス目の桁数）も、そのままシステムの入力規則として持ち込まれました。
この段階の影響は現在も残っています。デジタル庁デザインシステムβ版が、インプットテキストについて「穴埋め文章ではなく、項目ごとに入力する」「入力値の文字種を原則として限定しない」とわざわざ明記しているのは、この種の設計が今も現場に残っているからです。同システムは、既存システムの制約でやむを得ず文字種を限定する場合も、エラーで突き返す前に自動変換による入力支援を行うことを推奨し、変換のタイミングは送信ボタン押下時または確認画面表示時が望ましいとしています。入力直後やフォーカスアウト時に値を書き換えると、利用者の入力と異なる表示になって混乱を招くためです。
つまり「紙を写した段階」の本質的な問題はレイアウトではなく、システム側の都合を利用者の入力作業に転嫁していることにあります。ここが次の変化の出発点になりました。
変化2：入力支援をブラウザ側に委譲する
2つ目の変化は、入力の一部をブラウザとOSに任せるようになったことです。HTMLのautocomplete属性にname・email・postal-codeなどのトークンを指定すると、ブラウザが保存済みの値を自動入力します。MDNによれば、有効な自動補完トークンを与えることは、WCAG 2.2の達成基準1.3.5「入力目的の特定」（レベルAA）の要件を同時に満たします。配送先と請求先のように同じ種類の値が複数ある場合は、shipping postal-code／billing postal-codeのように接頭辞を付けて区別できます。
注意点はautocomplete="off"の扱いです。MDNは、フォーム全体に広く適用するのではなく、CAPTCHAやワンタイムトークンの欄のように本当に必要な場合に限ることを勧めています。「ブラウザに勝手に入れられると困る」という運用上の不安で全体をオフにすると、自動入力の恩恵と1.3.5への適合を同時に失います。
同じ発想の支援として、モバイルのソフトウェアキーボードを切り替えるinputmode属性があります。一方で、使わないほうがよいとされる手段もあります。デジタル庁デザインシステムは、プレースホルダーテキストに入力条件や例を書かないこと（フォーカスすると消え、エラー時に見比べられないため）、入力の最大長制限にmaxlength属性を使わないこと（意図しないテキストの送信につながるため）、メールアドレスを前半と後半に分割しないことを挙げています。入力条件はプレースホルダーではなくサポートテキストに書く、というのがこの段階の到達点です。
重要なのは、入力支援が「入力欄を飾る機能」ではなく「入力行為そのものを減らす仕組み」として位置づけられたことです。
変化3：1画面に全項目から、段階表示へ
3つ目は構造の変化です。英国政府のサービスマニュアルは、フォーム設計の出発点として「1ページに1つのこと（one thing per page）」を置いています。1つのこととは、1つの伝える情報、1つの判断、1つの質問です。この構造は、不慣れな手続きでも現在地を見失いにくい、モバイルで扱いやすい、エラーから復帰しやすい、といった利用者側の利点に加えて、回答を自動保存しやすい、質問単位で計測できる、分岐や繰り返しを扱いやすい、という設計側の利点があるとされています。
興味深いのは、この方式に対する当初の懸念が実地調査で覆された点です。英国政府デジタルサービス（GDS）のユーザーリサーチブログは、進捗インジケーターは利用者にほとんど見られておらず、ある長い申請フォームで削除しても完了率は変わらなかったこと、ページ数の多さは各質問が答えやすく全体の目的に結びついていれば問題にされないこと、入力内容の確認・修正ページはむしろ利点であることを報告しています。アコーディオン型のフォームは推奨から外されました。
ただし万能ではありません。サービスマニュアル自体が、同じ利用者が繰り返し使う業務システムなどではページを統合する判断がありうると述べています。公開フォームで利用頻度が低いほど段階表示が有利、社内の業務画面で習熟した担当者が高速に処理するほど一覧表示が有利、と考えると判断しやすくなります。
段階表示を採用すると、新たな責務が生じます。WCAG 2.2の達成基準3.3.7「冗長な入力項目」（レベルA）は、同一プロセス内で以前に入力・提示された情報の再入力を求める場合、自動入力するか、利用者が選択できるようにすることを求めます。例外は、再入力が必要不可欠な場合、セキュリティ確保に必要な場合、以前の情報が無効になった場合の3つです。解説書は、この要件を満たす責任はサイト側にあり、ブラウザのオートコンプリート機能では十分とみなされないと明記しています。「請求先住所は配送先と同じ」のチェックボックスのような選択手段でもよく、選択できるデータは同じページ上にある必要があります。なお対象は同一プロセス内であり、セッションをまたぐ保存までは求められません。決済代行事業者を挟む購入フローのように、ドメインをまたぐプロセスも範囲に含まれます。
変化4：全員に同じ項目から、状況に応じた項目提示へ
4つ目は、誰に何を聞くかを動的に決めるようになったことです。サービスマニュアルは、最も多いシナリオを優先して質問順を設計し、対象外となる条件はできるだけ早く尋ね、分岐質問で関係のない質問を見せないことを勧めています。段階表示は、この分岐と相性がよいから広まったという側面もあります。
実装時の落とし穴は、項目の出し入れが予測不能な変化になることです。デジタル庁デザインシステムは、入力値の変更をトリガーに新しいダイアログを開く、フォームが送信される、値が書き換わると同時にフォーカスが移動するといった変化を避けるよう求めています。入力フィールドの変更によって次以降のフォームが変化する場合は、そのことを事前にテキストで伝えることが条件です。条件分岐は「黙って項目が増減する」のではなく、「変わることを予告したうえで変える」必要があります。
自由記述の位置づけもここで変わります。デジタル庁デザインシステムのテキストエリアの設計原則は、自由入力形式の回答は利用者にとって負荷が高いとし、「その他を選んだ方だけご記入ください」のように質問を分割したうえでの使用を検討するよう述べています。自由記述は最初に置く汎用の受け皿ではなく、選択肢で拾えなかった分岐の先に置く例外的な手段、という扱いです。文字数制限があるならラベルに具体的に書き、おおむね20文字を超える制限では文字数カウンターを添えます。
さらに先の動きとして、ブラウザがウォレットから身元情報を受け取るDigital Credentials APIの標準化が進んでいます。W3Cの公開履歴では2025年7月の初回公開作業草案以降、2026年9月時点でも作業草案（Working Draft）の段階です。項目を「聞く」のではなく「提示してもらう」方向の変化として押さえておく価値はありますが、仕様が流動的で対応環境も限られるため、現時点では主要な入力手段ではなく追加の選択肢として扱うのが妥当です。
入力負担と必要情報のバランスを取る手順
4つの変化を踏まえると、既存フォームの見直しは次の順序で進められます。
- 項目ごとに使い道を書き出す。サービスマニュアルが最初に置く問いは「なぜその質問をするのか」です。誰がいつ使うか、正確性をどう確認するかを1行で書けない項目は削除候補です。項目を減らす施策が、UI改善より先に来ます。
- 残った項目を3つに仕分ける。（a）ブラウザに埋めさせられるもの（氏名・住所・電話・メール）は
autocompleteトークンを付与、（b）同じプロセスの前工程で得ているものは自動入力か選択で再利用（3.3.7）、（c）どちらでもないものだけが「人に聞く項目」です。 - (c)だけを分割と分岐の対象にする。公開フォームや利用頻度の低い手続きは1ページ1質問を出発点にし、対象外条件は前半で尋ねます。習熟者が繰り返す業務画面では統合を検討します。生年月日のように1つの質問が複数フィールドになるのは問題ありません。
- エラーと支援テキストを前倒しする。入力条件はサポートテキストに事前提示し、プレースホルダーに逃がさない。文字種の制約が外せないなら、エラーで返す前に自動変換を検討し、変換結果は確認画面で承認・修正できるようにします。
- 計測単位を質問単位にする。段階表示の利点の一つは、どの質問で離脱・エラーが起きたかが分かることです。進捗バーの有無のような見た目の調整より、離脱の多い質問を削れないか・分岐の先に移せないかを先に検討します。
この手順の効果は、フォーム単体ではなく上流で決まります。必要情報の一覧は多くの場合、営業・審査・CRMの運用側が決めています。Web担当者は「この項目は誰が何に使うか」を関係部署に確認するところから、フロントエンドエンジニアは既存フォームの項目をa/b/cに仕分けるところから着手すると、議論が具体的になります。
出典
- デジタル庁デザインシステムβ版: インプットテキスト（使い方）
- デジタル庁デザインシステムβ版: インプットテキスト（アクセシビリティ）
- デジタル庁デザインシステムβ版: テキストエリア（概要）
- GOV.UK サービスマニュアル: フォームの構造化（Structuring forms）
- GOV.UK ユーザーリサーチブログ: フォーム構造の選び方（No more accordions）
- ウェブアクセシビリティ基盤委員会（WAIC）: WCAG 2.2 解説書 達成基準 3.3.7 冗長な入力項目
- MDN Web Docs: HTML属性 autocomplete
- W3C: Digital Credentials 公開履歴
