Json To Csv LogoJson To Csv

JSONファイルとCSVファイルとは?初心者のための両形式ガイド(2026年版)

JSONとCSVはどちらもプレーンテキストですが、データの持ち方はまったく違います。このガイドでは同じデータを両形式で並べて示し、本当に重要な5つの違いを解説し、JSONからCSVへの変換で何が残り何が静かに消えるのかを検証します。

更新日: 2026-10-219 分で読めます

JSONファイルとCSVファイルとは?まずJSONの見た目から

こちらは本物のJSONファイルです。顧客レコードが2件入っています。このガイドのすべての概念はこのファイルに立ち返りますので、最初に一度ゆっくり目を通してください。角括弧や引用符に慣れていなくても大丈夫です。1つずつ分解していきます。JSONファイルは拡張子が.jsonのプレーンテキストなので、メモ帳でもVS Codeでも、そのまま開いて中身を読めます。

ファイル全体は角括弧[ ]で囲まれた配列で、その中に2つのオブジェクトが入っています。波括弧{ }で囲まれた各オブジェクトが、1件のレコードです。オブジェクトの中では、データがキーと値のペアで保持されます。"id": 101は、キー"id"が値101を持っているという意味です。キーはいつも引用符で囲まれた文字列になります。この「キーが必ず文字列」という約束が、JSONを読むときの最初の手がかりです。

値の型が保たれること。これがJSONの大きな強みの1つです。"Amelia Chen"は文字列です(テキストで、引用符付き)。101、2023、4は数値です(引用符なし)。trueとfalseは真偽値です。nullは「ここには値がない」という明示的な表現で、空の文字列とは違います。AmeliaのlastNoteはnullです。フィールドは存在するけれど値がない状態です。一方BrunoのlastNoteには、電話をかけてほしいという内容のテキストが入っています。プログラムがこのファイルを読み込むとき、数値は数値として計算でき、真偽値は条件分岐に使え、nullは「未記入」として区別できます。型があるから、データはただの文字の羅列ではなく、意味を持ったまま受け渡しできるのです。ちなみに、フィールド自体が存在しない場合とnullの場合も区別されます。キーがなければ「その項目はこのレコードにはない」、nullなら「項目はあるが値は未定」という違いで、APIの仕様を読むときの重要な手がかりになります。

そしてネスト、つまり入れ子構造こそ、JSONが存在する理由です。"address"は顧客オブジェクトの中にあるオブジェクトで、cityとstateという独自のキーを持ちます。"tags"は顧客オブジェクトの中にある配列で、2つの文字列を保持しています。JSONは任意の深さまでネストできます。オブジェクトの中の配列の中のオブジェクト、データが続く限りどこまでもです。空白は無意味なので、上の見やすく整形した版と1行に詰めたミニファイ版は、同じデータです。覚えておきたい癖が1つあります。1つのオブジェクトの中に同じキーが2回出てくると、最後の値が勝って最初の値は警告なく消えます。ビルドマシンでJSON.parseを使って検証したところ、{"a":1,"a":2}は2と解析されました。実際にはめったに起きませんが、起きたときは何も警告してくれないので、一度だけ知っておいてください。

customers.json:2件のレコード、ネストあり
[
  {
    "id": 101,
    "name": "Amelia Chen",
    "email": "amelia@example.com",
    "vip": true,
    "signupYear": 2023,
    "address": { "city": "Austin", "state": "TX" },
    "orders": 4,
    "tags": ["newsletter", "referral"],
    "lastNote": null
  },
  {
    "id": 102,
    "name": "Bruno Almeida",
    "email": "bruno@example.com",
    "vip": false,
    "signupYear": 2024,
    "address": { "city": "São Paulo", "state": "SP" },
    "orders": 1,
    "tags": ["newsletter"],
    "lastNote": "Call, don't email"
  }
]

JSONファイルとCSVファイルとは?次にCSVの見た目

では、同じ2件のレコードをCSVにしたものを見てみましょう。この出力は、このページのコンバーターが上のJSONから生成したものです。フラット化をオンにしています。つまり見えているのは、変換が実際に行う処理そのもので、都合よく作ったイメージ図ではありません。

最初の行はヘッダー行、つまり列名の行です。それ以降の各行が1件のレコードで、値が同じ順序でカンマ区切りで並びます。形式はこれだけです。ヘッダー、行、区切り文字。10列、2行。ネストはどこにもありません。表計算ソフトで開けば、そのまま表として表示されます。

