XMLをフォーマット

XML（拡張可能マークアップ言語）は25年以上存在していますが、現代のソフトウェアのインフラストラクチャに深く織り込まれています：Office文書やAndroidレイアウトからSOAP API、RSSフィード、設定ファイル、デジタル保存ワークフローまで。もはや人気者ではありません—その王冠はJSONに渡りました—しかし、XMLは厳密な構造、豊富なメタデータ、長期的な相互運用性が重要である場所で依然として重要です。この記事の目標は、XMLを徹底的に説明することです：その起源、動作方法、処理と検証の方法、新しい形式との比較、そして2025年以降に安全かつ効果的に使用する方法。

1. XMLとは実際何か

XMLは、ネストされた要素と属性を使用して構造化データとドキュメントを表現するための簡略化されたマークアップ言語です。World Wide Web Consortiumの 拡張可能マークアップ言語 (XML) 1.0勧告 によって定義されており、整形式XMLドキュメントの構文を指定し、プロセッサがそれらをどのように処理すべきかを記述しています。

XML仕様は、XMLをSGML（標準一般化マークアップ言語）の制限されたサブセットとして記述しており、SGMLの核心的な力—明示的なマークアップで構造化テキストを表現すること—を保持しながら、実装をより簡単にするように設計されています。

いくつかの重要な特性がXMLを特徴づけます：

• テキストベースでUnicode対応。 XMLドキュメントはプレーンテキストで、Unicode/ISO 10646文字セットに依存しており、これにより移植性と言語独立性がもたらされます。
• 自己記述的。 タグ名と属性は意味を持ちます。構造を基本的に理解するために別のスキーマは必要ありません（ただし、スキーマはそれをはるかに強力にします）。
• 階層的。 XMLのツリー構造は、ネストされたデータ、ドキュメント、設定階層に直接マッピングされます。
• 拡張可能。 独自のタグと語彙を発明できます；XML自体は許可された要素のセットを固定しません。

2. 簡単な歴史：SGMLからXMLへ、そして現代のWebへ

XMLのルーツはSGMLにあり、1980年代のISO標準で、出版や技術文書で広く使用されていました。1990年代中期までに、WebのHTML（それ自体がSGMLベース）はどこにでもありましたが、制限が多すぎ、プレゼンテーションと密接に結合していました。

1996–1997年頃、Jon Bosak、Tim Bray、C. M. Sperberg-McQueen、James Clarkなどを含むワーキンググループが、簡単かつ信頼性高く解析できる、よりシンプルでWebに適したSGMLのサブセットを設計し始めました。最初のXML 1.0勧告は1998年に公開され、XMLはSOAP、WSDL、SVG、XSLT、および多数の業界固有の語彙を含む、多くの初期Web標準とプロトコルの基盤となりました。

その後、XML 1.1は文字処理と制御文字のいくつかのエッジケースを改良しましたが、XML 1.0は実践では依然として支配的なバリアントです。

3. コアXML構文：整形式ドキュメント

XML 1.0仕様は、整形式ドキュメントの正確な構文を定義しています。最低限、整形式XMLドキュメントは：

• 正確に1つのルート要素を持ちます。
• 一致する開始タグと終了タグを使用します。
• 要素を適切にネストします（重複するタグはありません）。
• 引用符で囲まれた属性値を使用します。
• 合法な文字とエンコーディングを使用します。

小さくても有効なドキュメントは次のようになります：

<?xml version="1.0" encoding="UTF-8"?>
<note>
  <to>George</to>
  <from>Adam</from>
  <message>Hello XML!</message>
</note>

XML宣言はオプションですが、バージョンと文字エンコーディングを指定する従来の方法です。ドキュメント要素 <note> は単一のルートです。テキストノード、要素、属性、コメント、処理命令、エンティティ参照が一緒になって、仕様で記述されているツリー構造を形成します。

XMLはまた、整形式と 有効なドキュメントを区別します：

• 整形式ドキュメントは構文規則に従います。
• 有効なドキュメントは、さらに、その構造と内容を制約するDTDまたはスキーマに準拠しています。

4. 名前空間：語彙を安全に混合する

XML語彙が増えるにつれて、名前の衝突が問題になりました：1つの語彙が <title> を書籍のタイトルに使用する可能性があります；別の語彙は職位のタイトルに使用します。衝突を避けるために、XMLは 名前空間を導入しました。これはW3C勧告 XMLの名前空間 で定義されています。

