VS CodeでER図を作成する

執筆 WorksCove 2026年8月31日更新日 2026年9月4日

VS Codeの拡張機能を使えば、新しいER図の作成、ドキュメント内の描画、接続中のDB構造の確認をエディタ内で行えます。

VS CodeのER図ツールは、専用編集、ドキュメント用の描画、自由作図、DB構造の確認で役割が異なります。以下は2026年8月時点の情報で、インストール前にマーケットプレイスの発行者名も確認します。

拡張機能を選ぶ三つの基準

入れる前に三つ決めておくと、候補がすぐ絞れます。

保存されるファイルはテキストか。 チームでリポジトリに置いて一緒に管理するつもりなら、ここがいちばん重要です。テキストで保存される形式は変更点がdiffで見えてコードレビューに載せられますが、画像ファイルでは何が変わったのか分かりません。

DDLをやり取りできるか。 すでに動いているDBがあるなら、CREATE TABLE文を読み込んで図にできるか、描いた結果をDDLとして書き出せるかが作業量を左右します。絵しか描けない拡張機能は絵で終わります。

結果をどこに貼るのか。 READMEに載せる図、会議資料用の画像、実際のDBに適用するスキーマのどれが目的かで、向く拡張機能が変わります。

ERD Editor：エディタの中の専用ER図ツール

発行者：dineug

VS Codeの中で本格的にER図を描くなら、この拡張機能がいちばん近いです。インストールして .erd.json の拡張子で空ファイルを作って開くと、専用の編集画面が立ち上がります。

テーブルとカラムを作ってリレーションをつなぐ基本操作はもちろん、リレーションの個数も0または1、ちょうど1、0以上、1以上の四通りから指定できます。カラスの足の記法で使う組み合わせと同じ体系なので、記号に自信がなければER図の記号まとめを横に置いておくとよいです。

実務で効いてくるのは読み込みと書き出しです。SQL DDLを貼り付ければVS Codeの中でER図を自動生成でき、逆に描いた結果をDDLとして取り出せます。DBMLやGraphQLスキーマからの読み込みにも対応しています。本番DBのスキーマを一度読み込んでおけば、その後はエディタの中で構造を確認できます。

ファイルがテキストベースなのでリポジトリに置いて管理するのにも向きます。ブラウザやIntelliJでも同じエディタが使えるため、メンバーごとに道具が違っても同じファイルを共有できます。

Mermaid：ドキュメントにそのまま入る図

発行者：Matt Bierner（Markdown Preview Mermaid Support）

READMEやWikiに構造図を載せるのが目的なら、専用のER図ツールは要りません。Markdownの文書にMermaidのコードブロックを書き、プレビュー拡張機能を入れれば、エディタの中でレンダリングされた図をそのまま確認できます。

