無料 SQL → JSON コンバーター

SQL CREATE TABLE文をJSONスキーマに変換します。列名、型、制約を瞬時に抽出します。

データはデバイスを離れません

SQL → JSON変換について

このツールはSQL CREATE TABLE文を解析し、JSONスキーマ形式に変換します。列名、データ型(INT、VARCHAR、TEXT、BOOLEAN、DATE、TIMESTAMP、DECIMAL)、制約(NOT NULL、PRIMARY KEY、DEFAULT値)を抽出します。JSON出力は、APIドキュメント、データベース設計、移行ツールに適しています。

サポートされているSQLデータ型

よくある質問

どのSQL方言がサポートされていますか?

このコンバーターは、MySQL、PostgreSQL、SQL Server、SQLiteで使用される標準SQL構文を処理します。方言固有の機能は完全に認識されない場合があります。

複雑な制約を処理しますか?

コンバーターはNOT NULL、PRIMARY KEY、DEFAULT、基本的な型情報を認識します。CHECKやFOREIGN KEYなどの複雑な制約はテキスト注釈として保存されます。

JSON出力を直接使用できますか?

はい!JSON出力は読みやすさのためにフォーマットされており、APIスキーマ、TypeScriptインターフェース、ドキュメントジェネレーターで使用できます。

スキーマであり、データではない：このツールができること

このコンバーターはSQL CREATE TABLEステートメントを受け取り、JSONスキーマを出力する：カラム・型・基本制約の記述で、APIコントラクト・TypeScript型生成・ドキュメントストアのマイグレーションに適している。INSERTの行やクエリ結果セットをJSONに変換するわけではない。「SQL to JSON」への検索意図はその2つのニーズにほぼ半々に分かれている；行からオブジェクトへの変換を期待していた場合は別のツールが必要だ。スキーマ変換のパスは開発者向けのケースだ：テーブル定義があり、他のツールが使用できる構造化された形状の記述が欲しい場合だ。

SQLの短い歴史

SQLはIBMのサンノゼ研究所で1970年代初頭にDonald D. ChamberlinとRaymond F. Boyceによって設計された。当初の名称はSEQUEL（Structured English Query Language）で、IBMの実験的なリレーショナルデータベースSystem Rへの高水準インターフェースとして構想された。リレーショナルモデル自体は1970年にEdgar F. Coddが発表していた；ChamberlinとBoyceの貢献は、Coddの代数的な記号よりも自然な英語の節（SELECT … FROM … WHERE …）をモデルにした、一般のアナリストが読める構文だった。Boyce（Boyce-Codd正規形にもその名を残した）は、共同発明した言語が商業リリースされる前の1974年に26歳で亡くなった。名称は1975年にHawker SiddleyのSEQUELという商標との衝突のためSQLに変更されたが、米国では元の「sequel」という発音が国際的な「ess-cue-ell」と並んで残っている。

ANSIは1986年にSQLを標準化し（SQL-86）、ISOは1987年にほぼ同一のバージョンをISO/IEC 9075として批准した。その後3〜5年ごとに改訂されている：SQL-92（今でもほとんどのチュートリアルが前提とするベースライン）、SQL:1999（再帰クエリ・トリガー）、SQL:2003（XML型・MERGE）、SQL:2011（テンポラルテーブル）、SQL:2016（JSONサポート）、そして最新のSQL:2023（多次元配列・プロパティグラフクエリ）。競合する技術の波（1990年代のオブジェクトデータベース・2000年代後半のNoSQL・2010年代のデータレイク）にもかかわらず、SQLは50年以上にわたって構造化データの主要なクエリ言語として存続している。2024年には、ほとんどのNoSQLプラットフォームがSQLまたはSQL的なレイヤーを再導入している（CassandraのCQL・MongoDBの$sql集計ステージ・DynamoDBのPartiQL・Spark SQL・Trino・DuckDB・BigQuery・Snowflake）。これはSQLがいかなる単一のストレージエンジンも超えて存続するというMike Stonebrakerの予言を裏付けている。

JSONを一段落で

JSON（JavaScript Object Notation）はDouglas Crockfordが2001年に策定し、JavaScriptオブジェクトリテラル構文のサブセットから派生して、2013年にECMA-404として、2017年にIETF RFC 8259として標準化された。値の型は6つしかない（文字列・数値・真偽値・null・配列・オブジェクト）で、日付・小数・バイナリ・スキーマのネイティブな概念はない。JSONスキーマ（別の仕様、現在はドラフト2020-12）はその上に構造的・型的なバリデーションを重ねる。このコンバーターにとってのJSONスキーマの価値：ほぼすべての現代のコードジェネレーターとバリデーションライブラリが理解できるポータブルでスキーマ非依存なフォーマットだ。

機械的な変換

代表的な入力：

CREATE TABLE users (
  id INT PRIMARY KEY,
  email VARCHAR(255) NOT NULL,
  signup_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  is_active BOOLEAN DEFAULT TRUE
);