例えば：

<book xmlns:dc="http://purl.org/dc/elements/1.1/">
  <dc:title>XML in Depth</dc:title>
</book>

ここで、dc:title は、dcプレフィックスをダブリンコア名前空間URIにバインドすることで、他の <title> 要素から安全に区別されます。名前空間は現代のXMLエコシステムで重要です：XSD、XSLT、SOAP、RSS、Office Open XMLはすべてそれらに大きく依存しています。

5. 検証：DTD、XML Schemaなど

5.1 DTD

元のXML仕様には、ドキュメントの許可された構造—許可された要素、属性、エンティティなど—を定義する標準的な方法として Document Type Definitions (DTD) が含まれていました。DTDはコンパクトでXMLプロローグにうまく統合されていますが、制限があります：非XML構文を使用し、型付けが弱く、名前空間で苦労します。

5.2 XML Schema (XSD)

DTDの制限に対処するため、W3Cは XML Schema Definition (XSD)を標準化しました。現在はバージョン1.1で、 XML Schema Definition Language (XSD) 1.1 Part 1: Structures にあります。XSD自体がXMLで記述され、名前空間をサポートし、豊富な型付け（文字列、数値、日付、リスト、ユニオン）、出現制約、複雑なコンテンツモデルを提供します。

他のスキーマ言語—RELAX NGやSchematronなど—が存在しますが、XSDは多くの企業環境や標準駆動の環境で事実上の標準のままです。

5.3 検証が重要な理由

検証は、XMLを構造化テキストからシステム間の 契約に変換します。例えば：

• 金融メッセージング仕様は、支払い指示のための厳格なスキーマを定義します。
• Office Open XMLやRSSなどの標準は、スキーマでドキュメント形式を形式化します。
• ビルドおよび設定ツールは、pom.xmlや web.config などのファイルを検証して、エラーを早期に検出します。

6. XMLの処理：DOM、SAX、ストリーミング

XML自体は単なるテキストです。何か有用なことをするには、ソフトウェアはそれを何らかのモデルに解析する必要があります。2つの古典的な処理モデルは DOM と SAXです。

6.1 DOM：メモリ内ツリー

W3Cの DOM Level 3 Core仕様 は、要素、属性、テキスト、コメントなどのノードを持つ完全なドキュメントツリーを表す言語中立のオブジェクトモデルを定義しています。DOMはランダムアクセスに適しており、推論が容易で、ライブラリで広くサポートされていますが、ドキュメント全体をメモリに保持する必要があります。

6.2 SAX：イベント駆動ストリーミング

Simple API for XML (SAX) は、XMLをストリームとして解析し、"要素の開始"や"要素の終了"などのイベントに対してコールバックを発火するイベント駆動APIです。 SAXプロジェクトサイト と Oracle SAXチュートリアル で説明されています。

SAXは、ツリー全体を保存せずに1回のパスでドキュメントを処理するため、メモリ効率が非常に高く、ログ、メッセージ処理、バッチ変換などの大きなストリームに理想的です。StAXなどのプルベースのストリーミングAPIは同様の原則に従います。

7. XPath、XSLT、XQuery：XMLのクエリと変換

7.1 XPath

XPath は、/bookstore/book[1]/titleなどのパスライクな式を使用してXMLドキュメントの部分をアドレス指定するコンパクトなクエリ言語です。最新バージョンは XPath 3.1 で定義されており、マップと配列を介してJSONデータも処理するようにモデルを拡張し、大量の標準関数によってサポートされています。

XPathは多くのツールに組み込まれています：XSLT、XQuery、XML Schemaアサーション、および人気のあるプログラミング言語のAPI。

7.2 XSLT

XSL Transformations (XSLT) は、XMLを他の形式—XML、HTML、テキスト、または現代のプロセッサではJSON—に変換するための宣言型言語です。W3Cの XSLT 3.0勧告 は、パターンマッチングと選択のためにXPathに依存するテンプレートベースのシステムを定義しています。

スタイルシート自体がXSLT名前空間を使用するXMLドキュメントです。XSLT 3.0は、巨大なドキュメントのストリーミング機能と、JSONとマップとの統合の改善を追加します。

7.3 XQuery

XQuery は、XMLリポジトリ用の完全なクエリ言語で、 XQuery 3.1 で定義されています。ネイティブXMLデータベースやドキュメントストアに保存されることが多いXMLデータコレクションをクエリおよび変換するように設計されており、FLWOR式（for、let、where、order by、 return）を使用して強力な結果セットを生成します。

