開発あるある「CSV地獄」
― Excelが勝手にデータを壊す問題と対策

1Excelの「親切」がデータを壊すメカニズム

ExcelでCSVファイルを開くと、Excelは各セルのデータを見て「これは数値だな」「これは日付だな」と自動的に判断し、表示形式を変換します。この判断は人間にとっては便利なこともありますが、CSVデータにとっては余計なお世話です。

問題の本質は、Excelがデータを「表示」するだけでなく、内部的な「値」そのものを書き換えてしまうことにあります。

表示形式を「文字列」に戻しても、すでに失われた先頭のゼロは復元できません。Excelが内部で保持しているのは数値の「312345678」であり、元の「0312345678」という文字列はCSVを開いた瞬間に消えています。

CSVはただのテキストファイルです。「型」という概念がありません。すべてのデータは文字列として保存されています。しかしExcelは「中身を見て型を推測する」という設計思想で動いているため、CSVとExcelは根本的に相性が悪いのです。

2被害パターン別 ― こうしてデータは壊れる

Excelの自動変換によるデータ破壊には、いくつかの典型的なパターンがあります。EC業務で特に被害が大きいものから順に見ていきましょう。

パターン1：長い数字が指数表記になる

最も被害が大きく、最も気づきにくいパターンです。Excelは12桁以上の数字を指数表記（科学的記数法）に変換します。

データの種類	CSVの元データ	Excelで開いた結果
JANコード（13桁）	4901234567890	4.90123E+12
ISBNコード（13桁）	9784123456789	9.78412E+12
注文番号（長い数字）	20260402153045001	2.02604E+16
Amazon注文ID	503-1234567-8901234	そのまま表示（ハイフンあり）

さらに厄介なのは、表示形式を「数値」に変えても元に戻らないことです。Excelは内部的に浮動小数点数として値を保持しているため、15桁を超える部分は精度が失われます。

パターン2：先頭のゼロが消える

Excelは数字だけで構成されたデータを「数値」と判断するため、先頭のゼロを不要な桁として削除します。

データの種類	CSVの元データ	Excelで開いた結果
郵便番号	0120045	120045
電話番号	09012345678	9012345678
商品コード	00456	456
SKU	001-A-0023	そのまま表示（記号を含むため）

先頭ゼロの消失は一見地味ですが、郵便番号や電話番号が壊れると配送事故に直結します。「0120045」が「120045」になれば、正しい郵便番号として認識されず、荷物が届きません。

パターン3：日付に勝手に変換される

Excelは「日付っぽい文字列」を見つけると、日付型に変換します。この判定が意外なほど広範囲です。

CSVの元データ	Excelの解釈	表示結果
1-2	1月2日	1月2日 または Jan-02
3/4	3月4日	3月4日 または Mar-04
2026-04	2026年4月	Apr-26
12E3	数値 12000	12000

商品のサイズ表記「S-1」「M-2」「L-3」のうち、「M-2」だけが日付の「2月」に変換されたという事故も実際に起きています。特定のデータだけ壊れるため、目視チェックでは気づきにくいのが厄介です。

パターン4：数値の精度が失われる

Excelが扱える有効桁数は最大15桁です。16桁以上の数値は、下位の桁が0に丸められます。

クレジットカード番号（16桁）、一部のモールの注文番号、商品管理番号など、15桁を超える数字のIDは全て影響を受ける可能性があります。

3EC実務で実際に起きる事故

前章のパターンが、EC業務の現場ではどのような事故につながるのか。実際によくあるシナリオを見ていきます。

事故1：JANコードの破壊 → 商品マスタ不一致

モールから商品データをCSVでダウンロードし、Excelで価格を修正して再アップロード。このときJANコードが指数表記のまま保存されると、モール側で「該当商品なし」のエラーになります。

さらに怖いのは、エラーにならず通ってしまうケースです。Excelが丸めた値がたまたま別の商品のJANコードと一致した場合、意図しない商品の情報が上書きされる可能性があります。

事故2：郵便番号・電話番号の破壊 → 配送事故

受注データをCSVで出力し、Excelで確認・加工して配送業者のシステムに取り込む運用。このフローで郵便番号の先頭ゼロが消えると、配送先が正しく認識されません。

• 「0120045」→「120045」 ―― 7桁から6桁になり、配送システムの取り込みでエラー
• 「0980001」→「980001」 ―― 北海道の郵便番号の先頭ゼロが消えると、該当なしになる
• 電話番号「09012345678」→「9012345678」 ―― 配送ドライバーが連絡できない

事故3：商品一括更新でのデータ混在

楽天やYahoo!ショッピングの商品一括更新では、CSVで数百〜数千行のデータを一度に更新します。このとき、一部の行だけデータが壊れている状態が最も危険です。

1,000行のCSVで5行だけデータが壊れていても、目視では見つけられません。「価格を直しただけなのに、なぜかJANコードのエラーが出る」というのは、まさにこのパターンです。

事故4：在庫連携CSVの数値化 → 在庫数の誤り

複数モール間の在庫を同期するためにCSVを使っている場合、商品コードが壊れると在庫数が別の商品に紐づく事故が起きます。

