2026年のXML：モダン開発にまだ関連性はあるのか？

正直に言うと、2026年に「XML」と聞くと、最初に「レガシーコード」と思ってしまいます。でもそれは実は不公平です。XMLは地球上で最も重要なシステムのいくつかを静かに動かしており、すぐになくなることはありません。その理由をお見せしましょう。

XMLがまだ主役の場所

銀行・金融： ヨーロッパで銀行送金をするたびに、それがISO 20022メッセージを通る可能性が高いです — これはXMLです。財務報告にはXBRL（これもXML）が使われています。毎日何兆ドルものお金がXMLのパイプを流れているのです。

医療： HL7 FHIRはJSONとXMLの両方を使いますが、ほとんどの病院システムが動いている古いHL7 v2/v3メッセージは？純粋なXMLです。患者記録、検査結果、処方箋 — すべてXMLです。

あなたのOffice文書： すべての.docx、.xlsx、.pptxファイルは実際にはXMLファイルで満たされたZIPアーカイブです。一度開いてみてください — 魅力的です（そしてちょっと怖いです）。

Android開発： AndroidのすべてのレイアウトファイルはXMLです。activity_main.xmlはおそらくすべてのAndroid開発者が最初に作成するファイルでしょう。

ビルドツール： Mavenのpom.xml、.NETの.csprojファイル、Spring Frameworkの設定 — XMLはエンタープライズツールチェーンに深く組み込まれています。

XMLにできてJSONにできないこと

名前空間： 名前の衝突なしに、異なる語彙の要素を1つのドキュメントで組み合わせることを想像してください。XML名前空間がこれを可能にします。HTMLに埋め込まれたSVGや、SOAPヘッダーとカスタムペイロードの混合などのフォーマットに不可欠です。

混合コンテンツ： 一部の単語が太字で他が斜体の段落をJSONで表現してみてください。控えめに言ってもぎこちないです。XMLはドキュメントのために設計されたので、これを自然に処理できます。データだけのためではありません。

XSLT変換： 1つのXSLTスタイルシートを書くだけで、XMLをHTML、PDF、別のXML形式、またはプレーンテキストに変換できます。JSONの世界には本当の意味で対応するものがない宣言的変換言語です。

スキーマ検証： XML Schema (XSD)は多くの分野でJSON Schemaよりも表現力があります。要素の順序、複雑な型階層、JSON Schemaが苦戦するフィールド間の制約を強制できます。

実世界の例

請求書を生成する必要があるEコマースシステムを構築するとしましょう。XML + XSLTを使えば、請求データをXMLに保存し、異なるXSLTスタイルシートを適用して生成できます：ブラウザ用のHTML版、印刷用のPDF版、サプライヤーシステム用のEDI版 — すべて同じソースデータから。JSONでやってみてください。

XML名前空間の実践

名前空間は、実際に必要になるまで混乱するように見えるXML機能の1つです。実践的な例を見てみましょう — XHTMLドキュメント内に埋め込まれたSVGアイコンです：

名前空間がなければ、パーサーはがHTML語彙に属するのかSVG語彙に属するのか分かりません。名前空間があれば、1つのドキュメント内で自由に語彙を混合でき、これはJSONには単純にメカニズムがないものです。

開発者がXMLで犯しがちな間違い

本番システムでXMLを扱って何年も経ちますが、最もよく見る落とし穴はこちらです：

1. エンコーディング宣言を無視する。 XMLファイルに非ASCII文字が含まれているのにエンコーディング宣言を忘れると、パーサーはUTF-8またはデフォルト値を想定します。常に明示的に宣言してください：

2. 要素の方が適切なのに属性を使う。 属性は複雑な構造を保持できず、繰り返すことができず、簡単に進化させることができません。値が後で複雑になる可能性がある場合は、代わりに子要素を使ってください。

