フォームのリアルタイムバリデーション、表示タイミングが9割

フォーム入力中にエラーを出すタイミングを間違えると、ユーザーを混乱させる逆効果になります。blur・input・submitそれぞれの特性と、実案件で使えるベストプラクティスを解説します。

こんな悩み、ありませんか？

フォームにリアルタイムバリデーションを実装したのに、「かえって使いにくい」とクライアントからクレームが来た——。そんな経験はないでしょうか。

入力欄をクリックした瞬間にエラーが出る、文字を1文字入れただけで「メールアドレスの形式が正しくありません」と怒られる、送信前なのにページ全体が赤くなる……。これらはすべて「バリデーション自体は正しいのに、タイミングが悪いせいで体験を壊している」典型例です。

リアルタイムバリデーションは正しく実装すればフォームの完了率を大幅に改善する強力な施策ですが、タイミングの設計を間違えると、むしろ離脱を増やす諸刃の剣になります。この記事では、タイミング設計の考え方から実装コード、現場でよくやりがちなミスまで、実案件を踏まえて解説します。

なぜ「タイミング」がそんなに重要なのか

ユーザーがフォームを操作するとき、その心理的な流れは大きく3つのフェーズに分かれます。

flowchart LR
    A[フォーカス\n入力開始] --> B[入力中\n文字を打つ]
    B --> C[フォーカスアウト\n次の項目へ]
    C --> D[送信ボタン\nを押す]
    style A fill:#DBEAFE,stroke:#3B82F6
    style B fill:#FEF9C3,stroke:#F59E0B
    style C fill:#D1FAE5,stroke:#10B981
    style D fill:#EDE9FE,stroke:#8B5CF6

このフェーズのどこでエラーを表示するかによって、ユーザーが感じる「ストレス」はまったく異なります。

入力開始直後にエラーを出すのは、「まだ何も書いていないのに怒られた」状態です。「必須項目です」というメッセージを一文字も打つ前に見せられたら、誰でも萎えます。

入力中に毎キーストロークでエラーを出すのも問題です。メールアドレスを入力するとき、t → ta → tar と打つたびに「正しくありません」と表示されたら、ユーザーは入力に集中できません。

一方、すべてをsubmit時にまとめて出すだけでは、どこを直せばいいか分かりにくく、長いフォームだと上まで戻るのが面倒でユーザーが途中離脱します。

ベストなタイミングは「フォーカスアウト後 + 送信時」の組み合わせです。これを前提に、実装を組んでいきましょう。

実案件での話：問い合わせ完了率が1.4倍になった件

あるBtoB企業のコーポレートサイトを制作した際、問い合わせフォームの完了率が著しく低いという課題がありました。Analytics上でフォームページの直帰率を確認すると、入力途中での离脱が集中しており、特に「メールアドレス」と「電話番号」の項目で手が止まっているユーザーが多いことが判明しました。

当時のフォームはsubmit時のサーバーサイドバリデーションのみで、送信するまでエラーが分からない仕様。しかも送信後にページリロードされ、入力内容が消える実装でした。

改善後は以下の方針でバリデーションを再設計しました：

• blur（フォーカスアウト）時：形式チェック・必須チェックのエラーを表示
• input時：エラーが一度表示された後のみ、リアルタイムでエラーを更新（修正中にリアルタイムフィードバックを得られる）
• submit時：全項目を再チェックし、未入力項目にフォーカスをセット

この3段構えで実装し直した結果、問い合わせフォームの完了率が改善前の約1.4倍に向上しました。

実装：段階的バリデーションのコードと解説

基本の考え方：「触れた項目だけ」エラーを出す

各フィールドに touched という状態フラグを持たせ、一度blurされたフィールドだけバリデーション表示を有効にするのがポイントです。

const fields = document.querySelectorAll('.form-field');

fields.forEach(field => {
  // blurされた時点でtouchedフラグを立て、バリデーション実行
  field.addEventListener('blur', () => {
    field.dataset.touched = 'true';
    validateField(field);
  });

  // input時は「既にtouchedなら」リアルタイム更新
  field.addEventListener('input', () => {
    if (field.dataset.touched === 'true') {
      validateField(field);
    }
  });
});

function validateField(field) {
  const errorEl = document.querySelector(`#error-${field.name}`);
  const value = field.value.trim();
  let message = '';

  if (field.required && value === '') {
    message = 'この項目は必須です。';
  } else if (field.type === 'email' && value !== '') {
    const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
    if (!emailRegex.test(value)) {
      message = '正しいメールアドレスの形式で入力してください。';
    }
  } else if (field.type === 'tel' && value !== '') {
    const telRegex = /^[0-9\-\+\(\)\s]{10,15}$/;
    if (!telRegex.test(value)) {
      message = '正しい電話番号の形式で入力してください。';
    }
  }

  if (message) {
    errorEl.textContent = message;
    errorEl.style.display = 'block';
    field.setAttribute('aria-invalid', 'true');
  } else {
    errorEl.textContent = '';
    errorEl.style.display = 'none';
    field.setAttribute('aria-invalid', 'false');
  }
}

