Webとモバイルクライアントの共通バリデーションルール

なぜバリデーションはずれるのか

バリデーションがずれる理由は単純です：Webとモバイルのフォームは別々のタイミングで、別の人が作ることが多いからです。あるチームがウェブに簡単なルールを追加し、別のチームが古いバージョンをアプリにコピーして、そのまま進めてしまう。

最初は差が小さく見えます。しかしある変更で露呈します。パスワードが8文字から12文字に変わる。電話番号に国コードが必要になる。以前は任意だった項目が必須になる。もし片方のクライアントだけが更新されると、同じ顧客があるデバイスでは有効なデータを入力でき、別のデバイスでは拒否されることになります。

だからこそ共有バリデーションルールが重要です。なければ、それぞれのクライアントが独自の“真実”になります。

実際にずれるとどうなるか

サインアップフォームは問題を素早く露わにします。ウェブでは「会社名」が任意かもしれませんが、モバイルでは数ヶ月前に作られた画面のままで必須になっているかもしれません。ユーザーは同じフォームを二度入力し、異なる結果に遭遇して製品が壊れていると思います。

これは通常、ルールがいくつかの場所にコピーされ手作業で更新されると起きます。リリースのタイミングがさらに悪化させます。ウェブの変更は今日公開できても、モバイルの修正は次のアプリリリースまで待つことがあります。

食い違いは基本的な箇所で現れます：必須項目、形式チェック、年齢や注文量、割引ルールのようなビジネス上の制約。サポートチームは、ある画面が値を受け入れて別の画面が拒否する理由を説明する羽目になります。時間が経つとユーザーはエラーメッセージを信用しなくなり、チームはリリースを信用しなくなります。

問題はルール自体よりも、同じルールがあまりにも多くの場所に存在することです。

どのルールをすべての場所で同じにするべきか

フォームがWebである挙動、モバイルで別の挙動だとユーザーはすぐ気づきます。最も安全な方法は、どのルールが普遍的かを決め、それらをすべてのクライアントで同じに保つことです。

まずは基本から。あるデバイスで必須で別のデバイスで任意という状況は、非常に明確なプロダクト上の理由がない限り避けましょう。形式チェックも一致させます。メール、電話、日付などのフィールドはどこでも同じパターンに従うべきです。例えば一方が電話番号に空白を許すのに対し、もう一方が拒否するような小さな違いでも混乱を招きます。

文字数制限や許可文字も同様です。モバイルでユーザー名が30文字許されてウェブで20文字しか許されないと、別のクライアントで後から編集できなくなるデータが保存されてしまいます。名前、メモ、コード、IDなどでも同じ問題が起きます。

ビジネスルールも同じくらい重要です。ユーザーが一定の年齢以上である必要がある、サポートされる地域に属している必要がある、特定のアカウント状態である必要がある、などのチェックはどの画面でも同じに動作するべきです。

文言は画面ごとに完全に同一である必要はありません（特にモバイルの小さな画面では）が、意味は一貫していなければなりません。片方のアプリが「有効な日付を入力してください」と表示し、別のアプリが「サポートされていない日付」と表示すると、ルールが違うと誤解されるかもしれません。

簡単なテストが有効です：ユーザーが同じデータをWebとモバイルで入力したら、同じ結果と同じ基本的な修正案内が得られるべきです。

最終判断はバックエンドに任せる

フロントエンドでの素早いフィードバックは有用ですが、最終判断にはなり得ません。バックエンドが常にデータの有効性を決めるべきです。

Webとモバイルは明らかな問題を早期に検出するべきです。必須項目の欠落、メール形式の誤り、不可能な日付、明らかに範囲外の値などをフロントで指摘すれば、送信前にユーザーが修正できます。

しかしバックエンドはより全体像を見られます。ライブデータやアカウント状態、権限、在庫、または他ユーザーによって直前に変更されたレコードに紐づくビジネスルールをチェックできます。プロモコードがスマホ上では有効に見えても、サーバー側では期限切れや既に使用済みだと判断されることがあります。

共有バリデーションルールをうまく機能させるには、バックエンドがクライアント側で理解できる形式でエラーを返すべきです。「入力が無効です」のようなあいまいな返信は避け、安定したエラーコードやルール名とわかりやすいメッセージを組み合わせてください。

いくつかの例を挙げます：

• required（必須フィールド）
• invalid_format（メールや電話の形式不正）
• out_of_range（範囲外の値）
• not_allowed（権限や状態による拒否）
• already_exists（メール、ユーザー名、IDの重複）

