バリデーションとは、入力されたデータが決められた形式や条件を満たしているかを、処理を進める前に確かめる工程です。目的は不正な値でのエラー防止だけではありません。データの整合性を保ち、不正な入力を突く攻撃を防ぎ、業務ルールの逸脱を水際で止める役割まで含みます。この記事では、バリデーションの定義と妥当性確認(validation)・検証(verification)の違い、単項目・相関・業務ルールという検証の区分、フロントエンドとサーバーサイドの二重検証、実際に動くコードで示す実装手順、フレームワーク機能を使った実装パターン、そして抜けをテストで担保する設計までを、受託開発の実装現場の視点で整理します。
まとめ：バリデーションの目的・区分・多層設計と実装の要点
バリデーションの芯は「入力を信用しない」ことです。利用者の打ち間違いも、悪意ある改ざんも、同じ前提で受け止めます。フロントエンドの検証は入力体験を良くするための即時フィードバックであり、データの正しさを保証するのはサーバーサイドの検証です。ブラウザの検証は迂回できるため、サーバー側を最後の砦に据えます。
検証の中身は、単項目（型・桁数・必須・書式）、項目間の相関（開始日と終了日の前後など）、業務ルール（在庫数やDB上の一意性）の三層で考えると漏れが減ります。実装はフレームワークの宣言的バリデーションを基本に置き、フレームワークで表せない業務判断だけを個別のコードで補うと保守性が上がります。
設計で見落とされがちなのが、境界値と異常系のテストです。正常系だけを確かめて「動いた」と判断すると、上限値や空文字、想定外の型で本番が壊れます。一方で、あらゆる項目に過剰な検証を積めば、増えるのは開発と保守の負担だけです。本記事では、どこまで検証し、どこで止めるかの判断基準まで示します。
実装の骨格も先に示しておきます。フロントはHTMLの制約検証属性とcheckValidity()で送信前に弾き、サーバーはスキーマ定義ライブラリで受信データを丸ごと検証し、失敗したら項目ごとの理由をまとめて返す。この三点セットが最小構成です。エラー応答の形式には、RFC 9457 Problem Details for HTTP APIs（2023年7月発行・RFC 7807を廃止）という既製の仕様があり、独自形式を発明せずに済みます。具体的なコードは後半の実装手順で示します。
バリデーションとは何か：定義と妥当性確認・検証の違い、目的の全体像
まず言葉の範囲をそろえます。バリデーションは、アプリケーションが受け取ったデータを処理する前に、それが「期待どおりの形と意味を持つか」を判定する行為です。フォームの入力チェックが代表例ですが、対象は画面入力に限りません。APIで受け取るリクエスト、取り込むCSV、外部システムからの連携データも、すべて検証の対象になります。
バリデーションの定義と、入力値を一切信用しないという前提が必要な理由
バリデーションが必要なのは、外から入ってくる値が正しい保証がどこにもないからです。利用者は必須欄を空のまま送信し、全角数字と半角数字を混在させ、想定より長い文字列を貼り付けます。さらに、画面を経由せずにリクエストを直接組み立てる操作も日常的にある話です。だからアプリケーションは、受け取った値を常に疑う前提で設計します。検証を通らなかったデータは処理に進めず、理由を添えて突き返す——この線引きがバリデーションの基本動作です。
この前提の抜けは、脆弱性の分類でも独立して扱われる項目です。MITREが管理する共通脆弱性タイプ一覧では、入力検証の不備がCWE-20 Improper Input Validationとして定義され、そこから境界外書き込みやインジェクションなど多数の弱点が派生する関係にあると整理されています。つまり入力検証は個別機能の作り込みではなく、他の弱点の親にあたる位置づけだと読み取れます。
validation（妥当性確認）とverification（検証）の違いと使い分け
日本語ではどちらも「検証」と訳されがちですが、ソフトウェア品質の文脈では区別します。バリデーション（validation）は「作ったものが利用者の要求・目的に合っているか」を確かめる妥当性確認です。ベリフィケーション（verification）は「仕様どおりに正しく作られているか」を確かめる検証です。入力チェックの文脈でのバリデーションは、受け取ったデータが業務上の要求（必須・範囲・関係性）を満たすかを見る点で、この妥当性確認の考え方に沿っています。用語の混同は設計会議の齟齬を生むため、チーム内で意味をそろえておくと安全です。
| 観点 | validation（妥当性確認） | verification（検証） |
|---|---|---|
| 問い | 要求・目的に合っているか | 仕様どおり正しく作られているか |
| 入力検証での意味 | データが業務要件を満たすか | 実装が設計どおり動くか |
| 代表例 | 必須・範囲・項目間の整合 | 単体テスト・結合テスト |
入力チェックの現場では両者が地続きです。バリデーションのルール自体が仕様どおり実装されているかは、後述のテストで確かめます。
バリデーションの種類：単項目・相関・業務ルールの検証区分と観点
検証内容をひとまとめに考えると、必ず抜けが出ます。チェックの性質で層に分けるのが管理の要点です。単項目で完結するもの、複数項目の関係を見るもの、外部データや業務知識を要するものの順で、実装の難易度と結合度が上がります。
単項目チェック（必須・型・桁数・書式）で押さえる具体的な確認項目
単項目チェックは、一つの入力欄だけで判定が完結する検証です。実務でまず押さえるのはこの層です。必須入力の有無、数値・日付といった型の適合、文字数や桁数の上限下限、メールアドレスや電話番号の書式（多くは正規表現で判定）、選択肢が許可値の範囲に収まっているか。ここは要件が明確で自動化しやすいため、後述するフレームワークの宣言的バリデーションで大半をまかなえます。単項目チェックの網羅性が、入力起因の障害の多くを未然に防ぎます。
構文的検証と意味的検証を分けて考える入力検証の区分と適用範囲
OWASPのInput Validation Cheat Sheetは、検証を二段階に分けて説明しています。構文的検証（syntactic validation）は、日付や識別番号のように構造が決まった項目が正しい形式かを見るもの。意味的検証（semantic validation）は、開始日が終了日より前かといった、業務文脈での値の妥当性を見るものです。前者はフレームワークの宣言的な仕組みで書けますが、後者は業務知識が要るため個別実装になります。
この区分は、検証の書き場所を決めるときに効きます。同じ「日付の検証」でも、書式がYYYY-MM-DDかどうかは入力の受け口で判定でき、その日付が受注可能期間内かはサービス層でしか判定できません。両者を同じ場所にまとめると、業務ルールが入力層に染み出して再利用が効かなくなります。なお同ドキュメントは、メールアドレスの検証について、技術的に有効なアドレスの表現が複雑なため過度に厳密な正規表現を目指さず、基本的な形式確認のうえで実際に送信して確かめる方法が確実だとも述べています。
相関チェック・業務ルールチェック（項目間・DB照合）の観点と難所
相関チェックは、複数の入力欄をまたいで整合を見る検証です。たとえば「開始日が終了日より後になっていないか」「支払方法がクレジットなら card番号が必須になるか」といった、項目間の依存関係が対象です。業務ルールチェックはさらに一歩進み、DBや外部システムの状態を参照します。「注文数が在庫数を超えていないか」「登録しようとするメールアドレスが既存ユーザーと重複していないか」がこの例です。いずれも業務知識とデータアクセスを伴うため、フレームワークの宣言的な仕組みだけでは表しきれず、個別のコードで書く場面が増えます。相関・業務ルールの検証漏れは、単項目の漏れよりデータ不整合という深い障害につながりやすい難所です。
バリデーションをどこで検証するか：フロントとサーバーの多層設計と役割
同じ検証を「どこで実行するか」で、役割がまったく変わります。フロントとサーバーは競合ではなく、目的の異なる二重の守りです。片方だけに寄せると、使い勝手か安全性のどちらかが崩れます。
フロントエンドとサーバーサイドの二重検証と、それぞれの役割分担
フロントエンド（ブラウザ側）の検証は、利用者への即時フィードバックが目的です。送信前に「メールアドレスの形式が違います」と示せば、往復の待ち時間なく直せます。ただしブラウザ側の検証は、開発者ツールやAPIの直接呼び出しで容易に迂回できる点が弱点です。したがってデータの正しさを担保する責任は、サーバーサイドの検証が負います。実装の原則はこうです。フロントは体験のために「親切に」検証し、サーバーは安全のために「必ず」検証する。両者で同じルールを持つ二重化は、冗長ではなく設計として正しい形です。
- フロント：入力中・送信前に即時チェックし、利用者に修正を促す
- サーバー：受信した全データを再検証し、通らなければ処理を拒否する
- DB制約：一意性やNOT NULLなど、最終防衛線を型・制約で担保する
この三段で、体験の良さとデータの正しさを両立させます。入力欄をどこまで絞り込むと離脱が減るかという観点は、EFO（入力フォームの離脱を止める改善施策）の考え方と地続きで、検証メッセージの出し方はフォーム改善の一部でもあります。
サーバーサイド検証を最後の砦とする入力検証のセキュリティ観点
サーバーサイド検証を必須とする最大の理由は、セキュリティです。検証を通らない値をそのまま処理すると、SQLインジェクションやクロスサイトスクリプティング（XSS）といった攻撃の入口になります。ここで押さえるのは、許可する値を定義して合致しないものを弾く「許可リスト方式」を基本にすることです。危険な文字だけを除く「拒否リスト方式」は、想定外のパターンをすり抜けやすいうえ、O'Brianのような正当な入力まで巻き込んで弾いてしまう欠点があります。
ただし、入力検証だけで攻撃を止められると考えるのは誤りです。前掲のOWASPのチートシートは、入力検証はインジェクションやXSSの第一の防御ではなく補完的な位置づけであり、出力先の文脈に応じたエスケープ（HTMLなら<script>を<script>へ変換するなど）が主たる対策だと明記しています。OWASP Top 10のA03 Injectionも、防御の筆頭にパラメータ化クエリなどAPIレベルの分離を挙げ、入力検証はその次に置いています。国内向けの実装指針としては、IPAの安全なウェブサイトの作り方が届出のあった脆弱性をもとに対策を整理しており、根拠として参照しやすい資料です。攻撃種別ごとに入力検証がどこまで効くかの線引きと許可リストの組み立て手順は入力バリデーションで防げる攻撃の範囲と許可リスト設計に、XSSとCSRFの守り方の違いはXSSとCSRFの違いと実装レベルの対策にまとめました。
バリデーションを実装する手順：HTML属性・スキーマ・サーバー検証を書く
ここからは実際に動く形で書きます。題材は「メールアドレス・数量・郵便番号・利用期間」を受け取る注文フォームです。フロントで即時に弾き、サーバーで再検証し、失敗した項目をまとめて返すところまでを、三つの断片で追います。
HTMLの制約検証属性とcheckValidityでフロント側の入力チェックを書く
ブラウザには標準の制約検証（Constraint Validation）が備わっており、追加ライブラリなしで単項目チェックを書ける仕組みです。MDNのConstraint Validationのガイドによれば、使える属性はrequired・pattern・min・max・minlength・maxlength・stepで、違反の内訳はvalidity.valueMissingやvalidity.patternMismatchといったプロパティで判別できます。まずマークアップ側を書きます。
<form id="order" novalidate>
<input type="email" name="email" required maxlength="254">
<input type="number" name="quantity" required min="1" max="99" step="1">
<input type="text" name="zip" required pattern="[0-9]{7}">
<input type="date" name="startsOn" required>
<input type="date" name="endsOn" required>
<button type="submit">注文する</button>
</form>novalidateを付けているのは、ブラウザ既定の吹き出しを止めて表示を自前で組み立てるためです。判定そのものは属性が担い続けるので、次のスクリプトで送信時にまとめて拾います。setCustomValidity()に空文字を渡すと違反状態が解除される仕様なので、判定のたびに必ずリセットしてから設定します。
const form = document.getElementById("order");
form.addEventListener("submit", (e) => {
const zip = form.elements.zip;
zip.setCustomValidity("");
if (zip.validity.patternMismatch) {
zip.setCustomValidity("郵便番号はハイフンなしの数字7桁で入力してください");
}
if (!form.checkValidity()) {
e.preventDefault();
form.reportValidity();
}
});この時点で守れているのは体験だけです。属性もスクリプトも開発者ツールから書き換えられるため、同じ条件をサーバー側にもう一度置きます。
Zodのスキーマ定義とsafeParseでサーバー側の入力検証を実装する
TypeScriptのサーバーでは、スキーマ定義ライブラリで受信データを丸ごと検証する書き方が扱いやすい形です。Zodは2026年9月時点で4系が安定版として案内されており、z.email()やz.iso.date()のようにフォーマットを直接呼び出せます。相関チェックはrefine()で足せます。
import * as z from "zod";
const OrderSchema = z.object({
email: z.email(),
quantity: z.number().int().min(1).max(99),
zip: z.string().regex(/^[0-9]{7}$/),
startsOn: z.iso.date(),
endsOn: z.iso.date(),
}).refine((v) => v.startsOn <= v.endsOn, {
message: "開始日は終了日以前にしてください",
path: ["startsOn"],
});
const result = OrderSchema.safeParse(await req.json());
if (!result.success) {
return problemResponse(result.error.issues);
}
const order = result.data;parse()ではなくsafeParse()を使うと、失敗が例外ではなくsuccess: falseの戻り値になり、error.issuesに違反の配列が入る仕組みです。各要素は違反した位置（path）とメッセージを持つので、そのままレスポンスへ組み替えられます。ライブラリ単体の入り口としてはZodの導入と基本的な書き方にまとめてあります。在庫数の照合のようにDBを参照する意味的検証は、ここではなくサービス層に置き、スキーマは形と範囲の判定に絞ると責務が混ざりません。
検証エラーをRFC 9457のproblem+jsonで項目ごとに返す実装
返し方は独自に決める必要がなく、利用できる既製の仕様があります。RFC 9457はエラー応答のメディアタイプとしてapplication/problem+jsonを定め、type・title・status・detailという共通メンバーを示しています。同じ種類の違反が複数ある場合はerrorsのような拡張メンバーに配列で並べ、位置をJSONポインタで指す例が仕様本文に掲載済みです。それに沿うと応答はこうなります。
HTTP/1.1 422 Unprocessable Content
Content-Type: application/problem+json
{
"type": "https://example.com/probs/validation-error",
"title": "入力値が条件を満たしていません",
"status": 422,
"errors": [
{ "detail": "数量は1以上99以下で指定してください", "pointer": "#/quantity" },
{ "detail": "開始日は終了日以前にしてください", "pointer": "#/startsOn" }
]
}ステータスコードは、構文として解釈できない要求なら400、形式は読めるが内容が条件を満たさないなら422を選ぶのが素直な割り当てです。どちらもRFC 9110（HTTP Semantics）が定義しており、422はUnprocessable Contentとして規定されています。チーム内でどちらに寄せるかを先に決め、APIのエラー設計として文書化しておくと実装がぶれません。URIの切り方や冪等性を含めた設計判断はREST API設計のレビュー基準に整理しています。
バリデーションの実装パターン：宣言的検証とカスタム検証の使い分け
実装は、フレームワークが用意した仕組みを基本線に置くのが保守の観点で有利です。検証ルールをコードのあちこちに散らすと、仕様変更のたびに漏れが生まれます。宣言的に一箇所へ集め、表せない業務判断だけを個別実装で補います。
宣言的バリデーション（アノテーション・スキーマ）の実装と集約
多くのフレームワークは、検証ルールを宣言的に書く仕組みを持っています。Javaでは@NotNullや@Sizeといったアノテーションをフィールドに付ける方式が標準化されており、その仕様は3.1系で名称がBean ValidationからJakarta Validationへ改められました。仕様ページによれば3.1はJakarta EE 11向けで、Java SE 17以上を前提とし、レコード型の扱いを明確化したリリースだと記載されています。Spring側の組み込み方はSpring Frameworkのリファレンスが扱っており、当社の解説ではアノテーションを使ったバリデーションの実装が具体像をつかむ参考になります。
PHPならLaravelのバリデーションが同じ発想で、ルールを配列やFormRequestに宣言して集約します。実務での書き分けはLaravelのFormRequestとカスタムルールにまとめました。言語をまたいで同じ検証条件を共有したいときは、JSON Schemaのように仕様が公開された記述形式へ外部化する手もあり、その書き方はJSON Schemaで検証条件を外部化する書き方で扱っています。まず宣言的に書ける範囲を最大限に広げ、残りをカスタム検証で補うのが基本方針です。
カスタム検証と、エラーメッセージ返却・例外処理を含む実装の設計方針
宣言的に表せないのは、DB照合や複数項目の業務判断です。ここはカスタムの検証ロジックを書きますが、検証層は「判定するだけ」に留め、業務処理と混ぜないほうが後で読みやすくなります。検証に失敗したときの返し方も設計対象です。エラーは項目ごとにまとめて返し、利用者が一度に直せる形が基本になります。一項目ずつ弾いて再送信を繰り返させる作りは、体験を大きく損ないます。APIであれば、前節のproblem+jsonのように、どのフィールドがどの理由で失敗したかを構造化したレスポンスで返すのが実務的です。例外を投げるか結果オブジェクトで返すかは言語の流儀に合わせ、チーム内で統一します。
バリデーションをテストで担保する設計と、過剰検証を見送る判断基準
検証ルールは書いただけでは信用できません。ルール自体にバグがあれば、素通りする値や、正しい値を弾く誤検知が起こります。ここで取る立場は明快です。バリデーションは、境界値と異常系のテストとセットで初めて品質になります。そして、すべてを検証すればよいわけでもありません。
境界値・異常系をテストで担保する範囲選定と、回帰不具合の防止
バリデーションのテストで最初に狙うのは境界値です。桁数上限が10なら、9・10・11を確かめます。0件・1件・空文字・全角混在・想定外の型といった異常系も、正常系と同じ比重で並べるのが要点です。検証ルールは仕様変更で頻繁に触るため、一度書いたテストが将来の変更で壊れていないかを継続的に確かめるリグレッションテストによる回帰の防止が効きます。どのレベルのテストにどれだけ配分するかは、テストピラミッドに基づくテスト配分の考え方が指針になります。バリデーションは大半が単体テストで安く広く固められる領域で、費用対効果の高いテスト対象です。
受託開発における入力検証の設計品質と、第三者によるレビュー体制
入力検証の抜けは、稼働後に不正データや障害という形で表面化します。とくに外部に開発を委託した成果物や、担当者が入れ替わりながら保守するシステムでは、検証がフロントだけで済まされていないか、許可リスト方式になっているかを客観的に確かめる価値が大きい領域です。検証ロジックの妥当性は、実装者以外の目でコードレビューの観点に沿った確認を通すと抜けが見つかりやすくなります。一創ではシステム保守運用・内製化支援として、既存システムの入力検証やセキュリティ観点を含むコード品質評価と、レビュー体制づくりの伴走を行っています。
あらゆる項目を検証しない：過剰なバリデーションを見送る判断条件
検証は多いほど安全とは限りません。内部システムだけが呼ぶ管理用APIで、値の生成元がシステム内に閉じているなら、外部入力と同じ厳格さは過剰になり得ます。表示専用で後続処理に渡らない項目に複雑な業務ルール検証を積むのも、保守コストに見合いません。判断基準はこうです。その値が信頼できない経路（利用者・外部システム）から来るか、そして検証漏れがデータ不整合やセキュリティ事故につながるか。両方が「はい」なら厳格に検証し、そうでなければ軽くする。「全項目に一律で最大限の検証」ではなく、リスクの重みで濃淡をつける設計が現実に即します。この入力検証は、システム開発のテスト工程全体の中での品質保証の一部として位置づけると、どこまでやるかの線引きがぶれにくくなります。
よくある質問
バリデーションの実装でつまずきやすい点を、6つの質問に絞って整理します。
バリデーションとサニタイズ（無害化）の違いは何ですか？
バリデーションは入力値が条件を満たすかを判定し、満たさなければ処理を拒否する行為です。サニタイズは、受け取った値から危険な要素を除去・変換して安全な形に整える処理です。判定して弾くのが検証、加工して安全にするのが無害化で、目的が異なります。OWASPのチートシートも、入力検証はインジェクション対策の補完であり、出力先の文脈に応じたエスケープが主たる防御だと述べています。
フロントエンドだけでバリデーションすれば十分ではないですか？
不十分です。ブラウザ側の検証は開発者ツールやAPIの直接呼び出しで容易に迂回できるため、データの正しさを保証できません。フロントは利用者への即時フィードバックが目的で、正しさの担保はサーバーサイドの検証が負います。同じルールを両方に持つ二重化が、体験と安全の両立につながります。
バリデーションのエラーメッセージはどう返すのが良いですか？
項目ごとにまとめて返し、利用者が一度に修正できる形が基本です。一項目ずつ弾いて再送信を繰り返させる作りは体験を損ないます。APIの場合は、RFC 9457のproblem+jsonのように、どのフィールドがどの理由で失敗したかを構造化したレスポンスにすると、フロント側で表示を組み立てやすくなります。メッセージは、何をどう直せばよいかが伝わる具体的な文言が望ましいです。
バリデーションエラーのHTTPステータスは400と422のどちらですか？
JSONとして解析できないなど構文が壊れている要求には400を、形式は読めるが値が条件を満たさない場合には422（Unprocessable Content）を返す割り当てが素直です。どちらもRFC 9110で定義されています。ただし422を扱わないクライアントもあるため、公開APIでは400に寄せる判断もあり得ます。混在が一番読みにくいので、チームで一方に決めて文書化してください。
バリデーションはどこの層に実装するのが正しいですか？
単一の層に寄せず、フロント・サーバー・DB制約の多層で持ちます。フロントは即時フィードバック、サーバーは正しさとセキュリティの担保、DBは一意性やNOT NULLといった最終防衛線という役割分担です。中核となる業務ルールの検証はサーバーサイドに集約し、外部から来る値は必ずサーバーで再検証します。
正規表現によるバリデーションで注意すべき点はありますか？
複雑すぎる正規表現は、可読性が下がるうえ、極端な入力で処理が異常に遅くなるReDoS（正規表現によるサービス拒否）の原因になることがあります。仕組みと回避策はReDoSの解説にまとめました。メールアドレスなどは過度に厳密な表現を目指さず、実用的な範囲に留めるのが安全です。書式チェックは正規表現で行い、値の範囲や業務ルールは別途コードで判定する、と役割を分けると保守しやすくなります。
関連記事
- 入力バリデーションとは：防げる攻撃の範囲と許可リスト設計を実装目線で整理
- JSON Schemaとは：検証条件を言語非依存の記述形式へ外部化する書き方
- Zodの使い方入門：TypeScriptでスキーマ検証を導入する手順と基本構文
- REST API設計のベストプラクティス：エラー応答と冪等性のレビュー基準
- システム開発のテスト：バリデーションを含む品質保証をテスト工程全体で捉える
- テストピラミッドとは：検証ルールを単体テストで安く広く固めるテスト配分
- リグレッションテストとは：仕様変更で検証ルールが壊れていないかを担保する
- コードレビューとは：入力検証の抜けを実装者以外の目で確認するレビュー観点
- Springのバリデーション実装：アノテーションを使った宣言的検証の具体像
