Diagram-as-Code の完全マスター:現代の開発チームのための VPasCode 完全チュートリアル

はじめに:ドキュメント革命はここから始まります

ソフトウェア開発のスピードが速い世界において、私たちが全員直面する不快な真実があります:私たちのドキュメントは常に古びた状態にある私たちは、ドラッグ&ドロップの図描画ツールとの格闘に無数の時間を費やし、箱や矢印を手作業で慎重に整列させてきましたが、コードが変更された瞬間に、丹念に作成した視覚資料が陳腐化してしまうのをただ見守るしかなかったのです。
しかし、ドキュメントが開発のペースに追いつくことができたらどうでしょうか?プロフェッショナルなアーキテクチャ図の作成が、関数を書くのと同じくらい簡単になったらどうでしょうか?
Diagram-as-Code 革命へようこそ。このチュートリアルでは、VPasCode、チームがシステムアーキテクチャ図を作成、共有、維持する方法を変革する、ビジュアルパラダイム社のブラウザベースのプラットフォームについてご案内します。図をコードとして扱うことで、数時間ではなく数分で出版品質のビジュアルを生成する方法を発見し、ドキュメントがシステムとシームレスに進化することを保証できます。
マイクロサービスのドキュメント作成を行う開発者、ステークホルダーへのプレゼンテーションを行うアーキテクト、インフラのマッピングを行う DevOps エンジニアのいずれであっても、この包括的なガイドは、VPasCode をマスターし、チームのドキュメント作成の質を高めるためのスキルを身につけるために必要なものを提供します。


1. はじめに:5 分で最初の図を作成 {#getting-started}

インストール不要、設定不要、コードのみ

VPasCode の最も強力な機能の一つは、摩擦ゼロのオンボーディングです。インストールする必要も、アカウント作成も、複雑な設定もありません。今すぐ最初の図を作成しましょう。
ステップバイステップのクイックスタート:

  1. VPasCode にアクセス:ブラウザを開いて、https://www.vpascode.com/editor/

  2. エンジンを選択:ドロップダウンメニューから選択してください:

    • Mermaid – フローチャートやモダンなドキュメントに最適

    • PlantUML – UML やエンタープライズアーキテクチャに理想的

    • Graphviz – 複雑なネットワークトポロジに完璧

  3. テンプレートを読み込む:「Examples」をクリックして、スタートテンプレートを選択

  4. 編集とプレビュー:左側のパネルでコードを修正すると、右側の図が即座に更新されるのを見ることができます

  5. エクスポートまたは共有:SVG/PNG としてダウンロードするか、共有可能な URL をコピー

VPasCode:Diagram-as-Codeによるシステムアーキテクチャドキュメンテーション
図1:VPasCodeは、テキストベースのコードを瞬時にプロフェッショナルなアーキテクチャ図に変換します


2. VPasCodeインターフェースの理解 {#interface}

構文の詳細に入る前に、まずワークスペースに慣れておきましょう。
VPasCodeのユーザーインターフェース—テキストから図面(またはDiagram-as-Code)を作成するためのオールインワンエディタ
図2:2分割されたVPasCodeインターフェース—左側にコード、右側にライブプレビュー

インターフェースコンポーネントの詳細:

左パネル(コードエディタ):

  • 構文ハイライト対応のテキストエディタ

  • 参照しやすい行番号

  • 自動補完機能

  • リアルタイムでのエラーハイライト表示

右パネル(ライブプレビュー):

  • 即時の視覚的レンダリング

  • パンおよびズーム操作コントロール

  • ベクトルベース表示(あらゆるズームレベルで鮮明)

  • クリックして要素を検証

上部ツールバー:

  • エンジンセレクター(Mermaid/PlantUML/Graphviz)

  • テンプレートギャラリー

  • エクスポートオプション(SVG、PNG、PDF)

  • 共有ボタン(永続的なURLを生成)

  • 設定と環境設定

下部ステータスバー:

  • 構文検証ステータス

  • 文字数カウント

  • 最終保存時刻

  • キーボードショートカットリファレンス

コアワークフローの原則:

コード記述 → 即時プレビューの確認 → 改良 → エクスポート/共有

この即時フィードバックループこそが、VPasCodeをこれほど強力なものにしています。「レンダリング」ボタンをクリックする必要も、コンパイルを待つ必要もありません。タイピングするだけで、純粋で瞬時の視覚的フィードバックが得られます。


3. Mermaid.jsの習得:フローチャートとその先 {#mermaid-tutorial}

Mermaid.js は、開発者フレンドリーな図描画の事実上の標準となっています。その構文は直感的で読みやすく、コードと共に存在するドキュメントに最適です。

チュートリアル 1: ユーザー認証フローの作成

次のスプリント計画で使用する可能性のある、実用的な認証フローの図を作成してみましょう。
コード例:

認証フロー図:資格情報の検証、JWTトークンの生成、エラーハンドリングループを備えたダッシュボードへのリダイレクトを示す。

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: マイクロサービスアーキテクチャ図

では、サービスの関係性を示すより複雑なシステムアーキテクチャを作成しましょう。
コード例:

マイクロサービスアーキテクチャ図:クライアント層、APIゲートウェイ、ビジネスサービス、データ層を示し、PostgreSQL、MongoDB、Redisとの接続を含む。

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:注文処理のシーケンス図

シーケンス図は、コンポーネント間の時間的相互作用を理解するために不可欠です。
例コード:

シーケンス図:顧客、Webアプリ、注文サービス、支払いサービス、在庫サービス、通知サービス間の注文処理フローを示す。

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 はプロジェクトのタイムライン可視化もサポートしています。
サンプルコード:

認証モジュールのスプリント24ガントチャート:6月1日から6月17日までのバックエンド、フロントエンド、統合チームのタイムラインタスクを示す。

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 コマースプラットフォームのコンポーネント図

サンプルコード:

ECプラットフォームの階層化アーキテクチャ図:プレゼンテーション層、API層、ビジネスサービス層、データ層の詳細を示す。

@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

PlantUMLコンポーネント図
図 3: レイヤー構造を示す PlantUML コンポーネント図

チュートリアル 2: クラウドインフラストラクチャのデプロイメント図

サンプルコード:

チュートリアル 3: C4 モデル – コンテナ図

C4 モデルは、抽象化の複数のレベルでソフトウェアアーキテクチャを伝えるのに優れています。
サンプルコード:

C4モデルコンテナ図:パブリックサブネット、プライベートサブネット、Webサーバー、APIサーバー、ストレージコンポーネントを含むAWSクラウドデプロイメントアーキテクチャを示す。
@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:マイクロサービス依存関係グラフ

サンプルコード:

マイクロサービス依存関係グラフ図:APIゲートウェイ、サービスメッシュ、データベースおよび外部ゲートウェイと接続されたサービスを示す。
図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:組織階層

サンプルコード:

CEOジョン・スミス、執行役員チーム、製品担当副社長、およびエンジニアリング担当副社長が、バックエンド、フロントエンド、QA、およびDevOpsチームを率いる組織階層図。

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):

ソース管理から継続的インテグレーション、デプロイメント、およびモニタリングに至る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):

ユーザー、注文、注文項目、製品、および支払いテーブルを備えたeコマースデータベーススキーマを示す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}