すべてがテキストになったこと。これがCSVを特徴づける性質です。101、true、2023は数値や真偽値のように見えますが、ファイル自体はそれを知りません。ただの文字の並びです。開く側のソフトがどう解釈するかを決めます。Ameliaの行の末尾にある空のセルは、nullだったlastNoteです。nullは「何もない」セルになりました。2つのタグは1つのセルにまとまり、"newsletter; referral"としてセミコロンとスペースで結合されています。Brunoのメモは引用符で囲まれています。中にカンマが含まれているからです。区切り文字を含む値を壊さず守る方法が、引用符なのです。これがCSVのクォートのルールです。さらに、引用符で囲まれた値の中に引用符そのものが出てくる場合は、引用符を2つ重ねて表現します。He said "hi"という値は"He said ""hi"""と書かれます。この二重化ルールを知っていると、CSVの壊れたように見える行の多くが読み解けるようになります。

addressオブジェクトは2つの列、address.cityとaddress.stateになりました。このドット記法でのフラット化こそ、コンバーターが行う処理そのものです。フラット化トグルの裏側については、専用のガイドで詳しく解説しています。CSVがもう言えなくなったことに注目してください。cityとstateが1つのaddressオブジェクトに属していたこと。newsletterとreferralが2つの別々のタグであって、セミコロン入りの1つの文字列ではなかったこと。形状は消えました。値は残っています。この「値は残るが形状は消える」という感覚が、このガイドの核心です。

同じ2件のレコードをCSV化(変換エンジンの検証済み出力)
id,name,email,vip,signupYear,address.city,address.state,orders,tags,lastNote
101,Amelia Chen,amelia@example.com,true,2023,Austin,TX,4,newsletter; referral,
102,Bruno Almeida,bruno@example.com,false,2024,São Paulo,SP,1,newsletter,"Call, don't email"

JSONファイルとCSVファイルとは?本質的な5つの違い

同じデータ、2つの哲学です。どちらの形式を使うかを決める5つの違いがあります。これを押さえれば、「どちらを使うべきか」という議論のほとんどは自分で判断できるようになります。

第1に、形状です。JSONはツリー、CSVはテーブルです。JSONは、注文の中に顧客、その中に住所、その中に商品のリストというように、現実の深さまでネストできます。CSVにある階層は1つだけです。行と列だけです。それより深いものは、ドット記法の列にフラット化するか、テキストとして1つのセルにシリアライズするしかありません。どちらの方法でも、元の構造は実質的にそこにはもうありません。データに階層があるかどうかが、最初の分岐点です。

第2に、型です。JSONは数値の2023とテキストの"2023"を区別し、真偽値のtrueと文字列の"true"を区別します。CSVが保持するのは文字だけで、解釈は後から、ファイルを開く側が行います。だから文字列の"007"はCSVでは文字007のまま届きます(このページのコンバーターで検証済み)。それでも表計算ソフトで開くと7と表示されることがあります。CSVはテキストを忠実に保持しました。その上でExcelが独自の推測を加えたのです。形式は仕事を果たしました。意見を加えたのはビューアーです。型が重要なデータ、たとえば商品コードや電話番号の先頭のゼロを扱うときは、この違いが実務に直結します。郵便番号の先頭の0が消えて困った経験がある方は、まさにこの型の落とし穴に当たっています。CSVで受け渡す場合は、開く前に列の書式を「文字列」にしておくのが定番の対策です。

第3に、スキーマです。JSONは自己記述的です。各レコードが自分のキーを持っているので、レコードごとに違っていても構いません。1人の顧客だけが他の顧客にはない"notes"フィールドを持っていても、ファイルは完全に有効です。CSVのスキーマはヘッダー行にあり、均一性を前提とします。余分な値を持つ行には、文書化された置き場所がありません。行ごとにフィールドが違う不揃いなデータは、JSONでは何の問題にもなりませんが、CSVでは列の整合性パズルになります。ヘッダー行は、CSVにおける列の契約書のようなものです。受け手はこの1行を頼りに各列の意味を判断するので、列の順序や名前が変わると、連携先の取り込み処理が壊れることがあります。

第4に、手編集です。JSONは小さなミスを大きな声で咎めます。カンマや引用符が1つ欠けただけで、ファイル全体が無効になります。面倒ですが正直です。だからJSONバリデーターという道具が存在します。CSVは小さなミスを静かに咎めます。値の中に引用符なしのカンマが1つ混ざると、それ以降の列がすべてずれるのに、ファイルは開きます。ただし間違った内容で開きます。手で編集するなら、静かな破損より、大きな声で失敗してくれるほうが安全です。

第5に、作り手です。形式は作り手に従います。API、アプリ、データベース、ログがJSONを出すのは、型付きのネスト構造で物事を考える世界だからです。表計算ソフト、業務用のエクスポート、メールの添付ファイルがCSVなのは、人間が表で考える世界だからです。誰かからファイルを渡されたら、その形式はたいてい、どちらの世界から来たかを教えてくれます。そして変換は、2つの世界が対話するための方法です。

