JSONTech
ツール:JSON フォーマッターJSON バリデーターJSON ビューアJSON 比較JSON 修復JWT デコーダーJSONPath テスター

JSON vs YAML: Differences, Pros & Cons (With Examples)

Both formats represent the same data, but they make very different trade-offs. Here's how to decide which one fits your use case.

JSONTech チームFebruary 10, 20259 min read

短い答え

機械が主な対象の場合はJSONを使用してください — API、データ交換、プログラム的に解析されるもの。人間が主な対象の場合はYAMLを使用してください — 設定ファイル、CI/CDパイプライン、手動で編集されるもの。それが一般的なルールであり、約90%の確率で当てはまります。

しかし、実際のトレードオフ、注意点、実際の運用で重要なニュアンスを知りたい場合は、読み続けてください。

並行構文比較

同じデータを両方の形式で表現してみましょう。これはウェブアプリケーションの典型的な設定です：

JSON

{
  "server": {
    "host": "0.0.0.0",
    "port": 3000,
    "ssl": true
  },
  "database": {
    "driver": "postgres",
    "host": "db.example.com",
    "port": 5432,
    "credentials": {
      "username": "app_user",
      "password": "s3cret"
    },
    "pools": [5, 10, 20]
  },
  "features": {
    "darkMode": true,
    "betaAccess": false,
    "maxUploadSizeMB": 25
  }
}

YAML

# サーバー設定
server:
  host: "0.0.0.0"
  port: 3000
  ssl: true

# データベース設定
database:
  driver: postgres
  host: db.example.com
  port: 5432
  credentials:
    username: app_user
    password: s3cret
  pools:
    - 5
    - 10
    - 20

# 機能フラグ
features:
  darkMode: true
  betaAccess: false
  maxUploadSizeMB: 25

YAMLバージョンは短く、各セクションを説明するコメントがあり、ほぼ箇条書きのアウトラインのように読みやすいです。JSONバージョンはより明示的で、すべての文字列が引用符で囲まれ、構造は波括弧と角括弧で定義され、型に関しては全く曖昧さがありません。

私の経験では、主にコードを書く開発者はJSONの明示性を好む傾向があります。DevOpsエンジニアやシステム管理者はYAMLの可読性を好む傾向があります。どちらのグループも間違ってはいません。

フォーマット間を瞬時に変換する: JSONを私たちのJSONからYAMLコンバータに貼り付けて、YAMLの同等物を並べて表示します。逆に YAMLからJSONに変換することもできます。

機能比較

