CSVとJSON — 違いと相互変換のポイント

CSV と JSON は、どちらもテキストでデータを表す定番の形式ですが、得意分野がまったく違います。CSV は行と列の表（2次元）を表すのに向き、JSON はネスト（入れ子）や型を持つ構造化データを表すのに向きます。本記事では両者の仕組みの違い、相互変換でつまずきやすい点、文字コードや区切り文字、そして用途別の使い分けを正確に整理します。

1. CSV とは — 行と列・区切り・RFC 4180

CSV（Comma-Separated Values）は、1行を1レコード、各列をカンマ（,）で区切って表す、2次元の表形式です。多くの場合、先頭行を列名（ヘッダー）として使います。仕様は RFC 4180 で一応の標準化がされていますが、実際には方言が多い点に注意が必要です。

id,name,age
1,Alice,30
2,Bob,25

クオートとエスケープ

値そのものに区切り文字・改行・ダブルクオートが含まれると、単純なカンマ区切りでは壊れてしまいます。RFC 4180 では、こうした値全体をダブルクオート（"）で囲むことで「これで1つの値」と示します。さらに、囲んだ値の中にダブルクオートを書くときは二重（""）にしてエスケープします。

• カンマを含む値：Tokyo, Japan は "Tokyo, Japan" と囲む。
• 改行を含む値：セル内改行も、その値全体をダブルクオートで囲めば1つの値として扱える。
• ダブルクオートを含む値：She said "hi" は "She said ""hi""" と表記する。

id,note
1,"Tokyo, Japan"
2,"She said ""hi"""
3,"line1
line2"

2. JSON とは — 構造化・ネスト可・型あり

JSON（JavaScript Object Notation）は、オブジェクト（キーと値の集合 { }）と配列（順序付きリスト [ ]）を入れ子にして、構造のあるデータを表すテキスト形式です。CSV と違い、値が型を持つのが大きな特徴です。

• 型を区別する：文字列（"30"）と数値（30）、真偽値（true/false）、null がはっきり分かれます。
• ネストできる：オブジェクトの中にオブジェクトや配列を入れられ、階層構造をそのまま表せます。
• 配列を持てる：1つのキーに複数の値（リスト）を持たせられます。

{
  "id": 1,
  "name": "Alice",
  "age": 30,
  "active": true,
  "address": { "city": "Tokyo", "zip": "100-0001" },
  "tags": ["admin", "staff"]
}

このように JSON は、CSV では1セルに収まらない階層・配列・型を自然に表現できます。Web API のレスポンスやアプリの設定ファイルで広く使われるのは、この表現力のためです。

3. 比較表 — 可読性・ネスト・型・サイズ・用途

両者の特徴を一覧で整理します。どちらが優れているかではなく、データの形に合うかで選ぶのが基本です。

同じ表データなら CSV の方がサイズは小さくなりがちです。一方、ネストや型の区別が必要なら、行と列だけの CSV では表現しきれず JSON が必要になります。

4. 相互変換の考え方 — ヘッダーをキーに／ネストの平坦化

CSV → JSON は素直

CSV を JSON に変換する基本は、ヘッダー行を各オブジェクトのキーにし、2行目以降の各行を1つのオブジェクトにして配列にまとめる、という流れです。

id,name,age
1,Alice,30

↓

[
  { "id": "1", "name": "Alice", "age": "30" }
]

ここで注意したいのが型です。CSV の値は本来すべて文字列なので、上の "30" のように数値も文字列として読み込まれるのが既定の挙動です。数値や真偽値にしたい場合は、変換時に「この列は数値」と明示的に型変換する必要があります（自動推定は誤変換の原因にもなります）。

JSON → CSV は平坦化が難所

逆向きは一筋縄ではいきません。JSON はネストや配列を持てますが、CSV は2次元の表なので、階層をどう列に落とすか（平坦化）を決める必要があります。代表的な論点は次の2つです。

• キーの和集合をヘッダーにする：オブジェクトごとにキーが揃っていないことがあります。全オブジェクトに現れるキーの和集合を列に取り、欠けている値は空セルにします。
• ネスト・配列の平坦化：address.city のようにキーをドット区切りで平坦化したり、配列をどう1セルに収めるか（JSON 文字列のまま入れる、要素ごとに列を増やす等）を決めます。いずれも独自ルールであり、標準で定まったやり方はありません。

{ "id": 1, "address": { "city": "Tokyo" }, "tags": ["a","b"] }

↓（平坦化の一例）

id,address.city,tags
1,Tokyo,"[""a"",""b""]"

5. 文字コード・BOM・区切り（TSV／セミコロン）

CSV は仕様が緩い分、文字コードと区切り文字でのトラブルが起きやすい形式です。一方 JSON は標準で UTF-8 が前提なので、この種の問題は起きにくくなります。

• 文字コード：基本は UTF-8 を使うのが安全です。日本語環境では Shift_JIS の CSV も残っており、UTF-8 として開くと文字化けします。受け渡し時はエンコーディングを必ず合わせます。
• BOM：一部の表計算ソフトは、先頭に BOM（Byte Order Mark）付き UTF-8 でないと UTF-8 と認識せず文字化けすることがあります。逆に、BOM をデータの一部として誤って読み込む処理もあるため、付ける／付けないを意識して扱います。
• 区切り文字：カンマ以外も使われます。タブ区切りは TSV、地域や設定によってはセミコロン（;）区切りが使われます（小数点にカンマを使う地域などで顕著）。どの区切りかを取り違えると1列にまとまって読めません。
• 改行コード：RFC 4180 は CRLF を基本としますが、LF のみの CSV も多く、混在で崩れることがあります。

6. 使い分け — 表計算／設定／API

最後に、現場での選び方を用途別にまとめます。

• 表計算・データ交換 → CSV：Excel や Google スプレッドシートでそのまま開け、フラットな表データの一括エクスポート／インポートに最適です。行数が多い大量データの受け渡しにも向きます。
• 設定ファイル → JSON：ネストした設定や型のある値（数値・真偽値）を扱え、多くの言語やツールが標準で読み書きできます（コメント不可な点は留意）。
• Web API → JSON：階層構造や配列、型をそのまま運べるため、API のリクエスト／レスポンスの標準的な形式になっています。

迷ったら、「1枚の表に収まるか？」を基準にしてください。収まるなら CSV、ネストや配列・型の区別が要るなら JSON、と考えれば大きく外しません。