最終更新: 2026-05-01

フォーム入力の文字数バリデーション設計 - UX を損なわない制限の実装

フォームの文字数バリデーションは、データの整合性を守りつつユーザー体験を維持するという、相反する要求のバランスを取る設計課題です。maxlength 属性を設定するだけでは不十分であり、リアルタイムカウンター、サロゲートペアへの対応、サーバーサイド検証、そしてエラー発生時の適切なフィードバックまで、考慮すべき要素は多岐にわたります。本記事では、データベースの VARCHAR 長との整合性も踏まえながら、実務で使えるバリデーション設計のパターンを解説します。文字数制限の基本概念を押さえた上で読み進めてください。

maxlength 属性の落とし穴

HTML の maxlength 属性は、最も手軽な文字数制限の手段です。しかし、この属性には開発者が見落としがちな問題がいくつか存在します。

最大の問題は、maxlength が UTF-16 コードユニット数で制限をかける点です。基本多言語面 (BMP) の文字は 1 コードユニットですが、絵文字やサロゲートペアを含む文字は 2 コードユニットを消費します。つまり、maxlength="10" と設定したフィールドに絵文字を入力すると、見た目上は 5 文字しか入力できません。

この問題は特に名前入力フィールドで顕著です。日本の戸籍に登録されている漢字には CJK 統合漢字拡張 B に含まれるものがあり、maxlength で 2 コードユニットを消費します。「𠮷田」という名字は見た目上 2 文字ですが、maxlength 上は 3 コードユニットを消費します。全角・半角の文字数カウントの問題とも密接に関連する課題です。

もう一つの問題は、maxlength がユーザーに無言で入力を拒否する点です。制限に達すると、それ以上の文字が入力できなくなりますが、なぜ入力できないのかのフィードバックがありません。ユーザーはキーボードの故障を疑ったり、ブラウザの不具合だと思ったりする可能性があります。

JavaScript による正確な文字数カウント

maxlength の UTF-16 問題を回避するには、JavaScript で書記素クラスタ (Grapheme Cluster) 単位のカウントを実装する必要があります。書記素クラスタとは、人間が「1 文字」と認識する単位のことで、サロゲートペアや結合文字、ZWJ シーケンスを正しく 1 文字としてカウントします。

最も信頼性の高い方法は、Intl.Segmenter API を使用することです。

// Intl.Segmenter による書記素クラスタカウント
function countGraphemes(text) {
  const segmenter = new Intl.Segmenter('ja', { granularity: 'grapheme' });
  return [...segmenter.segment(text)].length;
}

// 使用例
countGraphemes('Hello');        // 5
countGraphemes('こんにちは');    // 5
countGraphemes('👨‍👩‍👧‍👦');          // 1
countGraphemes('🇯🇵');           // 1
countGraphemes('𠮷田太郎');      // 4

Intl.Segmenter は 2024 年時点で主要ブラウザ (Chrome 87+, Firefox 125+, Safari 15.4+) でサポートされています。古いブラウザをサポートする必要がある場合は、grapheme-splitter ライブラリがフォールバックとして利用できます。

ただし、すべてのフォームで書記素クラスタカウントが必要なわけではありません。メールアドレスや URL のように ASCII 文字のみを受け付けるフィールドでは、maxlength で十分です。書記素クラスタカウントが必要なのは、ユーザーが自由にテキストを入力するフィールド (名前、コメント、自己紹介文など) に限られます。

リアルタイム文字数カウンターの設計

リアルタイム文字数カウンターは、ユーザーに残り文字数を視覚的にフィードバックする UI コンポーネントです。X (旧 Twitter) の文字数制限で採用されている円形プログレスインジケーターは、この分野のベストプラクティスとして広く認知されています。

カウンターの設計で考慮すべきポイントは以下の通りです。

X の設計が優れているのは、文字数制限に近づくにつれて円形インジケーターの色が変化し、超過するとマイナスの数値が赤く表示される点です。入力をブロックするのではなく、超過した状態でも編集を続けられるようにし、投稿ボタンを無効化するというアプローチは、ユーザーに「どこを削るか」を考える余裕を与えます。

サーバーサイドバリデーションの必須性

クライアントサイドのバリデーションは UX のためのものであり、セキュリティやデータ整合性の保証にはなりません。maxlength 属性も JavaScript のカウンターも、ブラウザの開発者ツールで簡単に無効化できます。API を直接叩けば、フロントエンドのバリデーションは完全にバイパスされます。

サーバーサイドでの文字数バリデーションは、パスワードの文字数セキュリティと同様に、セキュリティの最後の砦です。以下の点を必ず実装してください。

• バイト数の検証: データベースの VARCHAR はバイト数または文字数で制限されるため、サーバーサイドで UTF-8 エンコード後のバイト数も検証する
• 正規化の適用: Unicode の NFC 正規化を適用してから文字数をカウントする。同じ見た目の文字でも、合成済み文字と結合文字列で文字数が異なる場合がある
• 制御文字の除去: NULL 文字、バックスペース、その他の制御文字を除去してからカウントする
• トリミング: 先頭と末尾の空白を除去してからカウントする。空白だけで文字数を消費させない

// Python でのサーバーサイドバリデーション例
import unicodedata

