INSIGHT
入力欄だけでは決まらない——AIで作ったアプリの入力条件を確かめる
画面以外の入口でも、業務で受け付けてよい値だけを扱えるか。
日付欄には日付しか入らない。金額欄には数字だけ。画面を試した担当者は「入力チェックもできている」と報告した。ところが同じデータをCSVから取り込むと、終了日より後の開始日や、存在しない部門コードまで登録できた。
入力条件は、画面の部品が受け付ける文字だけではない。ファイル取込、外部サービスからの連携、管理画面からの登録でも、同じ業務条件を守る必要がある。
入力欄の見た目を整えたことと、すべての入口で業務に使える値だけを受け付けたことは別の確認である。
値が入る入口を、一枚に並べる
最初に、データが作られ、変わる入口を洗い出す。利用者が入力する画面。表計算ファイルやCSVの取込。取引先や外部サービスから届く連携。管理者による一括登録。既存データの複製や再利用。画面から見えない入口も含める。
一つの項目について、入口ごとに受け付ける条件が一致しているかを見る。画面では部署を選択肢から選ぶのに、ファイルでは自由な文字列を登録できるなら、後工程で集計できない値が生まれるかもしれない。外部連携の値を「相手が送るから正しい」と扱えば、仕様変更や相手側の誤りをそのまま保存する。
OWASPのInput Validation Cheat Sheet は、Web画面だけでなく、供給者、取引先、事業者などのバックエンドから届くデータも含め、信頼できない可能性がある入力を受け取る早い段階で検証する考え方を示す。これはAIで作ったアプリ固有の事故を示す資料ではない。入口の種類にかかわらず条件を揃える根拠として使える。
形式の正しさと、業務上の正しさを二段に分ける
形式の検証は、値の形を確かめる。日付として読めるか、数字か、桁数の範囲か、必須項目があるか、決めた候補のどれか。業務上の検証は、その形の値が仕事の条件に合うかを確かめる。開始日が終了日以前か、申請金額が残予算を超えていないか、その部門コードが申請日時点で有効か、といった条件である。
「2026-02-31」は日付として成立しない。「2026-03-31」は日付として成立しても、契約終了後の申請日なら業務上は受け付けないかもしれない。ゼロ円は数字として正しくても、支払申請で許すかは業務ルールによる。
条件表には、項目名、形式、必須か、許容範囲、他項目との関係、参照する正本、条件を決める人を書く。分からない値を自動補正する場合は、補正前の値と理由を追えるかも決める。曖昧な入力をもっともらしい値へ黙って直すと、利用者が誤りに気づけない。
値が正しいことと、その人が登録してよいことも別である。有効な部門コードでも、他部門の予算を使う権限がなければ申請を通さない。入力条件の試験とは別に、利用者の権限に応じて操作を許す確認を残す。
「形式として読める」と「その仕事で正しい」を二段にし、どちらを誰が決めるかを分ける。
文字の揺れは、保存前にそろえる範囲を決める
同じ内容でも、全角と半角、前後の空白、改行、文字コード、日付や時刻の表し方が違うことがある。入力時にそろえる処理を正規化という。比較や検索を安定させる助けになるが、何でも自動で変えればよいわけではない。
顧客名の空白を消すと別の正式名称になる場合がある。先頭のゼロを落とせば、識別番号の意味が変わる。時刻に地域の情報がなければ、締切の前後が変わる。自由記述では、日本語の文字や正当な記号を拒否しすぎると、業務に必要な入力まで失う。
OWASP資料も、構文と意味の検証、許可する値の定義、長さや範囲の確認、自由記述のUnicode正規化、画面側だけでなく処理側での検証を説明している。一方、入力検証だけをSQLインジェクションやXSSなどへの主な防御にしないとも明記している。入力条件を整えれば他の対策が不要になるわけではない。
拒否した後に、利用者が直せるところまで設計する
入力を拒否するだけでは、業務が止まる。利用者には、どの項目が、どの条件に合わず、どう直せるかを示す。複数件の取込なら、全体を取り消したのか、正しい行だけ保存したのか、エラー行を直して再送できるのかを明らかにする。
エラー記録には、入口、処理した日時、行や項目、受け取った値を安全に識別する情報、拒否理由、訂正後の結果を残す。顧客情報や秘密をエラー画面とログへそのまま出す必要はない。利用者向け表示と、担当者が調べる記録を分ける。
業務上の例外をすべて「不正な入力」にしない。締切後の訂正や特別承認が正規の仕事なら、例外の申請先、承認者、記録を用意する。判断が必要な値は保留にし、担当者が決める前に後工程へ流さない。
試験用の同じ値を各入口へ入れ、期待する結果と比べる
自分が作った入力欄の一項目を選び、許可された試験環境に架空の値を用意する。たとえば契約開始日なら、正しい日付、形式違い、存在しない日付、終了日より後の日付、空欄を比べる。画面以外の入口や管理操作は、実装担当に同じ条件の試験を頼む。
各入口で、受理・拒否・保留が同じ業務ルールになるか、表示とログは何を返すか、訂正後に正しく処理できるかを記録する。画面だけ止まり、連携からは登録できたなら、その差を実装担当へ渡し、処理側の検証を見直す。ある入口だけ別の条件が必要なら、その理由と担当を表に残す。
結果は、業務責任者、データを受け渡す担当、作成・保守担当で共有する。業務責任者は値の意味、受渡し担当は形式、保守担当は各入口の実装と記録を確認する。利用を広げる条件は、主要項目についてこの対応を説明できることである。
入力条件は、正しい値を一度通す試験ではなく、拒否・保留・訂正まで同じ規則で動いた記録として合意する。
同じ値を各入口から通し、業務で受け付けてよい条件を確かめる
入力欄の制限は、利用者を助ける大切な機能である。ただし、業務のデータは画面以外からも入る。値の形が正しくても、仕事の条件に合うとは限らない。
まずは自分で分かる一項目について、受け付けてよい値と、拒否・保留してほしい値を並べたい。試した入口と結果を残し、見えない連携や処理側の確認は担当へ渡す。業務上の条件が曖昧なら、その意味を知る人と確かめてから実装へ戻す。