CSV / JSON / XML / YAML 比較と選択ガイド | Toolsbase

データ形式の選択がなぜ重要か

API レスポンスに XML を使い続けていたシステムを JSON に移行したら通信量が 40% 削減された、という事例は珍しくありません。逆に、設定ファイルに JSON を選んだせいでコメントが書けず保守性が下がった、というケースもあります。

CSV、JSON、XML、YAML——それぞれが異なる時代に異なる問題を解くために設計されました。仕様を理解した上で選択することで、パフォーマンスと保守性の両方を改善できます。

CSV ── 表形式データの最小解

仕様と歴史

CSV（Comma-Separated Values）は RFC 4180（2005年）で定義されていますが、実装の方言が多く、完全な標準化は困難です。起源は 1960 年代の IBM メインフレームにさかのぼり、スプレッドシートの普及とともに広まりました。

RFC 4180 のコア定義は簡潔です：

レコードは CRLF で区切る
最後のレコードの末尾改行は任意
フィールドはダブルクォートで囲める
フィールド内のダブルクォートは二重化（""）でエスケープ

構造上の制約

CSV は本質的に 2 次元のデータ（行と列）しか表現できません。

name,age,department,skills
Alice,28,Engineering,"JavaScript,TypeScript"
Bob,32,Design,"Figma,CSS"

フィールド内にカンマを含む場合、クォートが必要になります。ネスト構造、型情報、メタデータを持てないのが根本的な制約です。

import csv

# Python で CSV を安全に読む
with open('data.csv', newline='', encoding='utf-8') as f:
    reader = csv.DictReader(f)
    for row in reader:
        print(row['name'], row['age'])  # age は文字列として扱われる

向いている用途

データの移送（データベース間、システム間のバルクインポート）
Excel / Google Sheets との連携
ログファイルやセンサーデータ（構造が単純で大量のデータ）
データアナリストとのやり取り

JSON ── Web API のデファクトスタンダード

仕様

JSON（JavaScript Object Notation）は RFC 8259（2017年）と ECMA-404 で定義されています。RFC 8259 は以前の RFC 7159 を廃止したもので、エンコーディングを UTF-8 に一本化しています。

JSON が CSV より構造化されているのは、6 種類のデータ型（文字列、数値、真偽値、null、オブジェクト、配列）を持つためです。

{
  "user": {
    "name": "Alice",
    "age": 28,
    "skills": ["JavaScript", "TypeScript"],
    "active": true,
    "metadata": null
  }
}

パース速度と実装

JSON は実装が簡単で、ほぼすべての言語に標準パーサーが組み込まれています。JavaScriptエンジン（V8 など）は JIT コンパイルと組み合わせた高速パーサーを持ちます。

// JSON のパースとシリアライズ
const data = JSON.parse('{"name":"Alice","age":28}');
const json = JSON.stringify(data, null, 2); // 整形出力

// 大きなファイルにはストリーミングパーサー
const { parser } = require('stream-json');
const { streamArray } = require('stream-json/streamers/StreamArray');
const fs = require('fs');

fs.createReadStream('large.json')
  .pipe(parser())
  .pipe(streamArray())
  .on('data', ({ value }) => processItem(value));

JSON Schema によるバリデーション

JSON は単体ではスキーマを持ちませんが、JSON Schema（draft 2020-12）で構造を定義・検証できます。

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "required": ["name", "age"],
  "properties": {
    "name": { "type": "string", "minLength": 1 },
    "age":  { "type": "integer", "minimum": 0, "maximum": 150 }
  }
}

向いている用途

REST API のリクエスト / レスポンス
設定ファイル（コメントが不要な場合）
NoSQL データベースのドキュメント形式（MongoDB など）
フロントエンドとバックエンド間のデータ交換

XML ── 構造化データの先駆者

仕様

XML（Extensible Markup Language）は W3C によって 1998 年に勧告された仕様です。HTML に似たタグ構文を持ち、名前空間・属性・テキストコンテンツを柔軟に表現できます。

<?xml version="1.0" encoding="UTF-8"?>
<users xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:noNamespaceSchemaLocation="users.xsd">
  <user id="1">
    <name>Alice</name>
    <age>28</age>
    <skills>
      <skill>JavaScript</skill>
      <skill>TypeScript</skill>
    </skills>
  </user>
</users>

XSD によるスキーマ定義

XML Schema Definition（XSD）は XML で最も成熟したスキーマ言語です。型・制約・カーディナリティ（出現回数）を厳密に定義できます。

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="user">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="name" type="xs:string"/>
        <xs:element name="age">
          <xs:simpleType>
            <xs:restriction base="xs:integer">
              <xs:minInclusive value="0"/>
              <xs:maxInclusive value="150"/>
            </xs:restriction>
          </xs:simpleType>
        </xs:element>
      </xs:sequence>
      <xs:attribute name="id" type="xs:positiveInteger" use="required"/>
    </xs:complexType>
  </xs:element>
</xs:schema>

ファイルサイズの問題

XML はタグ名を開始タグと終了タグに重複して書くため、同等のデータを JSON で表現した場合より 3〜5 倍大きくなることがあります。

同じデータの比較（参考値）:
JSON: 120 bytes
XML:  380 bytes （タグの繰り返しで増加）
YAML: 100 bytes
CSV:   50 bytes （構造を捨てた場合）

向いている用途

