CSV整形が毎回振り出しに戻る理由と、初回だけで終わらせる手順

CSVの整形が毎回ゼロからになるのは、作業が雑だからではない。モールごとに文字コード・改行・列名の仕様が違うのに、毎回同じ手順で直しているからだ。仕様差を先に一覧化して変換ルールを固定すれば、手直しは毎回ではなく初回だけで済む。

• CSVが崩れるのは作業ミスではなく、モール間の仕様差という構造の問題である。原因を分類できれば、直し方は毎回同じ手順に落ちる
• ChatGPTに投げる前に「どこまで機械に渡すか」の線を引く。行数の検算と、個人情報・表記の確認は人の側に残す
• 変換ルールを一度テンプレ化してGASでボタンにすれば、作業は「毎回の手直し」から「初回の設計」に変わる

CSVの整形が「毎回振り出しに戻る」本当の理由

月曜の朝、楽天RMSから商品CSVを落とす。セラーセントラルから在庫ファイルのテンプレートを落とす。ストアクリエイターProからも商品データを落とす。Shopify Adminからも商品CSVをエクスポートする。ここまでは数分で終わる。そのあとの数時間が、毎回そっくり同じ形で消えていく（時間は作業内容によって変わる。目安として次の章で自分の数字を測る）。

消え方も毎回同じだ。Excelでダブルクリックして開いた瞬間に商品名が化ける。JANコードの先頭ゼロが落ちている。発売日が勝手に別の形式になっている。列名がモールごとに違うので、突合するために手で並べ替える。直したファイルをアップロードしたら「日付形式が不正です」で弾かれる。弾かれた行を探して直して、もう一度上げる。

ここで多くの人が「自分の作業が雑だからだ」と結論づける。チェックリストを作り、指差し確認を増やし、それでも来月また同じだけの時間が消える。原因の置き場所を間違えているからだ。

崩れている本当の理由は、4つのモールがそれぞれ別の前提でCSVを吐いているのに、こちらが毎回同じ手順で開いていることにある。文字コードが違う。改行コードが違う。区切り文字が違う。列名の設計思想が違う。仕様がバラバラなファイルを、Excelというひとつの入り口に同じ開き方で通している。入り口が1つで中身が4種類なら、事故は確率ではなく必然で起きる。

この構造が見えると、対処の順番が変わる。「気をつける」は対処ではない。やることは3つに分かれる。

• 入り口を分ける: モールごとに「どう開くか」を固定する。ダブルクリックで開かない
• 変換ルールを外に出す: 頭の中でやっている置換を、シートに書き出す
• 同じ処理を毎回書き直さない: ルールが固まったものだけ機械に渡す

重要なのは、この3つがどれも「初回だけ」の作業だという点だ。仕様差は毎月変わるものではない。変わらないものに毎月コストを払っているから、作業が振り出しに戻り続ける。

もうひとつ見落とされやすいのは、この作業がたいてい一人で回っていることだ。「この列は文字列で読む」「この表記はこっちに寄せる」というルールが担当者の頭の中にしかなく、どこにも書かれていない。手作業の問題は工数だけではなく、手順が人に貼りついていて外に出せないという点にもある。

現場で起きる崩れ方は、だいたい4種類に収まる

仕組み化の前に、崩れ方を分類しておく。原因を4つに畳めれば、遭遇したときに「どこを見ればいいか」が即決まる。分類していないと、毎回ゼロから原因を探すことになる。

1. 文字化け（文字コードの不一致）

商品名が「?????」や意味のない記号の羅列になる、あるいは全角記号だけが壊れる。これは中身が壊れたのではなく、書き出したときの文字コードと、開くときに想定された文字コードが違うだけである。データそのものは無事なことが多い。

Windows版Excelで起きやすいのが、UTF-8のCSVをそのままダブルクリックしたケースだ。ExcelにUTF-8だと認識させるには、ファイル先頭にBOM（EF BB BFの3バイト）が付いている必要がある。BOMなしUTF-8をそのまま開くと化ける、というのが定番の詰まりどころになる。逆に、Shift_JIS（CP932）で書き出されたファイルをUTF-8前提のツールに読ませても同じことが起きる。

