form-strategy

フォーム戦略

フォームは、意図を行動に変える場所です。適切に設計しないと、コンバージョンを逃し、ユーザーを苛立たせ、スパムに埋もれてしまいます。特定の技術スタックには依存しません。

---

使用する場面

• フォームを設計または再設計するとき
• 重要なフォームのコンバージョン率が低下しているとき
• スパムが大量に届き、受信トレイやデータベースを圧迫しているとき
• サイト全体のフォームを監査するとき
• バリデーションのロジックを計画するとき
• フォームのツール（フォームサービス、カスタム開発、ノーコード）を選ぶとき
• フォームを CRM、メール、その他の後続システムと連携するとき
• 複数ステップのフォームについて判断するとき

使用しない場面

• 一般的なコンバージョン最適化（cro-optimization を使用）
• フォームのコピー（landing-page-copy を使用）
• フォーム固有の内容を超えるバックエンド処理（frontend-component-build、code-review-web を使用）
• 一般的なアクセシビリティ（accessibility-audit を使用）

---

必要な入力情報

• フォームの目的（どのような行動を促し、どのような結果を得るのか）
• 現在のフォーム（URL、スクリーンショット、または入力項目）
• 現在のパフォーマンス（完了率、スパム率、次のステップへのコンバージョン率）
• 後続システム（送信内容の送信先：CRM、メール、データベース、サポートツール）
• ビジネスの背景（件数、リードの緊急度、誤った登録と登録の見逃しのコスト）

---

フレームワーク：5つの観点

フォームに関するあらゆる判断は、次のいずれかの観点に当てはまります。

観点 1：入力項目の戦略

最も大きな効果をもたらす要素です。入力項目を1つ増やすごとに、コンバージョン率は下がります。

各項目について確認すること：

• ユーザーに価値を提供するために必須ですか？
• ビジネスに価値をもたらすために必須ですか？
• 別の情報源（メールアドレスのドメイン、行動、状況）から推測できますか？
• 後から質問できますか（最初の連絡後、2回目の訪問時、設定ページでなど）？

基本ルール： 次のステップに進むために必要な最小限の情報だけを尋ねます。それ以外は後回しにします。

B2B の問い合わせフォームなら、名前とメールアドレスがあれば始められます。電話番号、会社の規模、役職はあると便利ですが、見込み度の判定に役立つ以上にコンバージョンを妨げることがよくあります。

チェックアウトなら、国、郵便番号、住所、名前、支払い情報が必要です。それ以外（紹介元、マーケティングの受信許可、アカウント作成）は任意にするか、購入後に移します。

観点 2：入力項目の設計

各項目の見た目と動作を決めます。

• 入力欄の上にラベルを置くほうが、プレースホルダーより適しています。プレースホルダーのラベルは入力を始めると消えてしまいます。
• インラインラベル（フローティングラベル）は、非常にコンパクトなフォームに適しています。
• ほとんどのフォームでは1列レイアウトにします。視線が縦に流れるためです。
• 関連する項目をまとめて、間隔を空けて区別できるようにします。無関係な項目を隣り合わせにしないでください。
• 適切な入力タイプ： メールアドレスには email、電話番号には tel、数値には number、日付には date を指定します。モバイルのキーボードが入力内容に合わせて切り替わります。
• オートコンプリート属性： autocomplete="email"、autocomplete="given-name" などを指定します。ブラウザーやパスワードマネージャーが入力を補完します。
• 適用できる項目には妥当なデフォルト値を設定します（IP アドレスをもとに国を事前選択するなど）。誤っていた場合にユーザーを誤解させるような値をデフォルトにしないでください。

観点 3：バリデーション

何が問題なのか、いつ問題なのか、どう直せばよいのかをユーザーに伝えます。

• キー入力のたびではなく、フォーカスが外れたときにバリデーションを行います。 入力中にインラインエラーが表示されると、違和感があります。
• 送信時にも再度バリデーションを行います（ユーザーが入力し忘れた項目を検出します）。
• 具体的なメッセージを表示します。 「メールアドレスには @ を含めてください」は「無効なメールアドレスです」より適切です。
• エラーは、該当する入力項目の横に表示します。
• エラーがある場合はフォームを送信させないでください。最初にエラーがある項目を強調表示し、その位置までスクロールします。
• サーバー側でもバリデーションを行います。 クライアント側のバリデーションは UX のため、サーバー側のバリデーションは正確性のためです。

電話番号や郵便番号など形式に柔軟性がある項目は、寛容にバリデーションします。「標準的ではない」形式ではなく、明らかに誤っているものだけを拒否します。電話番号には多くの形式があります。

