1 入力検証の概要
1.1 入力検証の目的
1.1.1 正しさの担保（形式・範囲・整合性）
入力検証は、外部から渡される情報がシステムの期待する形に適合することを確認する工程である。具体的には、データ型や書式、許容される長さ、数値の上下限、文字種、複数項目間の整合性などを点検し、不備のある値を処理対象から外す。これにより、後続処理が前提とする条件を満たした入力のみが渡され、計算誤りや状態異常の発生を抑えられる。
1.1.2 障害の回避（誤入力による不具合防止）
誤入力は意図せず発生する。たとえば利用者が桁を誤って入力する、ブラウザや端末が想定外の文字コードを送る、外部システムが古い仕様で値を送信するなどがある。入力検証は、こうしたズレを早い段階で検出し、処理を止める、または安全な形に整えることで、タイムアウトの誘発やデータ破損、整合性破壊といった障害の連鎖を抑止する。
1.1.3 セキュリティ対策としての役割
入力検証はセキュリティ対策の一部として位置づけられる。入力が想定外の構造や長さ、文字列を含む場合、解析・連結・実行の過程で脆弱性が顕在化しうるためである。検証により、危険な形の入力を遮断し、後段の防御（エスケープ、パラメータ化、権限制御など）が効く前提を整える。なお、検証だけで完全な防御になるわけではなく、他の対策と組み合わせて設計する必要がある。
1.2 入力検証の対象範囲
1.2.1 ユーザー入力（フォーム、チャット、ファイル）
ユーザーが入力する情報は多様である。Webフォームではフィールドごとの文字列や選択値、チャットでは自由記述、ファイルではメタデータや中身の形式が対象になる。特にファイルは、拡張子やMIME種別だけで判断せず、内容の特徴やサイズ上限など複数条件で評価するのが一般的である。チャットの自由文は意図を抽出する処理に渡るため、長さや文字種だけでなく、後続で解釈される領域に応じた検証が必要になる。
1.2.2 API入力（クエリ、ヘッダー、ボディ）
APIではクエリパラメータ、ヘッダー、リクエストボディが入力検証の対象となる。クエリやヘッダーは型が曖昧になりやすく、欠落・重複・予期しない形式を含むことがある。ボディはスキーマに基づく検証が重要で、必須項目の有無、型の一致、フィールド間の整合性、許容される文字範囲などを確認する。加えて、パース前のサイズ制限や文字コード制限も設計要素になる。
1.2.3 外部連携入力（連携先、バッチデータ）
外部連携では、受け取る側が送信者の都合を完全には保証できない。連携先が仕様変更後の値を送る、運用ミスで欠損や重複が発生する、バッチ処理が再実行で同一データを送り直すといった事象が起こり得る。したがって、受信時の基本的な妥当性チェックに加え、参照整合や時系列の条件、再送に対する冪等性といった観点も検証設計に含めることが多い。
1.3 検証の基本原則
1.3.1 最小特権の考え方（必要な範囲のみ受け入れる）
検証は「何でも受け入れてから対処する」よりも、「必要な条件を満たすものだけを受ける」方向で設計すると安全性と品質が両立しやすい。許容範囲を狭めるほど意図しないデータの混入を防げる一方で、運用上の例外が増える。したがって、要件に基づき、実際に必要な形式・値域・項目群を明確化し、過剰な寛容さを避ける姿勢が重要となる。
1.3.2 「拒否」か「修正」かの方針
入力を拒否するか、一定の範囲で修正するかは方針として定める必要がある。たとえば前後の空白は利用者利便のために削除することがあるが、数値表現の解釈や文字種の変換は、意図と異なる結果を生む危険がある。修正を行う場合は、変換ルールの明示、変更点の記録、再現性の確保が求められる。拒否する場合は、利用者が誤りを修正できるよう理由を短く具体的に返す。
1.3.3 設計段階での要件化
検証は実装後の付け足しではなく、要件定義の段階で仕様化するべきである。どの入力が必須で、どの型・範囲が許容され、どの組み合わせが成立するかを定義することで、開発者ごとの解釈のブレを減らせる。さらに例外ケースの扱い、エラー応答の形式、ログに残す情報、運用時の変更手順まで含めて決めると、品質が安定する。
2 検証の種類と手法
2.1 形式検証（フォーマット）
2.1.1 データ型の検証
2.1.1.1 数値・日時・文字列・列挙の扱い
型の検証は、文字列として受け取った入力を処理対象の型に安全に変換できるかを確認する工程である。数値は桁の扱い、符号、小数点の有無などを基準に判断し、日時はタイムゾーンや形式の一致を点検する。文字列は許容文字（禁止文字や制御文字の扱い）と長さを確認する。列挙では、選択肢に存在する値のみを受理し、未知のラベルを弾くことで後段の分岐の安全性を高める。
2.1.2 パターン検証（正規表現など）
パターン検証は、入力が特定の形に一致するかを判定する手法である。正規表現は実装の柔軟性が高い一方、複雑な式は誤判定や性能劣化の原因になり得る。設計では「必要最低限の制約で十分か」を見極め、過度な正確さを求めて保守性を落とさない工夫が重要になる。パターン検証は、型変換や長さ検証と併用することで堅牢性が上がる。
2.1.3 エンコード・文字種の検証
エンコードの検証では、受信したデータが期待する文字コードに解釈可能かを確認する。文字種（例：半角英数字のみ、特定のUnicode範囲のみなど）も形式の一部として扱える。誤った解釈は文字化けだけでなく、比較や正規化の結果の違いにもつながる。したがって、データ境界での文字コード取り扱い方針を明確にし、変換が必要な場合はルールを固定して運用する。
2.2 範囲・制約の検証
2.2.1 長さ制限（桁数、文字数、バイト数）
長さ制限は、過大入力による負荷や保存領域の枯渇、想定外の切り詰めを防ぐ。文字数制限とバイト数制限は意味が異なるため、対象がUnicodeの場合は注意が必要である。桁数の上限は数値処理の安全性に直結し、たとえば金額や識別番号では桁の変化を許さない設計が多い。長さ制限は最も基本的であるが、実装漏れが起きやすい点でもある。
2.2.2 値の上限下限（数値、期間、頻度）
数値の上下限、期間の範囲、繰り返し頻度の上限などは、ビジネス上の前提に密接である。たとえば割引率や有効期限、アクセス回数などの条件が破られると、計算の破綻や不正利用の誘発につながる。境界値（最小や最大）を含めるのか、厳密に超過した場合は拒否するのかといった仕様を明確化し、実装とテストで一致させる。
2.2.3 相関制約（複数項目の整合）
相関制約は、単一項目では正しく見えても、組み合わせによって成立しないケースを検出する。たとえば開始日時が終了日時より後である、数量と単価が整合しない、Aの指定がある場合Bが必須になるなどが典型である。相関検証はエラー理由の説明が難しくなりやすいため、どの組み合わせ条件に違反したかを整理して返す設計が望ましい。
2.3 意味検証（ビジネスルール）
2.3.1 状態遷移の整合（申請・承認など）
意味検証の一例として状態遷移の整合がある。申請、審査、承認、却下といったライフサイクルに対し、許可される遷移のみを受理する。入力の値だけでなく、現在の状態や権限も踏まえて妥当性を判断する必要がある。これにより、順序を飛ばした更新や、許可されない段階での操作を防ぐ効果がある。
2.3.2 存在確認（参照整合性）
参照整合性では、入力された参照IDが実在すること、参照先が有効な状態であることを確認する。欠落や不正なIDはもちろん、論理削除された対象や期間外の対象も不正として扱うことがある。存在確認は外部I/Oを伴うことが多いため、性能と整合性のバランスを考慮し、キャッシュやインデックス、トランザクション境界を設計する。
2.3.3 禁止条件（利用不可状態）
意味検証には「利用してはいけない条件」の判定が含まれる。たとえば凍結ユーザー、停止中の機能、締め処理後の編集、特定期間の取引不可などである。ここでは入力値の正しさだけでなく、環境や運用状況を含めた条件を評価する。禁止条件の一覧化と更新手順を用意し、恣意的な判断を減らすことが品質につながる。
3 実装設計
3.1 検証の実行場所（層）
3.1.1 クライアント側検証
クライアント側検証は利用者の手戻りを減らす目的で導入される。送信前に形式の誤りを検知できるため、体験が改善する。ただしクライアント側の検証は改ざんされ得るため、最終的な正当性の根拠にはしない。実運用では、サーバー側の検証と整合するようルールを設計し、可能なら共有可能な定義を工夫する。
3.1.2 サーバー側検証
サーバー側検証は最も重要な防衛線である。入力の最終受け入れを担当し、型変換、長さ、範囲、相関、参照整合まで含めて判断する。クライアントの挙動に依存しないため、外部からの任意リクエストにも耐えられる。さらに、検証失敗時の応答形式やログ出力を一貫させることで、運用時の調査効率が上がる。
3.1.3 データベース側制約
データベース側制約は「二重の安全策」として位置づけられる。チェック制約、外部キー、ユニーク制約、型や桁の制限などが該当する。アプリ側で検証していても、並行処理やバッチの経路では漏れが生じる可能性があるため、最終的な整合性の砦になる。ただし、エラー応答の可読性はアプリ側で制御した方が良い場合が多く、責務分担を考えて設計する。
3.2 検証ルールの設計
3.2.1 ルールの分解と再利用
検証ルールは大きな単位で一括実装すると変更が困難になる。そこで、型判定、長さ、パターン、範囲、正規化などを小さな部品に分け、再利用可能にする。これにより、同種の入力（例：複数フォームで同じメール形式）に対して一貫した挙動を提供できる。変更時には該当部品のみを更新でき、影響範囲を見積もりやすい。
3.2.2 エラーメッセージ方針
エラーメッセージは、利用者にとっての修正可能性と、運用者にとっての診断性の両立が必要である。ユーザー向けには、どの入力が何に違反したかを簡潔に示す。一方で、内部情報や詳細なスタックトレースは不用意に返さない。言語や形式が統一されるほど、自動化されたクライアントや支援機能でも扱いやすくなる。
3.2.3 ローカライズと入力形式の工夫
多言語環境では、数値表記、日付表現、全角半角などが違いとして現れる。ローカライズでは表示言語だけでなく入力補助も含めて設計する必要がある。たとえば日付は入力ウィジェットにより構造化できる場合があるし、文字種の混在を避けるガイドも有効である。形式の工夫は誤入力を減らし、結果として検証の負荷も下げられる。
3.3 正規化（ノーマライゼーション）
3.3.1 表記ゆれの統一（例：全角半角）
正規化は、同じ意味を持つ表記の差を吸収するために行う。代表例として全角と半角の差がある。識別子や検索キーなどでは表記ゆれを揃えることで、同一性判定の一貫性が増す。ただし、変換が本来の意味を損なう可能性がある領域では慎重さが要る。どこまでを自動補正するかを定め、結果をログで追えるようにするのが望ましい。
3.3.2 大文字小文字・区切りの統一
アルファベットの大小、区切り記号（ハイフンやスペースの扱い）なども正規化の対象になり得る。たとえばメールアドレスの一部は大小の扱いが意味を持たないことがあるため、仕様に基づいて統一する。区切りの挿入は視認性のために行われることが多いので、保存や比較の前に削除・統一すると後段の処理が単純になる。
3.3.3 トリム、空白、改行の扱い
前後の空白や連続する空白、改行コードの差は、比較や保存に影響を与えやすい。通常は前後のトリムを行い、内部空白は仕様に応じて扱いを決める。改行をそのまま保持する必要がある入力（自由文）では、サニタイズや長さ制限と整合させて設計する。正規化のタイミングは検証の前段に置き、判定の基準を一貫させる。
4 セキュリティとの関係
4.1 注入攻撃と検証の関係
4.1.1 SQLインジェクション対策の考え方
SQLインジェクションの防止では、入力検証は「補助線」として機能する。主防御は、パラメータ化クエリやプリペアドステートメント、適切な型拘束などである。検証は、異常な構造や極端に長い文字列などを弾くことで攻撃の成立可能性を下げる。ただし「危険文字をブラックリストで除去すれば安全」といった単純化は避け、データの扱いの責務を分けることが重要になる。
4.1.2 コマンドインジェクションの回避
コマンドインジェクションでは、外部コマンドの組み立てやシェル解釈が危険源になる。入力検証は、許容するコマンド引数の形式を絞り、パス区切りや制御文字、エスケープに関わる文字を規定することでリスクを下げられる。加えて、可能ならシェルを介さないAPIを使い、引数を分離して渡す設計が望ましい。検証は単独では不十分であり、実行機構の安全性確保とセットで考える。
4.1.3 ファイル操作関連の危険回避
ファイル操作では、パス指定の誤りが想定外の読み書きにつながることがある。入力検証では、ファイル名やディレクトリの形式、許容する拡張子、サイズ、文字種などを制限する。さらに参照先のルートディレクトリに対する相対位置の検証（パスの正規化と逸脱チェック）を組み合わせることで、パストラバーサルのような問題を抑制しやすい。単なる拡張子チェックだけでは不十分になりやすい。
4.2 典型的な落とし穴
4.2.1 「クライアントだけ検証」問題
クライアント側のチェックのみで安全性を担保しようとすると、改ざんや別クライアントからの入力により検証が無効化される。結果として、サーバーでは想定外の値が処理され、例外や保存破損につながる。対策として、サーバー側で同等の制約を適用し、入力経路が複数ある場合はそれらに共通の検証層を確保する必要がある。
4.2.2 ブラックリスト依存のリスク
ブラックリスト方式は、攻撃のバリエーションが増えるにつれて対応不能になりやすい。表面上の危険文字を除去しても、別の解釈経路やエンコード差異により脆弱性が残ることがある。より望ましいのは、許容パターン（ホワイトリスト）に基づく形式検証や、型・範囲・構造の制約を明確にするアプローチである。
4.2.3 桁あふれ・型変換の事故
型変換の事故は、検証の欠落よりも「一見正しく見えるが値が変化する」形で起こる。たとえば大きすぎる数値が暗黙に別の型へ変換されて桁あふれが発生する、浮動小数への変換で精度が失われるなどである。検証では、変換の前後で値が一致するか、上限下限の基準が型の範囲内に収まるかを確認することが重要になる。
4.3 出力との連携（誤解を防ぐ）
4.3.1 検証とエスケープの役割分担
入力検証は「入力が期待通りか」を確認する作業であり、出力エスケープは「表示や解釈の文脈で安全に扱うための変換」である。両者は目的が異なるため、検証ですべてを解決しようとすると誤解が生まれる。たとえば検証で許可した文字列でも、HTMLやSQLなど出力先の文脈によって危険になり得る。したがって、検証とエスケープは別責務として設計し、同じ前提で扱い続けることが重要である。
4.3.2 コンテキスト依存の扱い
安全性はコンテキストに依存する。同じ文字列でも、HTML中、URL中、ログ中、コマンド引数中では処理が異なるため、必要な対策も変わる。入力検証は共通部品として組み込めるが、出力時の変換やエスケープは文脈ごとに切り替える必要がある。設計では「どこで何が保証されるか」を明確にし、誤った適用を防ぐ。
5 エラーハンドリングとユーザー体験
5.1 エラーの分類と返却設計
5.1.1 妥当性エラー（バリデーション）
妥当性エラーは、入力が仕様に適合しないことによって発生する。返却設計では、どの項目が不正か、どの条件を満たせていないかを伝える。システム側でのログには具体的な値や判定結果の要約を残しつつ、ユーザーに対しては過度な技術情報を避ける。エラーコードとメッセージを対応付けることで、クライアント側の挙動も安定する。
5.1.2 システムエラー（例外、タイムアウト）
システムエラーは、入力自体に起因しない障害である。例外やタイムアウト、依存サービスの不調などが該当する。ここでは、ユーザーに対して「一時的な問題」や「再試行」を促す設計が一般的である。内部情報の漏えいを避けるため、詳細はログに留め、表面上の説明は短くする。判定不能な場合に妥当性エラーとして扱わないよう区別も必要となる。
5.1.3 再試行可能性の表示
再試行可能性は、ユーザーが次に取る行動に直結する。ネットワーク切断や一時的な混雑など、再実行で改善する可能性がある場合は、その旨を示す。一方で形式不備のように再試行しても変わらない場合は、入力修正を促す。結果として、無駄な再送やサポート負荷を抑える効果がある。
5.2 フィードバック設計
5.2.1 フィールド単位の指摘
フィールド単位で指摘することで、修正箇所が明確になる。複数の不備があるときは、優先順位をつけて主要な違反から提示する設計が有効である。入力の見落としが起きるとユーザーの手戻りが増えるため、UIとAPIの両方で整合したエラー表現にすることが望ましい。
5.2.2 具体例の提示（サンプル入力）
具体例は理解を助ける。たとえば形式エラーでは、期待する形のサンプルを短く示す。誤りの種類によって例を変えると学習効果が高い。例示はガイドとして機能するが、過度に長い説明や大量のバリエーションを出すと逆効果になるため、最小限の提示に留める。
5.2.3 ユーザーの入力支援（オート補完など）
入力支援は検証の前段で誤りを減らす。候補提示、入力補完、選択式への置換などが代表である。自由入力を完全に排除できない場合でも、可能な領域だけ構造化することでエラー率を下げられる。支援があるほど検証ルールもシンプルにできるため、設計全体の整合が重要になる。
5.3 ユーモアを含む注意（軽い配慮）
5.3.1 断り方のトーン調整
軽いユーモアは緊張を和らげるが、誤りの重大さや対象の状況と調和させる必要がある。たとえば個人情報に関わる入力でふざけた表現をすると不信感につながる。トーンは控えめにし、根幹は「何が必要か」を伝えることに置くと、配慮と有効性を両立しやすい。
5.3.2 過度な煽りを避けるガイド
煽りや罰のような表現はユーザーの行動を乱す可能性がある。入力ミスの指摘は事務的に、ただし一言の配慮を添える程度が安全である。メッセージの目的を、責めることではなく修正可能性を高めることに置き続けると、運用上のトラブルも減る。
6 テストと品質保証
6.1 テスト観点
6.1.1 境界値テスト（最小・最大・1差）
境界値テストは検証の要点を効率良く確認する。最小値・最大値・それぞれの1差、空値、長さの上限超過などを系統的に用意する。境界条件は実装の分岐が増えやすいため、ここでの不一致が品質低下に直結する。テストデータは仕様書と一致するよう管理する必要がある。
6.1.2 正常系・異常系の網羅
正常系は許容される入力が期待通り処理されるかを確認する。異常系は不正な形や範囲、欠落に対して適切なエラーが返るかを確認する。特に異常系は、エラー分類（妥当性かシステムか）を含めて検証することで、原因切り分けが容易になる。網羅には優先順位をつけつつも、重要な項目から徹底する。
6.1.3 想定外入力（ファジング的発想）
想定外入力は、仕様外の文字列や極端なサイズ、ランダムな組み合わせなどで挙動を探索する発想に基づく。目的はクラッシュや過度な負荷、例外の未処理などを見つけることにある。ファジングは完全網羅を保証しないが、検証ルールの盲点を発見する助けになる。安全な環境で実施し、影響を抑える運用が必要である。
6.2 自動化の考え方
6.2.1 ルールのテストデータ管理
テストデータは読みやすく、更新しやすくすることが重要である。検証ルールごとに入力例と期待結果を対応付け、変更時に差分が追える形にする。データは冗長にせず、ただし境界に関わるケースは欠かさない。可能なら仕様書の表現と同じ粒度で管理する。
6.2.2 回帰テストと影響範囲
回帰テストは、ルール変更による副作用を検出するために行う。変更した検証部品に依存する入力項目、関連するAPI、保存先の制約まで影響範囲を見積もる。影響が広い場合は、優先度の高い経路から段階的に実行する。テストの結果とログの関連付けを整えると、原因究明が速くなる。
6.3 監視・改善
6.3.1 失敗パターンの計測
運用中の失敗は、検証ルールの改善材料になる。エラーの発生率、頻出する違反カテゴリ、特定端末やクライアントの偏りなどを計測する。統計情報から、ルールが厳しすぎるのか、正規化が不十分なのか、説明が不足しているのかを推定できる。個人情報の取り扱いには注意し、集計中心で管理する。
6.3.2 ルールの見直しサイクル
見直しは、仕様の意図を維持しつつ現場の実態に合わせるプロセスである。失敗の増加が短期の仕様変更と同期している場合は原因を切り分ける。改善は段階導入や段階的緩和から始め、効果と副作用を測る。恒常的な運用でルールが磨かれると、エラー率とクレームの双方が減りやすい。
6.3.3 アラートと運用手順
アラートは、検証エラーが急増した際に即座に気づくための仕組みである。たとえば新しいクライアント配布後にエラー率が跳ねた場合などは、原因調査の優先度を上げる。運用手順として、確認すべきログの場所、切り戻し手段、ユーザーへの影響通知の基準を用意すると対応が安定する。
7 運用・保守
7.1 ルール変更の影響管理
7.1.1 後方互換性の扱い
入力検証ルールを強化すると、既存利用者や外部連携が影響を受ける。後方互換性は、緩和期間を設ける、段階的に新ルールへ切り替える、または旧仕様の入力を一定期間だけ許容するなどで確保する。互換性の度合いはビジネス要件とリスクに応じて決める必要がある。
7.1.2 移行期間の設計
移行期間では、どの入力が新旧どちらで解釈されるかを明示し、監視で影響を測る。段階導入は、まず影響の少ない項目から始めたり、一部のクライアントだけ新ルールを適用したりする方法がある。ユーザーへの告知や、外部パートナーへの仕様共有も移行設計の一部として扱う。
7.2 ドキュメント化
7.2.1 検証仕様書の作り方
検証仕様書は、形式、範囲、相関、正規化、エラー応答の内容をまとめた参照資料である。表形式で許容・非許容の条件を明確にすると、実装とテストの一貫性が高まる。加えて、変更履歴と根拠を残すことで、将来の保守時に迷いが減る。仕様書は「実装のための契約」として扱うのが望ましい。
7.2.2 API契約（入力仕様）との整合
API契約は、利用者と提供者の期待を揃える要素である。検証ルールが契約書とずれていると、クライアントが誤った形式を送り続けたり、運用上の問い合わせが増えたりする。契約と検証を同じソースから生成する、あるいは更新時に同時改訂する運用を整えると、齟齬が減る。
7.3 権限・コンテキスト依存検証
7.3.1 ロール別の許容範囲
入力が同じでも、権限やロールによって許容される値が変わる場合がある。たとえば管理者は特定のフィールドを指定でき、一般ユーザーは参照のみといった差が生じる。検証では、権限情報を参照して許容範囲を切り替える。これにより、入力の形式が正しくても不適切な操作が通ることを防げる。
7.3.2 環境別（開発・本番）差分の管理
開発環境と本番環境では、依存サービスの違いやデータ量、ログ方針が異なることがある。検証ルールに環境差が入ると、テストでは通ったのに本番で失敗するような事態が起きやすい。差分は明確に管理し、可能なら検証ルール自体は同一に保つ方針が望ましい。やむを得ない差は文書化し、運用で説明可能な状態にする。
8 参考実装（概念例）
8.1 典型的な検証フロー
8.1.1 受信→正規化→検証→処理
概念例として、受信した入力をまず正規化し、その後で形式と範囲、相関の検証を行う流れがある。正規化により比較基準を揃えることで判定の一貫性が増す。検証が成功した入力だけを処理層に渡し、業務ロジックでは「検証済み」という前提で進めると責務が整理される。失敗した場合は、エラー応答を返して処理を中断する。
8.1.2 エラー収集→応答→ログ記録
検証失敗時は、どのルールに違反したかを収集してから応答を組み立てる。利用者へは項目単位の指摘を返し、運用者向けには相関するリクエスト識別子と失敗カテゴリをログに残す。ログには、必要十分な情報のみを保存し、機密データの露出を避ける。これにより、後日の調査と改善サイクルが回しやすくなる。
8.2 具体例（フォーム入力）
8.2.1 メールアドレス
メールアドレスでは、形式検証として一般的な構造（ユーザー部とドメイン部）を確認する。文字種の制限や長さ上限も合わせて設定し、空白の混入は正規化で除去する方針が取られることが多い。さらに、保存前に比較用の正規化（大小や区切りの扱い）を行うことで、重複判定の安定性が上がる。
8.2.2 パスワード（ルール設計の考え方）
パスワードでは、要求する強度は長さや構成条件で表すが、入力検証の目的は「入力が壊れていないこと」と「受理基準を満たすこと」にある。文字種の禁止や必要条件を過度に複雑にすると、利用者の入力困難を招きやすい。検証では長さの範囲を中心に据え、ログやエラー応答に生の値を含めない運用を徹底する。
8.2.3 数量・日付
数量は整数・小数、桁数、上下限を検証し、必要なら丸めや小数点の扱いを定義する。日付は形式（例：年-月-日の区切り）と現実的な範囲（存在する日付）を確認する。タイムゾーンやロケールにより解釈が変わるため、入力ウィジェットで構造化する、または仕様上の基準（UTC基準など）を明示することで事故を減らせる。
8.3 具体例（API入力）
8.3.1 パラメータの型と範囲
APIでは、必須・任意、型、最小/最大値をスキーマに落として検証する。クエリの文字列は型に変換できること、数値が許容範囲内であることを確認する。範囲検証は整数と小数で基準が異なるため、比較方法を統一する。さらに欠落や重複に対しても、応答の仕様を決めておくとクライアントの実装が安定する。
8.3.2 本文のスキーマ整合
JSONなどの本文では、フィールドの存在、型、列挙値、ネスト構造の整合を確認する。相関制約として、ある項目が指定される場合に別項目が必須になる条件を検証する。スキーマ検証に加え、正規化の有無や配列の長さ上限なども合わせて定義することで、予期しないデータ構造に起因する処理失敗を抑える。
8.3.3 参照IDの存在確認
参照ID（ユーザーID、商品ID、組織IDなど）は、実在性と有効状態を確認する。存在しないIDは妥当性エラーとして扱い、論理削除や期間外のIDは別カテゴリとして表現すると運用がしやすい。確認はトランザクション境界と整合性要件を考慮し、必要ならキャッシュやインデックスで性能を確保する。加えて、権限に基づく参照可否も同時に評価するのが一般的である。