JSONとは?プログラミングでの書き方や基本ルールを徹底解説

結論: JSON(JavaScript Object Notation)とは、プログラミング言語やOSの壁を越えてデータをやり取りするための、世界標準のテキストフォーマットです。

Contents

JSONは「プログラミング言語」ではない

最初に誤解を解いておきます。「JSONプログラミング」という言葉で検索されることが多いですが、JSON自体はプログラミング言語ではありません

Mikoto

え、そうなんですか? 「JSONプログラミング」って検索候補に出てくるから、てっきりJavaScriptみたいにコードを書くものだと思ってました。

Yachi

よくある誤解ですね。JSONに計算処理やロジックを書く機能はありません。あくまで「データをどう記述するか」を決めただけのテキストファイルなんです。

JSONはデータ記述言語、つまり「データの書き方のルールブック」です。Pythonで書かれたプログラムと、Javaで動いているシステムが会話をする際、お互いの言葉(文法)は異なりますが、「JSON」という共通のルールでデータを渡すことで、スムーズな意思疎通が可能になります。

現代のWeb開発において、JSONを扱えないことは「読み書きができない」のと同義です。この記事では、JSONの正確な構文ルールから、現場で頻発するエラー、そして主要言語(JavaScript/Python)での具体的な扱い方までを網羅的に解説します。

【ここでのポイント】JSONはプログラミング言語ではなく、データを保存・交換するための「形式(フォーマット)」です。ロジックは持てませんが、あらゆる言語で読み書きできる汎用性が武器です。

JSONとは?「共通申請書」としての役割

JSON(ジェイソン)は、元々JavaScriptのオブジェクト表記法をベースに考案されましたが、現在は特定の言語に依存しない独立した規格(Language Independent)として確立されています(RFC 8259 / ECMA-404)。

JSONの役割を直感的に理解するために、「Web上の『共通申請書』フォーマット」とイメージしてください。

例えば、役所の手続きを想像してみましょう。

  • Aさん(Python使い): 日本語しか話せません。
  • Bさん(Java使い): 英語しか話せません。

二人が直接会話をしても通じませんが、「この申請書(JSON)の『名前』欄には名前を書き、『年齢』欄には数字を書く」という共通のフォーマットが決まっていれば、お互いに書かれた内容を正しく理解し、処理を進めることができます。

Yachi

この「人間が見ても分かりやすい」という点が重要です。昔はバイナリ形式という人間には読めないデータ交換も多かったんですが、デバッグのしやすさから、今はテキスト形式であるJSONがデファクトスタンダード(事実上の標準)になっています。

なぜJSONが標準なのか?XML・CSVとの構造比較

データの保存形式には、他にもCSVやXMLがあります。なぜそれらを押しのけてJSONが主流になったのでしょうか。理由は「構造化能力」と「軽量さ」のバランスが圧倒的に良いからです。

RPGゲームの武器データ「エクスカリバー(攻撃力50)」を例に、3つの形式を比較してみましょう。

1. CSV (Comma-Separated Values)

  • 特徴: カンマ区切り。Excelで開きやすく、最も軽量です。
  • 欠点: 「101」がIDなのか個数なのか、見ただけでは分かりません。また、複雑な階層構造(アイテムの中に属性データが入るなど)を表現できません。

2. XML (Extensible Markup Language)

  • 特徴: タグで囲むため意味が明確です。
  • 欠点: 終了タグ(</id>など)が必要で記述が長く(冗長)、ファイルサイズが大きくなりがちです。プログラム側での解析(パース)コストも高くなります。
Yachi

個人的には、レガシーシステムとの連携などのっぴきならない事情がない限り、新規開発でXMLを採用する理由はないと考えています。終了タグのタイプ量が増えるだけでなく、可読性もJSONの方が優れているからです。

3. JSON

  • 特徴: キーと値がペアになっており意味が明確。XMLのような終了タグがないため記述がすっきりしており、JavaScriptエンジンで高速に解析できます。
Mikoto

確かにXMLに比べると、JSONの方がシュッとしてて見やすいですね。

Yachi

そうなんです。WebAPIでは通信量(パケット)の節約も重要なので、同じ情報をより少ない文字数で表現できるJSONが好まれるんです。

データの管理方法として比較される「SQL」の基本については、こちらの記事で詳しく解説しています。

