JSON を Markdown にオンラインで無料で変換

オンラインで JSON ファイルを Markdown に無料で変換します。ファイルをアップロードすると、クリーンで LLM 対応の出力が即座に得られます。サインアップなし、ファイルあたり 50 MB、何も保存されません。

JSONをMarkdownに変換する：入れ子のダンプを、目で読める文書にする

JSONは機械のための形式で、人間はそれを我慢して読んでいるにすぎません。ネストが3段までなら問題ない。 しかし8段の深さで、その真ん中に400個のオブジェクトの配列が挟まっていたら、どの閉じ括弧がどれに対応するのかを 探して波括弧の壁をスクロールし続けることになります。生のAPIレスポンスをブラウザのタブで開いたことのある人なら、 あの感覚を知っているはずです。

JSONをMarkdownに変換すると、そのツリーが文書として書き直されます。オブジェクトのキーは見出しに、 入れ子のオブジェクトは入れ子のセクションに。同じ形のレコードの配列は、Ctrl+Fではなく目で走査できる 表になります。上のツールに.jsonファイルをドロップすれば数秒で手に入ります。無料、登録不要、 上限50MB、こちら側には何も残しません。

JSONからMarkdownへ：構造はこう対応づけられる

変換の実体はツリーを上から下へたどる処理で、JSONの各構文はそれぞれMarkdownの構文に対応します。

  • オブジェクトはセクションになる。customerのようなトップレベルのキーは見出しになり、 その配下のすべてがその見出しの下に収まります。深さは見出しレベルになるので、これまでインデントから 推測するしかなかった階層が、ひと目で見えるようになります。
  • スカラーのキーと値はラベル付きの行になる。"status": "active"は status: active と読めるようになります。引用符、コロン、末尾のカンマはすべて消え、 典型的なファイルなら文字数のおよそ3分の1が一緒に消えます。
  • スカラーの配列は箇条書きになる。タグやIDの一覧が、データ構造ではなく 「リスト」に見えるようになります。
  • 同じ形のオブジェクトの配列は表になる。これが最大の見どころで、下に専用の節があります。
  • 空値とnull。null、""、[]が入ったフィールドは ほとんど情報を持たないのに、出現するレコードごとにトークンを消費します。平坦化はそのノイズを 500回繰り返す代わりに畳み込みます。

生のJSONが読み手にとって不便な点は、パーサーにとって便利な点と表裏一体です。すべてのレコードがすべてのキーを 繰り返し宣言する。深くネストしたJSONは、自分の形を記号の陰に隠します。Markdownはその形を表面に引き出します。

同じ形のオブジェクトの配列が理想のケース

JSONが同じキーを共有するレコードの一覧——注文、ユーザー、商品、ログ、検索結果——であれば、最良の結果が 得られます。Markdownの表が1つ、キーが列見出し、レコードが1行ずつ。生のJSONで3,000行を占めていた 200個のオブジェクトが、200行の表に畳み込まれます。

この節約は見た目の話ではありません。生のJSONでは、200個のレコード全部がフィールド名"created_at"を 繰り返し、"customer_id"を繰り返し……と続きます。表なら、各フィールド名の出現はヘッダー行の 1回きりです。コンテキスト上限と戦っているLLMにとって、これはデータセットが収まるか収まらないかの分かれ目に なります。出力の下のトークンカウンターがそれを数字で示してくれます。同じファイルを両方の形式で変換して、 数が落ちるのを見てください。

崩れるのは形の揃っていないレコードの場合です。オブジェクトの半分だけがaddressブロックを 持っていたり、あるフィールド自体が入れ子のオブジェクトだったりすると、平らな表ではきれいに表現できません。 欠けだらけの幅広い表になるか、入れ子の内容が独立したセクションに押し出されます。データが本当に表形式なら、 先にCSVとして書き出して CSVをMarkdownに変換 を使うほうが、たいてい整った表になります。CSVはそもそも形が揃っていないと成立しない形式だからです。

そもそも変換すべきでない場合

ここは正直に書いておく価値があります。変換ツールを売り込むページの多くは書きませんが——LLMは生のJSONを まったく問題なく読めます。学習中に大量に見てきた形式です。何かを変換する義務は、誰にもありません。

正確なキーが重要なら、生のJSONのまま渡してください。APIレスポンスに対するコード——TypeScriptの インターフェース、パーサー、マッピング関数——をモデルに書かせるなら、必要なのはキー名そのもの、ネストそのもの、 型そのものです。Markdownはその一部を意図的にぼかします。生のペイロード、あるいはそれを刈り込んだサンプルを 貼り付けて、モデルに「実際にパースする対象」を見せるのが正解です。

人間が読む工程があるとき、あるいはトークンが逼迫しているときに変換してください。見知らぬAPIが 何を返すのか理解したい。他人の書いた設定ファイルをレビューしたい。大きなエクスポートをモデルに食わせたいが、 生ファイルの4割が記号だ。JSON Markdown変換が働きに見合うのはこうした場面で、それ以外は好みの 問題です。

ミニファイ済み、整形済み、そしてJSON Lines

頻繁に出会う3つの変種は、それぞれ挙動が違います。

  • ミニファイ済みJSON——空白なしの巨大な1行。ほとんどのAPIが実際に返す形式です。 人間には読めず、行の切れ目という手がかりがないぶんモデルにも扱いにくい。変換の恩恵が最も大きいのが ここで、200KBの1行が構造のある文書に変わります。
  • 整形済み（pretty-printed）JSON——すでにインデント済み。読みやすくはなりますが、 そのインデント自体が数千個の先頭スペースとなってトークン代を取ります。Markdownなら空白代を払わずに 階層が手に入ります。
  • NDJSON / JSON Lines——1行に完全なJSONオブジェクトが1つ、外側の配列なし。ログや ストリーミングエクスポートの標準です。性質上つねに形が揃っているので、表出力にはほぼ理想的です。 ファイルが.jsonlや.ndjsonなら、.jsonにリネームするか、 各行を配列で包んでからアップロードしてください。

