YAML は JSON のスーパーセットですか？

YAML 1.2 は技術的に JSON のスーパーセットです — 有効な JSON ドキュメントは有効な YAML 1.2 でもあります。ただし、YAML 1.1 (多くのパーサーで依然として使用されている) は異なるブール値解釈ルールを持ち、すべての有効な JSON を正しく解析しない可能性があります。実際には、互換性があるが交換可能ではないものとして扱ってください: YAML ファイルには YAML パーサーを、JSON ファイルには JSON パーサーを使用し、片方がもう片方を処理すると仮定しないでください。

YAML はコメントを持てますか？JSON は？

YAML は # 文字を使ってコメントをサポートし、これは JSON に対する最も引き合いに出される利点の 1 つです。JSON は意図的にコメントを省略します — 仕様はコメント構文を定義していません。JSON5 (非公式拡張) と JSONC (VS Code で使用されるコメント付き JSON) はコメントサポートを追加しますが、それらは有効な JSON ではなく、非標準のパーサーを必要とします。説明的なメモを含む人間が読める設定が必要な場合、YAML の方が適しています。

解析が速いのは JSON と YAML のどちらですか？

JSON は解析が大幅に速いです。JSON パーサーはシンプルでよく最適化されています — V8、CPython、JVM の現代の実装は JSON を毎秒数百メガバイトで解析します。YAML パーサーはインデント、アンカー、エイリアス、複数のスカラー型、複雑なエッジケースを処理する必要があり、大幅に遅くなります。高スループット API レスポンスや大きなデータファイルには、JSON が明確なパフォーマンスの勝者です。

なぜ Kubernetes や GitHub Actions は JSON ではなく YAML を使用するのですか？

これらのツールは、機械によって生成されるのではなく、人間が手でファイルを書くことで設定されます。YAML のコメント、複数行文字列、よりクリーンなリスト/マッピング構文のサポートは、設定ファイルをより読みやすく、保守しやすくします。GitHub Actions ワークフローには通常、JSON では扱いにくい説明コメントと複数ステップのロジックが含まれます。Kubernetes マニフェストは、チームがコードレビューでレビューする意図したシステム状態を記述します — 解析速度よりも可読性が重要です。

YAML の Norway 問題とは何ですか？

YAML 1.1 では、2 文字の文字列「NO」がブール値の false として解釈されます。YAML 1.1 は「no」「n」「false」「off」、およびそれらの大文字バリアントを false として扱うためです。これは、ノルウェーの国コードキー「NO」を持つ YAML マッピングが、ブールコンテキストに現れた場合に値を誤って解析することを意味します。同様に「YES」は true、「ON」も true になります。YAML 1.2 は「true」と「false」のみをブール値として認識することでこれを修正しますが、多くのパーサーはまだ 1.1 の動作を実装しています。

いつ JSON と YAML を変換すべきですか？

機械生成された設定を人間が読みやすくしたい、コメントを追加したい、または Kubernetes や Ansible のような YAML ネイティブツールにデータを供給したい場合は、JSON を YAML に変換します。API にデータを送信したい、JSON ツールで処理したい、またはデータベースに保存したい場合は、YAML を JSON に変換します。Toova の JSON to YAML と YAML to JSON コンバーターは両方とも、データをサーバーに送信せずにブラウザ内で変換を処理します。

JSON vs YAML — どちらをいつ使うか

2026年5月10日 Toova

JSON と YAML はどちらも構造化されたデータをテキストとして表現する方法です。両方とも、文字列、数値、ブール値、配列、ネストされたオブジェクトをサポートします。両方とも、あらゆるプログラミング言語とプラットフォームで広くサポートされています。しかし、両者は非常に異なるトレードオフを行います: JSON はマシンの可読性と解析速度を最適化します。YAML は人間の可読性と表現力豊かな設定を最適化します。どちらに手を伸ばすべきかを知ることで、API 用に設計された設定形式を手書きの設定ファイルに使ったり、その逆をしたりすることから生じる種類の摩擦を防げます。

このガイドでは、構文の違い、各形式の実用的な強みと弱み、形式に依存する実世界のツール選択、パフォーマンスの考慮事項、そして 2026 年の明確な意思決定フレームワークをカバーします。

JSON: 概要

JSON (JavaScript Object Notation) は、Douglas Crockford によって 2000 年代初頭に正式化され、RFC 8259 と ECMA-404 で標準化されました。設計目標は、複雑なパーサーを必要とせずに、任意のプログラミング言語で解析およびシリアル化できる最小限の明確な形式でした。

