JSONとCSVの違い：表と入れ子のデータに適した形式

ファイルをエクスポートするとき、CSVとJSONのどちらかを選ぶ画面をよく見かけます。CSVはExcelで開けて、JSONは開発者が使う形式だという理解だけでは、出力後に注文項目が消えたり会員番号の先頭の0がなくなったりする理由を見落としかねません。選択の基準は、誰がファイルを開くかに加えて、データがどのような構造を持つかです。この記事では説明用に小さな注文データを作り、形式の選択から変換後の確認までの方法を扱います。

1. 表の1行と入れ子構造の違いをまず確認する

CSVは、行とフィールドからなる表形式を表すのに適しています。例えば1行が1人の会員を表し、列が会員番号、名前、登録日なら、構造は単純です。一方、1つの注文に配送先オブジェクトと複数の商品項目が含まれる場合は、JSONのオブジェクトと配列で関係を表せます。JSONオブジェクトは名前と値の組であり、配列は順序のある値のリストです。配列の順序とオブジェクト項目の表示順を同じものとして扱わないほうがよいでしょう。

JSONには文字列、数値、真偽値、null、オブジェクト、配列があります。文書全体が必ず波括弧で始まる必要はありません。単独の値や配列もJSON文書になれますが、実際に読み込むプログラムが特定の構造だけを受け付けるかどうかは別途確認しなければなりません。形式自体が許す構文と、特定のサービスが求める入力仕様は異なります。ファイルの拡張子が合っているだけでは、アップロードの互換性は保証されません。

比較する点	CSV	JSON
基本構造	行とフィールドを中心とする表	オブジェクトと配列で入れ子の関係を表現
値の種類	読み込むツールと別途の規則で解釈	文字列・数値・ブール値・nullなどを区別
複数の商品を含む注文	項目ごとの行に展開するか、別の表に分ける	注文内の項目配列として表現
人が確認する場合	表編集ツールで行・列を比較しやすい	階層と値の種類を確認しやすい
必ず合意すべき内容	区切り文字・文字コード・空の値・列の意味	フィールドの意味・必須値・重複する名前の処理

2. 同じ注文を2つの形式で表現する

以下のデータは実際の顧客情報ではなく、説明用の例です。注文番号は数値として計算する値ではなく、文字を保持する識別子なので文字列で記しています。商品が2つあるため、項目配列には2つのオブジェクトがあります。金額と決済情報は含めていません。形式の違いを確かめるために不要な項目を減らすと、変換の過程でどの情報が消えたかを読み取りやすくなります。

{
  "order_id": "0012",
  "customer": "김예시",
  "items": [
    {"sku": "A01", "quantity": 2},
    {"sku": "B02", "quantity": 1}
  ],
  "memo": null
}

この構造を1つのCSVに展開する場合、商品項目ごとに1行を作れます。注文番号と顧客名は繰り返されますが、その繰り返しが重複注文を意味するわけではありません。1行の意味を「注文」から「注文内の商品項目」に変えた結果です。注文数を数える際に行数をそのまま使うと、1つの注文を2件と数えてしまいます。変換前後で何を1件として数えるかを先に定める必要があります。

order_id,customer,sku,quantity
0012,김예시,A01,2
0012,김예시,B02,1

上のCSV例は項目構造を示すためにmemoを省略しているので、JSON全体を損失なく変換した結果ではありません。注文レベルのメモと商品レベルの情報を両方保持するには、注文表と商品項目表を分ける方法もあります。注文表には注文番号が1回、項目表には同じ注文番号が複数回現れます。2つの表を結ぶキーが注文番号です。これはこの記事で提案する設計例であり、CSVが自動的に関係を管理するという意味ではありません。2つのファイルを渡すなら、結合の規則とキーが欠けている場合の処理も説明しなければなりません。

3. CSVのカンマと引用符を正確に扱う

RFC 4180は、広く使われるCSVの表現を説明する情報提供文書です。すべてのツールが完全に同じ規則で読み込む保証はありません。文書で説明される方法では、カンマ、改行、二重引用符を含むフィールドを二重引用符で囲み、フィールド内の二重引用符は2つ重ねて表します。この規則を知らずに文字列を単純にカンマで分割すると、1つのメモ欄が2列に分かれる場合があります。

id,memo
01,"회의, 자료 확인"
02,"그는 ""확인""이라고 적었다"

最初のメモ内のカンマは列の区切りではなく、メモの内容です。2つ目のメモの連続した二重引用符は、読み込み時には内容中の1つの二重引用符を表します。引用されたフィールド内には改行も含められるため、テキストファイルの物理的な行数が常にデータレコード数と一致するわけではありません。CSV専用の読み込み機能でレコードを数え、単純な行数計算は補助的な確認に使ってください。

区切り文字がセミコロンやタブのファイルも表データとして渡されますが、受け取るプログラムの選択画面で実際の区切り文字を合わせる必要があります。すべての内容が最初の列にまとまっている場合、データがないのではなく、区切り文字の解釈が合っていない可能性があります。列が急に増えた場合は、引用処理や内容中のカンマを確認します。手作業でカンマを消す前に元のファイルをコピーして保管すると、復元しやすくなります。