実務上の注意を1つ。壊れたファイルは変換できません。末尾のカンマ、二重引用符の代わりの一重引用符、 文字列内のエスケープされていない改行、Pythonのエクスポートに紛れ込んだNaN——どれも バリデーションで弾かれます。出どころが怪しいファイルは、先にリンターに通してください。

実際に使われている場面

  • ドキュメントのないAPIの理解。実際のレスポンスを1つ取って変換すれば、レスポンスの形の 読めるアウトラインが手に入ります。たいていのベンダードキュメントより上等で、そのままモデルに リファレンスとして渡せます。
  • 分析データやエクスポートの確認。プロダクト分析ツールから出てきた数千件のイベントが、 実際に質問を投げられる表になります。
  • 設定の監査。Kubernetesのマニフェスト、ESLintの設定、デプロイ設定——Markdownに変換すると、 継承と上書きの関係が、入れ子の波括弧の中では見えなかった形で浮かび上がります。
  • ドキュメント作成。Markdown出力はREADMEにもwikiにもドキュメントサイトにも、 整形し直さずそのまま貼れます。
  • 2つのペイロードの比較。変更前と変更後を変換して、Markdown同士でdiffを取る。 構造の変化は、移動した括弧だらけのJSON diffよりはるかにはっきり見えます。

そのJSONがコードベースの中にあるなら、コードベースごと変換する

ほとんどのJSONファイルは単体では存在していません。package.json、フィクスチャ、シードデータ、 OpenAPIの仕様——それを読むコードの隣、リポジトリの中に置かれています。その1ファイルだけを切り出して変換すると、 モデルにはデータだけが渡り、文脈がまったく渡りません。

その状況なら、代わりに GitHubリポジトリをテキストに変換を使うか、 プロジェクトがどこにもプッシュされていない手元のものなら ローカルフォルダ変換を使ってください。 JSONファイルと、それを読み込むソースファイルの両方にチェックを入れれば、関係の両側を含んだ1つのテキストが 得られます。GitLab版もあります。 開発に関わる用途なら、ほぼ常にこちらが正解です。単体ファイルの変換ツールは、単体でやってきたJSONのための ものです。

よくある質問

JSONをMarkdownに変換するには？

上に.jsonをアップロードすると、Markdownになって返ってきます。入れ子のオブジェクトは見出しレベルに、同じ形のレコードの配列はパイプ表に、キーはラベル付きのフィールドになります。無料、1ファイル50MB、アカウント不要。.mdとしてダウンロードするか、ドキュメント、Issue、プロンプトにコピーしてください。

オブジェクトの配列は表になりますか？

オブジェクトの形が揃っていればなります。それがMarkdownの最も得意なケースです。同じキーを持つレコードの一覧は、キーごとに1列のパイプ表に変換され、生の配列よりはるかに走査しやすくなります。要素ごとにフィールドが異なる不揃いの配列は、共通の列を組み立てられないため、表ではなくセクションに落ちます。

深いネストはどう扱われますか？

ネストは見出しの深さに対応づけられますが、Markdownの見出しは######で打ち止めです。8段ネストした設定ファイルは底を突き、最深部はその上のレベルに畳み込まれます。それほど深い構造ならプレーンテキストでも損はしません。どちらにせよ、読める形で生き残るものはなかったからです。

APIレスポンスのドキュメント化に向いていますか？

実際のペイロードを手作業で整形せずにドキュメントページやプルリクエストへ載せる、最短の方法です。サンプルレスポンスを貼って変換すれば、Markdownが表示できる場所ならどこでも描画されるフィールド表が手に入ります。推測できないのは、どのフィールドが省略可能か、そしてサンプルでたまたま値がnullだったときにその型が何を意味するか、です。

LLMに渡すならJSONをMarkdownに？それともテキストに？

形が意味を持つならMarkdownです。このフィールドはあのオブジェクトに属している、とモデルに理解させたい場合です。埋め込み用にチャンク分割するならテキスト。構文記号はベクトルを薄めるノイズでしかありません。説明してほしいペイロードが1つあるだけなら、Markdownのほうが読みやすく、コストはほとんど変わりません。

Markdownかプレーンテキストか、そしてほかのツール

構造がまったく要らない場合——埋め込みの構築、検索用のインデックス作成、ファイルを可能な限り小さい トークン数まで絞る場合——は、代わりに JSONをプレーンテキストに変換 を選んでください。構文を翻訳するのではなく、まるごと剥ぎ取ります。ページ上部の形式切り替えで両者を 行き来でき、選択済みのファイルも引き継がれるので、2回アップロードせずに両方試せます。

ほかの構造化形式については、XMLを Markdownに変換がフィード、SOAPペイロード、エンタープライズのスキーマを、 HTMLをMarkdownに変換が 保存したWebページを扱います。ページを選ぶのが面倒なら File2Txtが総合窓口で、 PDF、Officeファイル、画像、アーカイブも受け付けます。より広い背景は LLM向けに ファイルを整える方法のガイドにまとまっています。

Repo2Txtを開発・運営しているのは v12hero、 プライバシー最優先のネイティブアプリとWebアプリを作る独立系デベロッパーです。