JSONのツリー表示 vs テーブル表示：本当に素早くデバッグできるのはどっちか

ほとんどのJSONビューアーは、ツリー表示（入れ子構造で折りたたみ可能、1行に1つの値）とテーブル表示（行と列、表計算ソフトのような形式）のどちらかを選べるようになっている。同じデータの見た目が違うだけに見えるので、ツールが最初に開いた方をそのまま使いたくなる。だがその判断は間違っている——この2つのビューは実際にはデータの形とデバッグ作業の種類によって使い分けるべきものであり、選び間違えると本当に時間を無駄にする。

それぞれのビューが本当に得意なこと

ツリー表示はJSONの実際の構造をそのまま反映する：すべてのオブジェクトと配列は折りたたみ可能なノードになり、末端の値はそれぞれキーと一緒に独立した行に並ぶ。次のような場合に向いている：

構造そのものをデバッグしている場合——深く入れ子になったオブジェクトのどこに値があるかを探したり、そもそもあるフィールドが存在するかを確認したりしたいとき。
データが不規則な場合——同じレスポンス内でもオブジェクトによって持っているキーの集合が違ったり、任意フィールドがあったり、入れ子の深さがまちまちだったりする。こうした状態はテーブルではきれいに表現できないが、ツリーならできる。
親子関係を明示的に確認する必要がある場合——ある特定のオブジェクトがどの配列に属しているかを追跡するときなど。

テーブル表示はオブジェクトの配列を行と列に平坦化し、キーごとに1列を割り当てる。次のような場合に有利になる：

形が揃ったオブジェクトの配列がある場合——ユーザー一覧、注文一覧、ログエントリーなど、全部が同じ形をしているデータ。
外れ値を探している場合——数値のはずの場所にnullが入っている、列挙値にタイプミスがある、1行だけフィールドが欠けている、といったケース。テーブルは目が列を上から下へたどれるので外れ値が視覚的にすぐわかるが、ツリー表示だと同じ異常がそれぞれ個別に展開された何十ものノードの中に埋もれてしまう。
表計算ソフトに近い感覚が欲しい場合——並べ替えたり、どの行が同じ値を共有しているかを一目で把握したりしたいとき。

ビューを選び間違えたときの具体的な失敗

深く入れ子になったAPIレスポンス（セッションオブジェクトの中にユーザーオブジェクト、その中に認証トークン）をテーブル表示で開くと、ほとんどのセルが単に[Object]や[Array]とだけ表示されるテーブルになる——平坦化する先が入れ子構造にはないため、意味のないプレースホルダーに潰れてしまい、結局そこをクリックして中を見る必要が出てくる。これは最初からツリー表示で開くより明らかに悪い結果だ。

ほぼ同じ内容のログエントリーが200行並んだ配列をツリー表示で開くと、200個の個別に折りたたまれたノードができ、statusが思いがけずnullになっている1行を見つけるために1つずつ開いていくしかない——テーブルなら2秒で終わる確認が、ツリーでは何分もクリックを繰り返すことになる。

シンプルな判断基準

まず自分に問いかけてみる：気になっている違いは「兄弟同士の間」で起きているのか、それとも「深さ方向」で起きているのか？

似たような要素を大量に互いに比較しているなら（兄弟同士）——テーブル表示を使う。
入れ子構造をたどって値を追いかけているなら（深さ方向）——ツリー表示を使う。

日常的なJSONのデバッグ——主にデータが読みやすく、構文的に正しいことを確認したいだけの場合、インデントを確認する、括弧の対応を確認する、余分なカンマを見つける、といった作業では、どちらのビューも厳密には必要ない。正しくインデントされ整形された元のJSON（JSONフォーマッターが出してくれるもの）は、ほとんどのちょっとした確認作業には十分なほど構造を明確に示してくれるし、ビューアーを特定のモードに切り替えるより速く手に入る。ツリー表示やテーブル表示に頼るべきなのは、データが大きすぎる、あるいは入れ子が深すぎて、上から下へ単純に読むだけでは対応できない場合だけだ。