ウェブアプリケーションの設定、サービス間のデータ交換、スプレッドシートエクスポートの分析、APIレスポンスの読み取りなど、構造化テキストフォーマットで保存されたデータに出会う場面は多くあります。最も一般的な4つはJSON、YAML、CSV、XMLです。
各フォーマットは異なる目的を念頭に設計されており、適切なものを選ぶにはユースケースに依存します。この記事では、各フォーマットの概要、見た目、使いどころ、そして比較について説明します。
JSON — JavaScript Object Notation
JSONはウェブにおけるデータ交換フォーマットとして主流の地位を確立しました。名前に反して言語に依存せず、あらゆる場所で使われています。
構文の例:
{
"name": "Alice Martin",
"age": 34,
"skills": ["Python", "SQL", "Docker"],
"address": {
"city": "Lyon",
"country": "France"
}
}
主な特徴:
- クリーンで読みやすい構文のキーバリューペア
- 文字列、数値、真偽値、配列、オブジェクト、nullに対応
- 標準JSONではコメント不可
- 厳密な構文 — 末尾のカンマやシングルクォートはエラー
一般的なユースケース: REST API、設定ファイル(package.json、tsconfig.json)、NoSQLデータベース(MongoDB)、フロントエンドとバックエンド間のデータ交換。
豆知識。 JSONの厳密な構文は強みでもあり弱みでもあります。パースが信頼性が高く曖昧さがないようになる一方で、カンマ1つの欠如や余分な末尾カンマでファイル全体が壊れてしまいます。
YAML — YAML Ain't Markup Language
YAMLは、最も人間が読みやすいデータシリアライゼーションフォーマットとして設計されました。括弧の代わりにインデントを使用し、特に設定ファイルで人気があります。
構文の例:
name: Alice Martin
age: 34
skills:
- Python
- SQL
- Docker
address:
city: Lyon
country: France
主な特徴:
- インデントベースの構造(括弧や波括弧なし)
#でコメントに対応- JSONのすべてのデータ型に加え、日付や複数行文字列などにも対応
- 空白に敏感 — インデントの誤りでファイルが壊れる
一般的なユースケース: Docker Composeファイル、Kubernetesマニフェスト、CI/CDパイプライン(GitHub Actions、GitLab CI)、Ansibleプレイブック、Hugo/Jekyll設定。
YAMLはJSONのスーパーセットであり、有効なJSONドキュメントはそのまま有効なYAMLでもあります。しかし、YAMLの柔軟性は諸刃の剣にもなりえます。暗黙的な型変換(例えばyesが真偽値のtrueとして解釈される、3.10が3.1になるなど)が多くの微妙なバグの原因となっています。
CSV — Comma-Separated Values
CSVは最もシンプルな構造化データフォーマットです。テーブルデータをプレーンテキストとして保存し、各行が1レコード、値はカンマ(あるいはセミコロン、タブなどの区切り文字)で区切られます。
構文の例:
name,age,city,country
Alice Martin,34,Lyon,France
Bob Dupont,28,Paris,France
Carol Smith,41,London,UK
主な特徴:
- 非常にシンプル — 区切り文字付きのテキストだけ
- データ型なし — すべてが文字列
- ネストしたデータを表現する標準的な方法がない
- 公式のユニバーサル標準がない(RFC 4180は存在するが普遍的には守られていない)
- ファイルサイズが非常に小さい
一般的なユースケース: スプレッドシートのエクスポート、データベースのインポート/エクスポート、データ分析(pandas、R)、シンプルなデータ交換、ログファイル。
CSVのシンプルさは最大の強みであると同時に最大の制限でもあります。フラットなテーブルデータには完璧ですが、階層構造の表現はできません。エッジケース(値内のカンマ、複数行フィールド、エンコーディング問題)により、パースは見た目ほど単純ではありません。
XML — Extensible Markup Language
XMLはJSONが主流になる前の主要なデータ交換フォーマットでした。HTMLに似たタグベースの構文を使用し、スキーマ、名前空間、変換などの高度な機能をサポートします。
構文の例:
<?xml version="1.0" encoding="UTF-8"?>
<person>
<name>Alice Martin</name>
<age>34</age>
<skills>
<skill>Python</skill>
<skill>SQL</skill>
<skill>Docker</skill>
</skills>
<address>
<city>Lyon</city>
<country>France</country>
</address>
</person>
主な特徴:
- 開始タグと終了タグによるタグベースの構造
- 属性、名前空間、スキーマ(XSD)、変換(XSLT)をサポート
- コメント対応
- 他のフォーマットと比べて非常に冗長
- 厳密なバリデーションを備えた非常によく定義された標準
一般的なユースケース: SOAPウェブサービス、エンタープライズ統合、ドキュメントフォーマット(DOCX、SVG、RSS)、Java/.NETエコシステムの設定ファイル、政府・金融データ交換。
XMLはJSONやYAMLよりも冗長ですが、スキーマバリデーション機能により、データの整合性とシステム間の正式な契約が重要なコンテキストでは欠かせない存在です。
並列比較
| 特徴 | JSON | YAML | CSV | XML |
|---|---|---|---|---|
| 可読性 | 良好 | 優秀 | 良好(テーブル型) | やや低い |
| 冗長性 | 低い | 低い | 非常に低い | 高い |
| コメント | 不可 | 可能 | 不可 | 可能 |
| ネストデータ | 対応 | 対応 | 非対応 | 対応 |
| データ型 | 基本型 | 豊富 | なし(すべて文字列) | スキーマによる |
| スキーマバリデーション | JSON Schema | 標準なし | なし | XSD |
| ファイルサイズ | 小 | 小 | 最小 | 大 |
| パース速度 | 高速 | 中程度 | 高速 | 中程度 |
| 主な領域 | Web API | DevOps設定 | データ/スプレッドシート | エンタープライズ |
使い分けの指針
- JSONを選ぶのは、Web APIの構築、JavaScript/TypeScriptプロジェクトの設定保存、サービス間のデータ交換の場合です。現代のほとんどのアプリケーションにおけるデフォルトの選択肢です。
- YAMLを選ぶのは、人間が頻繁に読み書きする設定ファイルを作成する場合です。可読性とコメントサポートにより、DevOpsやInfrastructure as Codeに最適です。
- CSVを選ぶのは、テーブルデータを扱う場合、スプレッドシートやデータベースとの入出力、ファイルサイズを最小にする必要がある場合です。階層的なものには使わないでください。
- XMLを選ぶのは、エンタープライズシステム、SOAP API、正式なスキーマバリデーションが必要なコンテキストで作業する場合です。ドキュメント指向のマークアップ(SVGやRSSなど)が必要な場合にも適しています。
フォーマット間の変換
これらのフォーマット間の変換はよくあるタスクです。いくつか注意点があります:
- JSONからYAML(およびその逆)は、YAMLがJSONのスーパーセットであるため、通常はロスレスです。
- CSVからJSON/YAMLはフラットデータには問題ありませんが、ネストされた出力のための構造に関する決定が必要です。
- XMLからJSONは情報が失われる可能性があります(属性、名前空間、順序)。JSONには対応する概念がないためです。
- 任意のフォーマットからCSVは、データがフラットであるか、意味のある形でフラット化できる場合にのみ機能します。
ヒント。 フォーマット間の変換を行う際は、常に出力を確認してください。自動変換では、特にXMLの属性、YAMLの型変換、CSVのエンコーディングのエッジケースにおいて、データが暗黙的に失われることがあります。
さらに詳しく
ToolK.ioでは、JSON、YAML、CSV、XML間の変換、データのフォーマットやバリデーション、そしてプロジェクトで構造化データを扱うための関連チュートリアルなど、無料ツールを提供しています。