Dimension 4: スパム対策

公開フォームはスパムを招きます。最初から対策を計画しましょう。

多層防御：

1. ハニーポットフィールド。 人間は入力しませんが、ボットは入力する隠しフィールドです。入力されていたら、通知せずに拒否します。無料で手間がかからず、手軽なスパムには驚くほど効果的です。
2. 時間ベースの検出。 送信が2～3秒未満で完了した場合（ボット）、または非常に長い時間が経過してから完了した場合（不審なセッション）は拒否します。
3. レート制限。 同じ IP からの送信が多すぎる場合は拒否します。
4. 最後の手段として CAPTCHA を使用。 最新の不可視 CAPTCHA（hCaptcha、reCAPTCHA v3、Turnstile）は手間がかかりません。従来の画像 CAPTCHA はコンバージョンを大きく損ないます。
5. 行動シグナル。 カーソルは動きましたか？スクロールはありましたか？最新のサービスはこうした動きを追跡します。
6. コンテンツフィルタリング。 明らかなスパムコンテンツ（リンク、対象ユーザーが地域限定の場合の外国語コンテンツ、よくあるスパム用語）を拒否します。
7. サーバー側での確認。 スパムの標的になりやすいフォームでは、受信トレイに直接届けるのではなく、キューを使用します。

ほとんどの問い合わせフォームでは、ハニーポット＋時間チェック＋Turnstile（または同等のサービス）で十分です。

Dimension 5: 送信フロー

送信後に何が起こるかを決めます。

• 短いフォームにはインラインの成功メッセージを表示します。確認のためだけにリダイレクトしないでください。
• 価値の高い送信には確認ページを用意します（次の手順を提示し、今後の見通しを伝えるため）。
• 登録、購入、出欠確認には確認メールを送ります。必ず送信してください。
• エラーが発生した場合は、ユーザーがすべてを再入力せずに済むようデータを保存します。
• 楽観的 UI（サーバーの確認前に成功を表示）は、リスクの低いフォームでは有効ですが、リスクの高いフォームでは危険です。

複数ステップのフォームの場合：

• 進捗状況を表示します（5 段階中 3 段階目）
• ステップ間の状態を保存します（更新や移動に備えるため）
• データを失わずに前のステップへ戻れるようにします
• 最後だけでなく、各ステップで検証します

---

ワークフロー

ステップ 1：現状を監査する

サイト上の各フォームについて、以下を確認します。

• 目的は何か
• フィールド数、必須か任意か
• 現在の完了率
• 現在のスパム率
• 検証ルール
• 送信後に起きること
• データの連携先

ステップ 2：フォームごとに成功を定義する

フォームによって成功の指標は異なります。

• リードフォーム：有望なリード（営業部門が定義）
• ニュースレター：確認済みの購読（ダブルオプトイン後）
• 問い合わせ：内容のある返信（単なる送信ではない）
• チェックアウト：決済の成功

単なる送信数ではなく、重要な指標を追跡します。

ステップ 3：フィールドを徹底的に削減する

フィールド戦略の基準を適用します。各フィールドについて、次のように判断します。

• 価値の提供に必須か？残します。
• あると便利か？任意にするか、後で尋ねます。
• 振り分けや評価に使うか？多くの場合、推測できます。

7 フィールドのフォームを 3 フィールドにします。コンバージョンが上がります。

ステップ 4：スパム対策を設定する

フォームを公開する前に：

• ハニーポットフィールドを追加します
• 時間ベースの検出を追加します
• レート制限を追加します
• フォームへのアクセスが多い場合やスパムが多い場合は、最新の CAPTCHA を追加します

公開後は状況を監視します。実際に通過しているスパムに応じて、多層防御を調整します。

ステップ 5：検証を改善する

各フィールドを確認します。

• 検証は具体的ですか？
• 適切なタイミングで実行されますか（キー入力時ではなく、フォーカスが外れたとき、または送信時）？
• エラーメッセージは、次に何をすべきか分かる内容ですか？
• サーバー側の検証とクライアント側の検証は一致していますか？

ステップ 6：アクセシビリティを確認する

最低限、次の項目を満たしてください。

• すべての入力に対応するラベルがある（視覚的に見えるもの、または aria-label）
• エラーが入力と関連付けられている（aria-describedby、aria-invalid）
• フォーカスの順序が視覚的な順序と一致している
• エラーの表示が色だけに依存していない
• フォーム全体をキーボードで操作できる

WCAG の完全な監査については、accessibility-audit を参照してください。

ステップ 7：連携先までテストする

フォームを送信して、以下を確認します。