対処は「開く前にエンコードを指定する」の一択だ。Excelなら「データ」タブの「データの取得と変換」からテキスト/CSVを選んでインポートし、元ファイルの文字コードを指定する。ここを飛ばして開いたファイルは、何をどう直しても不安が残る。

2. 先頭ゼロの消失（自動データ型判定）

JANコード、郵便番号、電話番号、モール別商品番号のように、数字だがゼロ埋めに意味がある列で起きる。0123456が123456になり、桁が1つ減る。ExcelがCSVを開くときに「これは数値だ」と判定して型を変えているのが原因で、文字化けと違って見た目が壊れないぶん気づきにくい。

さらに厄介なのは、13桁のJANコードのように桁数が多い場合、指数表記（4.9E+12のような形）に変わることがある点だ。この状態で保存し直すと、元の値は画面からは復元できない。対処はここでも開き方で決まる。インポート時に該当列のデータ型を文字列に指定する。ダブルクリックで開かない、が最初に共有されるべきルールになる。

3. 列ズレ（カンマ・改行の内包）

住所欄の「東京都○○区△△1-2-3, ○○ビル5F」のように値の中にカンマが入っている場合、その値がダブルクォートで囲まれていないとそこで列が割れる。1行の列数が変わるので、それ以降の列がすべてひとつずつズレる。

もっと見つけにくいのが、商品説明文やお客様の備考欄に改行が入っているケースだ。囲みが崩れると1行が2行に割れる。行数が合わないのに、どの行が原因なのか画面上では分からない、という状態になる。対処は2段構えで、ダウンロード直後に行数と列数を控えておくことと、テキストエディタで生のCSVを開いてダブルクォートの扱いを目で確認することだ。Excelで開いた時点では、この情報は既に失われている。

4. 日付と改行コードの不一致

2026/8/1と入っていた日付が、Excelを経由した瞬間にシリアル値や別の書式に化ける。見た目では気づかず、アップロードして初めて「日付形式が不正」と返ってくる。日付はYYYY-MM-DDのように形式を先に決め、変換のたびにその形へ寄せるのが安全側の運用になる。

改行コードも同じ性質の問題だ。Windows系はCRLF、Unix系はLFで、これが混在すると1行として扱われるべきデータが分割されたり、逆に連結されたりする。テキストエディタの多くはステータスバーに改行コードを表示するので、まずそこを見る癖をつける。

この4種類は、原因も対処もそれぞれ独立している。「CSVが崩れた」とひとまとめにしている限り、対処は毎回その場しのぎになる。逆に4つに分けられれば、次の工程に進める。

モール別の仕様差を「一覧」にしてから触る

ここが、整形を仕組み化するかどうかの分岐点になる。やることは単純で、自分が扱っているモールの仕様を1枚の表にするだけだ。1回作れば、あとは仕様変更のたびに更新するだけで済む。

先に釘を刺しておくと、この表を「ネットで調べた値」で埋めてはいけない。文字コードや区切り文字は、モール側の仕様変更、管理画面のダウンロードオプション、扱うCSVの種類（商品／受注／在庫）によって変わる。解説記事の値を信じて設計すると、その前提が動いた瞬間に静かに壊れる。埋めるのは、自分のアカウントで実際に1ファイル落として確認した値だけにする。

確認する項目は次の6つでいい。

確認項目	どこで確認するか	なぜ必要か
取得元の画面名	管理画面のメニュー階層をそのままメモする	引き継ぎのとき「どこから落とすか」で必ず止まる
文字コード	テキストエディタで開き、エンコード表示を見る	文字化けの原因の大半がここに集約される
BOMの有無	エディタの「UTF-8」「UTF-8 with BOM」表示	Excelで素直に開けるかどうかが変わる
区切り文字	生ファイルの1行目（カンマかタブか）	タブ区切りをCSVとして扱うと全列が崩れる
改行コード	エディタのステータスバー（CRLF／LF）	行数のズレの原因になる
ヘッダー行の有無と列名	1行目をそのままコピーして保存する	列名マッピングの元データになる

