静的な画像を超えて:Mermaid と AI ツールを活用した図をコードとして扱う力の解放
ドキュメント危機
すべてのエンジニアリングチームはその苦しみを知っている。数週間をかけて美しいマイクロサービスアーキテクチャを設計し、ステークホルダーを感動させるように細部まで丁寧にVisioの図を描く。6か月後、システムは進化している——新しいサービスが追加され、データベースが移行され、APIエンドポイントが非推奨になっているが、図は時間の流れに取り残されている。それは遺物だ。事実とは違う。
これが「ドキュメント腐敗(doc-rot)」であり、エンジニアリング生産性の静かな殺し手だ。図が嘘をついていると、開発者はそれを見過ごす。開発者がドキュメントを無視すると、伝統的な知識が支配する。システムを知っている唯一の人物が去ったとき、複雑なコードベースと地図のない状態が残される。
図をコードとして扱う(DaC)がその解決策であり、その中心にあるのはMermaid、プレーンテキストを美しいビジュアルに変換するJavaScriptベースの図作成ツールだ。

核となる哲学:図をソフトウェアのように扱う
図をコードとして扱うという根本的な変化は、アプリケーションコードと同じ厳密さで図を扱うということだ。つまり、次のようになる:
1. バージョン管理は標準
図が.mermaidファイルであるとき、それはソースコードと一緒にGitリポジトリに存在する。すべての変更が追跡される。git blameで、どの人が新しいサービスを追加したかを確認できる。git diff変更をマージする前に確認でき、いつでも以前の状態に戻せる。

gitGraph
commit id: "初期アーキテクチャ"
commit id: "ユーザー・サービスを追加"
branch feature/order-service
commit id: "注文サービス v1"
commit id: "決済ゲートウェイを追加"
checkout main
merge feature/order-service
commit id: "APIゲートウェイを更新"
例:MermaidのGitグラフ構文を使って、図自身のGit履歴を可視化する
2. 図に対するコードレビュー
プルリクエストはもはやコードだけのものではない。開発者が新しいサービスを提案したり、データフローを変更したりすると、その変更はPR内で読みやすいdiffとして表示される。レビュアーは図そのものにコメントでき、アーキテクチャ上の意思決定がマージ前に議論され承認されることを保証できる。
3. CI/CDパイプラインとの統合
あなたの図はパイプライン内で自動的に生成され、検証される。GitHub Actionが次のことを行うと想像してみてください:
-
すべてのMermaid図をPNG/SVG形式でレンダリングする
-
それらをドキュメントサイトにアップロードする
-
無効なMermaid構文が検出された場合、ビルドを失敗させる

flowchart LR
A[開発者がコードをプッシュ] --> B[CIパイプラインを実行]
B --> C[テストを実行]
B --> D[Mermaid図をレンダリング]
D --> E{構文が正しいか?}
E -->|はい| F[ドキュメントにアップロード]
E -->|いいえ| G[ビルド失敗&チームに警告]
F --> H[アプリケーションをデプロイ]
G --> I[開発者が構文を修正]
I --> A
例:図の検証とデプロイ用のCI/CDワークフロー
Mermaidの実際の活用:実世界の例
実際の例を交えて、Mermaidがサポートする図の種類を一緒に見ていきましょう。
例1:マイクロサービスアーキテクチャ(フローチャート)
これは最も一般的な用途です—サービス間の通信を可視化することです。

flowchart TB
subgraph "クライアント層"
MobileApp[モバイルアプリ]
WebApp[Webアプリケーション]
end
subgraph "APIゲートウェイ"
Gateway[APIゲートウェイ]
end
subgraph "マイクロサービス"
UserSvc[ユーザーサービス]
OrderSvc[注文サービス]
ProductSvc[製品サービス]
PaymentSvc[支払いサービス]
end
subgraph "データ層"
UserDB[(ユーザーDB)]
OrderDB[(注文DB)]
ProductDB[(製品DB)]
Redis[(Redisキャッシュ)]
end
subgraph "外部サービス"
Stripe[Stripe決済]
EmailAPI[メールAPI]
end
MobileApp --> Gateway
WebApp --> Gateway
Gateway --> UserSvc
Gateway --> OrderSvc
Gateway --> ProductSvc
Gateway --> PaymentSvc
UserSvc --> UserDB
UserSvc --> Redis
OrderSvc --> OrderDB
OrderSvc --> Redis
ProductSvc --> ProductDB
ProductSvc --> Redis
PaymentSvc --> Stripe
OrderSvc --> EmailAPI
PaymentSvc --> EmailAPI
例:キャッシュ、データベース、外部依存関係を含む完全なマイクロサービスアーキテクチャ
例2:ユーザー認証フロー(シーケンス図)
シーケンス図は、サービス間の複雑な相互作用を文書化するのに最適です。