• データが適切な場所に届く
• 必須フィールドに正しく値が入力されている
• スパム対策が機能している（スクリプトでテストする）
• ユーザーが期待する確認を受け取る
• 内部通知が速やかに届く

連携先のシステムに変更があると、フォームは気づかれないまま壊れることがあります。連携を更新したら、必ずテストしてください。

ステップ 8：モニタリング

• 時間経過に伴う完了率
• 時間経過に伴うスパム率
• 送信ごとのエラー数（エラーが多いほど UX が悪い）
• 離脱フィールド（ユーザーはどこで入力をやめるか？）

---

よくある失敗パターン

フィールドが多すぎる。 ほとんどの B2B 問い合わせフォームには、必要な数の 3 倍ものフィールドがあります。減らしましょう。

入力中にバリデーションが実行される。 煩わしく、ユーザーが入力を終える前にエラーが発生します。

汎用的なエラーメッセージ。 「入力が無効です。」どこが？なぜ？具体的に伝えましょう。

必須フィールドが明示されていない。 ユーザーは送信に失敗して初めて必須だと気づきます。必須項目を明示しましょう（短いフォームでは、任意項目を明示する方法もあります）。

オートコンプリートが無効になっている。 「セキュリティのため」とされていますが、セキュリティが向上することはほとんどなく、UX のコストは必ず発生します。オートコンプリートは有効にしておきましょう。

タブ移動順序が正しくない。 Tab キーでフィールドが飛ばされたり、前の項目に戻ったりします。tabindex は必要な場合にのみ設定し、自然な DOM 順序を使いましょう。

送信ボタンがスクロールしないと見えない位置にある。 特にモバイルでは、ユーザーがボタンに気づきません。

エラー時に入力内容が保存されない。 ユーザーが送信し、エラーが 1 件あり、フォームに戻ると、すべてのフィールドが空になっています。これは最悪です。状態を保存しましょう。

スパム対策が CAPTCHA だけ。 CAPTCHA は入力の負担になります。単一の負担に頼るより、多層的な対策のほうが効果的です。

CAPTCHA が初期状態で表示される。 最新の CAPTCHA（Turnstile、reCAPTCHA v3）は、ほとんどの場合は非表示で、必要な場合にのみ追加の認証を求めます。これらを使いましょう。

ニュースレター登録が実際にはマーケティングリストへの登録になっている。 オプトインの範囲を守りましょう。ユーザーが製品アップデートに登録した場合、マーケティングニュースレターに追加してはいけません。

確認ページが行き止まりになっている。 「送信ありがとうございます」と表示するだけで、次のステップがありません。次に何をすればよいでしょうか？行動につながる選択肢（関連コンテンツを読む、ホームページに戻る、ソーシャルメディアをフォローするなど）を提示しましょう。

マーケティングメールにダブルオプトインがない。 ボットや入力ミスによってリストの質が低下します。これが重要な理由については email-deliverability を参照してください。

メールアドレス欄で name@ が有効と判定される。 ブラウザー仕様のバリデーションは緩やかです。実際の形式に照らして検証しましょう。

ネイティブより使いにくいカスタムの日付ピッカー。 ネイティブの <input type="date"> は、現在ほとんどのプラットフォームで十分に使いやすくなっています。特別な理由がない限り、独自に作り直すのはやめましょう。

再読み込みで入力内容が失われるフォーム。 長いフォームでは、localStorage に保存し、読み込み時に復元しましょう。

---

出力形式

フォーム監査ドキュメントには、次の項目が含まれます。

• フォーム一覧： サイト上のすべてのフォーム
• フォームごとのレビュー： 目的、フィールド、パフォーマンス
• 推奨事項： フィールドの削減、バリデーションの改善、スパム対策、デザインの変更
• スパム対策プラン： フォームごとの対策レイヤー
• アクセシビリティ状況： フォームごとの WCAG 準拠状況
• 下流連携マップ： 各フォームのデータの送信先
• モニタリング計画： 追跡する項目

---

必要なデータが利用できない場合

このスキルの出力は、このスキル単独では生成できないデータ、測定値、またはツールの結果に依存します。必要な入力、ツール、またはデータソースが利用できない、あるいは検証できない場合に認められる出力は、その不足を明記した成果物です。何が必要だったのか、実際に何を取得または検証できたのか、出力のどの部分に影響するのかを記載してください。成果物を完成させるために必要な数値を捏造、推定、または補間することは、いかなる場合も認められません。不足を明記すれば、それで回答として成立します。

---

参考ファイル

• references/form-anatomy-checklist.md：フォームの監査または設計に使える、フィールドごと・動作ごとのチェックリストです。構造、アクセシビリティ、バリデーション、スパム対策を扱います。