JSONとXMLの相互変換｜データ構造の対応・失われやすい情報・使い分け

WebのAPIではJSON、設定ファイルや業務システムの連携ではXMLと、扱うデータ形式が分かれている場面はよくあります。「このJSONをXMLに変換したい」「受け取ったXMLをJSONとして処理したい」というニーズは日常的に発生しますが、両者は似ているようで設計思想が違うため、機械的に変換すると思わぬ情報が抜け落ちることがあります。本記事では、JSONとXMLの相互変換について、データ構造の対応関係から失われやすい情報、変換時の注意点までを順を追って解説します。

JSONとXMLの基本的な違い

JSON（JavaScript Object Notation）は、キーと値のペアを中心とした軽量なデータ形式です。オブジェクト（{}）、配列（[]）、文字列、数値、真偽値、nullという、プログラミング言語のデータ型に近い構造をそのまま表現できるのが特徴です。記述量が少なく、JavaScriptをはじめ多くの言語でそのままパースできるため、WebのAPIレスポンスで広く使われています。

一方のXML（Extensible Markup Language）は、開始タグと終了タグで要素を囲む、HTMLに似たマークアップ形式です。要素のネスト（入れ子）に加えて、タグに属性を付けられること、名前空間でタグの衝突を避けられること、コメントやスキーマ（DTD・XML Schema）による厳密な構造定義ができることなど、文書としての表現力が豊かです。歴史が長く、企業間データ交換や設定ファイル、ドキュメント記述などで根強く使われています。

つまりJSONは「データ構造をそのまま素直に表す」のが得意、XMLは「文書として豊かにメタ情報を付ける」のが得意という違いがあります。この設計思想の差こそが、相互変換を一筋縄ではいかなくする原因です。

データ構造の対応：オブジェクト・配列・属性

相互変換を理解する第一歩は、両形式の構成要素がどう対応するのかを押さえることです。代表的な対応関係は次のとおりです。

たとえばJSONの{"book": {"title": "XML入門"}}は、XMLでは<book><title>XML入門</title></book>のように、キーが要素名、値がテキストへと対応します。これは比較的素直なマッピングです。

難しいのは配列です。XMLには配列を直接表す記法がなく、通常は同じ名前の要素を繰り返すことで表現します。{"item": ["A", "B"]}は<item>A</item><item>B</item>になりますが、逆方向では「同名要素が1つだけのとき、それは要素1つなのか、要素数1の配列なのか」を機械的に判別できません。ここが変換ツールごとにルールが分かれるポイントです。

さらにXML独自の属性も悩みどころです。<book id="1">のような属性をJSONへ移すとき、多くの変換系では{"book": {"@id": "1"}}のように@などの接頭辞を付けたキーで表します。要素のテキスト内容は#textといった特別なキーに割り当てるのが一般的です。こうした「JSONにない概念をどう表すか」の規約は標準化されておらず、ツールによって異なります。

変換で失われやすい情報

JSONとXMLは表現できる範囲が重ならない部分があるため、変換は必ずしも可逆（往復しても元に戻る）とは限りません。とくに次のような情報は失われたり変質したりしやすいので注意が必要です。

• 属性と要素の区別：XML→JSONで属性を@付きキーに落とし込んだあと、JSON→XMLで戻すと、規約が一致しなければ属性が要素になってしまうことがあります。
• 要素の順序：XMLでは子要素の並び順に意味があることがありますが、JSONオブジェクトのキーは原則として順序を保証しません。順序が重要な文書では情報が損なわれます。
• コメント・名前空間・処理命令：XMLのコメントや名前空間宣言、<?xml ?>のような処理命令は、JSONに対応する概念がなく、変換時に捨てられがちです。
• データ型：JSONの数値や真偽値はXMLでは単なる文字列になります。逆にXMLの"123"を数値とみなすかは判断が必要で、型情報が曖昧になります。
• 空要素とnull：XMLの空要素（<a/>）を空文字列とするかnullとするか、扱いがツールで分かれます。