sequenceDiagram
autonumber
participant User
participant Frontend
participant AuthSvc as 認証サービス
participant UserDB as ユーザーデータベース
participant Cache as Redisキャッシュ
participant EmailSvc as メールサービス
User->>Frontend: 認証情報入力
Frontend->>AuthSvc: POST /login (メールアドレス、パスワード)
AuthSvc->>UserDB: メールアドレスでユーザーを照会
UserDB-->>AuthSvc: ハッシュ化されたパスワードとユーザー情報を返却
AuthSvc->>AuthSvc: bcryptでパスワードを検証
alt 正しい認証情報
AuthSvc->>AuthSvc: JWTトークンを生成
AuthSvc->>Cache: セッションを保存(キー:user_id、有効期限:1時間)
AuthSvc-->>Frontend: 200 OK + JWTトークン
Frontend-->>User: ダッシュボードにリダイレクト
else 不正な認証情報
AuthSvc->>EmailSvc: ログイン失敗アラートを発動
AuthSvc-->>Frontend: 401 Unauthorized
Frontend-->>User: エラーメッセージを表示
end
Note over AuthSvc,EmailSvc: 5回の失敗後、アカウントを15分間ロック
例:成功と失敗のパスを詳細に示した認証フロー。キャッシュやアラートなどの副作用を含む
例3:AWS上のクラウドインフラ構造(クラス図)
クラス図はコード以外にも使える—クラウドリソースとその関係性をモデル化できる。

classDiagram
class VPC {
+string cidr_block
+string region
+createSubnet()
+deleteSubnet()
}
class Subnet {
+string availability_zone
+string cidr_block
+boolean is_public
+attachRouteTable()
}
class EC2Instance {
+string instance_type
+string ami_id
+int storage_gb
+start()
+stop()
+reboot()
}
class RDSDatabase {
+string engine
+string version
+int storage_gb
+boolean multi_az
+takeSnapshot()
+restoreFromSnapshot()
}
class S3Bucket {
+string bucket_name
+string region
+boolean versioning_enabled
+uploadFile()
+downloadFile()
}
class IAMRole {
+string role_name
+string policy_document
+attachPolicy()
+detachPolicy()
}
VPC "1" --> "*" Subnet
Subnet "1" --> "*" EC2Instance
Subnet "1" --> "0..1" RDSDatabase
VPC "1" --> "0..*" S3Bucket
EC2Instance --> IAMRole
RDSDatabase --> IAMRole
例:プロパティとメソッドを持つクラスとしてAWSインフラをモデル化し、ドキュメント作成やインフラストラクチャとしてのコード(IaC)計画に役立てる
例4:ECOMMERCE注文処理(ステート図)
ステート図は、エンティティが異なるステータス間をどのように遷移するかを示すのに優れています。

stateDiagram-v2
[*] --> カート: ユーザーがアイテムを追加
カート --> チェックアウト: ユーザーがチェックアウトへ進む
チェックアウト --> 支払い保留中: ユーザーが注文を提出
支払い保留中 --> 支払い処理中: 支払いゲートウェイを開始
支払い処理中 --> 支払い完了: 支払い成功
支払い処理中 --> 支払い失敗: 支払いが拒否された
支払い失敗 --> チェックアウト: ユーザーが支払いを再試行
支払い失敗 --> [*]: ユーザーがカートを放棄
支払い完了 --> 注文確認済み: 確認メールを送信
注文確認済み --> 処理準備中: 倉庫に割り当て
処理準備中 --> 発送済み: 運送業者に引き渡し
発送済み --> 途中配送中: 運送業者が引き取り
途中配送中 --> 配達完了: 配達が確認された
配達完了 --> レビュー依頼済み: ユーザーにレビューを依頼
レビュー依頼済み --> [*]: ユーザーがレビューを提出
配達完了 --> 返金依頼中: ユーザーが返金を申請
返金依頼中 --> 返金承認済み: サポートが承認
返金承認済み --> 返金処理済み: 金額が返還
返金処理済み --> [*]: 注文が完了
state "高リスク詐欺検査" as フラウドチェック {
[*] --> スコア確認
スコア確認 --> 低リスク: スコア < 50
スコア確認 --> 高リスク: スコア >= 50
高リスク --> 手動レビュー: チームにフラグを立てる
手動レビュー --> 低リスク: 承認済み
手動レビュー --> 支払い失敗: 拒否済み
}
支払い保留中 --> フラウドチェック: リスク評価がトリガーされた
フラウドチェック --> 支払い処理中: 低リスク
例:詐欺検出を内包した状態を持つ完全なeコマース注文ステートマシン
例5:GitHubのイシューを用いたスプリント計画(Gitグラフ)
Gitグラフは、Git自体の範囲を超えたワークフローを表現できます。

