JSON vs XML: Which Data Format Should You Use?

XML dominated data interchange for over a decade. Then JSON showed up and changed everything. Here's why — and when XML is still the better choice.

JSONTech チームFebruary 20, 202510 min read

簡単な歴史のレッスン

XML（eXtensible Markup Language）は1998年に誕生しました。当時、JavaアプレットやSOAPウェブサービスが最先端の技術でした。XMLは、HTMLのメタ言語であるSGMLの簡略化されたサブセットとして設計され、役割を果たしました。長年にわたり、XMLはデータ交換、構成、文書ストレージ、ほぼすべての用途における標準でした。

しかし、2000年代初頭にウェブ開発者がAJAXアプリケーションを構築し、ブラウザとサーバー間でデータを渡すためにXMLよりも軽量なものが必要だと気づきました。ダグラス・クロックフォードは2001年から2002年にかけてJSONを正式に定義し、急速にシフトが進みました。2010年までには、新しいREST APIのほとんどがJSONを使用していました。2015年には、もはや議論の余地はありませんでした。

しかし、ここで人々が間違えることがあります：XMLは「負けた」わけではありません。XMLは本当に優れている領域に後退したのです。それらの領域を理解することが、思慮深いアーキテクチャの決定と流行に乗ることを区別します。

構文比較

同じデータ — 本のリスト — を両方の形式で表現してみましょう：

JSON

{
  "library": {
    "books": [
      {
        "isbn": "978-0-13-468599-1",
        "title": "The Pragmatic Programmer",
        "author": "David Thomas, Andrew Hunt",
        "year": 2019,
        "available": true,
        "tags": ["programming", "best-practices", "career"]
      },
      {
        "isbn": "978-0-596-51774-8",
        "title": "JavaScript: The Good Parts",
        "author": "Douglas Crockford",
        "year": 2008,
        "available": false,
        "tags": ["javascript", "programming"]
      }
    ]
  }
}

XML

<?xml version="1.0" encoding="UTF-8"?>
<library>
  <books>
    <book isbn="978-0-13-468599-1" available="true">
      <title>The Pragmatic Programmer</title>
      <author>David Thomas, Andrew Hunt</author>
      <year>2019</year>
      <tags>
        <tag>programming</tag>
        <tag>best-practices</tag>
        <tag>career</tag>
      </tags>
    </book>
    <book isbn="978-0-596-51774-8" available="false">
      <title>JavaScript: The Good Parts</title>
      <author>Douglas Crockford</author>
      <year>2008</year>
      <tags>
        <tag>javascript</tag>
        <tag>programming</tag>
      </tags>
    </book>
  </books>
</library>

XMLバージョンは約40%大きく、これは典型的です。すべての要素名は2回表示され（開始タグと終了タグ）、配列にはラッパー要素が必要です。XMLには「属性」と「要素」の概念もあります — isbnとavailableが<book>タグの属性であり、他のフィールドは子要素であることに注意してください。この柔軟性は特徴であると同時に、終わりのない設計論争の原因でもあります。

対照的に、JSONには物事を行う方法が1つあります：キーと値。属性と要素の区別はありません。終了タグもありません。儀式が少なく、曖昧さが少ないのです。

自分で試してみてください： JSONを私たちのJSON to XML converterに貼り付けて、XMLの同等物を瞬時に確認してください。また、XML to JSONで逆に変換することもできます。

機能比較

機能	JSON	XML
冗長性	コンパクト	冗長（開始 + 終了タグ）
可読性	データ構造に適している	文書に適している
コメント	❌ なし	✅ あり（`<!-- comment -->`）
スキーマ検証	JSONスキーマ（別の仕様）	XSD、DTD、RELAX NG（成熟していて強力）
名前空間サポート	❌ なし	✅ あり（名前の衝突を回避）
データ型	文字列、数値、ブール値、null、オブジェクト、配列	すべてがテキスト（型はスキーマによる）
属性	❌ なし（キーのみ）	✅ あり（要素のメタデータ）
混合コンテンツ	❌ なし	✅ あり（テキスト + マークアップの交互）
変換	手動コード	XSLT（宣言的変換）
クエリ言語	JSONPath、JMESPath	XPath、XQuery（より成熟）
解析速度	高速（単純な文法）	遅い（複雑な文法、検証）
ブラウザネイティブ解析	✅ `JSON.parse()`	✅ `DOMParser`
ファイルサイズ（同じデータ）	小さい（XMLの約60-70%）	大きい（冗長なタグ）
ツールエコシステム	現代的で成長中	成熟していて広範囲

