SQLからER図を自動生成する：DDLから図まで

2026年8月12日

すでに稼働中のDBがあるなら、ER図を手で描く理由はありません。スキーマはもうDBの中にあります。DDLとして取り出してツールに渡せば、図は自動で出来上がります。

この記事では、SQLからER図を作る方法3つを比較したうえで、ECサイトのDBをひとつ用意し、DDLの取り出しから図の完成まで実際の画面で確認します。

方法は3つ、状況で選べばいい

SQLからER図への道は、大きく3通りです。

方法	向いている場面	必要なもの
DBツールの内蔵機能（MySQL Workbench、DBeaver）	使い慣れたツールで自分だけ構造を確認したいとき	DB接続
コードで生成（Mermaidなど）	ドキュメントにテキストとして埋め込み、gitで管理したいとき	変換スクリプト
ブラウザツールにDDLを貼り付け	編集・共有・定義書まで続けたいとき	DDLファイル

DBツールの内蔵機能: WorkbenchとDBeaver

追加インストールが要らないのが最大の利点です。

MySQL Workbenchでは、DatabaseメニューのReverse Engineerから接続とスキーマを選ぶとEER図が作られます。EERはEnhanced ERの略で、WorkbenchにおけるER図の拡張版の呼び名と考えれば大丈夫です。

DBeaverはさらに手軽です。接続したスキーマやテーブルを開くと、ER Diagramタブが最初からあります。選んだテーブルだけのカスタム図も作れます。

ただし、この図はDBに接続できる人しか見られません。接続権限のない企画担当や新しいメンバーに見せるには、結局画像に書き出して渡すことになり、スキーマが変わるたびに同じ作業が繰り返されます。図を編集して設計案を作ったり、テーブル定義書につなげたりするのも、この方式の守備範囲の外です。

コードで生成: Mermaidなどのテキスト図

DDLをMermaid記法に変換するスクリプトを使う（またはAIに変換を頼む）方式です。結果がテキストなので、Markdownにそのまま入り、変更がgit diffで見えるのが魅力です。READMEやWikiに構造図を固定する用途では、これに勝るものはありません。

その代わり、結果はほぼ読み取り専用です。配置を整えたりカラムを直したりする作業はコードをまた触ることになり、データ型・インデックス・コメントといった細部は記法の表現力の限界でかなり省かれます。

ブラウザツールに貼り付け

DDLファイルがひとつあればよく、DB接続もインストールも不要です。出来上がった図はその場で編集でき、リンクで共有でき、テーブル定義書にもつながります。上のふたつと違って「見る」で終わらず「作業を続ける」ための方式です。

この記事の実習はこの方法で進めます。

ステップ1: DBからDDLを取り出す

どの方法でも、始まりはDDLです。DBMSごとに1行で済みます。

# MySQL / MariaDB — データなし、スキーマのみ
mysqldump -u USER -p --no-data mydb > schema.sql

# PostgreSQL — 必ずplain（テキスト）形式で
pg_dump -U USER --schema-only -Fp mydb > schema.sql

肝心なのは --no-data（PostgreSQLは --schema-only）です。ER図に必要なのはCREATE TABLE文だけなのでデータを出す理由がなく、実データがファイルに出ないためセキュリティレビューでも引っかかりません。数GBのDBでも、スキーマだけなら数十KBのテキストです。

PostgreSQLにはもうひとつ注意点があります。形式がplain（-Fp）である必要があります。 バックアップでよく使われるcustom形式（-Fc）はバイナリアーカイブで、開いてもテキストではないため、どのツールにも貼り付けられません。custom形式のバックアップしか手元にない場合は、pg_restoreでテキストに展開すれば大丈夫です。

# custom形式のバックアップ（-Fc）をplain SQLに変換
pg_restore --schema-only -f schema.sql backup.dump

一部のテーブルだけ必要なら、名前を後ろに並べます。

# 注文まわりのテーブルだけ
mysqldump -u USER -p --no-data mydb orders order_items payments > orders.sql

GUIが楽ならそちらでも構いません。DBeaverならテーブルを選んで右クリック → DDLの生成。OracleはSQL Developerのエクスポート（DDLのみ）、SQL ServerはSSMSのタスク → スクリプトの生成で同じものが得られます。