SOAP Web サービス（エンタープライズシステムとの連携）
ドキュメント指向のデータ（SVG、XHTML、Office Open XML）
名前空間による厳格な型システムが必要な場合
レガシーシステムとの統合

YAML ── 人間可読性を最大化した設定言語

仕様

YAML（YAML Ain't Markup Language）は YAML 1.2.2（2021年10月）が現行仕様です。JSON の厳格なスーパーセット（YAML 1.2 以降、有効な JSON はすべて有効な YAML）として設計されています。

# YAML はコメントが書ける
user:
  name: Alice
  age: 28
  skills:
    - JavaScript
    - TypeScript
  active: true
  metadata: null  # null は ~ と書くこともできる

アンカーとエイリアス

YAML の強力な機能として、アンカー（&）とエイリアス（*）による値の再利用があります。

defaults: &defaults
  timeout: 30
  retries: 3
  log_level: info

production:
  <<: *defaults  # マージキー
  log_level: warning  # オーバーライド
  database: prod-db.example.com

staging:
  <<: *defaults
  database: staging-db.example.com

YAML のパースに関する注意点

YAML は表現力が高い反面、予期しない型変換が起きやすいという罠があります。

# 問題のある例
country_code: NO   # ノルウェーの国コードだが、false に変換される（YAML 1.1）
version: 1.0       # 浮動小数点数として扱われる
date: 2024-01-01   # 日付オブジェクトに変換される（パーサーによる）
port: 8080         # 整数として扱われる（意図通り）

YAML 1.2 では true/false のみが真偽値です（YES/NO/on/off は文字列）。ただし古いパーサーが YAML 1.1 に準拠している場合は NO が false になります。CI/CD 設定ファイルでの実害が多い トラップです。

import yaml

# PyYAML デフォルトは YAML 1.1 準拠
yaml.safe_load('country: NO')  # {'country': False}

# ruamel.yaml は YAML 1.2 準拠
from ruamel.yaml import YAML
yml = YAML()
yml.load('country: NO')  # {'country': 'NO'}

向いている用途

CI/CD パイプライン設定（GitHub Actions、GitLab CI など）
アプリケーション設定ファイル（人間が頻繁に編集するもの）
インフラ設定（Kubernetes マニフェスト、Ansible Playbook、Helm Charts）
コメントと階層構造の両方が必要な設定

4 形式の総合比較

特性	CSV	JSON	XML	YAML
人間可読性	高い（単純データ）	高い	普通	非常に高い
データ型	なし	6 種	なし（文字列のみ）	豊富
コメント	不可	不可	可能	可能
ネスト構造	不可	可能	可能	可能
スキーマ	なし	JSON Schema	XSD / DTD	JSON Schema（流用）
相対ファイルサイズ	最小	小	最大	小〜中
パース複雑度	低い	低い	高い	中程度
標準化	RFC 4180	RFC 8259	W3C Rec	YAML 1.2.2
ストリーミング対応	可能	可能	可能（SAX）	限定的
バイナリ表現	不可	不可（Base64 回避策）	不可	不可

用途別の選択フロー

API レスポンス

推奨: JSON。REST API の事実標準です。XML は SOAP が求められるエンタープライズシステムを除き、新規設計では選ぶ理由がありません。

GET /api/users/1
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json

{"id": 1, "name": "Alice", "age": 28}

設定ファイル

推奨: YAML または TOML。コメントが書けること、インデントによる階層表現が読みやすいことが主な理由です。

# GitHub Actions workflow
name: CI
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm test

データ交換（バルクデータ）

推奨: CSV（構造が単純な場合）または JSON Lines（JSONL）。CSV は Excel や pandas との親和性が高く、データアナリストへの受け渡しに適しています。

# JSONL (JSON Lines) - 1行1オブジェクトのストリーミングに適した形式
import json

with open('events.jsonl', 'w') as f:
    for event in events:
        f.write(json.dumps(event) + '\n')

ログ出力

推奨: JSON（構造化ログ）。ログを機械的に処理・集計する場合、JSON の構造化ログが最も扱いやすいです。

{"timestamp": "2026-04-15T10:30:00Z", "level": "ERROR", "message": "Connection failed", "service": "payment", "user_id": 42}

形式間の変換

各形式間でのデータ変換が必要な場面は多くあります。

CSV → JSON 変換: CSV-JSONコンバーター
XML → JSON 変換: XML-JSONコンバーター
YAML ↔ JSON 変換: YAML-JSONコンバーター
JSON の整形・バリデーション: JSONフォーマッター

まとめ

用途	推奨形式
REST API	JSON
SOAP / エンタープライズ連携	XML
設定ファイル（コメント必要）	YAML
大量の表形式データ移送	CSV
ストリーミングログ	JSON Lines
Kubernetes / CI/CD	YAML

データ形式の選択は一度決めると変更コストが高いため、プロジェクト初期に要件を整理することが重要です。特に API では JSON、CI/CD 設定では YAML というのが 2026 年時点での実務的な標準と言えます。

参考文献

RFC 8259 — The JavaScript Object Notation (JSON) Data Interchange Format (2017年、IETF)
RFC 4180 — Common Format and MIME Type for CSV Files (2005年、IETF)
W3C XML 1.0 Specification (W3C勧告)
YAML 1.2.2 Specification (2021年10月)
JSON Schema Draft 2020-12