この表を、楽天RMS・Amazonセラーセントラル・Yahoo!ショッピングのストアクリエイターPro・Shopify Adminのように、扱っているモールの数だけ行として作る。ダウンロードの種類が複数あるなら（商品CSVと受注CSVなど）それも別の行にする。

一般論として語られる話――Shopifyのエクスポートはカンマ区切りのUTF-8、Amazonの出品用テンプレートはタブ区切りのテキストとして保存する、といった説明――は、確認の起点にはなるが、そのまま設定値にしてはいけない。各モールの正式なマニュアルは基本的にログイン後にしか読めず、更新も随時入る。表に書くべきは「公式ヘルプにこうあった」ではなく「◯月◯日に自分が落としたファイルはこうだった」だ。確認日の列を足しておくと、この区別が自然に守られる。

ここまで作ると、面白いことが起きる。「毎回違う」と思っていた作業が、実は3〜4パターンの組み合わせでしかなかったと分かる。文字化けするのはこの2モールだけ、先頭ゼロが落ちるのはこの列だけ、タブ区切りなのはここだけ。その粒度まで落ちれば、機械に渡せる形になっている。

整形にかかっている時間を、先に洗い出す

仕組み化に着手する前に、もうひとつやることがある。いま何にどれだけ時間を使っているかを、自分で計測することだ。地味だが、飛ばすと後で必ず困る。困り方は2つあって、自分で「やる価値があるのか」を判断できなくなることと、社内に「仕組み化したい」と言うときの根拠が「なんとなく大変です」しか無くなることだ。

計測といっても、ストップウォッチは要らない。1か月だけ、作業ログを4項目に分けてメモすればいい。

• ダウンロードと開く作業: 管理画面から落として、正しい文字コードで開き終わるまで
• 崩れの修復: 文字化け・先頭ゼロ・日付・列ズレを直している時間
• 表記の統一: 列名を揃える、表記ゆれを置換する時間
• 再アップロードとエラー対応: 弾かれて、原因を探して、上げ直すまで

この4つに分けるのがポイントになる。合計時間だけ分かっても打ち手は決まらないが、内訳が分かると、どこから機械に渡すべきかが決まるからだ。修復と表記統一に大半が寄っているなら変換ルールのテンプレ化が効く。再アップロードのエラー対応に寄っているなら、アップロード前の検証（行数・列数・必須列のチェック）を先に作るべきだと判断できる。

粒度は「1回あたり何分×月に何回」で十分だ。1回45分の作業が月8回なら月6時間、という程度の精度でいい。自社の人件費に置き換えれば、いくらまでなら投資していい作業なのかも決まる。有料ツールを検討するときの判断もここで速くなる。

そして、この数字は仕組み化した後にもう一度測る。ここで初めて「何分減った」が自分のデータとして手に入る。世の中に出回っている削減率を引用するより、自分の現場で測った1つの数字のほうが社内では強い。測った時間を通る言い方に変換する部分は、数字で語れるEC担当者になるための考え方のほうで扱っている。

ChatGPTに整形を頼むときの指示文の作り方

仕様差の一覧と変換ルールが手元にあれば、ChatGPTに整形を頼めるようになる。逆に言うと、ルールが無い状態で「これを整形して」と投げるのが一番危ない。何を正解とするかを渡していないので、AIは自分の判断で補完してくる。

実務で使える指示文の骨格は、次の4ブロックになる。

あなたはEC商品データのクレンジング担当です。
添付CSVを整形してください。

【元データの前提】
- 1行目はヘッダー
- 文字コード：（判明していれば明記。不明なら「不明」と書き、先に判定させる）

【変換ルール】
- 列名マッピング：氏名/お名前/顧客名 → 顧客名 のように明示する
- 表記ゆれ統一：東京/東京都 → 東京都、(株)/株式会社 → 株式会社 など
- 全角半角・余計な空白・改行を除去する
- JANコード・郵便番号・電話番号など先頭ゼロを含む列は文字列として保持し、数値変換しない
- 日付は YYYY-MM-DD 形式に統一する
- 元データの行数は変えない。不明な値は勝手に補完しない

