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をコピーして貼り付けると、文法エラーがあれば「何行目に問題がある」と教えてくれる。

使い方は簡単だ。

  1. バリデーターサイトを開く
  2. チェックしたいJSONをテキスト欄に貼り付ける
  3. 検証ボタンを押す
  4. エラーがあれば、行番号とエラー内容が表示される

方法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)