【マイレース開発記録(8)】バリデーション地獄　　　　　　　　　　　　　　　　　　　　　　　

入力チェックは“地味に最強”だった

この回は、正直に言います。
いちばん地味で、いちばん心が折れそうになった工程です。

バリデーション（入力チェック）。

占いアプリだから、入力が多い。
そして、入力が多いほど「想定外」は増える。
バグの多くは、ロジックより先に “入力のゆがみ” から生まれます。

「動いた！」の次に来たのは、
「でも、変な入力されたらどうなるの？」という現実でした。

なぜバリデーションが必要だったのか

マイレースの入力は4つあります。

• 生年月日
• 出生時間
• 出生地（都道府県）
• 眺めたい日（占いたい日）

これ、全部そろって初めて計算できます。

でも、ユーザーは必ずやります。

• 日付を入れない
• 時刻を入れない
• 都道府県を選ばない
• 生年月日より前の日を選ぶ
• 変な形式で送ってくる（JS側の想定外）

「ちゃんと入力してね」で済むなら楽なんですが、
Webアプリは、入力を“信じてはいけない”世界です。

JSのフォームは「正しい気がする」問題

最初はこう思っていました。

required を付けてるし、select だから大丈夫だよね

…大丈夫じゃなかったです。

• required はブラウザ依存の挙動がある
• fetch() でPOSTするので、フォーム送信とは違う
• 何より APIは直接叩ける

つまり、
フロントで弾いても バックエンド側で必ず守らないといけない。

ここでようやく、
「バリデーションは“保険”じゃなくて“柱”」だと理解しました。

Flask API側で最初に決めた方針

私は今回、バリデーションの方針をこう決めました。

1. API側で必ず検証する
2. エラーは 日本語で明確に返す
3. フロント側は そのまま表示してユーザーが直せる ようにする

「何が悪いのか分からないエラー」は、ユーザーも、開発者も苦しいです。

だから、たとえば都道府県が不正なら

• 出生地が不正です

日付が逆なら：

• 占いたい日は出生日以降にしてください

こういうふうに、直し方が見える形にしました。

実装：app.py のバリデーション（最低限だけど重要）

APIではまず、JSONを受け取って、こう検証しています。

• birthday と target は日付として解釈できるか
• birth_time は HH:MM 形式か
• prefecture は辞書 PREFECTURES に存在するか
• target < birthday になっていないか

この段階で落ちたら、400 を返します。

Python

if pref not in PREFECTURES:
return jsonify({"error": "出生地が不正です"}), 400

if target < birthday:
return jsonify({"error": "占いたい日は出生日以降にしてください"}), 400

この2行があるだけで、
“壊れ方”がかなり減りました。

でも、地獄はここからだった

バリデーションを入れた途端、今度は自分が混乱しました。

• フロントで弾く？バックで弾く？両方？
• エラーをどこで表示する？
• 「必須」ってどのタイミングで判断する？
• 時刻が空のとき split(":") で落ちる
• 日付が空だと strptime で例外
• 例外処理が増えるほど、コードが読みにくくなる

そして私は、ここで自分の特性にぶつかりました。

発達特性×バリデーションの相性が悪い理由

バリデーションは、細かい条件の連続です。

• AならB
• BならC
• Cなら例外
• その例外にはメッセージ…

この「条件の網目」が増えるほど、
私の中で優先順位が混乱しやすくなりました。

• 何を先にチェックするべきか
• 例外の順番で挙動が変わる
• どのケースが未対応なのか分からなくなる

気がつくと、

「直したはずなのに別の入力で落ちる」

の繰り返し。

これが、私のバリデーション地獄でした。

ここでAIが“効いた”ポイント

AIが助けてくれたのは、コードを生む力というより

「条件を整理して、言語化する力」**でした。

私はAIにこういう相談をしました。

• 入力の失敗パターンを列挙して
• どの順番でチェックすると混乱しにくい？
• try/except の粒度はどこが適切？
• この例外はどのエラーメッセージにすべき？

すると、
“チェック項目を表にして整理する”という提案が出てきました。

結果、私は自分の中で

• 形式チェック（パースできるか）
• 存在チェック（prefectureが辞書にあるか）
• 論理チェック（targetがbirthday以降か）

と段階を分けられるようになりました。

これが大きかった。

学び：バリデーションは「ユーザーのため」だけじゃない

今回いちばん意外だったのは、

バリデーションが開発者のメンタルを守る

ということでした。

入力が揺れると、
ロジックが正しいのか、入力が悪いのか分からなくなる。

でも、入口で入力を整えると

• バグの原因が切り分けやすい
• デバッグが楽になる
• 仕様が言語化される
• APIが“信用できる”ようになる

これは就活的にもすごく大事で、
「品質担保を意識している」証拠になります。

次回予告

次の記事では、地獄の続きです。

【マイレース開発記録(9)】47都道府県の緯度経度実装
— 「出生地」をどう扱うかで設計が揺れた —

占星術アプリっぽく見える部分ですが、裏では地味にデータ設計と整合性の話になります。

また紆余曲折、書きます。