開発のきっかけ：ある月曜日の絶望
「このシステムの全体像、誰か知ってますか？」
週明けのミーティングで私が放ったその一言に、チーム全員が沈黙しました。
手元にあるのは、数年かけて継ぎ足し秘伝のタレのようになった巨大なデータベース。最新のER図はどこにもなく、唯一の正解は動いている「コード（DDL）」だけでした。
一つひとつのテーブル定義をエディタで開き、脳内でリレーションを組み立てる作業。
「あ、これ user_id じゃなくて owner_id で繋がってるのか……」そんな発見を繰り返すたびに、エンジニアとしての貴重な時間が溶けていくのを感じました。
「SQLを貼り付けたら、一瞬で綺麗なER図が出ればいいのに」
そう思って既存のツールを探してみましたが、あるものは「SQLをサーバーにアップロードしてください」というセキュリティ上の不安があり、またあるものは「専用ソフトのインストール」が必要で、今すぐ使いたい自分のニーズには合いませんでした。
特に機密性の高いプロジェクトの設計情報を、出所の分からないサーバーに送信するのはエンジニアのプライドが許しません。「100%安全で、今すぐ、ブラウザだけで完結するER図生成器」。そんな、自分自身が一番欲しかった道具を作ろうと決めたのが、SQL to ER図変換ツール 開発の始まりでした。
技術的な挑戦：ブラウザという「孤独な環境」での戦い
サーバーサイドの強力なライブラリを使わずに、ブラウザ上のJavaScriptだけでSQLを解析するのは、予想以上に泥臭い作業の連続でした。
1. 終わりのない「SQL方言」との追いかけっこ
SQLには、MySQLやPostgreSQLといった「方言」があります。
最初は「CREATE TABLE文なんてどれも同じだろう」と高を括っていましたが、いざ実装を始めると、カラム定義の細かな記法や、インラインで書かれた制約条件など、考慮すべきパターンが山のように出てきました。
正規表現を書き換えてはテストし、また別のパターンのSQLで壊れる。
そんなサイクルを何度も繰り返しながら、少しずつ「SQLの気持ち」を理解できるパーサーを育てていきました。
2. Mermaid.jsという救世主
解析したデータをどうやって「図」にするか。この難問を解決してくれたのが Mermaid.js です。
エンジニアがMarkdownでよく使うこのツールをエンジンに据えることで、「SQL → 中間データ → Mermaid記法 → SVG」というクリーンな変換ラインが完成しました。
erDiagram
USER ||--o{ POST : writes
USER {
string username
string email
}この仕組みのおかげで、ユーザーは図を画像として保存できるだけでなく、生成された「コード」をコピーしてGitHubのドキュメントにそのまま流用できるという、副次的なメリットも生まれました。
セキュリティへの「執念」
このツールで一番譲れなかったのは、「データは一歩もブラウザの外に出さない」ことです。
開発中、何度も「サーバー側で処理したほうが楽だな」という誘惑に駆られましたが、そのたびに「それは自分が使いたいツールじゃない」と踏みとどまりました。
通信が発生しない。だから、誰にも気兼ねせず、社外秘のDMLやDDLを貼り付けられる。
この安心感こそが、ツールとしての本質的な価値だと信じています。
最後に
SQL to ER図変換ツールは、私自身の「面倒くさい」という感情から生まれた道具です。
開発者が本来向き合うべきは、ドキュメントの清書ではなく、より良いシステムの設計であるはずです。
「設計図がない」と途方に暮れている誰かの元に、このツールが届き、一筋の光になればこれほど嬉しいことはありません。
さあ、手元のSQLを貼り付けて、設計の「答え合わせ」を始めましょう。