この用語をシェア
XMLとは
XML（eXtensible Markup Language）は、構造化されたデータを記述するためのマークアップ言語です。拡張可能マークアップ言語とも呼ばれ、独自のタグを自由に定義できることが最大の特徴です。
XMLの主要な特徴
- 拡張性：必要に応じて独自のタグやスキーマを定義可能
- 構造化：階層構造でデータを整理・表現
- 可読性：人間にも機械にも理解しやすい形式
- プラットフォーム非依存：異なるシステム間でのデータ交換が可能
- Unicode対応：多言語文字を含むデータの表現に対応
基本的な構文
<?xml version="1.0" encoding="UTF-8"?>
<book>
<title>IT用語集</title>
<author>野口真一</author>
<year>2025</year>
<chapters>
<chapter id="1">
<title>AI技術</title>
<pages>50</pages>
</chapter>
<chapter id="2">
<title>クラウド技術</title>
<pages>45</pages>
</chapter>
</chapters>
</book>仕組み・詳細解説
XMLを正しく設計・実装するには、単なる「タグでデータを囲む記法」以上に、整形式のルール、名前空間、スキーマ、パース方式という4つの仕組みを理解しておく必要があります。
整形式（Well-formed）と妥当性（Valid）
XML文書には「整形式（well-formed）」と「妥当（valid）」という2段階の正しさの基準があります。整形式とは、XMLパーサーが構文として受理できる最低限の条件で、次のルールを満たす必要があります。
- ルート要素（文書全体を囲む最上位の要素）が1つだけ存在する
- すべての開始タグに対応する終了タグが存在する（
<br/>のような空要素タグも可） - 要素の入れ子が交差しない（
<a><b></a></b>のような重なりは不可） - 属性値は必ず引用符（
"または'）で囲む - 要素名・属性名は大文字と小文字を区別する
これに対して「妥当性」は、DTDやXSDなどのスキーマ定義に照らして、要素の出現順序・出現回数・データ型までが規約どおりかを検証するものです。整形式であることは妥当性検証の前提条件であり、整形式ですらない文書はどのXMLパーサーでもエラーとして拒否されます。実務では「well-formedであることは必須、validであることは業務要件次第」と覚えておくと判断しやすくなります。
名前空間（XML Namespace）
複数のスキーマや語彙を1つの文書内で組み合わせると、同じタグ名が異なる意味で衝突することがあります。これを避けるのが名前空間（Namespace）で、xmlns属性にURIを指定して要素・属性のスコープを一意に区別します。
<book xmlns:dc="http://purl.org/dc/elements/1.1/">
<dc:title>IT用語集</dc:title>
<dc:creator>野口真一</dc:creator>
</book>ここでのURI（http://purl.org/dc/elements/1.1/）はあくまで識別子であり、実際にそのアドレスへアクセスする必要はありません。SOAPやOffice Open XML（.docx/.xlsx）のように、複数の規格を1つの文書内に混在させるフォーマットでは名前空間が必須の仕組みになっています。
スキーマ定義：DTD・XSD・RELAX NG
XML文書の構造を定義する方法は1つではなく、用途や年代によって主に3種類が使われています。
| 方式 | 特徴 |
|---|---|
| DTD （Document Type Definition） |
XML自体とは異なる独自構文。歴史が古く、多くの既存フォーマットで今も使われるが、データ型の指定が弱く名前空間との相性もよくない |
| XSD （XML Schema Definition） |
W3C勧告。スキーマ自体をXMLで記述でき、xs:stringやxs:integerなどのデータ型、minOccurs/maxOccursによる出現回数の制約を厳密に定義可能。SOAP・エンタープライズ連携で標準的 |
| RELAX NG | ISO/IEC 19757規格。XML構文とコンパクト構文（非XML）の両方で記述でき、XSDより文法表現力が高いとされるが採用例はXSDより少ない |
パース方式：DOM・SAX・StAX
プログラムからXMLを読み込む方式にも複数のアプローチがあり、扱うデータ量や用途によって使い分けます。
- DOM（Document Object Model）：文書全体をツリー構造としてメモリ上に展開する方式。要素への自由なアクセスや書き換えがしやすい一方、文書サイズが大きいとメモリ消費が課題になる
- SAX（Simple API for XML）：開始タグ・終了タグ・テキストなどの出現をイベントとして順に通知するプッシュ型の逐次解析。メモリ消費が小さく大規模ファイル向きだが、文書全体を保持しないため後方参照ができない
- StAX（Streaming API for XML）：SAXと同様にストリーミングで処理するが、アプリケーション側が能動的に次のトークンを取得するプル型。Javaの
javax.xml.streamなどで採用され、SAXよりコードの見通しが良いとされる
具体例・ユースケース
XMLが実際にどのような形で使われているか、代表的な4つの現場を具体例とともに見ていきます。
1. SOAP APIのリクエスト／レスポンス
SOAP（Simple Object Access Protocol）は、メッセージ本体をXMLで表現するWebサービスプロトコルです。金融・物流など既存の基幹システム連携で今も現役です。
<!-- リクエスト例 -->
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<GetStockPriceRequest>
<TickerSymbol>IBM</TickerSymbol>
</GetStockPriceRequest>
</soap:Body>
</soap:Envelope>
<!-- レスポンス例 -->
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<GetStockPriceResponse>
<Price>134.50</Price>
</GetStockPriceResponse>
</soap:Body>
</soap:Envelope>2. RSS／Atomフィード
ブログやニュースサイトの更新情報配信に使われるRSS・Atomは、XMLの語彙（ボキャブラリ）として定義された代表例です。
<rss version="2.0">
<channel>
<title>野口真一のブログ</title>
<link>https://shinichi.noguchi.jp.net/blog/</link>
<item>
<title>AI活用事例のご紹介</title>
<pubDate>Mon, 01 Jun 2026 09:00:00 +0900</pubDate>
</item>
</channel>
</rss>3. SVG（ベクター画像）
SVG（Scalable Vector Graphics）はグラフィックを描画するためのXML語彙で、拡大縮小しても劣化しないアイコンやグラフの表現に使われます。ブラウザは<img>タグや<svg>の直接埋め込みとしてそのままレンダリングできます。
4. 設定ファイル・構成ファイル
ビルドツールやフレームワークの設定にもXMLは根強く使われています。代表例として、Javaのビルドツール「Maven」のpom.xml、Androidアプリの画面レイアウトを定義するlayout.xml、Springフレームワークの旧来のBean定義XMLなどが挙げられます。これらはIDEの補完やスキーマ検証が効きやすいという理由で、設定用途では現在もXMLが選ばれ続けています。
メリット・デメリット
メリット
- 拡張性が高い：業務ドメインに合わせて独自タグを自由に定義できる
- 厳密なスキーマ検証：XSDやDTDにより、データの型・出現順序・必須項目までを機械的に検証できる
- 名前空間による衝突回避：複数の語彙を1つの文書に安全に混在させられる
- 変換・整形の仕組みが充実：XSLTを使えばXMLを別のXMLやHTML、テキストへ変換できる
- 属性とテキストを両方保持できる：メタ情報（属性）と内容（テキスト）を分けて記述しやすい
- ツール・エコシステムの成熟度：長年使われてきたためパーサー、バリデータ、IDE支援が豊富
デメリット・注意点
- データサイズが大きくなりがち：開始・終了タグが繰り返されるため、同じ内容でもJSONより冗長になりやすい
- パース・生成のコストが相対的に高い：軽量なJSONのパーサーに比べ、DOM解析はメモリと処理時間を要しやすい
- シンプルなデータ交換には過剰：単純なキー・バリュー程度の情報であれば構造が冗長に感じられる
- 新規Web APIでの採用は減少傾向：モダンなREST APIやマイクロサービスではJSONやgRPC（Protocol Buffers）が主流になりつつある
- セキュリティ設定を誤ると脆弱性になる：後述のXXE攻撃など、パーサーの初期設定次第でリスクが生じる
混同されやすい用語・類似技術との違い
XML と JSON の違い
| 項目 | XML | JSON |
|---|---|---|
| データサイズ | 大きい（タグの冗長性） | 小さい（軽量） |
| 可読性 | 高い（構造化されている） | 高い（シンプル） |
| 属性のサポート | あり（属性とテキストを区別可能） | なし（キーと値のみ） |
| バリデーション | XSD、DTD、RELAX NGで厳密 | JSON Schemaで可能（後発の仕組み） |
| コメント | <!-- -->で記述可能 |
仕様上サポートなし |
| 主な採用領域 | SOAP、EDI、Office文書、設定ファイル | REST API、モバイルアプリ通信、設定ファイル |
XML と HTML の違い
どちらも「タグ」で構造を表す点は共通ですが、目的が異なります。HTMLはブラウザでの表示を目的とした固定のタグ集合（<div>、<p>など）を使い、多少文法が崩れていてもブラウザが解釈して表示してくれます。一方XMLはデータの意味づけを目的とし、タグ名を自由に定義できる代わりに、整形式でない文書はパーサーがエラーとして拒否します。なお、XHTMLはHTMLの語彙をXMLの整形式ルールで書き直したものです。
XML と YAML の違い
YAMLはインデントで階層を表す軽量な記法で、Kubernetesの設定ファイルなどでよく使われます。タグの開閉がない分XMLより人間には読みやすい一方、属性の概念やXSDに相当する成熟した標準スキーマ言語（近年はJSON Schemaの流用が中心）は薄く、スキーマ駆動での厳密な検証を重視する場面ではXMLに分があります。
実務ポイント：設計のベストプラクティスとセキュリティ注意
設計のベストプラクティス
- 命名規則を統一する：要素名・属性名は意味の分かる英語にし、キャメルケースかケバブケースかをプロジェクト内で統一する
- 名前空間はドメイン管理下のURIにする：自組織が管理するドメインを名前空間URIに使い、将来の衝突を避ける
- スキーマ駆動で設計する：先にXSDを設計し、JAXB（Java）などのツールでスキーマからコードを生成すると、実装とスキーマの乖離を防げる
- 属性とテキストの使い分けを決める：メタ情報（IDやタイプ）は属性、本体データは要素の内容として一貫させると可読性が上がる
- バージョニングを組み込む：名前空間URIやルート要素にバージョン情報を含め、後方互換性のある変更をしやすくする
セキュリティ上の注意点
- XXE（XML External Entity）攻撃への対策：DTDの外部実体参照を悪用し、サーバー内のファイルを読み取られたりSSRFに悪用されたりする脆弱性です。多くのXMLパーサーは外部エンティティ解決やDTD処理がデフォルトで有効になっていることがあるため、業務で外部からXMLを受け取る場合はDTD処理や外部エンティティ解決を明示的に無効化する設定が定石です
- エンティティ展開爆弾（いわゆるBillion Laughs攻撃）への対策：内部エンティティを再帰的に定義してメモリを枯渇させる攻撃手法です。エンティティ展開の再帰回数やサイズに上限を設けるパーサー設定が有効です
- XML Signature／XML Encryption：文書の改ざん検知や機密情報の暗号化を行う標準仕様で、SAML（シングルサインオン）などで利用されます
- スキーマバリデーションを入力検証の一部にする：XSDによる型・構造チェックはSQLインジェクション対策そのものではありませんが、想定外のデータ構造を早期に弾く効果があります
2025〜2026年の最新動向
2025〜2026年にかけても、エンタープライズ連携やレガシーシステムの領域ではXMLが健在です。一方で、新規のWeb API開発ではJSONベースのREST APIやProtocol Buffersを用いるgRPCへの移行が続いており、XMLの利用は「新規開発の主役」から「既存資産の保守・連携」へと役割がシフトしています。具体的な傾向は次のとおりです。
- エンタープライズ連携・金融領域：SOAP WebサービスやWS-Security、企業間データ交換（EDI）は現在も多くの基幹システムで稼働中。金融メッセージング標準もXMLベースの規格への移行が段階的に進められています
- Office文書フォーマット：Microsoft Officeの標準形式であるOffice Open XML（.docx/.xlsx/.pptx）は、内部的にZIP圧縮されたXMLファイル群で構成されており、日常的に大量のXMLが生成・消費され続けています
- 出版・ドキュメント管理：DocBookやDITAなど、構造化文書のXML語彙は技術文書・マニュアル制作の現場で根強く使われています
- 設定ファイル領域：Maven、Android、Springなど、スキーマ検証とIDE補完のしやすさを理由にXML形式の設定ファイルを維持しているエコシステムが多数存在します
- AI・LLM連携の文脈：LLMのFunction Calling／Tool UseはJSON Schemaでの入出力定義が主流ですが、既存のXMLベースAPIをラップしてLLMから呼び出せるようにする統合作業（レガシー連携）は引き続き需要があります
総じて、Web API設計の第一候補としては引き続きJSONやgRPCが優勢ですが、厳密なスキーマ検証・名前空間・文書指向のデータを扱う領域では、XMLは今後も一定の存在感を保つと見られます。
よくある質問（FAQ）
Q. XMLとは？
A. XML（eXtensible Markup Language）は、データを構造化して記述するためのマークアップ言語です。タグを自由に定義でき、データの意味を明示できます。SOAPやRSS、SVGなどで広く使用されています。
Q. XMLはまだ使われていますか？
A. Web APIではJSONが主流ですが、SOAP Webサービス、エンタープライズ連携（EDI）、設定ファイル（Maven pom.xml等）、文書形式（Office Open XML）では現在も広く使われています。
Q. XMLとJSONの使い分けは？
A. 軽量なデータ交換にはJSON、厳密なスキーマ検証やドキュメント構造にはXML。レガシーシステムとの連携ではXML、モダンなWeb開発ではJSONが標準的です。
Q. 「整形式（well-formed）」と「妥当（valid）」の違いは何ですか？
A. 整形式は、単一ルート要素・タグの対応・引用符付き属性値などXML構文としての最低条件を満たしていることです。妥当性はさらにDTDやXSDなどのスキーマに照らして要素構成やデータ型が規約どおりであることを指し、整形式であることが妥当性検証の前提になります。
Q. XMLのセキュリティ上の注意点は？
A. 代表的なリスクはXXE（XML External Entity）攻撃で、DTDの外部実体参照を悪用してサーバー内のファイルを読み取られる恐れがあります。外部からXMLを受け取って処理する場合は、パーサーのDTD処理や外部エンティティ解決を無効化する設定が定石です。エンティティを再帰定義してメモリを枯渇させるBillion Laughs攻撃への対策も合わせて検討します。
Q. XSD（XML Schema Definition）とは何ですか？
A. XSDはW3C勧告のXMLスキーマ言語で、XML自体の構文を使って要素の出現順序・出現回数（minOccurs/maxOccurs）・データ型（xs:stringやxs:integerなど）を厳密に定義できます。古くからあるDTDより表現力が高く、SOAPやエンタープライズ連携で標準的に使われています。