手元にあるファイルでも大丈夫です。マイグレーションフォルダのSQL、同僚から渡されたダンプ、Wikiに貼ってあったCREATE TABLE文 — 出どころがどこでも、DDLなら材料になります。

ステップ2: 貼り付けて取り込む

ECサイトのDBで実際にやってみます。会員、カテゴリ、商品、注文、注文明細、決済 — 6テーブルの典型的なECの骨格です。全部載せると長くなるので、2テーブルだけ抜き出すとこんな形です。

CREATE TABLE orders (
  id           BIGINT AUTO_INCREMENT PRIMARY KEY,
  member_id    BIGINT NOT NULL COMMENT '注文会員',
  status       VARCHAR(20)   NOT NULL DEFAULT 'PAID' COMMENT '注文ステータス',
  total_amount DECIMAL(12,2) NOT NULL COMMENT '注文合計',
  ordered_at   DATETIME      NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '注文日時',
  CONSTRAINT fk_orders_member FOREIGN KEY (member_id) REFERENCES members (id)
) COMMENT='注文';

CREATE TABLE order_items (
  id         BIGINT AUTO_INCREMENT PRIMARY KEY,
  order_id   BIGINT NOT NULL COMMENT '所属注文',
  product_id BIGINT NOT NULL COMMENT '注文商品',
  quantity   INT NOT NULL COMMENT '数量',
  unit_price DECIMAL(12,2) NOT NULL COMMENT '注文時点の単価',
  CONSTRAINT fk_order_items_order   FOREIGN KEY (order_id)   REFERENCES orders (id),
  CONSTRAINT fk_order_items_product FOREIGN KEY (product_id) REFERENCES products (id)
) COMMENT='注文明細';

WorksCove ERDでプロジェクトの読み込み → SQLスキーマの読み込みを開き、ファイルをアップロードするかテキストをそのまま貼り付けます。

SQLスキーマ読み込みダイアログにECサイトのDDLを貼り付けた画面（WorksCove ERD）

読み込みモードがふたつある点は覚えておくと便利です。既存テーブルを残して追加するモードは作業中の図にテーブルを足し、削除して読み込むモードはゼロから作り直します。初回ならどちらでも結果は同じです。

読み込みを押すと、6テーブルがリレーション線までつながった状態でキャンバスに現れます。配置が散らかっていたら自動整列を使えばよく、方式が5種類（Grid、Force-directed、Hierarchical、Circular、Orthogonal）あるのでスキーマの性格で選べます。FKで上下の流れがある業務スキーマなら、Hierarchicalがいちばん読みやすいことが多いです。参照される側が上、参照する側が下と、階段状に並ぶためです。

DDLから自動生成されたECサイトのER図 — 6テーブルとFKのリレーション線（WorksCove ERD）

ここまで、手で描いたものはひとつもありません。カラムも、データ型も、FKの線も、日本語コメントも、すべてDDLから来ています。実際にかかる時間は、DDLを取り出す時間がほぼすべてです。リレーション線のカラスの足の記号の読み方は、ER図の記号まとめに別途あります。

おまけも付いてきます。DDLのCOMMENTがカラムの説明として取り込まれるので、Physicalビュー（物理名）とLogicalビュー（論理名）を切り替えて見られます。開発者は member_id で読み、企画担当には「注文会員」で見せる、という使い分けです。本番DBにコメントを地道に付けてきたチームなら、その資産がここで生きてきます。

DBMSの種類だけは必ず合わせる

注意点はひとつだけです。取り込み画面のプロジェクトDBMSタイプを、実際のDDLと一致させてください。

同じCREATE TABLEでも、DBMSごとに文法が少しずつ違うからです。パーサーを4種類作る中で確認した代表的な違いを挙げると、こうなります。

カラムコメントの位置が違います。 MySQLはカラム定義の中に COMMENT '説明' を書きますが、PostgreSQLはCREATE TABLEの後に COMMENT ON COLUMN ... 文が別に出てきます。MySQL基準でしか読まないパーサーにpg_dumpの結果を入れると、テーブルはできるのにコメントだけがごっそり抜け落ちます。
型の体系が違います。 MySQLの AUTO_INCREMENT はPostgreSQLでは bigserial またはIDENTITY構文になり、Oracleのダンプには NUMBER(10,0) のような別体系の型やTABLESPACEなどのストレージ指定が一緒に付いてきます。
ダンプにはスキーマ以外の文が混ざります。 実際のmysqldumpファイルには SET 文やロック関連の文が、pg_dumpには所有者・権限の設定文が入っています。パーサーがこれらを自然に読み飛ばせないと、1行目からエラーになります。

