JSON とは？初心者向け完全ガイド

モダンなウェブを支えるデータ形式 JSON について、構文から API での利用まで幅広く解説します。

JSONTech チーム2025年1月15日8 分

JSONを30秒で理解する

JSON（JavaScript Object Notation）は、軽量でテキストベースのデータフォーマットであり、ウェブ上のデータ交換の共通語となっています。REST APIを呼び出したり、package.jsonファイルを開いたり、MongoDBで作業したことがあるなら、JSONをすでに使用していることになります — おそらくあまり考えずに。

JSONの本質は、構造化データをプレーンテキストとして表現する方法です。人間が読める（主に）、機械が解析しやすい（非常に簡単）、そして実質的にすべてのプログラミング言語でサポートされています。この組み合わせが、JSONが勝利した理由です。

簡単な歴史

JSONは、2000年代初頭にダグラス・クロックフォードによって普及しました。彼はそれを「発明」したわけではありません — 構文は1999年から存在していたJavaScriptのサブセットですが、彼はそれに名前を付け、ウェブサイト（json.org）と仕様を提供しました。時には、ブランドが発明よりも重要です。

このフォーマットは、RFC 4627（2006年）で正式に規定され、その後RFC 8259（2017年）およびECMA-404標準に取って代わられました。しかし正直なところ、仕様は初めからあまり変わっていません。JSONのシンプルさが最大の強みです — 変更することがあまりないのです。

JSONが主流になる前は、XMLが支配的なデータ交換フォーマットでした。開発者がJSONに集まった理由を知りたいなら、私たちのJSONとXMLの比較をチェックしてください。

6つのJSONデータ型

JSONは正確に6つのデータ型をサポートしています。それ以上でもそれ以下でもありません。この制約は意図的であり、シンプルさと異なる言語間での相互運用性を保ちます。

型	説明	例
文字列	ダブルクォートで囲まれたテキスト	`"hello world"`
数値	整数または浮動小数点（16進数、NaN、Infinityは不可）	`42`, `3.14`, `-7`
ブール値	リテラル `true` または `false`	`true`
ヌル	空または不明な値を表す	`null`
オブジェクト	キーと値のペアの無秩序なコレクション	`{"name": "Ada"}`
配列	値の順序付きリスト	`[1, 2, 3]`

リストにないものに注意してください：日付、関数、未定義、コメント、またはバイナリデータ。JSONはそれらをネイティブにサポートしていません。日付は通常、ISO 8601文字列（"2025-01-15T10:30:00Z"）として渡され、バイナリデータはBase64エンコードされます。少し面倒ですが、フォーマットを普遍的に保つためです。

JSON構文ルール

JSONの構文は厳格です。JavaScriptから来た場合、これらのルールのいくつかにつまずくかもしれません。ここにそれらがあります、甘やかしはありません：

キーはダブルクォートで囲まれた文字列でなければなりません。 シングルクォートは機能しません。引用されていないキーは機能しません。これはJavaScriptではありません。
文字列はダブルクォートを使用しなければなりません。 'hello' は無効なJSONです。"hello" は有効です。
末尾のカンマは不可。 最後のプロパティの後のカンマ？JSONはノーと言います。
コメントは不可。 これはおそらくJSONの最も物議を醸す設計決定です。ダグラス・クロックフォードは、乱用を防ぐために意図的にコメントを削除しました。
単一値のルートは不可（古い仕様では）。 RFC 8259は現在、任意のJSON値をルートとして許可していますが、多くのパーサーはまだオブジェクトまたは配列を期待しています。

こちらが有効なJSONドキュメントです：

{
  "name": "Grace Hopper",
  "age": 85,
  "languages": ["COBOL", "FORTRAN"],
  "retired": true,
  "spouse": null,
  "address": {
    "city": "Arlington",
    "state": "VA"
  }
}

そして、こちらがそれを壊すものです：

{
  name: "Grace Hopper",     // ❌ 引用されていないキー
  'age': 85,                // ❌ シングルクォートのキー
  "languages": ["COBOL",],  // ❌ 末尾のカンマ
  // これはコメントです      // ❌ コメントは許可されていません
}

無効なJSONがありますか？ 私たちのJSONフォーマッターに貼り付けて、構文エラーを瞬時に見つけ、末尾のカンマのような一般的な問題を自動修正してください。

JSONとJavaScriptオブジェクトの違い

これはほとんどすべてのJavaScript開発者がある時点でつまずくことです。JSONはJSオブジェクトリテラルのように見えますが、同じものではありません。ここでそれらは分岐します：

特徴	JSON	JavaScriptオブジェクト
キー	ダブルクォートで囲まれた文字列でなければならない	引用されていない識別子、シンボル、または計算されたものが可能
文字列	ダブルクォートのみ	シングルクォート、ダブルクォート、またはバックティック
末尾のカンマ	許可されていない	許可されている
コメント	許可されていない	許可されている
値	文字列、数値、ブール値、ヌル、オブジェクト、配列	上記すべてに加えて関数、未定義、Date、RegExpなど
メソッド	サポートされていない	サポートされている
使用法	データ交換フォーマット（テキスト）	メモリ内データ構造

