Mermaidシーケンス図のサンプル

シーケンス図の基本

提供いただいたサンプル（認証フロー）

sequenceDiagram
  autonumber
  participant adminmenu as ui/admin_menu
  participant claim as ui/claim
  participant auth
  participant division as use_case/division
  participant role as use_case/role

  Note over adminmenu: 【filteredAdminMenusプロバイダー】
  adminmenu ->>+ claim: 【claimRoleListプロバイダー】
  claim ->>+ auth: 【claimDivisionIdプロバイダー】
  auth ->>- claim: クレーム内のdivisionIdを提供
  claim ->>+ division: divisionId を元に【divisionDetailプロバイダー】
  division ->>- claim: Divisionを提供
  claim ->>+ role: division.roleIds を元に【roleListプロバイダー】
  role ->>- claim: Roleリストを提供
  claim ->>- adminmenu: 自身の所属に付与されたRoleリストを提供

シンプルなAPI通信の例

sequenceDiagram
  autonumber
  participant Client
  participant API
  participant DB
  participant Cache

  Client->>+API: GET /users/123
  API->>+Cache: キャッシュ確認
  Cache-->>-API: キャッシュなし
  API->>+DB: SELECT * FROM users WHERE id = 123
  DB-->>-API: ユーザーデータ
  API->>+Cache: キャッシュ保存
  Cache-->>-API: OK
  API-->>-Client: 200 OK (ユーザーデータ)

メッセージの種類

矢印の種類と意味

sequenceDiagram
  participant A
  participant B

  A->>B: 同期メッセージ
  A-->>B: 応答メッセージ
  A->>+B: 同期呼び出し（活性化あり）
  B-->>-A: 応答（非活性化あり）
  A-)B: 非同期メッセージ
  A--)B: 非同期応答
  A-xB: 失敗/エラー
  A--xB: 失敗応答

実践的なシーケンス図

認証フロー

sequenceDiagram
  autonumber
  actor User
  participant Frontend
  participant AuthAPI
  participant UserDB
  participant TokenService

  User->>Frontend: ログインボタンクリック
  Frontend->>Frontend: 入力検証
  Frontend->>+AuthAPI: POST /auth/login {email, password}

  AuthAPI->>+UserDB: ユーザー検索（email）
  UserDB-->>-AuthAPI: ユーザー情報

  alt ユーザーが存在しない
    AuthAPI-->>Frontend: 401 Unauthorized
    Frontend-->>User: エラー表示
  else ユーザーが存在する
    AuthAPI->>AuthAPI: パスワード検証

    alt パスワード不一致
      AuthAPI-->>Frontend: 401 Unauthorized
      Frontend-->>User: エラー表示
    else パスワード一致
      AuthAPI->>+TokenService: トークン生成
      TokenService-->>-AuthAPI: JWT Token
      AuthAPI-->>-Frontend: 200 OK {token, user}
      Frontend->>Frontend: トークン保存
      Frontend-->>User: ダッシュボードへリダイレクト
    end
  end

決済処理フロー

sequenceDiagram
  autonumber
  actor Customer
  participant Shop as ECサイト
  participant Payment as 決済API
  participant Card as カード会社
  participant Bank as 銀行
  participant Notification as 通知サービス

  Customer->>Shop: 購入ボタンクリック
  Shop->>Shop: 在庫確認

  Shop->>+Payment: 決済リクエスト
  Note right of Payment: 決済情報<br/>・金額: ¥10,000<br/>・カード情報

  Payment->>Payment: 決済情報検証
  Payment->>+Card: オーソリ要求
  Card->>+Bank: 与信確認
  Bank-->>-Card: 与信OK
  Card-->>-Payment: オーソリOK

  Payment->>Payment: 決済処理実行
  Payment->>+Card: 売上確定
  Card-->>-Payment: 確定完了

  Payment-->>-Shop: 決済完了

  par 並列処理
    Shop->>Customer: 注文完了画面
  and
    Shop->>Notification: メール送信依頼
    Notification->>Customer: 注文確認メール
  end

マイクロサービス間通信

sequenceDiagram
  autonumber
  participant Client
  participant Gateway as API Gateway
  participant Auth as Auth Service
  participant User as User Service
  participant Order as Order Service
  participant Notification as Notification Service

  Client->>+Gateway: GET /api/users/123/orders
  Gateway->>+Auth: トークン検証
  Auth-->>-Gateway: 検証OK (userId: 123)

  par 並列データ取得
    Gateway->>+User: GET /users/123
    User-->>-Gateway: ユーザー情報
  and
    Gateway->>+Order: GET /orders?userId=123
    Order-->>-Gateway: 注文リスト
  end

  Gateway->>Gateway: データ結合
  Gateway-->>-Client: 統合レスポンス

  loop 各注文に対して
    Client->>+Gateway: POST /api/orders/{id}/invoice
    Gateway->>+Order: 請求書生成
    Order->>+Notification: 請求書送信依頼
    Notification-->>-Order: 送信完了
    Order-->>-Gateway: 生成完了
    Gateway-->>-Client: 200 OK
  end

