データベースを設計するとき、こんな徒労を味わったことはないでしょうか。GUIのER図ツールできれいな図を描いたのに、その図はツールの中に閉じていてGitで管理できない。SQLのDDLは別で書くから図とスキーマが二重管理になり、いつの間にか食い違う。チームに共有しようにも、画像を書き出して貼るしかない——。ER図は設計の要なのに、コードのように扱えないせいで、いつも“お荷物”になりがちです。erd-editorは、この問題を正面から解決する、「DBスキーマをコードとして扱える」オープンソースのER図エディタです。作者はdineug氏、GitHubで約1,700スター（2026年7月時点）を集めています。

この記事を読むと、①erd-editorで結局何ができるのか（ER図をGUIで描きつつSQL DDLと相互変換し、設計を.erd.jsonとしてGit管理する）、②どんな課題を解決するのか（GUI専用ツールの「バージョン管理できない・SQL二重管理・共有が面倒」）、③何を代替できるのか（有償のER図ツールや、手描きのER図）が分かります。開発ワークフローの自動化・効率化の全体像を押さえたい方は、AI自動化ツール｜2026年版の比較と選び方も、こうしたツールを組み込む文脈の参考になります。

erd-editor：ER図をGUIで描きながらSQL DDLと相互変換し、設計を.erd.jsonファイルとしてGit管理できるオープンソースのER図エディタ。VSCode・IntelliJ・Webで動く
erd-editorは、ER図を「画像」ではなく「コード（.erd.jsonファイル）」として扱えるようにした、Git管理できるER図エディタ。
この記事のポイント
  • ・erd-editorは、DBスキーマをコードとして扱えるオープンソースのER図エディタ（約1,700★）。
  • ・ER図とSQL DDLを相互変換でき、設計は.erd.jsonファイルとしてGit管理できる。
  • ・VS Code拡張・IntelliJプラグイン・Webアプリの3形態で使える。
  • ・Webアプリはリアルタイム共同編集・E2E暗号化・PWAオフライン・ローカルファーストに対応。
  • ・MySQL・PostgreSQL・SQLite・OracleのDDL書き出しに対応。

1. erd-editorとは：DBスキーマをコードとして扱えるER図エディタ

erd-editorのアプリ画面。テーブルとリレーションをGUIで配置してER図を描くエディタ
erd-editorの編集画面。テーブルとリレーションをGUIで配置してER図を組み立てる。出典: dineug/erd-editor README

erd-editorは、データベースのテーブル構造とその関係（リレーション）を、GUIで視覚的に設計できるER図エディタです。ER図（Entity-Relationship Diagram）とは、「どんなテーブルがあり、それらがどう繋がっているか」を図で表したもので、データベース設計の共通言語です。

erd-editorが並のER図ツールと決定的に違うのは、設計を“画像”ではなく“ファイル”として残す点にあります。描いたER図は .erd.json（または .json）というテキストファイルとして保存されます。これが何を意味するかというと——ER図をGitでバージョン管理でき、プルリクエストで差分をレビューでき、コードと同じリポジトリに置けるということです。

・スキーマ＝ファイル：ER図が.erd.jsonというテキストになり、Gitで履歴を追える
・SQLと双方向：SQL DDLをインポートして図に起こし、図からSQL DDLを書き出せる
・エディタ統合：VS CodeやIntelliJの中で、コードと並べてスキーマを編集できる

つまりerd-editorは、これまで「デザインツールの世界」に閉じていたER図を、「コードの世界」に引っ張り込んだツールだと言えます。スキーマ設計を、コードレビューやバージョン管理といったエンジニアの流儀にそのまま乗せられる——これが最大の価値です。

この発想は、近年広がる「Everything as Code（すべてをコードとして扱う）」の潮流とも重なります。インフラをコードで定義する（Infrastructure as Code）、ドキュメントをコードで管理する（Docs as Code）——と同じように、erd-editorは「スキーマ設計をコードとして扱う（Schema as Code）」を実現します。図という“非テキスト”の成果物を、テキストのファイルに落とし込むことで、Gitの恩恵（履歴・ブランチ・レビュー・巻き戻し）がまるごと使えるようになる。ER図が長年「作ったはいいが、その後の管理に困る」お荷物だったのは、まさに“非テキスト”だったからです。erd-editorは、その根本原因を「ファイル化」という一点で解決した、と言い換えることもできます。

