JSONとYAMLの違い - どちらを使うべきか
JSON と YAML はどちらも「人間が読み書きできる構造化データ」を扱う形式ですが、向き不向きが明確に分かれます。本記事では使い分けの指針と、相互変換時のハマりどころを整理します。
1. 結論：用途別の使い分け
| 用途 | 推奨 | 理由 |
|---|---|---|
| Web API / fetch のレスポンス | JSON | ブラウザとほぼ全言語で標準サポート |
| 機械間連携・データ保存 | JSON | パーサが速く、誤解釈が少ない |
| K8s / GitHub Actions / Docker Compose 等の設定 | YAML | コメントが書ける、人間が編集しやすい |
| 長文・複数行を含む設定 | YAML | 複数行リテラルが扱いやすい |
| 言語をまたぐ設定共有 | JSON | YAMLの解釈差で事故るリスク |
2. 同じデータを比較
JSON
{
"name": "TN LABO",
"tools": ["ssl", "dns"],
"options": { "ttl": 60, "active": true }
}
YAML
name: TN LABO tools: - ssl - dns options: ttl: 60 active: true
3. JSON の特徴
- ★ 機械にやさしい — 構文が単純で曖昧さがない。
- ★ 全言語標準対応 — ブラウザの
JSON.parseから K8s API の出力まで。 - ✗ コメントが書けない（JSON5/JSONC は別物）
- ✗ 末尾カンマが許されない
- ✗ 文字列は必ずダブルクォート
4. YAML の特徴
- ★ 人間にやさしい — インデントベース、コメント可、引用符ほぼ不要。
- ★ 複数行リテラル —
|（改行保持） />（折り返し）。 - ✗ 暗黙の型変換が事故の温床（後述）
- ✗ インデントの空白数で意味が変わる
- ✗ 仕様が複雑で、パーサごとに挙動差がある（YAML 1.1 vs 1.2）
5. YAML の落とし穴
The Norway Problem (no → false 問題)
countries: - NO # ノルウェーのつもりが… - SE - DK # YAML 1.1 では NO が boolean false に解釈される
対策: 文字列は明示的に引用符で囲む。"NO", 'NO'
誤解されやすい値
yes / no / on / off→ boolean に解釈（1.1）012→ 8進数として 10 と解釈1.0→ float として「1」になる- 日付っぽい文字列 → date 型に変換される
確実なのは YAML 1.2 準拠のパーサを使う ことと、文字列は引用符で囲む こと。
6. 相互変換のコツ
YAML → JSON はおおむね無損失。逆の JSON → YAML はコメントを生成できないので、人間用にする場合は手で追加します。
JSON⇔YAML変換ツール ならブラウザ上で即変換できます（データはサーバに送信されません）。
7. パフォーマンス
- パース速度: JSON が圧倒的に速い（YAMLの 5〜30 倍）
- ファイルサイズ: JSON の方が小さくなることが多い（インデント無し時）
- ストリーミング処理: JSON Lines (JSONL) なら行単位処理が容易
結論
「人が編集する設定ファイルは YAML、機械が扱うデータは JSON」と覚えておけば、9割の場面でハズレません。
関連ツール: JSON整形 / JSON⇔YAML変換 / テキスト差分