前回からの続きと、この講義の役割
前回のH-04では、フォームに何を、どう並べて入力してもらうかを6要素で設計しました。今回はその一歩先、入力された値が条件を満たしているかを確かめる仕組み、バリデーションを扱います。ここで大切なのは、検証には画面側とサーバー側の2か所があり、それぞれ果たす役割がまったく違うという点です。この違いを自分の言葉で言い分けられるようになることが、この講義の目標です。
このスライドのポイント
- 前回H-04: フォームに何をどう並べて入力してもらうかを6要素で設計した
- 今回: 入力された値が条件を満たしているかを確かめる仕組み＝バリデーション
- 検証には画面側とサーバー側の2か所があり、果たす役割が違う
バリデーションの定義と、2つの側
バリデーションとは、入力された値が決めた条件、たとえば形式や範囲、必須かどうかを満たしているかを確かめる検証のことです。これには2つの場所があります。1つはクライアント側、つまりブラウザの中での検証で、入力した直後に間違いへ気づかせる、利用者への親切です。もう1つはサーバー側の検証で、不正な値からデータを守る防御にあたります。こちらの詳細はカテゴリJで扱います。ここで押さえるべきは、クライアント側の検証はD-01で見たとおり利用者の手元で動くため、無効化したり回避したりできる、という点です。ですから、それだけでは防御にはなりません。
このスライドのポイント
- バリデーション＝入力値が条件（形式・範囲・必須）を満たすかの検証
- クライアント側（ブラウザ内）＝入力直後に気づかせる、利用者への親切
- サーバー側＝不正な値からデータを守る防御（詳細はカテゴリJ）
- クライアント側は利用者の手元（D-01）で動くため、無効化・回避できる→防御にはならない
なぜ必要か——「画面でチェックしているから大丈夫」の落とし穴
この区別を知らないと、「画面できちんとチェックしているから大丈夫」という、とても危険な誤解に陥ります。クライアント側の検証は利用者の手元で動くため、画面を細工されれば簡単に素通りされてしまいます。つまり、親切のための仕組みを、防御のための仕組みだと取り違えている状態です。ここは、クライアントは利用者の手元だというD-01の考え方と、安全は高リスクの領域だというA-09の考え方が合流する、重要な地点です。
このスライドのポイント
- 知らないと「画面でチェックしているから大丈夫」という致命的な誤解に陥る
- クライアント側の検証は回避できるので、細工された値は素通りする
- D-01（クライアントは利用者の手元）とA-09（安全は高リスク領域）の合流点
構造——2段の検証
検証の構造は2段になっています。上段がクライアント側で、反応が速く、利用者に親切ですが、回避されうる検証です。下段がサーバー側で、こちらが最終防衛線になります。大事なのは、この2つはどちらか一方があればよいのではなく、両方が必要で、しかも役割が違うということです。速く知らせる親切と、確実に守る防御。片方でもう片方を肩代わりすることはできません。
このスライドのポイント
- 検証は2段: クライアント側＝速い・親切・回避されうる／サーバー側＝最終防衛線
- 両方必要で、役割が違う
- 片方でもう片方を代替できない
処理の流れ——経費申請フォームで見る
経費申請フォームで考えます。金額欄にマイナスの値を入れた瞬間、赤い文字で「0円より大きい値を入れてください」と知らせる。これがクライアント側の親切です。利用者は送信する前に間違いへ気づけます。ところが、もし誰かが画面の仕組みを細工して、マイナスの金額をそのまま送ってきたらどうでしょう。それを受け取って弾くのは、サーバー側の検証の仕事です。同じ「マイナスを禁止する」という検証でも、片方は体験のため、もう片方はデータを守るためにある、というわけです。
このスライドのポイント
- 金額欄にマイナスを入れた瞬間、赤字で知らせる＝クライアント側の親切
- 画面を細工して送られたマイナス値を弾くのはサーバー側の仕事
- 同じ「マイナス禁止」でも、片方は体験のため、片方はデータを守るため
技術サンプルカード
サンプルは、検証の2段構えを1枚にした構成図です。入力はまずクライアント側検証を通り、ここですぐに間違いを知らせます。ただしこの通過点は回避されうるものです。次に送信、これはD-03で見た通信を経て、サーバー側検証を通ります。こちらがデータを守る最終防衛線です。読み方のポイントは、通過点が2つあること、そして両者の役割は違い、片方ではもう片方を代替できないことです。AIには「この検証はクライアント側とサーバー側のどちらにありますか。サーバー側にも同じ検証はありますか」と質問して確かめます。
混同しやすい概念——「検証済み」と「安全」
混同しやすいのが、「クライアント側で検証済み」ということと、「安全である」ということです。この2つはまったく別のことを指しています。クライアント側で検証済みというのは、利用者が快適に入力できたという体験の話です。一方、安全であるというのは、不正な値からデータが守られているというサーバー側の話です。画面側で検証したことを、そのまま安全の根拠にしてはいけません。
このスライドのポイント
- 対比: 「クライアント側で検証済み」vs「安全」
- 前者は体験の話、後者はサーバー側の話
- 画面側で検証したことを、安全の根拠にしてはいけない
バイブコーディングでの確認点
バイブコーディングでの確認点です。AIにフォームを作らせたら、必ず「サーバー側にも同じ検証がありますか」と確認してください。画面側だけの検証をもって「入力チェックは対策済みです」と報告してくるAIには、特に注意が必要です。それは親切を防御と取り違えた報告だからです。人間の側が、この2つの役割を知っているからこそ、その報告の抜けに気づけます。質問例はそのまま、「このフォームの検証は画面側だけですか、サーバー側にもありますか」です。
このスライドのポイント
- AIがフォームを作ったら「サーバー側にも同じ検証がありますか」を必ず確認
- 画面側だけの検証で「対策済み」と報告するAIは要注意
- 人間がこの2つの役割を知っているから、報告の抜けに気づける
一問一答とまとめ
一問一答です。防御の役割を果たすのは、クライアント側とサーバー側、どちらの検証でしょうか。……答えは、サーバー側です。クライアント側は親切であり、回避されうるからです。30秒まとめ。バリデーションには2つの側があり、クライアント側は速く知らせる親切、サーバー側はデータを守る防御。両方が必要で、片方では代替できません。次回のH-06では、画面そのものが持つ「状態」と、その移り変わりの設計へ進みます。関連資料は「AIアプリのセキュリティ超入門」と「フォーム設計パターン50」です。
このスライドのポイント
- 一問一答: 防御の役割を果たすのはどちら側の検証？→サーバー側
- 30秒まとめ: 検証は2段。クライアント側＝親切、サーバー側＝防御。両方必要・代替不可
- 次回: H-06 状態と状態遷移
- 関連資料: 「AIアプリのセキュリティ超入門」「フォーム設計パターン50」
