ExcelでCSVの先頭ゼロ・日付・指数表記が崩れたときの確認

一番大事なのは、「失われた値は後から推測できない」ことです

もともと 00123 だった値が 123 で保存されてしまうと、そのCSVだけ見ても「0が2個あった」とは分かりません。このチェッカーは変換兆候を探せますが、消えた情報を復元するツールではありません。原本を残す理由がここにあります。

16桁以上の整数は、見た目が整数でも要注意です

Excelの数値精度は15桁が大きな境目です。16桁以上の注文番号・会員番号・JAN系のような値を数値として扱うと、後ろの桁が変わる可能性があります。番号は計算する数字ではなく「識別子」として文字列扱いする方が安全です。

指数表記は、長い番号が数値扱いされたサインになることがあります

1.23457E+15 のような値が出ていたら、長いIDが数値として解釈された可能性があります。表示だけが指数表記でも内部値が保たれている場合はありますが、CSVへ再保存した後は原本との比較が重要です。

日付らしい値は、本当に日付なのかを先に考えます

1-2 や 2026-09-12 は正しい日付かもしれませんし、コード値かもしれません。このツールは「日付らしい」と示すだけで、業務上の日付かどうかまでは判断しません。

例えば、こんな使い方です

商品コード・注文番号・日付候補が混ざるCSVをExcelで手直しした後、アップロード前に一度通します。警告箇所だけ元CSVと見比べれば、全行を目視するより確認範囲をかなり絞れます。

警告が出たら、全部を「壊れた」と決めつけないでください

このチェックは、壊れやすい形を広めに拾うためのものです。16桁の注文番号はリスクですが、最初から文字列として正しく保存されていれば問題ありません。2026-09-12 も、本当に日付列なら正常です。警告は「ここを原本と比べる」という目印として使います。逆に警告0件でも、すでに 00123 → 123 と変わった後なら元のゼロ数は分からないため、原本比較なしで完全性を証明することはできません。

チェック対象は先頭1000データ行までです。巨大CSVで重要列が後半にしかない場合は、別途その範囲を抽出して確認するか、元システム側の型指定も確認してください。