03 / ガイド
レビュー前に JSON を整形して検査する
API ペイロードや設定ファイルのためのレビュー手順:まず整形し、構造をツリーで検査し、2 つのドキュメントを決定的に比較する——データをどこにも送らずに。
なぜ整形が最初なのか
ミニファイされた JSON は機械のためのものです。1 行、インデントなし、キーの順序はシリアライザ次第。その壁を目でレビューさせると、削除された権限、反転したフラグ、予期しないエンドポイントがすり抜けます。
整形は手元にある最も安価な妥当性チェックでもあります。パースに失敗するドキュメントは本番でも動かなかったはずで、それをレビュータブで知るほうがデプロイログで知るよりはるかにましです。
- 可読性のみ整形は可読性の変換です。空白と改行だけを変え、データは決して変えないため、整形済みコピーは常に原本と安全に照合できます。
- 深さはシグナル一貫したインデントはネストの深さを一目で示します。設定ミスは深さに潜むもので、1 段深く置かれたオプションは単純に無視されます。
- 期待される形で出荷レビューするのは整形済みコピー、出荷するのはシステムが期待する形です。整形は人間のためで、通信のためではありません。
テキストだけでなくツリーを検査する
ツリービューは、レビューアが実際に聞きたい質問——どんなキーがあるか、各値の型は何か、構造はどれくらい深いか——に括弧を数えずに答えます。生テキストはどれにも素早く答えられません。
JSON Tree Viewer は明示的にパースします。Parse JSON を押すまで何も描画されず、不正な入力には静かに失敗するのではなく、位置付きのエラーと修復ヒントが返ります。結果はノードごとの型と件数付きの展開可能なツリーとして開き、Formatted タブには選択したインデントで正規化されたドキュメントが表示されます。
パースのサマリはノード数と最大深度を報告し、ペイロードが持つべき規模との手早い健全性チェックになります。予約されたプロトタイプキーは拒否されるため、悪意あるペイロードが検査中に無害を装うことはできません。
ツリーはレビューの会話も平らにします。「items の 3 番目の要素の price が null」は誰でも数秒で検証できるコメントですが、ミニファイ行のバイトオフセットは違います。
JSON Tree Viewer を開く2 つのドキュメントを決定的に diff する
キーの順序が変わった時点で、目視による 2 つの JSON の比較は破綻します。構造的な diff は両側をパースし、実際に変わった部分——追加、削除、変更された値——を順序や空白に関係なく報告します。
Text & JSON Diff には行・文字・JSON の 3 つのモードがあります。レビューで決定的なのは JSON モードです。両方のドキュメントがパースされてから値ごとに比較されるため、並べ替えられたキーや再整形された空白は、正しく「同一」と報告されます。
JSON 以外のテキストには、行モードと文字モードに空白無視と改行コード正規化のトグルがあり、サマリは追加・削除・変更をカウントします。ペイロードと設定には JSON モードを。片側がそもそも有効な JSON でない場合は行モードに切り替えてください。
決定性は便利さ以上の意味を持ちます。2 人のレビューアが同じ比較を実行したら同じ答えが得られなければなりません。さもなければレビューは変更についての判断ではなく、ツールについての交渉になってしまいます。
Text & JSON Diff を開くローカルランタイムの制限を知る
これらは明示的な上限を持つローカルランタイムで、バルクデータ処理ではなくレビュー用ペイロード向けのサイズです。上限を知れば、デスクトップツールに切り替えるべきタイミングがわかります。
上限があるのは、パースと diff があなたが読んでいるのと同じタブで動くからです。正直な上限はフリーズしたページよりましで、ワークスペースは超過を暗黙の切り捨てではなく明示的なエラーとして報告します。
- ビューアの上限JSON Tree Viewer は最大 256 KiB の入力、40 段のネスト、10,000 ノードまで受け付けます。API レスポンスや設定ファイルには十分です。
- diff の上限Text & JSON Diff は片側 256 KiB まで比較し、最大 10,000 件の差分レコードを報告し、それを超えると比較が複雑すぎると宣言します。
- ブラウザの外それより大きなエクスポート——データベースダンプ、ログアーカイブ、生成フィクスチャ——はブラウザタブではなくデスクトップエディタやコマンドラインツールの領分です。
5 分のレビューチェックリスト
ほとんどのペイロードの問題を本番到達前に拾う短い手順です。
本物のペイロードだけでなく、プロデューサのサンプルデータにもチェックリストを回してください。現実と食い違うフィクスチャは、バグと同じくらい確実にレビューを無効化します。
- パースまず整形してパース:ドキュメントが有効であることを確認し、ノード数と深度が期待どおりか一目見ます。
- 検査ツリーを検査:葉の型を確認します。数値の識別子が文字列で届くのは、典型的な統合バグです。
- diff最後の既知良好バージョンと JSON モードで diff し、報告された変更をすべて読んでから承認します。
ペイロードをデバイスに留める
レビュー用ペイロードには顧客レコード、トークン、内部 URL が含まれることがよくあります。ローカルビューアはその素材をタブに留めます。テキストはデバイス上で動くコードによってパースされ、操作の一部として送信されることはありません。
この境界があるからこそ、レビュー中に実際のステージングペイロードをこれらのツールで扱えます。ただし自分の責任まで消えるわけではありません。書き出したファイル、クリップボードの内容、ツリーのスクリーンショットは、ワークスペースを離れた後も慎重に扱うべきものです。
レビューでペイロードの断片を共有しなければならない場合は、問題を示す最小の抜粋だけを貼り、先に識別子を伏せてください。サポートチャネルが求めるのと同じ作法です。
「ローカル検査」が信頼できる主張である理由。
ブラウザランタイムがデータをデバイスに留める仕組みと、レビューに使う任意のツールのデータ経路を検証する方法。