【AI時代の図形】設計系3選 — Structurizr・DBML・Diagrams(Python)徹底比較

当サイトを閲覧いただきありがとうございます。本記事はAI時代にコード管理できる図形シリーズの第4回として、ドメイン特化型の設計系3種を比較解説します。シリーズ全体の一覧は完全ガイドをご覧ください。

MermaidやD2は何でも描ける汎用ツールでしたが、本記事で扱う3つはそれぞれ特定の設計領域に特化しています。その分、自分の得意領域では汎用ツールとは比べものにならない表現力と生産性を出してくれます。

AI時代にこれらのツールが重要になる理由は明確で、設計意図をAIに伝えるだけで、そのまま仕様書に使える図が出力されるからです。たとえば「ECサイトのDB設計をDBMLで」と指示すればテーブル定義からリレーションまで一式出てきますし、「AWS上のマイクロサービス構成をDiagramsで」と頼めば公式アイコン入りの図が生成されます。設計と図の作成が同時に完了するこのワークフローは、AIなしの時代には考えられなかったものです。

3種比較表

Structurizr DSL — C4モデルでアーキテクチャを構造化

Structurizr DSLは、Simon Brown氏が提唱した「C4モデル」に基づいてソフトウェアアーキテクチャ図をコードで記述するためのツールです。

C4モデルとは、システムを4段階のズームレベル（全体俯瞰 → サービス構成 → 内部構造 → コード詳細）で整理する手法です。Structurizrは一つの定義ファイルからこの4段階の図を自動生成できます。MermaidやD2のように「図を1枚ずつ描く」のではなく、「システムの構造を定義すれば複数の図が自動で出てくる」という根本的に異なるアプローチです。

サンプル：ECサイトのモデル定義

workspace {
    model {
        user = person "ユーザー" "Webアプリを利用する一般ユーザー"
        admin = person "管理者" "システム管理を行う内部スタッフ"

        softwareSystem = softwareSystem "ECサイト" "オンラインショッピングシステム" {
            webapp = container "Webアプリケーション" "React SPA" "TypeScript"
            api = container "APIサーバー" "REST API" "Node.js"
            db = container "データベース" "ユーザー・商品・注文データ" "PostgreSQL" "Database"
            cache = container "キャッシュ" "セッション・商品キャッシュ" "Redis" "Database"
        }

        emailSystem = softwareSystem "メール配信" "注文確認メール送信" "External"
        paymentSystem = softwareSystem "決済システム" "クレジットカード決済" "External"

        user -> softwareSystem "商品の閲覧・購入"
        admin -> softwareSystem "商品管理・注文管理"
        softwareSystem -> emailSystem "メール送信"
        softwareSystem -> paymentSystem "決済処理"
    }

    views {
        systemContext softwareSystem "SystemContext" {
            include *
            autoLayout
        }
        container softwareSystem "Containers" {
            include *
            autoLayout
        }
    }
}

一つのモデル定義から、Level 1のコンテキスト図（俯瞰）とLevel 2のコンテナ図（詳細）を同時に生成できます。

サンプル：デプロイメント図

    model {
        deploymentEnvironment "Production" {
            deploymentNode "AWS" {
                deploymentNode "ap-northeast-1" {
                    deploymentNode "ECS Cluster" {
                        containerInstance api
                    }
                    deploymentNode "RDS" {
                        containerInstance db
                    }
                }
                deploymentNode "CloudFront" {
                    containerInstance webapp
                }
            }
        }
    }

物理的なデプロイ構成も同じDSLで表現できます。

メリット・デメリット

Mermaidとの決定的な違いは、「図を描く」のではなく「モデルを定義する」点です。一つのモデル定義から複数の抽象度の図を自動生成できるので、経営層向けの俯瞰図と開発者向けの詳細図が同じファイルから出てきます。図同士の情報が食い違う心配がなくなるのは、大規模プロジェクトでは本当に助かります。

その分導入のハードルは高いです。DSLの構文に加えてC4モデルの概念（Context/Container/Component/Code）の理解が前提になりますし、C4の枠組みに収まらない図（フローチャートやシーケンス図）は描けません。5〜10人規模のチームならMermaidで十分かもしれません。

なお、Structurizrにはクラウド版（有料）とLite版（無料・Docker）があります。

AIとの相性

