JSONをフォーマット

JSON—JavaScript Object Notation—は、構造化データ交換のためのユビキタスなテキストベースのフォーマットです。IETFによってRFC 8259として、またEcma InternationalによってECMA-404として標準化されており、これらが一体となって、現代のAPI、ログ、設定、データベースを支えるコンパクトで言語に依存しない構文を定義しています。

構文とエンコーディング：システム間の対話を維持する正確なビット

JSONの値は、オブジェクト、配列、文字列、数値、あるいはリテラルのtrue、 false、nullのいずれかです。オブジェクトは文字列を値にマッピングし、配列は順序付けられた値を保持します。構造文字の周りには重要でない空白が許容されます（RFC 8259、ECMA-404）。JSONはJavaScriptから生まれましたが、言語に依存せず、事実上どこでもサポートされています（MDN: JSON）。通信回線上では、事実上の標準であり推奨されるエンコーディングはUTF-8です（RFC 8259 §8.1）。相互運用性の安全性を高めるために、I-JSONプロファイル（RFC 7493）は、エンコーディングと数値範囲に関する規則を厳格化しています。

JavaScriptでは、グローバルなJSONオブジェクトが2つの主力機能を提供します：JSON.parse（オプションのreviver付き）とJSON.stringify（整形出力用のreplacer/spacing付き）で、MDNに記載されています（parse、stringify）。

数値：見かけは単純、驚くほど鋭い

JSONの数値文法は10進数ですが、仕様では精度や整数/浮動小数点数の区別は規定されていません。実装がそれらをどのように表現するかを選択します（RFC 8259 §6）。JavaScriptとNode.jsでは、NumberはIEEE-754倍精度であり、[−(2^53−1), 2^53−1]の範囲の整数のみが正確に安全です。Number.MAX_SAFE_INTEGERとBigInt型を参照してください。これが、公開APIがIDを文字列として送信し、「安全な整数」を明示的に検証することが多い理由です。

バニラJSONを超えて：ポインタ、パッチ、マージパッチ

利用が成熟するにつれて、JSONをその場でアドレス指定し、変更するための標準が登場しました。JSONポインタ（RFC 6901）は、値を特定するための小さなスラッシュ区切りの構文で（例：/a/b/0）、~と/のエスケープ規則があります。JSONパッチ（RFC 6902）は、部分的な更新を順序付けられた操作（add、remove、replace、move、copy、test）としてモデル化し、application/json-patch+jsonとして転送されます。より単純な差分については、JSONマージパッチ（RFC 7386）は、ドキュメント形式のマージを使用します。存在するフィールドは追加/置換され、フィールドをnullに設定すると削除されます。多くのフレームワークが、これらの形式の一方または両方を標準でサポートしています。

スキーマと型：検証と生成

JSON自体はスキーマレスですが、エコシステムは検証、ドキュメンテーション、コード生成のためにスキーマに依存しています。JSONスキーマ2020-12ファミリーは、type、properties、itemsなどの制約と合成キーワードを指定し、OpenAPI 3.1と整合しています。コード生成中心のワークフロー向けには、JSON Type Definition（RFC 8927）が、主流の型システムに予測可能にマッピングされる、意図的に表現力の低い言語を提供します。

ストリーミングとビッグデータ：JSON Linesとシーケンス

古典的なJSONはペイロードごとに1つの完全なテキストを期待しますが、これはストリーミングログや長寿命のレスポンスを複雑にします。2つのパターンが役立ちます：

• JSONテキストシーケンス（RFC 7464）：UTF-8 JSONテキストのストリームで、それぞれがレコードセパレータ（U+001E）で始まり、LFで終わります。application/json-seqとして登録されています。
• NDJSON / JSON Lines：各行が独立したJSON値であり、追跡、gzip圧縮、マップリデュースが容易です（ndjson.org、jsonlines.org）。ElasticsearchのBulk APIなど、一括APIで人気があります。

