1そもそも「改行コード」って何？

テキストファイルを開いたとき、行が変わるのは当たり前のように見えます。しかし、コンピュータの中では「改行」も1つの文字として保存されています。目には見えませんが、確かにそこにいる――それが改行コードです。

そして厄介なことに、この「改行を表す文字」には3つの種類があります。OSによって採用しているものが違うため、ファイルをやり取りするだけで衝突が起きます。

「文字コード」と並んで、CSV業務でじわじわ効いてくるのがこの改行コード問題です。文字コードは UTF-8・Shift_JISの記事で扱いましたが、改行コードはそれとは別の独立した落とし穴。本記事では、改行コードがなぜ厄介なのか、EC実務でどう壊れるのかを解説します。

2LF・CR・CRLF ― 3つの改行コードの違い

改行コードは大きく分けて3種類。それぞれの正体を整理します。

改行コード	記号	バイト表現	主に使われるOS・環境
LF（Line Feed）	\n	0x0A	Mac（OS X以降）/ Linux / Unix / Webサービスのサーバー全般
CR（Carriage Return）	\r	0x0D	古いMac（OS 9以前）。今はほぼ絶滅
CRLF（CR + LF）	\r\n	0x0D 0x0A	Windows / 楽天RMS / 多くの日本のEC基幹システム / メールヘッダ

名前の由来はタイプライター

名前の由来は、コンピュータが普及する前のタイプライターの動作から来ています。

• CR（Carriage Return） ―― 印字ヘッドを行の先頭に戻す動作（横方向の移動）
• LF（Line Feed） ―― 紙を1行送り出す動作（縦方向の移動）

本来、紙を新しい行に進めるには「行の先頭に戻る（CR）」と「紙を1段送る（LF）」の両方の動作が必要でした。Windowsはこの忠実な再現としてCRLFを採用。一方、Mac/Linux/Unix は「LFだけで十分でしょ」と簡略化したのです。

なぜ、いまだに3種類も残っているのか

「世界標準を1つに決めればいいのに」と思うところですが、現実にはそうなっていません。理由はシンプルで、過去の互換性を捨てられないからです。

• Windowsの世界 ―― 業務ソフト・メモ帳・古いシステムがCRLF前提で動いている
• Web・サーバーの世界 ―― ほぼすべてLinuxで動いており、LFがデフォルト
• HTTP・SMTPなどの通信プロトコル ―― 仕様上CRLFと決まっている
• 日本のEC基幹システム ―― Windowsで作られたものが多く、CRLF前提

つまり、業務PC（Windows / CRLF）と、サーバー（Linux / LF）の文化の違いが、ファイル1つの中でぶつかるのが、今のEC現場の構図です。

3改行コードが混ざるとどうなるか ― 5つの典型的な壊れ方

改行コードの混在は、人間の目には全く見えません。その上で、プログラムが期待する改行と違うとこんな壊れ方をします。

パターン1：全データが1行になる

LFで保存されたCSVを、CRLFしか改行と認識しないプログラムで読み込むと、すべての行が連結されて1行になります。

逆のパターンも起きます。CRLFのファイルを「LFを改行と見なす」古いプログラムで読むと、各行末に \r（CR）が残骸として残り、商品コード末尾に見えない文字がついている状態になります。これが「なぜか商品が一致しない」「マスタ突合が外れる」事故の原因になります。

パターン2：CSVの行数がズレる

CSVの「列の中に改行が含まれているデータ」を扱うとき、もっとも壊れやすいパターンです。

たとえば商品説明文に改行が入っている場合、その改行は「商品説明という1つのセルの内部の改行」であって、「次の商品行への改行」ではありません。 CSVではこれを区別するため、改行を含むセル全体をダブルクォート " で囲むルールがあります。

ところが、ここで「セル内の改行はLF、行の区切りはCRLF」のように改行コードが混在しているCSVを、改行コードの種類を区別しないプログラムで読み込むと、セル内改行も行区切りとして解釈されてしまい、1商品が2行・3行に分裂する現象が起きます。

• 商品マスタ500行を取り込んだはずなのに、システム上は753件登録されている
• 商品説明文の途中で行が分断され、別商品の列が後半行に押し出される
• 分断された行のSKUコードが空で登録される

この事故はサイレントに発生します。エラーが出ないので気づくのは、お客様から「商品ページがおかしい」と問い合わせが入ってからです。

パターン3：取り込みでエラーになる

逆に、システム側が厳密に改行コードをチェックしていると、改行コードが想定と違うだけで取り込み自体が失敗します。

• 「ファイルフォーマットが不正です」
• 「行末文字を認識できません」
• 「改行コードを CRLF に統一してください」

この場合、データは壊れませんが、毎回手作業で改行コードを変換する手間が発生します。月末に大量更新があるECでは、これだけで数十分〜数時間のロスになります。

パターン4：行末に ^M が残る

CRLFのファイルをMac/Linux系のエディタやviで開くと、各行の末尾に ^M という見慣れない記号が表示されることがあります。これはCR（\r）の残骸です。

このまま「ただのテキスト」だと思って処理に流すと、商品コードや管理番号の末尾に不可視のCRがくっついた状態でデータベースに登録されます。後日、別システムから「A001」で検索しても見つからず、原因が分からない――典型的な迷宮入りトラブルです。

パターン5：商品説明文の改行が表示されない・崩れる

EC特有のトラブルです。商品説明文をCSV経由でモールにアップロードする際、改行コードの種類によって表示が変わる場合があります。

• 楽天RMSはCRLFを期待 ―― LFのまま入れると、商品ページで改行が消えて文章が一続きになる
• 逆に、HTML 用の <br> タグと改行コードが二重に入って、不要な空行が量産される
• JSONで送る場合、改行は \n にエスケープされる必要があり、生のCRLFが混ざるとパースエラー