DSLの構文が構造化されているので、AIに生成させやすい部類です。私も試しに「ECサイトのアーキテクチャをC4モデルで記述して」とClaude（このサイトの記事執筆に使っているAIです）に投げてみましたが、person・softwareSystem・containerの階層構造がきれいに出力されました。ただし、viewsブロックの自動レイアウト設定やデプロイメントノードの記述はたまに構文エラーが混じるので、生成後にStructurizr Liteでプレビューして確認するのが無難です。

DBML — データベース設計をコードで管理

DBMLはHolistics社が開発した、データベーススキーマをテキストで記述する専用言語です。テーブル定義やリレーションをシンプルな構文で書くと、自動でER図が生成されます。

dbdiagram.ioというWebツールと連携しており、ブラウザ上でリアルタイムにER図をプレビューできます。DBMLからSQLへの変換もできます。

サンプル：ブログシステムのスキーマ

Table users {
  id integer [pk, increment]
  username varchar [not null, unique]
  email varchar [not null, unique]
  password_hash varchar [not null]
  role varchar [default: 'user']
  created_at timestamp [default: `now()`]

  Note: 'ユーザーマスターテーブル'
}

Table posts {
  id integer [pk, increment]
  title varchar [not null]
  body text
  status post_status [default: 'draft']
  user_id integer [not null]
  category_id integer
  published_at timestamp
  created_at timestamp [default: `now()`]
}

Table categories {
  id integer [pk, increment]
  name varchar [not null, unique]
  slug varchar [not null, unique]
}

Table comments {
  id integer [pk, increment]
  body text [not null]
  post_id integer [not null]
  user_id integer [not null]
  created_at timestamp [default: `now()`]
}

Enum post_status {
  draft
  published
  archived
}

Ref: posts.user_id > users.id
Ref: posts.category_id > categories.id
Ref: comments.post_id > posts.id
Ref: comments.user_id > users.id

[pk] で主キー、> で多対1、< で1対多、- で1対1のリレーションを表現します。TableGroup で論理的なグループ化もできます。

メリット・デメリット

CREATE TABLE の羅列と比べると、DBMLのスキーマ定義ははるかに読みやすく書きやすいです。ER図の自動生成、SQLへの変換（PostgreSQL/MySQL対応）、SQLからの逆変換もできるので、設計と実装を行き来しやすいのが実用的です。

用途はデータベース設計のみに限定されます。ER図のビジュアルプレビューはdbdiagram.io依存で、完全オフライン環境では使いにくい。ただ、DB設計だけならMermaidのER図より表現力が高いので、テーブル数が10を超えるような設計ではDBMLに軍配が上がります。

AIとの相性

DBMLはAIにとってかなり書きやすいフォーマットのようで、「ブログシステムのDBスキーマをDBMLで設計して」と投げると、テーブル定義・リレーション・インデックスまで含めた実用的なスキーマが返ってきます。特に便利なのが既存SQLからの変換で、CREATE TABLE 文を貼り付けて「DBMLに変換して」と頼むだけでほぼ正確に変換してくれます。DB設計はAIが最も得意とする領域の一つだと感じています。

Diagrams（Python） — クラウドアーキテクチャ図をPythonで描く

DiagramsはPythonコードでクラウドアーキテクチャ図を描くライブラリです。AWS・GCP・Azure・Kubernetesの公式アイコンが500種類以上組み込まれており、プロフェッショナルな図をコードだけで生成できます。内部的にはGraphvizを利用しています。

サンプル：AWSのWebアプリ構成

from diagrams import Diagram, Cluster
from diagrams.aws.compute import ECS
from diagrams.aws.database import RDS, ElastiCache
from diagrams.aws.network import ELB, CloudFront, Route53
from diagrams.aws.storage import S3

with Diagram("Web Application Architecture", show=False):
    dns = Route53("Route 53")
    cdn = CloudFront("CloudFront")
    lb = ELB("ALB")

    with Cluster("ECS Cluster"):
        svc = [ECS("App 1"), ECS("App 2"), ECS("App 3")]

    db = RDS("PostgreSQL")
    cache = ElastiCache("Redis")
    storage = S3("Static Assets")

    dns >> cdn >> lb >> svc
    svc >> db
    svc >> cache
    cdn >> storage

>> 演算子で接続を表現し、Cluster() でグルーピングします。

サンプル：マイクロサービス構成

from diagrams import Diagram, Cluster
from diagrams.aws.compute import ECS, Lambda
from diagrams.aws.database import RDS, DynamoDB
from diagrams.aws.integration import SQS, SNS
from diagrams.aws.network import APIGateway

