JSON修復の実践：エラー位置から信頼できるデータまで

APIログ、JavaScriptからコピーしたオブジェクト、手作業で編集された設定ファイルは、JSONに見えても有効なJSONではないことがあります。修復の目的は、単にパーサーのエラーを消すことではありません。業務上の意味を変えずに、検証でき、再現でき、信頼できるデータにすることです。

1. 元の入力を保存する

唯一のコピーを上書きしないでください。まず元のテキスト、取得元、時刻、リクエストIDを保存します。ログにはトークン、メールアドレス、内部URLが含まれる場合があります。ツールに貼り付ける前に、不要な機密フィールドを削除してください。元の入力が残っていれば、修復後の変更が意味を変えていないか確認できます。

2. 最初のエラーから直す

よくある破損には、シングルクォート、プロパティ間のカンマ抜け、True や None のような非JSONリテラル、末尾カンマがあります。パーサーは通常、処理を続けられなくなった最初の位置を報告します。そのため、文書全体を勘で一括修正しないでください。文字列とキーをダブルクォートにする、足りないカンマを補う、真偽値と null を標準の小文字にする、末尾カンマを削除する、という順で進めます。

候補を JSON修復ツール に入れ、出力を JSON検証ツール で再確認できます。

3. コメントを単純置換で消さない

// とブロックコメントはJavaScript構文であり、標準JSONではありません。ただし、同じ文字列はURLなどの文字列内にも現れます。信頼できる修復処理は、まず文字列境界を認識してから本物のコメントだけを処理します。コメントが業務上の説明を持つ場合は、静かに削除せず、ドキュメントや明示的なフィールドへ移してください。

4. 途中で切れたデータは安全に推測できない

ネットワーク切断により、配列の途中や未完了のフィールドだけが残ることがあります。ツールは括弧を補えますが、失われたID、オブジェクト、配列要素は知りません。構文が有効になっても、データが完全だとは限りません。元データを再取得するか、不完全なレコードとして扱うべきです。

重複キー、先頭ゼロ、大きすぎる整数、日付文字列、NaN、Infinity も人の判断が必要です。パーサーによって重複キーの扱いが異なる場合があり、JavaScriptの安全整数を超える識別子は通常文字列で渡すべきです。

5. 4層で検証する

まず、ブラウザとバックエンドの両方で解析できるか確認します。次に、ルート型、必須フィールド、値の型を確認します。さらに JSON Diff で修復前後を比較し、金額、権限、状態、IDを重点的に見ます。最後に、壊れたサンプルを回帰テストへ追加し、同じ問題が戻らないようにします。

まとめ

信頼できるJSON修復は、元文を保存し、最初のエラーを直し、変更を記録し、再検証し、業務上の意味を確認する流れで進めます。自動ツールは句読点、引用符、コメント、標準リテラルの問題に有効ですが、欠落データや契約ルールの判断までは代替できません。