3. スキーマに対して検証しない。 検証されていないXMLを受け渡すのは、サイレントな障害のレシピです。XSDがあるなら使ってください。不正なデータがシステムを通じて連鎖するのを防ぎ、パース時にデータの問題を検出します。

4. 文字列連結でXMLを構築する。 これは絶対にやめてください — 起こるのを待っているインジェクション脆弱性です。常に適切なXMLライブラリまたはDOMビルダーを使用してください。

XMLパフォーマンスのヒント

XMLパーサーには主に2つの種類があり、正しいものを選ぶことがパフォーマンスに大きく影響します：

• DOMパーサーはドキュメント全体をツリーとしてメモリにロードします。ランダムアクセスが必要な小〜中規模のドキュメントには最適です。大きなファイルには不向き — 100MBのXMLファイルはDOMツリーとして1GB以上のRAMを消費することがあります。
• SAX/StAXパーサーはドキュメントをストリームとして、一度に1要素ずつ処理します。メモリをほとんど使わず、大きなファイルに対してはるかに高速です。トレードオフは、ドキュメント内を行き来できないことです。

目安はこうです：XMLが10MB未満ならDOMで大丈夫です。10MBを超えたら、ストリーミングを真剣に検討してください。100MBを超えたら、サーバーがメモリ不足になるのを見るのが好きでない限り、ストリーミングは必須です。

XML vs JSON：クイックリファレンス

XMLの簡単な歴史

XMLは1998年2月にW3C勧告として公開されました。1980年代から存在していたが悪名高く複雑だったSGML（Standard Generalized Markup Language）の簡略化されたサブセットとして設計されました。目標は、人間が読めて機械で解析でき、曖昧さを避けるのに十分厳格で、どんなドメインにも十分柔軟なフォーマットを作ることでした。2000年代の最初の10年間、XMLは*まさに*データ交換フォーマットでした。SOAPウェブサービス、RSSフィード、Atomフィード、XHTML — すべてがXMLでした。その後JSONが登場してWeb APIの空間を引き継ぎましたが、XMLはそのユニークな機能（名前空間、スキーマ、変換）が実際に重要なすべてのドメインを保持しました。

現代のXML開発者

今日のほとんどの開発者はハイブリッド環境で働いています。Web APIとリアルタイム通信にはJSONを、ドキュメント処理、エンタープライズ統合、規制順守にはXMLを使います。両方のフォーマットを知り、いつどちらを使うべきか知ることは、本当に価値のあるスキルです。

XMLセキュリティ：XXEとその他の落とし穴

XMLについてセキュリティエンジニアが夜も眠れなくなるものが1つあるとすれば、それはXXE — XML External Entity攻撃です。正直に言うと、あなたも心配すべきです。XXEは正当な理由でOWASP Top 10リストに載っており、2026年でもまだ開発者を不意打ちしています。

XXEの仕組みはこうです：XMLでは、ドキュメント型宣言（DTD）で「エンティティ」— 本質的には変数 — を定義できます。*外部*エンティティはサーバー上のURLやファイルパスを参照できます。パーサーが外部エンティティを解決するよう設定されている場合（多くはデフォルトでそうです）、攻撃者はサーバーから任意のファイルを読み取るXMLを作成できます：

パーサーがこれを処理すると、&xxe;を/etc/passwdの内容で置き換えます。それだけで、攻撃者はシステムから機密ファイルを読み取ります。より高度な攻撃では、サーバーからの送信HTTPリクエスト（Server-Side Request Forgery）を行ったり、悪名高い「billion laughs」攻撃 — 利用可能なすべてのメモリを消費する再帰的なエンティティ展開 — でサービス拒否を引き起こすこともできます。

修正は簡単です：外部エンティティ処理を無効にしてください。 2つの人気のある言語での方法はこちらです：