ひとことで
  • ・erd-editor＝ER図を「画像」でなく「Git管理できるファイル」として扱えるエディタ。
  • ・設計・SQL・コードを同じリポジトリ・同じエディタで回せるのが核心。

2. なぜ必要か：GUI専用ツールの「バージョン管理できない」問題を解決

GUI専用ER図ツールの課題（設計がツールに閉じる・バージョン管理不可・SQLと二重管理・共有が面倒）を、erd-editorがファイル化・Git管理・SQL相互変換で解決する対比図
解決するのは「ER図がコードのように扱えない」という、設計にまつわる根深い不便さ。

erd-editorが解決するのは、多くのER図ツールが構造的に抱える「設計がツールに閉じる」問題です。きれいな図は描けても、その後の運用でつまずく——という経験には、多くのエンジニアに心当たりがあるはずです。

具体的な不便はこうです。

・バージョン管理できない：GUIツール内に設計が閉じ、Gitで履歴やレビューができない
・SQLと二重管理：図とDDLを別々に管理するため、片方を直し忘れて食い違う
・共有が面倒：チームに渡すには画像を書き出して貼るしかなく、編集を引き継げない
・エディタを行き来：コードはVS Code、図は別ツール、と作業が分断される

erd-editorは、これらを「設計をファイルにする」という一手で丸ごと解決します。バージョン管理には.erd.jsonのGit管理で応え、SQL二重管理にはDDLとの相互変換で応え、共有にはファイルをリポジトリで共有することで応え、エディタの行き来にはVS Code/IntelliJ統合で応える——という具合です。1つの発想（スキーマ＝ファイル）が、4つの不便を同時に解消しています。

誤解しないでほしい点
  • ・erd-editorはあくまで「設計・可視化」のツール。実データベースを直接操作する管理ツールではない。
  • ・SQLインポートは方言に柔軟だが万能ではない。複雑なDDLは一部未対応の可能性がある。

この不便が効いてくるのは、設計が一度きりで終わらず、チームで継続的に育てていくほどです。個人の使い捨てなら画像1枚でも困りませんが、スキーマが変化し続け、複数人でレビューする現場では、「図がGit管理できない」ことが日々の摩擦になります。erd-editorは、その摩擦を「設計をコードと同じ流儀で扱う」ことで消しにいきます。とりわけ、開発初期にER図で全体像を固め、その後もマイグレーションのたびに図を更新していく——という“生きた設計ドキュメント”の運用では、この差が決定的です。図が古びて実態と乖離した「死んだドキュメント」になるか、コードと一緒に更新され続ける「生きたドキュメント」になるか。erd-editorは後者を、特別な規律を強いることなく、日常のGitワークフローの中で自然に実現します。ドキュメントが陳腐化する最大の原因は「更新の手間」ですが、その手間をコード変更と一体化させることで、陳腐化そのものを起きにくくしているのです。設計とコードが同じリポジトリで同じ歴史を刻む——これは地味ながら、チームの認識のズレを防ぐ強力な仕掛けです。新しくチームに入ったメンバーが、リポジトリを見れば最新のスキーマ設計をそのまま把握できる、という副次的なメリットも生まれます。ドキュメントを別の場所に探しに行く必要がなく、コードのそばに常に最新の設計図がある——これは想像以上に開発体験を軽くします。

3. 主な機能：SQL DDL相互変換・.erd.json・エディタ統合

VS Code内で動くerd-editor。.erd.jsonファイルを開いてエディタ内でER図をGUI編集できる
VS Code内のerd-editor。コードと同じエディタで.erd.jsonを開き、GUIでER図を編集できる。出典: dineug/erd-editor README

erd-editorの機能は、「設計をコードとして回す」ために必要なものが一通りそろっています。柱ごとに見ていきましょう。