次に対応：

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "users",
  "type": "object",
  "properties": {
    "id": { "type": "integer" },
    "email": { "type": "string", "maxLength": 255 },
    "signup_at": { "type": "string", "format": "date-time" },
    "is_active": { "type": "boolean", "default": true }
  },
  "required": ["id", "email"]
}

ステップバイステップ：入力をトークナイズし、CREATE TABLEとテーブル名を特定し、括弧で囲まれたカラムリストを見つけ、DECIMAL(10,2)やCHECK (x > 0)のような入れ子の括弧を考慮しながらトップレベルのカンマでカラム定義を分割し、各カラムを名前+型+修飾子に解析し、SQL型を最も近いJSONスキーマ型にマッピングする。NOT NULLはrequired配列へのメンバーシップになる。DEFAULTはdefault値になる。PRIMARY KEYは通常アノテーションまたはrequiredへのメンバーシップになる。CHECK・FOREIGN KEY・UNIQUEおよびインデックスはJSONスキーマに直接対応するものがないため、テキストアノテーションになることが多い。

方言の問題

SQLは単一の言語ではなく、有名な方言の集合だ。基本的な識別子のクォートでさえ異なる：

型名も異なる。INT(11)（MySQL）は表示幅のヒントでPostgreSQLは拒否する。PostgreSQLのSERIALはINT NOT NULL AUTO_INCREMENT PRIMARY KEYの省略形；SQL ServerではIDENTITYが同じ役割を果たし；SQLiteはAUTOINCREMENTを使用する。BOOLEANはMySQLでは内部でTINYINT(1)だ。地理型（GEOMETRY・POINT）、JSONカラム型（JSON・JSONB）、配列型（PostgreSQLのINTEGER[]）、全文ベクトル型（pgvectorのVECTOR(1536)）はJSONスキーマに対応するものがなく不透明な文字列アノテーションとなる。BLOBおよびBYTEAバイナリデータはネイティブなJSON表現を持たない；標準的な方法はbase64文字列化でcontentEncodingヒントを付ける。

SQL型 対 JSON型：インピーダンスの不一致

SQLはリッチな型システムを持つ；JSONは6つの値型を持ちスキーマはない。知っておく価値のある点：

これを使う場面

現代の代替手段

その他の質問

CREATE TABLEにFOREIGN KEY制約がある場合は？

JSONスキーマにはネイティブな外部キーの概念がない。最もクリーンな表現は、参照されるテーブルとカラムを示すカスタムアノテーション（例：非標準のx-foreign-keyプロパティ）だ。このコンバーターは出力にテキストノートとして関係を保持する；完全に形式的な参照モデリングが必要な場合、JSONスキーマの$ref + 別の定義ブロックが最も近いが、多対多のケースでは使いにくい。よりリッチなリレーショナルモデリングにはDBMLまたはAtlas HCLを検討する。

出力にCHECK制約が含まれないのはなぜですか？

JSONスキーマは多くの単純なCHECK制約を表現できる。CHECK (age >= 0)は{"minimum": 0}になり、CHECK (status IN ('a','b'))は{"enum": ["a","b"]}になる：しかしCHECK節の任意のSQL式（関数呼び出し・結合・サブクエリ）はJSONスキーマに対応するものがない。コンバーターは単純なケースを認識し、複雑な制約はサイレントに削除するのではなくテキストアノテーションとして保持する。

INSERT行をJSONに変換できますか？

このツールではできない。スキーマレベルの変換（CREATE TABLE）のみを処理する。行レベルの変換には、通常データベースネイティブな方法が適切だ：PostgreSQLのSELECT row_to_json(t) FROM tbl t、MySQLのJSON_OBJECT()、またはCSVにエクスポートしてCSV-JSONツールを使用する。mysqldump --xmlをXML-JSONコンバーターにパイプするのも一般的な方法だ。

JSONでBIGINTが問題になるのはなぜですか？

JavaScriptのJSON.parseはIEEE 754の倍精度を使用し、2^53 = 9,007,199,254,740,992までの整数しか正確に表現できない。それを超える数値は精度を失う。SQLのBIGINTは2^63 ≈ 9.2クインティリオンまで対応でき、安全なJSON整数範囲をはるかに超える。JSONを通じてBIGINTを安全に転送するクロスプラットフォームの規約は、文字列としてシリアライズし宛先でBigIntで解析することだ；多くのAPI（Twitter / XのツイートID・StripeのID・PostgreSQLのbigserial）がまさにこれを行っている。

何かサーバーに送信されますか？

いいえ。パーサーはブラウザ内で動作し、JSON出力はローカルで生成される。ペーストしたSQLはデバイスの外に出ることはない。CREATE TABLEステートメントに独自のカラム名・内部テーブル規約・その他のログに残したくない詳細が含まれている場合にこれが重要だ。ページは一度読み込まれればオフラインでも動作する。

関連ツール

JSONフォーマッター

JSONを瞬時にフォーマット、ミニファイ、検証します。

SQLフォーマッター

SQLクエリをフォーマットおよび美化します。

XMLフォーマッター

XMLドキュメントをフォーマットおよび検証します。