4EC実務で起きやすい改行コード事故

ここからは、EC運営の現場で実際によく見かけるトラブル例を、シーン別に整理します。

シーン1：楽天RMSのCSVを、Pythonの自動処理で書き換える

楽天RMSからダウンロードしたCSVは Shift_JIS + CRLF。これをPythonで読み込み、価格や在庫を書き換えて再アップロードする、という自動化はよくあります。

ところが、Pythonのデフォルト挙動は環境によって改行を勝手に変換することがあります。Mac/Linuxサーバー上で何も指定せずに書き出すと、出力ファイルがLFになってしまい、楽天RMSにアップロードしたときに認識されない、または商品説明文の改行が消える、といった事故が起きます。

Pythonでファイルを開くときは、明示的に改行コードを指定する必要があります。

シーン2：Amazon SP-APIのレスポンスを、楽天用CSVに変換する

Amazon SP-API から取得したデータはJSON形式で、改行コードという概念は基本的にありません。問題は、これをCSVに整形して楽天用にアップロードする段階で起きます。

• JSON内の商品説明文に \n（LF相当）が入っている
• そのままCSVに書き出すと、セル内改行がLFのまま残る
• CSV全体の行区切りはCRLFで書き出している
• 結果、1ファイル内に2種類の改行コードが混在

このCSVを楽天RMSにアップロードすると、商品説明文の途中でセルが分断され、列ズレが起きる――というのが典型パターンです。

シーン3：複数モールのCSVをExcelで統合する

楽天・Amazon・Yahoo!ショッピングからダウンロードしたCSVを、1つのExcelに統合するケース。

ExcelでCSVを開いて「名前を付けて保存」すると、すべてCRLFに統一されます。これは一見ありがたい挙動ですが、その後そのCSVをLinuxサーバー上のスクリプトに渡すと、また改行コードが合わずにエラー、という事故も起きます。

シーン4：商品説明文をテキストエディタで編集する

商品説明文を整える作業を、メモ帳やTeraPad、サクラエディタなどで行うことがあります。エディタによって、保存時の改行コードが違います。

• 古いメモ帳 ―― 強制的にCRLF
• VS Code ―― ファイルを開いた時点の改行コードを維持（混在もそのまま保存される）
• サクラエディタ ―― 設定次第（デフォルトは「変換しない」）

担当者ごとに使うエディタが違うと、同じファイルを編集して回しているうちに改行コードがバラバラになる、ということが普通に起きます。

シーン5：GASでスプレッドシートからCSV出力する

Google Apps Script（GAS）でスプレッドシートの内容をCSVファイルとして出力する場合、デフォルトで生成されるCSVはLFです。これをそのまま楽天RMSやWindowsの基幹システムに食わせると、改行が認識されません。

GASでCSVを生成するときは、自分で \r\n に置換してから出力する必要があります。「データの中身は合っているのに、なぜかアップロードが失敗する」場合、まず疑うのはここです。

5「改行コード」と「文字コード」を混同しないこと

現場でよくある誤解として、「文字化けかな？」と思ったら実は改行コードの問題だった、というケースが頻発します。逆もまた然りです。

この2つは独立した別の概念で、組み合わせは自由です。

組み合わせ	よく出会う場面
UTF-8 + LF	Mac/Linuxで作ったファイル、Web/APIから来たデータ
UTF-8 + CRLF	WindowsのVS CodeやExcelで保存したUTF-8 CSV
Shift_JIS + CRLF	楽天RMS、古い基幹システム、Windows標準
Shift_JIS + LF	事故。誰も意図せず作る組み合わせ。最も壊れやすい

「文字化け」と「改行ズレ」のどちらが起きているかで、確認すべき場所も対処も違います。切り分けの第一歩は、エディタで開いて「文字コード」と「改行コード」の両方を確認することです。

文字コード側の話は、「文字コードの落とし穴」 にまとめてあります。あわせて読むと、CSV系トラブルの大半は切り分けられるようになります。

6場当たり対応の限界と、仕組みで止めるという選択肢

改行コードのトラブルは、「気をつける」では絶対に再発します。担当者が変わったとき、エディタを変えたとき、新しいモールが増えたとき、システムをアップデートしたとき――きっかけはいくらでもあります。

毎回ファイルをエディタで開いて改行コードを確認する、というオペレーションを、365日・全担当者・全ファイルで間違いなく続けられるか？と考えると、現実的ではありません。

• 担当者の入れ替わりで、ノウハウが引き継がれない
• 月末や繁忙期に手順が省略されて、事故が起きる
• 新しい外注先・新しいモール対応のたびに、改行コードの問題が再燃する
• 「いつもどおりにやったのに、今回だけアップロードが失敗した」という再現性のないバグに振り回される

こうしたトラブルを根本から止めるには、人間が改行コードを意識しなくていい仕組みを入れるのが確実です。

これらはPython・GAS・Node.jsなどで実装可能です。一度仕組みにしてしまえば、担当者が改行コードのことを知らなくても、毎回正しい形式で出力されます。

「文字コードを判定する」「改行コードを判定する」「BOMを処理する」「セル内改行を保つ」「出力先ごとにフォーマットを切り替える」――これらをきちんと組むと、CSV系トラブルの9割はそもそも発生しなくなります。

もし、毎月のCSV運用で「アップロードが通らない」「商品説明の改行が崩れた」「列がズレて反映された」といった事故を繰り返しているなら、その作業自体を仕組み化するのが、一番確実かつ安いコストの解決策です。改行コードに人間の注意力を1ミリも使わなくて済む状態は、思っているよりもすぐ作れます。