JSON と YAML の使い分け
JSON と YAML はどちらもデータ記述言語ですが、設定ファイル・API レスポンス・機械可読性など用途で向き不向きが明確です。決定表と実例で解説。
公開 · 更新 · yuzlrin
代表的な使い分け
JSON は以下で選ばれます:
・Web API のレスポンス（REST / GraphQL）
・JavaScript/TypeScript からの読み書き（JSON.parse/stringify 標準）
・ブラウザ ↔ サーバー間通信（fetch / XHR のデフォルト）
・スキーマ自動生成が必要なデータ（JSON Schema 対応ツール多数）
YAML は以下で選ばれます:
・CI/CD 設定（GitHub Actions、GitLab CI、CircleCI）
・Kubernetes マニフェスト / Helm Chart
・Ansible / Salt など IaC ツールの playbook
・Docker Compose、Prometheus 設定など DevOps 系
なぜ YAML は DevOps で多い？
YAML は空行・コメント・複数行文字列をそのまま書けるので、人間が長い設定ファイルを読み書きするのに向きます。一方 JSON はコメント非対応、末尾カンマ禁止など制約が多く、手書き設定ではしんどい。
ただし YAML はインデント依存（タブと空白の混在はエラー）、型推論が複雑（'no' がブール偽になる Norway 問題）など落とし穴があり、機械生成の正確性では JSON に劣ります。
相互変換するときの注意
JSON → YAML は安全（JSON はすべて valid YAML）。逆は YAML 特有の機能（アンカー &、エイリアス *、マルチドキュメント ---）が落ちるため、変換後は必ず差分を確認してください。
Kubernetes では「JSON で書いても valid」なので、Terraform や CDK からの吐き出し時は JSON が採用されることもあります。
関連ツール
よくある質問
JSON にコメントは書けない？
標準 JSON（RFC 8259）はコメント非対応です。設定ファイルで必要なら JSONC（JSON with Comments、VSCode が採用）や JSON5 のような拡張形式を使うか、YAML / TOML に切り替えます。
YAML の 'no' 問題とは？
YAML 1.1 では 'yes', 'no', 'on', 'off' が真偽値として解釈されます。Norway の国コード 'NO' や 'No' を書くと false になるのが Norway problem。YAML 1.2 ではこの自動解釈を廃止していますが、多くのライブラリはまだ 1.1 互換です。
JSON5 や HJSON って何？
JSON の拡張で、コメント、末尾カンマ、単一引用符などを許容する人間向け variant。設定ファイル用途に向きますが、機械連携には素の JSON に戻すのが無難です。