with Diagram("Microservices", show=False, direction="TB"):
    api_gw = APIGateway("API Gateway")

    with Cluster("認証サービス"):
        auth = ECS("Auth")
        auth >> RDS("Auth DB")

    with Cluster("商品サービス"):
        product = ECS("Product")
        product >> DynamoDB("Product DB")

    with Cluster("注文サービス"):
        order = ECS("Order")
        order >> RDS("Order DB")

    api_gw >> [auth, product, order]
    order >> SQS("Queue") >> Lambda("Notify") >> SNS("Topic")

AWS、GCP、Azureのアイコンを混在させたマルチクラウド構成図も一つのスクリプトで描けます。

メリット・デメリット

PowerPointやdraw.ioでAWSアイコンを1つ1つ配置した経験がある人なら、公式クラウドアイコン500種以上が最初から入っているありがたみが分かると思います。Pythonコードなのでループで同じ構成を複数環境分生成したり、Terraformと同じリポジトリでインフラ図を管理したりできるのも開発者にとって自然な使い方です。

セットアップはPython環境とGraphvizの両方が必要でやや手間がかかります。また当然ですがクラウドアーキテクチャ図に特化しているので、フローチャートやシーケンス図が欲しければ別のツールと併用する前提です。

AIとの相性

PythonコードなのでAIにとっては生成しやすく、「AWSのサーバーレス構成をDiagramsで描いて」と依頼するとimport文からwith Diagramブロックまで一通り出力してくれます。ただし、存在しないアイコンクラス名を生成してしまうことがたまにあるので、公式ドキュメントのアイコン一覧と突き合わせる手間は発生します。>> 演算子のチェーンで接続を書く部分はほぼ間違えないので、import文だけ確認すれば大体動きます。

選定ガイド

実践Tips：設計ツールを開発フローに組み込む

DBMLをスキーマ管理の起点にする

DBMLはER図の可視化だけでなく、スキーマの正式な定義ファイルとして使えます。開発フローの例：

1. AIに「ユーザー管理のDB設計をDBMLで」と依頼
2. 出力されたDBMLをチームでレビュー（Git PR）
3. dbml2sql でSQLマイグレーション生成
4. dbdiagram.io or CI でER図を自動生成

既存DBからのリバースエンジニアリングも sql2dbml で可能なので、レガシーなデータベースの可視化にも使えます。

Diagrams(Python)をインフラコードと同じリポジトリで管理

Terraform/CDKなどのインフラコードと同じリポジトリに diagrams/ フォルダを置き、構成図をPythonスクリプトとして管理するのがおすすめです。インフラの変更PRに構成図の更新も含めることで、コードと図のズレが起きにくくなります。

導入方法

Structurizr

# Lite版（Docker）
docker run -it --rm -p 8080:8080 -v ./:/usr/local/structurizr structurizr/lite

# CLI版
java -jar structurizr-cli.jar export -workspace workspace.dsl -format plantuml

DBML

# CLIツール
npm install -g @dbml/cli

# DBMLからSQL変換
dbml2sql schema.dbml --postgres -o schema.sql

# SQLからDBML変換
sql2dbml schema.sql --postgres -o schema.dbml

ブラウザでdbdiagram.ioにアクセスすれば、インストール不要で使えます。

Diagrams（Python）

# Graphvizのインストール（必須）
brew install graphviz  # macOS
sudo apt install graphviz  # Ubuntu

# Diagramsのインストール
pip install diagrams

# 実行
python architecture.py

この記事に関連する記事

まとめ

本記事ではAI時代のコード管理図形として、ドメイン特化型の設計系3種を比較解説しました。如何だったでしょうか。

この3つに共通するのは、特定の領域に特化したことで汎用ツールより効率よく作業できる点です。アーキテクチャの体系的なドキュメント化にはStructurizr、DB設計にはDBML、クラウド構成図には**Diagrams(Python)**と、用途がはっきりしているならこちらの方が楽です。

しかもこの3つはいずれもAIとの相性が良いので、「設計の概要を伝えるだけでコードが出力される」という体験が得られます。これはなかなか便利ですよ。

次回はドメイン特化・ハードウェア系（WaveDrom、Railroad Diagram、Bytefield）について解説します。

シリーズ目次 → 『AI時代の図形』完全ガイド

各ツールの詳細は公式サイトも参考にしてください：Structurizr / DBML / Diagrams

それでは次の記事も閲覧いただけると幸いです。