erDiagram
  MEMBERS ||--o{ POSTS : "投稿"
  POSTS ||--o{ COMMENTS : "コメント"

この方式の利点は、成果物がコードだということです。gitにそのまま入り、変更履歴がdiffとして残り、GitHubでも同じ図が描画されます。文法とリレーション記号の読み方はMermaidでER図を書くに掲示板の例でまとめてあります。

代わりに配置を自分で調整できず、データ型やインデックスといった細かい情報は載せにくいです。ドキュメント用の要約図として使い、精密な設計は別のツールに任せる役割分担がよく合います。

Draw.io Integration：自由に描きたいとき

発行者：hediet

draw.ioをVS Codeの中でそのまま使う拡張機能です。.drawio、.dio、.drawio.svg、.drawio.png のファイルをエディタで開くと、draw.ioの編集画面が立ち上がります。オフライン版が同梱されているので、ネット接続なしでも動きます。

ER図だけでなくシステム構成図やフロー図まで、一つのリポジトリで同じツールに揃えたいときに向きます。Entity Relationの図形ライブラリを有効にすればカラスの足のコネクタもそのまま使えます。図形の出し方とリレーション線の指定はdraw.ioでER図を書く方法にまとめてあります。

覚えておくと便利なのは、同じ .drawio ファイルをXMLとしても開けて、両方の画面が同期する点です。テキストで開いて値をまとめて直し、図で確認するという進め方ができます。Live Shareを使って複数人で同じダイアグラムを一緒に編集することもできます。

MSSQL拡張機能のスキーマデザイナー：SQL Serverなら

発行者：Microsoft（MSSQL拡張機能）

SQL Serverを扱っているなら、選択肢がもう一つあります。MicrosoftのMSSQL拡張機能にスキーマデザイナーが入り、2026年に正式機能になりました。T-SQLを直接書かずに、画面上でテーブル、外部キー、主キー、制約を作成・編集できます。

検索、ドラッグ＆ドロップ、フィルタ、ズーム、ミニマップ、自動整列に対応しているので、テーブルの多いスキーマでも扱いやすいです。変更内容を視覚的に確認してスクリプトを生成するところまで、一つの画面でつながります。

SSMSで同じ作業をする手順はSSMSでデータベースダイアグラムを作成するにまとめてあります。エディタの中で完結させたいのか、SSMSのダイアグラム機能を使うのかで選べば大丈夫です。

Database Client：接続中のDBの構造を見る

発行者：cweijan

新しく描くのではなく、すでにあるDBの構造を確認するのが目的なら、DBクライアント系の拡張機能が速いです。Database ClientはMySQLやPostgreSQLをはじめ多数のデータベースに接続し、SQLエディタとデータグリッドを提供しつつ、ER図の表示にも対応しています。

接続情報を入れるだけなので、スキーマをファイルに取り出す手順が省けます。ただし拡張機能の中で見る図なので、接続権限のない人に見せる必要があるなら、画像かDDLとして取り出す一手間が別に要ります。

インストールする前に確認すること

マーケットプレイスには似た名前の拡張機能がいくつも並びます。入れる前に三つだけ確認すると失敗が減ります。

発行者の名前を見ます。 同じ機能をうたう拡張機能が複数あることがあるので、この記事に書いた発行者と一致しているかを確認してから入れるほうが安全です。拡張機能のページ上部に発行者名が表示されています。

最終更新の時期を見ます。 何年も更新のない拡張機能は、VS Codeのバージョンが上がると動かなくなることがあります。ダウンロード数や評価より、最終更新日のほうが実用的な手がかりです。

オフラインで動くかを確認します。 閉じたネットワークで作業する環境なら、外部通信が必要な拡張機能は使えません。Draw.io Integrationのようにオフライン版を同梱しているものは、こうした環境でも問題なく動きます。

ERD Editorで最初のダイアグラムを作る

入れたら実際に描いてみるのが早いです。手順はこうです。

プロジェクトの中に schema.erd.json のように .erd.json で終わる空ファイルを作ります。
ファイルを開くと、テキストエディタではなくER図の編集画面が立ち上がります。
テーブルを追加して名前を入れ、カラムとデータ型を埋めます。主キーにするカラムに印を付けます。
親テーブルから子テーブルへリレーションをつなぎ、個数を指定します。
エクスポートでDDLを選ぶと、CREATE TABLE文が得られます。

すでに動いているDBがあるなら、手順3から始める必要はありません。先にDDLを読み込んで全体を載せ、新しく足すテーブルだけ描くほうがずっと速いです。DDLの取り出しコマンドはSQLからER図を自動生成するのステップ1にDBMSごとにまとめてあります。

Mermaidで掲示板を丸ごと描くと

先ほどの例はリレーション二行だけでしたが、実際のドキュメントではカラムまで書きます。掲示板を四テーブルで描くとこうなります。

erDiagram
  MEMBERS ||--o{ POSTS : "投稿"
  MEMBERS ||--o{ COMMENTS : "コメント"
  CATEGORIES ||--o{ POSTS : "分類"
  POSTS ||--o{ COMMENTS : "コメント"

  MEMBERS {
    bigint id PK
    varchar email UK
    varchar nickname
  }
  POSTS {
    bigint id PK
    bigint member_id FK
    int category_id FK
    varchar title
  }

リレーションを上にまとめ、テーブル定義を下に置くと、コードの最初の数行だけで構造が読み取れます。変更が入ったときも、関係が変わったのかカラムが変わったのかがdiffで分かれて見えます。

場面ごとの組み合わせ例

拡張機能を一つに絞るより、チームの進め方に合わせて二つ三つを使い分ける形が多いです。

ドキュメントを中心に置くチーム。 READMEやWikiに構造図を維持するのが目的なら、Mermaidプレビューだけで足ります。スキーマが変わったらコードブロックを直し、レビューでdiffとして確認すれば済みます。画像ファイルを別に管理する必要がありません。

設計を頻繁に行うチーム。 機能ごとにテーブルを足すなら、ERD Editorで設計してDDLに書き出す流れが合います。.erd.json をリポジトリに置き、マイグレーションのファイルと一緒にレビューへ出せば、構造の変更がコードレビューの中で扱われます。

SQL Serverを使うチーム。 MSSQL拡張機能のスキーマデザイナーでエディタ内から設計し、結果をスクリプトとして取り出して適用する流れが自然です。SSMSも併用しているならSSMSでデータベースダイアグラムを作成するの内容とつながります。

用途別にまとめると

拡張機能	ファイル形式	DDL読み込み	DDL書き出し	拡張機能なしで閲覧
ERD Editor（dineug）	`.erd.json`（テキスト）	対応（DBML・GraphQLも）	対応	不可
Mermaidプレビュー（bierner）	Markdownのコードブロック	なし	なし	GitHub・GitLabで描画
Draw.io Integration（hediet）	`.drawio` 系（XML）	なし	なし	`.drawio.png`・`.drawio.svg`なら可
MSSQLスキーマデザイナー（Microsoft）	DBスキーマを直接編集	接続で代替	スクリプト生成	不可
Database Client（cweijan）	接続ベース	接続で代替	ツールの機能次第	不可

実際に効いてくるのは右の二列です。DDLをやり取りできればツールを変えても資産が残り、拡張機能なしで見られれば、チームの外に見せるときの手間がなくなります。設計まで行うならERD Editor、ドキュメントが目的ならMermaid、既存DBを見るのが目的ならDBクライアント系です。

画像ファイルがそのまま原本になる方式

Draw.io Integrationで知っておくとよいことが一つあります。ファイルを .drawio.png や .drawio.svg で保存すると、そのファイルは普通の画像でありながら、同時に編集できる原本になります。画像ビューアでは絵として開き、VS Codeではエディタとして開きます。

WikiやIssueにそのまま貼れば絵として見え、リポジトリにある同じファイルを開けばすぐ直せます。原本と画像を別々に管理していて片方だけ古くなる、という問題がこの方式では起きません。

ただし画像ファイルなので、gitではdiffが見えません。変更履歴をレビューしたいダイアグラムならテキスト形式のほうが向き、ドキュメントに貼っておいて時々手を入れる図ならこの方式が快適です。

チームで使うときに考えておくこと

ファイル形式が協業のやり方を決めます。 テキストで保存される形式なら、リポジトリに置いてdiffでレビューできます。スキーマの変更をコードレビューと同じ流れで扱いたいなら、ここが効いてきます。逆に画像ファイルは何が変わったのか確認できず、二人が同時に直すとコンフリクトの解消も難しくなります。

拡張機能のインストールを前提にしない経路を一つ残しておきます。 企画担当や他チームに構造を見せる場面は必ず来ます。拡張機能を入れていない人でも見られるように、画像として書き出す手順かリンクで共有する経路を決めておくと、そのとき慌てずに済みます。

拡張機能の顔ぶれは変わります。 いま使っている拡張機能が数年後も維持されている保証はありません。だからこそ、原本をDDLかテキストで残しておく習慣が安全です。DDLさえあれば、拡張機能がなくなっても別のツールで描き直せます。DDLの取り出し方はSQLからER図を自動生成するにDBMSごとにまとめてあります。

よくある質問

VS Codeだけでer図を作成できますか？

作成できます。ERD Editor拡張機能を入れると、エディタの中にテーブルを作ってリレーションをつなぐ専用画面が開き、SQL DDLの読み込みやDDLへの書き出しもできます。ドキュメントに載せる図が目的なら、Mermaidのプレビュー拡張機能だけでも足ります。

既存DBの構造をVS Codeで見られますか？

DBに接続する拡張機能を使えば見られます。Database Client系の拡張機能は接続したデータベースのテーブルをER図として表示しますし、SQL Serverを使っているならMicrosoftのMSSQL拡張機能に入っているスキーマデザイナーが使えます。

拡張機能で描いたER図をチームで共有するには？

拡張機能ごとにファイル形式が違うので方法が分かれます。相手も同じ拡張機能を入れているならファイルをそのままリポジトリに置けばよく、拡張機能を入れていない人に見せるなら、画像として書き出すかDDLを取り出してブラウザのツールに入れるほうが確実です。

ER図のファイルをgitで管理してもよいですか？

テキストベースの形式ならおすすめできます。MermaidのコードやERD Editorのファイルのようにテキストで保存される形式は、変更点がdiffで見えるのでレビューできます。逆に画像のようなバイナリファイルは何が変わったのか分からず、コンフリクトの解消も難しいので、原本はテキストで持ち、画像は必要なときに作るほうがすっきりします。

設計にはERD Editor、ドキュメントにはMermaid、自由作図にはDraw.io Integration、既存DBの確認にはDBクライアント系の拡張機能を使います。ER図の原本をDDLまたはテキストで保存すれば、拡張機能を変更しても再利用できます。

エディタの外へ図を持ち出す段階になったら、DDLをWorksCove ERDに貼り付けてダイアグラムとテーブル定義書を作り、リンクで共有する方法もあります。ブラウザで使える無料ツールの比較は無料オンラインER図ツール5つを比較にまとめてあります。