XXE以外にも、XMLインジェクションに注意してください — ユーザー入力が適切なエスケープなしにXMLに挿入される攻撃です。これはSQLインジェクションのXML版です。文字列連結の代わりに、常に適切なXMLビルダーライブラリを使用してください（よくある間違いのセクションで既に述べましたが、*それほど*重要なので繰り返す価値があります）。

黄金ルール：信頼できないXMLをデフォルトのパーサー設定でパースしないでください。 常に明示的に外部エンティティの解決、DTD処理、XInclude処理を無効にしてください。外部からのXMLは、SQLクエリのユーザー入力と同じ疑いを持って扱ってください。

XPath：プロのようにXMLをクエリする

XMLを定期的に扱っていてXPathを使っていないなら、難しい方法でやっています。XPathはXMLドキュメントをナビゲートするために特別に設計されたクエリ言語で、コツをつかめば非常に強力です。

XPathはCSSセレクターのXML版と考えてください。ネストされたループでDOMを手動で走査する代わりに、必要なノードを正確に選択する簡潔な式を書きます。いくつかの実践的な例を見てみましょう：

JavaScriptとPythonでのXPathの使い方はこちらです — 最も多くの開発者が使う2つの言語です：

注目すべき点が1つあります：JSONには組み込みのクエリ言語がありません。最も近い相当物はjqで、素晴らしいツールですが、フォーマットの標準化された一部ではなく外部ツールです。XPathはXMLエコシステムに組み込まれており — ブラウザがネイティブにサポートし、事実上すべてのプログラミング言語で利用可能で、W3Cによって標準化されています。これはXMLの真の競争優位性の1つです。

XPathはまた、XSLT（変換するノードを選択する）とXQuery（XMLデータベース用の完全なクエリ言語）の基盤でもあります。XPathを学べば、XML技術のファミリー全体を解放したことになります。

業界固有の標準におけるXML

先ほど銀行と医療について触れましたが、業界固有の標準におけるXMLの影響範囲はそれよりもはるかに深いです。XMLが単に使われているだけでなく*必須*であるドメインを見てみましょう：

法律： 法律業界は裁判所への提出やケース管理にXMLを大いに活用しています。OASISが開発したLegalXMLは、電子裁判所提出、法的引用、ケースメタデータを標準化しています。米国では多くの州裁判所システムがXMLベースの電子提出フォーマットを義務付けています。リーガルテックを構築しているなら、XMLの上に構築しています。

出版： これは人々を驚かせる話です — あなたが読んだすべてのEPUB電子書籍はXMLの上に構築されています。EPUBファイルはXHTMLコンテンツファイル（XML）、OPFパッケージ記述子（XML）、ナビゲーションドキュメント（XML）を含むZIPアーカイブです。別のXMLフォーマットであるDocBookは1990年代から技術文書のスタンダードです。O'Reilly Mediaは有名にも何年もDocBookを使って、単一のXMLソースから複数の出力フォーマットで書籍を制作していました。

科学と数学： MathMLはXMLで数学的記法を表現するためのW3C標準です。すべてのモダンブラウザでサポートされており、Web上の科学出版に不可欠です。さらに分子構造のためのChemical Markup Language（CML）、恒星データのためのAstronomical Markup Language、そして数十の他の科学XMLボキャブラリーがあります。精度と曖昧さのないデータ表現が重要な場合 — そして科学では常にそうです — XMLが力を発揮します。

政府と調達： Universal Business Language (UBL)はOASIS標準で、世界中の政府が調達、請求、サプライチェーン管理に使用しています。欧州連合の電子請求指令は、企業対政府の請求にUBLベースのXMLを本質的に義務付けています。ヨーロッパの政府に販売しているなら、XML請求書を送っています。

航空： Aeronautical Information Exchange Model（AIXM）は航空データのXMLスキーマを定義しています — 空港、空域、航法援助施設、手順。すべてのフライト管理システム、すべての航空交通管制の更新、すべてのNOTAM（航空従事者への通知）がAIXMデータに触れています。これは「JSONに切り替えよう」という会話を誰もしていないドメインです。なぜならフォーマット移行の安全性への影響が巨大だからです。

