JSON→XML変換ツール — データ形式を変換するタイミングと方法

ソフトウェア開発を続けていれば、いつかXMLしか理解しないシステムに出会うでしょう。銀行のSOAP APIかもしれません。エンタープライズERPの統合かもしれません。2003年に構築されて以来変わっていない政府のデータフィードかもしれません。どんな場合でも、モダンなシステムがJSON形式でデータを生成し、それをXMLに変換する必要が生じます。

JSON→XML変換ツールはそのためのものです。JSONを貼り付けると、クリーンなXMLが出力されます。しかし、変換中に実際に何が起きているか、どこでうまくいかないかを理解しておくと、デバッグ時間を節約できます。

なぜJSONとXMLは共存しているのか

XML（eXtensible Markup Language）は1998年に人間とマシンの両方が読める構造化データの標準として導入されました。1990年代後半から2000年代にかけて、エンタープライズソフトウェアの共通言語となりました：SOAPウェブサービス、設定ファイル、ドキュメント形式（Office XML、SVG、XHTML）、大規模システム間のデータ交換などにXMLが使われました。

JSON（JavaScript Object Notation）は2001年にダグラス・クロックフォードが公式に仕様化したシンプルな代替手段として登場しました。JavaScriptとの親和性が高く、XMLよりもはるかに冗長でなく、手書きでの読み書きがずっと簡単でした。REST APIが主流となりJavaScriptがウェブを制覇するにつれ、JSONがAPIレスポンスのデフォルトとなりました。

しかし問題があります。XMLで構築されたシステムは消えていません。メインフレームは今でも動いています。SAPやOracleのERPシステムは依然としてXMLを使用しています。SOAPウェブサービスは銀行、保険、医療、政府の分野でまだ生きています。XSLT、SVG、RSSはXMLベースで、なくなりません。

JSON→XML変換が必要なシナリオ

SOAPのAPI統合： 典型的なケースです。SOAP（Simple Object Access Protocol）はXML形式のリクエストボディを必要とします。アプリケーションがREST APIからJSONでデータを受け取り、それをSOAPエンドポイントに送信する前にXMLに変換する必要があります。金融サービス、医療（HL7）、政府システムで頻繁に発生します。

エンタープライズERPとCRMシステム： SAP、Oracle、旧世代のSalesforce統合は多くの場合XMLベースのAPIを公開するか、XMLフォーマットのデータファイルを期待します。

MavenおよびAntビルド設定： JavaビルドツールはXMLを使用します（MavenのpomXML、AntのbuildXML）。JSONデータからこれらの設定をプログラム的に生成・変更する場合に変換が必要です。

RSSおよびAtomフィード： JSON APIまたはデータベースからフィードを構築する場合、RSS/Atom仕様に準拠したXMLを出力する必要があります。

政府・規制データ提出： 多くの国の税務当局、統計機関、規制機関は依然としてXML形式のデータ提出を要求しています。

変換の仕組み

基本的な概念はシンプルです。JSONのキーと値のペアがXML要素にマッピングされ、JSONオブジェクトが子要素を持つ親要素になり、値がテキストコンテンツになります。

シンプルなオブジェクト

次のようなシンプルなJSONオブジェクト：

{
  "name": "Alice",
  "email": "alice@example.com",
  "age": 30
}

は次のようなXMLになります：

<root>
  <name>Alice</name>
  <email>alice@example.com</email>
  <age>30</age>
</root>

JSONキーがXML要素名になります。値がそれらの要素内のテキストコンテンツになります。XMLは正確に一つのルートノードが必要なため、ラッパーのルート要素が追加されます。

ネストされたオブジェクト

ネストは自然に機能します。別のオブジェクト内にネストされたJSONオブジェクトは、独自の子を持つ親XML要素になります：

{
  "user": {
    "name": "Bob",
    "address": {
      "city": "Portland",
      "country": "US"
    }
  }
}

は次のようになります：

<root>
  <user>
    <name>Bob</name>
    <address>
      <city>Portland</city>
      <country>US</country>
    </address>
  </user>
</root>

データ型

