AIものさし

AIでフォームの入力エラー文を作る方法｜項目・条件・直し方をそろえる

架空の申込条件と文案を照合。必須・任意、人数1～4の境界、複数エラーを8例で検算し、文案と実装・受付完了を分けます。

AIものさし編集部

AIでフォームの入力エラー文を作るときは、「入力が正しくありません」と短くするだけでなく、どの項目に何が必要で、どう直せばよいかを示します。文章を親切にする途中で、任意項目を必須へ変えたり、入力できる上限を変えたりしないことも必要です。

この記事では、架空のイベント申込フォームから、入力条件とエラー文を対応させます。成果物は文案と条件の照合表で、フォームの実装、ブラウザ検証、AI生成、受付処理は行っていません。

目次

エラー文より先に、入力条件を固定する

今回の条件は、氏名が必須、参加人数が1～4人の整数、会社名が任意です。氏名は前後の空白を除いて文字が残ることを確認し、氏名の漢字・かな・英字などの文字種を限定する条件は置きません。

表は横にスクロールできます

項目架空の入力条件文案が変えてはいけないこと
氏名必須。前後の空白を除いて空なら不足漢字だけ、姓と名の間に空白必須などを追加しない
参加人数1～4人の整数0人を認めず、4人ちょうどを除外しない
会社名任意空欄をエラーにしない

これは独自の架空条件で、実在イベントの受付仕様ではありません。実際の文案では、正式な入力条件と項目名を先に確認します。AIに利用者像だけを渡して、必須・任意や上限を推測させません。

エラーになる前のラベルや説明にも、必須、任意、人数の範囲を示す案を用意します。入力後に初めて必要条件を知らされる文面にせず、フォーム上の案内とエラー文が一致するようにします。

項目、問題、直し方を文案へ含める

W3CのWCAG 2.2解説は、検出した入力エラーについて対象項目を特定し、エラーをテキストで説明することを示しています。修正方法が分かる場合の提案も別の達成基準で扱い、セキュリティや目的を損なう場合の例外を含みます。W3C：Error Identification（新しいタブで開く）、Error Suggestion（新しいタブで開く）

今回の文案は次のように固定します。エラーIDは条件と文案を照合するための説明用の識別子で、利用者へそのまま表示する必要はありません。

表は横にスクロールできます

エラーID検出した条件利用者へ示す文案
NAME_REQUIRED氏名が空、または空白のみ氏名は必須です。入力してください。
PEOPLE_RANGE参加人数が1～4の整数ではない参加人数は1～4人の整数で入力してください。

「氏名が不正です」より、足りないものを直接示します。「正しい人数を入力」より、どこまで入力できるかを示します。ただし、この文を置けばフォーム全体がWCAGへ適合する、と判定したものではありません。

文案の改善で、仕様を追加しない

次の案は、今回の条件に合いません。

表は横にスクロールできます

採用しない案条件との不一致
氏名は漢字で入力してください許可する文字種を勝手に狭める
参加人数は1～3人で入力してください4人を除外してしまう
会社名を入力してください任意を必須へ変える

これらはAIが実際に出した誤答ではなく、点検用に作った反例です。「自然で丁寧か」と「条件が正しいか」を別に読みます。丁寧な表現でも、利用者が入力できる範囲を変えていれば修正します。

利用者を責める表現や、開発者向けの内部エラーだけを返す表現も避けます。項目名が画面では「参加人数」なのに、文案では「数量」と呼ぶなど、対応する場所が分かりにくい語の揺れも確認します。

具体的な入力で、表示する文案を照合する

次は文案との対応を確認する架空データです。参加人数は型の処理後の値として、数値と真偽値を区別して渡しています。実際の入力欄から数値へ変換する処理は、この例に含めていません。

表は横にスクロールできます

ケース氏名参加人数会社名期待するエラー
C01空欄2空欄氏名のみ
C02佐藤0空欄参加人数のみ
C03空白のみ5空欄氏名と参加人数
C04山田1空欄なし
C05鈴木4空欄なし
C06中村1.5空欄参加人数のみ
C07田中2空欄なし
C08田中True（真偽値）空欄参加人数のみ

