{ freetool24 }
Data Tools

XML vs JSON：APIと設定ファイルのデータフォーマットを理解する

XMLとJSONを比較し、それぞれの使いどころを学び、構造化データの変換・バリデーション・クエリに役立つツールをマスターしましょう。

6分で読めます

モニターに表示されたデータの可視化

外部と通信するアプリケーションは、必ず何らかの構造化フォーマットでデータをやり取りします。2000年代はXMLが主流でした。2010年代にはJSONが台頭しました。しかしXMLが消えたわけではありません――SOAP API、RSSフィード、SVGグラフィック、Androidレイアウト、そして数え切れないほどのエンタープライズシステムを支えています。両方のフォーマットを理解することで、より幅広い対応力を持つ開発者になれます。

JSONの概要

JSON（JavaScript Object Notation）は、モダンなWeb APIの共通言語です。ほとんどのプログラミング言語が持つデータ型に直接対応しています：

{
  "user": {
    "id": 42,
    "name": "Alice Chen",
    "roles": ["admin", "editor"],
    "active": true,
    "score": 98.6,
    "avatar": null
  }
}

型： string、number、boolean、null、array、object。

JSONは簡潔で人間が読みやすく、あらゆる言語で簡単にパースできます。REST API、設定ファイル、ブラウザストレージのデフォルト選択肢です。

XMLの概要

XML（eXtensible Markup Language）は、タグ付き要素のツリーとしてデータを表現します：

<?xml version="1.0" encoding="UTF-8"?>
<user id="42">
  <name>Alice Chen</name>
  <roles>
    <role>admin</role>
    <role>editor</role>
  </roles>
  <active>true</active>
  <score>98.6</score>
</user>

XMLは冗長ですが表現力に富んでいます。属性（上記のid="42"など）、名前空間（語彙の混在に対応）、コメント、処理命令、厳格なバリデーションのためのスキーマをサポートしています。

並べて比較

機能 JSON XML
冗長性 コンパクト 冗長
データ型 6つのネイティブ型 すべてテキスト
コメント ❌ 非対応 ✅ <!-- -->
属性 ❌ 概念なし ✅ あり
名前空間 ❌ 概念なし ✅ あり
スキーマ JSON Schema XSD、DTD、RelaxNG
クエリ言語 JSONPath、jq XPath、XQuery
XSLTトランスフォーム ❌ ✅
人間の可読性 高い 中程度
パースの複雑さ 低い 高め

JSONを使うべき場面

  • REST API（事実上の標準）
  • ブラウザのlocalStorage / sessionStorage
  • 設定ファイル（package.json、tsconfig.json）
  • NoSQLドキュメントストア（MongoDB、Firestoreなど）
  • マイクロサービス間の通信
  • 高速かつ軽量なデータ交換が必要な場面全般

XMLを使うべき場面

  • SOAPウェブサービス（金融・医療・行政など）
  • RSSおよびAtomフィード
  • SVGグラフィック
  • Androidリソースファイル（レイアウト、文字列、マニフェスト）
  • Officeドキュメント形式（.docx、.xlsxはXMLを含むZIPファイル）
  • 混合コンテンツが必要な場面（インラインマークアップを含むテキスト）
  • JSONへの移行が済んでいないエンタープライズシステム

フォーマット間の変換

XMLをJSONに変換しても、1対1のマッピングになることはほとんどありません――属性、テキストノード、名前空間といったXML固有の概念はJSONには存在しないからです。よく使われる変換戦略を紹介します：

属性をプロパティに変換する

<user id="42" active="true">Alice</user>

変換後の例：

{ "@id": "42", "@active": "true", "#text": "Alice" }

またはフラット化：

{ "id": 42, "active": true, "name": "Alice" }

最適なアプローチはユースケースによって異なります。属性の扱い方オプションを備えた XML to JSON Converter で変換を処理してみてください。

JSON SchemaによるJSONのバリデーション

JSON SchemaはJSONドキュメントの期待する構造を定義できます：

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "required": ["id", "name", "email"],
  "properties": {
    "id": { "type": "integer", "minimum": 1 },
    "name": { "type": "string", "minLength": 1 },
    "email": { "type": "string", "format": "email" },
    "roles": {
      "type": "array",
      "items": { "type": "string" }
    }
  }
}

JSON Schema Validator を使ってJSONドキュメントをスキーマに対してバリデーションしましょう――構造上のエラーを本番環境に届く前に検出できます。

JSONPath：ネストされたデータのクエリ

JSONPathとJSONの関係は、XPathとXMLの関係と同じです。クエリ構文の例：

$.store.book[*].author          — すべての著者
$.store.book[0].title           — 最初の本のタイトル
$.store.book[?(@.price < 10)]   — 10ドル未満の本
$..price                        — どこにあっても全priceの値

XMLに対するXPathの同等表現：

/store/book/author               — すべての著者
/store/book[1]/title             — 最初の本のタイトル
/store/book[@price < 10]         — 10ドル未満の本
//price                          — どこにあっても全priceの値

フォーマットとpretty-print

どちらのフォーマットも、ミニファイすると人間には読みにくくなります。デバッグや人間によるレビューには常にpretty-printを使いましょう。

ミニファイされたJSON：

{"user":{"id":42,"name":"Alice Chen","roles":["admin","editor"]}}

pretty-printされたJSON（スペース2つのインデント）：

{
  "user": {
    "id": 42,
    "name": "Alice Chen",
    "roles": [
      "admin",
      "editor"
    ]
  }
}

JSON Formatter を使えば、JSONのpretty-print、ミニファイ、バリデーションを即座に行えます。2つのJSONを比較したい場合は、JSON Diff で変更箇所を正確にハイライト表示できます。

よくある落とし穴

JSON

  • 末尾のカンマ — JSONでは無効（JavaScriptでは有効）
  • シングルクォート — JSONの文字列にはダブルクォートが必要
  • 文字列としての数値 — "42" ≠ 42；一貫性を保つこと
  • 深いネスト — 読みにくくクエリも困難；可能な限りフラット化する

XML

  • エスケープされていない文字 — <、>、&、"、' はエンティティとしてエスケープが必要
  • 先頭のBOM — UTF-8 BOMを解釈できないパーサーがある
  • 名前空間の混乱 — 複数の語彙が混在するドキュメントでは間違えやすい

どちらのフォーマットも十分に理解され、優れたツールが揃っており、今後も使われ続けます。それぞれの使いどころを把握し、データをバリデーションすることで、インテグレーションの信頼性が大幅に向上します。

すべての記事に戻るツールを閲覧