ブラウザをクラッシュさせずに巨大なJSONファイルを表示する方法

50MBのAPIダンプやデータベースの完全なエクスポートデータを、どのブラウザベースのJSONツール（本ツールも含む）に貼り付けても、タブの動作が遅くなったり、完全にフリーズしたりします。これは特定のツールのバグではなく、ブラウザがテキストやDOMをレンダリングする方法に起因する特性です。ここでは、実際に何が起きているのか、そしてその回避策について説明します。

大きなJSONファイルがブラウザを「読み込みが遅い」だけでなく「フリーズ」させる理由

2つの異なるコストが積み重なっています：

解析にかかる負荷。 JSON.parse が、形式が正しい50MBの文字列を解析する場合、一般的なノートPCでは約0.5秒から数秒かかります。これは確かに目立ちますが、本当の問題ではありません。
レンダリングにかかる負荷。 これこそが実際にタブをフリーズさせる原因です。ツールがフォーマット済みの結果を巨大なテキストブロック（あるいはさらに悪いことに、キーごとにDOMノードを持つ折りたたみ可能なツリー）としてレンダリングする場合、ブラウザは潜在的に数百万ものDOMノードのレイアウトと描画を行わなければなりません。タブが応答しなくなる原因は、解析ではなくこれなのです。

したがって、サイズ制限に引っかかる原因は、JSON仕様やパーサーによるものではなく、ブラウザに膨大な量のテキストやネストされたUIを一度に描画させようとしていることにあります。

本当に大きなファイルに対する実際のワークフロー

ブラウザ上でファイル全体を開かないでください。 代わりに：

まず必要な部分のみを抽出する。 200MBのダンプデータ内の1つの破損したレコードをデバッグする場合、残りの199MBを画面に表示する必要はありません。コマンドラインツールなら、ブラウザのタブのようにファイル全体をメモリに読み込むことなく、これを処理できます：

# pull out one top-level key from a huge file, streaming
jq '.results[42]' huge-file.json > fragment.json

# or just grep for context around a known string first
grep -n '"user_id": 88214' huge-file.json

ブラウザではその断片のみをフォーマットします。 数KBの抽出済みJSONは瞬時にフォーマットされ、実際に読み取ることができます。これは、この特定のエラーに限らず、あらゆる大規模なログやダンプに対して身につける価値のある「関心のある断片のみをフォーマットする」という習慣です。
値ではなく構造を確認する必要がある場合、まずローカルで jq 'keys' または jq '. | length' を実行して形状を把握し、その後何を抽出するかを決定してください。配列に50,000個のエントリがあることを知るために、50,000個のエントリをすべて確認する必要はありません。

ブラウザツールが本当に適している場合

実際のデバッグの大部分 — API レスポンス、設定ファイル、Webhook のペイロードなど — では、扱うデータサイズは数百キロバイトではなく、キロバイトから数メガバイト程度です。この範囲であれば、フォーマッタに直接貼り付けて、正確なエラー位置を含む読みやすい出力を即座に得る方が、コマンドラインを使うよりもはるかに速いです。この方法が通用しなくなるサイズは、多くの人が想定しているよりもはるかに大きく、実際に問題を引き起こすのは「1ページ分以上」ではなく、具体的には「数十メガバイト以上」です。

クイックリファレンス

ファイルサイズ	対処法
5MB未満	ブラウザのフォーマッタに直接貼り付ける — 瞬時に処理され、問題なし
5～30MB	まだ処理可能だが、少し時間がかかる；読む必要のある部分のみをフォーマットする
30MB以上	まず `jq` / `grep` で関連する部分のみを抽出し、その部分のみをフォーマットする

この問題を解決するために、ツールに「大容量ファイルモード」は必要ありません。解決策は、表示する前にデータを抽出することであり、これはワークフローの変更であり、ツールの制限ではありません。