だからこそ、ツールが自分のDBMSのダンプをそのまま読めるかどうかは、思った以上に重要です。WorksCove ERDはMySQL/MariaDB、PostgreSQL、Oracle、SQL Serverの4種類のDDLをそれぞれの文法どおりにパースし、書き出しも同じ4種類に対応しています。MySQLで取り込んだスキーマをPostgreSQLのDDLとして出すDBMS間変換もでき、その際はデータ型の対応まで文法に合わせて変わります。

ファイルを作るのも面倒なら: DBに直接接続

DDLファイルを作るステップ自体も省略できます。リバースエンジニアリング、つまりDBに直接接続してスキーマを読み取る機能を使えば、接続情報を入れてテーブルを選ぶだけです。WorksCove ERDのリモートデータベース読み込みは4つのDBMSすべてに対応し、外部から接続できないDBのためにSSHトンネル経由の接続もできます。

スキーマが定期的に変わるDBを追いかけるときに、この方式は特に楽です。変わるたびにダンプファイルを作って運ぶ代わりに、再接続して取り込み直せば終わりだからです。

本番DBの認証情報を外部ツールに入れるのが気になるなら、無理をする必要はありません。スキーマ参照権限だけの読み取り専用アカウントを別に作るか、最初の方法どおりDDLファイルを貼り付ければ、同じ結果が得られます。

図ができたあとにやること

レガシーDBを引き継いだ場面を思い浮かべると、図ができるのは把握の終わりではなく始まりです。ER図ができれば、同じデータで続けられる仕事があります。

テーブル定義書を出す。 スキーマはもうツールの中にあるので、カラム定義表はドキュメントタブからすぐ出ます。検収や引き継ぎで提出する定義書を、Excelで一から作り直す必要はありません。作り方と形式はテーブル定義書の作り方にまとめてあります。

設計バリデーションを回す。 PKの欠落、循環参照、FKインデックスといった項目を自動で点検できます。長く運用されたDBほど、「なんでこうなってるんだ？」という箇所が検証リストとして一覧になるのが役に立ちます。AIが作ったスキーマを同じ方法で検証する例はAIでER図を作るで扱っています。

チームに共有する。 読み取り専用の共有リンクを作れば、DB接続権限のないメンバーも構造を見られます。「最新の図をもう一回出して」という依頼と、そのたびの画像書き出しが一緒になくなります。

変更を反映し続ける。 スキーマが変わったら、新しいDDLを取り込み直すかDBに再接続すれば済みます。バージョンを残しておけば、リリース間で構造がどう動いたかも比較できます。

流れをまとめると3ステップです。DDLを取り出し、貼り付け、整列する。今日、手元のそのDBで一度試してみてください。思ったより早く終わって、拍子抜けするかもしれません。

よくある質問

データも一緒にエクスポートする必要がありますか？

いいえ。ER図に必要なのはテーブル構造だけなので、スキーマだけで十分です。mysqldumpなら --no-data オプションでCREATE TABLE文だけを出力できます。ファイルは軽くなり、実データが外に出ないためセキュリティ面でも安心です。

DDLファイルを作らず、DBに直接接続して取り込めますか？

リバースエンジニアリング対応のツールなら可能です。WorksCove ERDはMySQL/MariaDB、PostgreSQL、Oracle、SQL Serverに直接接続してスキーマを読み取れます。本番DBの認証情報を外部ツールに入れるのが気になる場合は、DDLファイルを出力して貼り付ける方法でも同じ結果になります。

テーブル数がかなり多いのですが、全部入りますか？

ツールごとの無料枠だけ確認してください。WorksCove ERDの無料プランはプロジェクトあたり40テーブルまでで、立ち上げ期のサービスならおおむね収まります。それより大きいスキーマなら、主要なドメインのDDLだけ切り出して取り込むのも実用的です。

図の画像しかなくてDDLがない場合は？

画像からスキーマを自動復元する標準的な方法はありません。現実的な近道は、画像をAIに見せてDDLを書いてもらうことです。受け取ったDDLを貼り付ければ、この記事の流れがそのまま使えます。