JSONをCSVに変換すると実際に何が起きるか

変換とは、フラット化のことです。木を表に投影する作業です。このセクションのすべての主張は、ビルドマシン上で、このページが実際に動かしている変換エンジンそのものに対して検証しています。理想化されたルールではなく、本物のルールです。

フラット化をオンにすると、エンジンは6つのルールを適用します。ネストしたオブジェクトはドット記法の列になります。address.city、address.stateのようにです。単純な値のリストは1つのセルになり、"; "で結合されます。newsletterとreferralは"newsletter; referral"になりました。nullは空のセルになります。空のリストも空のセルになります。つまりnullと空のリストは、変換後には区別できなくなります。空のオブジェクトは{}という文字通りのテキストになります。数値と真偽値はテキスト形式になります。2023は文字としての"2023"になります。

6つ目のルールは、やっかいなケースを扱います。オブジェクトのリストです。オブジェクトを区切り文字で結合する道理のある方法はないので、エンジンはリストをJSONテキストとしてセルに格納します。このとき引用符は二重化されます。テスト用のレコード、空のオブジェクト、空のリスト、null、3階層のネスト、オブジェクトのリストに対して実行すると、正確に次の出力が得られました。

フラット化をオフにすると、エンジンはもっと単純で、表としては使いにくい動作をします。ネストした値はすべて、JSONテキストのままセルに残ります。同じaddressオブジェクトは、引用符が二重化された{"city":"Austin"}というセルのテキストになります。値は同じです。表としての使いやすさは大きく劣ります。どちらの設定が正解かは、フラット化のガイドで場面ごとに解説しています。

もう1つ、静かなルールがあります。変換が始まる前に起きます。JSON.parseはキーが重複すると最後の値を残すので、{"code":"A1","code":"B2"}のようなレコードはB2だけが変換されます。最初の値は、コンバーターがデータを見る前に消えています。実際にはまれなことですが、一度だけ知っておく価値があります。

実際のエンジンに通した境界ケース(フラット化オン)
a,b,c,d.e.f,g
{},,,1,"[{""h"":1},{""h"":2}]"

変換で残るもの、失われるもの

残るもの:すべての末端の値が、テキストとして残ります。名前、数値、日付、メモ、メールアドレス。すべてCSVに存在し、すべて正しい値です。「入力した情報が失われたか」という問いへの答えはノーです。表計算ソフト、インポートウィザード、人の目でのざっとした確認には、必要なものは何も欠けていません。

失われるもの:まず型です。数値の2023とテキストの"2023"はCSVでは同一になります。trueと"true"も同一です。CSVを読む側が推測しますが、推測はソフトによってまちまちです。Excelはテキストの"007"を数値の7に変え、"1-2"を日付に変えることで有名です。第2に、ネストした形状です。address.cityはもうオブジェクトだったことを知りません。"newsletter; referral"は2つのタグだったことを知りません。第3に、重複したキーです。最後の値だけが残ります。第4に、nullと空のリストの区別です。どちらも空のセルになるため、「値がない」と「中身のないリスト」が1つに溶けてしまいます。

ここから逆フラット化の問題が生まれます。戻す変換は推測になります。"newsletter; referral"は2つのタグだったのか、たまたまセミコロンを含む1つの文字列だったのか。address.cityは本当にオブジェクトだったのか、それとも最初から文字通り"address.city"というキーだったのか。コンバーターは推測できますが、CSVは覚えていません。経験則はこうです。JSONを正本として残し、表のビューが必要になるたびにCSVを生成する。ストレージは安い。形状の再導出は安くない。

どちらの形式を選ぶべきか

データに形状があるとき、読み手がプログラムであるときはJSONを選んでください。APIやアプリやデータベースとのやり取り。行ごとに形が違うネストしたデータや不揃いなレコード。型を生かしたまま残したい値。価格は数値として、フラグは真偽値として。ログ、設定ファイル、コードが処理するものすべてです。あとで構造を取り戻す可能性があるなら、JSONだけが安全な保管場所です。

読み手が人間であるとき、相手の道具が表の形をしているときはCSVを選んでください。ExcelやGoogleスプレッドシートで開く人。技術者でない同僚へのメール添付。行と列を期待する道具。BIダッシュボード、インポートウィザード、メーリングリストのアップローダーなどです。データが本当にフラットで、ファイルを小さくしたいときもCSVです。ビルドマシンでの実測では、均一な顧客行1,000件がJSONでは111,433バイト、CSVでは48,473バイトでした。半分以下のサイズです。JSONが各行にキー名を繰り返すからです。ネストしたデータではこの比較は成り立ちません。CSVは工夫なしにネストを保持できないからです。でもフラットな表なら、サイズではCSVが毎回勝ちます。

