はじめに:ドキュメント革命はここから始まります
ソフトウェア開発のスピードが速い世界において、私たちが全員直面する不快な真実があります:私たちのドキュメントは常に古びた状態にある私たちは、ドラッグ&ドロップの図描画ツールとの格闘に無数の時間を費やし、箱や矢印を手作業で慎重に整列させてきましたが、コードが変更された瞬間に、丹念に作成した視覚資料が陳腐化してしまうのをただ見守るしかなかったのです。
しかし、ドキュメントが開発のペースに追いつくことができたらどうでしょうか?プロフェッショナルなアーキテクチャ図の作成が、関数を書くのと同じくらい簡単になったらどうでしょうか?
Diagram-as-Code 革命へようこそ。このチュートリアルでは、VPasCode、チームがシステムアーキテクチャ図を作成、共有、維持する方法を変革する、ビジュアルパラダイム社のブラウザベースのプラットフォームについてご案内します。図をコードとして扱うことで、数時間ではなく数分で出版品質のビジュアルを生成する方法を発見し、ドキュメントがシステムとシームレスに進化することを保証できます。
マイクロサービスのドキュメント作成を行う開発者、ステークホルダーへのプレゼンテーションを行うアーキテクト、インフラのマッピングを行う DevOps エンジニアのいずれであっても、この包括的なガイドは、VPasCode をマスターし、チームのドキュメント作成の質を高めるためのスキルを身につけるために必要なものを提供します。
1. はじめに:5 分で最初の図を作成 {#getting-started}
インストール不要、設定不要、コードのみ
VPasCode の最も強力な機能の一つは、摩擦ゼロのオンボーディングです。インストールする必要も、アカウント作成も、複雑な設定もありません。今すぐ最初の図を作成しましょう。
ステップバイステップのクイックスタート:
-
VPasCode にアクセス:ブラウザを開いて、https://www.vpascode.com/editor/
-
エンジンを選択:ドロップダウンメニューから選択してください:
-
Mermaid – フローチャートやモダンなドキュメントに最適
-
PlantUML – UML やエンタープライズアーキテクチャに理想的
-
Graphviz – 複雑なネットワークトポロジに完璧
-
-
テンプレートを読み込む:「Examples」をクリックして、スタートテンプレートを選択
-
編集とプレビュー:左側のパネルでコードを修正すると、右側の図が即座に更新されるのを見ることができます
-
エクスポートまたは共有:SVG/PNG としてダウンロードするか、共有可能な URL をコピー

図1:VPasCodeは、テキストベースのコードを瞬時にプロフェッショナルなアーキテクチャ図に変換します
2. VPasCodeインターフェースの理解 {#interface}
構文の詳細に入る前に、まずワークスペースに慣れておきましょう。

図2:2分割されたVPasCodeインターフェース—左側にコード、右側にライブプレビュー
インターフェースコンポーネントの詳細:
左パネル(コードエディタ):
-
構文ハイライト対応のテキストエディタ
-
参照しやすい行番号
-
自動補完機能
-
リアルタイムでのエラーハイライト表示
右パネル(ライブプレビュー):
-
即時の視覚的レンダリング
-
パンおよびズーム操作コントロール
-
ベクトルベース表示(あらゆるズームレベルで鮮明)
-
クリックして要素を検証
上部ツールバー:
-
エンジンセレクター(Mermaid/PlantUML/Graphviz)
-
テンプレートギャラリー
-
エクスポートオプション(SVG、PNG、PDF)
-
共有ボタン(永続的なURLを生成)
-
設定と環境設定
下部ステータスバー:
-
構文検証ステータス
-
文字数カウント
-
最終保存時刻
-
キーボードショートカットリファレンス
コアワークフローの原則:
コード記述 → 即時プレビューの確認 → 改良 → エクスポート/共有
この即時フィードバックループこそが、VPasCodeをこれほど強力なものにしています。「レンダリング」ボタンをクリックする必要も、コンパイルを待つ必要もありません。タイピングするだけで、純粋で瞬時の視覚的フィードバックが得られます。
3. Mermaid.jsの習得:フローチャートとその先 {#mermaid-tutorial}
Mermaid.js は、開発者フレンドリーな図描画の事実上の標準となっています。その構文は直感的で読みやすく、コードと共に存在するドキュメントに最適です。
チュートリアル 1: ユーザー認証フローの作成
次のスプリント計画で使用する可能性のある、実用的な認証フローの図を作成してみましょう。
コード例:

graph TD
A[ユーザーが認証情報を入力] --> B{形式は有効?}
B -->|いいえ| C[検証エラーを表示]
B -->|はい| D[認証サービスへ送信]
C --> A
D --> E{認証情報が一致?}
E -->|いいえ| F[401 未認証を返す]
E -->|はい| G[JWT トークンを生成]
G --> H[HttpOnly Cookie にトークンを保存]
H --> I[ダッシュボードへリダイレクト]
F --> A
style A fill:#e1f5ff,stroke:#0066cc
style I fill:#d4edda,stroke:#28a745
style F fill:#f8d7da,stroke:#dc3545
ここで示されていること:
-
分岐ノード(菱形で
{?}) -
方向性のあるフロー(
TD= 上から下へ) -
色によるカスタムスタイル
-
自己参照ループ
-
明確なラベル付け
チュートリアル 2: マイクロサービスアーキテクチャ図
では、サービスの関係性を示すより複雑なシステムアーキテクチャを作成しましょう。
コード例:

graph LR
subgraph Client["クライアント層"]
Web[Web アプリ<br/>React]
Mobile[モバイルアプリ<br/>Flutter]
end
subgraph API["API ゲートウェイ"]
Gateway[ Kong Gateway ]
Auth[認証サービス]
Rate[レートリミッター]
end
subgraph Services["ビジネスサービス"]
User[ユーザーサービス]
Order[注文サービス]
Product[商品サービス]
Payment[決済サービス]
end
subgraph Data["データ層"]
UserDB[(ユーザー DB<br/>PostgreSQL)]
OrderDB[(注文 DB<br/>MongoDB)]
ProductDB[(商品 DB<br/>PostgreSQL)]
Cache[(Redis キャッシュ)]
end
Web --> Gateway
Mobile --> Gateway
Gateway --> Auth
Gateway --> Rate
Rate --> User
Rate --> Order
Rate --> Product
User --> UserDB
User --> Cache
Order --> OrderDB
Order --> Payment
Product --> ProductDB
Payment --> OrderDB
style Gateway fill:#ff6b6b,stroke:#c92a2a,color:white
style UserDB fill:#4ecdc4,stroke:#087f5b
style OrderDB fill:#4ecdc4,stroke:#087f5b
style ProductDB fill:#4ecdc4,stroke:#087f5b
style Cache fill:#ffe66d,stroke:#f08c00
主要概念:
-
subgraph論理的なグループ化用 -
LR左から右へのレイアウト用 -
複数行ラベル用
<br/> -
データベース円筒記法用
[( )] -
複雑なルーティングと関係
チュートリアル 3:注文処理のシーケンス図
シーケンス図は、コンポーネント間の時間的相互作用を理解するために不可欠です。
例コード:

sequenceDiagram
autonumber
participant C as Customer
participant W as Web App
participant O as Order Service
participant P as Payment Service
participant I as Inventory Service
participant N as Notification Service
C->>W: Add items to cart
C->>W: Click "Checkout"
W->>O: POST /orders {items, shipping}
O->>I: Reserve inventory
I-->>O: Reservation confirmed
O->>P: Process payment
P-->>O: Payment successful
O->>O: Create order record
O->>N: Send order confirmation
N-->>C: Email confirmation
O-->>W: 201 Created {orderId}
W-->>C: Show success page
Note over O,P: Critical section<br/>must be transactional
rect rgba(200, 200, 0, 0.2)
O->>P: Charge card
P-->>O: Transaction ID
end
シーケンス図の機能:
-
autonumber自動ステップ番号付け用 -
participant宣言用 -
->>同期呼び出し用 -
-->>応答用 -
ノート上注釈用 -
矩形セクションの強調表示用
チュートリアル 4: スプリント計画のためのガントチャート
Mermaid はプロジェクトのタイムライン可視化もサポートしています。
サンプルコード:

gantt
タイトル スプリント 24 - 認証モジュール
日付形式 YYYY-MM-DD
軸形式 %m/%d
セクション バックエンド
API 契約の設計 :完了, des1, 2024-06-01, 2日
JWT サービスの実装 :進行中, des2, 2024-06-03, 3日
データベースマイグレーション : des3, des2 の後, 2日
ユニットテスト : des4, des3 の後, 2日
セクション フロントエンド
ログインコンポーネント : front1, 2024-06-03, 3日
トークン管理 : front2, front1 の後, 2日
保護されたルート : front3, front2 の後, 2日
セクション 統合
API 統合 : int1, des4 の後, 2日
E2E テスト : int2, int1 の後, 3日
セキュリティ監査 : int3, int2 の後, 2日
4. PlantUML 深入り:エンタープライズアーキテクチャ {#plantuml-tutorial}
PlantUML は正式な UML ダイアグラムとエンタープライズアーキテクチャのドキュメント作成に優れています。実践的な例を見ていきましょう。
チュートリアル 1: E コマースプラットフォームのコンポーネント図
サンプルコード:

@startuml
!テーマ プレーン
skinparam 背景色 #FFFFFF
skinparam コンポーネントスタイル uml2
タイトル "E コマースプラットフォーム - コンポーネントアーキテクチャ"
パッケージ "プレゼンテーションレイヤー" {
[Web フロントエンド] as Web
[モバイルアプリ] as Mobile
[管理ダッシュボード] as Admin
}
パッケージ "API レイヤー" {
[API ゲートウェイ] as Gateway
[認証] as Auth
[レートリミッター] as RateLimit
}
パッケージ "ビジネスサービス" {
[カタログサービス] as Catalog
[注文サービス] as Order
[支払いサービス] as Payment
[配送サービス] as Shipping
[通知サービス] as Notify
}
パッケージ "データレイヤー" {
データベース "製品 DB" as ProdDB
データベース "注文 DB" as OrderDB
データベース "ユーザー DB" as UserDB
キュー "メッセージキュー" as MQ
}
Web --> Gateway
Mobile --> Gateway
Admin --> Gateway
Gateway --> Auth
Gateway --> RateLimit
Gateway --> Catalog
Gateway --> Order
Order --> Payment
Order --> Shipping
Order --> Notify
Catalog --> ProdDB
Order --> OrderDB
Auth --> UserDB
Payment ..> MQ : イベント公開
Shipping ..> MQ : イベント購読
Notify ..> MQ : イベント購読
@enduml

図 3: レイヤー構造を示す PlantUML コンポーネント図
チュートリアル 2: クラウドインフラストラクチャのデプロイメント図
サンプルコード:
チュートリアル 3: C4 モデル – コンテナ図
C4 モデルは、抽象化の複数のレベルでソフトウェアアーキテクチャを伝えるのに優れています。
サンプルコード:

@startuml
!define AWS_COLOR FF9900
!define DOCKER_COLOR 0DB7ED
skinparam componentStyle uml2
skinparam backgroundColor #FAFAFA
title「クラウド展開アーキテクチャ」
package「AWS リージョン:us-east-1」{
package「パブリックサブネット」{
[CloudFront CDN] as CDN
[アプリケーションロードバランサー] as ALB #AWS_COLOR
}
package「プライベートサブネット 1」{
[Web サーバー 1] as Web1 #DOCKER_COLOR
[Web サーバー 2] as Web2 #DOCKER_COLOR
}
package「プライベートサブネット 2」{
[API サーバー 1] as API1 #DOCKER_COLOR
[API サーバー 2] as API2 #DOCKER_COLOR
}
package「データ層」{
database「RDS プライマリ」as RDS1 #AWS_COLOR
database「RDS レプリカ」as RDS2 #AWS_COLOR
[ElastiCache Redis] as Cache #AWS_COLOR
}
package「ストレージ」{
[S3 バケット] as S3 #AWS_COLOR
[EFS 共有ストレージ] as EFS #AWS_COLOR
}
}
インターネット –> CDN
CDN –> ALB
ALB –> Web1
ALB –> Web2
Web1 –> API1
Web1 –> API2
Web2 –> API1
Web2 –> API2
API1 –> RDS1
API2 –> RDS1
RDS1 -[破線]> RDS2
API1 –> キャッシュ
API2 –> キャッシュ
API1 –> S3
API2 –> S3
Web1 –> EFS
Web2 –> EFS
@enduml
チュートリアル 4: ワークフローのアクティビティ図
サンプルコード:

@startuml
|顧客|
start
:商品を検索;
:カートに追加;
:チェックアウトへ進む;
|システム|
:カート内の項目を検証;
:合計金額を計算;
if (在庫あり?) then (はい)
:在庫を予約;
else (いいえ)
:在庫切れを表示;
stop
endif
|顧客|
:配送先住所を入力;
:支払い方法を選択;
|システム|
:支払い処理;
if (支払い成功?) then (はい)
:注文を作成;
:確認メールを送信;
:在庫を更新;
else (いいえ)
:支払いエラーを表示;
detach
endif
:注文を出荷;
:注文ステータスを更新;
stop
partition "バックグラウンドジョブ" {
:請求書を生成;
:倉庫に通知;
}
@enduml 5. Graphviz の基礎:複雑なネットワーク可視化 {#graphviz-tutorial}
Graphviz(DOT言語)は、レイアウトアルゴリズムが重要な複雑な関係やネットワークトポロジの可視化に優れています。
チュートリアル 1:マイクロサービス依存関係グラフ
サンプルコード:

図4:マイクロサービスの依存関係とデータフローを示すGraphviz可視化
digraph MicroservicesDependencies {
rankdir=TB;
node [shape=box, style="rounded,filled", fontname="Arial"];
edge [fontname="Arial", fontsize=10];
// 色付きノード定義
node [fillcolor="#e3f2fd"];
"API Gateway" [fillcolor="#ffcdd2"];
"Service Mesh" [fillcolor="#fff9c4"];
// コアサービス
"User Service";
"Auth Service";
"Order Service";
"Payment Service";
"Inventory Service";
"Notification Service";
"Analytics Service";
// データベース
node [shape=cylinder, fillcolor="#c8e6c9"];
"User DB";
"Order DB";
"Product DB";
"Analytics DB";
// 外部サービス
node [shape=box, fillcolor="#f3e5f5", style="dashed,filled"];
"Payment Gateway";
"Email Service";
"SMS Service";
// 関係性
"API Gateway" -> "Service Mesh";
"Service Mesh" -> "User Service";
"Service Mesh" -> "Auth Service";
"Service Mesh" -> "Order Service";
"Service Mesh" -> "Payment Service";
"Service Mesh" -> "Inventory Service";
"User Service" -> "User DB";
"Auth Service" -> "User DB";
"Order Service" -> "Order DB";
"Order Service" -> "Inventory Service";
"Order Service" -> "Payment Service";
"Inventory Service" -> "Product DB";
"Payment Service" -> "Payment Gateway";
"Notification Service" -> "Email Service";
"Notification Service" -> "SMS Service";
"Analytics Service" -> "Analytics DB";
"Order Service" -> "Notification Service" [style=dashed];
"Payment Service" -> "Notification Service" [style=dashed];
// グループ化のためのサブグラフ
{
rank=same;
"User Service";
"Auth Service";
}
{
rank=same;
"Order Service";
"Payment Service";
"Inventory Service";
}
} チュートリアル2:組織階層
サンプルコード:

digraph OrgChart {
rankdir=TB;
node [shape=box, style="rounded,filled", fontname="Helvetica"];
edge [fontname="Helvetica", arrowsize=0.7];
// 経営層
CEO [label="CEOnJohn Smith", fillcolor="#1976d2", fontcolor="white"];
// Cレベル
subgraph cluster_exec {
label="経営チーム";
style=dashed;
color="#90caf9";
CTO [label="CTOnSarah Johnson", fillcolor="#42a5f5"];
CFO [label="CFOnMichael Brown", fillcolor="#42a5f5"];
COO [label="COOnEmily Davis", fillcolor="#42a5f5"];
CPO [label="CPOnDavid Wilson", fillcolor="#42a5f5"];
}
// エンジニアリング
subgraph cluster_eng {
label="エンジニアリング";
style=filled;
color="#e3f2fd";
VP_Eng [label="VP Engineering", fillcolor="#64b5f6"];
subgraph cluster_eng_teams {
label="チーム";
style=dotted;
Backend [label="バックエンドチームn(12名のエンジニア)", fillcolor="#bbdefb"];
Frontend [label="フロントエンドチームn(8名のエンジニア)", fillcolor="#bbdefb"];
DevOps [label="DevOpsチームn(5名のエンジニア)", fillcolor="#bbdefb"];
QA [label="QAチームn(6名のエンジニア)", fillcolor="#bbdefb"];
}
}
// プロダクト
subgraph cluster_product {
label="プロダクト";
style=filled;
color="#fff3e0";
VP_Product [label="VP Product", fillcolor="#ffb74d"];
PM1 [label="プロダクトマネージャーnプラットフォーム", fillcolor="#ffcc80"];
PM2 [label="プロダクトマネージャーnモバイル", fillcolor="#ffcc80"];
PM3 [label="プロダクトマネージャーnアナリティクス", fillcolor="#ffcc80"];
}
// 関係性
CEO -> CTO;
CEO -> CFO;
CEO -> COO;
CEO -> CPO;
CTO -> VP_Eng;
VP_Eng -> Backend;
VP_Eng -> Frontend;
VP_Eng -> DevOps;
VP_Eng -> QA;
CPO -> VP_Product;
VP_Product -> PM1;
VP_Product -> PM2;
VP_Product -> PM3;
// 協働を示す点線
PM1 -> Backend [style=dotted, color="#757575"];
PM2 -> Frontend [style=dotted, color="#757575"];
PM3 -> Backend [style=dotted, color="#757575"];
} チュートリアル3:データフロー図
サンプルコード:

digraph DataFlow {
rankdir=LR;
nodesep=1.0;
node [shape=ellipse, style="filled", fontname="Arial"];
edge [fontname="Arial", fontsize=9];
// 外部エンティティ
node [fillcolor="#ffccbc", shape=box];
Customer [label="顧客"];
Vendor [label="ベンダー"];
Bank [label="銀行システム"];
// プロセス
node [fillcolor="#c5cae9", shape=circle];
P1 [label="注文"];
P2 [label="支払い処理"];
P3 [label="在庫更新"];
P4 [label="請求書生成"];
P5 [label="出荷"];
P6 [label="通知送信"];
// データストア
node [fillcolor="#c8e6c9", shape=box3d];
D1 [label="注文DB"];
D2 [label="在庫DB"];
D3 [label="顧客DB"];
D4 [label="請求書記録"];
// データフロー
Customer -> P1 [label="注文リクエスト"];
P1 -> D1 [label="注文保存"];
P1 -> D3 [label="顧客更新"];
P1 -> P2 [label="支払い詳細"];
P2 -> Bank [label="支払いリクエスト"];
Bank -> P2 [label="支払い確認"];
P2 -> P3 [label="支払い成功"];
P3 -> D2 [label="在庫減少"];
P3 -> P4 [label="注文確定"];
P4 -> D4 [label="請求書保存"];
P4 -> P6 [label="請求書データ"];
P3 -> P5 [label="出荷リクエスト"];
P5 -> Vendor [label="配送ラベル"];
P5 -> P6 [label="追跡情報"];
P6 -> Customer [label="注文確認n+ 追跡"];
// クエリを示す点線
D1 -> P5 [label="注文詳細取得", style=dashed];
D2 -> P1 [label="在庫確認", style=dashed];
D3 -> P1 [label="顧客情報取得", style=dashed];
} 6. 実世界の実装パターン {#implementation-patterns}
パターン1:CI/CDパイプラインドキュメンテーション
サンプルコード(Mermaid):

graph LR
subgraph Source["ソース管理"]
Git[GitHub リポジトリ]
PR[プルリクエスト]
end
subgraph CI["継続的インテグレーション"]
Lint[リンティング]
Test[ユニットテスト]
Build[ビルド成果物]
Scan[セキュリティスキャン]
end
subgraph CD["継続的デプロイ"]
Dev[開発環境へデプロイ]
Stage[ステージング環境へデプロイ]
E2E[E2E テスト]
Prod[本番環境へデプロイ]
end
subgraph Monitor["モニタリング"]
Logs[ログ集約]
Metrics[メトリクスダッシュボード]
Alerts[アラートシステム]
end
Git --> PR
PR --> Lint
Lint --> Test
Test --> Build
Build --> Scan
Scan --> Dev
Dev --> Stage
Stage --> E2E
E2E --> Prod
Prod --> Logs
Prod --> Metrics
Metrics --> Alerts
style Git fill:#f0f0f0,stroke:#333
style Prod fill:#d4edda,stroke:#28a745,color:black
style Alerts fill:#f8d7da,stroke:#dc3545,color:black
パターン 2: データベーススキーマ設計
サンプルコード (PlantUML):

図 5: E コマースデータベーススキーマを示すエンティティリレーションシップ図
@startuml
!define TABLE(name) entity name << (T,#FFAAAA) >>
!define PK(x) x <<PK>>
!define FK(x) x <<FK>>
TABLE(Users) {
PK(user_id) : INT
--
email : VARCHAR(255)
password_hash : VARCHAR(255)
created_at : TIMESTAMP
last_login : TIMESTAMP
status : ENUM
}
TABLE(Products) {
PK(product_id) : INT
--
sku : VARCHAR(50)
name : VARCHAR(255)
description : TEXT
price : DECIMAL(10,2)
stock_quantity : INT
category_id : INT
}
TABLE(Categories) {
PK(category_id) : INT
--
name : VARCHAR(100)
parent_id : INT
}
TABLE(Orders) {
PK(order_id) : INT
--
FK(user_id) : INT
order_date : TIMESTAMP
total_amount : DECIMAL(10,2)
status : ENUM
shipping_address : TEXT
}
TABLE(OrderItems) {
PK(item_id) : INT
--
FK(order_id) : INT
FK(product_id) : INT
quantity : INT
unit_price : DECIMAL(10,2)
}
TABLE(Payments) {
PK(payment_id) : INT
--
FK(order_id) : INT
payment_method : ENUM
transaction_id : VARCHAR(255)
amount : DECIMAL(10,2)
status : ENUM
processed_at : TIMESTAMP
}
Users ||--o{ Orders : places
Orders }o--|{ Users : belongs_to
Orders ||--|{ OrderItems : contains
OrderItems }o--|| Products : references
Products }o--|| Categories : categorized_in
Orders ||--o{ Payments : paid_by
note right of Users
顧客アカウントと認証データを保存
end note
note left of Orders
配送情報を含む主要な取引記録
end note
@enduml
パターン 3: インフラストラクチャ・アズ・コードの可視化
サンプルコード (Mermaid):
graph TB
subgraph AWS["AWS クラウドインフラストラクチャ"]
direction TB
subgraph Networking["ネットワーク"]
VPC[VPC 10.0.0.0/16]
IGW[インターネットゲートウェイ]
NAT[NAT ゲートウェイ]
subgraph Public["パブリックサブネット"]
ALB[アプリケーションロードバランサー]
Bastion[バスターションホスト]
end
subgraph Private["プライベートサブネット"]
subgraph AppTier["アプリケーション層"]
ECS1[ECS タスク 1]
ECS2[ECS タスク 2]
ECS3[ECS タスク 3]
end
subgraph DataTier["データ層"]
RDS[RDS PostgreSQL<br/>マルチ AZ]
Redis[ElastiCache Redis]
end
end
end
subgraph Storage["ストレージ"]
S3[S3 バケット<br/>アセットとバックアップ]
EFS[EFS 共有ストレージ]
end
subgraph Security["セキュリティ"]
WAF[WAF ルール]
SG[セキュリティグループ]
IAM[IAM ロール]
end
subgraph Monitoring["モニタリングとロギング"]
CW[CloudWatch]
XRay[AWS X-Ray]
SNS[SNS 通知]
end
end
User[エンドユーザー] --> CloudFront[CloudFront CDN]
CloudFront --> WAF
WAF --> ALB
ALB --> ECS1
ALB --> ECS2
ALB --> ECS3
ECS1 --> RDS
ECS2 --> RDS
ECS3 --> RDS
ECS1 --> Redis
ECS2 --> Redis
ECS3 --> Redis
ECS1 --> S3
ECS2 --> S3
ECS3 --> S3
ECS1 --> EFS
ECS2 --> EFS
ECS3 --> EFS
ECS1 --> CW
ECS2 --> CW
ECS3 --> CW
RDS --> CW
Redis --> CW
CW --> SNS
style VPC fill:#f9f9f9,stroke:#333,stroke-width:2px
style ALB fill:#ff9900,stroke:#cc7a00,color:white
style RDS fill:#2e73b8,stroke:#1a4d80,color:white
style User fill:#95a5a6,stroke:#7f8c8d

図 6: AWS クラウドインフラストラクチャのアーキテクチャ図
7. 高度な技術: スタイルとカスタマイズ {#advanced-techniques}
マーメイドの高度なスタイル
テーマのカスタマイズ:

%%{init: {'theme':'base', 'themeVariables': {
'primaryColor': '#4CAF50',
'primaryTextColor': '#fff',
'primaryBorderColor': '#388E3C',
'lineColor': '#757575',
'secondaryColor': '#FFC107',
'tertiaryColor': '#fff'
}}}%%
graph TD
A[開始] --> B{判断}
B -->|はい| C[プロセス A]
B -->|いいえ| D[プロセス B]
C --> E[終了]
D --> E
style A fill:#2196F3,stroke:#1976D2,color:white
style E fill:#F44336,stroke:#D32F2F,color:white
PlantUML スキンのパラメータ
プロフェッショナルなスタイル:

@startuml
' グローバルスタイル
skinparam backgroundColor #FFFFFF
skinparam shadowing false
skinparam roundcorner 10
skinparam linetype ortho
' コンポーネントのスタイル
skinparam component {
BackgroundColor #E3F2FD
BorderColor #1976D2
ArrowColor #1976D2
}
' パッケージのスタイル
skinparam package {
BackgroundColor #FFF3E0
BorderColor #F57C00
FontSize 14
}
' ノートのスタイル
skinparam note {
BackgroundColor #F1F8E9
BorderColor #689F38
FontColor #33691E
}
package "フロントエンド" {
component [React アプリ]
component [Redux ストア]
}
package "バックエンド" {
component [Node.js API]
component [Express サーバー]
database [MongoDB]
}
[React アプリ] --> [Redux ストア]
[Redux ストア] --> [Node.js API]
[Node.js API] --> [Express サーバー]
[Express サーバー] --> [MongoDB]
note right of [Redux ストア]
アプリケーション全体の集中型状態管理
end note
@enduml
Graphviz 高度な属性
プロフェッショナルなネットワーク図:

digraph AdvancedStyling {
// グローバルグラフ属性
graph [
bgcolor="#f8f9fa"
fontname="Helvetica"
fontsize=16
label="エンタープライズシステムアーキテクチャn本番環境"
labelloc="t"
pad=0.5
ranksep=1.5
nodesep=1.0
];
// デフォルトノード属性
node [
fontname="Helvetica"
fontsize=11
style="filled,rounded"
penwidth=2
];
// デフォルトエッジ属性
edge [
fontname="Helvetica"
fontsize=9
penwidth=1.5
arrowsize=0.8
];
// カスタムスタイルを持つノードクラスタ
subgraph cluster_presentation {
label="プレゼンテーション層";
style=filled;
color="#e3f2fd";
fontcolor="#1565c0";
Web [label="Web アプリケーション<br/>React 18", fillcolor="#64b5f6", fontcolor="white"];
Mobile [label="モバイルアプリ<br/>Flutter", fillcolor="#64b5f6", fontcolor="white"];
}
subgraph cluster_business {
label="ビジネスロジック層";
style=filled;
color="#fff3e0";
fontcolor="#e65100";
API [label="REST API<br/>Node.js", fillcolor="#ffb74d", fontcolor="black"];
GraphQL [label="GraphQL ゲートウェイ", fillcolor="#ffb74d", fontcolor="black"];
}
subgraph cluster_data {
label="データ層";
style=filled;
color="#e8f5e9";
fontcolor="#2e7d32";
Primary [label="プライマリ DB<br/>PostgreSQL 14", shape=cylinder, fillcolor="#a5d6a7"];
Replica [label="読み取りレプリカ<br/>PostgreSQL 14", shape=cylinder, fillcolor="#c8e6c9"];
Cache [label="Redis キャッシュ<br/>クラスタモード", shape=cylinder, fillcolor="#c8e6c9"];
}
// カスタムスタイルを持つエッジ
Web -> API [label="HTTPS/REST", color="#1976d2", fontcolor="#1976d2"];
Mobile -> API [label="HTTPS/REST", color="#1976d2", fontcolor="#1976d2"];
Web -> GraphQL [label="WebSocket", color="#1976d2", fontcolor="#1976d2", style=dashed];
API -> Primary [label="読み書き", color="#388e3c", fontcolor="#388e3c"];
API -> Cache [label="キャッシュ", color="#f57c00", fontcolor="#f57c00", style=dashed];
GraphQL -> Replica [label="読み取り専用", color="#388e3c", fontcolor="#388e3c"];
Primary -> Replica [label="ストリーミングレプリケーション", color="#757575", style=dotted];
}
8. 共同作業と共有ワークフロー {#collaboration}
共有可能な図の作成
ステップバイステップの共有:
-
共有リンクの生成:
-
VPasCode の「共有」ボタンをクリック
-
生成された URL をコピーする
-
メール、Slack、またはドキュメントを介して共有する
-
-
ドキュメントへの埋め込み:
## システムアーキテクチャ  または、インタラクティブ版を埋め込む: <iframe src="https://www.vpascode.com/embed/abc123xyz" width="100%" height="600"></iframe> -
プレゼンテーション用のエクスポート:
-
スケーラブルなウェブグラフィック用の SVG
-
PowerPoint/Keynote 用の PNG (300 DPI)
-
印刷用ドキュメント用の PDF
-
バージョン管理の統合
図のコードを Git に保存する:
project-root/
├── docs/
│ ├── diagrams/
│ │ ├── architecture/
│ │ │ ├── system-overview.puml
│ │ │ ├── deployment-view.puml
│ │ │ └── data-flow.mmd
│ │ ├── processes/
│ │ │ └── user-journey.mmd
│ │ └── infrastructure/
│ │ └── aws-architecture.dot
│ └── README.md
└── src/
Git ワークフローの例:
# 図の作成
echo '@startuml
component "API Gateway"
@enduml' > docs/diagrams/architecture/gateway.puml
# 変更をコミット
git add docs/diagrams/architecture/gateway.puml
git commit -m "API Gateway のアーキテクチャ図を追加"
git push
# チームメンバーは、コードを貼り付けるか URL から読み込むことで、VPasCode で表示できるようになりました
チームコラボレーションのパターン
パターン 1: アーキテクチャ決定記録 (ADRs)
# ADR-007: マイクロサービス通信パターン
## 背景
マイクロサービスの通信方法を標準化する必要があります。
## 決定
サービス間通信には、RabbitMQ を介した非同期メッセージングを使用します。
## アーキテクチャ図
```mermaid
graph LR
A[Service A] -->|Publish| B[(RabbitMQ)]
B -->|Subscribe| C[Service B]
B -->|Subscribe| D[Service C]
結果
-
結合度の低下(デカップリングの向上)
-
スケーラビリティの向上
-
メッセージ処理の複雑さの増加
**パターン 2: スプリント計画ドキュメント**
スプリントに合わせて進化していく生きた図を作成します:

graph TD
subgraph Sprint24["Sprint 24 - 進行中"]
Done[✅ 完了タスク]
InProgress[🔄 進行中]
ToDo[📋 未着手]
Blocked[⛔ 停止中]
end
Done --> Task1[ユーザー認証モジュール]
Done --> Task2[データベースマイグレーション]
InProgress --> Task3[API 開発]
InProgress --> Task4[フロントエンド統合]
ToDo --> Task5[ユニットテスト]
ToDo --> Task6[ドキュメント作成]
Blocked --> Task7[サードパーティ統合]
style Done fill:#d4edda,stroke:#28a745
style InProgress fill:#fff3cd,stroke:#ffc107
style ToDo fill:#e2e3e5,stroke:#6c757d
style Blocked fill:#f8d7da,stroke:#dc3545
結論: ドキュメントの卓越性への旅
おめでとうございます!VPasCode と Diagram-as-Code の手法に関する包括的な旅を完了しました。学んだことを振り返り、今後の道筋を切り開きましょう。
習得した内容
このチュートリアルを通じて、あなたは次のことを学びました:
-
テキストベースの図の力: 図を作成するためにコードを書くことで、手動での配置の煩わしさがなくなり、一貫性が確保され、ドキュメントの保守性が向上することがわかりました。
-
3 つの業界標準エンジン: 現在は、以下の分野で実践的なスキルを身につけています:
-
Mermaid.js開発者フレンドリーなフローチャートとモダンなドキュメント作成のために
-
PlantUMLエンタープライズグレードのUMLおよびアーキテクチャ図作成のために
-
Graphviz複雑なネットワークトポロジおよび関係性の可視化のために
-
-
実世界のパターンマイクロサービスアーキテクチャからデータベーススキーマ、CI/CDパイプラインから組織図まで、あらゆるシステムやプロセスを可視化する力を身につけました。
-
コラボレーションワークフローURLによる図の共有、ドキュメントへの埋め込み、バージョン管理との統合、CI/CDパイプラインでの生成自動化の方法を理解しています。
-
プロフェッショナルなスタイリングカスタムテーマ、一貫したブランディング、異なる聴衆に適した詳細レベルを用いて、出版品質のビジュアルを作成できます。
より大きな視点
VPasCodeが真に革命的なのは、ツールそのものだけでなく、それが表すパラダイムシフトにあります。図をコードとして扱うことで、あなたは:
-
ギャップを埋める実装とドキュメントの間に
-
アーキテクチャの民主化チームの全員がアクセスできるようにすることで
-
知識の将来性確保テキストベースでバージョン管理されたアーティファクトを通じて
-
オンボーディングの加速明確で実行可能なドキュメントによって
-
技術的負債の削減更新をテキスト編集のようにシンプルにすることで
次のステップ
1週目:小さく始める
-
組織内の既存の図を1つ選びます
-
お好みのエンジンを使ってVPasCodeでそれを再現します
-
同僚と共有し、フィードバックを集めます
-
コードをプロジェクトリポジトリに保存します
週2〜3:勢いを高める
-
チームの一般的な図表タイプ用のテンプレートを作成する
-
命名規則とスタイルガイドラインを確立する
-
図表レビューをコードレビュープロセスに統合する
-
「コードとしての図表」ワークフローを文書化する
2ヶ月目:スケーリングと自動化
-
自動図表生成のためのCI/CD統合を設定する
-
組織向けの図表ライブラリを作成する
-
チームメンバーにワークフローをトレーニングする
-
節約された時間とドキュメント品質の向上を測定する
3ヶ月目以降:文化として定着させる
-
アーキテクチャの意思決定においてコードとしての図表を推進する
-
成功事例をリーダーシップと共有する
-
テンプレートをコミュニティに還元する
-
AI支援による図表生成などの高度な機能を探る
競争上の優位性
コードとしての図表を習得した組織は、大きな優位性を獲得します:
✅ 意思決定の迅速化: 明確な視覚化が理解と合意形成を加速する
✅ オンボーディング時間の短縮: 新入りのエンジニアは実行可能なドキュメントを通じてシステムをより速く理解する
✅ ステークホルダーとのコミュニケーションの向上: プロフェッショナルな図表が技術的視点とビジネス的視点をつなぐ
✅ メンテナンス負担の軽減: テキストの更新は、図表の再描画よりも速い
✅ コード品質の向上: 図面化の行為は、アーキテクチャ上の問題を早期に明らかにします
ムーブメントに参加する
あなたは、ドキュメントが負担である必要はないと認識する、開発者、アーキテクト、チームからなる成長し続けるコミュニティの一員となりました。VPasCodeを使えば、ドキュメントを資産に変えるためのツールが手に入ります。それは、コードと共に進化していく、生きているシステムそのものの表現です。
最後の言葉
図面をコードとして扱うことを始めるのに最適な時期は昨日でした。次に最適な時期は、今です。
あなたの未来の自分、そして未来のチームメイトは、常に最新で、常にアクセス可能で、常に正確なドキュメントから得られる明確さ、一貫性、そして自信に対して、あなたに感謝するでしょう。
始める準備はできましたか? 訪問する VPasCode 今すぐ、最初の図面コードを貼り付けて、テキストが明確さへと変化する様子をご覧ください。この結論を読むのにかかった時間よりも短い時間で、あなたは最初のDiagram-as-Code成果物を作成しているはずです。
技術ドキュメンテーションの未来はここにあります。それはコード駆動型で、ブラウザベース、そして完全に無料です。革命へようこそ。
このチュートリアルについて
この包括的なガイドは、Diagram-as-Codeを通じて開発チームがドキュメント作成の慣行を近代化できるよう支援するために作成されました。ビジュアルパラダイムの20年にわたるエンタープライズアーキテクチャの専門知識を基盤として構築されたVPasCodeは、技術コミュニケーションの未来を表しています—アクセスしやすく、保守可能で、無料です。
最終更新日:2026年6月
対象読者:ソフトウェア開発者、システムアーキテクト、DevOpsエンジニア、技術ライター、および開発チーム
前提条件:ソフトウェアアーキテクチャの概念に関する基本的な理解
推定完了時間:完全なチュートリアルで2〜3時間、クイックスタートで15分
楽しい図面化を!🎨📊