XMLがまだ勝つ場合

XMLを完全に切り捨てるのは魅力的ですが、その衝動に抵抗してください。XMLが単に十分ではなく、本当に優れている特定の領域があります。

1. 文書マークアップと混合コンテンツ

これがXMLのキラーフィーチャーです。インラインフォーマットを持つ段落を考えてみてください：

<paragraph>
  これは<bold>重要な</bold>テキストで、
  <link href="/page">ハイパーリンク</link>が埋め込まれています。
</paragraph>

これをJSONで表現しようとすると、混合された文字列とオブジェクト要素の配列、または何らかのマークアップエスケープ構文になってしまいます。JSONは構造化データのために設計されており、文書のためではありません。XMLは両方のために設計されています。

このため、HTML（XMLのいとこ）、DocBook、DITA、出版フォーマットはすべてXMLベースの構文を使用しています。EPUBファイルはXMLです。Microsoft Officeファイル（.docx、.xlsx）は圧縮されたXMLです。文書の世界はXMLで動いており、JSONがその王座を奪うことはありません。

2. SOAPウェブサービス

企業システム、特に銀行、医療、政府では、依然としてSOAPに大きく依存しています。これらのサービスは厳格なスキーマ（WSDL）を持つXMLを使用しており、RESTに移行することはありません。レガシー企業APIと統合する場合、好むと好まざるとにかかわらずXMLを扱うことになります。

3. XSLT変換

XSLTを使用すると、XML文書を宣言的に変換できます — 構造を再編成し、フィルタリングし、フォーマットすることができます — 手続き的なコードを書くことなく。XMLデータからHTMLレポートを生成したり、XMLスキーマ間で変換したり、文書パイプライン処理を行うのに強力です。JSONにはXSLTの能力に匹敵するものはありません。

4. 名前空間

複数のソースからのデータを名前の衝突なしに単一の文書に統合する必要がある場合、XML名前空間はこれを優雅に解決します：

<root xmlns:hr="http://example.com/hr"
      xmlns:fin="http://example.com/finance">
  <hr:employee>
    <hr:name>Alice</hr:name>
    <fin:salary currency="USD">95000</fin:salary>
  </hr:employee>
</root>

JSONには名前空間の概念がありません。2つのAPIが異なる意味を持つ同じキー名を使用している場合、衝突を手動で解決する必要があります。

5. RSS、Atom、およびSVG

RSSおよびAtomフィードはXMLです。SVGグラフィックスもXMLです。これらのフォーマットはウェブエコシステムに深く埋め込まれており、変わることはありません。これらのいずれかを生成または消費する場合、XMLサポートが必要です。

JSONが勝つ場合

ほとんどの現代の開発タスクにおいて、JSONは実用的な選択です。ここでは明確に優位性を示しています：

1. REST API

数字が物語ります。さまざまなAPI調査によると、公開APIの90%以上がJSONを主要なレスポンス形式として使用しています。ワイヤー上で軽量で、解析が速く、JavaScript、Python、Ruby、Go、ほとんどの他の言語のネイティブデータ構造に直接マッピングされます。

// REST APIを呼び出す — レスポンスはすでにJSONです
const response = await fetch("https://api.github.com/users/octocat");
const user = await response.json();
console.log(user.login); // "octocat"

XMLの場合、DOMパーサーをインスタンス化し、ノードをトラバースしてテキストコンテンツを手動で抽出する必要があります。JSONでは、.json()を呼び出すだけでネイティブオブジェクトが得られます。開発者体験のギャップは非常に大きいです。

2. NoSQLデータベース

MongoDB、CouchDB、DynamoDB、Firestore、Elasticsearch — NoSQLエコシステム全体はJSON（またはJSONに似た）文書を中心に構築されています。データがすでにJSONである場合、ドキュメントデータベースに保存するのはほぼ摩擦がありません。

3. モバイルおよびフロントエンドアプリケーション

モバイルアプリは帯域幅とバッテリーを効率的に使用する必要があります。JSONの小さいペイロードサイズと高速な解析は、アプリのパフォーマンス向上に直接つながります。iOS（Codable）とAndroid（Gson、Moshi、Kotlin Serialization）は、優れたJSONライブラリを持っています。

4. 構成（注意点あり）

package.json、tsconfig.json、.eslintrc.json — JSONはJavaScriptツールエコシステムの至る所にあります。コメントがないことはここでの実際の痛点であり、多くのツールがJSONCまたはJSON5を受け入れるようになっています。より複雑な構成については、YAMLを代替として検討することをお勧めします。

