概要
入力を信じるな、検証せよ。
ユーザーの入力、外部APIのレスポンス、ストレージからの復元――これら**“信用ならない値”**に対して、
何を必須とし、どの形式を受け入れ、どう誤りを検出・通知するかが、アプリケーションの安全性とUXを左右する。
本稿では、バリデーションを次の観点から整理する：
- 型検査・null/undefinedの検出
- 複数条件を持つフィールド検証
- 同期/非同期バリデーション
- UI表示との責務分離
- 汎用的なバリデーション構造の構築
1. 型チェックと存在確認
✅ 単純なプリミティブチェック
function isString(value) {
return typeof value === 'string';
}
function isNonEmptyString(value) {
return isString(value) && value.trim().length > 0;
}
→ ✅ typeof / Array.isArray() / instanceof による型ガードを基本とする
2. 必須チェックと複数条件の設計
function validateEmail(value) {
if (!value) return 'メールアドレスは必須です';
if (!/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(value)) return '形式が正しくありません';
return null;
}
→ ✅ nullなら成功 / エラーメッセージを返す方式が実用的
3. フィールド単位のバリデータ関数群
const validators = {
name: (v) => v?.trim() ? null : '名前は必須です',
age: (v) => v > 0 ? null : '年齢は1以上を入力してください',
email: validateEmail
};
→ ✅ 各フィールドに責任を持たせ、ルールを分離
→ ✅ フォーム設計において再利用可能
4. フォーム全体の検証戦略
function validateForm(data) {
const errors = {};
for (const key in validators) {
const error = validators[key](data[key]);
if (error) errors[key] = error;
}
return Object.keys(errors).length > 0 ? errors : null;
}
- ✅ エラーがあるかどうかは
nullまたはerrorsの有無で判定 - ✅ フロントエンドでの事前検証 → API送信 → サーバー検証の流れに統合可能
5. 非同期バリデーション（重複チェックなど）
async function checkUsernameExists(username) {
const res = await fetch(`/api/check-username?name=${username}`);
const { exists } = await res.json();
return exists ? 'このユーザー名はすでに使われています' : null;
}
- ✅ 入力中でも検証可能に（例：Debounce + 非同期検証）
- ✅ UI側で非同期の状態管理が必要（
isCheckingフラグなど）
6. UIとバリデーションの責務分離
- ✅
validateXXX()関数は純粋関数とする（DOM操作しない） - ✅ 表示（例：赤枠・メッセージ）はコンポーネント側が担当
- ✅ バリデーション関数はテスト可能なロジックに留める
7. 汎用バリデーションユーティリティの構築
function createValidator(rules) {
return (value) => {
for (const rule of rules) {
const error = rule(value);
if (error) return error;
}
return null;
};
}
// 使用例
const validatePassword = createValidator([
(v) => v.length >= 8 ? null : '8文字以上必要です',
(v) => /[A-Z]/.test(v) ? null : '大文字を含めてください'
]);
→ ✅ チェックルールを配列で柔軟に組み合わせ可能
→ ✅ 共通ルールの再利用が容易に
設計判断フロー
① 値の型が保証されない？ → 型ガード関数を定義
② 必須項目？ → 空チェック + 明示的なエラーメッセージ
③ ルールが複数ある？ → 順序付きの関数配列で検証
④ APIと連携したい？ → 非同期検証関数を導入
⑤ UI更新と検証を分離したい？ → 検証は純粋関数として定義
よくあるミスと対策
❌ バリデーション関数内でDOMを直接操作
→ ✅ 検証は検証、表示は表示。役割を分ける
❌ エラー表現がコード内にハードコーディングされすぎる
→ ✅ 国際化や再利用性を考慮し、メッセージ辞書化を検討
❌ 同期/非同期検証が混在して管理不能に
→ ✅ ステータスを分離（例：同期検証結果 + 非同期検証中フラグ）
結語
バリデーションとは“値の正しさ”ではなく、**“正しさの判断基準を構造として設計する行為”**である。
- チェックは明確に
- メッセージは意味を持って
- 責務は関数に封じて
- 検証は構造で繰り返せるように
ユーザーの安心は、信頼できる入力から生まれる。
堅牢な検証は、UIの品位と信頼性を支える基盤である。