1EC現場で「CSVを開いただけで壊れる」が日常的に起きている
楽天RMSから落とした売上CSV、Amazonセラーセントラルからダウンロードした注文レポート、Yahoo!ショッピングの商品マスタ。ExcelでダブルクリックしてCSVを開いた瞬間、データはもう壊れています。そのまま「上書き保存」をすれば、壊れた状態で確定。元に戻す手段はありません。
EC実務でこの現象に出会わない人は、ほぼいません。具体的には、こんな景色になります。
EC担当者が日常的に遭遇するCSV破壊事例
- JANコード「
4901234567890」が「4.90123E+12」に変わる - 電話番号「
0312345678」の先頭ゼロが消えて「312345678」になる - 商品コード「
05-06」が日付「5月6日」に勝手に変換される - 商品名が文字化けして「
ï½¢」のような記号の羅列になる - 商品説明欄の改行がぐちゃぐちゃになり、全データが1セルに連結される
- セルが「
=SUM(A1:A10)」と書かれた商品名を計算式と解釈して「0」と表示 - 大きな会員番号がいつのまにか丸められて末尾が「
000」になる
これらは全て、Excelが「親切」にデータを解釈しようとした結果起きる現象です。CSVを「壊した」のはExcel側で、ユーザーは何もしていません。そしてもっと恐ろしいのは、これらの破壊が音もなく、警告もなく、ただ起きることです。
仕入れ先に送る商品マスタ、モールにアップロードする在庫CSV、社内の経理処理に使う売上CSV――こうしたファイルが破壊されたまま流通すると、商品が間違ったJANコードで登録される、在庫数が桁違いに反映される、会員番号が一致せず注文が紐づかない、といった事故に直結します。
2Excelが勝手にデータを書き換える7つの破壊パターン
「壊れる」とひと口に言っても、症状はパターンごとに違います。EC現場で実際に発生しやすい7パターンを、楽天・Amazonの実例とともに整理します。
パターン1: JANコードが指数表記(1.23E+12)に変わる
もっとも典型的で、もっとも被害が大きいのがこれ。13桁のJANコードや国際的なEAN/UPCコードは、Excelが「数値」と判定して指数表記に丸め込む対象です。
表示形式を「数値」に戻しても、Excelは内部的に有効桁数15桁を超える部分を「ゼロ」で埋めます。13桁JANは大丈夫ですが、16桁以上の会員IDや決済トランザクションIDは末尾が000に化け、元に戻りません。
パターン2: 電話番号・郵便番号の先頭ゼロが消える
顧客リスト、配送先データ、店舗マスタ。電話番号「0312345678」をExcelで開くと「312345678」になり、桁数が1つ減ります。郵便番号「0123456」も同様。
原因はパターン1と同じで、Excelが「これは数値だ」と判断するからです。数値の世界に「先頭のゼロ」は存在しないため、消えるのは当然の処理――しかしCSVのデータはそもそも文字列なので、消えてはいけないのです。
パターン3: 「05/06」「3-1」が日付に勝手に変換される
これがEC現場でもっとも厄介なパターンです。商品コード、サイズ、寸法表記、SKU番号などに含まれる「05-06」「1-2」「3/4」のような表記を、Excelは日付として解釈して勝手に変換します。
| CSVの元データ | Excelが表示する内容 | 復元可能性 |
|---|---|---|
05-06 |
5月6日 または 2026/5/6 | 不可(年が確定不能) |
1/2 |
1月2日 | 不可(分数として保存されない) |
3-1 |
3月1日 | 不可 |
2024-08 |
2024/8/1(日が勝手に追加される) | 不可 |
サイズ表記「3-1」(3列1段の意味)が「3月1日」に化け、サイズSKUが全部3月1日になる――こんな事故が、EC物販の現場では今でも普通に起きます。日付フォーマットの問題はそれ自体が深い沼で、詳しくは 日付フォーマットの罠 を参照してください。
パターン4: 商品名が文字化けする
「ï½¢é»é£é»¨ï½£」のような記号の羅列。これはUTF-8で書かれたCSVを、Shift_JISだと思って読んだ結果起きる文字化けです。逆もあり、Shift_JIS のCSVをUTF-8 として読んでも盛大に化けます。
楽天RMSの一括ダウンロードCSVはShift_JIS(CP932)、Amazonセラーセントラルの一部レポートはUTF-8、ShopifyはほぼUTF-8、Yahoo!ショッピングはShift_JIS――モールごとに文字コードが違うため、ExcelのデフォルトでないモールのCSVは必ず化けます。
仕組みと対策の詳細は 文字コードの落とし穴 にまとめています。
パターン5: 改行がぐちゃぐちゃになり、行が連結する
商品説明欄に改行が入っているCSVをExcelで開くと、1商品の途中で行が分かれる、または全行が1行に連結される現象が起きます。
原因は改行コードの違いです。Windows製のCSVはCRLF、Mac/Linux製はLF、楽天RMSはCRLFですが商品説明欄の中身はLF――こうした改行コードの混在がExcelの行認識を混乱させます。
改行コードの仕組みと、CSV内に改行を含めるときの正しい書き方は 改行コード地獄 で詳しく解説しています。
パターン6: 商品名の頭の「=」「+」「-」が計算式と解釈される
「=お得セット」「+5%増量」「-10%OFF」のような商品名。Excelは先頭の「=」「+」「-」を数式の開始記号とみなし、計算しようとしてエラーや「0」を表示します。
セキュリティ業界では「CSVインジェクション」と呼ばれる現象でもあり、悪意のあるユーザーが「=cmd|...」のような文字列を商品名に仕込み、CSV経由でPCに任意コマンドを実行させる攻撃手法も存在します。EC事業者として、お客様が入力した文字列を含むCSVをExcelで開く際は、セキュリティ的にも警戒すべき動作です。
パターン7: 大きな数値の「桁落ち」(末尾000化)
16桁以上の会員番号、注文ID、決済トランザクションID、Amazonの注文番号「249-1234567-1234567」のハイフンを抜いた数値。Excelの内部精度は15桁までのため、それを超える数値は末尾がゼロで埋められて復元不能になります。
注文ID違いの問い合わせ対応、決済プロバイダーへの照会、不正利用調査――いずれも桁落ちした数値では特定できないため、業務に直接的な穴が空きます。CSV地獄 にもこのメカニズムを詳しく書いていますが、根本的な対策は「Excelで開かない、もしくは正しく開く」しかありません。
3なぜダブルクリックではダメなのか
「Excelで開く」と一言で言っても、開き方は複数あり、結果がまったく違います。多くの人がやっているのは、エクスプローラーやデスクトップでCSVファイルをダブルクリックする開き方。これがいちばん危険です。
| 開き方 | 挙動 | データ破壊の可能性 |
|---|---|---|
| ダブルクリックで開く | Excelが全列を自動判定して型変換 | ほぼ確実に壊れる |
| Excel起動 → ファイル → 開く | 同じく自動判定 | ほぼ確実に壊れる |
| データタブ →「テキストまたはCSVから」 | 列ごとに型を指定可能 | 正しく操作すれば壊れない |
| Power Query経由で取り込み | 列の型を明示指定 | 壊れない |
ダブルクリックでは、「自動判定」をユーザーが介入できないのが最大の問題です。「これは文字列として読みたい」と指示する機会が一切なく、Excelの判断にすべて任されます。そして判断は、ECデータにとってほぼ常に間違っています。
もうひとつ重要な点。ダブルクリックで開いて見るだけのつもりでも、その時点で内部値は書き換わっています。「上書き保存」していなくても、コピー&ペーストで他のシートに貼ったり、フィルターで絞ったりした瞬間、壊れた値が業務に流れ出します。
4データを壊さない「正しい開き方」3ステップ
Excelには、列ごとに型を指定してCSVを取り込む機能があります。これを使えば、JANコード列を「文字列」に、サイズ列を「文字列」に、と明示的に指定でき、自動変換を防げます。
ステップ1: 空のExcelブックを開く
まずCSVを開かない。Excelを起動して、空のブックを表示します。CSVファイルをダブルクリックしないこと――これが鉄則です。
ステップ2: データタブから「テキストまたはCSVから」を選ぶ
Excel上部のリボンで「データ」タブ → 左端の「テキストまたはCSVから」をクリック。読み込みたいCSVファイルを選択します。
するとプレビュー画面が出ます。ここで重要なのは、画面下の「ファイルの元のエンコード形式」と「区切り記号」を確認すること。
- 楽天RMSのCSV → エンコードは「932: 日本語 (シフトJIS)」
- AmazonセラーセントラルのCSV → 「65001: Unicode (UTF-8)」
- 区切り記号 → 通常はカンマ。タブ区切りの場合は「タブ」
プレビューで日本語が文字化けしていたらエンコードが間違っています。正しいものに切り替えると、ちゃんと読めるようになります。
ステップ3: 「データの変換」で列の型を指定する
プレビュー画面で「データの変換」(または「変換」)ボタンを押すと、Power Queryエディターが開きます。ここがCSVを壊さないための本丸です。
Power Queryでやること
- JANコード・電話番号・郵便番号の列 → ヘッダーのアイコンをクリックして「テキスト」に変更
- 商品コード・SKU・サイズ表記の列 → 同じく「テキスト」に変更
- 注文ID・会員番号など16桁以上ありうる列 → 必ず「テキスト」に変更
- 金額・数量など本当に計算したい列だけ「整数」「10進数」に
- 左上の「閉じて読み込む」でExcelに反映
この手順で取り込むと、JANコードは指数表記にならず、先頭ゼロは消えず、サイズ表記は日付化しません。最初は面倒に感じても、3回やれば10秒で終わるようになります。
5すでに壊れたCSVを救う方法
「ダブルクリックで開いて、上書き保存してしまった」――これが起きると原則として復元不能です。Excelが書き戻したCSVには、すでに丸まった指数値・消えた先頭ゼロ・変換された日付しか残っていません。
救いがあるのは、「上書き保存していない」かつ「元のCSVをまだ削除していない」場合のみ。このときだけは、以下のリカバリーが効きます。
- Excelを保存せずに閉じる。「保存しますか?」のダイアログで必ず「保存しない」
- 元のCSVファイルが残っていることを確認
- 第4章の正しい手順で開き直す
もし元のCSVがすでに上書きされていた場合、復元の道は限られます。
- モールやSaaSからもう一度ダウンロードし直す(できる場合は最優先)
- Windowsの「以前のバージョン」「ファイル履歴」「OneDriveのバージョン履歴」を確認
- クラウドストレージのゴミ箱・バージョン履歴をチェック
これらが全てダメなら、そのCSVのデータは失われたと諦めるしかありません。バックアップ運用の重要性は バックアップの落とし穴 にも整理しています。
6そもそも「Excelで開かない」という選択肢
Excelの正しい開き方を覚えるのも大事ですが、用途によってはExcelを使わない方が早くて安全です。EC実務でCSVを扱う3つのシーンと、それぞれのおすすめツールを整理します。
シーン1: 中身を「見るだけ」「確認するだけ」
請求書のチェック、ファイルの中身確認、行数の確認。この用途でExcelを使う必要はゼロです。むしろExcelで開くと壊れるリスクしかありません。
| ツール | 適した用途 | 特徴 |
|---|---|---|
| メモ帳 / Notepad++ | ざっと内容を見る | Windowsに標準。改行コードと文字コードを表示できる |
| VS Code | 大きいCSVを見る・検索する | 無料。文字コード切り替え・検索・正規表現が強力 |
| Googleスプレッドシート | 表形式で確認したい | インポート時に列の型指定が可能。Excelより壊しにくい |
シーン2: 編集してモールにアップロードする
これがいちばん事故が起きやすいシーンです。商品マスタCSVを編集して楽天やAmazonにアップロードする業務では、1セルでも壊れるとアップロード時にエラーか、正しく更新されない商品が混入します。
選択肢は3つ。
- Excelで第4章の手順を厳密に守る――列の型指定を絶対に飛ばさない
- Googleスプレッドシートで開く――インポート時に「数値を変換しない」を選べる
- テキストエディタ(VS Codeなど)で直接編集――一括置換は正規表現が便利。ただし 正規表現の沼 にハマらないよう注意
シーン3: 集計・分析したい
売上の傾向分析、商品ごとの数値比較、月次レポート。この用途なら、CSVを直接Excelで開かないのが正解です。Power Queryで取り込み、ピボットテーブルで集計、というフローにすれば元のCSVは一切書き換わりません。
もっと正確にやりたいなら、BIツール(Looker Studio、Power BI)やデータベースに取り込むのが本道。1万行を超えるCSVをExcelで開くこと自体、無理が出てきます。
7業務フローでの再発防止 ― ルール化と自動化
「ExcelでCSVを開くと壊れる」――この事実を社内の全員に毎回説明し続けるのは現実的ではありません。属人的な注意ではなく、業務フローとして再発を防ぐ仕組みに落とし込みましょう。
ルール1: モールCSVをExcelで開かない
もっとも単純で強力なルール。モールから落としたCSVは、Excelで直接開かない。必ずGoogleスプレッドシートかPower Query経由で開く。これを業務マニュアルに明記し、新人研修の最初に伝える。
「Excelで開いて確認したい」というニーズには、VS CodeやNotepad++で見るだけを推奨します。表形式で見たければGoogleスプレッドシートで開けばよい。
ルール2: モール提出用CSVは「専用ツール」で生成する
商品登録CSVや在庫更新CSVを作成するときは、Excelで手作業で作らず、社内ツール経由で出力する。Excelに触らせないことで、人為的な型変換ミスが起きません。
EC業務の自動化で、CSV生成・加工・アップロードを自動化するメリットは EC業務の自動化、その落とし穴 でも触れています。
ルール3: 「壊れていないか」チェックする工程を入れる
編集後のCSVをアップロードする前に、JANコードが13桁あるか・電話番号の先頭ゼロが残っているか・改行が乱れていないかを機械的にチェックする工程を設ける。1分でできる検査が、数日後の事故を防ぎます。
業務に組み込むべきチェックポイント
- JANコード列が「1.23E+12」になっていないか
- 電話番号・郵便番号の先頭ゼロが残っているか
- 商品コードの「
05-06」が「5月6日」になっていないか - 商品名の文字化けが起きていないか
- 商品説明欄の改行で行数が変わっていないか
- 注文ID・会員番号の末尾が「
000」になっていないか
8この記事のまとめ ― CSVは「開く前」が9割
ExcelでCSVを開くと壊れる――これはExcelのバグではなく、「文字列も数値も型なしで並べる」CSVと、「内容を見て型を推測する」Excelの設計思想の根本的な不一致から来る問題です。EC業務で扱うCSVには、JANコード・電話番号・サイズ表記・文字コード・改行コード・大きな数値ID――Excelが間違いやすい要素のフルコースが入っているので、EC現場ほどこの問題が頻発します。
対策は派手なものは要りません。
このトピックのまとめ
- EC現場のCSV破壊は7パターン――JAN指数化・先頭ゼロ消失・日付変換・文字化け・改行ズレ・計算式扱い・桁落ち
- ダブルクリックでの開き方がもっとも危険。Excelの自動判定にデータが任される
- 正しい開き方は「データタブ → テキストまたはCSVから → データの変換 → 列の型を文字列指定」の3ステップ
- 「見るだけ」ならVS Code・メモ帳・Googleスプレッドシートを使い、そもそもExcelで開かない選択肢が安全
- 業務フローとして「モールCSVは専用ツール経由」「アップロード前のチェック工程」をルール化する
- 関連トピック: CSV地獄・文字コードの落とし穴・改行コード地獄・日付フォーマットの罠
「CSV運用が毎週どこかで詰まる」「商品マスタの更新でJANコードが壊れる事故が止まらない」「モール3社のCSV処理を統一したい」――こうした課題は、EC業務とデータ処理の両方が分かる人間に相談するのがいちばん早く片付きます。Excel依存の業務フローを少し整理するだけで、CSV起因のトラブルはほぼゼロにできるからです。