よくあるJSON構文エラーの特定と修正方法：RFC 8259準拠ガイド
1. 構文バリデーション、JSON Schema、ビジネスルールの明確な違い
エンジニアの間で頻繁に見られる誤解の一つに、あらゆるJSONの検証作業を単一の処理として混同してしまう点があります。実際のシステム設計においては、以下の3つの独立した検証レイヤーが明確に区別されます。
- RFC 8259 構文バリデーション（Syntax Validation）：入力データがJSONの字句文法に厳格に合致しているかを判定します。中括弧・角括弧の対応、ダブルクォートで囲まれたキーと文字列、カンマによる要素区切り、正当なプリミティブリテラル（文字列、数値、真偽値、null）が対象です。クォートや括弧が一つでも不足していれば、そもそも有効なJSONデータとして成立しません。
- JSON Schema バリデーション：構文的に正しいJSONが、あらかじめ定義されたデータ仕様（
$schema定義、各プロパティの型、必須フィールド、配列長の境界値など）を満たしているかを検証します。構文上は完全に正しくても、スキーマ違反となるケースは日常的に発生します。 - ビジネスルールバリデーション（Business Rules）：アプリケーション固有のドメイン要件（例：口座残高が負の値にならないこと、終了日時が開始日時より未来であることなど）を精査します。構文パーサーや汎用スキーマでは、ドメイン論理の正当性までは保証できません。
GoToolstackのJSONツールが担う役割は、厳格なRFC 8259構文チェックとAST（抽象構文木）に基づくコード整形です。JSON Schemaの評価やアプリケーション業務ルールの判定機能は備えていません。
2. フォーマット処理は自動修復機能ではありません
JSONフォーマッター（整形・圧縮ツール）は、すでに構文的に成立しているASTに対してインデント、改行、空白文字を整然と再配置する機構です。破損したデータを自動的に推測・修復するエンジンではありません。
構文の崩れた文字列を入力した場合、エンジンは最初に現れた無効バイトの位置で処理を直ちに中断し、エラー位置と周辺文字列を含む診断情報（例：Trailing comma in object is not allowed at position 45）を明確に表示して出力欄を空にします。開発者の意図を勝手に解釈して括弧を補ったり、不正な末尾カンマを勝手に除去したり、シングルクォートを自動置換することはありません。フォーマットを完了するには、ソースデータ側の手動修正が必要です。
3. 頻発する5大JSON構文エラーと診断メッセージ
エラー1: 末尾の不要なカンマ（Trailing Comma）
× 不正な記述：
{
"name": "GoToolstack",
"active": true,
}エンジン診断メッセージ：Trailing comma in object is not allowed at position 45 (near "active": true,
}")
✓ 正しい修正方法：RFC 8259において、カンマは「区切り文字」であり終端文字ではありません。末尾の閉じ括弧 } や ] の直前にある最後のカンマを削除してください。
エラー2: ダブルクォートの代わりにシングルクォートを使用
× 不正な記述：
{'status': 'success'}エンジン診断メッセージ：Expected string key in object at position 1 (near "{'status': 'success'}")
✓ 正しい修正方法：JavaScriptのオブジェクト記法ではシングルクォートが許容されますが、RFC 8259第7条ではすべてのキーおよび文字列値に対して必ずダブルクォート（"）を使用することが義務付けられています（{"status": "success"}）。
エラー3: クォートされていないオブジェクトキー（Unquoted Keys）
× 不正な記述：
{count: 42}エンジン診断メッセージ：Expected string key in object at position 1 (near "{count: 42}")
✓ 正しい修正方法：JavaScriptのオブジェクトリテラルとは異なり、JSONではすべてのプロパティ名を必ずダブルクォートで囲む必要があります（{"count": 42}）。
エラー4: 不正なエスケープシーケンスと未エスケープのバックスラッシュ
× 不正な記述：
{"path": "C:\programs\data.json"}エンジン診断メッセージ：Invalid escape sequence \p at position 13 (near "{"path": "C:\programs"}")
✓ 正しい修正方法：RFC 8259で定義されているエスケープ文字は "、\\、/、、 、
、
、 、および4桁の16進数ユニコードシーケンス \uXXXX のみです。Windowsのファイルパスなどに含まれるバックスラッシュは、2重にエスケープしてください：{"path": "C:\\programs\\data.json"}。
エラー5: JSON本文内のコメント記述
× 不正な記述：
// サーバー設定項目
{"port": 8080}エンジン診断メッセージ：Unexpected token '/' at position 0 (near "// サーバー設定項目")
✓ 正しい修正方法：標準のJSON仕様にはコメント記法（// や /* */）が一切存在しません。通信や解析に渡す前に、コメント記述を完全に削除してください。
4. 64ビット整数の精度欠損トラップ：ロスレストークン保持と受信側システムの制限
標準的なJavaScript環境では、数値データはすべてIEEE 754倍精度64ビット浮動小数点数として処理されます。安全に表現可能な整数の上限は次の通りです。
Number.MAX_SAFE_INTEGER = 9,007,199,254,740,991 (2^53 - 1)Web APIがデータベースの主キーやTwitter ID、ブロックチェーンのトランザクション番号などとして大きな64ビット整数（例：9007199254740993）を返却した場合、標準の JSON.parse() を実行するとエラーを出すことなく自動的に 9007199254740992 へ丸められ、データ破損が生じます。
GoToolstackのJSONエンジンは、数値をAST上で文字列トークンとしてそのまま保持するカスタム・ロスレスパーサーを搭載しています。そのため、本ツール内での整形出力時は元の全桁が確実に維持されます。ただし、この保持動作は受信側システムの安全までを保証するものではありません。整形後のJSONを受け取った後続のマイクロサービスやDBドライバ、外部フロントエンドが標準のfloat64パーサーで解析すれば、その時点で再び丸め誤差が発生します。分散システムでは、大きな64ビット整数IDを文字列型（例："9007199254740993"）として設計・通信することが推奨されます。
5. 重複するオブジェクトキーとRFC 8259における解釈のあいまいさ
同一オブジェクト内に同名のキーが複数記述された構造を考えてみます。
{"user": "alice", "user": "bob"}GoToolstackのASTパーサーは、各キーと値のペアを記述された順序通りにすべて保持し、事前の値を勝手に削除することはありません。しかし、RFC 8259第4条では、重複キーに対するパーサーの振る舞いが実装によって異なることが明確に指摘されています。
- 最初のキーのみを採用し、以降の重複を単に無視するパーサーが存在します。
- 一般的な言語標準ライブラリ（JSの
JSON.parse()やPythonのjson.loads()など）の多くは、後勝ちで値を上書きし、最後のキーのみを残します。 - 厳格なパーサーでは、重複キーを検出した瞬間に構文エラーとしてドキュメント全体を破棄します。
GoToolstackが整形出力で重複キーを維持するからといって、後続システムが同一の解釈を行う保証はありません。本番運用のJSONデータでは、すべてのキーを一意に保つ必要があります。
6. ツールの技術的制限事項と処理境界
ブラウザメモリ上限と大規模データ：50MBを超える大容量の圧縮JSONを整形する場合、DOMテキストエリアの再描画処理に伴い、ブラウザのメインUIスレッドが一瞬フリーズする可能性があります。数ギガバイト規模のログ解析には、jq などのストリーミングCLIツールの利用を推奨します。
- ツリービューおよびスキーマ検証の非搭載：本ツールは軽量かつ即応性を重視した2ペインのプレーンテキストエディタと診断メッセージを提供します。折りたたみ式DOMツリービューアやJSON Schemaの検証機能は含みません。
- 使用禁止値：
NaN、Infinity、-InfinityはRFC 8259で認可されていません。JavaScriptのundefined、関数、循環参照構造を持つオブジェクトもJSONへシリアライズできません。 - クライアント側でのローカル完結：すべての字句解析およびAST整形はユーザーのブラウザメモリ内でのみ実行されます。入力データが外部サーバーへ送信されることは一切ありません。
