CSV vs XLSX vs JSON: 最適なデータ形式の選び方
データ形式の選択が、なぜ本当に重要なのか
データ形式を間違えると、本当に避けることのできるはずの苦労をすることになります。壊れたインポートデータのクリーンアップ、エンコーディングエラーとの格闘、あるいはスプレッドシートの数式が突然壊れた理由を困惑する同僚に説明するのに何時間も費やすことになるのです。これは稀な技術的問題ではありません。アナリスト、開発者、運用チームのプロジェクトをすり減らす日々の摩擦です。ほとんどの場合、CSV、XLSX、JSONの3つの形式のいずれかを扱うことになるでしょう。これらは一見似ていますが、解決する問題は全く異なります。CSVは50年の歴史を持つプレーンテキストの働き者で、地球上のほぼ全てのツールが読み込めます。XLSXはMicrosoftの強力なスプレッドシート用コンテナで、生データ以上のものを保持します。JSONはウェブのネイティブ言語であり、APIや現代のアプリケーションを支えています。どれか一つが他より「優れている」わけではありません。Shopifyからの10列の商品カタログ？CSVとしてエクスポートすれば、30秒で何の問題もなくGoogleスプレッドシートに取り込めます。同じカタログがAPI経由で提供されるなら？それはJSONでなければなりません。そして、もし財務チームがピボットテーブル、条件付き書式、名前付き範囲を必要とするなら、XLSXだけがその役目を果たせます。このガイドでは、抽象的な技術論争ではなく、あなたが実際に行っている作業に適した形式を選択するための実践的なフレームワークを提供します。
CSV：強み、弱み、そして最適な使用場面
CSV、つまりカンマ区切り値（Comma-Separated Values）は、データ形式の中で最もシンプルなものです。各行は単なるテキストの1行で、フィールドはカンマ（時にはタブやセミコロン）で区切られています。数式も、フォントも、データ型もありません。ただのテキストです。この徹底したシンプルさは、その最大の強みであると同時に、最も厄介な弱みでもあります。その力は否定できません。CSVファイルは非常に小さいです。XLSXで45MBになる50万行のデータセットが、CSVならわずか8MBにまで縮小できます。さらに良いことに、あらゆるものがCSVを読み込めます。PostgreSQLのCOPYコマンド、Pythonの組み込みcsvモジュール、Rのread.csv()など、これらはすべて特別なライブラリなしでネイティブにCSVを扱えます。ETLジョブ、データ移行、SalesforceやMailchimpのようなツールへの一括アップロードにおいて、CSVは誰もが認めるチャンピオンです。しかし、弱点も非常に現実的です。CSVには「データ型」という概念がありません。郵便番号のような`00147`は、インポートツールが賢くテキストとして扱わない限り、`147`になってしまいます。日付は悪夢です。アメリカ（MM/DD/YYYY）とヨーロッパ（DD/MM/YYYY）のソースからのデータをマージしようとしたことがある人なら、この苦労を知っているでしょう。`04/05/2026`は4月5日なのか、5月4日なのか？CSVでは、それは賭けです。さらに、埋め込まれたカンマや改行による混乱もあります。これには完璧なクォーテーションが必要ですが、多くのエクスポーターは正しく処理してくれません。そして文字エンコーディングも忘れてはいけません。UTF-8とWindows-1252の不一致があの悪名高い文字化けを引き起こします。ですから、ルールはこうです。データが単純なフラットテーブルで、最大限の互換性が必要な場合、またはファイルサイズが重要な場合にCSVを使いましょう。書式の維持、データ型の強制、ネストされたデータの扱いが必要な場合は、他の形式を探すべきです。
XLSX：スプレッドシート以上、データベース未満
XLSXは2007年以来Microsoft Excelのデフォルト形式であり、Googleスプレッドシート、LibreOffice Calc、そしてあらゆる本格的なBIツールでスムーズに扱えます。豆知識ですが、XLSXファイルは実はXMLファイルが詰まったZIPアーカイブなのです。これは自分で証明できます。`.xlsx`ファイルを`.zip`にリネームして中身を覗いてみてください。このアーキテクチャこそが、XLSXにその力を与えているのです。CSVの「すべてがテキスト」というアプローチとは異なり、XLSXは真のデータ型を保存します。日付はシリアル値（例えば2026年5月17日なら`46188`）として保存され、別の書式コードを持つため、ユーザーには常に正しく表示されます。数値は最大15桁の有効数字を持つ数値として、ブール値は曖昧な文字列ではなく`TRUE`/`FALSE`として保存されます。それだけでなく、XLSXは複数シート、名前付き範囲、数式、グラフ、ピボットテーブル、データ検証ルールといった機能をすべて1つのファイルに詰め込んでいます。技術者ではない同僚、特に財務や運用の担当者に渡すレポートであれば、XLSXが唯一のプロフェッショナルな選択肢です。彼らにCSVを送るのは、単に彼らの仕事を増やすだけです。しかし、これはデータベースではありません。pandasを使って20万行のXLSXをプログラムで解析すると10～15秒かかることがありますが、同じデータがCSV形式なら2秒未満で読み込めます。そして注意すべきは、XLSXには1シートあたり1,048,576行という厳格な制限があることです。これより大きなデータセットをエクスポートすると、警告なしに切り捨てられます。結合されたセルや非表示の行といった形式の複雑さも、自動化スクリプトにとって大きな頭痛の種になることがあります。XLSXを選ぶべきなのは、受け手がスプレッドシートソフトを使う人間である場合、リッチな書式や複数シートが必要な場合、そしてデータ型を面倒な設定なしで完璧に保持したい場合です。
JSON：開発者の標準と、その現実的なトレードオフ
JSON、つまりJavaScript Object Notationは、現代のウェブの言語です。REST API、設定ファイル、そしてMongoDBのようなNoSQLデータベースの標準形式です。そのキラー機能であり、JSONが広く使われる理由は、ネストされた階層構造のデータをネイティブに表現できる能力です。1つのJSONオブジェクトで、明細項目の配列を含む注文を記述でき、各項目には独自の商品属性リストを持たせることができます。これをCSVでモデル化しようとすると、少なくとも3つの別々のファイルと多数の結合キーが必要になります。Stripe、Twilio、Google Maps APIからデータを取得するとJSONが返ってくるのはこのためです。Webhookにデータを送信するときもJSONを送ります。それが標準であるのには理由があるのです。JSONはデータ型もきれいに保持します。文字列は引用符で囲まれ、数値は囲まれません。ブール値は`true`/`false`で、`null`はそれ自体が独立した値です。曖昧さはありません。しかし、この力には代償が伴います。特に単純な表形式データの場合です。10万行のフラットなテーブルをオブジェクトのJSON配列として保存すると、すべてのフィールド名が10万回繰り返されることになります。この冗長性のせいで、4MBのCSVが簡単に18MBのJSONファイルになってしまいます。また、大規模になると人間には非常に不親切です。ミニファイされたJSONはただのテキストの壁です。ExcelやGoogleスプレッドシートはJSONをインポートできますが、そのプロセスは苦痛です。メニューをたどり（データ → データの取得 → ファイルから → JSONから）、Power Queryエディターと格闘して構造をフラット化しなければなりません。これは面倒です。JSONはAPI、階層データ、JavaScript中心のワークフローに使いましょう。人間が見る必要があるフラットなデータには、ほとんどの場合、不適切なツールです。
直接比較：実践的な判断基準表
これらの形式を、実世界で重要となる基準で直接比較してみましょう。ファイルサイズとパフォーマンスに関しては、その差は歴然です。10万行、15列のテーブルの場合、CSVは約12～20MBかもしれません。同等のJSONはキーの繰り返しにより25～50MBになる可能性があります。一方、XLSXは8～25MBの範囲で、データが主に数値であれば内部のZIP圧縮のおかげでCSVより小さくなることもあります。Pythonでの処理速度では、CSVが明らかに勝者で、XLSXよりも2～5倍速く読み込めます。JSONはその中間あたりです。汎用的なツールの互換性においては、CSVに勝るものはありません。良い意味で、誰もが扱える最低限の基準となっています。XLSXは僅差で2位ですが、プログラムからアクセスするには専用のライブラリが必要です。JSONはウェブとJavaScriptにとってはネイティブですが、スプレッドシートアプリケーションでは扱いにくく、異質な感じがします。データ構造についてはどうでしょう？データが階層的で、オブジェクトの中にオブジェクトがあるような場合、JSONが唯一の現実的な選択肢です。CSVとXLSXは基本的にフラットです。設定なしでデータ型を保持する点では、XLSXとJSONはどちらも優れています。数値、文字列、ブール値を明確に区別して保存します。一方、CSVはすべてを文字列として扱い、解釈は受け手側のツールに委ねられます。私からの正直なアドバイスですか？迷ったら、CSVから始めましょう。データ交換における「万能供与者」のようなものです。
形式間の変換：CocoConvertでできること、できないこと
CocoConvertは、CSV、XLSX、JSON間の直接的な双方向変換を提供します。標準的な表形式データであれば、私たちのツールは高速で信頼性があります。5万行のCSVをアップロードすれば、10秒以内に完全に構造化されたXLSXファイルが返ってきます。私たちは、CSV→XLSX、CSV→JSON、XLSX→CSV、XLSX→JSON、JSON→CSV、JSON→XLSXの6つの変換パスすべてに対応しています。変換における主な課題は、JSONの複雑さから生じます。私たちのJSONからCSV、JSONからXLSXへのコンバーターは、最も一般的なAPI出力、つまりフラットなオブジェクトの配列を想定して設計されています。JSONが数レベルのネスト構造を持っている場合、CocoConvertはそれをフラット化しようと試みます。しかし、深くネストされた、あるいは不規則な構造（オブジェクト内の配列の中の配列など）の場合、出力が不完全になる可能性があります。そのような高度なケースでは、アップロードする前に`jq`のようなコマンドラインツール（例：`jq '.[] | {id: .id, name: .customer.name, total: .order.total}' input.json > flat.json`）を使って自分でファイルを前処理する方が、よりきれいな結果が得られます。その他にも、形式特有の挙動がいくつかあります。XLSXからCSVに変換する場合、CocoConvertはアクティブなシートのみをエクスポートします。ワークブックに5つのシートがある場合、5回の変換を実行する必要があります。また、XLSXの数式は最後に計算された値に評価されます。数式自体は、変換後のCSVやJSONには保存されません。これは想定された動作ですが、よく混乱を招く点です。最後に、グラフ、ピボットテーブル、条件付き書式のような表示機能は失われます。これらにはCSVやJSONに対応する機能がないためです。すべての機能を保持したままXLSXファイルを再構築する必要がある場合、CocoConvertは適切な選択ではありません。マクロやopenpyxlを使ったPythonスクリプトの方が適しています。私たちは、お客様の時間を無駄にしないよう、ツールの限界について正直にお伝えすることを信条としています。
最終決定を下すための形式チェックリスト
では、どうやって最終決定を下せばよいのでしょうか？抽象的な「ベストプラクティス」について考えるのはやめて、あなたの特定のタスクについて、いくつかの的を射た質問を自問してみてください。まず何よりも先に問うべきは、誰が、あるいは何がこのファイルを使うのか？ということです。答えがExcelやGoogleスプレッドシートを日常的に使う人であれば、ファイルが非常に大きくない限り、XLSXを送りましょう。それが開発者、自動化パイプライン、ウェブAPI向けであれば、CSVかJSONが最良の選択です。次に、データの形を見てみましょう。すべての行が同じ列を持つ、単純でフラットなグリッドですか？それならCSVとXLSXが完璧です。ブログ投稿ごとのタグのリストのように、ネストした構造を持っていますか？それなら絶対にJSONが必要です。次に実用性を考えます。基本的なテキストエディタで読み取れる必要がありますか？それならCSVです。特別な書式や数式を保持したり、複数のシートを1つのワークブックにまとめたりする必要がありますか？それはXLSXだけの仕事です。ファイルサイズが大きな懸念事項の場合はどうでしょう？本当に巨大なデータセット（50万行以上）の場合、CSVが最も管理しやすいことが多いです。JSONは肥大化し、XLSXは行数の上限に達するかもしれません。最後に開発者向けの質問です。このファイルはGitリポジトリに置かれますか？プレーンテキスト形式（CSV、JSON）は変更の追跡が容易なため、バージョン管理にははるかに優れています。バイナリ形式のXLSXファイルの差分を取るのは悪夢です。これらの質問に答えれば、正しい選択はたいてい明らかになります。どの形式が優れているかという論争は、本質から目をそらすものです。これらのツールにはそれぞれ明確な目的があり、コツは単にツールを自分のワークフローに合わせることです。