JSON完全理解 — データ形式の文法とバリデーション
バイブコーディング入門 — 第15回
前回のおさらいと、今回のテーマ
前回(第14回)では、ページネーションとバージョニングを学んだ。大量データを分割表示するページネーション、APIの仕様変更で既存画面を壊さないバージョニング、エラー内容を具体的に返す構造化エラーレスポンス。この3つのテクニックで、成長するアプリに対応できるようになった。
さて、ここまでの連載で何度も登場してきたものがある。こんな形のデータだ。
{
"name": "株式会社田中商事",
"industry": "製造業",
"employees": 45
}
これがJSON(ジェイソン)だ。正式名称は JavaScript Object Notation(ジャバスクリプト・オブジェクト・ノーテーション)。名前にJavaScriptと付いているが、今はあらゆるプログラミング言語で使われている、Webの共通データ形式だ。
第6回のDevToolsでAPIのレスポンスを覗いたとき、この形式のデータが表示されていた。第12回〜14回のREST APIの解説でも、リクエストやレスポンスの例としてずっと使ってきた。
今回は、このJSONを正面から取り上げる。文法ルール、構造の読み方、よくあるミスの見つけ方、そしてAIが生成したJSONが正しいかどうかの検証方法まで。JSONが読めるようになると、APIのレスポンスが暗号ではなく普通の文章に見えるようになる。
JSONとは何か — Webの「共通語」
JSONは、アプリ同士がデータをやりとりするための書き方のルールだ。
日常生活のたとえで考えてみよう。あなたが取引先に顧客情報を送るとき、次のどちらが伝わりやすいだろうか。
パターンA(自由記述): 「田中商事さんは製造業で、従業員45人。電話は03-1234-5678。東京都千代田区にあります」
パターンB(表形式):
- 会社名: 株式会社田中商事
- 業種: 製造業
- 従業員数: 45
- 電話: 03-1234-5678
- 住所: 東京都千代田区
パターンBのほうが、一目で情報が整理されている。JSONは、このパターンBをコンピュータが読める形にしたものだ。
{
"company_name": "株式会社田中商事",
"industry": "製造業",
"employees": 45,
"phone": "03-1234-5678",
"address": "東京都千代田区"
}
「項目名」と「値」をペアにして、コロン(:)でつなぐ。複数のペアをカンマ(,)で区切り、全体を波括弧({ })で囲む。これがJSONの基本形だ。
JSONがWebの共通語になった理由は3つある。
1つ目: 人間にも読める。プログラムのコードと違って、JSONは項目名と値が並んでいるだけなので、プログラミング経験がなくても内容を理解できる。
2つ目: ほぼすべてのプログラミング言語で扱える。JavaScript、Python、Ruby、Go、どの言語でもJSONを読み書きする機能が標準で備わっている。
3つ目: 軽い。同じデータを表現するのに、JSON以前に主流だったXML(エックスエムエル)という形式に比べて、データ量が少なくて済む。通信量が減るので、アプリの表示が速くなる。
JSONの6つのデータ型
JSONで使えるデータの種類(型)は、たった6つしかない。少ないからこそ覚えやすい。
1. 文字列(string)
ダブルクォーテーション(" ")で囲んだテキストだ。
"株式会社田中商事"
"tanaka@example.com"
"2026-04-16"
注意点が1つある。JSONの文字列はダブルクォーテーション専用だ。シングルクォーテーション(' ')は使えない。'田中商事' と書くとエラーになる。
2. 数値(number)
クォーテーションで囲まない数字だ。整数も小数もマイナスも使える。
45
3.14
-100
よくある間違いが、数値を文字列にしてしまうことだ。"45" と書くと、それは数値ではなく文字列として扱われる。計算に使う値は、クォーテーションを付けない。
3. 真偽値(boolean)
true(正しい)か false(正しくない)の2択だ。
true
false
「この顧客はアクティブか?」「メール通知はオンか?」のように、はい/いいえで答えられる項目に使う。True や TRUE と書くとエラーになる。すべて小文字で true / false だ。
4. null(値なし)
「値が存在しない」ことを表す特別な値だ。
null
「まだ情報が入力されていない」「該当なし」という意味で使う。たとえば、退職日が未定の社員のデータなら "retired_at": null となる。NULL や Null ではなく、すべて小文字で null だ。
5. 配列(array)
複数の値をまとめたリストだ。角括弧([ ])で囲み、カンマで区切る。
["営業部", "マーケティング部", "総務部"]
[100, 200, 300]
[true, false, true]
配列の中身は、同じ型でなくてもよい(["田中", 45, true] も文法的にはOK)。ただし、実際のアプリでは同じ型で揃えるのが一般的だ。
6. オブジェクト(object)
波括弧({ })で囲んだ、キーと値のペアの集まりだ。JSONの基本形そのものがオブジェクトだ。
{
"name": "田中太郎",
"age": 35,
"active": true
}
オブジェクトの中にオブジェクトを入れることもできる(入れ子、ネスト)。これについては次のセクションで詳しく説明する。
入れ子(ネスト)の読み方 — JSONが複雑に見える原因
JSONが「難しそう」に見える最大の原因は、入れ子(ネスト)構造だ。オブジェクトの中にオブジェクトが入り、さらにその中に配列が入る。実際のAPIレスポンスはこういう形になることが多い。
{
"company": {
"name": "株式会社田中商事",
"address": {
"prefecture": "東京都",
"city": "千代田区",
"building": "田中ビル3F"
}
},
"employees": [
{
"name": "田中太郎",
"role": "代表取締役",
"email": "tanaka@example.com"
},
{
"name": "佐藤花子",
"role": "営業部長",
"email": "sato@example.com"
}
],
"is_active": true,
"founded_year": 2005
}
一見複雑だが、読み方にはコツがある。「外側から内側へ」順に読んでいくことだ。
ステップ1: 一番外側の波括弧を見る。全体が1つのオブジェクト(データのまとまり)だと分かる。
ステップ2: トップレベルのキーを確認する。company、employees、is_active、founded_year の4つだ。
ステップ3: 各キーの値の型を見る。
- company の値は { } で始まる → オブジェクト(中にさらにデータがある)
- employees の値は [ ] で始まる → 配列(複数のデータのリスト)
- is_active の値は true → 真偽値
- founded_year の値は 2005 → 数値
ステップ4: 必要な部分だけ深掘りする。company の中身を見たければ、company の { } の中だけを読む。全部を一度に理解しようとしなくてよい。
この「外側から内側へ」のアプローチは、どんなに複雑なJSONにも使える。DevToolsのPreviewタブでは、各オブジェクトや配列を折りたたんだり開いたりできるので、この読み方と相性が良い。
JSONの文法ルール — 間違えやすい5つのポイント
JSONの文法は厳密だ。プログラミング言語の中には、少しくらいの書き間違いを許してくれるものもあるが、JSONは許さない。カンマ1つ、クォーテーション1つの間違いでエラーになる。
ここでは、よくある間違いを5つ紹介する。
ミス1: 最後のカンマ(トレイリングカンマ)
間違い:
{
"name": "田中太郎",
"age": 35,
}
正しい:
{
"name": "田中太郎",
"age": 35
}
age の後ろにカンマがあるかないか、それだけの違いだ。JSONでは、最後の項目の後にカンマを付けるとエラーになる。JavaScriptのコードでは許されることが多いので、プログラマーでもよく間違える。
ミス2: シングルクォーテーション
間違い:
{
'name': '田中太郎'
}
正しい:
{
"name": "田中太郎"
}
JSONではダブルクォーテーション(")だけが有効だ。シングルクォーテーション(')は使えない。
ミス3: コメント
間違い:
{
"name": "田中太郎", // 代表取締役
"age": 35
}
JSONにはコメント(メモ書き)の仕組みがない。// や /* */ を書くとエラーになる。設定ファイルなどでコメントを使いたい場合は、JSONC(JSON with Comments)という別の形式が使われることがあるが、通常のAPIではコメントなしのJSONが使われる。
ミス4: キーのクォーテーション忘れ
間違い:
{
name: "田中太郎",
age: 35
}
正しい:
{
"name": "田中太郎",
"age": 35
}
JSONでは、キー(項目名)にも必ずダブルクォーテーションを付ける。JavaScriptのオブジェクトではクォーテーションなしでもOKだが、JSONでは必須だ。
ミス5: 数値と文字列の混同
要注意:
{
"price": "1500",
"quantity": 3
}
price が "1500"(文字列)になっている。これは文法的にはエラーにならないが、計算に使おうとすると問題になる。1500 × 3 = 4500 と計算してほしいのに、文字列同士では計算できない。金額・個数・年齢などの数値はクォーテーションを付けない。
JSONバリデーション — 文法チェックの方法
AIにアプリを作ってもらうとき、AIが生成したJSONに文法ミスが含まれていることがある。また、APIの設定ファイル(package.json や tsconfig.json など)を手で編集したときに、うっかりカンマを消してしまうこともある。
そういうとき、JSONが正しいかどうかをチェックする方法が「バリデーション」(検証)だ。
方法1: オンラインバリデーター
ブラウザで使えるJSONチェックツールがいくつかある。JSONをコピーして貼り付けると、文法エラーがあれば「何行目に問題がある」と教えてくれる。
使い方は簡単だ。
- バリデーターサイトを開く
- チェックしたいJSONをテキスト欄に貼り付ける
- 検証ボタンを押す
- エラーがあれば、行番号とエラー内容が表示される
方法2: DevToolsのConsoleタブ
ブラウザのDevToolsでもJSONの文法チェックができる。Consoleタブ(コンソールタブ)を開いて、次のように入力する。
少しだけコマンドが出てくるが、そのままコピーすれば動く。意味は分からなくてOKだ。
JSON.parse('{"name": "田中太郎", "age": 35}')
文法が正しければ、データがそのまま表示される。間違っていれば、赤い文字でエラーメッセージが出る。たとえば、最後にカンマを付けた場合:
JSON.parse('{"name": "田中太郎", "age": 35,}')
// → SyntaxError: Unexpected token } in JSON
「Unexpected token }」は、「}の位置に問題がある」(本当はカンマが余分)という意味だ。
方法3: AIに聞く
JSONの文法チェックは、AIが最も得意とする作業の1つだ。Claude CoworkにJSONを貼り付けて「このJSONに文法エラーがないか確認してほしい」と頼めば、エラー箇所を指摘して修正版も出してくれる。
大量のデータや複雑な入れ子構造のJSONは、目視でチェックするより、AIに任せるほうが確実だ。
実際のAPIレスポンスを読んでみよう
ここまでの知識を使って、実際のAPIレスポンスに近いJSONを読んでみよう。
あなたが20人の不動産会社の管理職だとする。物件管理アプリをバイブコーディングで作り、「物件一覧API」を呼び出した。返ってきたJSONがこれだ。
{
"properties": [
{
"id": 1,
"name": "グランドメゾン目黒",
"type": "マンション",
"price": 35000000,
"floor_area": 65.3,
"rooms": 2,
"available": true,
"features": ["オートロック", "宅配ボックス", "駐車場あり"],
"nearest_station": {
"name": "目黒駅",
"line": "JR山手線",
"walk_minutes": 8
}
},
{
"id": 2,
"name": "サンライズ渋谷",
"type": "マンション",
"price": 42000000,
"floor_area": 78.5,
"rooms": 3,
"available": false,
"features": ["オートロック", "ジム", "コンシェルジュ"],
"nearest_station": {
"name": "渋谷駅",
"line": "JR山手線",
"walk_minutes": 5
}
}
],
"total": 2,
"page": 1,
"limit": 20
}
さっき学んだ「外側から内側へ」で読んでみよう。
ステップ1: 一番外側は { }。全体が1つのオブジェクトだ。
ステップ2: トップレベルのキーは properties、total、page、limit の4つ。前回学んだページネーションの情報(total、page、limit)が含まれている。
ステップ3: properties の値は [ ] で始まっている。配列だ。中に2つのオブジェクトが入っている(= 物件が2件)。
ステップ4: 1件目の物件を見る。id は数値、name は文字列、price は数値(3,500万円)、available は真偽値(true = 空きあり)。features は文字列の配列(設備リスト)。nearest_station はオブジェクト(最寄り駅の情報がまとまっている)。
このように、型を手がかりにして読んでいけば、どんな複雑なJSONでも構造が理解できる。
JSONとExcelの対応関係
JSONの構造をExcelに置き換えると、イメージがつかみやすい。
配列([ ])はExcelの行に対応する。物件が2件あれば、配列の中に2つのオブジェクトが入る。Excelなら2行だ。
オブジェクト({ })のキーはExcelの列見出しに対応する。id、name、price、available がそれぞれ列見出しだ。
入れ子のオブジェクト(nearest_station)は、Excelなら「最寄駅_駅名」「最寄駅_路線」「最寄駅_徒歩分」のように列を分けて表現するところだ。JSONはこれを1つのまとまりとしてグループ化できる。
配列の中の配列(features)は、Excelでは1つのセルにカンマ区切りで入れがちな情報だ。JSONなら正式なリストとして扱える。
バイブコーディングでJSONを扱う場面
バイブコーディングでJSONに出会う場面は、大きく分けて4つある。
場面1: APIのレスポンスを読む
DevToolsのNetworkタブでAPIの返答を確認するとき、表示されるのはJSONだ。第6回で学んだスキルと今回の知識を組み合わせれば、「APIが何を返しているか」を自分の目で確認できる。
場面2: AIへの指示でデータ構造を伝える
第13回のリソース設計で学んだように、AIにアプリを作ってもらうとき、レスポンスの形式をJSONで指定すると精度が上がる。
「顧客一覧APIのレスポンスはこの形式にしてほしい」と伝えて、JSONのサンプルを貼り付ける。AIはそのサンプル通りのデータ形式で実装してくれる。
場面3: 設定ファイルの編集
Next.jsやTypeScriptの設定ファイル(package.json、tsconfig.json など)はJSON形式だ。AIが生成したこれらのファイルを手で微調整するとき、JSONの文法を知っていると安心だ。
場面4: データのインポート/エクスポート
Excelのデータをアプリに取り込んだり、アプリのデータをバックアップしたりするとき、JSON形式が使われることがある。CSVよりも構造が明確なので、入れ子の情報を扱う場合はJSONのほうが向いている。
AIにJSONのサンプルを作ってもらうテンプレート
JSONの構造を自分で1から書く必要はない。AIに作ってもらおう。
テンプレート: APIレスポンスのJSON設計
「顧客管理アプリの顧客一覧APIを作りたい。レスポンスのJSONを設計してほしい。
条件:
- 1件の顧客に含める項目: 会社名、業種、担当者名、メールアドレス、電話番号、ステータス(active/inactive)、登録日
- 一覧はページネーション付き(total、page、limit を含める)
- 各顧客に最終連絡日と連絡メモの履歴(最新3件)も含める
まずJSONのサンプルデータを2件分作って、そのあとAPIの実装をしてほしい。」
このテンプレートのポイントは、「まずJSONのサンプルを作って」と明示していることだ。AIがいきなりコードを書くのではなく、先にデータ構造を見せてもらう。それを確認してから実装に進めば、「思っていたのと違う」を防げる。
よくある不安と答え
JSONを自分で書く必要はあるのか
基本的にはない。バイブコーディングでは、JSONを書くのはAIの仕事だ。あなたの役割は「読めること」と「間違いに気づけること」だ。ただし、設定ファイル(package.json 等)をちょっとだけ直す場面は出てくるので、文法ルールを知っておくと安心だ。
JSONとCSVはどう違うのか
CSV(シーエスブイ)はカンマ区切りのテキストファイルで、Excelで開けるのが利点だ。単純な表(行と列)のデータに向いている。JSONは入れ子構造を扱えるので、「顧客の中に複数の連絡先がある」「注文の中に複数の商品がある」といった複雑なデータに向いている。どちらが優れているという話ではなく、用途が違う。
JSONのキーは日本語でもよいのか
文法的にはOKだ。{"会社名": "田中商事"} は有効なJSONだ。しかし、APIのキーは英語にするのが一般的だ。理由は、プログラムの中で company_name のように英語で参照するほうが、コードとの相性が良いからだ。AIに依頼するときも、英語のキー名で指定するのが無難だ。
JSONファイルが壊れたとき、元に戻せるか
アプリの設定ファイル(package.json 等)を編集して壊してしまった場合、バイブコーディングでGitを使っていれば、変更前の状態に戻せる。AIに「package.json を直前のコミットの状態に戻してほしい」と頼めばよい。Gitを使っていない場合でも、AIに「package.json を正しい状態に修正してほしい。エラー内容はこれです」と伝えれば、修正してくれることが多い。
まとめ
JSONはWebアプリのデータをやりとりするための共通形式で、波括弧({ })でオブジェクト、角括弧([ ])で配列を表す。データ型は文字列・数値・真偽値・null・配列・オブジェクトの6種類。入れ子構造は「外側から内側へ」読むのがコツだ。よくある文法ミスは、末尾のカンマ、シングルクォーテーション、キーのクォーテーション忘れの3つ。バイブコーディングでJSONを書く必要はほぼないが、APIレスポンスを読む力と、文法ミスに気づく力があれば、AIとのやりとりの精度が格段に上がる。
次回は「認証と認可 — 誰が何をできるかを管理する仕組み」。ログイン機能の裏側で何が起きているのか、OAuth(オーオース)やJWT(ジェイダブリューティー)とは何かを、非エンジニア向けに解説する。
参考リファレンス
- 前回: 第14回「APIのバージョニングとページネーション — 大量データを扱う設計テクニック」(/articles/vc-014)
- 次回: 第16回「認証と認可 — 誰が何をできるかを管理する仕組み」(/articles/vc-016)
- 第6回「HTTPリクエストとレスポンスを覗く — DevToolsで通信の中身を見る」(/articles/vc-006)
- バイブコーディング入門 カリキュラム(/vibe-coding)




