【Mermaid.js応用】「状態」と「構造」をモデル化する。ステート図とER図の極意

前回は、「処理の流れ」を描く方法を学びました。 しかし、流れ（Flow）だけを追っていると、エンジニアは致命的な罠に陥ります。

なぜ「二重課金」バグはなくならないのか？

それは、私たちが**「ハッピーパス（成功ルート）」**しか考えない癖がついているからです。

「購入ボタンを押す → 決済する → 完了画面へ」

このフローチャートには、「決済中に通信が切れたら？」「連打されたら？」という例外が含まれていません。 フローチャートは「どう動くか」を表しますが、「今どういう状態か」を見失いがちです。

解決策：ステートマシン（状態遷移）

この問題を解決するのが**ステート図（State Diagram）**です。 「システムは今、何待ちの状態なのか？」を厳密に定義することで、ありえない遷移（例：決済完了後にキャンセルボタンを押す）を設計段階で封じ込めます。

比較項目	フローチャート	ステート図
主語	手順（What happens next?）	状態（Where are we now?）
得意	業務プロセス、UXフロー	決済、ライフサイクル管理
アナロジー	カーナビ（ここを曲がって次へ）	信号機（赤の次は必ず青。赤から青には行けない）

---

3. State Diagram: 堅牢性の設計図

Mermaidを使えば、複雑な状態遷移も数行で記述できます。

基本構文とレンダリング

stateDiagram-v2
[*] --> Idle
Idle --> Processing: 実行ボタン押下

    state "処理中" as Processing {
        [*] --> Validating
        Validating --> Calculating
    }

    Processing --> Success: 完了
    Processing --> Error: 失敗

    Error --> Idle: リセット
    Success --> [*]

stateDiagram-v2
    [*] --> Idle
    Idle --> Processing: 実行ボタン押下

    state "処理中" as Processing {
        [*] --> Validating
        Validating --> Calculating
    }

    Processing --> Success: 完了
    Processing --> Error: 失敗

    Error --> Idle: リセット
    Success --> [*]

[!WARNING] 「[*]」を忘れないこと ステート図には必ず「開始」と「終了」があります。ライフサイクルのあるオブジェクト（注文、セッションなど）をモデリングする際は、生成から消滅までを描ききることが重要です。

---

4. ER Diagram: データの地図

アプリケーションの骨格を決めるのはデータ構造です。 ER図（Entity Relationship Diagram）をコードで管理することで、スキーマ変更のレビューがGitHub上で完結します。

ショッピングカートのデータモデル

erDiagram
USER ||--o{ ORDER : "places"
ORDER ||--|{ ORDER_ITEM : "contains"
PRODUCT ||--o{ ORDER_ITEM : "ordered in"

    USER {
        string email
        string password_hash
    }

    ORDER {
        int id
        date created_at
        string status "New/Paid/Shipped"
    }

erDiagram
    USER ||--o{ ORDER : "places"
    ORDER ||--|{ ORDER_ITEM : "contains"
    PRODUCT ||--o{ ORDER_ITEM : "ordered in"

    USER {
        string email
        string password_hash
    }

    ORDER {
        int id
        date created_at
        string status "New/Paid/Shipped"
    }

記号の読み方（Crow’s Foot）

• ||--||: 1 対 1
• ||--|{: 1 対 多（必須・1以上）
• ||--o{: 1 対 多（任意・0以上）

「ユーザーは必ず注文を持つわけではない（o{）」けれど、「注文には必ず商品が含まれる（|{）」といったビジネスルールを、この記号一つで表現できます。

---

まとめ：論理をコードにする

「動き（Flow）」と「状態（State）」、そして「構造（Data）」。 これらをMermaidで記述できるようになれば、あなたの設計スキルは格段に向上します。

しかし、現実のシステムはもっと残酷です。 数百のマイクロサービス、複雑に絡み合う依存関係……。 そのまま図にすれば、それは**「スパゲッティ」**にしかなりません。

次回、最終回 【Part 3】「カオス」を美しく手懐ける。 巨大なアーキテクチャ図を、「見るに耐えうる美しいドキュメント」に昇華させるテクニック（Subgraphs & Styling）を伝授します。