ステートダイアグラム

提供いただいたサンプル（申請フロー）

stateDiagram-v2
    state if_age <<choice>>
    state if_butt <<choice>>
    state if_trial <<choice>>
    [*] --> プロフィール入力
    プロフィール入力 --> if_age
    if_age --> 登録後1週 : 65歳以上
    if_age --> 【65歳未満】: 65歳未満
    登録後1週 --> if_trial
    if_trial --> 【65歳以上1週以内】\nbuttedAt=null\nlinkedId=null\nButtStatus=notYet : 1週以内
    if_trial --> 住基突合: 1週1日以上
    住基突合 --> if_butt
    if_butt --> 【65歳以上区内】\nbuttedAt=有\nlinkedId=有\nButtStatus=successful : 突合
    if_butt --> 【65歳以上区外】\nbuttedAt=有\nlinkedId=null\nButtStatus=failed : 失敗
    if_butt --> 【65歳以上転出】\nbuttedAt=null\nlinkedId=有\nButtStatus=movedOut : 削除
    【65歳以上区外】\nbuttedAt=有\nlinkedId=null\nButtStatus=failed --> アプリ利用申請ボタン
    【65歳以上転出】\nbuttedAt=null\nlinkedId=有\nButtStatus=movedOut --> 転入
    転入 --> アプリ利用申請ボタン
    アプリ利用申請ボタン --> 住基突合

注文状態遷移

stateDiagram-v2
    [*] --> カート
    カート --> 注文確認: 購入手続きへ
    注文確認 --> 決済処理: 注文確定

    state 決済処理 {
        [*] --> 与信確認
        与信確認 --> 決済実行: 与信OK
        与信確認 --> 決済失敗: 与信NG
        決済実行 --> [*]
        決済失敗 --> [*]
    }

    決済処理 --> 注文完了: 決済成功
    決済処理 --> 注文失敗: 決済失敗
    注文完了 --> 準備中: 自動遷移
    準備中 --> 発送済み: 発送処理
    発送済み --> 配達完了: 配達完了通知
    配達完了 --> [*]

    注文失敗 --> [*]
    カート --> [*]: キャンセル
    注文確認 --> カート: 戻る

高度な機能

ループと条件分岐

sequenceDiagram
  participant Client
  participant Server
  participant Cache
  participant DB

  Client->>+Server: データ一覧取得

  alt キャッシュ有効
    Server->>+Cache: キャッシュ確認
    Cache-->>-Server: キャッシュデータ
  else キャッシュ無効
    Server->>+DB: SELECT * FROM items
    DB-->>-Server: データ一覧
    Server->>Cache: キャッシュ保存
  end

  loop 各アイテムに対して
    Server->>Server: データ加工
    opt 画像URLが必要
      Server->>Server: 画像URL生成
    end
  end

  Server-->>-Client: 加工済みデータ

並列処理とクリティカルセクション

sequenceDiagram
  participant User
  participant API
  participant Service1
  participant Service2
  participant Service3

  User->>+API: 複合処理リクエスト

  par 並列処理1
    API->>+Service1: 処理A
    Service1-->>-API: 結果A
  and 並列処理2
    API->>+Service2: 処理B
    Service2-->>-API: 結果B
  and 並列処理3
    API->>+Service3: 処理C
    Service3-->>-API: 結果C
  end

  critical 排他制御区間
    API->>API: 結果の集約
    API->>API: データ整合性チェック
  option エラーがある場合
    API->>API: ロールバック処理
  end

  API-->>-User: 統合結果

ノートとハイライト

sequenceDiagram
  participant A as フロントエンド
  participant B as バックエンド
  participant C as データベース

  Note left of A: ユーザーがフォームに入力
  A->>+B: POST /api/data
  Note over A,B: HTTPSで暗号化

  rect rgb(200, 150, 255)
    Note right of B: トランザクション開始
    B->>+C: BEGIN TRANSACTION
    B->>C: INSERT INTO table1
    B->>C: UPDATE table2
    B->>C: COMMIT
    C-->>-B: トランザクション完了
  end

  B-->>-A: 200 OK

  rect rgb(255, 200, 200)
    Note over A,C: エラーハンドリング
    A->>+B: POST /api/data (不正なデータ)
    B-xB: バリデーションエラー
    B--x-A: 400 Bad Request
  end

ベストプラクティス

1. わかりやすい名前付け

   • 参加者（participant）には役割がわかる名前を使用
   • エイリアスを活用して表示名を簡潔に

2. 適切な矢印の使い分け

   • 同期/非同期を明確に区別
   • 活性化（+/-）を使って処理期間を表現

3. 構造化

   • loop、alt、opt、parを使って複雑なフローを整理
   • criticalで排他制御区間を明示

4. 注釈の活用

   • Noteで重要な情報を補足
   • rectでグループ化して視覚的に区別

5. 番号付け

   • autonumberで自動番号付けし、説明時の参照を容易に