【出力条件】
- 整形後のCSV
- 変更した列名の一覧
- 置換した表記ゆれの一覧
- 「元の行数」「整形後の行数」「差分とその理由」を必ず報告する

この指示文で効いているのは装飾的な部分ではなく、後半の「行数は変えない」「勝手に補完しない」「行数の差分を報告させる」である。

生成AIにCSVを渡したときの事故のうち、最も気づきにくいのが行数のズレだ。空行や小計行を「不要」と判断して落とす、重複に見える行をまとめる、といった処理がこちらの許可なく走ることがある。しかも出力は整った表として返ってくるので、画面上は完璧に見える。件数が合っていないことに気づくのは、アップロードして在庫数の合計が合わなくなったときだ。

さらに、大きなファイルを渡したときに先頭の一部だけを見て回答している場合もある。「全件処理しました」と書いてあっても、本当に全件を対象にしたかは件数で示させないと分からない。だから整形の指示とは別に、検算専用の指示を続けて投げる。

CSV全体の行数・列数・列名を最初に報告してください。
削除または変換した行がある場合は、行番号と理由を列挙してください。
先頭100行だけでなく全件を対象に処理したことを、件数の一致で示してください。

運用のコツは3つある。ダウンロード直後の行数を自分で控えておくこと（突き合わせる基準が無ければ報告は意味を持たない）。初回は10行程度の抜粋で通すこと。そして成功した指示文をそのまま保存すること。次回はファイルを差し替えるだけで済み、ここで「毎回考える作業」が消える。

GASで「毎回同じ変換」をボタンにする

ChatGPTでの整形は、ルールがまだ固まっていない段階では強い。一方で、毎月同じ変換を同じ結果で確実に繰り返す用途には向かない。実行のたびに出力が変わりうるものを、定型業務の中心には置けないからだ。

ルールが固まった時点で、処理はGAS（Google Apps Script）に移す。役割は難しいものではなく、「シートに書いた置換ルールを、上から順に当てるだけ」である。シートは2枚。dataにCSVを貼り、rulesのA列に変換前、B列に変換後を並べる。

function onOpen() {
  SpreadsheetApp.getUi()
    .createMenu('CSV整形')
    .addItem('置換ルールを適用', 'applyRules')
    .addToUi();
}

function applyRules() {
  const ss = SpreadsheetApp.getActiveSpreadsheet();
  const data = ss.getSheetByName('data');
  const rules = ss.getSheetByName('rules')
    .getDataRange().getValues().slice(1); // 1行目はヘッダー

  const range = data.getDataRange();
  const before = range.getNumRows();
  const values = range.getDisplayValues(); // セルに表示されている文字列をそのまま取得する

  const out = values.map(row => row.map(cell => {
    let v = String(cell).replace(/\s+/g, ' ').trim();
    rules.forEach(([from, to]) => {
      if (from !== '') v = v.split(String(from)).join(String(to));
    });
    return v;
  }));

  data.getRange(1, 1, out.length, out[0].length).setValues(out);
  SpreadsheetApp.getUi().alert('処理前: ' + before + '行 / 処理後: ' + out.length + '行');
}

短いコードだが、実務上の要点が3つ入っている。

• getDisplayValues()を使う: セルに表示されている文字列をそのまま取る。処理の途中でJANコードのような数値風の文字列を、GAS自身がさらに数値へ変換してしまうことを防ぐ書き方になる。ただしこれは「これ以上壊さない」ためのもので、既に壊れた値を直すものではない。JANコード列が貼り付けの時点で指数表記（4.9E+12）になっていれば、getDisplayValues()もその壊れた表示をそのまま返す。前提として、対象列は前段（インポート時にデータ型を文字列指定する）で正しく取り込んであることが必要になる
• 部分一致で置換する: セル全体が一致したときだけでなく、セルの中に含まれる文字列を置換する（(株)ABC商事のような、前後に文字が続くセルにも対応するため）。ただし部分一致は、変換前の文字列が変換後の文字列に含まれるルール（「東京」→「東京都」など）と組み合わせると二重に効いてしまう。そのルールだけ「セル全体が完全に一致したときだけ置換する」条件に分けるか、変換後の文字列を先頭から含む場合はスキップする一行を足しておく
• ルールをコードの外に出す: 表記ゆれが増えてもシートに1行足すだけで済む。コードを触れない人でも運用できる

