なぜJSONがXMLに取って代わったか

結論 — 勝ったのは「摩擦の少なさ」

JSONがXMLに取って代わった一言の理由は、Web API という現場で開発者が触れる摩擦が圧倒的に少なかったことです。JSONは新しく発明された形式ではなく、Douglas Crockford が2001年ごろ、既に存在した JavaScript のオブジェクト表記（オブジェクトリテラル）を「データ交換にそのまま使える」と見出し、名前を与えて公開したものです。ブラウザがネイティブに解釈でき、専用パーサもスキーマ定義もなしにテキストがそのままデータ構造になる——この即物的な軽さが、XML/SOAP の重厚な仕様体系に対して決定的に効きました。

当時の状況と競合 — XML/SOAPの重厚さ

2000年前後、システム間連携の本命は XML でした。XML 1.0 は W3C 勧告（1998年）で、あらゆる構造を厳密に表現でき、名前空間・スキーマ（XSD）・変換（XSLT）・問い合わせ（XPath/XQuery）と周辺仕様が充実していました。この上に築かれた RPC 規約が SOAP です。SOAP はもともと Microsoft 陣営（Dave Winer や Don Box らが関与）で1998年ごろに生まれ、W3C で SOAP 1.2 が勧告（2003年）となり、WSDL（インターフェース記述）や WS-* 系仕様群とともに「エンタープライズ Web サービス」の標準として推進されました。

問題は、この体系が Web ブラウザという実行環境と噛み合わなかった点です。SOAP は一件の呼び出しに必ず Envelope（封筒）と名前空間を要求し、型情報やヘッダで包みます。ブラウザ側では XML を DOM としてパースし、必要な値を XPath や手作業のツリー走査で取り出す必要がありました。同じデータを表すのに、XML/SOAP と JSON では手数がまるで違います。

同じ内容を並べると差は一目瞭然です。

<?xml version="1.0"?>
<user>
  <id>42</id>
  <name>Aki</name>
  <admin>true</admin>
</user>

{ "id": 42, "name": "Aki", "admin": true }

XMLでは要素名を開始・終了タグで二度書き、属性かテキストかの設計判断も付きまといます。JSONは数値・真偽値・文字列・配列・オブジェクトという最小の型だけを持ち、{"id":42} がそのままメモリ上のオブジェクトになります。

決定打・経緯 — RESTとAjaxが流れを変えた

横にスクロール

勝敗を分けたのは、2000年代半ばに重なった2つの潮流です。ひとつは Roy Fielding が博士論文（2000年）で定式化した REST で、独自の RPC 封筒を被せず、HTTP のメソッドと URL をそのまま資源操作の語彙として使う考え方です。SOAP が HTTP を「単なる運搬路」として上位に独自プロトコルを積んだのに対し、REST は HTTP の設計自体に乗ることで付随仕様を不要にしました。

もうひとつが Ajax です。ブラウザから非同期通信する XMLHttpRequest はもともと Microsoft が Outlook Web Access 向けに IE5（1999年）で実装した部品で、Jesse James Garrett が2005年に「Ajax」と名付けて設計手法として広めました。名前に XML を含みますが、実際にサーバーから受け取って扱うのに最も相性が良かったのは JSON でした。理由は単純で、返ってきたテキストをブラウザがそのままオブジェクトに変換できたからです。

こうして「HTTP でリソースを表現し、ボディに JSON を返す」素直な Web API が、実装コストと学習コストの両面で優位に立ちました。SOAP は WSDL からのコード生成ツールがある環境では強力でしたが、ツールに乏しいスクリプト言語やブラウザからは扱いにくく、公開 Web API の主役が JSON/REST へ移っていきました。GitHub や多くの SaaS が JSON API を既定とし、XML はオプション扱いへ後退します。

今への影響と教訓 — 適材適所

現在、公開 Web API・モバイル・SPA のデータ交換はほぼ JSON が既定です。JSONの上には JSON Schema（緩やかな検証）、JSON-LD（意味付け）、そして GraphQL のように別アプローチで REST を補う設計も育ちました。一方で XML は消えていません。長所である構造の豊かさが要る領域では今も最適です。

• 文書とデータが混在する用途（HTMLに近い文書、DOCX/XLSX などのオフィス文書内部、SVG）
• 厳密なスキーマ検証・電子署名・名前空間が要る契約的なデータ交換（一部の金融・行政・EDI）
• 設定・ビルド記述（一部のエコシステム。ただし近年は YAML/TOML/JSON も併存）

REST/HTTPとしての資源設計はWeb、データ形式のパースや直列化の内部動作はプログラミング、API通信の下回りとなるHTTPの仕組みはネットワークを参照してください。

一段で言うと

JSONは技術的にXMLを打ち負かしたというより、Web API という現場で開発者がぶつかる摩擦を最小化して勝ちました。ブラウザが即座にデータ化でき、余計な封筒も仕様も要らない——その素直さがRESTとAjaxの波に乗った。XMLは負けて消えたのではなく、混在文書や厳密検証という自分の得意分野に収まっただけです。標準を決めるのは仕様の格ではなく、日々それを書く人の摩擦の少なさ。これがこの交代劇の核心です。