コラム ｜ 物流データ収集技術 #6 ｜ 2026年8月19日

「CSVで送ってください」の落とし穴
──ファイル形式・文字コード・改行コードの実務ガイド

システム間でデータをやり取りするとき、最もよく交わされるやり取りがあります。

「データをいただけますか」
「はい、CSVで出力してお送りします」

この一言で話がまとまったように見えて、実際にファイルを受け取ってみると、うまく読み込めない。文字化けする。行数が合わない。数字だったはずの列が日付になっている——。データ連携の現場では、こうした問題が繰り返し起きています。

本記事では、データ連携で毎回ハマるポイントを具体例つきで整理します。物流に限らず、システム間でファイルをやり取りする場面で共通して役立つ内容です。

1. まず、どの形式でやり取りするか

データファイルの形式には、いくつかの選択肢があります。それぞれ得意な場面が異なります。

実務上は、相手のシステムが出力できる形式が最初の制約になります。基幹システムやWMSからの出力はCSVまたは固定長テキスト、IoT機器やAPIからはJSON、というのが典型的なパターンです。

2. CSVの罠——「カンマ区切り」だけでは決まらないこと

CSVは最も広く使われる形式ですが、同時に最も仕様の揺れが大きい形式でもあります。実務で問題になりやすい項目を順に見ていきます。

罠①：値の中にカンマが入る

最も古典的な問題です。住所、商品名、備考欄。これらにカンマが含まれると、列がずれます。

意図した3列のデータ

このまま読み込むと、2行目は「A001」「ボールペン（黒」「赤」「青）」「100」の5列として解釈されます。

これを防ぐのがダブルクォート（”）による囲みです。

クォートで囲んだ場合

ただし、今度は「値の中にダブルクォート自体が含まれる場合はどうするか」という問題が出てきます。CSVの一般的な取り決めでは、値の中のダブルクォートは2つ重ねて表現します。

値の中にダブルクォートがある場合

これは「15″モニタースタンド」という値を表します。この仕様に対応していない読み込み処理では、ここで破綻します。

罠②：値の中に改行が入る

備考欄や住所欄に改行が入力されているケースです。クォートで囲まれていれば1つの値として扱えますが、囲まれていない場合、そこで行が分かれてしまいます。

「送られてきたCSVの行数と、システムの登録件数が合わない」という現象の典型的な原因がこれです。件数のズレが小さいと見過ごされやすく、後から発覚することがあります。

罠③：改行コードの違い

行の区切りを表す「改行コード」には、複数の種類があります。

多くの読み込み処理は複数の改行コードに対応していますが、対応していない場合、ファイル全体が1行として読み込まれる、あるいは各行の末尾に余分な文字（\r）が付いたまま取り込まれる、といった現象が起きます。

後者は特に発見しにくい問題です。見た目には正常なのに、最終列の値だけが常に一致しない。「〝東京〟と〝東京〟が別の値として扱われる」といった形で現れます。

罠④：文字コード

日本語を含むデータでは、文字コードの不一致が文字化けを引き起こします。

特に注意したいのが、一部の文字だけが化けるケースです。丸数字（①②）、ローマ数字（ⅠⅡ）、環境依存の漢字（﨑、髙など）。これらは文字コード間で対応が取れないことがあり、大半のデータは正常に見えるため、問題の発見が遅れます。

罠⑤：NULL・空文字・ゼロの区別

CSVはテキストファイルなので、「値が存在しない」ことを表現する方法が決まっていません。

この区別は、集計結果に直接影響します。「未計測」を0として集計すれば平均値が下がりますし、欠損として除外すれば分母が変わります。どう表現するかを送信側と受信側で合意しておく必要があります。

罠⑥：Excelによる型の自動変換

CSVをExcelで開いて確認・編集し、そのまま保存する——この運用は、意図しないデータ変換を引き起こします。

商品コード、JANコード、電話番号、部屋番号。桁を保持したい数字列は、すべてこの影響を受け得ます。データ連携の経路にExcelでの手作業が挟まっている場合は、この点を確認しておく価値があります。

もう一つ見落とされやすいのが日付・時刻の書式変換です。Excelは日付として認識した値を、セルの表示形式に従って書き換えます。「2026/08/17」と入力されていた値が、保存後に「2026-08-17」や「8/17/2026」、あるいは「2026年8月17日」になっていることがあります。