onOpen()を入れると、スプレッドシートのメニューバーに「CSV整形」が追加される。実行が、コードを開く行為からメニューを選ぶ行為に変わる。引き継ぐときに「スクリプトエディタを開いて実行ボタンを押す」と説明しなくてよくなる差は大きい。

処理前後の行数をアラートに出しているのは、検算のためではない。mapで1行ずつ変換しているだけなので、行数は仕組み上ズレようがない。ここで出しているのは「意図した範囲が最後まで処理を終えた」ことを目で確認するための実行ログであり、行の抜け漏れそのものを検知する仕組みではない。行の抜け漏れが起きるとすれば前段のChatGPTでの整形時であり、そちらは指示文で件数の一致を報告させることが検算になる。

ただしこれは最小構成である。先頭ゼロを保持したまま貼り付ける方法、必須列の欠落チェック、モールごとの列順への並べ替えは、自分の環境で1つずつ足す必要がある。本番データに直接当てず、必ずコピーしたシートで結果を確認してから使う。

手段の向き不向きは次のように整理できる。金額は改定が入るので、各サービスの公式ページで最新の条件を確認してほしい。

手段	向いている場面	向かない場面	費用の考え方
ChatGPT等の生成AI	ルールが固まっていない段階の試行、表記ゆれの洗い出し	毎月同じ結果が必要な定型処理、社外に出せないデータ	プランによって扱えるファイルや機能が変わるため、要件を先に決めて公式条件を確認する
GAS（スプレッドシート）	ルールが固まった変換の繰り返し、社内での共有と引き継ぎ	初回の設計に手間がかかる。超大量データの処理	Googleアカウントの範囲で使えるが、実行時間などの制限は公式ドキュメントで確認する
専用ツール・OMS連携	複数モールの受注・在庫を恒常的に扱う運用	月数回・少量のスポット作業	月額と初期費用に対して、洗い出した工数（時間×人件費）が見合うかで判断する

機械に渡す範囲と、人が目で見る範囲を分ける

ここまでは「どう渡すか」の話だった。同じくらい重要なのが、渡してはいけないものを決めておくことである。線を引かずに始めると、便利になった分だけリスクも自動化される。判断の軸は3つある。

1. 社外に出してよいデータかどうか

受注CSVには氏名・住所・電話番号・メールアドレスが並んでいる。これを外部の生成AIサービスにアップロードしてよいかは、ツールの性能ではなく自社の規程とプライバシーポリシーで決まる。学習に使われるかどうかの扱いはサービス側の仕様で変わるため、「大丈夫だと聞いた」で進めない。

現実的な回避策は単純で、個人情報の列を落としてから渡すことだ。整形したいのが商品名や配送方法の表記ゆれなら、氏名・住所の列は要らない。処理対象の列だけを抜いて渡し、戻ってきた結果を元ファイルにキーで突き合わせる。この一手間で、判断が必要な場面そのものが消える。

2. 間違えたときに取り返しがつくかどうか

表記ゆれの統一を間違えても、気づけば直せる。一方、価格・在庫数・ポイント倍率を間違えたまま反映すると、売上と信用に直接影響する。この種の列は、機械の出力をそのまま反映せず、必ず反映前に人が数値を確認する対象として扱う。具体的には、アップロード前に3点だけ見る。行数が一致しているか、必須列が欠けていないか、価格列の最小値と最大値が想定の範囲に収まっているか。最後のひとつは、桁落ちや小数の混入を一発で見つけられる。

3. 表示に責任が伴うかどうか

商品説明文、送料や配送日の記載、返品の条件といった表示そのものが約束になる文言は、機械にまとめさせない。整形の名目で語尾や表現を寄せた結果、実際の運用と違う条件が表示されるという事故が起きうる領域だからだ。この種の文言は、変更したら必ず人が読んで確認する。

