XML (Extensible Markup Language) は、データの構造をタグで記述する汎用的なマークアップ言語です。1998 年に W3C が勧告として策定し、HTML と同じく SGML から派生しましたが、独自のタグを自由に定義できる拡張性が最大の特徴です。データの意味と構造を明示的に表現できるため、異なるシステム間のデータ交換フォーマットとして広く採用されてきました。

XML は豊富な関連技術のエコシステムを持っています。XSD (XML Schema Definition) によるスキーマ検証、XSLT (XSL Transformations) による変換、XPath による要素の指定、名前空間による語彙の衝突回避など、大規模で複雑なデータ構造を扱うための仕組みが整備されています。実務では sitemap.xml (検索エンジン向けサイトマップ)、RSS/Atom フィード (ニュース配信)、SOAP (Web サービスプロトコル)、SVG (ベクター画像)、Office ドキュメント (OOXML) など、多くの分野で使われています。

XML の構文ルールは HTML より厳格です。すべてのタグは閉じる必要があり (<br />)、属性値は必ず引用符で囲みます。大文字と小文字は区別され、ルート要素は 1 つだけです。エスケープが必ず必要な文字は & と < の 2 つで、それぞれ & と < というエンティティ参照で書きます。> が必須になるのは ]]> という並びの一部になる場合だけで、引用符 (" と ') は属性値を囲む記号と衝突するときに使う便宜的なエスケープです (W3C の XML 1.0 仕様の規定)。実務では 5 文字をまとめてエスケープしておくのが安全ですが、必須が 2 文字だという区別を知っていれば、他システムが出力した XML でエスケープの粒度が違っていても不正だと誤判定せずに済みます。この厳格さがパーサーの実装を単純にし、データの信頼性を高めています。

近年は REST API のレスポンス形式として JSON に置き換えられる傾向がありますが、XML が依然として選ばれる場面があります。文書構造の表現力が高い (混合コンテンツ、属性とテキストの共存)、厳密なスキーマ検証が必要、名前空間による語彙管理が必要、既存システムとの互換性が求められるといったケースです。業界標準として XML が定着している分野も多くありますが、規格名とデータ形式は一対一ではありません。金融業界の FIX は本来タグと値を並べたテキスト形式で、XML 版は FIXML として別に定義されており、主に清算や後方業務で使われています。医療分野の HL7 も、広く普及しているバージョン 2 系はパイプ記号で区切ったテキストで、XML を使うのはバージョン 3 系と診療文書規格の CDA です。連携仕様を調べるときは、規格名だけで形式を判断せずバージョンまで確認してください。

XML と JSON の比較では、XML はタグや属性などの構文要素が多く冗長になりがちですが、スキーマ検証やコメントをサポートする利点があります。JSON はシンプルで軽量ですが、コメントが書けず、スキーマ検証には JSON Schema という別の仕組みが必要です。

文字数カウントの観点では、XML はタグや属性などの構文要素が多いため、同じデータを表現する場合に JSON や YAML より文字数が多くなります。たとえば <name>太郎</name> は 15 文字ですが、JSON の "name": "太郎" は 12 文字です。差は要素が増えるほど開き、<person><name>太郎</name><age>30</age></person> は 45 文字、同じ内容の {"name":"太郎","age":30} は 22 文字になります (Python 3 で実測)。閉じタグの名前をもう一度書く分、要素数に比例してかさむのが XML の構造上の性質です。ただし転送量として見るときは gzip や Brotli による圧縮まで含めて比べてください。繰り返し出てくるタグ名は圧縮が効きやすく、圧縮後の差は文字数の差ほど大きくは残りません。API レスポンスのサイズ最適化を考えるなら、まず圧縮の有無を確認したうえで判断するのが実態に合います。