これらすべての業界に共通するのは何でしょうか？強力な検証、語彙を組み合わせるための名前空間、そして後方互換性を壊すことなく数十年にわたって進化できるフォーマットが必要だったためにXMLを選んだということです。これらの要件は変わっていません。

SOAP vs REST：XML APIがまだ存在する理由

過去10年以内にキャリアを始めた方は、すべてのAPIがJSONを使ったRESTだと思うかもしれません。しかし大きな銀行、保険会社、通信会社、政府機関に足を踏み入れれば、重要なビジネスロジックを処理するSOAPウェブサービスが見つかるでしょう。そしてそれには実際に良い理由があります。

SOAP（Simple Object Access Protocol）はXMLベースのメッセージングプロトコルで、REST+JSONが標準では提供していないいくつかの機能を持っています：

WSDLによる強力な契約： WSDL（Web Services Description Language）ファイルはSOAPサービスについて*すべて*を記述します — オペレーション、入出力メッセージ構造、データ型、エンドポイント。WSDLからJava、C#、Python、事実上すべてのエンタープライズ言語でクライアントコードを自動生成できます。REST APIにはOpenAPI/Swaggerがありますが、採用は任意です。SOAPでは、契約がサービスそのものです。

組み込みのエラー処理： SOAPにはフォルトコード、フォルト文字列、詳細要素を持つ標準化されたfault要素があります。すべてのSOAPクライアントはエラーのパース方法を正確に知っています。REST APIは？各APIが独自のエラーフォーマットを発明します。

WS-Security： SOAPにはメッセージレベルの暗号化と署名をサポートする包括的なセキュリティ標準があります — トランスポートレベル（TLS）だけではありません。これは、SOAPメッセージが中間サーバーを通過しながらもエンドツーエンドで暗号化されたまままでいられることを意味します。メッセージが複数のシステムを経由する金融サービスでは、これが非常に重要です。

トランザクションと信頼性： WS-AtomicTransactionとWS-ReliableMessagingは分散トランザクションサポートと保証された配信を提供します。これらはRESTがアプリケーション開発者に完全に委ねている難しい問題です。

とはいえ、SOAPには実際の欠点があります：メッセージは冗長で、学習曲線は急で、デバッグは苦痛で、XMLのオーバーヘッドにより単純なCRUD操作ではJSONより遅くなります。新しいWeb APIやマイクロサービスには、REST+JSONがほぼ常に正しい選択です。しかし複雑なエンタープライズ統合 — 特に規制された業界では — SOAPの組み込みの契約適用とセキュリティ機能は本当に価値があります。

XMLからJSONへの移行：実践ガイド

キャリアのどこかで、誰かがXMLベースのシステムをJSONに移行するよう依頼するでしょう。「もちろん、簡単です」と言う前に、誰もが驚く落とし穴をお見せしましょう。

属性の喪失： XML要素は属性と子要素の両方を持てます。JSONオブジェクトにはプロパティしかありません。Duneを変換するとき、idはどこに行きますか？formatは？テキストコンテンツは？一般的な慣例では属性に@プレフィックス、テキストコンテンツに#textを使いますが、普遍的な標準はありません — そしてあなたが何を選んでも、相手のシステムがあなたの慣例を理解する必要があります。

型変換： XMLは本質的にテキストベースです。XMLの文字列"42"は整数、浮動小数点数、文字列、または郵便番号かもしれません。JSONには明確な型があります。移行中には明示的な型マッピングルールが必要で、さもなければ数値が欲しいところに文字列が（またはさらに悪いことに、文字列が欲しいところに数値が — 郵便番号の先頭ゼロよさようなら）できてしまいます。