整理すると、機械に渡していいのは「ルールが明文化できて、間違いに気づける処理」だけになる。文字コードの変換、列名のマッピング、空白や全角半角の統一、日付形式の統一。この4つは機械が得意で、人がやると疲れるだけの作業だ。逆に、判断が要るもの、責任が伴うもの、取り返しがつかないものは人の側に残す。

整形ルールをテンプレ化して、自分が抜けても回る状態にする

最後の工程は、ここまで作ったものを他人が使える形にすることだ。ここを飛ばすと、手作業が自動化されただけで、業務が一人に貼りついている状態は何も変わらない。

必要なのは長いマニュアルではない。1枚のスプレッドシートに、次の4つがあればいい。

• 仕様シート: 先ほどの6項目（取得画面・文字コード・BOM・区切り・改行・列名）＋確認日
• ルールシート: 列名マッピングと表記ゆれの置換ルール。GASが読むのと同じシート
• 手順シート: 落とす→開く→適用→検算→上げる、を5行で書いたもの
• 事故ログ: 過去に何が崩れて、原因が何で、どう直したか。日付つきで追記する

この4枚目が効く。事故ログは、同じ崩れ方に2回目で遭遇したときの調査時間をゼロにするだけでなく、仕様変更の履歴そのものになる。「先月から列が1つ増えている」といった変化は、記録が無いと気のせいとして処理されてしまう。

テンプレ化できたかの判定は簡単で、自分以外の人にこの4枚だけを渡して1回やってもらうことだ。詰まった場所が、そのまま書き足すべき箇所になる。口頭で補足した内容は、補足した時点でシートに書く。これを2回まわせば、たいてい引き継げる形になる。

この作業には、工数削減とは別の副産物がある。手順を外に出せる人は、業務そのものを設計している人として見られるということだ。同じ時間を毎月使っている人と、その時間を仕組みに置き換えて誰でも回せるようにした人とでは、社内での位置づけが変わっていく。ツールに置き換えられにくいのは、手が速い人ではなく、業務の構造を分解して外に出せる人のほうだと考えている。

仕組み化した結果を社内提案として説明する型は、数字で語れるEC担当者になるための考え方にまとめてある。作業を減らした話を、評価される言い方に翻訳する部分を扱っている。

よくある質問

ChatGPTに整形させた結果を、そのままモールにアップロードしてもよいか

そのまま上げるのは避けたほうがいい。整形前後の行数・列数が一致していること、必須列が欠けていないこと、価格や在庫の数値が想定の範囲に収まっていることの3点は、反映前に人が確認する。特に行数のズレは出力の見た目では分からないため、ダウンロード直後の行数を自分で控えておき、それと突き合わせる運用にしておく。

Excelでダブルクリックして開いてはいけないのはなぜか

開いた時点でExcelが文字コードとデータ型を自動判定してしまい、文字化けや先頭ゼロの消失が発生するからだ。しかも保存し直すと、その判定結果がファイルに書き込まれる。「データ」タブの「データの取得と変換」からインポートし、文字コードと各列のデータ型（JANコードや郵便番号は文字列）を明示的に指定して開く。

プログラミングの経験がなくてもGASは使えるか

置換ルールをシート側に持たせる構成であれば、日々の運用でコードを触る必要はない。ただし初回の設置と、自社の列構成に合わせた調整は必要になる。いきなり本番データに当てず、コピーしたシートで処理前後の行数と数件の値を確認してから使う、という進め方を勧めたい。

受注CSVの顧客情報を生成AIに渡してもよいか

可否は自社の規程とプライバシーポリシー、および利用するサービスの条件で決まるため、一律には言えない。実務上は、処理したい列（商品名や配送方法など）だけを抜き出して渡し、個人情報の列は元ファイル側に残したままキーで突き合わせる方法が現実的だ。判断が必要な場面そのものを作らない設計にしておくと、運用が安定する。

あわせて読みたい: 数字で語れるEC担当者になるための考え方