JSONとCSVの使い分け｜設計データを壊さず再利用するための選び方

設計データや計算結果をファイルとして保存するとき、「CSVで十分なのか、それともJSONにすべきなのか」は意外に重要な判断です。

どちらもテキスト形式で、ExcelやPythonなどから扱えます。しかし、得意とするデータ構造は大きく異なります。

たとえば、次のような表形式のデータはCSVと相性がよいでしょう。

diameter_mm,length_mm,material
50,300,S45C
80,500,SUS304

一方、1個の油圧シリンダについて内径、ロッド径、ストローク、使用圧力、計算結果などをひとまとまりとして保存したい場合、JSONの方が構造を表現しやすくなります。

{
  "cylinder": {
    "bore_mm": 80,
    "rod_mm": 45,
    "stroke_mm": 500
  },
  "operating_pressure_mpa": 14
}

重要なのは「JSONの方が新しいからJSONを使う」といった判断ではありません。

保存するデータの構造と、そのデータを将来どう再利用するかによって形式を選ぶことが基本です。

結論：表ならCSV、構造ならJSON

大まかな判断基準は次のようになります。

ただし、実務ではどちらか一方に統一する必要はありません。

たとえば、

入力マスタ → CSV
計算条件 → JSON
計算結果 → JSON
集計結果 → CSV
データベース → SQL

のように、用途ごとに形式を使い分ける方が合理的です。

CSVとは何か

CSVはComma-Separated Valuesの略で、基本的には1レコードを1行として、各フィールドを区切り文字で分離する形式です。

RFC 4180では、一般的なCSV形式として、レコードを行単位で記述し、フィールドをカンマで区切る形式が文書化されています。また、カンマ、改行、ダブルクォートを含むフィールドをダブルクォートで囲む方法なども示されています。

たとえば部品データなら、

part_no,diameter_mm,length_mm,material
A001,50,300,S45C
A002,80,500,SUS304
A003,100,250,SS400

と表現できます。

これはそのまま表になります。

この「行と列」という単純さがCSV最大の長所です。

JSONとは何か

JSONはJavaScript Object Notationの略です。

RFC 8259では、JSONは構造化データを表現するための軽量なテキスト形式として定義されています。JSONでは文字列、数値、真偽値、nullに加え、オブジェクトと配列を表現できます。

たとえば機械の設計条件を、

{
  "machine": {
    "name": "press_001",
    "cylinder": {
      "bore_mm": 100,
      "rod_mm": 56,
      "stroke_mm": 600
    },
    "hydraulic": {
      "pressure_mpa": 14,
      "flow_l_min": 40
    }
  }
}

のように保存できます。

ここでは、

machine
 ├─ name
 ├─ cylinder
 │   ├─ bore_mm
 │   ├─ rod_mm
 │   └─ stroke_mm
 └─ hydraulic
     ├─ pressure_mpa
     └─ flow_l_min

という階層関係がファイルそのものに表現されています。

CSVでは、このような入れ子構造を直接表現するのは得意ではありません。

CSVが設計データに向いているケース

CSVが特に強いのは、同じ属性を持つデータが大量に並ぶ場合です。

たとえば材料マスタを考えます。

material,density_kg_m3,young_modulus_gpa
SS400,7850,200
S45C,7850,205
A5052,2680,70

すべての行が、

材料名
密度
ヤング率

という同じ列構造を持っています。

このようなデータでは、JSONにするメリットはそれほど大きくありません。

CSVならExcelで開きやすく、Pythonのcsvモジュールやpandasなどからも読み込みやすいため、マスタデータや一覧データの受け渡しに適しています。

JSONが設計データに向いているケース

JSONが強いのは、1つの対象に複数種類の情報が属している場合です。

たとえば油圧シリンダの設計データなら、

{
  "id": "CYL-001",
  "geometry": {
    "bore_mm": 100,
    "rod_mm": 56,
    "stroke_mm": 600
  },
  "operating_conditions": {
    "pressure_mpa": 14,
    "flow_l_min": 40
  },
  "calculated": {
    "extension_force_kn": 109.96,
    "extension_speed_mm_s": 84.88
  }
}

のように、

• 識別情報
• 形状
• 使用条件
• 計算結果

を分離できます。