5. リアルタイム通信

WebSocketメッセージ、サーバー送信イベント、リアルタイムデータフィードはほぼ普遍的にJSONを使用します。このフォーマットのコンパクトさとネイティブブラウザ解析は、高頻度のデータ交換に理想的です。

両方の形式を使用していますか？ 私たちのJSON to XMLおよびXML to JSONコンバーターを使用すると、簡単に相互変換できます。データを貼り付けて、瞬時に出力を確認してみてください。

業界のシフトの数字

XMLからJSONへのシフトは劇的であり、よく文書化されています：

Stack Overflow Trends： 「json」タグの付いた質問は2013年頃に「xml」を追い越し、現在では約2:1の割合でそれを上回っています。
公開API形式： ProgrammableWebのデータによると、JSONは2011年頃にXMLを超えて最も提供されるAPI形式となりました。今日、JSONは圧倒的な優位性を持っています。
npmエコシステム： 最高のJSON解析ライブラリ（組み込みのJSON.parse）は依存関係がゼロで、すべてのJavaScriptランタイムに同梱されています。XML解析はほとんどの言語でサードパーティライブラリを必要とします。
新しい仕様： ほとんどの新しいデータ標準（JSON-LD、GeoJSON、JSON Schema、JWT）はJSONベースです。XMLベースの仕様はほとんどがメンテナンスモードにあります。

とはいえ、医療（HL7、FHIRは部分的にXMLを使用）、出版（EPUB、DITA）、政府（多くのレガシーシステム）、金融（FIXプロトコル、ISO 20022）などの業界は、依然としてXMLに大きく依存しています。これらの分野で働いている場合、XMLの習熟はオプションではありません。

パフォーマンス比較

典型的なデータペイロードについて、2つの形式の比較は以下の通りです：

指標	JSON	XML
解析時間（1MB、Node.js）	~15ms	~60ms（SAX） / ~150ms（DOM）
シリアル化時間	~10ms	~45ms
ペイロードサイズ（整形）	1.0 MB	1.5–1.7 MB
ペイロードサイズ（最小化）	0.6 MB	1.2 MB（タグは削除できない）
Gzippedサイズ	~120 KB	~140 KB（圧縮で差が縮まる）

gzipped比較は興味深いです — XMLの繰り返しタグは実際にかなりうまく圧縮されるため、圧縮後のサイズ差は大幅に縮小します。gzippedレスポンスを提供している場合（提供すべきです）、ペイロードサイズの議論は最初に見えるほど説得力がありません。ただし、解析速度の違いは依然として重要です。

移行のヒント

XMLからJSONに移行する場合（一般的なタスク）、注意すべき点がいくつかあります：

属性には直接の同等物がありません。 XML属性は通常、変換ツールによって@でプレフィックスされた通常のJSONプロパティになります。
混合コンテンツは表現が難しい。 XMLに要素と交互にテキストがある場合、混合された文字列とオブジェクトの配列のような規約を決定する必要があります。
名前空間情報が失われます。 JSONには名前空間の概念がないため、衝突を手動で処理する必要があります。
順序は重要かもしれませんし、そうでないかもしれません。 XML要素の順序は重要です。JSONオブジェクトのキーの順序は技術的には保証されていません（ただし、ほとんどの実装は挿入順序を保持します）。
変換後に検証してください。 私たちのJSON Validatorを使用して、変換された出力が有効であることを確認し、JSON Compare toolを使用してデータの整合性を確認してください。

評価

現代のウェブ開発の大多数において、JSONは正しいデフォルトです。シンプルで、軽量で、解析が速く、ブラウザでネイティブにサポートされています。エコシステムの勢いは圧倒的です。

しかし、「すべてにJSONを使用する」というのは悪いアドバイスです。XMLは文書中心のデータ、混合コンテンツ、複雑なスキーマ検証、名前空間が多い統合、レガシー企業システムに対しては依然として優れた選択肢です。両方の形式を知り、それぞれが適切な場合を理解することが、あなたをバランスの取れた開発者にします。

私の経験では、最良のアプローチは実用的です：あなたが作業しているエコシステムが期待する形式を使用し、流れに逆らわないことです。必要に応じて相互変換し、実際の問題の解決に進みましょう。

さらに探求してください：

JSONとは？ — 完全な初心者向けガイド
JSON vs YAML — 別の一般的な形式比較
JSON to XML Converter
XML to JSON Converter
JSON Formatter — JSONを瞬時にフォーマットおよび検証