注文画面の入力ミスをどう防ぐ？画面と保存側で決める確認点

画面は入力を助け、保存する側は受け取った値を確かめる

入力検証とは、受け取った値がその項目で認める条件に合うかを確かめることです。箱数なら、入力が必要か、どんな数字の書き方を認めるか、業務で使える範囲かを確認します。「数字になっている」ことと、「この注文で使える箱数である」ことは別です。

ブラウザーは利用者が触る画面です。その場で説明や案内を出せれば、入力した人は送り直す前に修正できます。一方、APIは画面などからデータを受け渡す窓口です。APIの受け取り側であるサーバーは、届いた値を業務処理や保存へ進める前に確認します。APIという窓口と、データを保存するデータベースも同じものではありません。

MDNのフォーム検証の説明は、ブラウザーの検証があっても、フォームを通らない要求などが届くため、サーバー側の検証を必要としています。両側の確認は、どちらか一方でよいという重複作業ではありません。

OWASPの入力検証の指針も、形式と業務上の意味を確かめ、ブラウザーが確認する項目でもサーバー側で検証することを示しています。社内向けだからという理由だけで省略しません。また、入力値の検証と、操作してよい人かという権限の確認は別です。入力検証だけでシステム全体の安全が確定するわけではありません。

「箱数は数字で」から、業務で認める条件へ具体化する

この例の入力項目は箱数、業務の単位は箱です。先に営業の入力作業と、受注を扱う業務担当の判断をそろえます。開発担当へ「よい感じに制限して」と任せると、表示と実際に受け付ける条件が食い違うおそれがあります。

• 必須か：未確認。注文の下書きと確定で扱いを変える必要があるかも、業務担当へ聞きます。空欄を勝手にゼロへ置き換える条件にはしません。
• 数字の書き方：未確認。整数だけか、小数があるか、全角や単位付きの入力を受け付けるか、変換するなら何を残すかを決めます。一般論で「箱だから整数」と補いません。
• 下限と上限：未確認。何を根拠に範囲を決め、範囲外では何を案内するかを尋ねます。別会社の記事の数値をそのまま使わないでください。

「受け付ける条件」は、画面と保存側で業務上の意味をそろえます。ただし入力文字の表現まで、常に同じ型であるとは限りません。画面の文字をAPIへ渡す値に変換する設計なら、その変換と変換できない場合の返答も開発担当に説明してもらいます。値の見た目だけで一致を決めないことが大切です。

未入力・「三箱」・「3」を、同じ三つの相談例として使う

両担当へ別々の例を渡すと、違う条件の回答を比べることになります。今回は次の入力例をそのまま両者へ示し、許可するか、利用者へ何を伝えるか、保存はどう扱うかを尋ねます。

「3」は入力文字列として選んだ例です。採用済みの許可値、APIが実際に受け取った数値、保存に成功した記録の意味ではありません。

箱数欄へ同じ入力を入れたとき、画面の案内と保存側の判断をどこで揃えて決めるか。

この解説図を原寸で見る

図の読み方：左の三つの入力例を、中央の画面での案内と、右のAPI側の確認・返答へ対応させます。APIは画面を通らずに届く要求も受け取るため、画面だけの判定に任せません。右端の点線は三例共通で保存の扱いを尋ねる関係です。「？」は決める必要のある箇所を表し、実際のエラー画面や保存結果を表していません。

規則・画面案内・API応答・保存扱いの四つが同じ入力ごとに決まるまで、業務担当は仕様の了承を保留する。答えが揃えば同条件の試験を開発担当に依頼する。実試験の成功とは表示しない。

三例とも、次の四項目は現時点で未確認です。これは採用する回答まで同じという意味ではありません。次に決める内容を分けて尋ねます。

• 許可・拒否：未確認。業務条件から、それぞれを受け付けるか決める。
• 画面での案内：未確認。入力した人が何を直せばよいか説明する。
• API側の返答：未確認。拒否した理由を呼び出し元が区別できる形にする。
• 保存の扱い：未確認。注文や以前の記録に何が起きる設計かを確認する。

画面とAPIの担当へ、同じ規則と返答を確認する

業務担当は、何が業務で使える値か、どの段階で必要かを決めます。画面担当は、その条件をどう説明し、どの時点で知らせるかを答えます。APIの担当は、届いた値を独立してどう確認し、拒否をどう返し、保存へ進めるかを答えます。一人が両側を作る場合でも、確認する役割は分けて読みます。

この下書きでは、画面側の規則確認は未確認、保存側の規則確認は未確認、エラー文の確認は未確認です。単に「同じにします」という回答だけでなく、三つの入力それぞれの扱いを説明してもらってください。

日本語のWebフロントエンド設計ガイドラインでも、画面とサーバーの目的を分け、検証する条件の同期を扱っています。発注担当が先に特定のコード共有方式を指定するより、同じ条件が更新後もそろう方法と、その確認担当を開発側へ尋ねることが出発点です。

画面で受け付けると表示したのにAPIでは拒否する場合は、どちらの条件が今回の業務に合うかへ戻ります。逆に、画面では止めるがAPIは条件外の値を受け付ける場合も、そのまま了承しません。サーバーでしか確かめられない情報があるなら、それを使う条件と画面へ返す説明を別に整理します。両者が全く同じ処理を持つ、という意味でそろえるのではありません。

