レッスン 15
今日のエコシステムにおける JSON
強み、限界、別形式がより適する場合。
JSON が支持を得たのは、シンプルでテキストベース、主流言語のオブジェクトモデルにきれいにマップできるからです。すべての問題に最適な選択ではありません — トレードオフを理解すると、形式を意図的に選べます。
JSON がよく合う場面
- JavaScript、モバイル、サーバークライアントを含む HTTP API
- 起動時にツールがパースする 設定（
tsconfig、CI マトリックス） - 各メッセージが自己完結レコードである イベントストリーム
- 全当事者に共有バイナリスキーマを配布できない 相互運用性
摩擦点
| 制限 | 実務上の影響 |
|---|---|
| コメントなし | フィールドは別途文書化するか、ローカルのみ JSONC |
| 日付や小数をネイティブ型として持たない | 合意フォーマットの文字列としてエンコード |
| バイナリより冗長 | Protobuf や MessagePack より帯域幅が大きい |
| スキーマは任意 | プロデューサーとコンシューマーの間でドリフト |
これらは JSON を失格にするものではなく — 追加の規律（スキーマ、テスト、ドキュメント）が必要な領域を定義します。
形式ランドスケープの近隣
- XML — ドキュメント中心とレガシーエンタープライズで依然強い
- YAML — 人間が書く設定。信頼できない入力ではインデントとセキュリティに注意
- CSV/TSV — フラットな表形式データ、ネストしたグラフではない
- Protobuf / Avro — 信頼ネットワーク内のコンパクトバイナリと厳格スキーマ
チームはエッジ（公開 API）で JSON、内部でバイナリ形式を使うことが多いです。
JSON を意図的に採用する
UTF-8 を標準化し、可能ならスキーマや OpenAPI を公開し、破壊的変更は明示的にバージョン管理しましょう。JSON の普及は技術的なものと同じくらい社会的な慣習です — このコースの知識が、形式を魔法のように扱わずその慣習に参加する助けになります。