4. 数字に見える識別子を数値に変えない

0012は、注文番号の例では4桁の識別子です。表計算ソフトがこれを数値12と推定すると、表示やエクスポート時に先頭の0が消える場合があります。JSONの例では"0012"のように文字列として記して種類を区別できますが、CSVではその列をテキストとして読み込むよう、インポート設定や別途の列仕様を伝える必要があります。CSVの二重引用符だけで、すべてのプログラムの数値推定を防げるとは考えないでください。

電話番号、郵便番号、商品コードにも同じ判断が必要です。足したり平均を求めたりする値か、形を保持すべき識別子かを区別してください。日付のように見えるコードが自動的に日付へ変換される場合は、列をテキストに指定して元の値と比較します。すでに先頭の0が消えているなら、元データや桁数の規則を知らなければ復元できません。むやみに0を付け足すと、元から桁数が異なるコードとの区別が難しくなります。

5. 空文字列、null、欠落したフィールドを区別する

JSONの"memo": ""は空文字列という値がある状態であり、"memo": nullはnullという値がある状態です。オブジェクトにmemo項目自体がなければ、さらに別の状態です。業務でこの3つを同じ意味として使うこともできますが、形式が自動的に同じ意味を定めるわけではありません。「内容なし」「まだ収集していない」「その項目には非対応」を分けたいなら、入力規則を明示する必要があります。

CSVの空欄をJSONに変える際にすべてnullにすると、元は空文字列を意図していた値が区別できなくなる場合があります。逆にJSONのnullを文字列"null"に変えると、値の種類が変わります。変換前に、列ごとの空の値の処理表を作ってください。例えばメモの空欄は空文字列、未確定の数量はエラー、選択されていない配送日はnullとして処理する、といった規則です。この規則には、データの作成者と読み込む側の合意が必要です。

6. JSONのエラーは構文と構造を分けて探す

通常のJSON構文では、プロパティ名と文字列に二重引用符を使い、最後の項目の後にカンマを追加しません。コメントを含む設定ファイルや、一重引用符を使う別言語のオブジェクト表現をそのままJSONと呼ぶと、読み込みエラーが起こる場合があります。まず構文チェックで括弧、引用符、カンマを確認し、次に必須フィールドと値の種類を確認します。構文が正しくても、数量が負の数だったり注文番号が欠けていたりするデータは、業務仕様に合わない場合があります。

オブジェクトで同じ名前を繰り返すことは避けてください。RFC 8259は名前を一意にすることを推奨しており、重複する名前の扱いは実装ごとに異なる場合があります。quantityが2回現れるデータを読み込むツールがどちらの値を残すかに依存すると、変換結果を信頼しにくくなります。同種の複数の値には、無理に別々の名前を作るより、配列や別の項目構造を検討します。

7. 文字コードと変換結果を段階ごとに確認する

相互運用を行うJSON交換では、UTF-8の使用が重要です。CSVでは、ファイルを開くツールの文字コード解釈も確認しなければなりません。ハングルが文字化けして見えるときは、データを入力し直すよりも、インポート画面で元の文字コードを確認してください。JSONの構文エラーと文字化けは異なる問題かもしれません。正常に読み込めた元データを基準に変換し、人が読む名前だけでなく識別子の文字も照合します。

説明用の注文をCSVの2行に展開した場合、検証値は「注文番号の一意な数1、項目数2、数量の合計3」です。再びJSONにまとめる際は、項目が2つ含まれているかを確認します。行数だけが同じだから成功と判断すると、ある項目が別の項目として複製された誤りを見落とす場合があります。項目コードの集合、識別子、合計、空の値の状態を併せて比較すると、変換で失われた情報を見つけやすくなります。

ファイルを渡す際は、小さな例とともに列やフィールドの説明書を残してください。項目名、意味、値の種類、空の値の規則、1行の意味を記すことから始められます。データ形式を変えても、この説明は保つ必要があります。CSVをJSONに変換するツールを選ぶ前に、保持すべき意味を定めれば、変換ツールの自動推定を確認する基準が得られます。

8. 形式を選択する最終チェックリスト

• 1行がどの単位を表すかを定めたか？
• 1つの項目に複数の下位項目が含まれるか？
• 数値と識別子を区別したか？
• 空文字列・null・欠落の意味を定めたか？
• CSVの区切り文字と引用規則を確認したか？
• ハングルの文字コードを確認したか？
• 変換前後の項目数と一意なキーを比較したか？
• 実際に受け取るプログラムの入力仕様を確認したか？

単純な表を人が確認して交換するならCSVが便利な場合があり、階層と値の種類を保持して交換するならJSONが適している場合があります。どちらかが常に優れているわけではありません。データの関係、使用するツール、受け渡しの規則を併せて定め、変換後も同じ意味が残っているかを確認することが、実用的な選択基準です。

公式出典と執筆基準

• IETF RFC 8259：JSON形式
• IETF RFC 4180：CSV形式とMIMEタイプ

資料確認日：2026-10-10。実際に開いた公式資料をもとにAIが作成した説明です。別途示した計算・コード・確認事例は説明用であり、ユーザー環境を直接試験した結果や実測結果ではありません。公開日には機能と資料の変更の有無を再確認します。