多くのチームが落ち着く実用的な組み合わせはこうです。保存と交換はJSON、CSVは必要に応じてエクスポート。正本はリッチなまま残し、表の作業用コピーが必要になったらその都度生成します。このページのコンバーターは、まさにその2つ目のステップのためにあります。変換方法のガイドでは、確実な3つの方法、オンラインコンバーター、ExcelのPower Query、Pythonを解説しています。

2つの形式の間を行き来する

JSONからCSVへは、このサイトが得意とする方向です。このページ上部のコンバーターにJSONを貼り付けるかアップロードしてください。登録は不要です。変換はすべてブラウザの中で行われるため、データがお使いのマシンから外に出ることはありません。繰り返し使う作業やスクリプト化したい作業には、変換方法のガイドでExcelのPower QueryとPythonでの同じ作業を解説しています。

CSVからJSONへは、戻りの方向です。前のセクションの正直な注意点がついてきます。戻るときは型を推測しなければなりません。CSVが型を保持していなかったからです。逆方向のガイドでは変換方法を解説し、推測が外れうる場所を示しています。信じるのではなく、確認できるようにするためです。

関連ガイド

よくある質問

JSONとCSVは同じものですか?

いいえ。JSONはオブジェクトと配列でネストした型付きデータを保持し、CSVはテキストの行でフラットな表を保持します。解決する問題が違います。JSONはプログラムが交換する構造化データのため、CSVは人間が表計算ソフトで開く表のためです。両者の間では常に変換が行われているので、どちらの形式も消えません。どちらか一方だけ覚えればいい、というものではなく、使い分けが実務の基本になります。

CSVファイルはJSONのようにネストしたデータを保持できますか?

そのままではできません。CSVには行と列しかなく、それより深い階層はないからです。ネストはフラット化するか(addressオブジェクトがaddress.city列とaddress.state列になる)、1つのセルにJSONテキストとして詰めるしかありません。どちらの回避策も元の形状を失うので、ネストが重要ならJSONを残してください。フラット化のガイドでは、フラット化トグルがネストしたデータに何をするのかを正確に示しています。

JSONをCSVに変換するとデータは失われますか?

失われるのは形状であって、値ではありません。すべての末端の値はテキストとして残ります。ただし型は崩れます(数値も真偽値もテキストになる)。ネストはドット記法の列にフラット化され、重複したキーは最後の値だけが残り、nullと空のリストはどちらも空のセルになります。表計算ソフトやインポートには、必要なものは何も欠けていません。JSONに戻す可能性があるなら、元のファイルを残してください。CSVはあくまで作業用のコピーと考えるのが安全です。

ファイルサイズが小さいのはJSONとCSVのどちらですか?

フラットで均一なデータなら、たいていCSVがずっと小さくなります。ビルドマシンでの実測では、顧客行1,000件がJSONで111,433バイト、CSVで48,473バイトでした。半分以下のサイズです。JSONが各行にキー名を繰り返すからです。ネストしたデータではこの比較は成り立ちません。CSVはネストを重複やシリアライズなしに保持できないからです。サイズではなく形状で選んでください。

ExcelでJSONファイルを開けますか?

表計算シートとしては直接開けません。確実な方法は2つです。JSONを先にCSVに変換してから開く方法と、Power Queryを使う方法(データ、データの取得、ファイルから、JSONから)です。Power QueryならJSONを正しくExcelに取り込めます。ファイル変換のガイドでは、Power Queryの手順をステップごとに解説しています。ネストしたデータは取り込み時に列へ展開する操作が必要なので、初めての方はガイドの手順通りに進めるのが確実です。

JSONは人間が読める形式ですか?

はい。プレーンテキストですし、小さく整形されたJSONなら普通に読めます。読みやすさはサイズと深さで崩れます。ミニファイされた1行のエクスポートは、技術的には読めても実用的には読みにくいものです。大きなファイルは、先にフォーマッターで整形するか、CSVに変換して表で確認してください。

APIがCSVではなくJSONを返すのはなぜですか?

APIのデータがめったにフラットな表ではないからです。レスポンスはネストします(ユーザーが住所を持ち、住所が座標を持つ)。型が混ざります(数値、真偽値、null)。レコードごとに形が違います。これらはJSONが得意で、CSVが苦手なことです。データがすでに表で、読み手が人間ならCSVが輝きます。データに形状があり、読み手がプログラムならJSONが輝きます。APIの設計者は受け手がプログラムであることを前提にしているので、JSONが標準になっています。

1つのタブでJSONをCSVに変換

2つの形式が分かったら、ここで変換してみましょう。JSONを貼り付けてCSVをダウンロードできます。無料、登録不要、すべてブラウザ内で動作します。

JSON CSV コンバーターを開く
ガイド一覧