実際には、JSON.parse()とJSON.stringify()を使用して相互変換します：

// 文字列 → オブジェクト
const data = JSON.parse('{"name": "Ada", "year": 1843}');
console.log(data.name); // "Ada"

// オブジェクト → 文字列
const json = JSON.stringify({ name: "Ada", year: 1843 });
console.log(json); // '{"name":"Ada","year":1843}'

// 2スペースのインデントで整形
const pretty = JSON.stringify(data, null, 2);

一般的な使用例

1. REST API

これはJSONの主力です。現代のウェブAPIの大多数はJSONを送受信します。サーバーからデータをfetch()すると、ほぼ確実にJSONが返ってきます：

const response = await fetch("https://api.example.com/users/1");
const user = await response.json();
// { "id": 1, "name": "Alice", "email": "alice@example.com" }

2. 設定ファイル

package.json、tsconfig.json、.eslintrc.json、composer.json — リストは続きます。JSONは開発者ツールの至る所にあります。コメントがないのは本当に痛いところで、だからこそ一部のツールはJSON5やJSONC（コメント付きJSON）を代替としてサポートしています。

3. NoSQLデータベース

MongoDBはドキュメントをBSON（バイナリJSON）として保存します。CouchDBはプレーンJSONを使用します。DynamoDB、Firestore、その他数えきれないほどのものがJSONに似た構造を使用しています。ドキュメントデータベースで作業しているなら、JSONを扱っていることになります。

4. ローカルストレージと状態管理

ブラウザのlocalStorageは文字列のみを保存するため、状態をJSONにシリアライズするのが標準的なアプローチです：

// 保存
localStorage.setItem("prefs", JSON.stringify({ theme: "dark", lang: "en" }));

// 読み込み
const prefs = JSON.parse(localStorage.getItem("prefs") ?? "{}");

5. マイクロサービス間のデータ交換

メッセージキュー（RabbitMQ、Kafka）、ウェブフック、サービス間通信はすべてJSONに大きく依存しています。高スループットのシナリオでは最も効率的な選択ではないこともあります（ProtobufやMessagePackの方が速い）が、最もデバッグしやすいです。

JSONのベストプラクティス

JSONを日常的に扱ってきた年数を経て、私が推奨する習慣は以下の通りです：

一貫した命名規則を使用する。 キーにcamelCaseまたはsnake_caseを選び、API全体でそれを守ります。混在させるのはバグの早道です。
早期に検証する。 受信したJSONを盲目的に信頼しないでください。ビジネスロジックに到達する前に、JSONスキーマ検証を使用して不正なデータをキャッチします。
ネストを浅く保つ。 JSONが3〜4レベル以上深い場合は、フラット化を検討してください。深くネストされた構造はクエリが難しく、読みづらく、差分を取るのも難しいです。
リストには配列を、レコードにはオブジェクトを使用する。 明白に聞こえますが、数値の文字列キーを持つオブジェクト（{"0": "a", "1": "b"}）を配列の代わりに使用する人を見たことがあります。それは避けてください。
値がない場合は欠落したキーよりもnullを好む。 それはスキーマを明示的にし、フィールドが意図的に省略されたかどうかの曖昧さを避けます。
開発中は人間向けにフォーマットする。 ミニファイドJSONはバイトを節約しますが、可読性を損ないます。デバッグ時には整形を使用し、出荷時にはミニファイします。私たちのJSONミニファイアが後者を処理します。

自分で試してみてください： どんなJSONでも私たちのJSONフォーマッターに貼り付けて、瞬時に検証、フォーマット、構造を探索し、構文ハイライトとツリービューで確認してください。

JSON5とJSONCについては？

JSONの厳格さが気になる場合、あなたは一人ではありません。2つの人気のある拡張機能がルールを緩和します：

JSON5は、シングルクォートの文字列、末尾のカンマ、コメント、引用されていないキーなどを許可します。人間が主な対象である設定ファイルに最適です。
JSONC（コメント付きJSON）は、VS CodeやTypeScriptの設定で使用される最小限の拡張です。コメントサポートのみを追加します — 他には何もありません。

ただし、これらのいずれも有効なJSONではありません。APIを構築したり、システム間でデータを交換したりする場合は、標準のJSONを使用してください。ツールが明示的にサポートしている場合のみ拡張を使用してください。

まとめ

JSONが成功したのは、完璧だからではなく、ほぼすべてに対して十分良く、扱いやすいからです。その限られた型システムは時折フラストレーションを引き起こします（私の日時はどこ？）、そしてコメントなしのルールは本当に痛点です。しかし、それらの制約が普遍的な相互運用性をもたらすのです。

もしあなたが始めたばかりなら、JSONを学ぶ最良の方法は、実際に手を動かして扱うことです。データを私たちのツールに貼り付けて、意図的に壊してみて、何が起こるかを見てください。エラーメッセージを理解することが半分の戦いです。

さらに探求してください：

JSONとYAMLの比較 — それぞれのフォーマットを使用するタイミング
JSONとXMLの比較 — なぜJSONがほとんどの使用例でXMLに取って代わったのか
JSONバリデーター — JSONが有効かどうかを確認
JSONスキーマジェネレーター — JSONデータからスキーマを自動生成