基本情報 2022 サンプル問題 問20：テクノロジ系に関する問題

答えは d「論理チェック」 です。

お店で注文を受けるとき、「注文した日が、入力した日より前か（つじつまが合うか）」を確かめる検査です。「未来の日付で注文されてる！おかしい」みたいなチェックですね。

こういう「意味的におかしくないか」を見るチェックを論理チェックといいます。数字や形式が正しくても、業務ルール上ありえないものを弾くやつです。

👉 覚え方：論理＝つじつまチェック。「注文日 ≦ 入力日」みたいな“常識ルール”を確認するイメージ。

ほかの選択肢：a シーケンスチェック＝順番が正しいか／b 重複チェック＝同じデータが2つないか／c フォーマットチェック＝書式（日付の形 YYYY-MM-DD など）が合ってるか。

なぜこれが正解か

正解は d。論理チェック（logical check）は、データ項目間または業務ルール上の整合性が取れているかを検査するもの。「注文日 ≦ 入力日（営業日であること）」のように、形式は正しくても意味的に妥当でない値を検出する。

各選択肢の解説

• a シーケンスチェック：データが規定の順序（伝票番号の昇順等）で並んでいるかを検査。
• b 重複チェック：同一キーのデータが二重に存在しないかを検査。
• c フォーマットチェック：データの書式（桁数、文字種、日付形式 YYYY-MM-DD 等）が規定どおりかを検査。

覚え方・ひっかけ注意

入力データチェックの代表5種：(1)シーケンスチェック (2)重複チェック (3)フォーマットチェック (4)論理チェック(項目間関係) (5)チェックディジット（誤入力検出用検査数字）。「形式は OK だが業務的に変」を弾くのが論理チェック。範囲チェック（リミットチェック）も論理チェックの一種に分類されることがある。

理論的背景

入力データチェックはバッチ処理時代から続く伝統的な内部統制手法で、入力→処理→出力の各段階で適用される。チェック種別を体系化すると：

| チェック | 目的 | 例 |

|---|---|---|

| 形式（フォーマット） | 書式適合 | 郵便番号 7桁・数値 |

| 範囲（リミット） | 値域 | 年齢 0-150 |

| 重複 | 一意性 | 主キー重複なし |

| シーケンス | 順序 | 伝票番号連番 |

| 論理（関連） | 項目間整合 | 注文日 ≦ 入力日 |

| 照合 | マスタ突合 | 顧客コードが存在 |

| チェックディジット | 入力誤り検出 | ISBN・マイナンバー |

実務での使われ方

• データベース制約：CHECK制約・トリガで論理チェックを実装。`CHECK(order_date <= input_date)` のように宣言的に書ける。
• 入力フォーム：HTML5 の `pattern` 属性、JavaScript バリデーション、サーバサイド再検証（多層防御）。
• ETL/データ品質：DQ（Data Quality）ツール（Talend、Informatica DQ、Great Expectations 等）でルールベース検証。
• 業務システム：仕訳明細の貸借一致、在庫引当の数量整合など、論理チェックは業務エラー検出の核心。

試験での位置づけ

基本情報の経営戦略・システム監査分野で頻出。論理チェックはシステム監査の入力統制でも扱われ、応用情報・システム監査技術者試験では「予防的統制・発見的統制・是正的統制」の文脈で再登場。営業日チェックは祝日マスタや営業日カレンダとの照合が実装上の要点。

選択肢の発展補足

• a シーケンスチェック：磁気テープ時代のバッチ処理で重要。現代では RDBMS の主キー・ソート保証で代替。
• b 重複チェック：UNIQUE 制約、メッセージング系では idempotency key で実装。
• c フォーマットチェック：正規表現（regex）・JSON Schema・OpenAPI Schema が現代的実装。
• 関連概念：Garbage In, Garbage Out（GIGO）の原則から、入力時の徹底チェックが下流の品質を担保する。