JSON

JSONとは

JSON(JavaScript Object Notation)は、データを交換するためのテキスト形式です。[[JavaScript]] のオブジェクト記法が由来ですが、言語を問わず使える標準フォーマットになっています。

{
  "id": 42,
  "name": "山田太郎",
  "tags": ["frontend", "backend"],
  "active": true
}

初学者向けポイント

  • 使える型は6種類だけ: 文字列・数値・真偽値・null・配列・オブジェクト
  • キーは必ずダブルクォートで囲む(シングルクォート不可、末尾カンマ不可)
  • JavaScriptでは JSON.parse()(文字列→オブジェクト)と JSON.stringify()(オブジェクト→文字列)で変換する

書き方でつまずくところ

手で書いたJSONがパースできない原因は、ほぼ次の4つに絞られます。

  • シングルクォートは使えない — {'name': '山田'} は不可
  • 末尾カンマは書けない — {"a": 1,} でエラーになる
  • コメントを書けない — // も /* */ も仕様に無い
  • 文字列に生の改行を入れられない — \n とエスケープする

パースの失敗は Unexpected token ... at position 87 のように文字位置で報告されます。全体を上から読み直すより、報告された位置の前後だけを見るほうが速く直せます。

tsconfig.json などにコメントが書けることがありますが、これは JSONC と呼ばれるツール側の拡張であり、JSON 本体の仕様ではありません。同じ感覚でAPIに送るJSONへコメントを書くと、相手側で必ずパースに失敗します。

人が手で編集する設定ファイルで注釈を残したいなら、最初からコメントを書ける [[YAML]] を選ぶほうが素直です。YAML 1.2 の仕様では JSON が YAML の部分集合と定められており、正しいJSONはそのままYAMLとしても読めます。

型が6種類しかないことの帰結

型が少ないことは、どの言語からでも読み書きできる移植性の裏返しです。ただし実務では、そのしわ寄せが決まった3か所に出ます。

  • 日付型が無い — 文字列で表すしかありません。"2026-07-31T09:00:00Z" のような ISO 8601 形式が事実上の標準です。"2026/07/31 18:00" と書くとタイムゾーンの情報が失われ、受け取った側が別の時刻として解釈します
  • 数値が1種類しかない — 整数と小数の区別がありません。JavaScript は数値を倍精度浮動小数点として扱うため、正確に表せる整数は 9007199254740991(2の53乗ひく1)までです。これを超える64ビットのID(SNSの投稿IDなど)を数値で送ると、受け取った側で末尾の桁が静かに変わります。大きなIDは文字列として送るのが定石です。金額も同じ理由で、小数ではなく「円単位の整数」で持つのが安全です
  • バイナリを入れられない — 画像やPDFはBase64の文字列にして埋め込みますが、データ量が約1.33倍に膨らみます。大きなファイルはJSONに入れず、取得用のURLだけを載せます

もう1つ、null と「キーそのものが無い」は別物です。「値を空にしたい」のか「今回は触っていない」のかで意味が変わるため、どちらを使うかはAPIの仕様として先に決めておきます。

どこで使われるか

場面例
API通信[[REST API]] / [[GraphQL]] のリクエスト・レスポンス
設定ファイルpackage.json、tsconfig.json
データ保存[NoSQL]はJSONそのままの形で保存する
ログ構造化ログ(1行1JSON)

JSONから次に読む地図

JSONは単体で完結する技術ではなく、いろいろな技術が共通して使う器として現れます。目的別に次の一歩を選んでください。

運ぶ — 通信の本文にする

[[REST API]] と [[GraphQL]] は、リクエストとレスポンスの本文をJSONで運ぶのが標準です。ブラウザ側から実際に送受信する手順や、変換を待つ処理の書き方、失敗したときの見え方は [[fetchと非同期通信]] にまとまっています。

壊さない — 受け取ったJSONを信じない

外から来たJSONは「形が正しい保証は無い」前提で扱います。必須項目や型を機械的に検証するのが [[JSON Schema]]、文字そのものが壊れる側の話が [[文字コードと文字化け]] です。JSONの符号化はUTF-8が前提で、BOMを付けることは仕様で禁じられています。多くのパーサーはBOM付きのファイルを先頭でエラーにします。

ためる — そのままの形で保存する

[[MongoDB]] はJSONに近い形式のドキュメントとして保存し、[[PostgreSQL]] は表の一部の列にJSONを入れられます。「表として設計できる部分は列に分け、形が定まらない項目だけJSON列に逃がす」というハイブリッドは実務でよく使う手です。どちらの方式を選ぶかの整理は [[NoSQL]] にあります。

読む — 運用中のJSONを追う

1行1JSONの構造化ログにしておくと、後から検索・集計ができます。レベルの分け方や、1つのリクエストを一本の線として追うためのIDの付け方は [[ログ設計]] にまとまっています。

出させる — AIに構造化データを作らせる

[[生成AI・LLM]] に文章ではなく「決まった形のデータ」を出させるとき、その形がJSONです。関数呼び出しを指示させる [[Function Calling]]、その接続方式を標準化した [[MCP(Model Context Protocol)]]、それらを土台に自律的に動く [[AIエージェント]] は、いずれもJSONをやり取りの単位にしています。LLMの出力は項目が欠けることがあるため、[[JSON Schema]] での検証を挟むのが基本です。JSONを中間データとして受け取り、最終的なファイル生成はプログラムに任せる例が [[Excel自動生成]] です。

入れ物にする — トークンと権限

[[JWT]] のペイロードはJSONをエンコードしただけなので、署名で改ざんを検知できても中身は誰でも読めます。[[AWS IAM]] のポリシーもJSONで書きます。どちらも「JSONだから中身は見える」ことを前提に、何を入れないかを決めます。

関連技術とのつながり

  • [[JavaScript]] — 記法の由来。パース関数が言語標準で備わる
  • [[REST API]] / [[GraphQL]] — 通信データの標準形式として使用
  • [[NoSQL]] — JSONドキュメントをそのまま保存するDBがある
  • [[文字コードと文字化け]] — 符号化はUTF-8が前提。BOM付きだとパースに失敗する
  • [[JSON Schema]] — 受け取ったJSONの構造を機械的に検証する仕様
  • [[YAML]] — 人が手で書く設定ファイル向けの形式。JSONはYAMLの部分集合にあたる
Q: JSONで日時を表すときの標準的なやり方はどれ?
- [ ] 日付型を使って `2026-07-31` と書く
- [x] `"2026-07-31T09:00:00Z"` のような ISO 8601 形式の文字列にする
- [ ] 曜日を含む日本語の文章として書く
解説: JSONに日付型はありません。タイムゾーンまで含む ISO 8601 形式の文字列で表すのが事実上の標準です。

Q: 64ビットの大きなIDをJSONで受け渡すとき、推奨される方法はどれ?
- [x] 文字列として送る
- [ ] 数値としてそのまま送る
- [ ] 真偽値に変換して送る
解説: JavaScriptが正確に表せる整数は9007199254740991までで、それを超える数値は末尾の桁が静かに変わります。大きなIDは文字列で送るのが定石です。

Q: JSONの仕様として正しいのはどれ?
- [ ] `//` で始まるコメントを書ける
- [ ] オブジェクトの最後の要素の後ろにカンマを置ける
- [x] キーはダブルクォートで囲む必要がある
解説: コメントと末尾カンマはJSONの仕様にありません。tsconfig.json などでコメントが使えるのは JSONC というツール側の拡張です。