これらの名前はクライアント間で安定しているべきです。例えば一方で email_invalid、もう一方で invalid_email といった小さな差がバグの原因になります。

良いバックエンドのテストはシンプルです：UIをすっ飛ばしてAPIに直接リクエストを送っても、同じ不正データは同じ理由で拒否されるべきです。

真実のソースを一つにする

最もきれいな解決はルールブックを一つにすることです。各チームがWebフォームやモバイル画面ごとにバリデーションを書くと、ルールは必ずずれていきます。ルールを一度だけ定義し、すべてのクライアントがその定義に従う方がうまくいきます。

共有のソースはスキーマ、バックエンドモデル、中央のプロダクト設定などで構いません。形式より習慣が重要です。画面を作る前にフィールドを一度だけ定義してください。フィールド名、データ型、必須かどうか、形式、ビジネス上の上限・下限などをまとめておきます。

ビジネスオブジェクトごとにルールをグループ化するのも有効です。ユーザー、注文、請求書、サインアップリクエストなどは、どのデバイスでも同じルールセットを持つべきです。各オブジェクトについて、フィールド、必須チェック、形式ルール、ビジネス制約、バックエンドが返すエラーコードを記録しておきます。

これにより変更が安全になります。例えば電話番号を任意にする決定が出たら、iPhone、Android、Web、管理画面を探して個別に修正する代わりに、共有定義を一つ更新するだけで済みます。

バージョニングも重要です。ルールの変更はまだインストールされている古いアプリを壊す可能性があります。ルールを跡形もなく置き換えるのではなく、バージョンを付けてバックエンドが短期間古いクライアントをサポートできるようにしましょう。

変更時に簡単なレビューを入れるだけで、多くのチームが期待する以上に役立ちます。ルールが変わったら、プロダクトがビジネス目標を確認し、サポートが「名前欄が一般的な句読点を弾いている」や「住所ルールが厳しすぎる」といった実際の顧客問題を指摘できます。

もしAppMasterで構築しているなら、このアプローチは自然に当てはまります。バックエンドロジック、ウェブアプリ、ネイティブモバイルアプリを一つのノーコードプラットフォームで管理できるためです。どこで作るにせよ、ルールは一度書いて中央に置き、すべてのクライアントがそれに従うようにしましょう。

シンプルな展開プラン

バリデーションのずれを直すために大規模な書き換えは必要ありません。まずは一つのフォームからルールを明確にしましょう。

まず各フィールドをリストアップして平易な言葉で説明します。どんな値を受け入れるか、必須かどうか、どの形式に従うか、どんなビジネス条件があるかを明記します。単に「メールは必須」と書くだけでは不十分です。クライアントの一つが誤った形式を許す一方で別のクライアントが弾く、といった差が起きます。

次にバックエンドのチェックを先に実装します。その後、同じチェックをWebフォームとモバイルフォームに反映して、送信前にユーザーに素早いフィードバックを与えます。

シンプルな順序がおすすめです：

1. フィールドごとのルールリストを一つ作る。
2. まずバックエンドのバリデーションにルールを入れる。
3. Web側で同じフロントエンドチェックを追加する。
4. モバイル側でも同じチェックを追加する。
5. 同じサンプル入力で全てをテストする。

テストは隠れた差異が現れやすい場所です。各フィールドについて有効な例と無効な例を小さなセットで用意してください：空値、間違った形式、限界より1つ下の値、限界ちょうどの値、限界より1つ上の値。Webとモバイルがバックエンドとすべて一致すれば、信頼できるシステムができたと言えます。

例：顧客サインアップフォーム

サインアップフォームはわかりやすい例です。仮にフィールドが3つ、メール、パスワード、生年月日だとします。

Webとモバイルの両方で、送信前の反応は同じであるべきです。メールが空なら両方が止めて同じメッセージを表示する。形式が間違っていれば両方で検出する。

パスワードルールは正確に一致させます。最小が8文字なら、どこでも8文字であるべきです。ウェブで6文字、モバイルで10文字といった小さな不一致は、ユーザーがデバイスを切り替えたときにすぐ混乱を招きます。

生年月日はビジネスロジックがずれやすい項目です。例えば18歳以上のみサインアップ可能なら、両クライアントが同じカットオフルールと「今日」の定義を使わないと、ウェブで承認されモバイルで拒否されることがあります。

