1.1 データフォーマット比較 (XML, JSON, YAML)

あるプログラムが持っている「ルーター1台の情報」を、別のプログラムに送りたいとする。このとき、データをそのまま渡すことはできない。一度、誰が見ても同じ規則で読める「文字列」に書き直してから渡す必要がある。この「データを書き表すための共通の書式」がデータフォーマットである。XML・JSON・YAML は、その代表的な3つの形式だ。ネットワーク自動化では、API のやり取りや設定ファイルの中身として毎日のように登場する。

なぜ「データフォーマット」という層が必要なのか

データフォーマットという独立した層が要るのは、内部のデータの持ち方がプログラミング言語ごとに違っても、互いにデータを渡し合えるようにするためである。間に「共通の文字列」を1枚かませる、というのがその答えだ。理由を順に見ていく。

たとえば、Python で書いたプログラムの中では、データは「辞書」や「リスト」といった、その言語だけのまとまりとして存在している。しかし、この内部の持ち方はプログラミング言語ごとにバラバラである。そのため、内部の形のままではネットワーク越しに送ったり、ファイルに保存したりできない。

そこで、いったん「どの言語からでも同じ規則で読み書きできる文字列」に直す。この「内部のデータ → 文字列」への変換を シリアライズ（直列化） と呼ぶ。逆に「文字列 → 内部のデータ」へ戻すことを パース（解析） と呼ぶ。データフォーマットとは、このとき使う「共通の書き方のルール」のことである。

この共通ルールがあると、送り手と受け手で使っている言語が違っても通じ合える。たとえば送り手が Python、受け手が Go や JavaScript でも、間に挟まる文字列の文法さえ決まっていれば、互いに解釈できる。ネットワーク機器とコントローラ、コントローラと自動化スクリプト——このように作り手も実装言語も異なるもの同士をつなぐために、データフォーマットという層が独立して存在している。

この往復をまとめると次のようになる。左右で言語が違っても、真ん中に「文字列」という共通の通り道があるおかげでデータを渡し合える、という流れである。