def validate_text_length(text, max_chars=200, max_bytes=800):
    # 制御文字の除去
    cleaned = ''.join(c for c in text if unicodedata.category(c) != 'Cc')
    # NFC 正規化
    normalized = unicodedata.normalize('NFC', cleaned.strip())
    # 文字数チェック
    char_count = len(normalized)
    # UTF-8 バイト数チェック
    byte_count = len(normalized.encode('utf-8'))

    if char_count > max_chars:
        return False, f'文字数が上限を超えています ({char_count}/{max_chars})'
    if byte_count > max_bytes:
        return False, f'データサイズが上限を超えています'
    return True, None

フレームワーク別の実装パターン

主要なフロントエンドフレームワークでの文字数バリデーション実装パターンを比較します。

React Hook Form と Zod の組み合わせは、型安全性とバリデーションロジックの一元管理という点で優れています。Zod スキーマをサーバーサイドと共有することで、フロントエンドとバックエンドのバリデーションルールの不一致を防げます。

// React Hook Form + Zod の例
import { z } from 'zod';
import { useForm } from 'react-hook-form';
import { zodResolver } from '@hookform/resolvers/zod';

const schema = z.object({
  comment: z.string()
    .min(1, 'コメントを入力してください')
    .max(500, 'コメントは 500 文字以内で入力してください'),
  nickname: z.string()
    .min(1, 'ニックネームを入力してください')
    .max(20, 'ニックネームは 20 文字以内で入力してください'),
});

function CommentForm() {
  const { register, watch, formState: { errors } } = useForm({
    resolver: zodResolver(schema),
  });
  const comment = watch('comment', '');

  return (
    <div>
      <textarea {...register('comment')} />
      <span aria-live="polite">
        {comment.length}/500
      </span>
      {errors.comment && <p role="alert">{errors.comment.message}</p>}
    </div>
  );
}

文字数制限のエラーメッセージ設計

文字数超過時のエラーメッセージは、エラーメッセージの設計原則に従い、問題の内容と解決方法を簡潔に伝える必要があります。

段階的警告のアプローチが最も効果的です。文字数制限に近づいた段階で視覚的なフィードバックを与え、超過した場合は具体的な超過文字数と解決策を提示します。これにより、ユーザーは制限を意識しながら入力を進められ、超過した場合も冷静に対処できます。

フォーム設計の参考書籍はAmazon の UX デザイン関連書籍でも見つかります。

テキストエリアの自動リサイズと文字数制限の共存

テキストエリアの自動リサイズ (Auto-resize) は、入力内容に応じてフィールドの高さが自動的に拡張する UI パターンです。文字数制限と組み合わせる場合、いくつかの設計上の判断が必要になります。

自動リサイズの最大高さを設定しないと、長文入力時にページレイアウトが崩れる可能性があります。文字数制限が 500 文字のフィールドであれば、日本語で約 20 行分の高さ (約 400px) を最大値として設定するのが実用的です。最大高さに達した後はスクロールバーを表示し、入力の継続を妨げないようにします。

CSS の field-sizing: content プロパティは、2024 年に Chrome 123 で実装された新しい機能で、JavaScript なしでテキストエリアの自動リサイズを実現できます。ただし、Firefox と Safari では未サポートのため、プログレッシブエンハンスメントとして導入するのが現実的です。

モバイルフォームの文字数制限 - 特有の課題

モバイルデバイスでのフォーム入力には、デスクトップとは異なる文字数関連の課題があります。

• IME の変換中テキスト: 日本語入力の変換中 (composing 状態) は、input イベントが発火しても確定前のテキストが含まれる。compositionstart / compositionend イベントを監視し、変換中はバリデーションを一時停止する必要がある
• 予測変換の影響: iOS や Android の予測変換で候補を選択すると、一度に複数文字が入力される。maxlength を超える文字が一気に挿入される場合があり、JavaScript での制御が必要
• 画面サイズの制約: 文字数カウンターの表示スペースが限られるため、モバイルでは「残り 42」のように簡潔な表示にし、デスクトップでは「残り 42 文字 (458/500)」のように詳細を表示する
• ソフトキーボードの表示: ソフトキーボードが表示されると画面の有効領域が約半分になる。文字数カウンターがキーボードに隠れないよう、フィールド内またはフィールド直下に配置する

// IME 変換中のバリデーション制御
let isComposing = false;

textarea.addEventListener('compositionstart', () => {
  isComposing = true;
});

textarea.addEventListener('compositionend', () => {
  isComposing = false;
  validateLength(textarea.value); // 変換確定後にバリデーション
});

textarea.addEventListener('input', () => {
  if (!isComposing) {
    validateLength(textarea.value);
  }
  // カウンター表示は変換中も更新する (UX のため)
  updateCounter(textarea.value);
});

データベースとの整合性設計

フロントエンドの文字数制限とデータベースのカラム定義の不整合は、本番環境でのデータ切り捨てやエラーの原因になります。データベースの VARCHAR 長設計で詳しく解説されているように、MySQL の VARCHAR(255) は文字数ベースですが、実際のストレージ消費はエンコーディングに依存します。

安全な設計方針として、フロントエンドの文字数制限はデータベースのカラム定義よりも厳しく設定することを推奨します。たとえば、データベースが VARCHAR(500) であれば、フロントエンドの制限は 450 文字程度に設定し、Unicode 正規化やトリミングによる文字数変動のバッファを確保します。