DevOpsエンジニアがKubernetes設定をYAMLでエクスポートしたが、JSONしか受け付けないAPIに送る必要がある。アナリストがJSON形式のAPIレスポンスデータを受け取ったが、スプレッドシートが必要。データサイエンティストがデータベースからCSVをエクスポートしたが、Webダッシュボード用に構造化されたJSONが必要。
フォーマット変換は単なる機械的な操作ではありません。各フォーマットは異なるトレードオフを持ち、変換時に何が失われるかを理解することは、変換方法を知ることと同じくらい重要です。
3つのフォーマット、3つの哲学
各フォーマットは異なる対象者と異なる課題のために設計されました：
| フォーマット | 誕生年 | 設計目的 | 基本哲学 |
|---|---|---|---|
| CSV | 約1972年 | プログラム間のデータ交換 | 最大限のシンプルさ — 行と列のみ |
| JSON | 2001年 | Webデータ交換 | 厳格なルールによる機械可読の構造化データ |
| YAML | 2001年 | 設定ファイル | 最小限の構文による人間可読の構造化データ |
CSVはデータがフラットなテーブルであることを前提とします。すべての値は文字列です。ネスト、型付け、メタデータの概念がありません。
JSONはデータに構造があることを前提とします — オブジェクト、配列、型（文字列、数値、ブール値、null）。厳格で曖昧さがなく、機械には理想的ですが人間には冗長です。
YAMLは人間がファイルを読んで編集することを前提とします。波括弧の代わりにインデントを使用し、コメントをサポートし、よりリラックスした構文を持ちます。技術的に、YAMLはJSONのスーパーセットです — 有効なJSONドキュメントはすべて有効なYAMLでもあります。
YAMLはJSONのスーパーセット JSONドキュメントをそのままYAMLパーサーに貼り付けると動作します。逆は成立しません — コメント、アンカー、複数行文字列などのYAML機能にはJSON相当のものがありません。
実際の変換シナリオ
設定ファイルの移行（JSONからYAML、YAMLからJSON）
これが最も一般的な変換です。異なるツールは異なる設定形式を期待します：
- Docker Compose、Kubernetes、GitHub Actions、AnsibleはYAMLを使用
- package.json、tsconfig.json、ESLintはJSONを使用
- ツール間の移行にはしばしば設定の変換が必要
この変換はデータ内容に関しては双方向でロスレスですが、JSONにはコメント構文がないため、JSONに変換する際にYAMLのコメントは失われます。
データ分析（JSONからCSV）
APIレスポンスはJSONで返されます。アナリストにはスプレッドシートが必要です。この変換はフラットなJSON配列の場合にうまく機能します — 同じキーを持つオブジェクトの配列は自然に行と列にマッピングされます。
しかし、ネストされたデータでは破綻します。address.cityフィールドとskills配列を持つJSONオブジェクトには自然なCSV表現がありません。コンバーターは判断しなければなりません：ネストされたキーをフラット化する（address.cityが列になる）、ネストされた値を文字列としてシリアライズする、または破棄する。
データインポート（CSVからJSON）
逆のシナリオ：スプレッドシートのデータをWebアプリケーションやAPIにインポートする。CSVからJSONへの変換は、列ヘッダーをキーとするオブジェクトの配列を作成します。問題はCSVには型情報がないこと — 数値42、文字列"42"、ブール値trueはCSVではすべてただのテキストです。コンバーターは型を推測する必要があります。
可読性の向上（JSONからYAML）
密集したJSON設定ファイルを読みやすくする必要がある場合もあります。YAMLに変換すれば、クリーンなインデントとドキュメント用のコメント追加が可能になります。これは特にチームで管理する大きな設定ファイルで価値があります。
変換で何が失われるか
これはデバッグ時間を節約する重要な知識です：
| 変換 | 失われるもの |
|---|---|
| YAMLからJSON | コメント（JSONにはコメント構文がない） |
| JSONからCSV | ネスト（CSVはフラット）、型（すべてテキストになる）、配列 |
| CSVからJSON | なし（ただし型は推論が必要 — "42" vs 42） |
| CSVからYAML | なし（同じ型推論の問題） |
| JSONからYAML | なし（YAMLはJSONのスーパーセット） |
| YAMLからCSV | コメント、ネスト、型、アンカー/エイリアス |
パターンは明確です：CSV方向への変換は最も多くの情報を失います。CSVが最もシンプルなフォーマットだからです。JSONとYAML間の変換はほぼロスレスです。そしてYAMLのコメントはYAMLを離れるときに常に失われます。
双方向と一方向 JSON-YAMLとYAML-JSONの変換は実質的に双方向です（コメントを除きラウンドトリップ安全）。JSON-CSVとYAML-CSVの変換は複雑なデータに対しては一方向です — フラットなCSVからネストを再構築することはできません。
変換時のよくある落とし穴
YAMLの型強制の罠
YAMLは特定の文字列を自動的に非文字列型として解釈します。noはブール値falseになります。yesはtrueになります。文字列1.0は浮動小数点数になります。NO（ノルウェー）のような国コードは有名なバグの原因となっています。YAMLでは曖昧な値は常にクォートしてください。
CSVの区切り文字とエンコーディングの混乱
すべてのCSVがカンマを使うわけではありません。ヨーロッパのCSVではセミコロンがよく使われます（多くのヨーロッパの数値形式ではカンマが小数点区切りだからです）。タブ区切り値（TSV）も別のバリアントです。そして文字エンコーディングの不一致（UTF-8とLatin-1）はアクセント付き文字を文字化けさせます。
JSONの末尾カンマ問題
JSONは末尾のカンマを許可しません。これは有効なJavaScriptです：{"a": 1, "b": 2,} — しかし無効なJSONです。たった一つの末尾カンマがパースエラーを引き起こします。
大規模データセットのパフォーマンス
数百万行のデータセットの場合、CSVはJSONやYAMLよりも大幅に効率的です。JSONはすべての値に波括弧、角括弧、引用符を追加します。100万行のCSVは50MBかもしれませんが、同等のJSONは150MBになる可能性があります。
最初から正しいフォーマットを選ぶ
後から変換するのではなく、最初に正しいフォーマットを選ぶことで情報損失を回避できます：
- スプレッドシートやデータベース用の表形式データ — CSV
- APIやWebアプリ用の構造化データ — JSON
- 人間が編集する設定 — YAML
- コメント付きの複雑なネストデータ — YAML
- システム間のデータ交換 — JSON
さらに詳しく
ブラウザベースのツールでJSON、YAML、CSVの間を即座に変換：
- データフォーマット変換 — データを貼り付け、対象フォーマットを選択、結果をダウンロード
- JSONフォーマッター — JSONの検証、整形、圧縮
- JSON-CSVコンバーター — JSON配列をスプレッドシート対応CSVに変換
- YAML-JSONコンバーター — コメントを意識したYAMLとJSON間の変換