flowchart LR
    A["送り手の内部データ
(例: Python の辞書・リスト)"] -->|シリアライズ| B["文字列
XML / JSON / YAML の
いずれかの書式"]
    B -->|パース| C["受け手の内部データ
(例: Go や JavaScript の
オブジェクト)"]

なぜ複数のフォーマットが併存するのか

3つのフォーマットが1つに統一されず併存しているのは、それぞれが 解こうとした課題がそもそも違う からである。「共通の書式が必要」なら世界で1つにまとめればよさそうに思えるが、現実にはそうなっていない。なぜか。それぞれが「いつ・何のために」生まれたかを追うと、併存する理由が見えてくる。

• XML（eXtensible Markup Language） は、もともと文書（ドキュメント）をきちんと構造化するために生まれた。Web ページを書く HTML の親戚にあたる。XML が重視したのは「厳密さ」と「自己説明的であること」だ。たとえばタグに属性（タグに付ける補足情報）を足せる。名前空間 という仕組みで、同じ名前のタグが別の意味でぶつかるのを防げる。さらに スキーマ ——「この文書はこういう形でなければならない」という設計図——を使い、内容が正しい形かどうかを機械にチェックさせられる（XML 用のスキーマを XSD と呼ぶ）。こうした仕組みのおかげで、複雑で正確さが要る文書のやり取りに強い。半面、開始タグと終了タグを何度も書くため記述量が多く、冗長になりやすい。

• JSON（JavaScript Object Notation） は、Web の API でデータをやり取りする際、もっと軽くしたいという要求から広まった。JavaScript という言語の「オブジェクトの書き方」をほぼそのまま借りている。中身は「オブジェクト（キーと値の組の集まり）」と「配列（値を並べたもの）」という2つだけ。これらは、ほとんどのプログラミング言語に共通して存在する基本的なデータの形である。XML が持っていた属性や名前空間といった凝った仕組みは思い切って省いた。代わりに、機械が速く読み取れて、プログラム内部のデータとの対応が素直であること を優先した。タグがないぶん軽く、ほぼすべての言語が最初から（追加部品なしで）読み書きできる。

• YAML（YAML Ain’t Markup Language） は、JSON よりもさらに 人間が読み書きしやすいこと を優先して生まれた。波かっこ {} や引用符をできるだけ使わず、行頭のインデント（字下げ）の深さだけで階層の親子関係を表す。コメント（人間向けのメモ書き。機械は無視する）も書けるので、「なぜこの設定にしたか」を残せる。人が手で編集し続ける設定ファイルに向く。ただし空白の量で構造が決まるため、インデントが1つずれるとそれだけで意味が変わってしまう繊細さがある。

つまり XML は「厳密なチェック」、JSON は「軽い機械処理」、YAML は「人による編集のしやすさ」と、3つは重視する点（重心）が違う。1つに統一されないのは、いちばん向いているフォーマットが 用途によって変わる からである。

この「どの課題に重心を置いたか」を1枚にまとめると次のようになる。3つは優劣の関係ではなく、それぞれ別の方向に強みを伸ばした結果として並んで存在している。

flowchart TD
    Q["構造を持つデータを
どう書き表すか"] --> X["XML"]
    Q --> J["JSON"]
    Q --> Y["YAML"]
    X --> XV["重心: 厳密な検証
スキーマで形をチェック
正確さが要る文書・機器設定に強い"]
    J --> JV["重心: 軽量な機械処理
速く読めて構造が素直
機械同士の API 交換に強い"]
    Y --> YV["重心: 人による編集
インデントで読みやすくコメント可
人が手で書く設定ファイルに強い"]

同じデータを三形式で表現する

先に結論を言うと、3形式は見た目こそ大きく違うが、表しているデータの構造は同じである。違うのは書き方のルールだけだ。これを実感するために、まったく同じ内容を3形式で並べて書いてみる。

言葉だけの比較では差が見えにくいからだ。題材はネットワーク機器1台の情報。盛り込むのは、機器名（hostname）・管理用の IP アドレス（mgmt-ip）・稼働しているか（enabled）・搭載しているインターフェース2つ、という最小限の情報である。同じ情報なので、3つを見比べると「書き方の違い」だけが浮かび上がる。

XML

<device>
  <hostname>router1</hostname>
  <mgmt-ip>192.0.2.1</mgmt-ip>
  <enabled>true</enabled>
  <interfaces>
    <interface>
      <name>GigabitEthernet0/0</name>
      <speed>1000</speed>
    </interface>
    <interface>
      <name>GigabitEthernet0/1</name>
      <speed>1000</speed>
    </interface>
  </interfaces>
</device>

JSON

{
  "device": {
    "hostname": "router1",
    "mgmt-ip": "192.0.2.1",
    "enabled": true,
    "interfaces": [
      { "name": "GigabitEthernet0/0", "speed": 1000 },
      { "name": "GigabitEthernet0/1", "speed": 1000 }
    ]
  }
}

YAML

device:
  hostname: router1
  mgmt-ip: 192.0.2.1
  enabled: true
  interfaces:
    - name: GigabitEthernet0/0
      speed: 1000
    - name: GigabitEthernet0/1
      speed: 1000

中身は同じなのに、見た目はずいぶん違う。XML は開始タグと終了タグを繰り返すため、行数も文字数も最も多い。JSON は波かっこ {} と角かっこ [] で構造を示す。YAML はインデントとハイフン - だけで表すので、いちばん短い。

それでも、冒頭で述べたとおり、3つに共通する「骨組み」は同じである。すなわち「キーと値の組」「入れ子（あるまとまりの中に別のまとまりが入る）」「リスト（インターフェースが複数並ぶ）」の3つだ。フォーマットが違っても、表しているデータの構造は同一である。違うのは 見た目のルール だけで、データそのものは変わっていない。ここが本節でいちばん押さえたい点である。

なぜネットワーク自動化で JSON/YAML が多用され、XML も残るのか

結論を先に言うと、機械同士の API 交換には JSON、人が書く設定ファイルには YAML、機器設定の操作には XML、という棲み分けになっている。これはここまで見た「重心の違い」が、実際の現場での使い分けにそのまま効いた結果だ。1つずつ理由を見ていく。

• REST API のやり取りは JSON が主流。 REST とは、Web でおなじみの HTTP という通信のうえでデータを交換する、広く使われている方式である。やり取りする相手は、Web 画面・いろいろな言語で書かれたスクリプトなど多様だ。JSON は軽く、読み取り（パース）が速く、ほぼすべての言語が最初から対応している。だから、機械同士がデータを何度も往復させる用途で最も引っかかりが少ない。実際、Cisco の多くの製品（DNA Center や Meraki など）の REST API も JSON で応答を返す。

• 設定ファイルやプレイブックは YAML が主流。 たとえば自動化ツール Ansible の「プレイブック」（やりたい作業の手順を書いたファイル）は、人間が書いて管理する。YAML はインデントで読みやすく、コメントで意図を書き残せる。だから、人が繰り返し手で編集していくファイルに向く。ここでは「機械処理の速さ」より「人にとっての読み書きやすさ」のほうが大事になる。

• XML は NETCONF などで根強く残る。 NETCONF とは、ネットワーク機器の設定をプログラムから安全に操作するための専用の手順（プロトコル）で、データの表し方に XML を使う。なぜ XML なのか。機器の設定は「間違えると通信が止まる」領域だからである。ここでは XML の持つ 厳密さと、内容を機械でチェックできること が活きる。具体的には、YANG というデータモデル——「この設定はどんな形を取りうるか」を定めた設計図——で構造を定義し、送られてきた設定がその形に合っているかを機械的に検証できる。さらに名前空間のおかげで、機能ごとの設計図どうしが名前でぶつからずに組み合わせられる。多機能な機器の設定にはこれが効く。つまり XML は「古いから惰性で残っている」のではない。正確さが何より優先される場面で、その強みがちょうど効いている のである。

ここから見えるのは、フォーマットの選択が「流行り」ではなく その場面で何を最も重視するか で決まっている、ということだ。機械同士の軽快なやり取りなら JSON。人が編集する設定なら YAML。厳密な検証が要る機器設定なら XML。このように、それぞれの重心が活躍場面とぴたりと対応している。

トレードオフと使い分けの判断基準

結局のところ、3形式の違いは「あちらを立てればこちらが立たない」というトレードオフ（何かを取ると別の何かを諦める関係）に集約される。軸は3つだ。すなわち「人間にとって読みやすいか」「機械が処理しやすいか」「構造を厳密にチェックできるか」である。下の表で全体像を一望しておく。

迷ったときの判断基準は、次の問いに落とすと選びやすい。

• 誰が主に読み書きするか。 機械が往復させるなら JSON、人が手で編集し続けるなら YAML。
• 間違いをどこまで機械で防ぎたいか。 スキーマで厳密に検証したい設定領域なら XML（＋スキーマ／モデル）。
• 既存のプロトコルやツールが何を要求するか。 これが実は最も強い制約で、REST なら JSON、NETCONF なら XML、Ansible なら YAML と、相手が決まっていれば自由に選ぶ余地は小さい。

よくある誤解

初心者がやりがちな誤解に、「YAML は JSON より新しくて優れた上位互換だから、いずれ JSON を置き換える」という思い込みがある。これは正しくない。

YAML は人の編集しやすさに寄せた形式だ。だが、空白で構造が決まるぶんインデントのずれに弱い。機械同士で大量のデータを高速にやり取りする場面では、JSON のほうが素直で扱いやすい。実際、YAML は JSON をほぼ包み込む関係にある（多くの JSON は、そのまま YAML としても有効に読める）。しかしこれは「新旧」や「優劣」ではなく、あくまで 重心の違い である。どちらかが他方を追い出すのではなく、用途によって使い分けられている——これが正しい捉え方だ。

本ページはCisco DevNet Associate(200-901) Exam Topics v1.1を学習範囲の根拠として参照。文章・図表はすべて新規作成。