JSON は、文字や数値、配列、オブジェクトを使ってデータを表す軽量な記法です。Web API や設定ファイルで広く使われ、文字列中心のシンプルな構造なので、人間が目で追いやすく、プログラムでも扱いやすいのが特徴です。記号の並びは簡単に見えても、型の決まりや文字列の書き方には厳密さがあり、そこを理解すると読み書きのミスを減らせます。
値の並べ方と 6 つの型
JSON で表せる値は大きく 6 種類です。オブジェクト、配列、文字列、数値、真偽値、null だけで、関数や日付のような専用の型はありません。まずはこの「使える部品」が少ないことを押さえると、JSON がなぜ軽いのかが分かります。
| 型 | 書き方の例 | 意味 |
|---|---|---|
| オブジェクト | `{ “name”: “A” }` | 名前付きの値の集まり |
| 配列 | `[1, 2, 3]` | 順番を持つ値の並び |
| 文字列 | `”abc”` | 文字の並び |
| 数値 | `12.5` | 整数・小数 |
| 真偽値 | `true` / `false` | 真・偽 |
| null | `null` | 値がないこと |
オブジェクトは「キー」と「値」の組で表します。キーは必ず文字列で、`”speed”: 120` のように書きます。配列は同じ種類の値を並べるのに向き、`[“A”, “B”, “C”]` のように順序を保ちます。実務では、設定が 1 件ならオブジェクト、複数件の一覧なら配列、という考え方がよく使われます。
オブジェクトのキー名と階層
JSON の読みやすさは、キー名の付け方で大きく変わります。短すぎて意味が曖昧な名前より、`user_id` や `created_at` のように役割が分かる名前の方が保守しやすくなります。また、オブジェクトの中にさらにオブジェクトを入れることで、関連する値を階層的にまとめられます。
{
"machine": {
"name": "press-01",
"status": "running",
"sensors": {
"pressure": 12.3,
"temperature": 45.1
}
}
}このような入れ子構造は、設備情報、受注データ、ユーザー情報のように、まとまりがはっきりしたデータに向いています。一方で、深くしすぎると人間が追いにくくなり、どこに何があるのか把握しづらくなります。階層は便利ですが、必要以上に深くしないことが大切です。
文字列の引用符とエスケープ
JSON の文字列は必ずダブルクォート `”` で囲みます。シングルクォート `’` は使えません。また、文字列の中にダブルクォートや改行などを入れたい場合は、エスケープと呼ばれる書き方を使います。
代表的な例は次のとおりです。
- `\”` : ダブルクォート
- `\\` : バックスラッシュ
- `\n` : 改行
- `\t` : タブ
たとえば `”He said \”OK\””` のように書きます。ここを間違えると、見た目は似ていても JSON としては無効になります。特に、手で編集する設定ファイルでは引用符の閉じ忘れがよく起こるため、エディタの整形機能や JSON バリデータを使うと安全です。
数値・真偽値・null の扱い
JSON の数値は、見た目としては単純ですが、他の言語に渡したときの型変換で注意が必要です。たとえば、整数に見える値でも受け手側で浮動小数点として扱われることがあります。真偽値は `true` と `false`、null は「値が存在しない」ことを表し、空文字 `””` や 0 とは意味が違います。
実務では、次の違いを意識すると混乱を減らせます。
- `null` は未設定・不明・欠損を表す
- `”0″` は文字列の 0 であり数値ではない
- `false` は偽であり、`null` とは別物
API の応答では、項目がない場合に `null` を返すのか、項目自体を省略するのかが設計上のポイントになります。どちらを採るかで、受け手側の実装や判定条件が変わるため、仕様をそろえておく必要があります。
Python の dict との対応
JSON はプログラミング言語のデータ構造と相性がよく、Python では `dict` と `list` に近い形で扱えます。JSON を読み込むとオブジェクトは辞書、配列はリストとして使えるので、データ変換の入口として非常に便利です。
import json
text = '{"name": "A", "values": [1, 2, 3]}'
data = json.loads(text)
print(data["name"])
print(data["values"][0])
out = json.dumps(data, ensure_ascii=False)
print(out)この例の `loads` は文字列をデータに変換し、`dumps` はデータを文字列に戻します。`ensure_ascii=False` を付けると、日本語を `\uXXXX` にせずそのまま出力できます。インタプリタ言語では、このように短いコードで JSON を確認できるため、API の受信確認や設定値の検証に向いています。
API・設定・ファイル形式としての使い分け
JSON は、機械同士のデータ交換で特によく使われます。REST API のリクエストやレスポンス、Web アプリの設定、ログの一部、ツール間の受け渡しなどが代表例です。人が直接編集することもありますが、YAML のようにコメントを書けないため、説明が必要な設定では別途ドキュメントを用意することがあります。
DXF のような CAD 系ファイルは、構造や表現対象がまったく異なります。JSON は汎用的なデータ表現であり、図形そのものを表すのが主目的ではありません。逆に、API では JSON が標準的な選択肢になりやすく、送受信の共通言語として扱いやすいのが強みです。
つまずきやすい書式の違い
JSON でよくある混乱は、他の記法と混同することです。オブジェクトの末尾にカンマを付ける、キーをダブルクォートで囲まない、コメントを書き込む、といった書き方は JSON では認められません。見た目が似ていても、厳密には別の文法です。
| 項目 | JSON | JavaScript のオブジェクトリテラル | YAML |
|---|---|---|---|
| キーの引用 | 必須 | 省略可の場合あり | 省略可 |
| 末尾カンマ | 不可 | 可能な場合あり | 文脈による |
| コメント | 不可 | 可能 | 可能 |
| 主な用途 | データ交換 | プログラム内の記法 | 設定ファイル |
JSON は「厳密で単純」という性質があるため、機械処理には向いていますが、自由度が高い分だけ人が書くときのミスも起こりやすくなります。だからこそ、保存前の整形、スキーマ検証、テストデータでの確認が重要です。形式を正しく守れば、言語や環境をまたいでも扱いやすい、非常に実用的な表現になります。