JSONには明示的なデータ型（文字列、数値、真偽値、null、配列、オブジェクト）があります。XMLはテキストのみです。つまり：

• "active": true は <active>true</active> になります
• "count": 42 は <count>42</count> になります
• "score": 3.14 は <score>3.14</score> になります

難しい部分：配列

配列はJSON→XML変換が複雑になる部分です。XMLにはネイティブな配列の概念がないからです。最も一般的なアプローチは汎用ラッパーを使います：

{
  "colors": ["red", "green", "blue"]
}

は次のようになります：

<root>
  <colors>
    <item>red</item>
    <item>green</item>
    <item>blue</item>
  </colors>
</root>

別の一般的なアプローチは親キー名を各要素に使います：

<root>
  <colors>red</colors>
  <colors>green</colors>
  <colors>blue</colors>
</root>

どちらが「正しい」かは一概には言えません。受け取るシステムが何を期待しているかによります。

よくある落とし穴とエッジケース

無効なXMLタグ名

XMLの要素名には厳しいルールがあります：文字またはアンダースコアで始まらなければならず、スペースを含むことができず、"xml"で始まることもできません。JSONキーはほぼ何でも可能です。

これは次のようなJSONキーで問題を起こします：

• 数字で始まるキー： "1stItem" は無効なXMLタグです。一般的な回避策：アンダースコアをプレフィックスとして使う（_1stItem）
• スペースを含むキー： "first name" は <first name> にはなれません
• 特殊文字を含むキー： "price$" や "value@index" — 特殊文字は削除または置換が必要です

JSON null値

JSONのnullにはXMLの直接的な対応物がありません。一般的な規約：

• 要素を完全に省略する
• 空要素を含める：<fieldName/>
• xsi:nil="true" 属性を使う（XSD対応システム向け）

ルート要素の問題

JSONオブジェクトは複数のトップレベルキーを持てます。XMLは正確に一つのルート要素が必要です。

{
  "firstName": "Alice",
  "lastName": "Smith"
}

はXMLでラッパーのルート要素が必要です：

<root>
  <firstName>Alice</firstName>
  <lastName>Smith</lastName>
</root>

XML属性と子要素

XMLにはJSONにない概念があります：要素の属性です。<user id="42" active="true">Alice</user> には属性とコンテンツの両方があります。JSONにはこれに相当するものがありません。

JSON→XMLでは、この区別は通常無視されてすべてが子要素になります。しかし属性を持つXMLを生成する必要がある場合（多くのXMLスキーマが必要とする）、追加のロジックが必要です。

JSONとXML：どちらを使うべきか

JSONが良い場合：

• REST APIの構築
• 開発者が読み書きする設定ファイルの保存
• ウェブサービスとブラウザ間のデータ転送
• JavaScript/TypeScript環境での作業
• ファイルサイズと解析速度が重要な場合

XMLが良い場合：

• ターゲットシステムが必要とする場合（SOAP、多くのエンタープライズAPI）
• ドキュメント構造が必要な場合（混合コンテンツ：埋め込まれたフォーマットタグを持つテキスト）
• 個々のフィールドにメタデータを添付する必要がある場合
• SVG、RSS、XHTML、その他のXMLベースの標準の生成
• 長期アーカイブで自己記述が重要な場合

ほとんどの新しい開発ではJSONがシンプルさで勝ちますが、レガシーXMLの世界は巨大であり消えることはありません。

変換ツールの使い方

JSON→XML変換ツールは一般的なケースを処理します：シンプルなオブジェクト、ネスト構造、配列、基本的なデータ型。JSONを貼り付けると、コピーまたはダウンロードできるフォーマットされたXML出力が生成されます。

本番統合では、利用可能なスキーマ（XSD）に対して出力XMLを常に検証してください。変換は構造を処理しますが、特定のシステムが必要とする要素名、属性要件、名前空間宣言には追加の調整が必要な場合があります。

探索的または一回限りの変換（ペイロードの検査、データ構造の理解、テスト用のXML生成など）では、コードを書いたり何かをインストールしたりせずに数秒で処理できます。