CSVからSQLへのコンバーター — INSERT文を無料生成

CSVの行をSQLに変換する際、各列はINSERT INTO文の値になります — 数値はクォートなしのまま、テキストは内部のクォートを二重にしてシングルクォートで囲まれ（O'BrienはO''Brienになります）、空のセルはNULLになります。このツールはCSVファイル全体に対してその変換をブラウザ内で完結して行います。任意のテーブル名を指定でき、エクスポートした表計算データやデータベースのダンプがデバイスの外に出ることはありません。

このツールとは？

テスト用データベースへのデータ投入、表計算ソフトのエクスポート内容をテーブルに読み込む作業、あるいは小規模なデータ移行は、たいてい同じところから始まります。手元にCSVファイルがあり、必要なのはSQLです。このツールはCSVを解析し（ヘッダー行を列名として使用）、すべてのデータ行を1つのINSERT INTO文にまとめて生成します。そのままデータベースクライアントに貼り付けて実行できます。

文字列値はシングルクォートで囲まれ、内部のシングルクォートは二重にすることでエスケープされます（例：O'BriendはO''Brienになります）。これはMySQL、PostgreSQL、SQLiteで共通の標準的なエスケープルールです。空のCSVセルは空文字列ではなくSQLキーワードのNULLとして書き出されます — これは意図的な選択です。表計算ソフトの空セルは通常「値がない」ことを意味し、「空のテキスト」を意味するわけではなく、ほとんどのスキーマもそれに対してNULLを期待しているためです。

値をクォートするかどうかは、実際の型推論ではなくシンプルなヒューリスティックで判断されます。前後の空白を除いたセルが単純な整数または小数（先頭にマイナス記号がついてもよい）に見える場合は、クォートなしで書き出されます。それ以外のすべて — 先頭にゼロが付く郵便番号や電話番号のように、数字に似ているだけで余分な文字を含む値も含みます — は文字列としてクォートされます。これにより出力は誠実さを保ちます。小規模なインポートの良い出発点にはなりますが、実行前に実際のテーブルスキーマと照らし合わせてデータを検証する代わりにはなりません。

出典: CSVの解析はRFC 4180に準拠しています。これは正式なCSV標準に最も近いものです。文字列エスケープのためのシングルクォートの二重化は、MySQL、PostgreSQL、SQLiteで共通して採用されている慣習です。

なぜこれを使うのか？

カスタムテーブル名 — 一度設定すれば、すべての行がそのテーブルを対象にします。
正しい文字列エスケープ処理 — 値の中のシングルクォートは二重化され、SQLが壊れたり途切れたりしません。
予測可能なNULL処理 — 空セルは空文字列ではなくNULLになり、ほとんどのデータベースが欠損データを区別する方法と一致します。
一般的なSQL構文 — ここで生成されるINSERT INTO ... VALUES ...形式は、MySQL、PostgreSQL、SQLiteでそのまま動作します。
100%クライアントサイド — CSVデータ（顧客記録やビジネスデータを含む場合があります）はブラウザ内で解析・変換され、どこにもアップロードされません。

使い方

ヘッダー行付きのCSVデータを貼り付けてください。例：name,age\nAlice,30\nBob,25。
対象のテーブル名を入力してください（デフォルトはmy_table）。
「SQLを生成」をクリックしてください。
INSERT INTO文をコピーするか、.sqlファイルとしてダウンロードして、データベースに対して実行してください。

例

入力

name,age,city
Alice,30,
Bob,,NYC

出力

INSERT INTO `my_table` (`name`, `age`, `city`)
VALUES
  ('Alice', 30, NULL),
  ('Bob', NULL, 'NYC');

空セルがNULLになり（空文字列ではなく）、数値らしいage値の30はクォートなしのまま、すべてのテキスト値がクォートされている点に注目してください。

実用的なヒント

ローカルのテスト用データベースへのデータ投入：表計算ソフトから小さなサンプルをCSVとしてエクスポートし、ここで変換して、開発用データベースに対してINSERT文を実行します。
実際のテーブルに対して生成されたSQLを実行する前に、必ず列の型を確認してください — このツールは実際のスキーマではなく、シンプルなヒューリスティックで数値かテキストかを推測するため、特定の形式を期待する整数列には手動での調整が必要になる場合があります。
何千行もある場合、このツールが生成する単一の複数行INSERT文は有効なSQLですが、非常に大きな文はデータベースの最大パケットサイズを超える場合があります — その制限に達した場合は、先にCSVを小さなバッチに分割してください。

なぜ空文字列ではなくNULLなのか

CSVからSQLへの変換スクリプトを手書きする際によくある間違いは、欠損しているすべてのセルを空文字列''として扱うことです。これは技術的には有効なSQLですが、たいてい意図した意味にはなりません。整数として定義された列は''をきっぱり拒否しますし、テキスト列であっても、''はほとんどのスキーマ設計やレポート用クエリにおいて「この値を知らない」とは異なる意味を静かに持ちます（WHERE column IS NULLというチェックは空文字列にはマッチせず、その逆もまた然りです）。空セルにNULLを使うことは、ほとんどのデータベースやORMが期待するセマンティクスと一致し、数値列の一部の行に欠損値がある場合の型エラーも回避できます。

よくある質問

これはすべてのSQLデータベースで動作しますか？

生成される構文 — バッククォートで囲まれた識別子、シングルクォートで囲まれた文字列値、標準的なINSERT INTO ... VALUES ... — はMySQL、PostgreSQL、SQLiteで共通です。PostgreSQLは識別子にバッククォートを厳密には要求しません（クォートが必要な場合はダブルクォートを使用します）が、予約語と衝突するような特殊な列名でない限り、バッククォート付きの名前もそこで問題を起こしません。ここでは単一の公式SQL規格に従っているわけではなく、主要なデータベースでそのまま動く構文を採用しているだけです。

なぜ空セルは空文字列''ではなくNULLになるのですか？

これは意図的な設計判断です。実際のCSVエクスポートのほとんどの場合、空白のセルは値が不明または該当なしを意味し、文字どおりの空テキストを意味するわけではありません。NULLはほとんどのデータベーススキーマがそれに対して期待する値です。用途上どうしても空文字列が必要な場合は、そのケースについて生成されたSQLを手動で編集する必要があります。

値にクォートが必要かどうかをこのツールはどう判断しますか？

実際の型推論ではなく、シンプルなヒューリスティックです。前後の空白を除いたセルが数字のみで構成されている場合（先頭にマイナス記号、小数点は最大1つまで許容）、クォートなしの数値として書き出されます。それ以外はすべて文字列としてクォートされます。つまり00501のような郵便番号や電話番号は、余分な文字を含む場合にのみテキストとして扱われます — 先頭のゼロだけならここではまだ数値としてパースされるので、SQLを実行する前に郵便番号やIDのような識別子は必ず確認してください。

私のデータはどこかにアップロードされますか？

いいえ。解析とSQL生成はどちらもブラウザ内のJavaScriptとして実行されます — サーバーには何も送信されないため、エクスポートした顧客データやビジネスデータを扱っても安全です。

カンマや引用符を含むCSVの値も処理できますか？

はい。CSVは適切な引用フィールド用パーサーで解析されており、引用フィールド内のカンマ、改行、二重の引用符を理解します — 単純なカンマ区切りではありません — そのため「Smith, John」のようなフィールドは、2つの列に分割されることなく1つの値として読み込まれます。

CSVからSQLへの変換ツール