これによってプログラム側でも、

bore = data["geometry"]["bore_mm"]
pressure = data["operating_conditions"]["pressure_mpa"]

のように、値が何を意味しているのかを構造として扱えます。

「型」の違いは重要

CSVを扱うときに注意したいのがデータ型です。

CSVは基本的にテキストとして値を記録します。

たとえば、

part_no,diameter,enabled
00123,50,true

を読み込んだとき、

00123
50
true

が、

• 文字列なのか
• 整数なのか
• 真偽値なのか

という意味はCSVファイルだけでは十分に表現できません。

特に00123を表計算ソフトで数値として扱えば、先頭の0が失われる可能性があります。

JSONでは、

{
  "part_no": "00123",
  "diameter": 50,
  "enabled": true
}

とすることで、

"00123" → 文字列
50      → 数値
true    → 真偽値

を区別できます。

ただしJSONにも注意点があります。RFC 8259は数値表現を定義していますが、受け取り側のソフトウェアがどの範囲・精度まで正確に扱えるかは実装に依存します。したがって、非常に大きな整数や厳密な10進値などでは、アプリケーション側の型設計も必要です。

単位は値と分離する

工学データでは、形式以上に重要なのが単位の管理です。

次のデータは危険です。

{
  "pressure": 14,
  "flow": 40
}

14がMPaなのかbarなのか、40がL/minなのかm³/sなのか分かりません。

少なくとも、

{
  "pressure_mpa": 14,
  "flow_l_min": 40
}

のように単位を明示する方法があります。

さらに汎用性を上げるなら、

{
  "pressure": {
    "value": 14,
    "unit": "MPa"
  },
  "flow": {
    "value": 40,
    "unit": "L/min"
  }
}

という構造も考えられます。

前者は単純で扱いやすく、後者は単位変換システムへ拡張しやすい設計です。

どちらを採用するかは用途次第ですが、単位を暗黙にしないことが重要です。

CSVでも単位を列名に入れる

CSVでも同じ考え方が使えます。

bore_mm,rod_mm,pressure_mpa,flow_l_min
100,56,14,40

こうすれば、

bore,rod,pressure,flow
100,56,14,40

よりデータの意味が明確になります。

将来Pythonやデータベースへ移行するときにも、単位情報を失いにくくなります。

CSVのカンマや改行を手作業で処理しない

CSVは単純に見えますが、

AAA,BBB,CCC

を単純な文字列分割だけで処理すると問題が起きます。

たとえば、

part_no,description
A001,"plate, machined"

では、description内にもカンマがあります。

RFC 4180では、カンマや改行などを含むフィールドをダブルクォートで囲む形式が示されています。

そのためPythonでは、

line.split(",")

ではなく標準のcsvモジュールを使う方が安全です。

import csv

with open("parts.csv", newline="", encoding="utf-8") as f:
    reader = csv.DictReader(f)

    for row in reader:
        print(row["part_no"], row["description"])

Python公式ドキュメントでも、CSVファイルをファイルオブジェクトとして扱う場合はnewline=''で開くことが示されています。また、文字コードを指定する場合はencoding引数を使用できます。

JSONはPythonとの相性がよい

Python標準ライブラリにはJSONを扱うjsonモジュールがあります。

たとえば、

import json

with open("cylinder.json", encoding="utf-8") as f:
    data = json.load(f)

bore = data["geometry"]["bore_mm"]
rod = data["geometry"]["rod_mm"]

print(bore, rod)

のように、JSONのオブジェクトをPythonの辞書として扱えます。

設計条件を読み込み、

JSON
 ↓
Python
 ↓
計算
 ↓
結果追加
 ↓
JSON保存

という処理パイプラインを作りやすいのが利点です。

JSONを「データベース代わり」にしすぎない

JSONが便利だからといって、すべてを巨大なJSONファイルへ入れるのは適切ではありません。

たとえば数十万件の部品データを、

[
  {...},
  {...},
  {...}
]

と1ファイルへ保存すると、

• 特定レコードの検索
• 同時更新
• 部分更新
• インデックス
• データ整合性
• 複数ユーザーからの利用

などで不利になります。

データ量や利用者が増えた段階では、SQLite、PostgreSQL、MySQLなどのデータベースを検討する方が適切です。