機能JSONYAML
人間の可読性良好（フォーマットあり）優れている
コメントサポート❌ なし✅ あり（#構文）
ファイルサイズ大きい（引用符 + 波括弧）小さい（インデントベース）
解析速度非常に速い遅い（より複雑な文法）
機械に優しい優れている良好
人間による編集中程度（カンマを見逃しやすい）簡単（ただしインデントに敏感）
インデントの敏感さなし（空白は無視される）あり（インデントが構造を定義）
複数行文字列なし（\nエスケープを使用）あり（パイプ`
アンカーとエイリアスなしあり（&および*でDRY）
ネイティブデータ型6種類（文字列、数値、ブール、null、オブジェクト、配列）すべてのJSON型 + 日付、タイムスタンプ、バイナリ
仕様の複雑さ約10ページ約80ページ
ブラウザサポートネイティブ（JSON.parse）ライブラリが必要（js-yaml、yaml）

JSONを使用する場合

データがシステム間で交換される場合、特に人間が読むのではなく、JSONがより良い選択です：

APIとデータ交換

すべての主要なREST APIはJSONを使用しています。GraphQLのレスポンスはJSONです。WebhookのペイロードはJSONです。ウェブエコシステム全体はContent-Type: application/jsonを中心に構築されています。APIレスポンスにYAMLを使用するのは流れに逆らうことになります。

package.jsonとロックファイル

npm、Yarn、ほとんどのJavaScriptツールは設定ファイルとロックファイルにJSONを使用します。package.json仕様は厳密なJSONを要求します。コメントを追加することはできません（ただし、"//"キーを使用するよく知られたハックがあります）、トレーリングカンマも使用できません。面倒ですが、これが標準です。

{
  "name": "my-app",
  "version": "2.1.0",
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start"
  },
  "dependencies": {
    "next": "^15.0.0",
    "react": "^19.0.0"
  }
}

スピードが必要な場所

JSONパーサーは文法がシンプルなため、非常に高速です。パイプラインで数百万のメッセージを処理している場合、JSONの解析性能の優位性は大きいです。ほとんどのベンチマークでは5-10倍速いです。

YAMLを使用する場合

YAMLは人間がファイルを作成し、維持する場合に優れています。DevOpsの世界は主にYAMLに標準化されており、それには良い理由があります。

Docker Compose

version: "3.8"
services:
  web:
    build: .
    ports:
      - "3000:3000"
    environment:
      - NODE_ENV=production
    depends_on:
      - db

  db:
    image: postgres:16
    volumes:
      - pgdata:/var/lib/postgresql/data
    environment:
      POSTGRES_PASSWORD: secret

volumes:
  pgdata:

これをJSONで書こうとすると、なぜDockerがYAMLを選んだのかすぐにわかります。ネストされた構造は自然に読みやすく、コメントでセクションを注釈でき、閉じ括弧がないことでクリーンさが保たれます。

Kubernetesマニフェスト

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.25
          ports:
            - containerPort: 80

KubernetesのYAMLファイルは非常に大きくなることがあります。コメントとクリーンなインデントベースの構造がなければ、維持するのは耐え難いものになります。それでも、YAMLを使用しても、大規模なK8s設定は依然として非常に面倒です — だからこそ、HelmやKustomizeのようなツールが存在します。

CI/CDパイプライン

GitHub Actions、GitLab CI、CircleCI、ほとんどのCIプラットフォームはパイプライン定義にYAMLを使用します。ステップが存在する理由を説明するインラインコメントを追加できることは、午前2時にビルドの失敗をデバッグしているときに非常に価値があります。

一般的な落とし穴

YAMLの注意点

  • ノルウェー問題: YAML 1.1では、NOがブール値のfalseとして解釈されます。国コード、略語、その他の短い文字列は静かに誤解釈される可能性があります。YAML 1.2でこれが修正されましたが、一部のパーサーはまだ古い仕様を使用しています。曖昧な文字列は常に引用符で囲んでください。
  • インデントエラーは静か: 誤ったインデントレベルは必ずしも解析エラーを引き起こすわけではなく、意図したのとは異なる構造を作成することがあります。これは私の経験上、YAMLバグの最大の原因です。
  • タブ文字は禁止: YAMLはインデントにスペースのみを許可します。タブを混ぜると、暗号的な解析エラーが発生します。
  • セキュリティの懸念: YAMLの!!python/objectタグ（および類似のもの）は、解析中に任意のコードを実行する可能性があります。常に安全な読み込み関数を使用してください。

JSONの注意点

  • コメントなし。 あなたはそれを恋しく思うでしょう。誰もがそれを恋しく思います。一部のツールはJSONCをサポートしていますが、標準のJSONではサポートされていません。
  • トレーリングカンマの罠: JavaScriptではトレーリングカンマを持つことができますが、JSONではできません。両者の間でコピー＆ペーストを行うと、定期的に問題が発生します。
  • 数値の精度: JSONの数値はIEEE 754ダブルです。大きな整数（2^53を超える）は精度を失います。大きなIDを扱う場合は、文字列として渡してください。
  • 複数行文字列なし: 長いテキスト値には\nエスケープシーケンスが必要で、ファイルの可読性が低下します。

自分で試してみてください: 複雑なJSONファイルをYAMLに変換して、私たちのJSONからYAMLコンバータでフォーマット間の構造がどのようにマッピングされるかを確認してください。また、最初にJSONバリデーターでJSONを検証することもできます。

両方を使用できますか？

もちろん、ほとんどのプロジェクトはそうしています。典型的なNode.jsプロジェクトには、package.json（JSON）とdocker-compose.yml（YAML）、および.github/workflows/ci.yml（YAML）があるかもしれません。フォーマットを混在させることに問題はありません — ツールが期待するもの、または文脈に最も適したものを使用してください。

重要な詳細の1つ：YAMLはJSONのスーパーセットです（YAML 1.2以降）。つまり、すべての有効なJSONドキュメントは有効なYAMLでもあります。したがって、JSONをYAMLパーサーに貼り付けると、問題なく動作します。逆は真ではありません — YAMLにはJSONがサポートしていない機能があります。

パフォーマンス比較

パフォーマンスがあなたのユースケースで重要な場合、JSONが決定的に勝ちます。以下は、同じ1MBドキュメントを解析した際の大まかな数値です：

操作JSONYAML
解析時間（Node.js）~15ms~120ms
文字列化時間~10ms~80ms
ファイルサイズ（フォーマット済み）1.00 MB0.75 MB
ファイルサイズ（ミニファイド）0.60 MBN/A（YAMLを本当にミニファイすることはできません）

YAMLファイルは引用符や波括弧を省略するため小さくなりますが、解析にはかなりの時間がかかります。起動時に一度読み込まれる設定ファイルでは、これは問題になりません。しかし、1日に何百万回も処理されるAPIペイロードでは、非常に重要です。

結論

データ交換にはJSONを、設定にはYAMLをデフォルトの選択肢として推奨します。ツールがオプションを提供する場合は、誰がファイルを読み、編集するかを考えてください。機械？JSON。人間？YAML。両方？JSONから始めて、コメントがないことの痛みがYAMLに向かわせるかどうかを見てください。

そして、JSONが初めての場合は、基本を学ぶために私たちのJSONとは？ガイドから始めてください。

関連ツール：

関連ツール

YAML → JSON

YAML 設定を JSON に

JSON → XML

レガシー連携用に XML へ

JSON フォーマッター

インデント設定で JSON を整形

JSON バリデーター

詳細なエラーと行番号で JSON を検証

← ガイド一覧に戻る