XPath、XSLT、XQueryは、特に出版、デジタル人文科学、電子政府、データ統合のコンテキストで、大規模にXMLを操作するための豊富なツールキットを形成しています。

8. 今日のXMLの実際の使用

JSONがWeb APIを支配しているにもかかわらず、XMLは依然として多くのシステムと標準に深く埋め込まれています。

8.1 ドキュメント形式と標準

• Office Open XML (OOXML)。 現代のMicrosoft Office文書（.docx、.xlsx、.pptx）は、 ECMA-376 Office Open XML および関連するISO標準によって定義されたXMLファイルのZIPパッケージです。
• デジタル保存。 議会図書館などの機関は、XML（特にXML 1.0）を構造化デジタルコンテンツを表現するための安定した保存に適した形式として扱っています。
• 学術的および技術的マークアップ。 TEI、DocBook、その他のドメイン固有の語彙はXMLベースで、セマンティックマークアップと長期アーカイブを可能にします。

8.2 メッセージングとWebサービス

• SOAP。 W3Cの SOAP 1.2 仕様は、HTTPなどのプロトコル上で構造化メッセージを交換するためのXMLベースのエンベロープを定義しています。
• RSSとシンジケーション。 RSS 2.0仕様 は、フィードシンジケーション用のXML形式を定義しており、ブログ、ニュース、製品フィードに広く使用されています。

8.3 設定とビルドシステム

• Maven POM。 Apache Mavenのプロジェクトオブジェクトモデル（pom.xml）は、プロジェクトメタデータ、依存関係、プラグイン、ビルド設定を記述するXMLファイルで、 POMリファレンス と POMの紹介 に文書化されています。
• Spring Framework XML設定。 従来のSpringアプリケーションは、applicationContext.xmlや beans.xml ファイルでbeanと配線を定義することが多く、このアプローチは Springリファレンスドキュメント や Java Guides などのチュートリアルで説明されています。
• .NET設定。 ASP.NETとWCFは、XML形式の web.config と app.config ファイルに依存して、エンドポイント、バインディング、動作を設定します。これは Microsoftのweb.configドキュメント と WCF設定ガイド で説明されています。

より一般的には、検証とツールが重要な場合、特にXSDでサポートされるスキーマでは、XMLは一般的な設定形式のままです。

8.4 モバイルとUIレイアウト

Androidでは、UIレイアウトは通常 res/layout の下のXMLファイルで宣言されます。Googleのドキュメントでは、AndroidのXML語彙を使用してレイアウトを記述し、HTMLと同様にビューをネストし、各レイアウトファイルに単一のルート要素が含まれることを説明しています。

9. XML vs JSON vs YAML

2025年までに、JSONはWeb APIの人気コンテストで明確に勝利しました：最近の比較記事では、JSONがWeb API応答の約87％、XMLが9％、YAMLが4％と推定されています。

9.1 XMLの強み

JSONとYAMLと比較して、XMLは以下が必要な場合に優れています：

• 豊富なスキーマと強力な検証。 XSDは、複雑な型、制約、関係を指定でき、成熟したツールとバリデーターのエコシステムを持っています。
• 混合コンテンツとドキュメント。 XMLは、マークアップとテキストが交錯するテキスト豊富なドキュメント用に構築されました；JSONとYAMLは純粋に構造化されたデータにより適しています。
• 深いメタデータと拡張性。 名前空間とスキーマにより、オプションの要素と属性を古いコンシューマーを壊すことなく追加できるバージョン許容ドキュメントが可能になります。

9.2 JSONとYAMLの強み

JSONは読み書きが簡単で、JavaScriptオブジェクトに自然にマッピングされ、ワイヤ上でより小さくなります。チュートリアルでは、JSONが終了タグを省略し、より簡潔で、専用のXMLパーサーなしでブラウザでネイティブに解析できることを頻繁に指摘しています。

YAMLは設定の人間可読性を強調し、KubernetesやAnsibleなどのDevOpsツールで人気がありますが、その複雑さとインデントの感度によりエラーが発生する可能性があります。

9.3 適切な形式の選択

現代のガイダンスは次の傾向があります：

