RunToolz iconRunToolz
Welcome to RunToolz!
データフォーマット比較開発者ツール

JSON vs YAML vs XML:どのデータフォーマットを使うべき?

JSON、YAML、XMLの正直な比較 — それぞれの強み、弱み、プロジェクトに合った選び方を解説します。

RunToolz Team2026年2月8日7 min read

数ヶ月ごとに、チームでデータフォーマットの議論が始まります。「なんでここでJSON使ってるの?YAMLの方がずっとスッキリしてるのに。」とか、「XMLにはスキーマがあるから、そっちを使うべきだ。」とか。

真実は、万能なフォーマットは存在しないということ。それぞれが特定の問題を非常にうまく解決するから存在しています。いつどのフォーマットが適切なのか整理しましょう。

クイック判断マトリクス

| 特徴 | JSON | YAML | XML | |------|------|------|-----| | 人間の可読性 | 良い | 非常に良い | 悪い | | マシンパース速度 | 速い | 普通 | 遅い | | コメントサポート | なし | あり | あり | | スキーマ検証 | JSON Schema | 限定的 | XSD(強力) | | データ型 | 基本 | 豊富 | 文字列ベース | | 空白の重要度 | なし | あり(注意!) | なし | | ファイルサイズ | 小さい | 最小 | 大きい | | ブラウザネイティブ対応 | あり | なし | 部分的 | | 最適な用途 | API、設定 | 設定、DevOps | 文書、エンタープライズ |

JSON:ウェブの共通語

JSONはウェブで勝ちました。すべてのAPIがJSONを話し、すべてのブラウザがネイティブでパースし、すべての言語が組み込みサポートを持っています。REST APIを構築しているなら、もう決まっています。

JSONが光る場面:

  • APIのレスポンスとリクエスト
  • パッケージマニフェスト(package.jsoncomposer.json
  • サービス間のデータ交換
  • 高速パースが必要な場面

困る点:コメントが書けません。JSON設定ファイルに値がなぜそう設定されているか説明を付けられません。"_comment"キーで回避する人もいますが、それはハックです。

実際に試してみませんか?JSONのフォーマット&検証

YAML:人間に優しい選択肢

YAMLは人間がまず読めるように設計されました。波括弧なし、ほとんどの文字列に引用符なし、どこにでもコメントを追加できます。DevOpsチームに愛されています — Kubernetes、Docker Compose、GitHub Actions、Ansible — すべてYAMLを選びました。

しかしYAMLには罠があります:空白が重要です。インデントを一つ間違えると設定全体が壊れます。エラーメッセージは?しばしば不親切です。「Mapping values are not allowed here」は200行の設定では大した情報になりません。

また、YAMLの型変換が驚かせることがあります。yestrueになり、3.103.1になり、ノルウェーの国コードNOfalseになります。バグではありません — 予想外のタイミングで噛みつく仕様です。

XML:エンタープライズの主力

XMLは最近たくさん叩かれていて、一部は当然です。冗長ですから。JSONで1行のシンプルなキーバリューペアが、XMLでは3行になります。

しかしXMLは他のフォーマットにできないことができます。XSDスキーマは強力な検証を提供し、データ型、パターン、必須フィールド、値の範囲まで強制できます。XSLTでドキュメントを変換できます。名前空間は異なるソースからのドキュメントを組み合わせる際の名前の衝突を防ぎます。

医療(HL7)、金融(FIXML)、出版(DocBook)にいるなら、XMLは消えません。これらの業界はその厳密さゆえにXMLを選び、その厳密さこそが必要なものです。

いつ何を使うか

JSONを選ぶとき:

  • Web APIの構築
  • シンプルな設定の保存
  • フロントエンドとバックエンド間のデータ交換
  • 高速パースと幅広い言語サポートが必要な場合

YAMLを選ぶとき:

  • CI/CDパイプラインの記述
  • KubernetesやDockerの設定
  • コメントが役立つ、人間が編集する設定ファイル
  • エスケープ文字なしの複数行文字列が必要な場合

XMLを選ぶとき:

  • XMLが必要なエンタープライズシステムとの作業
  • 強力なスキーマ検証が必要な場合
  • 混合コンテンツのドキュメント(データを含むテキスト)
  • ドキュメントタイプを組み合わせるための名前空間が必要な場合

フォーマット間の変換

実務的な現実:フォーマット間の変換が頻繁に必要です。古いXML設定をYAMLに移行したり、API用にYAMLをJSONに変換したりする必要があるかもしれません。

構造は3つのフォーマット間でかなりきれいにマッピングされます。オブジェクトがマップになり要素になります。配列がシーケンスになり繰り返し要素になります。厄介な部分はXMLの属性(JSONやYAMLに直接対応するものがない)とコメント(JSONに変換すると失われる)です。

実際に試してみませんか?YAMLをJSONに変換

XMLとJSON間の変換や、表形式データを扱う際のCSVとJSON間の変換もできます。

本当の答え

エコシステムが期待するものを使いましょう。Kubernetesの設定を書いているならYAML。Web APIを構築しているならJSON。エンタープライズ医療分野ならXML。

ツールやチームの慣習に逆らわないでください。最高のデータフォーマットは、プロジェクトの全員がすでに理解しているものです。


データフォーマットの議論は楽しいですが、思うほど重要なことは稀です。ユースケースに合ったものを選び、一貫性を保ち、実際の問題解決に進みましょう。ユーザーは設定ファイルが波括弧を使うかインデントを使うかなんて気にしません。