SQL DDLの相互変換：既存のデータベースから.sqlファイル（CREATE TABLE文など）をインポートすると、テーブル・キー・インデックスを解析してER図に起こします。逆に、描いたER図からSQL DDLを書き出すこともできます。パーサーはベンダーを問わず柔軟に読めるよう作られています。

多彩なエクスポート：SQL DDLはMySQL・PostgreSQL・SQLite・Oracleといったベンダーの方言で書き出せます。加えて、エディタで定義したスキーマのJSONや、ORMオブジェクトの生成にも対応します。ここで「ORMオブジェクトの生成」に対応しているのは実務的に大きく、設計したテーブルを、アプリ側のモデル定義の下地としてそのまま活かせます。図を描く→DDLを書く→ORMモデルを書く、という3つの手作業が、erd-editorでは「図を描く」を起点に生成で繋がっていくわけです。ベンダーを問わずに設計を始め、書き出すときに対象を選ぶ——この「設計はDB非依存、出力時に具体化する」流れが、複数DBを扱う現場でも効いてきます。

.erd.jsonによるファイル管理：設計は.erd.json/.jsonとしてプロジェクト内に保存され、Gitでの管理・レビューが自然にできます。

エディタ統合：VS Code拡張（dineug.vuerd-vscode）とIntelliJプラグインがあり、IDEの中でER図を編集できます。コードとスキーマを同じ場所で扱えます。

マルチプラットフォーム：ブラウザで使えるWebアプリ（erd-editor.io）、IDE拡張、スタンドアロンと、複数の形態で提供されます。主要な使い方を整理すると次のとおりです。

形態 主な用途 特徴
VS Code拡張 コードと並べて設計 .erd.jsonをエディタ内で編集・Gitコミット
IntelliJプラグイン JetBrains系IDEで設計 .erd/.erd.jsonをIDE内で開く
Webアプリ ブラウザで手軽に/共同編集 PWAオフライン・リアルタイム共同編集・E2E暗号化
設計思想が効くところ
  • ・SQL⇄ER図の双方向変換で、「既存DBから図を起こす」も「図からDDLを作る」も両対応。
  • ・.erd.jsonという“テキストのスキーマ”が、Git・レビュー・CIといった開発文化に乗る。

ER図そのものを、テキストの関係として捉えると、たとえば次のような構造を可視化することになります（これはMermaidのER図記法による例で、erd-editorが扱う「テーブルと関係」のイメージです）。