JSONの基本構文:5つの記号と書き方の鉄則

JSONの構文は極めてシンプルです。基本的に以下の5種類の記号ダブルクォーテーションだけで構成されます。

  • 構造を作る: { }(オブジェクト)、[ ](配列)
  • つなぐ: :(キーと値の区切り)、,(データ同士の区切り)

書き方の3大鉄則

ここだけは絶対に覚えてください。JSONを手書きする際のミスの大半はここから生まれます。

  • ルート(根)は1つ
    データ全体を必ずひとつの { ... } または [ ... ] で囲みます。
  • キー(Key)は必ずダブルクォート
    "name": "Hero" のように、左側のキーは必ず " で囲む必要があります。
  • 文字列(String)も必ずダブルクォート
    値が文字列の場合も " で囲みます。シングルクォート ' は使用禁止です(構文エラーになります)。
Mikoto

JavaScriptだとキーのクォートを省略したり、シングルクォートを使ったりしますけど、JSONはダメなんですか?

Yachi

ここが一番の落とし穴です。JSONはJavaScript由来ですが、「より厳格なルールを持つ別物」と考えてください。手書き設定ファイルでこのミスをする人が後を絶ちません。

【ここでのポイント】JSONは構文ルールが非常に厳格です。JavaScriptの感覚で「多少省略しても動くだろう」と思っていると、必ずパースエラー(SyntaxError)になります。「すべてダブルクォートで囲む」と覚えておけば間違いありません。

JSONで使用可能な6つのデータ型と制約

JSONの「値(Value)」としてセットできるデータ型は、以下の6種類に限定されています。

データ型書き方の例解説
文字列"text", "こんにちは"必ず " で囲む。改行などはエスケープ文字(\n)を使う。
数値123, 10.5, -50" で囲まない。整数と浮動小数点の区別はない。8進数や16進数表記は不可。
真偽値true, false" で囲まない。全て小文字であること(Trueは不可)。
nullnull値が空であることを示す。" で囲まない。全て小文字
オブジェクト{ "k": "v" }キーと値の集合。
配列[ 1, 2, 3 ]値の順序付きリスト。

注意:JSONで使えない型

JavaScript等では当たり前に使う以下の型は、JSONには存在しません。

  • Date(日付): 日付型はありません。ISO 8601形式の文字列("2023-12-01T10:00:00Z")として扱い、プログラム側で変換します。
  • Function(関数): ロジックは保存できません。
  • undefined: 値が存在しない場合は、キー自体を含めないか、null を使います。
Mikoto

日付型がないって不便じゃないですか?

Yachi

一見不便ですが、逆に「フォーマットが文字列で統一される」というメリットもあります。個人的には、Unixタイムスタンプ(数値)で渡すよりも、ISO 8601形式の文字列を推奨します。デバッグ時に人間がパッと見て日時がわかるからです。

階層構造の表現:オブジェクトと配列の組み合わせ

JSONの真価は「ネスト(入れ子)」にあります。
オブジェクトの中に配列を入れたり、配列の中にオブジェクトを入れることで、実世界の複雑なデータをそのまま表現できます。

ここでは「RPGゲームのセーブデータ」を例に、JSONの構造設計を見てみましょう。

Mikoto

うわ、一気に複雑になりましたね…。カッコがいっぱいで目が回りそうです。

Yachi

複雑に見えますが、分解すれば「辞書(オブジェクト)」と「リスト(配列)」の組み合わせに過ぎません。

構造のポイント

  • player: キャラクター情報をひとまとまりにするため、オブジェクト({})をネストしています。さらにその中に stats(能力値)というオブジェクトが入っています。
  • inventory: アイテム名のリストは順序が重要なので、配列([])を使っています。
  • party_members: 「名前とHP」という構造を持ったデータが複数あるため、「オブジェクトの配列」という形をとっています。これはWeb APIで最もよく使われるパターンです。

【ここでのポイント】「名前がついているものはオブジェクト」「順序よく並んでいるものは配列」。この2つの原則さえ押さえておけば、どんなに複雑なデータ構造もJSONで表現できます。

エラー原因の9割!初心者がやりがちな「NG構文」リスト

エディタやAPI通信で SyntaxError: Unexpected token... と怒られたら、十中八九以下のどれかに該当します。

