JSON — 知星図

概要

JSON（JavaScript Object Notation）は、構造を持つデータをテキストで表現するためのフォーマットです。{"name": "Sato", "age": 28, "tags": ["dev", "tokyo"]} のように、キーと値の組（オブジェクト）と値の並び（配列）を入れ子にしてデータを組み立てます。名前のとおり JavaScript のオブジェクト記法に由来しますが、フォーマット自体は言語から独立しており、主要なプログラミング言語のほぼすべてが読み書きできます。

今日のシステム間のデータ交換は、大部分がJSONで行われています。Web API のリクエストとレスポンス、アプリケーションの設定ファイル（package.json など）、構造化されたログ、NoSQL データベースのドキュメント——「システムの境界をデータが越える場面」には、たいていJSONがいます。

なぜ生まれたか

2000年代初頭、システム間のデータ交換の標準は XML でした。しかし XML はタグの開閉で冗長になりがちで、スキーマや名前空間などの周辺仕様も複雑、パースの処理も重い。特にブラウザ上のJavaScriptからサーバとデータをやり取りする用途では、明らかに大げさでした。

ダグラス・クロックフォードは、JavaScriptにもともと備わっているオブジェクトリテラル記法の一部をそのまま切り出せば、軽量なデータ形式として十分使えることに着目し、2000年代前半にJSONとして仕様化しました。「新しく発明したのではなく、発見した」と彼が語るとおり、仕様書はわずか数ページです。Ajax の流行でブラウザとサーバの非同期通信が爆発的に増えると、パースが軽く人間にも読めるJSONは急速にXMLを置き換え、REST API の事実上の標準フォーマットになりました。

詳細

割り切った仕様——6つのデータ型しかない

JSONが表現できるのは、文字列・数値・真偽値（true/false）・null・配列・オブジェクトの6種類だけです。日付型もコメントも変数もありません。この徹底した割り切りが、あらゆる言語での実装を容易にし、「どの環境でも同じように解釈できる」という最大の価値を生みました。表現力の乏しさは弱点ではなく、相互運用性のための意図的な設計です。

文法上の注意点はいくつかあります。キーは必ずダブルクォートで囲む（{name: "x"} はJavaScriptとしては有効でもJSONとしては不正）、末尾カンマは許されない、コメントが書けない——JavaScriptのオブジェクトリテラルより厳格である点が、初心者がつまずきやすいところです。

シリアライズとデシリアライズ

プログラム内のオブジェクトはメモリ上の構造であり、そのままネットワークに流したりファイルに保存したりはできません。オブジェクトをJSON文字列に変換することをシリアライズ（直列化）、その逆をデシリアライズと呼びます。JavaScriptなら JSON.stringify / JSON.parse、Pythonなら json.dumps / json.loads が対応します。

この変換は行きと帰りの両方で起こります。

HTTP でJSONを送るときは、ヘッダに Content-Type: application/json を付けて「このボディはJSONです」と宣言します。異なる言語で書かれたシステム同士でも、この往復さえ成立すればデータを共有できる——JSONが「APIの共通語」と呼ばれる理由です。

型が消える、という宿命

JSONの割り切りには代償もあります。もっとも典型的なのが日付で、JSONに日付型はないため "2026-07-17T09:00:00Z" のような文字列（ISO 8601形式が慣例）として送り、受け取った側が日付として解釈し直す必要があります。数値の精度も落とし穴で、JavaScriptの数値は64bit浮動小数点のため、巨大な整数（IDなど）は末尾の桁が化けることがあり、あえて文字列で送るAPIも珍しくありません。「JSONを介すると型情報が一段落ちる」ことを前提に、境界でのバリデーション（スキーマ検証）を設けるのが実務の定石です。

スキーマと周辺エコシステム

JSON自体には「このデータはこの構造であるべき」という取り決めがありませんが、それを補う仕組みとして JSON Schema があり、APIの仕様記述（OpenAPI）やエディタの設定ファイル補完に使われています。また、コメントや末尾カンマを許した JSONC（VS Codeの設定など）、1行1JSONでログに適した JSON Lines、人間が書く設定用の YAML（JSONのスーパーセット）など、用途に応じた派生・隣接フォーマットも押さえておくと役立ちます。

実務での使いどころと注意点

APIレスポンスの設計では、「一貫したキーの命名（camelCase か snake_case か）」「エラー時も同じ構造で返す」といった規約を揃えることが、クライアント実装のしやすさに直結します。セキュリティ面では、受け取ったJSONを検証せずに信用しない、eval でパースしない（必ず JSON.parse を使う）、といった基本を守ること。また巨大なJSONを丸ごとメモリに載せるとパースが重くなるため、大量データではストリーミングパースやページネーションを検討します。シンプルなフォーマットだからこそ、運用の規律が品質を分けます。