Mermaid シーケンス図エディタ
シーケンス図は、関係者のあいだでやり取りされるメッセージを起きた順に示します。時間は上から下へ流れます。誰がどの順で誰を呼び、何が返ってくるのかが問いであるとき——API のやり取り、認証フロー、リトライ——に向いています。ある 1 つのコンポーネント内部の分岐が主題なら、フローチャートのほうが適しています。
OAuth 2.0 認可コードフロー
シーケンス図の典型的な出番です。関係者が 4 つ、利用者からは見えないリダイレクトが 1 回、そしてサーバー間でしか行えないトークン交換があります。文章では説明しにくく、フローチャートでは順序そのものを表せません。
sequenceDiagram
autonumber
participant U as 利用者
participant B as ブラウザ
participant A as 認可サーバー
participant API as リソース API
U->>B: 「ログイン」を押す
B->>A: GET /authorize?client_id&redirect_uri
A-->>B: ログイン画面へリダイレクト
U->>A: 認証情報を送信
A-->>B: 302 で redirect_uri へ、code 付き
B->>API: code を付けて POST /token
API->>A: code を交換 (サーバー間)
A-->>API: access_token と refresh_token
API-->>B: セッション Cookie を発行
B-->>U: ログイン完了実例で理解する
1. 関係者 2 つ、往復 1 回
`->>` は実線で塗りつぶしの矢じり、慣例としてリクエストです。`-->>` は破線で、慣例としてレスポンスです。強制ではありませんが、崩すと図がひと目で読めなくなります。
sequenceDiagram
クライアント->>サーバー: GET /orders
サーバー-->>クライアント: 200 注文一覧2. 別名と実行区間
`participant X as 長い名前` にすると、矢印は短いまま枠の表示だけ読みやすくできます。`activate` と `deactivate` は関係者が処理中である区間を描き、遅い下流呼び出しを見えるようにするのに便利です。
sequenceDiagram
participant API as 注文 API
participant DB as Postgres
API->>DB: SELECT * FROM orders
activate DB
DB-->>API: 4,200 行
deactivate DB
API->>API: レスポンスを組み立て3. alt と opt による分岐
`alt`/`else` は二者択一、`opt` は起きないこともある手順です。これらのブロックはすべて `end` で閉じる必要があります。閉じ忘れはシーケンス図で最も多いエラーで、しかも Mermaid はそれをブロックではなくファイル末尾で報告します。
sequenceDiagram
participant C as 決済画面
participant P as 決済代行
C->>P: 4,990 円を与信
alt 与信成功
P-->>C: 承認コード
C->>C: 注文を支払済みにする
else 与信失敗
P-->>C: 拒否理由
C->>C: 在庫の確保を解除
end
opt 不正スコアが高い
C->>C: 目視確認のキューへ
end4. リトライループと注記
`loop` は繰り返すメッセージをまとめます。`Note over` は、読み手が必ず聞きたくなること——タイムアウト値、上限回数、なぜ回数を制限するのか——を書いておく場所です。
sequenceDiagram
participant W as ワーカー
participant S as 検索インデックス
Note over W,S: リトライは 5 回まで、その後は退避
loop 最大 5 回
W->>S: PUT /documents/42
S-->>W: 503 Service Unavailable
W->>W: 指数バックオフ
end
W->>W: デッドレターキューへ移動5. 並行処理と自己呼び出し
`par` は同時に進む処理を表します。文章がいちばん苦手とするものです。関係者から自分自身への矢印は、架空のコンポーネントをでっち上げずに内部処理を示す正当な書き方です。
sequenceDiagram
participant O as 注文サービス
participant M as メール送信
participant I as 請求サービス
participant A as 分析基盤
O->>O: トランザクションを確定
par 顧客へ通知
O->>M: 確認メールを送信
and 帳票を作成
O->>I: 請求書 PDF を生成
and 指標を記録
O->>A: order_created を送出
end
O-->>O: 呼び出し元へ 201 を返すシーケンス図構文早見表
シーケンス図には独自の矢印の語彙があります。どれもフローチャートでは通用せず、逆にフローチャートの矢印はここでは期待どおりの意味になりません。
| 構文 | 意味 |
|---|---|
| sequenceDiagram | 図を開始。大文字小文字を区別する——`sequencediagram` は失敗。 |
| participant A | 関係者を宣言し、左から右の並び順を確定する。 |
| participant A as 名前 | 別名——矢印では短い ID、枠では正式名。 |
| actor A | participant と同じだが、人型で描かれる。 |
| A->>B: 文字 | 実線・塗りつぶし矢じり。慣例としてリクエスト。 |
| A-->>B: 文字 | 破線・塗りつぶし矢じり。慣例としてレスポンス。 |
| A->B: 文字 | 実線、矢じりなし。 |
| A-)B: 文字 | 開いた矢じり——慣例として非同期メッセージ。 |
| A-xB: 文字 | 末端が×の矢印——慣例として失われたメッセージ。 |
| activate A / deactivate A | A が処理中であることを示す実行区間を描く。 |
| alt 条件 / else 条件 / end | 排他的な分岐。 |
| opt 条件 / end | 実行されないことがあるブロック。 |
| loop 文字 / end | 繰り返されるメッセージ。 |
| par 文字 / and 文字 / end | 並行して進む分岐。 |
| Note over A,B: 文字 | 関係者をまたぐ注記。`Note left of`、`Note right of` もある。 |
| autonumber | 各メッセージに自動で番号を振る。 |
シーケンス図を壊す 6 つのエラー
いずれも Mermaid 11.12.2 で再現しました。壊れているほうを貼れば同じエラーが出て、直したほうは描画されます。
表示されるもの
図の最終行で Parse error
原因
開いたまま閉じていないブロックがあります。`alt`、`opt`、`loop`、`par` はいずれも対になる `end` が必要です。Mermaid は入力が尽きて初めて気づくため、閉じ忘れたブロックではなく最終行のせいにします。
対処
開いたブロックの数と `end` の数を数えます。エラー行がファイルの最後なら、ほぼ確実にこれです。
sequenceDiagram
A->>B: 要求
alt 成功
B-->>A: 了解sequenceDiagram
A->>B: 要求
alt 成功
B-->>A: 了解
end表示されるもの
メッセージ行で Parse error
原因
メッセージにコロンがありません。どの矢印にも後ろに `: 文字` が必要で、内容が自明に思えても省けません。
対処
コロンとラベルを足します。
sequenceDiagram
顧客->>店舗 注文sequenceDiagram
顧客->>店舗: 注文表示されるもの
No diagram type detected matching given configuration
原因
キーワードの大文字小文字が違います。Mermaid の図種キーワードは大文字小文字を区別し、`sequencediagram` は `sequenceDiagram` とは別のトークンです。
対処
D を大文字にします。
sequencediagram
A->>B: こんにちはsequenceDiagram
A->>B: こんにちは表示されるもの
Trying to inactivate an inactive participant (B)
原因
対応する `activate` のない `deactivate` があります。上の構文エラーと違ってこれは意味的な検査なので、メッセージはトークンの羅列ではなく読める文章です。それでも図は描画されません。
対処
`deactivate` は必ず `activate` と対にするか、両方やめて矢印だけで表します。
sequenceDiagram
A->>B: 要求
deactivate BsequenceDiagram
A->>B: 要求
activate B
B-->>A: 応答
deactivate B表示されるもの
関係者名の後ろで Parse error
原因
participant 行にコロンを書いています。この宣言が受け取れるのは名前か `as` による別名だけです。
対処
表示名には `as` を使います。
sequenceDiagram
participant API: 注文サービス
API->>DB: 問い合わせsequenceDiagram
participant API as 注文サービス
API->>DB: 問い合わせ表示されるもの
`end` がブロックを閉じずに関係者として現れる
原因
`end` はここでもキーワードです。ブロックの終わりを決めるのはインデントではなくトークンなので、`end` という名前の関係者はブロック終端と衝突します。
対処
関係者に `end` という名前を付けないこと。大文字にするか別名にします。
sequenceDiagram
A->>end: 終了処理sequenceDiagram
A->>Endpoint: 終了処理描画についての覚え書き
いずれもこのサイトが使う Mermaid 11.12.2 での実測です。シーケンス図は 2 つの点でここの他のどの図とも違う挙動をします。
関係者名を日本語にしても図は広がらない
日本語話者がいちばん心配しがちで、実際には心配のいらない点です。`participant A as Order service` / `participant B as Payment provider` を「注文サービス」「決済プロバイダ」に置き換えて実測したところ、viewBox は 450×215 で完全に同一でした。理由は次の項目のとおりで、シーケンス図の幅は関係者の数と間隔で決まり、ラベルの長さでは決まりません。既定の間隔を超えるほど長い名前でない限り、日本語名は事実上ただです。
幅を決めるのは関係者の数であって、メッセージの数ではない
関係者 2 つのあいだのメッセージ 3 本で viewBox はおよそ 450×309。同じ 2 つのあいだで 40 本にすると 450×2011 で、幅は一切動きません。関係者を増やすと横に広がり、メッセージを増やすと縦に伸びるだけです。実務的には、関係者が 6 つを超えるとノート PC の画面では読めない幅になります。メッセージ数が問題になるよりずっと手前です。
シーケンス図の viewBox 原点は負の値
このサイトの他の図種はすべて viewBox が `0 0` から始まりますが、シーケンス図は `-50 -10` から始まります。関係者の枠のために左と上に余白が確保されるためです。書き出した SVG を後段で加工するなら重要で、原点をゼロと決め打ちした切り出し処理は左端の関係者を切り落とします。
PNG 書き出しはここでは素直に動く
シーケンス図はラベルを埋め込み HTML ではなく通常の SVG テキストとして描きます。フローチャート、クラス図、状態遷移図、ER 図とはここが違います。ブラウザがそのままラスタライズできるため、書き出した PNG は画面と 1 ピクセル単位で一致します。描き直しも文字組みのずれもありません。
メッセージ 1 本あたりの高さはおよそ 45 ピクセル
書き始める前に、その図がスライド 1 枚に収まるかを見積もるのに使えます。メッセージ 20 本でおよそ 900 ピクセル。スクロールせずに読めるスクリーンショットの実用上限はこのあたりです。
別の図が向いている場合
メッセージの大半がある関係者から自分自身へのものなら、それは会話ではなくアルゴリズムの説明です。フローチャートのほうが読みやすくなります。
`alt` ブロックの中にさらに `alt` を入れ始めたら、分岐がこの形式の手に余っています。シーケンス図はシステムを通る 1 本の経路を見事に描き、すべての経路を非常にまずく描きます。ここには正常系だけを描き、異常系は別の図に分けてください。
そして本当に伝えたいのが、どんなコンポーネントがあってどうつながっているか——どんな順で通信するかではなく——なら、シーケンス図は役に立ちません。それはアーキテクチャ図であり、Mermaid ならサブグラフ付きのフローチャートのほうが合います。
他の図の種類
執筆 Dominik Malsch · 最終更新: