作業メモ
JSON差分を見る前に整えるポイント
JSON差分は、整形や型の前提がずれていると変更点が多く見えます。まず構文と見た目を整え、次に値の意味を分けて確認します。
ページ更新日:
構文エラーと意味の差分を分ける
差分ツールへ貼る前に、JSONとして読めるか、比較したい単位が合っているかを確認します。
キー順だけでは差分にしない
オブジェクトのキー順が違うだけなら、変更点として扱うべきかを先に決めます。
配列順は意味を持つことがある
配列の並び替えは、同じ要素でも差分として出るため、比較前に順序の意味を確認します。
次にやること
1. まずJSONとして読める状態にする
コメント、末尾カンマ、引用符抜けなどを先に切り分けます。
- JSON整形
構文エラーの有無と整形結果を確認します。
- JSONLバリデーター
ログが1行1JSON形式ならこちらで行単位に見ます。
2. 比較したい範囲を絞る
レスポンス全体ではなく、必要な配列やオブジェクトだけを取り出して確認します。
- JSONPath・JMESPathテスター
比較対象の値や配列を抽出します。
- JSON→CSV
表として比較したい配列をCSVへ変換します。
3. 差分を見て変更の種類を分ける
追加、削除、変更を分け、型や配列順の差を確認します。
詰まりやすい場面
- APIレスポンスの変更点を見たいが、差分が多すぎるとき
- null、空文字、数値と文字列の違いを見落としたくないとき
- 設定ファイルの変更レビュー前に、整形と比較順をそろえたいとき
具体例と判断基準
よくある失敗例
整形差を値の差とみなす
空白・改行・オブジェクトキー順だけの差は、構文解析後の比較で切り分けます。
数値1と文字列"1"を同じにする
表示が似ていても型が違います。APIや設定では異常差分になり得ます。
nullとキー欠落を同じにする
明示的nullと存在しないキーは受け手の挙動が異なる場合があるため別差分として確認します。
入力・作業サンプル
比較例
旧 `{"count":1,"memo":null}` と新 `{"count":"1"}` では、countの型変更とmemo削除を別々に記録します。
差分分類
期待: version追加。要確認: 型変更。異常: 必須キー欠落。ノイズ: 比較前に除外すると合意したrequestIdや時刻。
before
生ログ全体をテキスト差分し、時刻・順序・空白の差に埋もれて重要な値変更が見えない。
after
比較対象を同じレスポンス単位へ切り出し、両方を構文検証し、期待差分と異常差分をJSONパスで分類する。
この順番で見る理由
両入力が有効なJSONか、同じ対象・環境かを先に確認しないと、パーサーエラーや別データの差を仕様変更と誤認するためです。
迷ったときの判断基準
配列順を意味ありとする
順序がAPI契約や表示順に影響するなら、そのまま差分として扱います。
順序を別検証する
集合として扱う配列なら、識別キーで並べ替えた派生版を比較し、元順序も保存します。
関連ツールを使う流れ
- 構文: JSON整形で左右の構文エラーを先に直します。
- 差分: JSON差分比較で追加・削除・変更パスを出します。
- 抽出: 必要ならJSONPath/JMESPathで注目箇所だけを再確認します。
見た目の整形より、型・欠落・配列順・値の意味を優先して確認してください。
作業を止めて確認する条件
- 左右が別環境・別レコードで比較条件がそろわない
- 片方が構文エラー
- 配列順・null・欠落の期待仕様が不明
ツールを使わない判断
JSON Schema、契約テスト、スナップショットテストがありCIで検証できる場合は、それを合否の正本にし、画面差分は原因調査に使います。
対象外: スキーマ適合性、配列要素の意味的同一性、アプリケーション動作の保証。
最終チェックリスト
- 左右が同じ対象・条件のJSONである
- 両方の構文が有効である
- 数値/文字列、null/欠落、配列順を別々に確認した
- 期待差分と異常差分をパス付きで記録した
まず開くツール
各段階で最初に開くものだけを並べています。
必要なら見るページ
用語や周辺ツールが必要なときだけ使います。
- データ変換・開発カテゴリ
JSON、CSV、抽出、ハッシュなどの周辺ツールを見たいとき。