つまりJSONは、

構造化されたファイル形式

として優秀ですが、

データベースそのものではない

という区別が必要です。

CSVからJSONへ変換する

実務ではCSVとJSONを対立させるのではなく、相互変換できるようにしておくと便利です。

たとえばPythonなら、

import csv
import json

rows = []

with open("parts.csv", newline="", encoding="utf-8") as f:
    reader = csv.DictReader(f)

    for row in reader:
        rows.append(row)

with open("parts.json", "w", encoding="utf-8") as f:
    json.dump(
        rows,
        f,
        ensure_ascii=False,
        indent=2
    )

と変換できます。

ただし、このままではCSVから読み込んだ数値も文字列になります。

したがって本格運用では、

row["diameter_mm"] = float(row["diameter_mm"])

のような型変換や、入力検証を行う必要があります。

ここが重要です。

ファイル形式の変換と、データ意味の変換は別処理です。

単にCSVをJSONへ変換しただけでは、正しいデータモデルになったとは限りません。

データ形式より先にスキーマを決める

長期的に再利用するデータでは、

CSVかJSONか

より先に、

何を保存するか

を決める必要があります。

たとえばシリンダデータなら、

id
bore
rod
stroke
pressure
flow

だけでなく、

各値の型
単位
必須か任意か
許容範囲
欠損値の扱い
バージョン

まで定義すると、再利用性が大きく上がります。

概念的には、

{
  "id": "CYL-001",
  "schema_version": "1.0",
  "geometry": {
    "bore_mm": 100.0,
    "rod_mm": 56.0,
    "stroke_mm": 600.0
  }
}

のようにスキーマバージョンを持たせる方法もあります。

後からデータ項目を変更した場合でも、

schema_version = 1.0
schema_version = 2.0

を判定して変換処理を用意できます。

実務での選定ルール

設計データを保存するときは、次の順で判断すると整理しやすくなります。

まず、データが完全な表形式ならCSVを第一候補にします。

部品一覧
材料マスタ
計測ログ
計算結果一覧

などです。

次に、データが階層構造を持つならJSONを候補にします。

機械
 ├─ シリンダ
 ├─ ポンプ
 ├─ バルブ
 └─ 計算条件

のような構造です。

そして、データ件数や更新頻度、検索要求が大きくなったらデータベースへ移行します。

つまり、

表形式
 ↓
CSV

構造化オブジェクト
 ↓
JSON

大量データ・検索・更新・共有
 ↓
DB

という整理ができます。

将来の自動化を考えるならデータとロジックを分離する

設計自動化では、計算式の中に入力値を直接埋め込むより、

データ
↓
検証
↓
計算ロジック
↓
結果

と分離する方が拡張しやすくなります。

たとえば、

cylinder.json
        ↓
validator.py
        ↓
calculation.py
        ↓
result.json

という構造です。

さらに結果を一覧化したければ、

result.json
    ↓
export_csv.py
    ↓
results.csv

と変換できます。

こうするとJSONとCSVのどちらか一方にシステム全体を依存させず、それぞれの得意分野を利用できます。

まとめ

CSVとJSONには明確な得意分野があります。

CSVは、同じ列構造を持つ大量のデータを表として扱う場合に適しています。Excelとの受け渡しや一覧データにも向いています。

JSONは、階層構造、配列、数値、真偽値などを含む構造化データに向いています。設定ファイルやAPI、Pythonを使った自動処理とも相性がよい形式です。

重要なのは、どちらかを万能形式として採用することではありません。

一覧・マスタ → CSV
構造化データ・設定 → JSON
大量検索・共有 → DB

というように役割を分けることで、データを長期間再利用しやすくなります。

そして工学データでは、ファイル形式以上に、

• 項目名
• データ型
• 単位
• 必須条件
• 許容値
• スキーマバージョン

を明確にすることが重要です。

CSVやJSONはデータを入れる「器」です。

その器の中に意味が明確で、機械的に検証できるデータモデルを作ることが、設計計算、Python、自動化、Webツール、データベースへ発展させる基礎になります。

参考情報

RFC 8259 — The JavaScript Object Notation (JSON) Data Interchange Format

RFC 4180 — Common Format and MIME Type for CSV Files

Python csv module documentation