gitGraph
commit id: "スプリント計画" type: HIGHLIGHT
branch スプリント-1
commit id: "ユーザーストーリー #101: ログインページ"
commit id: "ユーザーストーリー #102: ユーザー登録"
branch バグ修正/ホットフィックス
commit id: "ホットフィックス: 認証トークンの有効期限切れ"
checkout スプリント-1
merge バグ修正/ホットフィックス
commit id: "ユーザーストーリー #103: パスワードリセット"
checkout main
merge スプリント-1 tag: "v1.0.0"
branch スプリント-2
commit id: "機能 #201: ショッピングカート"
commit id: "機能 #202: チェックアウトフロー"
branch 実験/aiレコメンデーション
commit id: "POC: MLレコメンデーションエンジン"
checkout スプリント-2
commit id: "機能 #203: 注文履歴"
checkout main
merge スプリント-2 tag: "v2.0.0"
commit id: "リリースノート: スプリント1および2完了"
例:プロジェクト管理、スプリント、機能ブランチをGitグラフとして可視化
図解におけるAI革命
メルヘイドの洗練された美しさにもかかわらず、構文は障壁となることがあります。システムを文書化している最中に、ずれた矢印や欠落した括弧のデバッグを誰が望むでしょうか?
ここがAIを活用したツールがすべてを変えるポイントです。
AI自動修正
このようなツールとしてVPasCode(Visual Paradigmの図をコードで表現するプラットフォーム)およびメルヘイドチャートは、Google GeminiやOpenAIなどのAIモデルを統合しており、次のような機能が可能です:
-
自動検出構文エラー
-
修正ワンクリックで破損した図を修正
-
提案図の構造の改善点
実際に見てみましょう:
破損したメルヘイドコード:

