IT用語集 2024/11/27

JSON（JavaScript Object Notation）とは？ 10分でわかりやすく解説

コラム

JSON（JavaScript Object Notation）は、システム間でデータをやり取りするときに広く使われるテキスト形式です。見た目がシンプルで扱いやすい一方で、書き方の細かなルール（クォート、カンマ、型）を外すとすぐにパースエラーになり、運用では「想定外の型」「バリデーション不足」「サイズ肥大化」などの事故も起きやすくなります。本記事では、JSONの基本から、現場でつまずきやすいポイント、設計・検証・セキュリティまでを整理し、JSONを安心して扱うための判断軸を作ります。

JSONとは

JSONの定義と概要

JSON（JavaScript Object Notation）とは、データの記述や交換に用いられる軽量なテキストベースのフォーマットです。JavaScriptのオブジェクト表記に近い形で表現できますが、現在は言語に依存しない汎用フォーマットとして、APIの入出力や設定情報の受け渡しなどで広く利用されています。

JSONが支持される理由は、構造が「オブジェクト（キーと値）」と「配列（値の並び）」に整理されており、人間が読み取りやすく、コンピュータもパースしやすい点にあります。ただし、読みやすいからといって曖昧に書けるわけではありません。JSONは仕様上、書式ルールが厳密で、少しのミスが処理停止につながります。

JSONの特徴と利点

JSONには、実務上メリットになりやすい特徴があります。

構文が比較的シンプルで、データ構造（階層・配列）を表現しやすい
言語・環境をまたいだやり取りに向く（多くの言語で標準サポートがある）
XMLなどに比べ、同じ情報をよりコンパクトに表現できることが多い
HTTP APIのリクエスト／レスポンス形式として定着している
整形や可視化のツールが豊富で、デバッグがしやすい

一方で「軽量で高速」と言い切るのは危険です。データ量が増えれば当然重くなりますし、ネストが深いJSONは扱いづらく、パース時間やメモリ負荷も無視できません。JSONは万能ではなく、用途と規模に合わせた設計が必要です。

JSONの基本構文

JSONは主に次の要素で構成されます。

要素	説明
オブジェクト	キーと値のペアを波括弧 `{}` で囲む（例：`{"name":"Alice"}`）
配列	複数の値を角括弧 `[]` で囲む（例：`[1,2,3]`）
値	文字列、数値、真偽値（true/false）、null、オブジェクト、配列

特に初心者がつまずきやすいルールは次のとおりです。

文字列は必ずダブルクォート（シングルクォートはJSONでは不可）
末尾カンマは不可（配列やオブジェクトの最後にカンマを付けない）
コメントは仕様上書けない（コメント付きは「JSON」ではなく別形式として扱う必要がある）
キーは基本的に文字列（{"1": "a"} のようにクォートする）

たとえば、見た目は正しそうでも末尾カンマだけでエラーになります。

{
  "name": "Alice",
}

このようなミスを減らすには、手書きを最小限にし、フォーマッタや検証ツールを前提に運用するのが安全です。

JSONとXMLの違い

JSONとXMLはどちらもデータ交換に使われますが、得意分野が異なります。

JSON	XML
データ構造（オブジェクト・配列）を表現しやすい	文書構造（タグ階層）を表現しやすい
比較的コンパクトでAPI向き	名前空間や属性など表現力が高い
多くのWeb APIで標準的	既存の業務標準や文書交換で利用されることがある

近年はWeb関連でJSONが主流になりやすい一方、既存システム連携や文書中心の要件ではXMLが選ばれることもあります。「どちらが優れているか」ではなく、用途に合う形式を選ぶのが現実的です。

JSONの活用方法

Webサービスでのデータ通信

JSONはWebサービス（API）で最もよく使われます。クライアントとサーバー間でデータをやり取りする際、JSONに統一すると言語や実装の違いを越えて同じ構造で受け渡しできるためです。特にREST APIでは、リクエスト／レスポンスのボディがJSONであるケースが一般的です。