// submit時はすべてtouchedにして全チェック
document.querySelector('form').addEventListener('submit', (e) => {
  fields.forEach(field => {
    field.dataset.touched = 'true';
    validateField(field);
  });

  const firstError = document.querySelector('[aria-invalid="true"]');
  if (firstError) {
    e.preventDefault();
    firstError.focus(); // エラーのある最初の項目にフォーカス移動
  }
});

import { useState } from 'react';

function ContactForm() {
  const [values, setValues] = useState({ email: '', tel: '' });
  const [touched, setTouched] = useState({});
  const [errors, setErrors] = useState({});

  const validate = (name, value) => {
    let message = '';
    if (!value.trim()) {
      message = 'この項目は必須です。';
    } else if (name === 'email') {
      if (!/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(value)) {
        message = '正しいメールアドレスの形式で入力してください。';
      }
    } else if (name === 'tel') {
      if (!/^[0-9\-\+\(\)\s]{10,15}$/.test(value)) {
        message = '正しい電話番号の形式で入力してください。';
      }
    }
    return message;
  };

  const handleChange = (e) => {
    const { name, value } = e.target;
    setValues(prev => ({ ...prev, [name]: value }));
    // touchedな項目だけリアルタイム更新
    if (touched[name]) {
      setErrors(prev => ({ ...prev, [name]: validate(name, value) }));
    }
  };

  const handleBlur = (e) => {
    const { name, value } = e.target;
    setTouched(prev => ({ ...prev, [name]: true }));
    setErrors(prev => ({ ...prev, [name]: validate(name, value) }));
  };

  return (
    <form>
      <div>
        <input
          type="email"
          name="email"
          value={values.email}
          onChange={handleChange}
          onBlur={handleBlur}
          aria-invalid={!!errors.email}
        />
        {touched.email && errors.email && (
          <p role="alert" className="error">{errors.email}</p>
        )}
      </div>
    </form>
  );
}

HTML側では、エラー表示用の要素と aria-invalid 属性を正しく使うことで、スクリーンリーダーにも対応した実装になります。

<div class="form-group">
  <label for="email">メールアドレス <span class="required">必須</span></label>
  <input
    type="email"
    id="email"
    name="email"
    class="form-field"
    required
    aria-describedby="error-email"
  >
  <p id="error-email" class="error-message" role="alert" style="display:none;"></p>
</div>

role="alert" を付けることで、エラー内容が更新された際にスクリーンリーダーが自動で読み上げてくれます。アクセシビリティ対応として必須の記述です。

よくある失敗パターンと対処法

❌ 失敗1：focusイベントでエラーを出す

// これはNG：項目をクリックしただけでエラーが出る
field.addEventListener('focus', () => {
  validateField(field); // まだ何も入力していない
});

フォーカスした瞬間に「必須です」と言われるのは、ユーザーにとって恫喝に近い体験です。必ず blur（離れた時点）を起点にしてください。

❌ 失敗2：成功メッセージを出さない

エラーだけ表示して、正しく入力できた時に何もフィードバックしないケース。「これで合ってるのかな？」という不安がユーザーに残ります。

// 正しく入力できたらグリーンのチェックを表示する
if (!message) {
  field.classList.add('is-valid');
  field.classList.remove('is-invalid');
}

エラーが消えただけでは安心感が伝わりにくいので、視覚的なOKサインを出すと離脱率が下がります。

❌ 失敗3：デバウンスなしでAPIチェックを叩く

メールアドレスの重複チェックなど、入力中にAPIを叩くケースでは必ずデバウンスを設けてください。

let debounceTimer;
field.addEventListener('input', () => {
  clearTimeout(debounceTimer);
  debounceTimer = setTimeout(() => {
    checkEmailDuplicate(field.value); // 500ms後に実行
  }, 500);
});

デバウンスなしでは1文字入力するたびにAPIリクエストが飛び、サーバー負荷が爆発します。これは過去の現場で実際に問題になったケースで、負荷試験の直前に気づいて修正した苦い経験があります。

❌ 失敗4：エラーメッセージが不親切

「入力エラーです」だけでは何をどう直せばいいか分かりません。

メッセージは「何が問題か」「どうすれば解決するか」まで含めるのが理想です。

まとめと次のステップ

フォームのリアルタイムバリデーションは、タイミング設計が9割です。技術的な実装よりも「どの瞬間にユーザーにエラーを伝えるか」という設計判断が、フォームの完了率に直結します。

「blur後にエラーを出し、touched後はinputでリアルタイム更新する」という段階的なアプローチは、ユーザーの認知負荷を最小化しながら、修正のしやすさを最大化する現時点でのベストプラクティスです。

これを土台に、プロジェクトの要件（API連携、多項目フォーム、ステップ式フォームなど）に応じてカスタマイズしていくのが、実案件での進め方です。

フォームの完了率でお悩みのケースや、既存フォームのUX改善を検討されている場合は、Fivenine Designにお気軽にご相談ください。コードレビューからフルリプレイスまで、プロジェクトの規模に応じて対応いたします。