マーメイドの高度なスタイル

テーマのカスタマイズ:

開始、分岐、プロセス、および終了状態に色分けされた形状を使用したMermaidの高度なスタイルを示すフローチャート。

%%{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 スキンのパラメータ

プロフェッショナルなスタイル:

中央集権型状態管理を示す、フロントエンドのReactアプリおよびReduxストアからバックエンドのNode.js API、Expressサーバー、およびMongoDBへのフロー。

@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 高度な属性

プロフェッショナルなネットワーク図:

Flutter、React、Node.js、およびPostgreSQLコンポーネントを備えたプレゼンテーション層、ビジネスロジック層、およびデータ層を示すエンタープライズシステムアーキテクチャ図。

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}

共有可能な図の作成

ステップバイステップの共有:

  1. 共有リンクの生成:

    • VPasCode の「共有」ボタンをクリック

    • 生成された URL をコピーする

    • メール、Slack、またはドキュメントを介して共有する

  2. ドキュメントへの埋め込み:

    ## システムアーキテクチャ
    
    ![アーキテクチャ図](https://www.vpascode.com/share/abc123xyz.svg)
    
    または、インタラクティブ版を埋め込む:
    <iframe src="https://www.vpascode.com/embed/abc123xyz" width="100%" height="600"></iframe>
    
    
  3. プレゼンテーション用のエクスポート:

    • スケーラブルなウェブグラフィック用の 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: スプリント計画ドキュメント**

スプリントに合わせて進化していく生きた図を作成します:

ユーザー認証モジュール、API開発、およびサードパーティ統合などの完了、進行中、未着手、およびブロックされたタスクを示すスプリント24のカンバンボード。

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 の手法に関する包括的な旅を完了しました。学んだことを振り返り、今後の道筋を切り開きましょう。

習得した内容

このチュートリアルを通じて、あなたは次のことを学びました:

  1. テキストベースの図の力: 図を作成するためにコードを書くことで、手動での配置の煩わしさがなくなり、一貫性が確保され、ドキュメントの保守性が向上することがわかりました。

  2. 3 つの業界標準エンジン: 現在は、以下の分野で実践的なスキルを身につけています:

    • Mermaid.js開発者フレンドリーなフローチャートとモダンなドキュメント作成のために

    • PlantUMLエンタープライズグレードのUMLおよびアーキテクチャ図作成のために

    • Graphviz複雑なネットワークトポロジおよび関係性の可視化のために

  3. 実世界のパターンマイクロサービスアーキテクチャからデータベーススキーマ、CI/CDパイプラインから組織図まで、あらゆるシステムやプロセスを可視化する力を身につけました。

  4. コラボレーションワークフローURLによる図の共有、ドキュメントへの埋め込み、バージョン管理との統合、CI/CDパイプラインでの生成自動化の方法を理解しています。

  5. プロフェッショナルなスタイリングカスタムテーマ、一貫したブランディング、異なる聴衆に適した詳細レベルを用いて、出版品質のビジュアルを作成できます。

より大きな視点

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分


楽しい図面化を!🎨📊