JSONをオンラインで検証する方法：開発者向け実践ガイド

JSON（JavaScript Object Notation）は、現代のWeb開発で最も広く使われているデータ交換フォーマットです。ほぼすべてのREST APIがJSON形式でデータを返し、package.jsonやtsconfig.jsonなどの設定ファイルもこのフォーマットを使用し、MongoDBのようなデータベースもJSON形式でドキュメントを保存しています。

問題は、たった1つの文字のミス（余分なカンマ、欠落したクォート、閉じられていないブラケット）がJSON全体を無効にし、アプリケーションにエラーを引き起こすことです。API応答で無効なJSONがあるとフロントエンドが壊れます。tsconfig.jsonにシンタックスエラーがあるとTypeScriptがコンパイルできません。

使用前にJSONを検証することで、何時間ものデバッグを節約できます。NexToolsのJSON検証ツールを使えば、任意のJSONを貼り付けて、エラーの正確な行番号を確認し、自動的に整形された出力を得ることができます。

JSONには厳密な構文ルールがあります。いずれかを違反すると無効なJSONが生成されます：

• キーはダブルクォートで囲む必要がある：{"name": "Ana"}は有効。{name: "Ana"}は無効。
• 文字列はダブルクォートを使い、シングルクォートは不可："value"は有効。'value'は無効。
• 末尾のカンマは不可：{"a": 1, "b": 2}は有効。{"a": 1, "b": 2,}は無効。
• コメントは不可：JSON内で//も/* */も使えません。
• 数値にはクォートを付けない：{"age": 25}は有効。{"age": "25"}は動作しますが、値は数値ではなく文字列です。

JSONで許可されるデータ型：

型	例	備考
String	"こんにちは"	常にダブルクォート
Number	42、3.14、-7	整数または小数、クォートなし
Boolean	true、false	小文字、クォートなし
Null	null	小文字、クォートなし
Array	[1, 2, 3]	カンマ区切りの値
Object	{"key": "value"}	キーと値のペア

JSONを扱う際に最も頻繁に遭遇するエラーです：

1. 最後の要素の後のカンマ：
   {"items": [1, 2, 3,]} — 3の後のカンマが無効。
2. ダブルクォートの代わりにシングルクォート：
   {'name': 'Taro'} — {"name": "Taro"}でなければならない。
3. クォートなしのキー：
   {age: 30} — {"age": 30}でなければならない。
4. エスケープされていない制御文字：
   文字列内のタブや改行は\tと\nとして記述する必要がある。
5. 文字列内のエスケープされていないクォート：
   {"text": "彼は"こんにちは"と言った"} — エスケープが必要。
6. コメント：
   JSONはいかなる種類のコメントもサポートしていない。
7. NaN、Infinity、undefined：
   これらのJavaScriptの値はJSONでは無効。代わりにnullを使用。
8. 16進数値：
   {"color": 0xFF0000}は無効。{"color": "#FF0000"}を使用。
9. 型付き配列での型の混在：
   [1, "二", true]は有効なJSONだが、多くのAPIは同種の配列を期待する。
10. BOM（バイトオーダーマーク）：
    一部のエディタがファイルの先頭に不可視バイトを追加し、JSONを無効にする。常にBOMなしのUTF-8で保存する。

これらのエラーはすべてJSON検証ツールで自動的に検出され、各エラーの正確な行と位置が表示されます。

JSONは2つの方法で表示できます：人間が読みやすい整形版（pretty-print）と、効率的な転送のための圧縮版です。

整形されたJSON：

{
  "user": {
    "name": "花子",
    "age": 28,
    "active": true
  }
}

圧縮されたJSON（同じデータ、より少ないバイト数）：

{"user":{"name":"花子","age":28,"active":true}}

圧縮版はスペースが少なく（APIやストレージに最適）、整形版は読みやすくデバッグが容易です。

JavaScriptでは：

JSON.stringify(data, null, 2)  // 2スペースで整形
JSON.stringify(data)           // 圧縮

大きなJSONファイルの圧縮には、JSON、CSS、JavaScriptを処理できるコード圧縮ツールを使用してください。

JSON以前は、XMLがデータ交換の主流フォーマットでした。両方とも現在も使われていますが、用途が異なります：

特徴	JSON	XML
可読性	より簡潔	より冗長
サイズ	30-50%小さい	大きい
データ型	String、Number、Boolean、Null、Array、Object	すべてテキスト
コメント	非対応	対応
スキーマ	JSON Schema	XSD、DTD
主な用途	REST API、設定	SOAP、ドキュメント、RSS
パース	ネイティブのJSON.parse()	XMLパーサーが必要

2026年現在、JSONはWeb開発、API、モバイルアプリケーションで主流です。XMLはレガシーな企業システム、RSS/Atomフィード、DOCXなどのドキュメントフォーマットで使われ続けています。

検証以外にも、これらの補完ツールが作業を効率化します：

• JSON検証ツール：構文チェック、行番号付きのエラー表示、自動フォーマット。
• コード圧縮ツール：スペースや改行を除去してJSONを圧縮。
• Base64エンコーダー：JSONをBase64にエンコードしてURLやHTTPヘッダーで転送。
• テキスト比較ツール：2つのJSONバージョンを比較して差分を検出。

ブラウザで：

• JSON.parse(jsonString) — JSON文字列をJavaScriptオブジェクトに変換。JSONが無効な場合はエラーを投げる。
• JSON.stringify(obj, null, 2) — オブジェクトを整形されたJSONに変換。

構文の検証はJSONが整形式であることだけを確認します。しかし実際のアプリケーションでは、データが正しい構造を持っているかも検証する必要があります。

そのためにJSON Schemaがあります。JSONドキュメントの構造を記述するための標準です：

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "required": ["name", "age", "email"],
  "properties": {
    "name": { "type": "string", "minLength": 1 },
    "age": { "type": "integer", "minimum": 0, "maximum": 150 },
    "email": { "type": "string", "format": "email" }
  }
}

このスキーマを使えば、ユーザーJSONにname（空でない文字列）、age（0から150の整数）、email（有効な形式）があることを自動的に検証できます。Ajv（JavaScript）、jsonschema（Python）、Newtonsoft（.NET）などのライブラリがJSON Schema検証を実装しています。

実際のプロジェクトでよくある問題を避けるためのプラクティス：

• 外部ソースからのJSONは常に検証する：API、ユーザーがアップロードしたファイル、webhookから受け取ったJSONは、処理する前にtry-catch内でJSON.parse()を通す。
• キーにはcamelCaseを使用：JavaScript/TypeScriptの標準的な規約です。user_nameではなくuserName。
• 3-4レベル以上のネストは避ける：深くネストされたJSONは読みにくく、走査しにくく、保守しにくい。
• 暗号化されていないJSONに機密データを保存しない：トークン、パスワード、秘密鍵は、ログやAPI応答の平文JSONに含めてはならない。
• オプションフィールドを省略する代わりにnullを使う：{"middleName": null}はフィールドを省略するよりも良い。
• パースエラーは適切に処理する：JSON.parseの生のエラーをエンドユーザーに表示しない。内部的にログに記録し、分かりやすいメッセージを表示する。