ただし、運用で問題になりやすいのは「仕様のあいまいさ」です。たとえば、同じ項目がある時は数値、ある時は文字列、といった揺れがあると、受け手は例外処理だらけになります。APIでは、後述するスキーマやバリデーションを前提に、型と必須項目を揃えるのが重要です。

モバイルアプリ開発におけるデータ形式

モバイルアプリでも、バックエンドとの通信でJSONが頻繁に使われます。通信帯域や処理資源が限られる場面では、不要な項目を返さない設計や、ページングなどの工夫が実務上の効きどころになります。

また、ローカルで設定情報を保持する目的でJSONを使うこともあります。ただし、後から項目が増える可能性があるなら、バージョン管理やマイグレーションの方針を持っておかないと、古いデータが読めずに不具合になるケースがあります。

設定ファイルとしての利用

JSONは設定情報の受け渡しにも利用されます。階層構造を扱いやすいため、環境ごとの設定（機能のON/OFF、接続先、閾値など）をまとめるのに向いています。

ただし、JSONは仕様上コメントを書けません。設定ファイルに説明を残したい場合は、次のような代替を検討します。

説明用のREADMEやドキュメントを別に用意する
説明が必要な項目を人間向けに整理した表を併設する
コメント可能な別形式（例：YAMLなど）を採用する

「コメントが書けるからJSONを設定ファイルに使う」と考えると、仕様とのズレで混乱しやすいので注意が必要です。

データベースとの連携

ドキュメント指向データベースでは、JSONに近い形でデータを扱えることが多く、アプリケーションとデータの構造が揃いやすいという利点があります。一方、リレーショナルデータベースでもJSON型をサポートする例があり、構造化データと半構造化データを併用する設計が可能です。

ただし「JSONをDBに入れれば自由」という発想は危険です。検索・索引・整合性の設計を後回しにすると、集計や運用監視が難しくなります。JSONで柔軟性を得るなら、どの項目を正規化し、どの項目をJSONに寄せるかを先に決めておくべきです。

JSONを扱うライブラリとツール

主要プログラミング言語のJSONライブラリ

JSONは多くの言語で標準サポートされています。代表例は次のとおりです。

JavaScript：ネイティブでサポート（JSON.parse / JSON.stringify）
Python：標準ライブラリ（json）
Java：Jackson、Gson
Ruby：標準ライブラリ（json）
PHP：json_encode() / json_decode()
C#：System.Text.Json（JsonSerializer など）

ライブラリ選定で見落としやすいのは「例外時の挙動」と「型の扱い」です。たとえば、数値の精度（小数・巨大整数）や、nullの取り扱い、未知フィールドが来たときの処理方針は、言語や設定によって差が出ます。サンプルが動くだけで判断せず、運用時の入力ゆらぎも想定して設計しましょう。

JSONデータの検証ツール

JSONの品質を確保するには、構文チェックだけでなく、「期待した構造か」を検証することが重要です。次のような用途でツールを使い分けると効果的です。

構文チェック：パース可能か、カンマやクォートが正しいか
整形（フォーマット）：差分比較をしやすくする
スキーマ検証：必須項目、型、文字列長、列挙値などを検査する

外部からJSONを受け取る場合は、検証を前提にしないと事故が起きます。「パースできたから正しい」とは限らないためです。

JSONデータの整形・可視化ツール

JSONはそのままだと読みづらいことがあります。ツリー表示や差分比較に強いツールを使うと、デバッグや調査が速くなります。特に、ネストが深いJSONや配列が大きいJSONでは、可視化が作業効率に直結します。

JSONデータの編集ツール

エディタを選ぶ際は、シンタックスハイライトだけでなく、次の機能があると運用が楽になります。

保存時フォーマット（整形）
バリデーション（構文エラーの即時表示）
スキーマ連携（補完・型チェック）

人が書くJSONは、どうしてもミスが混入します。編集ツール側でミスを早期に見つけられる環境を整えるのが現実的です。

