JSON (JavaScript Object Notation) は、キーと値のペアでデータを表現する軽量なテキストベースのデータ交換フォーマットです。書式は 2001 年に Douglas Crockford がまとめたもので、規格として整理されたのはその後です。2006 年の RFC 4627 が最初の規格化で、2013 年に ECMA-404 の第 1 版、2017 年に RFC 8259 と ECMA-404 の第 2 版が出ました。2026 年時点で参照すべきはこの RFC 8259 と ECMA-404 第 2 版の 2 つで、書き方は違っても定義している書式は同じです。JavaScript から派生した構文ですが、言語に依存しない汎用的な形式として Python、Java、Go、Ruby など事実上すべてのプログラミング言語でサポートされています。

JSON が扱えるデータ型は、文字列 (ダブルクォートで囲む)、数値 (整数・浮動小数点)、真偽値 (true/false)、null、配列 (角括弧)、オブジェクト (波括弧) の 6 種類です。この単純さが JSON の最大の強みであり、REST API のレスポンス形式として事実上の標準となった理由でもあります。

XML との比較では、JSON はタグの開始・終了が不要なため記述量が少なく、パースも高速です。同じデータでも、キー名を開始タグと終了タグに 2 回書く XML より短くなります。ただし削減率はキー名の長さ、入れ子の深さ、属性を使うかどうかで大きく変わるため、決まった比率として覚えられるものではありません。サイズを判断材料にするなら、実際のデータを両方の形式で書き出し、gzip をかけた後のバイト数で比べてください。同じ構造が繰り返されるデータでは gzip がタグ名の重複を吸収するので、圧縮後の差は圧縮前ほど大きくなりません。一方、XML はスキーマ定義 (XSD) や名前空間のサポートが充実しており、厳密なデータ検証が求められる場面では依然として選ばれます。YAML はバージョン 1.2 で JSON を厳密なスーパーセットとして取り込む方針が採られており、JSON のテキストはそのまま YAML として読み込めます。コメントやアンカー機能を持つため設定ファイルとして好まれますが、インデントに依存する構文はコピー&ペースト時にエラーを招きやすい欠点があります。なお包含関係は完全な等価ではなく、たとえば同じキーが重複した JSON は YAML の仕様上は不正です (エラーとして扱う実装もあれば、黙って片方の値だけを採る実装もあります)。

JSON にはいくつかの制約があります。コメントをサポートしていないため、設定ファイルとしては JSON5 や JSONC (JSON with Comments) が使われることがあります。日付型が存在しないため、日時データは ISO 8601 形式の文字列 (例: "2025-01-15T09:30:00Z") として表現するのが慣例です。日時の文字列は末尾の Z やオフセットを省くと、受け取る側が現地時間と解釈するか UTC と解釈するかで結果がずれるため、時差まで書き添えます。また、末尾のカンマ (trailing comma) が許容されないため、配列やオブジェクトの最後の要素の後にカンマを付けると構文エラーになります。

書式そのものは単純でも、仕様が細部を実装に委ねているため、実務でつまずくのはたいてい次の 2 点です。第一に数値の精度で、RFC 8259 は扱える桁数や範囲を規定せず、多くの実装が IEEE 754 の倍精度 (binary64) を前提にしています。同じ RFC が相互運用できる整数として挙げているのは 2 の 53 乗から 1 を引いた 9,007,199,254,740,991 まで (負の側も同じ絶対値まで) で、これを超える ID を数値として渡すと下位の桁が丸められ、別のレコードを指してしまいます。19 桁の ID や口座番号は、最初から文字列として受け渡すのが安全です。第二にキーの重複で、RFC 8259 はオブジェクト内の名前は一意であるべきだと書くにとどまり、重複自体を禁止していません。重複したときの動きは実装任せで、最後に現れた値だけを採るもの、エラーにするもの、すべてを返すものが混在します。検証をすり抜けさせる手口にも使われるため、生成側で重複を作らないことと、受け取り側でも重複を検出して弾くことの両方が必要です。

実務では JSON のバリデーションとスキーマ定義に JSON Schema が広く使われています。API のリクエスト・レスポンスの構造を JSON Schema で定義しておくと、クライアントとサーバー間のデータ契約が明確になり、不正なデータの混入を防げます。

セキュリティ面では、信頼できないソースからの JSON を eval() で解析することは絶対に避けるべきです。必ず JSON.parse() を使用し、不正なコードの実行を防止します。また、文字列の連結で JSON を組み立てていると、入力に含まれたダブルクォートや波括弧によってデータの構造そのものを書き換えられます。値の埋め込みは自前でエスケープするのではなく、各言語のシリアライザ (JavaScript なら JSON.stringify()) に任せるのが確実です。

文字数カウントの観点では、JSON のキー名、波括弧、角括弧、ダブルクォート、コロン、カンマなどの構文要素がデータサイズに影響します。文字コードについては、閉じた環境の外でやり取りする JSON は UTF-8 で符号化しなければならないと RFC 8259 が定めており、先頭に BOM を付けることも禁じています (受け取る側は BOM を無視してもよい、という扱いです)。バイト数の見積もりは UTF-8 を前提に計算すれば足ります。圧縮 (minify) により不要な空白やインデントを除去してサイズを削減でき、さらに gzip 圧縮を組み合わせると転送サイズを大幅に縮小できます。日本語を含むレスポンスでは、文字をそのまま書くか、バックスラッシュに u と 4 桁の 16 進数を続ける形式 (\u3042 など) にエスケープするかでもバイト数が変わります。UTF-8 なら日本語 1 文字は 3 バイトですが、エスケープすると 6 バイトになるため、ライブラリの設定で非 ASCII を機械的にエスケープしていると、日本語中心のレスポンスはおよそ 2 倍に膨らみます。API のレスポンスサイズを最適化する際には、不要なフィールドの除外やキー名の短縮も有効な手法です。