取り込む側のシステムは、多くの場合日付の書式を1つに固定して受け付けます。たとえば日付は「YYYY/MM/DD」、日時（タイムスタンプ）は「YYYY-MM-DD HH:MM:SS」というように、項目の種類ごとに異なる書式が指定されることもあります。Excelを経由すると、この書式が意図せず変わってしまいます。

罠⑦：ヘッダ行と項目の並び

1行目が項目名（ヘッダ行）なのかデータなのか。項目の並び順は固定なのか、ヘッダ名で判断するのか。項目が追加されたとき、末尾に足すのか途中に挿入するのか。

これらは連携開始時には問題になりませんが、数か月後にシステム改修で項目が1つ増えたときに顕在化します。列の並び順で判断する処理は、途中に列が挿入された瞬間に全体がずれます。

3. JSON・XMLという選択肢

CSVの罠の多くは、「表形式のデータを、区切り文字だけで表現しようとしている」ことに由来します。JSONやXMLは、値の範囲を明示的に示す構造を持つため、これらの問題の一部を回避できます。

JSONの例

値がどこからどこまでかが明確で、カンマが含まれていても問題になりません。また、1件の出荷に複数の明細がぶら下がるといった階層構造をそのまま表現できます。CSVで同じ構造を表そうとすると、ヘッダ用と明細用の2ファイルに分けるか、明細ごとにヘッダ情報を繰り返すことになります。

JSONを使う場合の注意点

JSONは文字コードとしてUTF-8を用いるのが一般的で、この点では迷いが少なくなります。一方で、注意すべき点もあります。

ファイル全体が1つの構造になる。 1件でもデータが壊れていると、ファイル全体が読み込めなくなることがあります。これを避けるため、1行に1件のJSONを並べる形式（JSON Lines / NDJSON と呼ばれます）が使われることもあります。

数値の扱いに注意が必要。 先頭にゼロが付くコードや、桁数の大きい数値は、数値型ではなく文字列型（クォートで囲む）として扱うのが安全です。

ファイルサイズが大きくなりやすい。 1件ごとに項目名が繰り返されるため、同じ内容のCSVより大きくなります。

XMLが使われる場面

XMLもJSONと同様に階層構造を表現できます。JSONより記述が冗長になりますが、EDI（電子データ交換）の標準や、一部の基幹システムとの連携で採用されていることがあります。連携相手がXMLを指定してきた場合は、その仕様に合わせることになります。

4. 分析基盤で使われるParquet

ここまでは、システム間でやり取りするファイル形式の話でした。一方、クラウドの分析基盤にデータを蓄積する段階では、別の形式が使われることがあります。その代表がApache Parquetです。

行指向と列指向の違い

CSVは行指向——1件のデータをまとめて記録していく形式です。1件ずつ読み書きする用途に適しています。

これに対してParquetは列指向——同じ列の値をまとめて記録します。「出荷日」の列だけ、「数量」の列だけ、というようにデータが並びます。

「1年分の出荷データから、月ごとの数量合計を出す」といった集計では、必要な列だけを読めば済むため、列指向のほうが効率的に処理できます。大量のデータを扱う分析基盤でParquetが採用されるのは、この特性によるものです。

5. 連携を始める前に取り決めておくこと

ここまで挙げた問題の多くは、事前の取り決めで防げます。実際、データを受け入れる側のシステムでは、取り込み時の挙動がこうした項目ごとに設定されているのが一般的です。「CSVで」の一言で済ませず、以下を確認しておくと後の手戻りを大きく減らせます。

ファイルの基本仕様

行と列の扱い

値の表現

データ型ごとの書式

※ 実際に必要な項目は連携する内容や受け入れ側のシステムによって異なります。上表は取り決めの出発点として参照してください。

まとめ：仕様を決めることが、データ連携の実務

データ連携で発生する問題の多くは、高度な技術課題ではありません。「CSVで」という言葉が指す内容が、送る側と受け取る側で違っていた——という取り決めの問題です。

文字コード、改行コード、クォート、値なしの表現。一つひとつは細かい項目ですが、これらを最初に確認しておくかどうかで、その後の作業量が大きく変わります。