JSON は正確に 6 つのデータ型をサポートします: 文字列 (常に二重引用符)、数値、ブール値 (true/false)、null、オブジェクト (文字列キーを持つキー値マップ)、配列 (順序付けされたリスト)。コメント、日付型、バイナリ型、参照はありません。このミニマリズムは意図的です: 厳格なルールは曖昧さを排除し、パーサーをシンプルで高速にします。

{
  "name": "deploy-service",
  "version": "2.1.0",
  "environment": "production",
  "replicas": 3,
  "enabled": true,
  "tags": ["backend", "critical"],
  "resources": {
    "cpu": "500m",
    "memory": "512Mi"
  }
}

すべてのキーは二重引用符で引用される必要があります。末尾のカンマは許可されません。コメントを書く方法はありません。改行文字をエスケープせずに文字列が複数行にまたがることはできません。これらの制約は、JSON を手で書きにくくしますが、コードから生成し、受信側で解析するのを簡単にします。

YAML: 概要

YAML (YAML Ain't Markup Language) は、Clark Evans、Ingy dot Net、Oren Ben-Kiki によって 2001 年から設計されました。JSON 互換性を達成するバージョン 1.2 は、2009 年に確定されました。YAML の設計目標は、開発者が新しい構文を学ばずにテキストエディタで直接書ける、人間が読めるデータ形式です。完全な仕様は yaml.org にあります。

YAML は、括弧の代わりにインデントを使用して構造を表現します。リストはハイフンを使用します。キーはデフォルトで引用符なしです。コメントは # で始まります。特殊文字を含まない限り、文字列は引用符を必要としません。複数行文字列には専用のブロックスカラー構文があります。

# 本番環境のデプロイメント設定
name: deploy-service
version: 2.1.0
environment: production
replicas: 3
enabled: true

tags:
  - backend
  - critical

resources:
  cpu: 500m
  memory: 512Mi

YAML で表現された同じデータ構造は、特にコメントやネストされたリストを含む場合、大幅に短く、より読みやすいです。トレードオフは、YAML のパーサーが大幅に多くの複雑さを処理する必要があることです: インデント感度、同じ型を表現する複数の方法、アンカー、エイリアス、マージキー、そして曖昧なブール値解釈の歴史的な遺産。

並列構文比較

複数行文字列

複数行文字列は、設定ファイルにとっての YAML の最も明確な利点の 1 つです。YAML は 2 つのブロックスカラースタイルを提供します: リテラル (|) は改行を正確に保持し、折りたたみ (>) は長い散文のために空白で行を結合します。

# YAML: 複数行文字列を書くさまざまな方法
# リテラルブロック (改行を保持)
description: |
  これは 1 行目です。
  これは 2 行目です。
  末尾の改行付きの最終行。

# 折りたたみブロック (改行はスペースになる、長い散文に最適)
summary: >
  この長い段落は複数行にわたって
  書かれていますが、空白で区切られた
  単一の文字列に結合されます。

# JSON では改行をエスケープする必要があります
# "description": "これは 1 行目です。
これは 2 行目です。
最終行。"

アンカーとエイリアス

YAML のアンカー (&) とエイリアス (*) は、変数のように値を一度定義して複数の場所で参照できるようにします。マージキー (<<) は、マッピングの内容を別のものにマージし、ある形式の継承を提供します。

# YAML のアンカーとエイリアスは重複を減らします
defaults: &defaults
  timeout: 30
  retries: 3
  log_level: info

development:
  <<: *defaults   # defaults をマージ
  log_level: debug

staging:
  <<: *defaults
  timeout: 60

production:
  <<: *defaults

JSON には同等のものがありません。JSON では、繰り返される設定は複製、テンプレートレイヤーで処理、または消費アプリケーションのロジックで管理される必要があります。YAML アンカーは人間が管理する設定には強力ですが、慣習に慣れていない読者にとってファイルを理解しにくくする可能性があります。

強みと弱み

JSON の強み

明確な解析 — 文法は単一ページで述べられるほど単純です。すべてのパーサーは特定の入力に対して同じ結果を生成します。
速度 — JSON パーサーは存在する最速のテキストパーサーの 1 つです。V8 は JavaScript 自体が実行するよりも大幅に速く JSON を解析します。
ネイティブ JavaScript サポート — JSON.parse() と JSON.stringify() はすべての JavaScript ランタイムに組み込まれています。依存関係不要。
普遍的なツール — すべての API クライアント、データベース、データパイプラインは JSON をネイティブに話します。これは事実上の API 形式です。
インデント感度なし — 空白は意味に無関係であり、JSON をエディタ、オペレーティングシステム、ツール間のフォーマットの違いに耐えうるものにします。

JSON の弱み

コメントなし — 設定値をインラインで説明できません。これは手書きのファイルにとって重要な痛みのポイントです。
人間にとって冗長 — すべてのキーが引用符で囲まれる必要があり、カンマがすべての項目を区切り、括弧がすべてのオブジェクトと配列を囲みます。
末尾カンマエラー — 最後の配列またはオブジェクト要素の後の末尾カンマは無効で、手で編集するときに簡単に導入できる解析エラーを引き起こします。
複数行文字列なし — 埋め込まれた改行を持つ文字列を表現するには \n エスケープが必要で、SQL クエリやシェルスクリプトのようなものを埋め込むのを面倒にします。
日付型なし — 日付は文字列です。慣習は異なり (ISO 8601、Unix タイムスタンプ、カスタム形式)、アプリケーションで処理する必要があります。

YAML の強み

コメント — # コメント構文は、インラインドキュメンテーションが必要な設定ファイルにとって YAML を明白な選択肢にします。
可読性 — 構文的ノイズが少ない。引用符なしのキー、カンマなし、人間が概要を書く方法を反映するインデントベースの構造。
複数行文字列 — リテラルと折りたたみブロックスカラーは、エスケープなしで長い文字列を優雅に処理します。
アンカーとマージキー — 大きな設定ファイルでの重複を減らします。
リッチな型システム — YAML パーサーは、明示的な型アノテーションなしで値形式から型 (文字列、整数、浮動小数点、ブール値、null、タイムスタンプ) を推測します。

YAML の弱み

複雑さ — YAML 仕様全体は巨大です。エッジケースは豊富です: Norway 問題、暗黙的な型強制の驚き、タブ対スペースの感度。
遅い解析 — YAML パーサーは、文法の複雑さのために JSON パーサーよりも大幅に遅いです。
インデントエラー — 単一の不揃いな行は、解析エラーを発生させずにドキュメントの意味を変え、見つけにくい微妙なバグを生み出します。
Norway 問題 — YAML 1.1 では、裸の NO はブール値 false として解析されます。国コード、略語、多くの英単語は、YAML 1.1 パーサー (依然として一般的) で予期しないブール値解釈を持ちます。
パーサーの動作の不一致 — 異なる言語の YAML パーサーは、仕様の異なるサブセットや異なるバージョンを実装しており、移植性の問題を引き起こします。

いつ JSON を使うか

API レスポンスとリクエスト

JSON は REST API の普遍的な形式です。すべての HTTP クライアントライブラリはそれをネイティブにシリアル化および逆シリアル化できます。解析速度は API スケールで重要であり、JSON の明確な文法は、すべてのクライアントとサーバーが同じデータを同一に解析することを意味します。GraphQL レスポンスは JSON です。OpenAPI/Swagger 定義は JSON です (ただし YAML も受け入れられます)。API を設計する場合、JSON をデフォルトにしてください。

{
  "user": {
    "id": 42,
    "email": "alice@example.com",
    "roles": ["admin", "editor"],
    "createdAt": "2026-01-15T10:30:00Z"
  }
}

コードによって生成された設定

プログラムが設定を生成するとき — 依存関係ロックファイルを出力するビルドツール、プロジェクトマニフェストを生成するフレームワーク、チェックサムを記録するデプロイメントツール — JSON が適切な形式です。出力は手で書く必要がなく、コメントが必要なく、JSON の明確な文法は、消費コードが生成されたものを正確に解析することを保証します。package.json、tsconfig.json、package-lock.json、composer.json はすべてこのパターンの例です。

サービス間のデータ交換

2 つのサービスがデータを交換する必要があるとき — メッセージキュー、Webhook、イベントストリーム — JSON の速度、普遍性、明確さがそれを正しい選択にします。YAML の利点 (コメント、複数行文字列) は、自動化されたデータパイプラインでは無関係です。デバッグ中にペイロードを検査するには JSON Formatter を使用し、ドキュメンテーション目的でペイロードを人間が読みやすくする必要がある場合は JSON to YAML コンバーターを使用します。

データベースでの保存

PostgreSQL、MongoDB、MySQL、および構造化データを保存するほとんどのデータベースは、JSON または JSON 互換形式で行います。YAML はどの主要なデータベースでもサポートされている保存形式ではありません。データベースに設定や構造化データを保存している場合、JSON を使用してください。

いつ YAML を使うか

インフラストラクチャとデプロイメント設定

Kubernetes マニフェスト、Helm チャート、Docker Compose ファイル、Ansible Playbook はすべて YAML を使用します。これらのファイルは人間によって書かれ、レビューされ、説明コメントを含むことが多く、リソースのセットを記述するための YAML の読みやすいリスト構文の恩恵を受けます。複数のコンテナ、ボリュームマウント、環境変数を持つ Kubernetes デプロイメントは、JSON よりも YAML で大幅に読みやすいです。

CI/CD パイプライン定義

GitHub Actions、GitLab CI、CircleCI、Bitbucket Pipelines はすべてパイプライン定義に YAML を使用します。パイプライン設定は人間によって作成され、頻繁にコメントされ、YAML の読みやすい構文の恩恵を受ける複数ステップのロジックを含みます。

# GitHub Actions ワークフロー — YAML の自然な適合
name: CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: テストを実行
        run: npm test

アプリケーション設定ファイル

Django 設定 (django-configurations 経由)、Ruby on Rails database.yml、Gatsby 設定、その他多くのフレームワークが設定に YAML を使用します。開発者がコードと並んで設定ファイルを読んで理解する必要があるとき、YAML がコメントと複数行の説明を含めることができる能力が認知的オーバーヘッドを減らします。

ドキュメンテーションデータ

Jekyll、Hugo、Eleventy のような静的サイトジェネレーターは、コンテンツファイルで YAML フロントマターを使用します。YAML メタデータと Markdown 本文コンテンツの組み合わせは広まっています。YAML の読みやすいキー値構文がテキストドキュメントの上部に自然に適合するためです。JSON フロントマターは存在しますが、めったに優先されません。

パフォーマンス

データ処理パイプラインの場合、シリアル化ベンチマークは、同等のデータに対して JSON が YAML よりも 5〜10 倍速く解析されることを一貫して示しています。1 MB ファイルでの V8 JSON.parse() 呼び出しは数ミリ秒で完了します。同等の YAML 解析は数十ミリ秒かかります。毎秒数千リクエストを処理するウェブサーバーには、この違いが重要です。起動時に 1 回設定ファイルを読み込む CLI ツールには、そうではありません。

パフォーマンスが主な懸念事項で、高スループットデータ形式に JSON と YAML を選択する場合、JSON が疑いなく勝ちます。さらに高速な解析が必要な場合、サービス間通信のための MessagePack や Protocol Buffers のようなバイナリ形式を検討してください。

セキュリティの考慮事項

YAML パーサーは JSON パーサーよりも複雑で、より大きな攻撃面を持っています。最も重要なリスクは YAML の逆シリアル化を介した任意のコード実行です。Python の PyYAML (safe_load がデフォルトで強制される前) では、デフォルトの yaml.load() 関数で信頼できない YAML をロードすると、YAML に埋め込まれた任意の Python コードを実行できました。PHP と Ruby の YAML パーサーには同様の脆弱性がありました。

ルール: 信頼できない YAML を解析するときは常に安全なロードを使用してください。Python では、yaml.load() を Loader 引数なしで使うのではなく、yaml.safe_load() を使用してください。Java では、許可された型を制限するようにコンストラクターを設定します。Ruby では、YAML.load() ではなく YAML.safe_load() を使用してください。

JSON の型システムには実行可能な値の概念がないため、JSON パーサーにはこの脆弱性はありません。JSON パーサーは、文字列、数値、ブール値、null、配列、オブジェクト — 決してコードではない — のみを生成できます。信頼できないユーザーデータを処理する場合、JSON は本質的に解析が安全です。

JSON と YAML の間の変換

形式は最も一般的なデータ型については意味的に互換性があります。データが YAML 固有の機能 (アンカー、カスタム型、ブロックスカラー) を使用しない場合、それらの間の変換は簡単です。JSON to YAML コンバーターを使って API レスポンスやロックファイルをドキュメンテーションやデバッグのために読みやすい YAML に変換します。YAML to JSON コンバーターを使って YAML 設定を JSON ネイティブツールや API に供給します。両方のツールはブラウザ内で動作します — データはデバイスから出ません。

JSON Formatter は、変換の前に JSON 構造を検査および検証するのに有用です。形式間で頻繁に移動する設定 — たとえば、API 呼び出しのためにシリアル化する必要がある Kubernetes マニフェスト — を扱う場合、両方のコンバーターをブックマークしておくと時間を節約できます。

意思決定フレームワーク

REST API レスポンスやリクエストを書く？ JSON。
Kubernetes、Docker Compose、Ansible を設定する？ YAML。
CI/CD パイプラインを書く？ YAML。
データベースにデータを保存する？ JSON。
コメント付きの人間が編集可能な設定ファイルを書く？ YAML。
コードからプログラム的に設定を生成する？ JSON。
信頼できないユーザー入力を処理する？ JSON (より安全なパーサー)。
高スループットデータパイプライン？ JSON (またはバイナリ形式)。
すでに 1 つの形式を一貫して使用しているプロジェクト？ 既存の慣習に従う。

迷ったときは、最も重要な要因はファイルを読み書きする人間です。ファイルが主に機械生成され機械消費される場合、JSON のシンプルさが勝ちます。人間がそれを読み、編集し、その明確さに関心がある場合、YAML の表現力は追加のパーサーの複雑さに見合います。