配列の曖昧さ： これは特にやっかいです。XMLでは、要素に子が1つあれば単一の要素です。同じ名前の複数の子があれば、自然にコレクションです。しかしJSONは何かが配列なのか単一の値なのかを事前に知る必要があります。考えてみてください：Widget — itemは文字列ですか、それとも1要素の配列ですか？別の注文に3つのアイテムがある場合、構造が変わります。JSONコンシューマーは両方のケースを処理する必要があります。

成功する移行のステップ：

• ステップ1： すべてのXMLスキーマの棚卸しを行い、使用している機能（名前空間、属性、混合コンテンツ、CDATAセクション、処理命令）を正確に文書化します。
• ステップ2： まずJSONスキーマを設計し、属性、混合コンテンツ、配列の処理方法を明示的に決定します。すべての決定を文書化します。
• ステップ3： 変換レイヤーを構築します（ビッグバンの書き直しではなく）。両方のフォーマットを並行して実行し、出力を比較します。
• ステップ4： コンシューマーを1つずつ移行し、全員が切り替わるまでXMLエンドポイントを維持します。
• ステップ5： XMLを廃止する前に、少なくとも1つの完全なビジネスサイクル（ドメインに応じて月、四半期、または年）の間、並行システムを運用します。

移行すべきでないとき： XMLが名前空間の大量混合、XSLT変換、またはXPathベースのビジネスルールを使用している場合、移行コストが利点を上回る可能性があります。また、XMLが規制標準（HL7、ISO 20022、UBL）によって義務付けられている場合、いずれにしてもXMLを維持することになります — JSONを追加することは、サポートする2番目のフォーマットを追加するだけです。

すべての開発者が知るべきXMLツール

適切なツールがあれば、XMLでの作業は苦痛である必要はありません。私が頼りにしているツールはこちらです：

xmllint： libxml2に付属しており、おそらく既にシステムにあります。スキーマに対してXMLを検証し、XMLをフォーマット（プリティプリント）し、XPath式を評価します — すべてコマンドラインから。XMLの世界のcurlです：シンプルで、速く、どこにでもあります。

Saxon： XSLTおよびXQuery処理のゴールドスタンダードで、Michael Kay（XSLT 2.0および3.0の仕様を文字通り編集した人物）が開発しました。本格的なXSLT変換を行うなら、Saxonが必要です。オープンソースのHome EditionはXSLT 3.0とXPath 3.1を処理します。

XMLSpy（Altova）： エンタープライズで人気のある商用XML IDEです。ビジュアルスキーマエディタ、XSLTデバッガ、データベース統合を備えています。高価ですが強力で、手動で編集するのが非現実的な巨大なXSDスキーマを扱う際に特に有用です。

oXygen XML Editor： XML集約的な作業に対する私の個人的なお気に入りです。ステップスルー実行によるXSLTデバッグ、XPath評価、自動補完付きのスキーマ対応編集をサポートし、DITAとDocBookの優れたサポートがあります。定期的にXSLTを書くなら、oXygenは1週間で元が取れます。

xmlstarlet： ターミナルから直接XMLをクエリ、編集、検証、変換できるコマンドラインXMLツールキットです。XMLのsedとawkと考えてください。XML設定ファイルから値を抽出したり、その場でXMLを変更する必要があるシェルスクリプトやCI/CDパイプラインに最適です。

XML拡張機能付きのVisual Studio Code： すでにVS Codeを使っているなら、Red Hatの「XML」拡張機能がスキーマ検証、自動補完、フォーマットを提供します。「XSLT/XPath」拡張機能と組み合わせれば、時々のXML作業には驚くほど有能な無料セットアップです。

自分で試してみよう

2つの世界をつなぐ必要がありますか？当サイトのXML to JSONコンバーターがデータ構造と型を保持しながら変換を処理します。XMLをデバッグしているなら、XML Formatterがどんなに醜いXMLも読みやすくします。そして本番環境にXMLをデプロイする前に、XML Validatorで構造的な問題を早期に検出しましょう。