• 商品コード「00123」の在庫50個 → Excelで「123」に変換される
• 別に「123」という商品コードが存在していた場合 → その商品の在庫が50個に上書きされる
• 元の「00123」の在庫は更新されない → 在庫切れなのに購入可能な状態が続く

4今日からできる回避策

完全な解決は「仕組み化」が必要ですが、今すぐ実践できる回避策もあります。Excel、Googleスプレッドシート、それぞれの方法を紹介します。

対策1：Excelの「テキストファイルウィザード」を使う

CSVをダブルクリックで開くのではなく、Excelの「データ」タブ → 「テキストファイルから」で取り込む方法です。この方法なら、各列のデータ型を「文字列」に指定してから読み込めます。

1. Excelを開き、「データ」タブ → 「テキスト/CSVから」を選択
2. CSVファイルを指定
3. プレビューで列のデータ型を確認
4. 数字系の列（JANコード、電話番号、郵便番号など）を「テキスト」に変更
5. 「読み込み」をクリック

対策2：CSVを直接編集できるツールを使う

Excel以外のツールでCSVを開けば、自動変換の問題を回避できます。

• Visual Studio Code（VS Code） ―― 無料のテキストエディタ。CSVをテキストとしてそのまま表示・編集できる。拡張機能「Rainbow CSV」を入れると列ごとに色分けされて見やすい
• サクラエディタ / 秀丸エディタ ―― Windows向けのテキストエディタ。CSVをテキストとして安全に開ける
• LibreOffice Calc ―― 無料の表計算ソフト。CSVを開くときに列の型を指定するダイアログが必ず表示される（Excelのようにいきなり変換されない）

対策3：CSVを保存するときのルール

Excelで加工した後にCSVとして保存する場合にも注意が必要です。

• 「名前を付けて保存」で「CSV UTF-8（コンマ区切り）」を選ぶ ―― 「CSV（コンマ区切り）」だとShift_JISになる
• 保存後に、テキストエディタで内容を確認する ―― 指数表記や先頭ゼロの消失がないかチェック
• 元のCSVファイルは必ずバックアップを取る ―― 上書き保存で壊れた場合の復旧用

5Googleスプレッドシートなら安全？ ― 別の落とし穴

「Excelがダメなら、Googleスプレッドシートを使えばいいのでは？」と考える方も多いでしょう。実際、Googleスプレッドシートはいくつかの点でExcelより安全ですが、完全に安全というわけではありません。

Googleスプレッドシートの良い点

• 先頭ゼロの保持が比較的うまくいく ―― ただし、手動で入力した場合のみ。CSVインポートでは条件次第
• 共同編集できるため、CSV受け渡しの必要が減る ―― CSVを介さないフローが組めれば、そもそもCSV問題が起きない

Googleスプレッドシートの落とし穴

• CSVインポート時に自動型変換が発生する場合がある ―― 「自動検出」設定だとExcelと同様の問題が起きる
• CSVとしてダウンロードすると書式情報が失われる ―― スプレッドシート上で「文字列」にしていても、CSV出力すると先頭ゼロが消えることがある
• 日付の自動変換はGoogleスプレッドシートでも起きる ―― 「1-2」が日付になる問題はExcelと同じ
• 大量データ（10万行超）のパフォーマンスが悪い ―― EC業務で扱う大規模CSVでは処理が重くなる

6根本解決は「人がCSVを直接開かない」仕組み

ここまで紹介した回避策は、すべて「人が正しい手順を毎回守る」ことが前提です。しかし現実には、忙しいときに手順を省略する、新しい担当者がルールを知らない、うっかりダブルクリックで開いてしまう――ということが必ず起きます。

CSV地獄の根本解決は、「人がCSVファイルを直接Excelで開く」というステップを業務フローから排除することです。

仕組み化のアプローチ

• 自動変換スクリプト ―― GASやPythonで、CSVの読み込み・加工・出力をプログラムで行う。プログラムはデータ型を正確に制御できるため、勝手な変換は起きない
• 専用ツールの導入 ―― CSVの確認・編集に特化したツール（CSVエディタ）を使う。表計算ソフトの自動変換機能がないため安全
• API連携への移行 ―― モールとのデータ連携をCSV経由からAPI経由に切り替える。データ型が明確に定義されるため、型の推測ミスが原理的に起きない
• 入出力の型チェック機構 ―― CSVを処理する前後で、JANコードの桁数・郵便番号の形式・電話番号の先頭ゼロなどを自動検証する仕組みを組み込む

こうした仕組みを一度構築すれば、担当者がExcelの操作に詳しくなくても、CSVの知識がなくても、データが壊れることはありません。

とはいえ、「どの列を文字列として扱うか」「モールごとのCSV仕様の違い」「エラー時のリカバリー方法」など、仕組みの設計には業務知識と技術知識の両方が必要です。中途半端な自動化は、手動作業よりも厄介な問題を生むことがあります。

もし毎月のCSV業務で「Excelで開いたらデータが壊れた」「アップロードしたらエラーになった」というトラブルが繰り返されているなら、その作業フロー自体を見直す時期かもしれません。