erDiagram USER ||--o{ ORDER : places ORDER ||--|{ ORDER_ITEM : contains PRODUCT ||--o{ ORDER_ITEM : "included in" USER { int id PK string email } ORDER { int id PK int user_id FK }

erd-editorは、こうした「テーブルと関係」をGUIで直感的に組み立て、それをテキストのファイルとSQLの両方に落とせるようにした、という理解が分かりやすいでしょう。

「スキーマをファイルとして扱える」ことが、実務でどう効くのかを具体的に考えてみましょう。たとえば、新しいカラムを1つ追加する変更を考えます。GUI専用ツールなら、図を直して、別途マイグレーションSQLを手で書き、両者が食い違っていないかを目視で確認する——という二度手間が発生します。erd-editorなら、GUIで図にカラムを足すと.erd.jsonが更新され、その差分がGitのdiffとして残ります。プルリクエストを出せば、レビュアーは「どのテーブルに何が増えたか」をコードレビューの流儀で確認でき、必要なら書き出したDDLと合わせてマイグレーションに繋げられます。「設計変更が、コードの変更とまったく同じワークフローに乗る」——この一貫性が、チーム開発でのスキーマ管理を劇的に楽にします。

さらに、.erd.jsonがテキストである意味は、CI（継続的インテグレーション）にも及びます。スキーマファイルをリポジトリに置いておけば、「スキーマが変わったらDDLを再生成する」「命名規則をチェックする」といった自動化を、通常のコードと同じパイプラインの中で回せます。ER図が“画像の添付ファイル”だった時代には不可能だった運用が、ファイル化によって初めて現実になるのです。

4. Webアプリの強み：PWAオフライン・リアルタイム共同編集・E2E暗号化

erd-editor Webアプリの特徴：PWAオフライン動作・リアルタイム共同編集・エンドツーエンド暗号化・ブラウザ自動保存（ローカルファースト）・タブ間同期
Webアプリ版の強み。手軽さと共同編集を、プライバシーを保ちながら両立する。

「IDEに入れるほどでもないが、サッと図を描いて共有したい」——そんなときに効くのがWebアプリ版（erd-editor.io）です。ブラウザだけで動きながら、実用的な機能を備えます。

・PWA対応（オフラインで動く）：インストールして、ネットが無くても使える
・リアルタイム共同編集：複数人で同時に同じER図を編集できる
・エンドツーエンド暗号化：共同編集しても、内容は暗号化されて守られる
・ローカルファースト：ブラウザに自動保存され、作業が消えにくい
・タブ間同期：複数のブラウザタブ間でリアルタイムに同期

注目すべきは、共同編集とプライバシーを両立している点です。リアルタイムで一緒に編集できるのに、エンドツーエンド暗号化でデータが守られる。多くのオンライン設計ツールが「便利さのためにデータを預ける」構図になりがちな中で、erd-editorのWeb版は「手軽さ・共同編集・プライバシー」を同時に狙っているのが特徴です。

使い分けの目安
  • ・コードと一緒に設計を育てる → VS Code / IntelliJ（.erd.jsonをGit管理）。
  • ・サッと描いて複数人で共同編集 → Webアプリ（PWA・共同編集・E2E暗号化）。

5. 使い方：VS Codeで.erd.jsonを開く・SQLをインポートする

erd-editorの使い方：VS Code拡張を入れて.erd.jsonを新規作成→GUIで設計、または既存の.sqlをインポート→ER図に起こし→SQL DDL/JSONで書き出す流れ
基本の流れ。新規に描くか、既存SQLから起こすか。どちらもファイルとして残る。

使い方はシンプルです。ここでは代表的なVS Code拡張での流れを紹介します。まず拡張機能をインストールします（VS Codeの拡張マーケットプレイスで「ERD Editor」を検索、または dineug.vuerd-vscode）。

導入後の使い方は、大きく2通りです。

・ゼロから描く：.erd.json ファイルを新規作成して開くと、GUIのER図エディタが立ち上がる。テーブルとリレーションを配置して設計する
・既存DBから起こす：手元の .sql（DDL）ファイルをインポートし、テーブル・キー・インデックスを解析してER図に変換する

設計ができたら、SQL DDL（対象ベンダーの方言）やJSONとして書き出して使います。そして最大のポイントは、その.erd.jsonをそのままGitにコミットできること。以降はコードと同じように、ブランチを切り、差分をレビューし、履歴を追えます。使い始めの流れをまとめると、こうなります。

・VS Code拡張「ERD Editor」をインストールする
・.erd.json を新規作成する（または既存の .sql をインポートする）
・GUIでテーブル・リレーションを設計する
・SQL DDL / JSON にエクスポートして使う
・.erd.json をGitにコミットし、レビュー・共有する

「描く → ファイルで残す → Gitに乗せる」——この流れに乗るだけで、ER図が“お荷物”から“管理できる資産”に変わります。ブラウザで試したいだけなら、インストール不要のWebアプリ（erd-editor.io）から触るのが手軽です。

6. 導入判断：向いている人・注意点

erd-editorの導入判断：スキーマをGit管理したい人・VSCode中心の開発者・既存DBを図で把握したい人に刺さる一方、実DB操作ツールではない点や複雑DDLの制約が注意
導入判断の観点。青は価値が出る条件、⚠️は用途の見極めどころ。

最後に、導入すべきかの判断材料を整理します。

erd-editorが向いている人

・スキーマ設計をGitで管理し、コードと同じ流儀でレビューしたい
・VS CodeやIntelliJ中心で開発しており、図も同じエディタで扱いたい
・既存のデータベースをER図で把握したい（SQLインポート）
・有償ツールを使わず、無料でER図設計を完結させたい
・チームで共同編集しつつ、プライバシーも守りたい（Web版）

慎重に判断すべきケース

・実データベースの直接操作・管理が主目的（erd-editorは設計・可視化寄り）
・非常に複雑・特殊なDDLをインポートしたい（方言によっては一部未対応の可能性）
・厳密なリバースエンジニアリングを全自動で完璧に求める（手直し前提で使う）

他のER図・スキーマ設計ツールと比べたときの、erd-editorの立ち位置も整理しておきましょう。dbdiagram.ioのようなDSLベースのツールは「テキストで書く」点は近いですが、GUIでの直感的な編集や、VS Code内での完結という点でアプローチが異なります。draw.io（diagrams.net）のような汎用作図ツールは自由度が高い反面、SQLとの相互変換や.erd.jsonのようなスキーマ特化のファイル管理はありません。DBeaverのようなDBクライアントはER図を描けますが、主目的は実データベースの操作であり、設計をコードとしてGit管理する用途とは軸が違います。erd-editorのユニークさは、「GUIの直感性」「SQLとの双方向」「ファイルとしてのGit管理」「エディタ統合」を1つに束ねた点にあります。どれか1つなら代替はありますが、この組み合わせを無料で提供するツールは多くありません。

いくつか具体的な注意点も押さえましょう。まず設計・可視化のツールであること。erd-editorはER図を描き・SQLと変換するツールで、実データベースを直接いじる管理ツール（DBクライアント）ではありません。次にSQLインポートは万能ではないこと。パーサーはベンダーに柔軟ですが、複雑な方言や特殊構文は一部読めない可能性があり、インポート後の手直しを前提にするのが安全です。裏を返せば、手描きやGUI専用ツールに比べれば圧倒的に「コードとして扱いやすい」のがerd-editorの立ち位置です。

導入前チェック
  • ・設計・可視化ツールであり、DBクライアント（実データ操作）ではない。
  • ・SQLインポートは方言に柔軟だが完璧ではない。取り込み後の確認・手直しを前提に。
  • ・チーム共同編集はWeb版、コードと一緒の管理はIDE拡張、と用途で使い分ける。

まとめ

erd-editorは、「ER図を、画像ではなくコードとして扱う」という発想で、データベース設計の“お荷物”を“管理できる資産”に変えるツールです。SQL DDLと相互変換でき、設計は.erd.jsonとしてGitに乗り、VS CodeやIntelliJの中で、あるいはブラウザで共同編集できる——スキーマ設計を、エンジニアの日常のワークフローにそのまま溶け込ませます。

結論
  • ・erd-editorは、DBスキーマをコードとして扱えるオープンソースのER図エディタ（約1,700★）。
  • ・ER図とSQL DDLを相互変換でき、設計は.erd.jsonとしてGit管理・レビューできる。
  • ・VS Code・IntelliJ・Webアプリの3形態。Web版は共同編集・E2E暗号化・PWAに対応。
  • ・MySQL/PostgreSQL/SQLite/OracleのDDL書き出しに対応。
  • ・設計・可視化ツールであり、実DB操作ツールではない。SQLインポートは手直し前提で。

改めて振り返ると、erd-editorの価値は「高機能さ」ではなく「設計を、開発の日常に溶け込ませたこと」にあります。ER図を描くツールは他にもありますが、その成果物がGitに乗り、コードレビューに乗り、CIに乗る——という“開発文化との地続き”を、無料で、VS Codeの中で実現したところに、多くのエンジニアが支持を寄せているのでしょう。データベース設計を「特別なイベント」ではなく「コードを書くのと同じ日常作業」に変える。地味ですが、日々効いてくるタイプの改善です。

「ER図がGitで管理できない」というモヤモヤに心当たりがあるなら、まずはWebアプリ（erd-editor.io）で触るか、VS Codeに拡張を入れて.erd.jsonを1つ作ってみてください。開発ツールを自動化・効率化の文脈で捉え直したい方は、AI自動化ツール｜2026年版の比較と選び方も合わせてどうぞ。

参照ソース

・dineug/erd-editor (GitHub) — 公式リポジトリ。機能・対応エディタ・ファイル形式の一次ソース。
・erd-editor 公式ドキュメント — インポート/エクスポートや使い方の詳細を記す公式ドキュメント。
・ERD Editor（VS Code Marketplace） — VS Code拡張の配布ページ。