flowchart LR
A[フロントエンド] --> B(APIゲートウェイ
B --> C[ユーザー サービス]
C --> D[(データベース
D --> E[キャッシュ]
AIで修正されたコード:

flowchart LR
A[フロントエンド] --> B(APIゲートウェイ)
B --> C[ユーザー サービス]
C --> D[(データベース)]
D --> E[キャッシュ]
AIは閉じ括弧や閉じカッコの欠落を認識し、即座に修正します。
自然言語から図への変換
おそらく最も強力な機能は、自然言語の記述から図を生成することです。 OpenDocs (VPのドキュメンテーションプラットフォーム)、単に望む内容を説明するだけで済みます:
「ユーザーがログインする様子を示すフローチャートを作成してください。認証情報が有効な場合、ダッシュボードにリダイレクトしてください。無効な場合、エラーを表示し、3回の試行を許可してください。3回失敗した後はアカウントをロックしてください。」
AI生成のMermaid:

flowchart TD
Start([ユーザーがログインを試行]) --> EnterCreds[メールアドレスとパスワードを入力]
EnterCreds --> Validate{認証情報の検証}
Validate -->|有効| Dashboard[ダッシュボードにリダイレクト]
Validate -->|無効| CheckAttempts{試行回数 < 3}
CheckAttempts -->|はい| Increment[試行回数カウンターを増加]
Increment --> ShowError[エラーメッセージを表示]
ShowError --> EnterCreds
CheckAttempts -->|いいえ| LockAccount[アカウントを15分間ロック]
LockAccount --> SendAlert[セキュリティアラートメールを送信]
SendAlert --> End([プロセス終了])
Dashboard --> End
図の形式間の変換
AIは異なる図形式間の変換も行えます。PlantUMLの図をMermaidに変換したい場合、AIツールが対応できます:
PlantUML 入力:

@startuml
actor ユーザー
participant "フロントエンド" as FE
participant "バックエンド" as BE
database "DB" as DB
ユーザー -> FE: ログインをクリック
FE -> BE: POST /login
BE -> DB: SELECT user
DB --> BE: ユーザーデータ
BE --> FE: JWTトークン
FE --> ユーザー: ダッシュボードを表示
@enduml
AI変換されたMermaid:

sequenceDiagram
actor ユーザー
participant フロントエンド
participant バックエンド
participant データベース
ユーザー->>フロントエンド: ログインをクリック
フロントエンド->>バックエンド: POST /login
バックエンド->>データベース: SELECT user
データベース-->>バックエンド: ユーザーデータ
バックエンド-->>フロントエンド: JWTトークン
フロントエンド-->>ユーザー: ダッシュボードを表示
インタラクティブチャットボット統合
一部のプラットフォームでは、図作成用のチャットボットインターフェースを提供しています。会話が可能です:
ユーザー: 「私のアーキテクチャ図に『在庫サービス』という新しいサービスを追加してください。」
AI:「既存の製品サービスおよび注文サービスに接続された在庫サービスを追加します。」
図は自動的に更新されます
ユーザー:「実際には、新しいデータベース『InventoryDB』にも接続するようにしてください。」
AI:「完了しました。在庫サービスは現在、製品サービス、注文サービス、および新しいInventoryDBに接続されています。」
図をコードとしてワークフローに統合する
ステップ1:小さなところから始める
一度にすべてのシステムを図示しようとしないでください。単一のコンポーネントから始めましょう——たとえば認証フロー、または開発中の新しい機能などです。
ステップ2:ドキュメントに埋め込む
ドキュメント(例:.mermaidフォルダ内)に併記してください。ビルドプロセス中にレンダリングするには、mermaid-cliなどのツールを使用してください。mermaid-cliビルドプロセス中にそれらをレンダリングします。
ステップ3:VPasCodeの統合エンジンを活用する
多様な好みを持つチームで作業している場合、VPasCodeは非常に価値があります。1つの場所で複数の図をコードとして記述する言語をサポートしています:
# VPasCodeでは、以下のように混在して使用できます:
diagrams/
├── architecture.mermaid
├── deployment.puml # PlantUML
├── database-erd.mermaid
└── workflow.d2 # D2言語
ステップ4:CI/CDで自動化する
GitHub ActionsまたはGitLab CIにステップを追加します:
- name: Mermaid図のレンダリング
run: |
for file in $(find docs -name "*.mermaid"); do
npx @mermaid-js/mermaid-cli -i $file -o ${file%.mermaid}.png
done
- name: ドキュメントサイトへのアップロード
run: |
aws s3 sync docs/ s3://your-docs-bucket/
ステップ5:プルリクエストでレビューする
すべてのアーキテクチャ変更には図の更新が必要であることをポリシーにしましょう。視覚的な変更についてはプルリクエストのコメントを使用して議論します:
レビュアー:「キャッシュは注文サービスとデータベースの間に配置すべきではないでしょうか?現在はユーザー・サービスにのみ接続されています。」
著者:「良い指摘です。図を更新します。」
現実世界への影響:事例研究
MermaidとVPasCodeを用いて図をコードとして採用したフィンテックスタートアップを考えてみましょう:
-
導入前:47個の静的Visioファイル、ほとんどが6か月以上前のもの。新入社員はアーキテクチャを理解するために3週間を費やしていた。
-
導入後:Mermaidで作成した図が12個あり、すべてGitに保存され、各機能追加ごとに更新される。新入社員は1週目から生産的になっていた。
チームのCTOは次のように述べた。「図がコンプライアンスのチェックボックスから開発プロセスの生きる一部へと変化しました。新しいアーキテクチャについて議論する際、Mermaidエディタを開き、実際にコードで図を描き出します。これは画期的な変化です。」
未来:継続的ドキュメント化
最終的な目標は「継続的ドキュメント化」であり、インフラ構成やコードから図が自動的に生成される仕組みです。すでに次のようなツールが登場しています:
-
Kubernetesのマニフェストをスキャンし、サービスのトポロジー図を生成する
-
OpenAPI/Swaggerファイルを解析し、APIのフロー図を作成する
-
クラウドリソースを監視し、アーキテクチャ図を自動更新する
Mermaidはこの動きの中心にあり、機械が生成できる一方で人間が理解できるシンプルなテキスト形式を提供しています。
今日から始める
静的な画像の枠を越えてみませんか?以下のアクションプランをご覧ください:
-
Mermaid拡張機能をインストールするお気に入りのIDE(VS Code、IntelliJ)に
-
最初の図を作成する を
.mdファイルにMermaidの構文を使って -
VPasCodeの無料トライアルを試す AI駆動の図作成を体験するために
-
動的なドキュメントリポジトリを開始する コードベースと並行して
-
この記事をチームと共有する そして会話を始める
あなたのアーキテクチャは、忘れ去られたフォルダにある埃をかぶった図よりも、ずっと良いもの deserves。図を重要な資産として扱う時が来ています。