バックエンドはリクエスト到着時に再度すべてをチェックする必要があります。重複アカウントや編集済みのリクエスト、古いアプリバージョンから送られる古いデータなどはそこで検出します。

メッセージも一貫して明確に保ちましょう。良い例は「メールアドレスを入力してください」「有効なメールアドレスを入力してください」「パスワードは最低8文字必要です」「このメールですでにアカウントが存在します」です。ユーザーがどこでも同じ文言を見ると、サポートが楽になり信頼が上がります。

ずれを生む間違い

多くのバリデーション問題は一つの明らかに壊れたルールから来るわけではありません。小さな不一致が時間とともに積み重なって起きます。

よくある間違いの一つはルールを片方のクライアントにだけ隠すことです。iPhoneアプリが電話番号を必須にしているのにウェブが任意にしている、といった具合です。別の間違いは同じフィールドで異なるパターンを使うこと。ウェブが郵便番号の空白を許すのにAndroidが弾く、あるいは片方が電話番号の先頭の+を保持し、もう片方が取り除くなどです。

より深刻なのはUIを過信することです。クライアント側の検証はユーザーが速やかに間違いを直すのに役立ちますが、それだけでは不十分です。古いアプリ、ブラウザの違い、APIへの直接リクエストはすべて、バックエンドが同じビジネス制約を強制しないと不正データを送る可能性があります。

あいまいなエラーメッセージは事態を悪化させます。「無効な入力」ではユーザーが何を直せばいいかわかりません。明確なメッセージが必要です。古いアプリバージョンも見落としがちな点です。新しいリリースで必須項目が増えても、古いクライアントは数週間未完成のデータを送り続けることがあります。

バリデーションがずれ続けるときの典型的な原因はこうした単純なものです：隠れた必須項目、異なる形式ルール、弱いバックエンドチェック、あいまいなエラーメッセージ、古いバージョンへの配慮がないこと。

リリースチェックで問題を見つける

出荷前に、すべてのクライアントで同じフォームを同じ方法でテストしてください。小さなサンプル入力セットを用意し、それらをWebアプリ、モバイルアプリ、バックエンドAPIに通します。あるクライアントが受け入れて別のクライアントが拒否するなら、共有バリデーションはまだ機能していません。

まず基本ケースから始めます。必須項目を空にし、形式不正な値を入力し、境界ケース（ちょうど限界の日時、1文字の名前、最大長まで埋めたフィールド）を試します。

事前チェックで次の問いに答えられるべきです：Webはモバイルと同じ不正入力を拒否するか、バックエンドはクライアントが見逃した無効データを拒否し続けるか、ユーザーはどのクライアントでも同じ意味を読み取れるエラーメッセージを見ているか。

バックエンドのチェックが最も重要です。誰かがUIをすっ飛ばして古いアプリを使うか、APIに直接送るかしても、結果は安全で予測可能であるべきです。

エラー文言は横並びで見直す価値があります。Webが「有効なメールを入力してください」と言い、モバイルが「不明なエラー」とだけ表示するなら、人はアプリの挙動が違うと考えます。

ローンチ後は数日間サポートチケットとユーザーコメントを監視してください。「携帯では動いたのにデスクトップでは動かない」といった苦情は、どのダッシュボードよりも早くバリデーションギャップを示します。

次に取るべきクリーンな手順

フォームがWebとモバイルで異なる形で壊れ続けるなら、すべてを一度に直そうとしないでください。繰り返し問題を起こすフォーム、通常はサインアップ、チェックアウト、プロフィール編集などから始めます。

厳格なルールはまずバックエンドロジックに移しましょう。必須フィールド、形式チェック、重複チェック、年齢やアカウント種別、地域などのビジネス上の制約はここで扱います。その後Webとモバイルは同じチェックを真似して、送信前に素早くフィードバックを返します。

ルールの書き方は平易に保ちます。「顧客ステータスを検証する」ではなく「法人顧客は税IDを入力する必要がある」「SMS通知が有効なら電話番号は必須」といった具合に書くと、デザイナー、開発者、テスター、サポートが差分を見つけやすくなります。

繰り返し作業を減らしたければ、AppMasterのようなツールが役立ちます。バックエンド、ウェブ、ネイティブモバイルを一つのシステムから構築でき、ビジネスロジックを揃えつつ各クライアントで速いフィードバックを与えられます。

目標は短期間で完璧なフォームを作ることではありません。目標は驚きやサポートチケットを減らし、製品が成長してもWebとモバイルのバリデーションが一貫していることです。