バイナリのいとこ：テキストが十分にコンパクトでない場合

帯域幅や速度が重要な場合、「バイナリJSON」形式はJSONのデータモデルを維持しつつ、人間が読めることと効率をトレードオフします：

• BSON（MongoDBのネイティブ形式）は、バイナリ、日時、型付き整数などの型を追加します（bsonspec.org）。
• MessagePackはコンパクトでスキーマフリーであり、多くの言語で広く実装されています（msgpack.org）。
• CBORは、拡張可能でコンパクトな形式（JSONトランスコーディングガイダンス付き）を標準化し、IoT/制約のあるコンテキストで一般的です（RFC 8949、cbor.io）。
• Smile（Jacksonエコシステムから）は、繰り返し使用される名前/値のオプションの逆参照を使用してJSONをエンコードします（jackson-dataformat-smile）。

セキュリティノート：古いトリックと現代の修正

JSONは単なるテキストであるため、ほとんどのリスクは転送方法と処理方法に起因します：

• JSONP（コールバック付きの<script>経由でデータを要求する）は、クロスオリジンリクエストのCORS以前の回避策でしたが、危険です。任意のスクリプトを実行します。実際のapplication/jsonレスポンスでCORSを優先してください（OWASP: JSONP Abuse）。
• JSONハイジャック：機密性の高い配列を返す単純なGETエンドポイントは、古いブラウザでクロスオリジンスクリプトタグを介して盗まれる可能性がありました。対策には、CSRF保護付きのPOSTや、非JSONセンチネルの接頭辞付けが含まれます（OWASP: JSON Hijacking）。
• JSONインジェクション：JSONをコードではなくデータとして扱います。入力を慎重にエスケープし、検証します（OWASP: JSON Injection）。

メディアタイプと遺産

JSONはRFC 4627 (2006)でデビューしました。登録されたメディアタイプはapplication/jsonで、その仕様は現在RFC 8259を指しています。公共のインターネットではUTF-8がデフォルトであるため、JSONレスポンスの「charset」パラメータは通常不要です。

本番環境で堅牢なJSONを運用するための実践的なヒント

• どこでもUTF-8をデフォルトにします。入力と出力でUTF-8を想定します（RFC 8259 §8.1）。
• 大きな整数は明示的に扱います：IDが2^53−1を超える可能性がある場合は、文字列として送信し、文書化します（MDN: MAX_SAFE_INTEGER）。
• ペイロードをJSONスキーマ2020-12（またはコード生成の多いスタックではJTD）で検証します。APIドキュメントの横にスキーマを公開します（OpenAPI 3.1）。
• 賢くパッチを適用します：操作レベルの差分にはJSONパッチを、単純なドキュメント形式の更新にはマージパッチを使用します。
• 大規模にストリーミングします：ログや長寿命のレスポンスにはJSONテキストシーケンスまたはNDJSONを選択し、メディアタイプを明示的にします。
• テキストがボトルネックの場合はバイナリ（BSON、MessagePack、CBOR、Smile）に頼りますが、両端が型について合意していることを確認してください。

「より親しみやすいJSON」について一言

開発者は、設定ファイルにコメント、末尾のカンマ、または単一引用符で囲まれた文字列を望むことがよくあります。これは標準のJSONの範囲外ですが、JSON5は、人間が編集するファイル向けの十分に文書化されたスーパーセットを提供します。両端を制御できない限り、公開API経由でJSON5を送信することは避けてください。

JSONの成功は、小さな表面積、幅広い言語サポート、そして分散システムの厄介な現実をカバーする隣接する標準（ポインタ、パッチ、スキーマ、シーケンス）の輪から来ています。基本（構文、エンコーディング、数値）を理解し、適切な隣接する標準に頼ることで、スタックやサービス全体で利益をもたらし続けます（RFC 8259、ECMA-404、RFC 6901、RFC 6902,RFC 7386,JSON Schema,JTD,RFC 7464,NDJSON）。