• ほとんどのWeb APIとクライアント-サーバー通信には JSON を使用します。
• クラウド/DevOps環境での開発者中心の設定には YAML を使用します。
• スキーマ駆動のドキュメント、混合コンテンツ、既存のXMLエコシステム（SOAP、OOXML、WCF、Androidレイアウト）、または標準化とツールが成熟している長期アーカイブが必要な場合は XML を使用します。

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

XMLの柔軟性には鋭いエッジが伴います。特に外部エンティティとDTDの周辺です。OWASPの XML External Entity (XXE) 防止チートシート は、XXEの脆弱性が攻撃者にローカルファイルの読み取り、サーバー側リクエスト偽造の実行、エンティティ拡張の悪用によるサービス拒否の引き起こしを可能にする方法を文書化しています。

一般的な攻撃ベクトルには以下が含まれます：

• ローカルまたはリモートリソースを参照する外部エンティティ。
• 巨大なペイロードに拡張されるDTD内のパラメータエンティティ。
• 信頼できないネットワーク上でのDTDの取得。

緩和ガイダンスは一般的に以下を推奨します：

• 可能な限りパーサーでDTDと外部エンティティを無効にします。
• OWASPの推奨事項に従う硬化されたパーサー設定または安全なライブラリを使用します。
• リスクのある機能を有効にせずにスキーマに対して検証します。

その他のセキュリティ考慮事項には、超大規模なドキュメント（リソースの枯渇）、ユーザー入力からクエリを構築するシステムでのXPath/XQueryインジェクション、権限の昇格やコード実行につながる設定ミスのXMLベースの設定ファイルが含まれます。

11. XMLの設計とベストプラクティス

慎重に使用すれば、XMLはデータとドキュメントをモデル化するためのクリーンで堅牢な方法のままです。いくつかの実用的なガイドライン：

• 明確なツリーをモデル化します。 リレーショナルスキーマを直接反映するのではなく、安定した概念ツリー（例えば、<invoice> → <lineItems> → <lineItem>）を中心にXMLを設計します。
• 要素と属性を意図的に選択します。 メインコンテンツと構造には要素を使用します；メタデータとフラグには属性を使用します。
• 最初から名前空間を使用します。 小さな語彙でも、名前空間を割り当てる（例えば、 xmlns="https://example.com/ns/invoice"）ことで、後で苦痛な移行を避けられます。
• スキーマでフォーマットをサポートします。 XSD（または別のスキーマ言語）を提供し、それを公開契約の一部として扱います。CIと統合ポイントでスキーマ検証を使用します。
• 人間が検査可能に保ちます。 きれいな印刷とコメントは、デバッグ、設定、長期メンテナンスに役立ちます。
• データとプレゼンテーションを分離します。 XMLを構造と意味に使用し、XSLTまたは他のツールでHTML、PDF、または他の形式に変換します。
• 適切な処理モデルを選択します。 中小規模のドキュメントと複雑なクエリの場合、DOM + XPath/XSLTが理想的かもしれません；非常に大きなストリームや制約のある環境では、SAX、StAX、またはイベント駆動処理を使用します。
• パーサーを硬化させます。 信頼できない入力を解析する際は、OWASPのXXE防止ガイダンスと言語のセキュリティベストプラクティスに従います。

12. XMLの将来の役割

日常のWeb開発では、XMLは主にJSONとYAMLに中心舞台を譲りました。しかし、多くのドメイン—企業統合、ドキュメント標準、設定管理、デジタル保存、レガシーシステム—では、すべてを新しい形式に書き直すことは実行不可能または望ましくありません。

W3CやEcmaなどの標準機関は、XML 1.x、XML Schema、XPath、XSLT、XQuery、SOAP、OOXMLなどのXMLベースの仕様を維持し続けており、議会図書館などの機関はXMLをアーカイブの主力として扱い続けています。

開発者にとって、これは、Officeファイル、Androidレイアウト、多くのJavaエンタープライズスタック、.NET設定、古いSOAP/WSDLサービス、または標準駆動のデータ交換に触れるたびに、おそらくXMLと対話することを意味します。XMLの構文、名前空間、スキーマ、処理モデルを理解することは、特に統合、インフラストラクチャ、または長期システムで作業する場合、依然として貴重なスキルです。

XMLはもはや現代のWeb APIのスターではないかもしれませんが、大量のソフトウェアのための堅牢で、よく指定され、強力にツール化された基盤のままです。強力なスキーマ、豊富なドキュメント、または既存のXMLベースの標準の広大な風景をナビゲートする必要があるときはいつでも、それを深く学ぶことは報われます。