エラー文は、どの欄をどう直すかが分かる文章にする

「入力エラーです」だけでは、箱数欄の未入力か、形式か、範囲かを利用者が判断できません。採用した規則に合わせて、項目の名前と直す理由を伝えます。必須が決まった場合には未入力への案内を、形式が決まった場合には認める書き方を示す、という順序です。未確定の規則をエラー文だけで確定させないでください。

WAICの「エラーの特定」の解説は、自動検出したエラーの場所を示し、内容をテキストで説明することを扱っています。欄を赤くするだけで済ませず、どの項目で何が起きたかを文章でも伝える設計にします。この一点を決めただけで、画面全体のアクセシビリティ適合を認定するものではありません。

案内を出す時点も相談します。入力の途中で何度も警告して妨げないか、欄から移った時点か、保存しようとした時点か、サーバーから拒否が返った時点かを区別します。修正後に古い案内が残らないか、ほかの欄へ移っても該当箇所が分かるかも確認します。

W3C WAIの入力検証の解説は、入力条件や案内を通じて誤りから直せるようにする考え方を示しています。利用する人に伝わる日本語、キーボードでの操作、読み上げでの通知など、今回の利用条件に応じた確認を開発担当と選びます。この記事の模式図だけでは、それらの実動作は分かりません。

拒否の返答と、注文・保存済み情報の扱いを一緒に決める

APIが拒否を返す設計と、保存済みの注文がどうなる設計かは、関連しますが同じ答えではありません。「エラーになる」と聞いただけで、何も保存されない、以前の情報が必ず残る、と補わないでください。箱数欄だけの更新なのか、注文全体の登録・変更なのかも開発側へ示します。

• どこまで変わるか：拒否時に箱数、注文のほかの項目、以前の記録をどう扱うか。途中まで反映する設計なら、それを業務で認めるか。
• 何を戻せるか：利用者が入力したほかの内容を保てるか。直して再度送る際、同じ注文を重複して作らないか。
• 結果をどう見分けるか：入力条件による拒否と、通信の中断などで結果が分からない状態を区別できるか。表示が止まったことだけで保存結果を決めない。

下書き段階で望んでいる設計は、業務担当が許可条件を決め、画面は入力中の分かる案内を出し、APIも独立して同じ許可条件を判定し、拒否時の応答と保存扱いを明示する提案。未承認の仕様であり実動作の記録ではない。 この希望を満たす回答があるかを確認します。APIの実装方法や、注文の更新をまとめて確定する方法は開発担当に説明してもらい、回答が業務に合わなければ採用を保留します。

回答を同じ仕様へ戻してから、決まった条件で試験する

両担当へ、次の問いをまとめて伝えます。資料を新しく増やすこと自体より、一つの箱数欄の同じ規則と入力例を、両側が同じ版で説明できることを優先してください。

1. 必須か、数字の書き方と許可範囲を業務担当がどう決めるか。
2. 同じ規則を画面とAPIの双方がどう確認するか。
3. 拒否時に箱数欄へどの日本語を表示し、APIは呼び出し元へ何を返すか。
4. 拒否した場合に注文や以前の保存済み情報をどう扱う設計か。
5. 三つの入力で両側の答えが揃うことを誰がどの環境で確認するか。

回答によって、次の作業を変える

仕様の採用と、実装・試験の結果を混ぜない

この下書きでは、採用した規則、実際の画面・保存側の動作、試験・保存・顧客への結果、完了の判断は、いずれも未確認です。仕様への返答を得たことを、動作や保存が成功した記録へ読み替えません。

採用後は、同じ三例を画面から試す確認と、画面の検査を経ない要求を受け取り側がどう扱うかの確認を開発担当へ依頼します。許可範囲が決まったら、その境界や範囲外、直した後のやり直しなど必要な例も追加します。実顧客の注文を使う前提にせず、確認用の環境・データ・版・担当と、期待する返答・保存扱いを決めます。

結果の説明を受けたら、操作、受け取った返答、保存後に残る情報を対応させます。条件を変えた場合は、画面の文だけでなく、API側の判定、返答、保存扱いと関係する試験も同じ版へ戻します。全体の受入条件の組み立ては、通常の入力・入力違い・権限から受入条件を決める方法につなげてください。

まとめ：同じ箱数の入力を、両側の答えと保存扱いへ結ぶ

画面の入力検証は、入力する人を助けるために使います。APIなど受け取り側でも、届いた値を独立して確認します。発注担当がそろえるのは、同じ業務条件と入力例に対する、画面の案内、許可・拒否の返答、保存の扱いです。

この例では、未入力、「三箱」、「3」のどれも許可や実結果が決まっていません。空欄を埋めるより、必要な回答を得て食い違いを直し、採用する条件と後の試験へつなげます。数字に見えること、エラーが表示されたこと、APIが返答したことだけで、注文の保存結果を決めないでください。

業務全体で何を受け渡すかが決まっていない場合は、受注・出荷・請求の流れから販売管理の要件を決める方法が先の整理に役立ちます。運用中のフォームでエラーを観測したい場合は、画面の入力エラーとGA4・受付記録を分ける方法で、設計の相談と観測の調査を分けて進めてください。