Mikoto

私もこれよくやります…。どこが間違ってるのか探すのに時間かかるんですよね。

Yachi

慣れているエンジニアでもやりがちです。特に「末尾のカンマ」は、他の言語の癖でつい付けてしまう代表的なミスですね。

1. 末尾のカンマ (Trailing Comma)

  • NG: [ "Potion", "Map", ]
  • NG: { "a": 1, "b": 2, }
  • 解説: 最後の要素の後ろにカンマを置いてはいけません。近年のプログラミング言語(JavaScriptやPython)では、Gitの差分を綺麗にするために「ケツカンマ」を許容することが多いですが、JSON仕様では厳格に禁止されています。

2. シングルクォートの使用

  • NG: {'key': 'value'}
  • 解説: JSONの世界ではシングルクォート ' は文字として認められません。必ずダブルクォート " を使ってください。

3. キーのクォート忘れ

  • NG: { key: "value" }
  • 解説: JSのオブジェクトリテラルと混同しがちですが、JSONではキーを裸で書くことはできません。

4. コメントの記述

  • NG: // ここは設定値
  • 解説: JSONにはコメント構文(///* */)が存在しません。設定ファイルとして使う場合に不便ですが、仕様です。
Yachi

個人的には、コメントが書けないのはJSONの弱点だと思っています。VSCodeの設定ファイルなどが .json ではなく「JSON with Comments (JSONC)」という拡張仕様を採用しているのはそのためです。ただし、通常のデータ通信ではコメントは使えないと覚えておいてください。

5. 数値のゼロ埋め

  • NG: 0123
  • 解説: 先頭が0の数値は許容されません(8進数と誤認されるのを防ぐため)。IDなどで「001」としたい場合は、数値ではなく文字列 "001" として扱ってください。

実践:プログラミング言語での読み書き(JavaScript編)

Webフロントエンド開発では、サーバーから受け取ったJSON文字列をJavaScriptのオブジェクトに変換して画面に表示する処理が日常的に行われます。

デシリアライズ(文字列 → オブジェクト)

JSON形式の文字列を、プログラムで扱えるオブジェクトに変換することを「デシリアライズ(パース)」と呼びます。

シリアライズ(オブジェクト → 文字列)

逆に、データをサーバーに送信したり保存したりするために、文字列へ変換することを「シリアライズ」と呼びます。

【ここでのポイント】JSON.parse() で読み込み、JSON.stringify() で書き出し。この2つのメソッドはWeb開発の基本中の基本です。特に stringify の第3引数でインデントを付けられる小技は、デバッグ時に役立ちます。

実践:プログラミング言語での読み書き(Python編)

Pythonでは標準ライブラリの json モジュールを使用します。Pythonの辞書型(dict)やリスト型(list)とJSONは非常に相性が良いです。

基本操作

Mikoto

trueTrue に、nullNone に変わってる!

Yachi

そうなんです。JSONの型と、各言語が持つ型は必ずしも一致しないので、ライブラリがいい感じに変換してくれるんです。

日本語を含むデータの書き出し

日本国内の開発でよくハマるのが、日本語が \uXXXX のようなUnicodeエスケープシーケンスになってしまう問題です。

Yachi

PythonでJSONを扱う際、この ensure_ascii=False はほぼ必須の呪文です。これを忘れると、せっかくの日本語データが人間には読めない記号の羅列になってしまい、ログ確認が非常に困難になります。

ファイルの読み書き

ファイル操作の場合は、関数名から s を抜いた loaddump を使います。

  • json.load(f): ファイルから読み込み
  • json.dump(data, f): ファイルへ書き込み

Web開発におけるJSONの役割とエコシステム

JSONは単なるデータ交換フォーマットを超え、現在ではシステムの中核を担う存在になっています。

  • REST API / GraphQL
    Webサービスの裏側では、リクエスト(要求)とレスポンス(応答)のボディとして膨大なJSONが飛び交っています。
  • 設定ファイル (Config)
    VSCodeの settings.json や Node.jsの package.json など、ツールの設定もJSONで記述されることが多いです。
  • NoSQLデータベース
    MongoDBやAzure Cosmos DBなどの「ドキュメント指向データベース」は、データをJSONライクな形式(BSON等)でそのまま保存します。SQLを使わずに、JSON構造のままクエリを投げられるのが特徴です。
  • ログ管理
    サーバーのログをテキスト行ではなくJSON形式(構造化ログ)で出力することで、DatadogやCloudWatchなどの解析ツールで「エラーレベルがErrorのものだけ抽出」といった高度な検索が可能になります。
Mikoto

ログまでJSONなんですか?

Yachi

そうです。昔はただのテキストでしたが、今はJSON形式で吐き出すのがモダンな設計です。プログラムで自動解析しやすくなるので、障害対応のスピードが段違いなんです。

JSONと深く関わる「API」や「Webhook」の仕組みについても合わせて学ぶと、理解がより深まります。

開発効率を上げるエディタと検証ツール

JSONは人間が読めるとはいえ、カッコの対応関係などを手書きで管理するのはミスのもとです。ツールによる支援を積極的に受けましょう。

1. Visual Studio Code (VSCode)

拡張子を .json にするだけで、標準機能が働きます。

  • 構文ハイライト: 色分けで見やすい。
  • エラー警告: カンマ忘れや不要なカンマを赤波線で教えてくれます。
  • フォーマット: Shift + Alt + F (Windows) でインデントを一瞬で整えてくれます。
Yachi

JSONを手書きするなら、メモ帳などのシンプルなエディタは絶対に使わないでください。VSCodeなら構文エラーをリアルタイムで指摘してくれるので、ケアレスミスで時間を浪費することがなくなります。

2. JSONLint

Webブラウザ上で使える構文チェッカー(バリデータ)です。APIから返ってきた謎の文字列をコピペして「Validate JSON」を押せば、どこが間違っているかを特定し、きれいに整形してくれます。

3. ブラウザ拡張機能

ChromeやEdgeに「JSON Viewer」系の拡張機能を入れておくと、ブラウザでAPIのURLを叩いた際、生のテキストではなく構造化されたツリー形式で見やすく表示されます。API開発をするなら必須のツールです。

よくある質問

JSONデータにコメントを書く裏技はありますか?

原則ありません。
どうしても必要な場合は、データとして "_comment": "ここにメモ" というキーを追加する運用回避策がありますが、システムによっては無視されたり、予期せぬエラーの原因になる可能性があるため推奨されません。コメントが必須な設定ファイル用途であれば、JSONC(JSON with Comments)やYAMLの採用を検討してください。

日付データはどう扱うのが正解ですか?

ISO 8601形式の文字列として扱います。
"2026-05-20T10:00:00Z" のような文字列として格納するのが世界標準です。受け取り側のプログラムで、この文字列を日付オブジェクトにパースして使用します。Unixタイムスタンプ(1716199200のような数値)を使う場合もありますが、人間が読めないためデバッグしづらくなります。

キーの順番は保存されますか?

保証されません。
JSONの仕様上、オブジェクト内のキーの順序は「順不同」です。{"a":1, "b":2}{"b":2, "a":1} は同じデータとして扱われます。もしデータの並び順に意味を持たせたい場合は、オブジェクトではなく「配列」を使用する必要があります。


まとめ

JSONは、現代のITエンジニアにとって「読み書きできて当たり前の共通言語」です。

  • 構造: {}[] の組み合わせで表現する。
  • ルール: キーと文字列は必ずダブルクォート "。末尾カンマは禁止。
  • 実践: 言語ごとのライブラリ(JSON.parse / json.loads)を使ってオブジェクトに変換する。

API連携や設定ファイル、データベースなど、開発のあらゆる場面でJSONは登場します。

Yachi

まずはVSCodeなどのエディタを使って、自分で手書きでJSONファイルを作ってみてください。「あ、ここでカンマ忘れたらエラーになるんだ」という感覚を指先で覚えるといいですよ。

この記事を書いた人

生成AIコンサルタント / テックリード

外資系IT企業にて社内の生成AI活用推進と
生成AIプロダクト開発リードを担当。

かつてはWeb系のエンジニアとして、
モダンな技術スタックでのシステム開発から
数百億レコード規模のデータベース運用までを
フルスタックに経験。

「コードも書けるコンサルタント」として、
活用論と実装論の両面から、
現場で使えるIT知識を発信します。

私と本サイトの詳細は運営者情報をご確認ください。

Contents