JSON vs YAML: データ交換の主役はなぜJSONになったのか？

「人が読むにはYAMLの方がずっと分かりやすいのに、なぜAPI通信ではJSONばかりが使われるのだろう？」 「YAMLにはどのような強みがあり、JSONはなぜ標準となったのだろうか？」

JSON vs YAML 中世の戦い

1. データフォーマット戦争の幕開け

かつて開発者たちは、システム間でデータをやり取りするための「共通の規格」を必要としていました。初期の頃は、XMLがその座を占めていました。

<person>
    <name>Alice</name>
    <age>25</age>
    <skills>
        <skill>Python</skill>
        <skill>Django</skill>
    </skills>
</person>

しかし、XMLはタグをいちいち閉じる必要があり、冗長で重すぎました。読むのも大変でした。そこで登場したのが、JSONとYAMLという代替案です。

2. JSON: Webデータ交換の標準へ

2001年、ダグラス・クロックフォードがJavaScriptのオブジェクト表現から着想を得て作成したのがJSONです。「最大限に軽量で、機械が読みやすいこと」がその核でした。

JSONの成功の秘訣は明確でした。 * 圧倒的な軽量さ: 不要な装飾がなく、データのみを伝達します。 * Webとの相性抜群: ブラウザ (JavaScript) で、特別なライブラリなしに直接オブジェクトへ変換できました。 * 直感的なマッピング: PythonのDict、JSのObjectなど、現代のプログラミング言語のデータ構造とほぼ一致します。

特にREST APIがWebの主流となるにつれて、JSONは事実上、世界共通言語となりました。

3. YAML: 人が読むために生まれたフォーマット

JSONよりも「人が読む楽しさ」に重きを置いた陣営もありました。「中括弧や引用符なしで、もっとすっきりと書けないだろうか？」という悩みから誕生したのがYAMLです。

name: Alice
age: 25
skills:
  - Python
  - Django

YAMLの特徴ははっきりしています。 * 究極の可読性: インデント (Indentation) ベースであるため、テキストが非常にきれいです。 * コメント (#) のサポート: JSONにはない「説明」を記述できるのが大きな利点です。 * 設定ファイルの王者: この可読性のおかげで、Kubernetes、Docker、GitHub Actionsなど、インフラ設定フォーマットを完全に掌握しました。

では、なぜデータ交換 (API) においてはJSONを超えることができなかったのでしょうか？

4. YAMLがデータ交換で劣勢になった現実的な理由

第一に、インデントの厳格さ (Space vs Tab) JSONは括弧が構造を定義しますが、YAMLは目に見えない空白一つが構造を決定します。複雑なデータをやり取りする際、空白が一つでも間違っていればデバッグ地獄に陥ります。

第二に、パース速度とリソース JSONは文法が単純なため、パーサーは非常に軽量で高速です。一方、YAMLは文法が非常に広範で複雑なため (コード実行機能まで含む)、これを解釈するのにより多くのメモリとCPUを消費します。大量のデータをやり取りするAPI環境では致命的です。

第三に、セキュリティ問題 YAMLは単なるデータを超えて、特定の言語のオブジェクトを直接呼び出す機能を含むことがあります。これは、リモートコード実行 (RCE) のようなセキュリティ脆弱性につながる危険性があり、不特定多数とデータをやり取りするAPI用途には不適切です。

5. 結局は「適材適所」の問題

JSONがデータ交換の王であるならば、YAMLは設定ファイルの王として、それぞれの領域を確固たるものにしました。

  • JSONを使うべき時: Web API通信、NoSQLデータベースへの保存、クライアントとのデータ転送時。
  • YAMLを使うべき時: プロジェクト設定ファイル (docker-compose.yml)、CI/CDスクリプト、人が直接管理すべきドキュメント。

Django Rest Framework(DRF)でもYAMLRendererを追加することは可能ですが、デフォルトは常にJSONRendererです。データは正確かつ迅速であるべきだからです。

結論: 一言でまとめると

「機械同士の会話 (API) はJSONに、人と機械の会話 (設定) はYAMLに。」

合わせて読みたい記事 :