C04とC05で境界の1人と4人を確認します。C07では、会社名が空でも問題ないことを残します。C08は「Trueを1として数えない」という、今回の計算用入力契約の確認です。画面にTrueという選択肢が存在する設定ではありません。

C03なら、氏名と参加人数の2項目へそれぞれの文案を対応させます。全体の案内を付けるなら「入力内容を2か所確認してください」とし、どの項目か分かる説明も残します。2項目の問題を一つの一般文へまとめて、直す場所が消えないようにします。

固定例のエラーと件数を検算する

次のPythonは、入力条件とエラーIDの対応を検査します。文案の読みやすさや、画面での通知を検証するものではありません。

messages = {
    "NAME_REQUIRED": "氏名は必須です。入力してください。",
    "PEOPLE_RANGE": "参加人数は1～4人の整数で入力してください。",
}

def errors(name, people, company):
    found = []
    if not name.strip():
        found.append("NAME_REQUIRED")
    if type(people) is not int or not 1 <= people <= 4:
        found.append("PEOPLE_RANGE")
    return found

cases = [
    ("", 2, ""), ("佐藤", 0, ""), ("　", 5, ""), ("山田", 1, ""),
    ("鈴木", 4, ""), ("中村", 1.5, ""), ("田中", 2, ""), ("田中", True, ""),
]
expected = [
    ["NAME_REQUIRED"], ["PEOPLE_RANGE"], ["NAME_REQUIRED", "PEOPLE_RANGE"], [],
    [], ["PEOPLE_RANGE"], [], ["PEOPLE_RANGE"],
]
actual = [errors(*row) for row in cases]
assert actual == expected
assert sum(bool(row) for row in actual) == 5
assert sum(len(row) for row in actual) == 6
assert all(key in messages for row in actual for key in row)
print([len(row) for row in actual])

8ケース中、エラーのあるケースは5件、エラーIDの延べ数は6件です。C03に二つあるためです。これを実フォームのエラー率やAIの正答率として報告しません。文字列以外の氏名、未定義の項目、別の数値形式などを受ける汎用検証も含めていません。

文案と、通知の実装を分けて確認する

W3Cのフォーム通知チュートリアルは、フォーム全体への通知と、各入力項目の近くでの通知を扱っています。文案を短く明確にし、修正の手掛かりを提供する考え方を参考にします。W3C：User Notifications（新しいタブで開く）

実装では、文案がどの入力項目と対応するか、キーボードや支援技術で気づいて移動できるか、複数エラーを確認できるか、訂正後に状態が更新されるかを別に検証します。赤い枠を付けただけで文案の代わりにしません。今回、その画面や読み上げを確認したわけではありません。

また、この入力検査でエラーがないことと、申込みがサーバーへ保存されたことは別です。入力条件を通った時点で「受付完了」と表示する文案へ変えず、実際の保存結果に応じた通知を別に設計します。

AIへは、条件付きの文案と照合理由を返させる

架空の申込フォームの入力エラー文を作ってください。
氏名は必須で空白のみは不可、参加人数は1～4人の整数、会社名は任意です。
各文案に、対象項目、検出条件、利用者が直すことを対応させてください。
文字種制限、人数上限、必須項目を追加・変更しないでください。
利用者を責めず、画面の項目名をそのまま使ってください。
会社名の空欄にエラーを作らず、入力エラーなしを受付完了としないでください。
出力：条件表、文案、条件との対応、境界例、実画面で未確認の項目。

この依頼と文案は手製例で、AIによる生成実測ではありません。文案を受け取ったら、まず条件が変わっていないか、次に項目と直し方が分かるかを編集確認します。最後に実フォームでの通知と保存結果を別に検証し、文章が完成したことだけで運用へ進めないようにしてください。

参考資料

公式資料の確認日：2026年10月20日。フォーム、条件、入力、文案、反例は独自の架空例です。掲載Pythonと固定例をローカルで検査しました。実装、AI生成、ブラウザ、支援技術、WCAG適合性、受付保存、利用者の操作・改善効果、画面表示は未検証です。

質問から自分に合うAIを探す