こうした損失は、変換が「データ構造の写し替え」であって「完全な等価変換」ではないことに起因します。変換後は必ず内容を確認し、必要なら整形して目視チェックすることが大切です。XMLの構造を見やすく整える際はXMLフォーマッターツールが役立ちます。

用途別の使い分け

そもそも、どちらの形式を使うべきかは用途で変わります。変換の前に「本当に変換が必要か」を見極めることも重要です。

JSONが向く場面

WebのAPI、シングルページアプリケーションとの通信、設定ファイルの一部、ログなど、プログラムが読み書きする軽量なデータにはJSONが向きます。記述量が少なく、JavaScriptや多くの言語でそのまま扱え、パースも高速です。データ構造をそのまま素直に表現したい場合の第一候補です。

XMLが向く場面

企業間のデータ交換（EDI）、金融や行政のフォーマット、文書中心のデータ（オフィス文書の内部形式など）、スキーマで厳密に構造を検証したい場合にはXMLが向きます。属性・名前空間・スキーマといった仕組みにより、複雑で長寿命なデータを厳格に定義できるためです。既存システムがXML前提のときも、無理にJSONへ寄せるより素直にXMLを扱うほうが安全なことがあります。

変換が必要になるのは、たとえば「XMLでデータを提供してくる外部APIを、JSON前提の自社システムで扱いたい」といった異なる世界をつなぐ場面です。このときJSON XML変換ツールを使えば、ブラウザ上で素早く相互変換を試せます。

変換時の注意点：属性・名前空間・型

実際に変換する際に、つまずきやすい3つのポイントを押さえておきましょう。

1. 属性の扱いを決めておく：XML→JSONでは、属性を@などの接頭辞付きキーにするか、別オブジェクトにまとめるかなど、ツールの規約を理解しておきます。逆変換で元に戻したいなら、同じ規約を使う変換系で往復するのが安全です。

2. 名前空間に注意する：ns:tagのような名前空間付きのタグは、JSONではコロンを含むキー名になったり、接頭辞が落ちたりします。名前空間が意味を持つデータでは、変換後に衝突や欠落が起きていないか確認が必要です。

3. 型変換を意識する：XMLの値はすべて文字列なので、JSONに変換したときに"true"や"123"が文字列のままになることがあります。受け取り側で数値や真偽値として扱いたい場合は、変換後に型を整える処理（キャスト）が必要です。逆にJSON→XMLでは型情報が落ちるため、スキーマ側で型を定義しておくと安全です。

これらはいずれも「JSONとXMLの表現力の差」から生じる問題です。変換は便利ですが、万能の自動変換は存在しないと理解し、対象データの構造に合わせて規約と確認手順を決めておくことが、トラブルを防ぐ近道です。

実際に変換してみる

理屈を理解したら、実際のデータで試すのがいちばんの近道です。手元のJSONやXMLをJSON XML変換ツールに貼り付けて相互変換し、配列がどう同名要素へ展開されるか、属性がどんなキーになるかを目で確かめてみてください。小さなサンプルで往復変換すると、どこで情報が変わるのかがよく分かります。

変換後のXMLが入り組んでいて読みにくいときは、XMLフォーマッターツールでインデントを整えると構造が一目で把握できます。要素のネストや属性の位置が見やすくなり、変換で意図しない形になっていないかのチェックがぐっと楽になります。JSONとXMLの相互変換は、対応関係と失われやすい情報を理解したうえで、小さく試して目視確認する。この基本を押さえれば、形式の違う世界をスムーズにつなげられます。

なお本記事は一般的な情報の提供を目的としたものです。実際の変換仕様やツールの挙動は、ライブラリや規約によって異なる場合があります。重要なデータを扱う際は、最新の公式仕様やドキュメントを確認したうえで判断してください。