JSONの実装のベストプラクティス

JSONデータ設計のポイント

JSON設計で重要なのは「受け手が迷わない構造」です。次の観点を押さえると、後から壊れにくくなります。

構造を単純に保つ：ネストは必要最小限にし、深くしすぎない
命名規則を統一する：camelCase / snake_case を混在させない
型を揃える：同じキーが状況で文字列になったり数値になったりしない
nullの意味を決める：未設定なのか、空を表すのかを仕様化する
拡張を想定する：新しいフィールド追加が起きても壊れない方針を決める

たとえば、日付を表す場合、「2025-12-30」のような文字列にするのか、UNIX時間の数値にするのかで、受け手の実装が変わります。形式を先に決めて固定し、仕様として明記するのが安全です。

バリデーションと契約（スキーマ）を前提にする

現場で多いトラブルは、入力の「揺れ」と「欠落」です。これを減らすには、JSONを受け取る側で次をセットにする必要があります。

構文検証：JSONとしてパースできるか
構造検証：必須項目があり、型と制約が満たされているか
仕様の共有：送信側と受信側で同じ前提（契約）を持てているか

仕様が曖昧なまま運用が始まると、「とりあえず動かす」例外処理が積み上がり、将来の改修が難しくなります。最初から完全なスキーマを作れなくても、必須項目と型だけでも固定しておくと、破綻しにくくなります。

JSONデータのセキュリティ対策

JSONはただのテキストですが、攻撃者にとっては入口になり得ます。実務で押さえたいポイントは次のとおりです。

信頼できないJSONは必ず検証する：サイズ制限、型、必須項目、文字数制限を持つ
エラーをそのまま返さない：内部構造やスタックトレースを露出させない
機密情報を含めない：トークンや個人情報をログに出さない設計にする
送受信はTLSで保護する：盗聴・改ざんのリスクを下げる
危険なマージ処理に注意する：入力JSONを無検証でオブジェクトにマージすると、実装によっては想定外の挙動を引き起こす

「JSONだから安全」ということはありません。入力値として扱う以上、他のフォーム入力と同じように、検証と制限を前提にしましょう。

JSONデータのパフォーマンス最適化

JSONが重くなる原因は、たいてい「返しすぎ」「詰め込みすぎ」です。パフォーマンスを落とさずに使うには、次の工夫が効きます。

必要な項目だけ返す：画面や処理に必要な項目に絞る
ページングを使う：配列が巨大になる設計を避ける
圧縮を活用する：通信量が支配的なら圧縮で効く場合がある
キャッシュ設計をする：更新頻度が低いデータはキャッシュ前提にする

「JSONが遅い」のではなく、設計が重いことが原因のケースが多いです。まずはデータ量と返却範囲を見直しましょう。

JSONデータのエラーハンドリング

JSON処理のエラーは、ユーザー体験や運用負荷に直結します。次の方針を持つと、調査と復旧がしやすくなります。

パースエラーと検証エラーを分ける：原因の切り分けを容易にする
エラー応答の形式を揃える：クライアント側が処理しやすい形にする
ログに必要十分な情報を残す：機密情報を除き、再現に必要な範囲で記録する
未知フィールドの扱いを決める：無視するのか、拒否するのかを仕様化する

特にAPIでは、エラーメッセージが曖昧だと、利用者も運用者も困ります。「どの項目が」「なぜ」不正なのかが分かる形にしつつ、内部情報を出しすぎないバランスが重要です。

まとめ

JSONは、システム間のデータ交換で広く使われる軽量なテキストフォーマットです。構造がシンプルで扱いやすい反面、書式ルールは厳密で、型の揺れやバリデーション不足があると運用で破綻しやすくなります。JSONを安全に活用するには、設計（構造と型の統一）、検証（スキーマや制約）、運用（サイズ・ログ・エラー方針）をセットで考えることが重要です。基本を押さえた上で、用途に合った形でJSONを使い分けましょう。