DTD と XSD：XML データ構造をめぐる主導権争い 

2026.01.08 最終更新日時 : 2026.01.08 ヴォン

前回までの2回の記事では、次の2つの基礎的な疑問に答えてきました。 

  • なぜ XML は大規模システムの中で今も使われ続けているのか 
  • そして XML は実際にどのように構造化されているのか 

しかし、構造を理解するだけでは問題の“半分”に過ぎません。 
エンタープライズ環境では、データは単に「文法的に正しい」だけでなく、 
システム間で取り交わされる“契約”に従って正しいものでなければなりません。 

もしその制御メカニズムが欠けてしまうと── 

  • 誤ったデータを入力してもシステムが動いてしまう 
  • パートナー企業から送られてくるファイルの形式がバラバラ 
  • バリデーションはコードで手作業のように実装するしかない 
  • 下流工程で初めてエラーが発覚する 

こうした課題が生まれてしまいます。 
これこそが、次に紹介する概念が存在する理由です。 

well-formed ≠ valid この違いが非常に重要になります。 

1. Well-formed は「XML が読み取れる」ことを保証するだけ 

例： 

A computer code on a white background AI-generated content may be incorrect. 
このドキュメントは 

  • 開始タグと終了タグが正しく対応している 
  • XML パーサーにとって構造的に問題がない 

→ しかし、システムが total は数値でなければならない と要求している場合、 
　この XML は実際には利用できません。 

2. DTD：XML スキーマの第一世代 

DTD（Document Type Definition）は XML と同時に登場し、次の目的を持っていました。 

  • 基本的な構造を記述する 
  • XML ドキュメントが「タグだらけの混乱状態」にならないよう保証する 

例： 

【DTD の強み】 

  • シンプルで読みやすい 
  • パースが速い 
  • レガシーシステムでのサポートが広い 

しかし、エンタープライズ環境では DTD の限界が非常に明確になります： 

  • データ型がない（すべて文字列扱い） 
  • namespace をサポートしない 
  • スキーマの拡張が困難 
  • 文法自体が XML ではないため、ツールが扱いにくい 

【よく起きる問題】 

  • 数値チェック、enum（列挙）、pattern（パターン）検証などをしたい場合、結局は独自にバリデーションコードを書く必要がある。　 

3. XSD：データを厳密にコントロールするために 

  • XSD（XML Schema Definition）は、DTD を置き換え、根本的な制約を解決するために設計されました。 

例：データ型の定義 

【XSD のアーキテクチャ上の特徴】 

  • データ型をサポート（string, integer, date, boolean, decimal など） 
  • 値の制約（min/max, pattern, length） 
  • スキーマの再利用（complexType, simpleType） 
  • 標準的な namespace のサポート 

これにより、「設計上の取り決め」を「強制ルール」へと昇格させることができます。 

上記の例は、次のような問題を完全に排除します： 

  • フォーマット不正なデータ 
  • 気まぐれな invoice コード 
  • 手入力ミスによるエラー 

4. Namespace ― DTD が“完敗”するポイント 

前回の記事で、namespaceが名前の衝突を避けるために使われることを確認しました。 

もし XML ドキュメントが 

  • 業界標準 
  • 企業独自の拡張 
  • 別システム向けのメタデータ 
    といった要素を組み合わせている場合、namespaceがない構造はほぼ受け入れられません。 

DTD はこの状況をまったく扱えません。 
XSD はそのために生まれた仕組みです。 

5. アーキテクチャ上の問題：DTD を選ぶべきか、XSD を選ぶべきか？ 

実際の導入現場では次のように使い分けられます。 

DTD を使うべきケース 

  • 既存のレガシーシステムが DTD を使っている 
  • ドキュメントが単純 
  • パース速度を最優先したい 

XSD を使うべきケース 

  • 組織間でデータをやり取りする 
  • 法的コンプライアンスが絡む 
  • 長期的に拡張する必要がある 
  • namespace を複数扱う 

ポイントはこれだけ： 

  • DTD は「構造」をコントロールする 
  • XSD は「構造 + データそのもの」をコントロールする 

6. よくある誤り 

多くのチームが DTD を選ぶ理由は、「速くて、作るのが簡単だから」 
というものです。 

しかしその後に起こるのは── 

  • フィールドを追加すると schema が崩れる 
  • データ型の検証は結局コードで書くしかない 
  • 他システム統合時に namespace が衝突する 

その結果： 
schema は存在しているのに、何も enforce できていない状態になり、 
まるで schema が“ない”のと同じになります。 

DTDとXSDの戦いは、実はエンタープライズ環境ではずっと前に終わっています。 
DTD はレガシー環境や単純なドキュメントでは今も有用ですが、 
もしあなたが求めるのが： 

  • 厳密なデータコントロール 
  • 長期的な拡張性 
  • 複数 XML 標準との連携 
  • 自動化されたバリデーション 

であるなら、XSD はほぼ必須の選択肢 です。 

次のレッスンでは、次の点について詳しく説明します。 
XPath — XML データを “SQL のように” クエリする方法 
について解説していきます。 

カテゴリー
セキュリティ
前の記事
XMLの構造を分解する：初心者のための要素、属性、名前空間の解説
2025.12.30