← 記事一覧
更新日: May 29, 20267 min read

JSON vs YAML: 違いと使い分け

JSON と YAML を比較: 構文、型、コメント、Norway problem のようなワナ。YAML は JSON の上位集合 —— 使い分けと変換方法。

JSON と YAML は同じ問題 —— 構造化データをテキストで表現する —— を解決しますが、トレードオフは正反対です。JSON は機械にとって曖昧さのないパースを最適化し、YAML は人間が書くことを最適化します。YAML 1.2 以降、すべての妥当な JSON ドキュメントは妥当な YAML でもあります。本ガイドでは両者の構文、型、機能を比較し、それぞれをいつ使うかを説明します。

短い答え

プログラム間で交換するデータには JSON —— API レスポンス、メッセージペイロード、機械が生成するもの一般。人間が手で書いて編集するファイルには YAML —— CI パイプライン、Kubernetes マニフェスト、アプリ設定 —— コメントと可読性が重要な場面で。

並べて見る構文

同じデータを両方のフォーマットで：

# YAML
service: api
replicas: 3
ports:
  - 8080
  - 8443
env:
  LOG_LEVEL: info
  DEBUG: false
// JSON
{
  "service": "api",
  "replicas": 3,
  "ports": [8080, 8443],
  "env": {
    "LOG_LEVEL": "info",
    "DEBUG": false
  }
}

YAML は中括弧や角括弧の代わりにインデントを使い、ほとんどの引用符を省き、コメントを許容します。JSON はもっと冗長ですが、意味のあるホワイトスペースがなく、信頼できる形でのパースと生成がはるかに容易です。

YAML は JSON の上位集合

YAML 1.2（2009）以降、YAML は JSON の厳密な上位集合です —— 任意の妥当な JSON ドキュメントは妥当な YAML です。YAML が JSON の「flow」構文を直接採用したためです。JSON を YAML ファイルに貼り付けてもそのまま動くのはこのためです。背景については YAML 1.2 と JSON 互換性 を参照。

# これは妥当な YAML —— 同時に妥当な JSON でもある
{"service": "api", "replicas": 3}

機能比較

機能JSONYAML
コメントなしあり（#）
末尾カンマ不可該当なし（block スタイルにはカンマがない）
複数行文字列エスケープ \n のみネイティブ（| と >）
アンカー / 参照なしあり（& / *）
ファイルあたり複数ドキュメント不可可（--- 区切り）
有意義なホワイトスペースなしあり（インデントが意味を持つ）
パース複雑度些細複雑
最適用途機械間のデータ交換人間が編集する設定

型の扱い：YAML の鋭利な角

YAML は型推論に積極的で、JSON の明示的な引用符が避けるサプライズを引き起こします：

# 「Norway problem」 —— YAML 1.1 パーサではこれらが真偽値になる
countries:
  - NO   # → false (!)
  - SE
  - true # → 真偽値、文字列 "true" ではない

version: 1.20   # → 数値 1.2、末尾のゼロが失われる
zip: 01234      # → 668（一部パーサで八進数として解釈）

JSON にはこの曖昧さが一切ありません："NO" は常に文字列 NO ですし、"01234" は常にその文字列です。YAML の値が必ず文字列であるべきときは、明示的に引用符を付けましょう。

TOML と JSON5 の位置づけ

「人に優しい」設定フォーマットとしてよく一緒に挙がる他の 2 つ：

  • TOML —— section/key 形式、手書きのアプリ設定向け（Cargo、Poetry、Hugo）。YAML より厳密で、意味のあるインデントなし、ネイティブで型付きの値（datetime、整数、float、配列、インラインテーブル）。データがほぼ平坦なテーブルのときに最適。
  • JSON5 —— 開発者向けに緩めた JSON：コメント、末尾カンマ、引用符なしキー、シングルクォート、複数行文字列を許容。標準 JSON パーサが受理する わけではなく、JSON5 ライブラリを使ってオプトインします（または「コメント + 末尾カンマ」サブセット用に JSONC パーサ、例：tsconfig.json）。

ざっくり目安：機械間交換は JSON、深くネストする人手編集の設定は YAML、平坦なアプリ/ツール設定は TOML、エディタ設定で YAML のホワイトスペース規則を採用せずに JSON にコメントが欲しいときは JSON5/JSONC。

どちらをいつ使うか

  • JSON を使う：REST/GraphQL API、メッセージキュー、ブラウザの localStorage、package.json、コードで生成または消費されるもの全般。
  • YAML を使う：GitHub Actions / GitLab CI、Kubernetes と Docker Compose、Ansible playbook、人間が編集してコメントを付けたいアプリ設定。

よくあるパターン：可読性のために設定を YAML で書き、ビルドかロード時に JSON に変換して、アプリケーションは常に JSON だけをパースする。

JSON と YAML を相互変換

# Python —— YAML から JSON
import yaml, json
data = yaml.safe_load(open('config.yaml'))
print(json.dumps(data, indent=2))

# yq を使ったコマンドライン
yq -o=json '.' config.yaml      # YAML → JSON
yq -P '.' config.json           # JSON → YAML

もしくは fixjson の YAML ⇄ JSON コンバータ でブラウザ上で即変換 —— YAML を貼って JSON を得る（または逆方向）、データはどのサーバにも送信されません。

よくある質問

YAML は JSON より良いですか？

「良い」というものはなく、それぞれ違う仕事に合わせて調整されています。人手編集の設定には YAML が良く（コメント、可読性）、機械間データ交換には JSON が良い（シンプル、高速、曖昧さのないパース）。

JSON は妥当な YAML ですか？

はい。YAML 1.2 以降、YAML は JSON の厳密な上位集合なので、任意の妥当な JSON ドキュメントは妥当な YAML です。逆は成立しません —— 多くの YAML は妥当な JSON ではありません。

なぜ YAML は「NO」を false にするのですか？

YAML は引用符のないスカラから型を推論し、一部パーサは NO、yes、on、off を真偽値として読みます（「Norway problem」）。値を引用符で囲めば（"NO"）強制的に文字列にできます。JSON は必須の引用符でこれを完全に回避します。

設定ファイルには YAML と JSON のどちらを使うべき？

人間が編集し、コメントと複数行文字列の恩恵があるなら YAML、ツールが生成または消費するなら JSON。多くのチームは YAML で書き、ロード時に JSON に変換します。

ブラウザで変換 & 検証