JSONとYAMLの違い
JSONは交換フォーマットです。厳格で、コメントがなく、すべてのAPIとパーサーが理解します。YAMLは人間向け設定フォーマットです。インデントがスコープを決め、コメントが書け、手で入力できます。プログラムがプログラムに渡すものにはJSONを、人が書いてプログラムに渡すものにはYAMLを選びましょう――そしてどちらの方向にも損失なく変換できます。
JSONとYAMLの違いとは
この2つのフォーマットはライバルとして紹介されることが多く、それが有用な真実をぼかしています。つまり、2つは別々の問題を解決しており、実際のプロジェクトの大半は両方を使っているということです。JSONがデータ交換を勝ち取ったのは、文法が1枚のカードに収まるほど小さく、あるサービスが出したペイロードを、共有設定なしに別のサービスが消費できるからです。YAMLが設定を勝ち取ったのは、それを編集するのがテキストエディタの前の人間であり、人間はコメントと、読みやすいリストと、引用符を省略する自由を求めるからです。
その人間やすさの代償が、YAMLの作者自身が「複雑」と評する仕様です。インデントが意味を持ち、裸のスカラーの型は推論され（古典的な失敗は`no`のような値が黙ってブール値falseになること）、書いた人が意図しない意味のままファイルが解析できてしまいます。JSONの厳格さこそが「退屈さ」の正体です――数値は数値、文字列は文字列であり、エディタがファイルを別のドキュメントに組み替えることはありません。
以下の比較は、トレードオフが実際に効いてくる水準――構文ルール、型の振る舞い、コメント、サイズ、そして各フォーマットが想定するツール――に留めます。両者をまたぎたいときは、このサイトに両方向のまっとうなコンバーターがあります。ここにあるすべてと同じく、完全にブラウザ内で動作します。
設定を表計算ソフトでのレビュー用に表へ起こすのはよくある工程で、YAMLからCSVコンバーターがタブを離れることなくそれを行います。
このページで比較しているまさにその変換が必要なら、YAMLからJSONコンバーターがブラウザ内で解析と出力のサイクルを実行します。アップロードは一切ありません。
構文：記号かインデントか
JSONの文法が使う構造文字は6種類――括弧、波括弧、コロン、カンマ――なので、ドキュメントのネストは記号に現れ、リンターは誤っている1文字を正確に指し示せます。YAMLは記号の枠を読みやすさに使います。ネストはインデント、リストはダッシュ、キー／値のペアに必要な区切りはコロンとスペースだけです。その結果、5行のJSONドキュメントは2行のYAMLになり、深くネストしたものは劇的に短くなります――その代償が、JSONには存在しない丸ごと一つのエラークラス、スペースの数が違うという失敗です。一部のパーサーは、この失敗をあなたの間違いからほど遠い行で報告します。
| 項目 | JSON | YAML |
|---|---|---|
| スコープの目印 | 波括弧と括弧 | インデント（スペースのみ） |
| コメント | なし――設計上排除 | # から行末まで |
| 引用符 | すべての文字列で必須 | ほとんどのスカラーで省略可能 |
| 複数行文字列 | \nエスケープのみ | ブロックスカラー（| と >） |
| アンカー／再利用 | なし | アンカー&とエイリアス* |
| 文法の大きさ | 1ページに収まる（RFC 8259） | 多段構成で有名なほど複雑 |
型：厳格か推論か
JSONのすべての値は自己申告です。文字列は引用符をまとい、数値は裸、ブール値はtrueとfalseのいずれか。YAMLは推論します。裸のyes、no、on、off、true、falseはブール値になり、裸の2026-09-19は日付になり、1.20のような値はリーダーによっては黙って数値1.2になることもあります。この失敗にはコミュニティでの名前があります――ノルウェー問題です。NOのような国コードがブール値falseになることに由来します。パーサーが要求しなくても防御的に引用符を付けるべきであることの、最も強力な論拠がこれです。
裏面も意図的な設計です。YAMLは、8080が面倒な儀式なしにポート番号として読める設定ファイルを求めています。JSONが求めるのは交換です。そこでは出力側と消費側がすべてのバイトについて合意しなければならず、推論はバグです。各フォーマットは、想定する読み手に合わせて最適化されています。
サイズ、パフォーマンス、ツール
YAMLは通常、ファイルは短く、解析は遅くなります。インデントの走査、複数行のブロックスカラー、アンカーの解決はいずれも、JSONの1パス文法より高くつきます。起動時に一度読む設定なら無関係です。しかし1日に数百万回ストリーミングされるワイヤーフォーマットにとって、これこそYAMLが通信経路でJSONを置き換えられなかった理由です。ツールも非対称です――すべての言語は標準ライブラリにJSONパーサーを同梱しますが、YAMLパーサーはサードパーティで、何を受け入れるかに実際の差があります。だからこそこのコンバーターは全仕様を保証する代わりに、サポートするサブセットを明示しています。
- ペイロードサイズ：手書きのファイルではYAMLが勝ち、最小化したJSONは引用符のルールが予測可能に圧縮されるため、通信経路上ではしばしばJSONが勝ちます。
- エラーメッセージ：JSONパーサーは問題の文字を指し示し、YAMLパーサーはインデントが一致しなくなった行を指し示します。
- 相互運用性：JSONはどこでも既定です――ログパイプライン、HTTP API、ブラウザのストレージ。YAMLはKubernetes、CIパイプライン、Ansibleでの既定です。
- 往復変換：準拠した実装のペアならJSON→YAML→JSONは可逆です。YAML→JSONは、ファイルがJSONにない機能――アンカー、複数ドキュメント、文字列以外のキー――を使った瞬間に損失が生じえます。
どちらをどの場面で選ぶか
選択が好みの問題であることはまれで、たいてい読み手の問題です。プログラムがドキュメントを作り、別のプログラムが消費するならJSONです：APIペイロード、構造化ログ、保存された状態、信頼境界を越えるものすべて。人間が書いて保守するドキュメントならYAMLです：CIパイプライン、Kubernetesマニフェスト、docker-composeファイル、レビュアーが記号を解読せずにdiffを読んで理解する必要があるあらゆる設定。
指針はきれいに反転します。15段階のネストを手で整形するJSONに気づいたら、そのファイルはYAMLを求めています。サービスの中で実行時にYAMLを解析していることに気づいたら、そのファイルはJSONを求めています。下のリンクのコンバーターを使えば、移行プロジェクトではなくワンクリックの作業になります。
よくある質問
YAMLはJSONのスーパーセットですか？
YAML 1.2は、ほとんどのJSONドキュメントを有効なYAMLにしました――波括弧がそのままのJSONファイルは、通常、変更なしにYAMLとして解析できます。逆は決して成り立ちません。コメント、アンカー、裸のキー、複数行文字列にはJSON表現がありません。つまり移行経路は設計上の一方向であり、完全なYAML→JSONの忠実度を主張するツールは、静かにサブセットを選んでいます。
解析が速いのはどちらのフォーマットですか？
JSONです。差は広く、一貫しています。JSONの文法はインデント状態を持たない1パスです。一方YAMLのスキャナーは桁の文脈を追跡し、ブロックスカラーを解決し、アンカーを展開します。起動時に読む設定なら差は数ミリ秒で無関係です。しかし大量のマシン間トラフィックでは、これがJSONがワイヤーを握る2つの理由のうちの1つです（もう1つは標準ライブラリでの普遍的サポートです）。
CIシステムやKubernetesがJSONではなくYAMLを使うのはなぜですか？
ドキュメントを書き、レビューするのが人間だからです。YAMLのコメントはマニフェストにインラインで自己説明させ、インデントは深いリソース定義を読みやすく保ち、diffは意図をはっきり示します。交換には危険なYAMLの性質――推論とインデントへの敏感性――こそが、手で保守する設定では強みになります。
YAMLのノルウェー問題とは何ですか？
一部のYAMLパーサーは裸のスカラーの型を推論します。そのためNO（ノルウェー）のような国コードがブール値falseとして解析され、offやonもブール値になります。対策は、文字列のままであるべき値はすべて引用符で囲むことです。JSONは構造上これに免疫があります――引用符なしなら数値かブール値、引用符付きなら文字列であり、間違えうる推論の段階が存在しません。
YAMLからJSONへの変換でデータが失われることはありますか？
あります。文書化されているのは3つの場合です。1ファイルに複数ドキュメントがある場合（単一ドキュメントのコンバーターでは最後の1つしか生き残りません）、アンカーとエイリアス（展開が必須で、内容が複製されます）、そして文字列以外のキーです。このサイトのコンバーターは、ドキュメントを黙って組み替えるのではなく、これらの場合を拒否するか明確に報告します。
YAMLのインデントは2スペースと4スペースのどちらにすべきですか？
どちらも有効です――YAMLが禁じているのはタブであってスペース数ではありません――しかしKubernetes、CI、Dockerのエコシステムでは2スペースが圧倒的な慣習で、1ファイル内で幅を混ぜるのがインデントエラーの発生源です。2を選び、エディタで強制すれば、すべてのdiffが読みやすいまま保てます。