2026.09.29

技術 💻
設計

シーケンス図の書き方｜記号・矢印・alt/loop一覧と実務6パターン

RJC Techチーム

結論

シーケンス図とは、登場人物が「どの順番で、誰に、何を送るか」を、上から下へ進む時間に沿って描く UML の図です。描くのは処理の手順ではなく、やり取りの順番です。

この記事でわかること

記号17種の早見表（Mermaid の書き方つき）
alt・loop など複合フラグメント7種の書き方
ログイン・決済など実務6パターンの完成コード

2026年10月16日更新｜Mermaid 11.17.2・PlantUML 1.2026.8 で描画確認

利用者・Webアプリ・会員DB を横に並べ、縦線（ライフライン）のあいだを 4 本の矢印（メッセージ）でつないだ、いちばん小さいシーケンス図です。

sequenceDiagram
    actor U as 利用者
    participant W as Webアプリ
    participant D as 会員DB
    U->>W: ログイン（ID・パスワード）
    W->>D: 利用者を検索
    D-->>W: 利用者レコード
    W-->>U: マイページを表示

この図のコードは次のとおりです。

sequenceDiagram
    actor U as 利用者
    participant W as Webアプリ
    participant D as 会員DB
    U->>W: ログイン（ID・パスワード）
    W->>D: 利用者を検索
    D-->>W: 利用者レコード
    W-->>U: マイページを表示

記号の早見表です。各記号の図と PlantUML のコードは、この後の節にあります。

記号	意味	Mermaid の書き方
同期メッセージ	呼び出して応答を待つ（実線）	`A->>B: 処理`
応答メッセージ	呼び出しへの返事（破線）	`B-->>A: 結果`
ライフライン	登場人物と、その存在期間	`participant A as 名前`
アクター	システムの外の人・外部システム	`actor U as 利用者`
alt	条件分岐（if／else）	`alt 条件` 〜 `else 条件` 〜 `end`
loop	繰り返し	`loop 条件` 〜 `end`
活性化バー	処理を実行中の期間（縦長の箱）	矢印に `+`／`-`、`activate A`
opt	条件を満たすときだけ実行	`opt 条件` 〜 `end`
非同期メッセージ	送ったら待たずに進む（開いた矢じり）	`A-)B: 処理`
ノート	補足説明	`Note over A,B: 説明`
自己呼び出し	自分の中の処理	`A->>A: 処理`
par	並行（順序を問わない）	`par` 〜 `and` 〜 `end`
break	条件を満たしたら残りを打ち切る	`break 条件` 〜 `end`
生成	途中で登場人物が作られる	`create participant C`
消滅	登場人物が消える（×）	`destroy C`
critical	割り込ませない区間	`critical` 〜 `end`
ref	別の図を参照	なし（ノートで代用）

確認環境：Mermaid 11.17.2（npm パッケージ）を Chromium（playwright-core 1.64.1）で描画し、この記事の Mermaid の図 22 枚すべてが構文エラーなく描けることを確かめました。画像化は @mermaid-js/mermaid-cli 12.0.0（mmdc）。PlantUML は GitHub リリースの plantuml-1.2026.8.jar を OpenJDK 21（Linux）で実行し、-checkonly と PNG・SVG 出力で確かめました。記号の意味は OMG の UML 2.5.1 仕様、構文は Mermaid・PlantUML の公式ドキュメント、各ツールの料金・機能は各社の公式ページで確かめています（確認日 2026年10月16日）。

本記事の内容は、ご自由にお使いください。
ご利用の際は、出典として本ページへのリンクを記載いただけますようお願いします。

（記載例）出典：株式会社RJC「シーケンス図の書き方｜記号・矢印・alt/loop一覧と実務6パターン」

シーケンス図とは：何を描いて、何を描かない図か

シーケンス図は、UML 2.5.1 で「相互作用図」に分類される図で、ライフライン（登場人物）のあいだで交わされるメッセージを、時間の順に表します。 1 枚で「1 つのシナリオ」を描きます。たとえば「ログインが成功するとき・失敗するとき」は 1 枚、「予約の確定」は別の 1 枚です。

知りたいこと	向いている図
誰が誰に、どの順番で何を送るか	シーケンス図
処理の手順と分岐（手続きの流れ）	アクティビティ図・フローチャート
1 つのものが、どの状態からどの状態へ変わるか	状態遷移図
システムに誰が関わり、何ができるか	ユースケース図
データの構造・クラスどうしの関係	クラス図・ER図

図の使い分けは関連記事「UML図の種類一覧：全14種類の使い分けと工程別早見表・PlantUML例」で扱っています。手順を描きたいときは関連記事「アクティビティ図の書き方と記号一覧スイムレーン例をPlantUMLで」、状態の変化は関連記事「状態遷移図と状態遷移表の書き方｜テスト設計とMermaid・PlantUML」で扱っています。

シーケンス図の読み方（4 つの約束）

時間は上から下へ進みます。矢印の上下の位置が、そのまま順番です
左が呼ぶ側、右が呼ばれる側です。利用者 → 画面 → サーバー → DB → 外部システムの順に並べると、矢印が左から右へ流れて読みやすくなります
矢印の線と矢じりで「待つ・待たない・返事」を読みます。実線は呼び出し、破線は応答です
枠（alt・loop など）の中だけが、条件付き・繰り返しです。枠の外は無条件に 1 回だけ起こります

シーケンス図の記号一覧（Mermaid・PlantUML の図つき）

ライフラインとアクター

ライフラインは「登場人物」と「その存在期間」を表します。 上の箱が名前、下に伸びる縦線が時間です（UML の表記では破線。Mermaid は実線で描きます）。システムの外にいる人や外部システムは、人の形の「アクター」で区別します。

sequenceDiagram
    actor U as 利用者
    participant W as Webアプリ
    participant D as 会員DB
    U->>W: 操作
    W->>D: 問い合わせ

sequenceDiagram
    actor U as 利用者
    participant W as Webアプリ
    participant D as 会員DB
    U->>W: 操作
    W->>D: 問い合わせ

@startuml
actor 利用者 as U
participant Webアプリ as W
database 会員DB as D
U -> W : 操作
W -> D : 問い合わせ
@enduml

Mermaid は participant 別名 as 表示名、PlantUML は participant 表示名 as 別名 と順番が逆です
並び順は宣言した順です。宣言しないと、最初に矢印に出てきた順に並びます
PlantUML は database（円柱）、queue、boundary、control、entity、collections の記号を選べます。Mermaid 11 では participant D@{ "type": "database", "alias": "会員DB" } と書くと円柱になります（Mermaid 11.17.2 で描画できました。描画する環境の Mermaid の版が合うか確かめてから使います）

活性化バー（実行仕様）

活性化バーは、その登場人物が処理を実行している期間を表す縦長の箱です。 UML では「実行仕様（ExecutionSpecification）」と呼びます。呼び出しを受けてから応答を返すまでを箱にすると、「どこで待っているか」が見えます。

sequenceDiagram
    participant W as Webアプリ
    participant A as 認証API
    participant D as 会員DB
    W->>+A: POST /login
    A->>+D: 利用者を検索
    D-->>-A: 利用者レコード
    A-->>-W: 200 OK

sequenceDiagram
    participant W as Webアプリ
    participant A as 認証API
    participant D as 会員DB
    W->>+A: POST /login
    A->>+D: 利用者を検索
    D-->>-A: 利用者レコード
    A-->>-W: 200 OK

@startuml
participant Webアプリ as W
participant 認証API as A
participant 会員DB as D
W -> A ++ : POST /login
A -> D ++ : 利用者を検索
D --> A -- : 利用者レコード
A --> W -- : 200 OK
@enduml

Mermaid は矢印の先に +（受け手を活性化）、矢印の元に -（送り手の活性化を終了）を付けます。activate A／deactivate A の行で書くこともできます
PlantUML は ++（受け手を活性化）、--（送り手を終了）です。activate／deactivate も使えます
活性化バーの中で、さらに別の相手を呼ぶと、バーは入れ子になります

メッセージの矢印の種類（同期・非同期・応答・生成・消滅）

矢印は「待つか、待たないか、返事か」で描き分けます。 UML 2.5.1 の表記では、同期は塗りつぶした矢じり、非同期は開いた矢じり、応答は破線、生成は破線が相手の箱に直接届く形、消滅はライフラインの終わりの ×です。

種類	UML の見た目	意味	Mermaid	PlantUML
同期	実線＋塗りつぶし矢じり	呼び出して、応答が来るまで待つ	`A->>B: 処理`	`A -> B : 処理`
非同期	実線＋開いた矢じり	送ったら待たずに次へ進む	`A-)B: 処理`	`A ->> B : 処理`
応答	破線＋矢じり	呼び出しへの返事	`B-->>A: 結果`（UML に合わせるなら `B--)A`）	`B --> A : 結果`
生成	破線が箱に届く	途中で登場人物が作られる	`create participant C` の次の矢印	`create C` の次の矢印、または `A -> C ** : 生成`
消滅	ライフラインの先の ×	登場人物が消える	`destroy C` の次の矢印（`A-xC: 削除`）	`A -> C !! : 削除`

sequenceDiagram
    participant A as 注文API
    participant S as 在庫サービス
    participant Q as キュー
    A->>S: 同期：在庫を確認（応答を待つ）
    S-->>A: 応答：在庫あり
    A-)Q: 非同期：イベントを送る（待たない）
    create participant J as ジョブ
    A->>J: 生成：ジョブを作る
    destroy J
    A-xJ: 消滅：ジョブを破棄

sequenceDiagram
    participant A as 注文API
    participant S as 在庫サービス
    participant Q as キュー
    A->>S: 同期：在庫を確認（応答を待つ）
    S-->>A: 応答：在庫あり
    A-)Q: 非同期：イベントを送る（待たない）
    create participant J as ジョブ
    A->>J: 生成：ジョブを作る
    destroy J
    A-xJ: 消滅：ジョブを破棄

@startuml
participant 注文API as A
participant 在庫サービス as S
participant キュー as Q
A -> S : 同期：在庫を確認（応答を待つ）
S --> A : 応答：在庫あり
A ->> Q : 非同期：イベントを送る（待たない）
create participant ジョブ as J
A -> J : 生成：ジョブを作る
A -> J !! : 消滅：ジョブを破棄
@enduml

Mermaid と PlantUML では ->> の意味が逆です。 Mermaid の ->> は塗りつぶし矢じり（同期）、PlantUML の ->> は細い矢じり（非同期）です。書き換えるときにいちばん間違えやすい点です。

Mermaid の応答 -->> は、描画すると破線に塗りつぶし矢じりになります。UML の応答（開いた矢じり）に厳密に合わせたいときは --) を使います（Mermaid 11.17.2 で、破線＋開いた矢じりで描画されました）。どちらを使うかより、チーム内で「破線＝応答」と決めておくことが読み違いを防ぎます。

Mermaid の create・destroy は v10.3.0 で加わった構文です。create は「次の矢印で作られる」という宣言なので、直後の矢印の受け手がその登場人物でないとエラーになります（後述）。

自己呼び出しとノート

sequenceDiagram
    participant A as 認証API
    participant D as 会員DB
    A->>A: 入力値を検証
    Note right of A: 自己呼び出し：自分の中の処理
    A->>D: ハッシュを照合
    Note over A,D: 失敗が5回続いたらロック

sequenceDiagram
    participant A as 認証API
    participant D as 会員DB
    A->>A: 入力値を検証
    Note right of A: 自己呼び出し：自分の中の処理
    A->>D: ハッシュを照合
    Note over A,D: 失敗が5回続いたらロック

@startuml
participant 認証API as A
participant 会員DB as D
A -> A : 入力値を検証
note right of A : 自己呼び出し：自分の中の処理
A -> D : ハッシュを照合
note over A, D : 失敗が5回続いたらロック
@enduml

ノートは Note right of A（右）、Note left of A（左）、Note over A,D（2 人にまたがる）の 3 通りです。タイムアウトの秒数、再試行の回数、ロックの条件など「矢印では表せない前提」はノートに書きます。 自己呼び出しは「入力チェック」「金額計算」のように、読み手の判断に関わる処理だけに絞ります。

複合フラグメント alt・opt・loop・par・break・critical・ref の書き方

複合フラグメントとは、メッセージのまとまりを枠で囲み、左上の演算子で「分岐」「繰り返し」などの意味を与える記法です。 枠の中の条件（ガード条件）は [ ] に書きます。Mermaid と PlantUML は、ラベルに書いた文字を自動で [ ] で囲みます。

演算子	意味	使う場面の例	Mermaid	PlantUML
alt	条件分岐。どれか 1 つの枝だけ実行	パスワード一致／不一致	`alt`〜`else`〜`end`	同じ
opt	条件を満たすときだけ実行（else なし）	ポイント利用があれば減算	`opt`〜`end`	同じ
loop	繰り返し	対象 1 件ごと、最大 3 回の再試行	`loop`〜`end`	同じ
par	並行。枝の順序は問わない	通知と記録を同時に	`par`〜`and`〜`end`	`par`〜`else`〜`end`
break	条件を満たしたら枠内を実行し、外側の残りを打ち切る	在庫 0 なら注文を中止	`break`〜`end`	同じ
critical	枠内を割り込まれずに一続きで実行	ロックを取って更新	`critical`〜`end`	同じ
ref	別のシーケンス図を参照	「ログイン処理」を別図に	なし（ノートで代用）	`ref over A, B : 図名`

UML 2.5.1 には、このほかに seq（弱い順序。既定）、strict（厳密な順序）、neg（起きてはいけない流れ）、assert（必ずこうなる）、ignore（無視するメッセージ）、consider（注目するメッセージ）があり、全部で 12 種類です。業務システムの設計書は、上の表の 7 種類でほぼ書けます。

alt（条件分岐）と条件の書き方

alt は「条件によって、どれか 1 つの枝だけが起こる」ことを表します。 else は「それ以外すべて」です。

sequenceDiagram
    participant A as 認証API
    participant D as 会員DB
    A->>D: パスワードを照合
    D-->>A: 一致／不一致
    alt 一致
        A->>A: セッションを発行
    else 不一致（失敗 5 回未満）
        A->>D: 失敗回数を +1
    else 不一致（失敗 5 回目）
        A->>D: アカウントをロック
    end

sequenceDiagram
    participant A as 認証API
    participant D as 会員DB
    A->>D: パスワードを照合
    D-->>A: 一致／不一致
    alt 一致
        A->>A: セッションを発行
    else 不一致（失敗 5 回未満）
        A->>D: 失敗回数を +1
    else 不一致（失敗 5 回目）
        A->>D: アカウントをロック
    end

@startuml
participant 認証API as A
participant 会員DB as D
A -> D : パスワードを照合
D --> A : 一致／不一致
alt 一致
  A -> A : セッションを発行
else 不一致（失敗 5 回未満）
  A -> D : 失敗回数を +1
else 不一致（失敗 5 回目）
  A -> D : アカウントをロック
end
@enduml

条件の書き方で、レビューの質が変わります。

書き方	問題	直し方
`alt 正常` ／ `else 異常`	何をもって正常かが読めない	`alt パスワード一致` ／ `else 不一致`
`alt 成功` ／ `else 失敗` ／ `else タイムアウト`	「失敗」に「タイムアウト」が含まれ、枝が重なる	枝が重ならない条件にする（`else 不一致` ／ `else 応答なし（3 秒）`）
`alt [一致]`	Mermaid は `[[一致]]` と二重になる。PlantUML は `[[ ]]` がリンクの記法なので、条件がリンクになる	括弧は書かない（自動で付く）
`else` だけ	「それ以外」に何が含まれるかを読み手が補う	`else それ以外（会員なし・不一致）` のように中身を添える
`alt 3 回まで再試行`	分岐ではなく繰り返し	`loop 最大 3 回` を使う

alt と opt の違いは「else 側で何かするか」です。 else 側で何もしないなら opt、何かするなら alt です。「UML の alt」と検索して来た方は、この表の 1 行目と 2 行目を見れば、ほとんどの迷いが解けます。

opt（条件を満たすときだけ）

sequenceDiagram
    participant O as 注文API
    participant P as ポイントサービス
    O->>O: 合計金額を計算
    opt ポイント利用あり
        O->>P: ポイントを減算
        P-->>O: 残高
    end

sequenceDiagram
    participant O as 注文API
    participant P as ポイントサービス
    O->>O: 合計金額を計算
    opt ポイント利用あり
        O->>P: ポイントを減算
        P-->>O: 残高
    end

@startuml
participant 注文API as O
participant ポイントサービス as P
O -> O : 合計金額を計算
opt ポイント利用あり
  O -> P : ポイントを減算
  P --> O : 残高
end
@enduml

opt に else を書くと、Mermaid は Parse error になります（後述）。else が要るなら alt に変えます。

loop（繰り返し）

loop は、枠の中を条件が成り立つあいだ、または決めた回数だけ繰り返します。 UML の表記では loop(最小, 最大) と回数を書けます（例：loop(1, 3)）。Mermaid と PlantUML のラベルは自由な文字なので、回数か終了条件を数字で書きます。「数回」では実装とテストの基準になりません。

sequenceDiagram
    participant B as 請求バッチ
    participant D as 業務DB
    loop 対象の注文 1件ごと
        B->>D: 注文を取得
        B->>B: 請求額を計算
        B->>D: 請求を登録
    end

sequenceDiagram
    participant B as 請求バッチ
    participant D as 業務DB
    loop 対象の注文 1件ごと
        B->>D: 注文を取得
        B->>B: 請求額を計算
        B->>D: 請求を登録
    end

@startuml
participant 請求バッチ as B
database 業務DB as D
loop 対象の注文 1件ごと
  B -> D : 注文を取得
  B -> B : 請求額を計算
  B -> D : 請求を登録
end
@enduml

繰り返しの種類	ラベルの例
件数ぶん	`loop 対象の注文 1件ごと`
回数の上限がある再試行	`loop 最大 3 回（間隔 1 秒・2 秒）`
条件が成り立つあいだ	`loop 次ページがあるあいだ`
定期的	`loop 5 秒ごと（完了まで）`

par（並行）

par は「枝どうしの順序を問わない」という設計判断を表します。 通知と記録のどちらが先でもよい、という意味です。Mermaid は枝を and で、PlantUML は else で区切ります。

sequenceDiagram
    participant O as 注文API
    participant M as メール送信
    participant L as ログ基盤
    par 通知
        O-)M: 注文確認メールを依頼
    and 記録
        O-)L: 注文ログを送る
    end

sequenceDiagram
    participant O as 注文API
    participant M as メール送信
    participant L as ログ基盤
    par 通知
        O-)M: 注文確認メールを依頼
    and 記録
        O-)L: 注文ログを送る
    end

@startuml
participant 注文API as O
participant メール送信 as M
participant ログ基盤 as L
par 通知
  O ->> M : 注文確認メールを依頼
else 記録
  O ->> L : 注文ログを送る
end
@enduml

break（打ち切り）

break は「条件を満たしたら枠の中を実行し、外側の枠の残りを打ち切る」記法です。 loop の中に置くと「繰り返しをやめる」、図の直下に置くと「このシナリオをここで終える」という意味になります。

sequenceDiagram
    participant O as 注文API
    participant I as 在庫サービス
    loop 商品 1件ごと
        O->>I: 在庫を確認
        I-->>O: 在庫数
        break 在庫が 0 のとき
            O->>O: 注文全体を中止（残りの商品は確認しない）
        end
    end

sequenceDiagram
    participant O as 注文API
    participant I as 在庫サービス
    loop 商品 1件ごと
        O->>I: 在庫を確認
        I-->>O: 在庫数
        break 在庫が 0 のとき
            O->>O: 注文全体を中止（残りの商品は確認しない）
        end
    end

@startuml
participant 注文API as O
participant 在庫サービス as I
loop 商品 1件ごと
  O -> I : 在庫を確認
  I --> O : 在庫数
  break 在庫が 0 のとき
    O -> O : 注文全体を中止（残りの商品は確認しない）
  end
end
@enduml

critical（割り込ませない区間）

critical は、枠の中を他の処理に割り込まれずに一続きで実行することを表します。 ロックを取ってから解放するまでを枠にすると、トランザクションの境界がレビューで確かめやすくなります。Mermaid には option で「別の状況」を書き足す独自の書き方があります。UML の critical は枝を持たないので、分岐は中に alt を入れて表すと UML に慣れた読み手にも伝わります。

sequenceDiagram
    participant A as 予約API
    participant D as 予約DB
    critical 同じ枠への二重予約を防ぐ（ロック中）
        A->>D: SELECT ... FOR UPDATE（枠をロック）
        A->>D: INSERT 予約
        A->>D: COMMIT（ロック解放）
    option ロック待ちがタイムアウト
        A->>A: 409 Conflict を返す
    end

sequenceDiagram
    participant A as 予約API
    participant D as 予約DB
    critical 同じ枠への二重予約を防ぐ（ロック中）
        A->>D: SELECT ... FOR UPDATE（枠をロック）
        A->>D: INSERT 予約
        A->>D: COMMIT（ロック解放）
    option ロック待ちがタイムアウト
        A->>A: 409 Conflict を返す
    end

@startuml
participant 予約API as A
database 予約DB as D
critical 同じ枠への二重予約を防ぐ（ロック中）
  A -> D : SELECT ... FOR UPDATE（枠をロック）
  A -> D : INSERT 予約
  A -> D : COMMIT（ロック解放）
end
@enduml

ref（別の図の参照）

ref は「ここはログイン処理（別図）」のように、別のシーケンス図を参照する記法です。 共通の処理を切り出すと、1 枚 1 シナリオを保てます。PlantUML は ref over で描けます。Mermaid には ref がないため、ノートに「ref：図の名前」と書いて代用します。

sequenceDiagram
    actor U as 会員
    participant W as Webアプリ
    participant A as 予約API
    Note over U,A: ref：ログイン処理（別図 SEQ-01 を参照）
    U->>W: 予約を確定
    W->>A: POST /reservations
    A-->>W: 予約番号

sequenceDiagram
    actor U as 会員
    participant W as Webアプリ
    participant A as 予約API
    Note over U,A: ref：ログイン処理（別図 SEQ-01 を参照）
    U->>W: 予約を確定
    W->>A: POST /reservations
    A-->>W: 予約番号

@startuml
actor 会員 as U
participant Webアプリ as W
participant 予約API as A
ref over U, W, A : ログイン処理（SEQ-01）
U -> W : 予約を確定
W -> A : POST /reservations
A --> W : 予約番号
@enduml

Mermaid では、link W: 設計書 @ https://… で登場人物の箱にリンクのメニューを付けることもできます（Mermaid 11.17.2 で描画できました）。別図の URL を付けておくと、設計書の中で行き来できます。

シーケンス図の書き方の手順（5 ステップ）

手順は「登場人物を決める → 主な流れ → 分岐と繰り返し → 例外 → 粒度を決める」の順です。 最初から分岐や例外を入れると、主な流れが見えなくなります。「会員制の予約サイトで予約を確定する」を例に進めます。

ステップ 1：登場人物を決め、左から並べる

候補	入れるか	理由
会員（アクター）	入れる	操作の起点
予約画面	入れる	会員と API の橋渡し
予約API	入れる	判断と分岐の中心
予約DB	入れる	空き確認と登録の相手
メール送信	入れる	外部への通知（非同期）
ログ基盤・監視	入れない	この図の判断に影響しない。異常系の図で扱う
PasswordHasher などのクラス	入れない	基本設計の粒度では内部の部品

並び順は「呼ぶ側を左、呼ばれる側を右」です。 会員 → 画面 → API → DB → 外部の順に並べると、矢印が左から右へ流れます。

ステップ 2：主な流れ（正常系）を上から順に描く

まず、うまくいくときの矢印だけを描きます。

sequenceDiagram
    actor U as 会員
    participant W as 予約画面
    participant A as 予約API
    participant D as 予約DB
    participant M as メール送信
    U->>W: 枠を選んで「予約する」
    W->>A: POST /reservations
    A->>D: 空きを確認
    D-->>A: 空きあり
    A->>D: 予約を登録
    D-->>A: 予約番号
    A->>M: 確認メールを依頼
    A-->>W: 201 Created（予約番号）
    W-->>U: 予約完了を表示

sequenceDiagram
    actor U as 会員
    participant W as 予約画面
    participant A as 予約API
    participant D as 予約DB
    participant M as メール送信
    U->>W: 枠を選んで「予約する」
    W->>A: POST /reservations
    A->>D: 空きを確認
    D-->>A: 空きあり
    A->>D: 予約を登録
    D-->>A: 予約番号
    A->>M: 確認メールを依頼
    A-->>W: 201 Created（予約番号）
    W-->>U: 予約完了を表示

ここで矢印のラベルを具体的にします。「処理」「データ」ではなく、「POST /reservations」「予約番号」のように、API 設計書や DB 設計書と同じ言葉を使います。

ステップ 3：分岐と繰り返しを枠で囲む

「空きあり／満席」は alt、「複数の枠をまとめて予約」なら loop です。このとき、枝の条件が重ならないようにします。

ステップ 4：例外（エラー・タイムアウト）を足す

設計レビューでいちばん見られるのは例外の流れです。 DB エラー、タイムアウト、外部サービスの停止を、利用者に何が返るかまで描きます。メール送信は結果を待たないので、非同期の矢印に変えます。

sequenceDiagram
    autonumber
    actor U as 会員
    participant W as 予約画面
    participant A as 予約API
    participant D as 予約DB
    participant M as メール送信
    U->>W: 枠を選んで「予約する」
    W->>+A: POST /reservations
    A->>D: 空きを確認（枠をロック）
    D-->>A: 空き状況
    alt 空きあり
        A->>D: 予約を登録・COMMIT
        D-->>A: 予約番号
        A-)M: 確認メールを依頼（非同期）
        A-->>W: 201 Created（予約番号）
        W-->>U: 予約完了を表示
    else 満席
        A->>D: ROLLBACK
        A-->>W: 409 Conflict
        W-->>U: 「この枠は埋まりました」を表示
    else DB エラー・タイムアウト（3秒）
        A-->>W: 503 Service Unavailable
        W-->>U: 「時間をおいて再操作」を表示
    end
    deactivate A

sequenceDiagram
    autonumber
    actor U as 会員
    participant W as 予約画面
    participant A as 予約API
    participant D as 予約DB
    participant M as メール送信
    U->>W: 枠を選んで「予約する」
    W->>+A: POST /reservations
    A->>D: 空きを確認（枠をロック）
    D-->>A: 空き状況
    alt 空きあり
        A->>D: 予約を登録・COMMIT
        D-->>A: 予約番号
        A-)M: 確認メールを依頼（非同期）
        A-->>W: 201 Created（予約番号）
        W-->>U: 予約完了を表示
    else 満席
        A->>D: ROLLBACK
        A-->>W: 409 Conflict
        W-->>U: 「この枠は埋まりました」を表示
    else DB エラー・タイムアウト（3秒）
        A-->>W: 503 Service Unavailable
        W-->>U: 「時間をおいて再操作」を表示
    end
    deactivate A

autonumber で矢印に通し番号が付き、レビューで「7 番の矢印ですが」と指摘しやすくなります
活性化バーは W->>+A で始め、alt の外の deactivate A で閉じています。枝の中で - を使うと、枝ごとに閉じようとしてエラーになります（後述）
戻りには HTTP ステータスなど「何が返るか」を書くと、API 設計との対応がはっきりします

ステップ 5：粒度を決めて削る

「この矢印を消すと、読み手の判断が変わるか」で残すかどうかを決めます。変わらない矢印は、ノートにまとめるか消します。基準は「どこまで描くか：粒度と省略の判断表」の節にまとめました。

実務パターン 6 つ（完成コード＋図）

パターン 1：ログイン＋認証（alt・活性化バー・autonumber）

会員制サイトのログインです。「会員なし」と「パスワード不一致」で同じエラーを返す（どちらが違うかを教えない）、失敗 5 回でロック、という設計判断を図に入れています。

sequenceDiagram
    autonumber
    actor U as 会員
    participant B as ブラウザ
    participant A as 認証API
    participant D as 会員DB
    U->>B: ID・パスワードを入力
    B->>+A: POST /login
    A->>+D: 会員を検索（ID）
    D-->>-A: 会員レコード（なければ空）
    alt 会員あり かつ パスワード一致
        A->>D: 失敗回数を 0 に戻す
        A->>A: セッションを発行
        A-->>B: 200 OK（Set-Cookie: session）
        B-->>U: マイページを表示
    else 会員なし または 不一致（失敗 5 回未満）
        A->>D: 失敗回数を +1
        A-->>B: 401 Unauthorized
        B-->>U: 「ID またはパスワードが違います」
    else 不一致（失敗 5 回目）
        A->>D: ロック状態に更新
        A-->>B: 423 Locked
        B-->>U: 「ロックされました」
    end
    deactivate A

sequenceDiagram
    autonumber
    actor U as 会員
    participant B as ブラウザ
    participant A as 認証API
    participant D as 会員DB
    U->>B: ID・パスワードを入力
    B->>+A: POST /login
    A->>+D: 会員を検索（ID）
    D-->>-A: 会員レコード（なければ空）
    alt 会員あり かつ パスワード一致
        A->>D: 失敗回数を 0 に戻す
        A->>A: セッションを発行
        A-->>B: 200 OK（Set-Cookie: session）
        B-->>U: マイページを表示
    else 会員なし または 不一致（失敗 5 回未満）
        A->>D: 失敗回数を +1
        A-->>B: 401 Unauthorized
        B-->>U: 「ID またはパスワードが違います」
    else 不一致（失敗 5 回目）
        A->>D: ロック状態に更新
        A-->>B: 423 Locked
        B-->>U: 「ロックされました」
    end
    deactivate A

同じ図の PlantUML 版です。database で DB を円柱にし、autonumber で番号を付けています。

@startuml
autonumber
actor 会員 as U
participant ブラウザ as B
participant 認証API as A
database 会員DB as D
U -> B : ID・パスワードを入力
B -> A ++ : POST /login
A -> D ++ : 会員を検索（ID）
D --> A -- : 会員レコード（なければ空）
alt 会員あり かつ パスワード一致
  A -> D : 失敗回数を 0 に戻す
  A -> A : セッションを発行
  A --> B : 200 OK（Set-Cookie: session）
  B --> U : マイページを表示
else 会員なし または 不一致（失敗 5 回未満）
  A -> D : 失敗回数を +1
  A --> B : 401 Unauthorized
  B --> U : 「ID またはパスワードが違います」
else 不一致（失敗 5 回目）
  A -> D : ロック状態に更新
  A --> B : 423 Locked
  B --> U : 「ロックされました」
end
deactivate A
@enduml

ポイント

失敗回数の扱い（リセット・加算・ロック）を DB への矢印として描くと、「ロックはどこで決まるか」が実装前に確かめられます
ロックやパスワードリセットの仕様そのものは、関連記事「ログイン機能の設計項目一覧｜パスワードリセットとアカウントロックの仕様」で扱っています

パターン 2：外部 API 呼び出しとタイムアウト・再試行（loop・break・ノート）

EC の注文で、外部の在庫サービスに在庫数を問い合わせる場面です。タイムアウト、再試行、打ち切りを 1 枚で表します。

sequenceDiagram
    participant C as 画面
    participant O as 注文API
    participant S as 在庫サービス（外部）
    participant L as ログ基盤
    C->>+O: 注文内容を確認
    loop 最大 3 回（間隔 1 秒・2 秒）
        O->>S: GET /stock/{sku}（接続 1 秒・読み取り 3 秒）
        alt 3 秒以内に応答
            S-->>O: 200 在庫数
            Note over O: 応答があればループを抜ける
        else タイムアウト・5xx
            Note over O,S: 応答なし。待つのをやめて次の試行へ
        end
    end
    break 3 回とも失敗
        O-)L: 警告ログ（相手・回数・所要時間）
        O-->>C: 503（時間をおいて再操作を案内）
    end
    O-->>-C: 在庫あり・注文可能

sequenceDiagram
    participant C as 画面
    participant O as 注文API
    participant S as 在庫サービス（外部）
    participant L as ログ基盤
    C->>+O: 注文内容を確認
    loop 最大 3 回（間隔 1 秒・2 秒）
        O->>S: GET /stock/{sku}（接続 1 秒・読み取り 3 秒）
        alt 3 秒以内に応答
            S-->>O: 200 在庫数
            Note over O: 応答があればループを抜ける
        else タイムアウト・5xx
            Note over O,S: 応答なし。待つのをやめて次の試行へ
        end
    end
    break 3 回とも失敗
        O-)L: 警告ログ（相手・回数・所要時間）
        O-->>C: 503（時間をおいて再操作を案内）
    end
    O-->>-C: 在庫あり・注文可能

ポイント

タイムアウトは「相手からの応答」ではないので、戻りの矢印ではなく、呼び出し側のノートで表します
再試行の回数と間隔、接続と読み取りのタイムアウト値は数字で書きます。値の決め方は関連記事「タイムアウト設計の値の決め方｜接続・読み取りの違いと多段の計算例」と「指数バックオフとは？リトライ間隔の決め方とジッターの実装」で扱っています
再試行してよいのは、同じ要求を繰り返しても結果が変わらない呼び出し（在庫の照会など）です。登録系の API を再試行する設計は、関連記事「冪等性とは？API設計での意味と冪等キーの実装方法」で扱っています
ログ送信は結果を待たないので非同期（-)）です

パターン 3：非同期処理（ジョブキュー）（非同期矢印・par・生成と消滅）

時間のかかる CSV 出力をジョブキューに回す場面です。利用者はすぐ応答を受け取り、完了はメールで知らせます。

sequenceDiagram
    actor U as 利用者
    participant W as Webアプリ
    participant Q as ジョブキュー
    participant J as ワーカー
    participant M as メール送信
    U->>+W: CSV 出力を依頼
    W->>Q: ジョブを登録（job_id）
    W-->>-U: 202 Accepted（job_id）
    J->>Q: ジョブを取り出す（ポーリング）
    Q-->>J: ジョブ（job_id）
    activate J
    create participant F as 一時ファイル
    J->>F: CSV を書き出す
    par 通知
        J-)M: 完了メールを依頼
    and 状態更新
        J->>Q: 状態＝完了（DL 用 URL）
    end
    destroy F
    J-xF: DL 用の置き場へ移して削除
    deactivate J
    opt 画面を開いたまま
        U->>W: GET /jobs/{job_id}
        W-->>U: 状態＝完了・DL リンク
    end

sequenceDiagram
    actor U as 利用者
    participant W as Webアプリ
    participant Q as ジョブキュー
    participant J as ワーカー
    participant M as メール送信
    U->>+W: CSV 出力を依頼
    W->>Q: ジョブを登録（job_id）
    W-->>-U: 202 Accepted（job_id）
    J->>Q: ジョブを取り出す（ポーリング）
    Q-->>J: ジョブ（job_id）
    activate J
    create participant F as 一時ファイル
    J->>F: CSV を書き出す
    par 通知
        J-)M: 完了メールを依頼
    and 状態更新
        J->>Q: 状態＝完了（DL 用 URL）
    end
    destroy F
    J-xF: DL 用の置き場へ移して削除
    deactivate J
    opt 画面を開いたまま
        U->>W: GET /jobs/{job_id}
        W-->>U: 状態＝完了・DL リンク
    end

ポイント

Web アプリはジョブを登録したらすぐ 202 を返すので、W-->>-U で活性化バーが終わります。ワーカーの活性化バーは別に始まります。この「活性化バーが分かれている」ことが、非同期であることの目印です
create participant で途中から登場し、destroy で消える一時ファイルを描くと、後片付け漏れをレビューで確かめられます
par は「順序を問わない」という意味です。通知と状態更新のどちらが先でもよい、という設計判断を図で伝えています
同期と非同期の使い分けの基準や、キューの再試行は、関連記事「非同期処理の設計：同期との使い分け基準とジョブキューのリトライ設計」で扱っています

パターン 4：バッチ処理（loop・alt・実行記録）

夜間に動く請求バッチです。1 件のエラーで全体を止めない（スキップして記録する）、実行記録を残す、終了コードを返す、という設計をシーケンス図にします。

sequenceDiagram
    participant S as スケジューラ
    participant B as 請求バッチ
    participant D as 業務DB
    participant F as ファイル置き場
    participant N as 通知
    S->>+B: 起動（対象日＝前日）
    B->>D: 実行記録を「実行中」で登録
    B->>D: 対象の注文を取得（確定済み・未請求）
    D-->>B: 対象一覧
    loop 注文 1件ごと
        B->>B: 請求額を計算
        alt 計算できた
            B->>D: 請求を登録、注文を「請求済み」に更新
        else 顧客情報に不備
            B->>D: エラー一覧に記録（スキップして続行）
        end
    end
    B->>F: 請求一覧 CSV を出力
    B->>D: 実行記録を「正常終了」に更新（成功・エラー件数）
    B-)N: 結果を通知（件数・エラーの有無）
    B-->>-S: 終了コード 0（エラー行ありは 4）

sequenceDiagram
    participant S as スケジューラ
    participant B as 請求バッチ
    participant D as 業務DB
    participant F as ファイル置き場
    participant N as 通知
    S->>+B: 起動（対象日＝前日）
    B->>D: 実行記録を「実行中」で登録
    B->>D: 対象の注文を取得（確定済み・未請求）
    D-->>B: 対象一覧
    loop 注文 1件ごと
        B->>B: 請求額を計算
        alt 計算できた
            B->>D: 請求を登録、注文を「請求済み」に更新
        else 顧客情報に不備
            B->>D: エラー一覧に記録（スキップして続行）
        end
    end
    B->>F: 請求一覧 CSV を出力
    B->>D: 実行記録を「正常終了」に更新（成功・エラー件数）
    B-)N: 結果を通知（件数・エラーの有無）
    B-->>-S: 終了コード 0（エラー行ありは 4）

ポイント

「対象の取得条件（確定済み・未請求）」を矢印に書くと、再実行（リラン）したときに同じ注文を二重に請求しないことが図から読めます
1 件ずつ更新するのか、まとめて COMMIT するのかは、loop の中に COMMIT を描くかどうかで表します
異常終了時のリランや終了コードの決め方は、関連記事「バッチ設計書の書き方と項目一覧｜リランと異常終了時の設計サンプル」で扱っています

パターン 5：画面遷移を伴う申込処理（入力 → 確認 → 完了・二重送信防止）

Web の申込フォームで、入力画面 → 確認画面 → 完了画面と進む処理です。入力エラーの戻り、セッションへの保存、二重送信の防止を描きます。

sequenceDiagram
    actor U as 申込者
    participant B as ブラウザ
    participant W as 申込Web
    participant D as 申込DB
    U->>B: 入力画面で項目を入力し「確認へ」
    B->>+W: POST /apply/confirm（入力値）
    W->>W: 入力チェック
    alt エラーあり
        W-->>B: 入力画面を再表示（エラー文言）
    else エラーなし
        W->>W: 入力値をセッションに保存、二重送信防止トークンを発行
        W-->>B: 確認画面（トークン付き）
    end
    deactivate W
    B-->>U: 画面を表示
    U->>B: 確認画面で「申し込む」
    B->>+W: POST /apply/complete（トークン）
    alt トークンが有効
        W->>D: 申込を登録
        D-->>W: 申込番号
        W->>W: セッションの入力値とトークンを破棄
        W-->>B: 完了画面（申込番号）
    else トークンが無効（二重送信・「戻る」からの再送信）
        W-->>B: 完了済みの案内
    end
    deactivate W
    B-->>U: 完了画面を表示

sequenceDiagram
    actor U as 申込者
    participant B as ブラウザ
    participant W as 申込Web
    participant D as 申込DB
    U->>B: 入力画面で項目を入力し「確認へ」
    B->>+W: POST /apply/confirm（入力値）
    W->>W: 入力チェック
    alt エラーあり
        W-->>B: 入力画面を再表示（エラー文言）
    else エラーなし
        W->>W: 入力値をセッションに保存、二重送信防止トークンを発行
        W-->>B: 確認画面（トークン付き）
    end
    deactivate W
    B-->>U: 画面を表示
    U->>B: 確認画面で「申し込む」
    B->>+W: POST /apply/complete（トークン）
    alt トークンが有効
        W->>D: 申込を登録
        D-->>W: 申込番号
        W->>W: セッションの入力値とトークンを破棄
        W-->>B: 完了画面（申込番号）
    else トークンが無効（二重送信・「戻る」からの再送信）
        W-->>B: 完了済みの案内
    end
    deactivate W
    B-->>U: 完了画面を表示

ポイント

画面遷移そのもの（どの画面からどの画面へ行けるか）は画面遷移図で描き、シーケンス図では「1 回の申込で、サーバーと DB に何が起きるか」を描きます。分担は関連記事「画面遷移図の書き方と例｜Mermaidで作る手順と画面一覧テンプレート」で扱っています
「入力エラーのときは入力画面に戻る」ので、エラー後の流れは描かず、正常系を主線にしています。1 枚に戻りの流れまで入れると、矢印が交差して読めなくなります
トークンの破棄を矢印にしておくと、「完了画面で再読み込みしたらどうなるか」がレビューで確かめられます

パターン 6：決済（外部決済代行・冪等キー・Webhook）

外部の決済代行サービスを呼ぶ場面です。タイムアウトで「決済が通ったか分からない」状態と、後から届く Webhook を描きます。

sequenceDiagram
    autonumber
    actor U as 購入者
    participant W as ECサイト
    participant P as 決済代行（外部）
    participant D as 注文DB
    U->>W: 「支払う」
    W->>D: 注文を「決済中」で保存（冪等キー＝注文番号）
    W->>P: POST /payments（金額・冪等キー）タイムアウト 10 秒
    alt 10 秒以内に応答
        P-->>W: 決済ID・状態＝成功
        W->>D: 注文を「決済済み」に更新
        W-->>U: 完了画面
    else タイムアウト（結果が不明）
        Note over W,P: 決済が通ったかは分からない。<br/>同じ冪等キーで問い合わせる
        W->>P: GET /payments?key=注文番号
        P-->>W: 状態（成功／失敗／該当なし）
        W->>D: 状態に合わせて更新
        W-->>U: 結果画面（不明なら「確認中」）
    end
    P-)W: Webhook：決済確定（非同期）
    W->>D: 注文を「決済確定」に更新（受信済みなら無視）
    W-->>P: 200 OK

sequenceDiagram
    autonumber
    actor U as 購入者
    participant W as ECサイト
    participant P as 決済代行（外部）
    participant D as 注文DB
    U->>W: 「支払う」
    W->>D: 注文を「決済中」で保存（冪等キー＝注文番号）
    W->>P: POST /payments（金額・冪等キー）タイムアウト 10 秒
    alt 10 秒以内に応答
        P-->>W: 決済ID・状態＝成功
        W->>D: 注文を「決済済み」に更新
        W-->>U: 完了画面
    else タイムアウト（結果が不明）
        Note over W,P: 決済が通ったかは分からない。<br/>同じ冪等キーで問い合わせる
        W->>P: GET /payments?key=注文番号
        P-->>W: 状態（成功／失敗／該当なし）
        W->>D: 状態に合わせて更新
        W-->>U: 結果画面（不明なら「確認中」）
    end
    P-)W: Webhook：決済確定（非同期）
    W->>D: 注文を「決済確定」に更新（受信済みなら無視）
    W-->>P: 200 OK

ポイント

決済の「タイムアウト」は、在庫照会のタイムアウトと違い、再送ではなく状態の確認をします。再送して二重課金になる事故を、冪等キーと状態確認の矢印で防いでいることが図から読めます
Webhook は外部から来る非同期のメッセージなので、矢印の向きが「外部 → 自社」になります。同じ Webhook が 2 回届いても壊れないことを「受信済みなら無視」として書きます
Webhook の署名検証や再送の扱いは、関連記事「Webhookとは？実装までわかる｜署名検証・リトライ・冪等性を実行ログで解説」で扱っています

どこまで描くか：粒度と省略の判断表

シーケンス図は、目的によって「ちょうどよい細かさ」が変わります。 同じ処理でも、基本設計書と詳細設計書では別の図になります。

観点	基本設計（関係者と合意）	詳細設計（実装者向け）	障害調査・コード読み
ライフラインの単位	利用者・画面・サービス・外部・DB	クラス・モジュール	実際のプロセス・スレッド
メッセージ名	業務の言葉、API のパス	メソッド名と主な引数	ログに出た名前と時刻
異常系	利用者に見える結果（エラー画面、503）	例外の種類、再試行、ロールバック	実際に起きた分岐だけ
描かないもの	クラス名、内部の処理	getter、ログ出力、値の整形	起きなかった分岐
1 枚の目安	ライフライン 4〜6、矢印 15 前後	1 ユースケースの 1 シナリオ	1 件の障害の 1 リクエスト

省略の仕方

省きたいもの	省略の仕方
応答の矢印	「応答は省略」とノートに書き、エラーの応答だけは残す
getter・値の整形・ログ出力	描かない。必要なら「入力チェック」のような自己呼び出し 1 本にまとめる
共通の処理（ログイン、認証）	別図に切り出し、PlantUML は `ref`、Mermaid はノートで参照する
正常系と異常系が多い	正常系 1 枚＋異常系 1 枚に分ける（1 枚 1 シナリオ）
同じ相手への連続した呼び出し	loop か 1 本にまとめ、ノートに件数・条件を書く
登場人物が 7 つ以上	役割の近いものを 1 つにまとめる（例：ログ基盤＋監視 → 運用基盤）

1 枚に収める目安

ライフラインは 4〜6、矢印は 15〜20 本までを目安にします。これを超えたら、シナリオを分けるか、共通部分を別図にします
枠の入れ子は 2 段まで（loop の中の alt まで）。3 段になったら、内側を別図にします
迷ったら「この矢印を消すと、読み手の判断が変わるか」で決めます。変わらないなら消します

設計書への載せ方（基本設計・詳細設計・Markdown・画像化）

どの設計書に、何を描くか

設計書	載せるシーケンス図	ライフライン
基本設計書（外部設計）	業務の流れ、外部連携、画面遷移を伴う処理、バッチの流れ	利用者・画面・サービス・外部システム・DB
詳細設計書（内部設計）	クラス間のやり取り、例外・再試行・トランザクションの境界	クラス・モジュール
API 設計書・IF 設計書	1 つの API の呼び出しと応答、タイムアウト・再試行の約束	呼ぶ側・API・外部

基本設計書では「主要な業務の流れ」ごとに 1 枚、詳細設計書では「複雑な処理（分岐・非同期・トランザクション）」に絞って描くと、枚数が増えすぎません。項目の全体は、関連記事「基本設計書の書き方｜項目・記入例とレビューの観点」と「詳細設計書の書き方｜基本設計との違いと記入例」で扱っています。

Markdown の設計書で描画できる場所

Mermaid のコードを ```mermaid のコードブロックに書くと、次の場所ではそのまま図として表示されます。

置き場所	Mermaid	PlantUML
GitHub（Issue・PR・Wiki・Markdown ファイル）	描画される	描画されない（画像を貼る）
GitLab	描画される	```plantuml で描画。Self-Managed は管理者が有効化
VS Code	1.121（2026年5月）から標準の Markdown プレビューで描画	拡張機能で描画
Notion	コードブロックの言語に Mermaid を選ぶと描画（コード・プレビュー・分割の表示）	画像を貼る
Confluence	Marketplace のアプリ（Mermaid Macros for Confluence など）で描画	Marketplace のアプリで描画
Obsidian	描画される	プラグインで描画

GitHub のドキュメントでは、図の描画は Issue・Discussions・プルリクエスト・Wiki・Markdown ファイルで使えると書かれています。Mermaid の全図種のコードは、関連記事「Mermaid記法一覧｜全図種のコピペ用コードと描画結果まとめ」で扱っています。

画像化する（Word・Excelに貼る）

Word や Excel の設計書には、PNG か SVG にして貼ります。 コードも設計書の近く（リポジトリや付録）に残しておくと、次の修正で描き直せます。

Mermaid は @mermaid-js/mermaid-cli（コマンド名 mmdc）で画像にします。

npm install -g @mermaid-js/mermaid-cli
mmdc -i login.mmd -o login.svg              # SVG
mmdc -i login.mmd -o login.png -b white -s 2 # PNG（背景白・2 倍の大きさ）
mmdc -i design.md -o design.out.md          # Markdown 内の mermaid ブロックを SVG に置き換え

パターン 1 のログインの図（login.mmd）を mmdc 12.0.0 で変換した結果です。

出力	結果
`login.svg`	202,750 バイト
`login.png`（`-s 2`）	1568×1426 ピクセル、164,817 バイト
Markdown モード	`design.out-1.svg` などが作られ、本文の mermaid ブロックが `![diagram](./design.out-1.svg)` に置き換わる

PlantUML は plantuml.jar を Java で動かします。シーケンス図の描画に Graphviz は要りません（PlantUML のドキュメントでは、Graphviz が要るのはクラス図・ユースケース図・状態図などで、それ以外の図では使わないと説明されています）。

java -jar plantuml.jar -charset UTF-8 -checkonly login.puml   # 構文だけ確かめる（画像は作らない）
java -jar plantuml.jar -charset UTF-8 login.puml              # PNG（既定）
java -jar plantuml.jar -charset UTF-8 -tsvg -o out login.puml # SVG を out/ に出力

同じログインの図を PlantUML 1.2026.8（OpenJDK 21）で変換した結果は、PNG が 789×694 ピクセル・26,742 バイト、SVG が 12,830 バイト、所要時間は約 0.8 秒でした。-charset UTF-8 は、実行環境の既定の文字コードに関係なくファイルを UTF-8 として読む指定です。OpenJDK 21 では付けなくても日本語が描画されましたが、Windows など既定の文字コードが UTF-8 でない環境でも同じ結果になるよう、付けておきます。

ツール比較表（Mermaid・PlantUML・draw.io・Lucidchart・Cacoo・Figma）

「コードで書いて Git で差分管理する」か「GUI で描いて共同編集する」かで、向くツールが分かれます。 料金と機能は各社の公式ページで確かめた内容です（確認日 2026年10月16日）。

ツール	料金	作り方	共同編集・置き場所	向く場面
Mermaid	無料（MIT ライセンスのオープンソース）	コード	Git で差分管理。GitHub・GitLab・Notion・VS Code で描画	Markdown の設計書・README・PR
PlantUML	無料（GPL のオープンソース）。Java が必要	コード	Git で差分管理。GitLab・VS Code 拡張・サーバーで描画	`ref`・`database` など UML の記法を細かく使う設計書
draw.io（diagrams.net）	無料（ソースは Apache 2.0）	GUI。Mermaid を取り込んで図形か SVG に変換できる	Google Drive・OneDrive・Confluence／Jira 連携	配置を手で整えたい図、既存の draw.io 資産
Lucidchart	無料プランは編集可能 3 文書・1 文書 60 図形。Individual $9.00/月〜	GUI。UML markup（テキストから生成）は有料プラン	リアルタイム共同編集	非エンジニアと一緒に編集する図
Cacoo	フリープランあり。スペースプラン ¥18,000/月（税別・ユーザー数無制限）	GUI	リアルタイム共同編集・コメント	日本語 UI でチーム全員が使う
Figma（FigJam）	個人は無料。有料は席（Full・Dev・Collab）ごとの料金	GUI（ホワイトボード）	リアルタイム共同編集	デザイン・企画の資料と同じ場所に置く

draw.io の PlantUML 取り込みは部分的な実装で、公式ブログでは段階的に終える方針が公表されています。コードから描くなら Mermaid が本線です
Lucidchart の無料プランの上限（3 文書・60 図形）は公式ページの記載で、線やテキストも図形として数えられます
FigJam の AI 生成はフローチャート・ガントチャート・組織図が対象と案内されており、シーケンス図は挙げられていません

よくある間違いと直し方（矢印の向き・応答・活性化バー・alt の条件・Parse error）

描き方の間違い

間違い	何が起きるか	直し方
応答を呼ぶ側の向きで描く（`W->>A: 200 OK`）	2 回呼び出したように読める	応答は呼ばれた側から破線で `A-->>W: 200 OK`
応答をすべて省く	何が返るか、エラーがどう返るかが分からない	省くなら「応答は省略」とノートに書き、エラーの応答だけ残す
活性化バーを始めるだけで閉じない	いつまで待っているのかが読めない	`+`／`-` を対で付けるか、`deactivate` で閉じる
alt の枝ごとに `-` で閉じる	2 つ目の枝で「inactive participant」のエラー	枝の中では閉じず、`end` の後に `deactivate`
alt の条件が重なる（「失敗」と「タイムアウト」）	どの枝が起きるか決まらない	枝が重ならない条件に分ける
同期と非同期を区別しない	待つ処理か分からず、タイムアウトの設計が抜ける	待つなら `->>`、待たないなら `-)`。迷ったら凡例を付ける
ラベルが「処理」「データ」	設計書の他の章と対応しない	「POST /login」「会員レコード」など具体的に
1 枚に正常系・異常系・管理者操作を全部入れる	矢印が交差して読めない	1 枚 1 シナリオ。共通部分は別図に
呼ぶ側が右、呼ばれる側が左	矢印が右から左へ流れて読みにくい	左から右へ流れるように並べ替える

次は、内部の処理を全部描いて分岐が見えなくなった例と、その直し方です。

sequenceDiagram
    participant C as LoginController
    participant S as AuthService
    participant R as MemberRepository
    participant H as PasswordHasher
    C->>S: login(id, pw)
    S->>S: validate(id)
    S->>S: trim(id)
    S->>R: findById(id)
    R->>R: buildQuery()
    R-->>S: member
    S->>S: getHash()
    S->>H: matches(pw, hash)
    H-->>S: true
    S-->>C: token

sequenceDiagram
    participant C as LoginController
    participant S as AuthService
    participant R as MemberRepository
    participant H as PasswordHasher
    C->>S: login(id, pw)
    S->>S: validate(id)
    S->>S: trim(id)
    S->>R: findById(id)
    R->>R: buildQuery()
    R-->>S: member
    S->>S: getHash()
    S->>H: matches(pw, hash)
    H-->>S: true
    S-->>C: token

問題	理由
自己呼び出しが多い（validate、trim、getHash、buildQuery）	読み手の判断に影響しない処理で、図が長くなる
正常系しかない	会員がいない、パスワード不一致のときの動きが分からない
活性化バーがない	どこで処理が止まって待っているのか読み取れない

クラスの境界をまたぐメッセージだけを残し、異常系を alt で足した直し方です。

sequenceDiagram
    participant C as LoginController
    participant S as AuthService
    participant R as MemberRepository
    participant H as PasswordHasher
    C->>+S: login(id, pw)
    S->>+R: findById(id)
    R-->>-S: member（なければ空）
    S->>+H: matches(pw, hash)
    H-->>-S: 一致 / 不一致
    alt 会員あり かつ 一致
        S-->>C: token
    else それ以外
        S-->>C: 認証エラー（どちらが違うかは返さない）
    end
    deactivate S

sequenceDiagram
    participant C as LoginController
    participant S as AuthService
    participant R as MemberRepository
    participant H as PasswordHasher
    C->>+S: login(id, pw)
    S->>+R: findById(id)
    R-->>-S: member（なければ空）
    S->>+H: matches(pw, hash)
    H-->>-S: 一致 / 不一致
    alt 会員あり かつ 一致
        S-->>C: token
    else それ以外
        S-->>C: 認証エラー（どちらが違うかは返さない）
    end
    deactivate S

Mermaid の `Parse error` の実例と直し方

Mermaid の構文エラーは、図の代わりに爆弾のアイコンと「Syntax error in text」「mermaid version 11.17.2」が表示され、ブラウザのコンソールに Parse error on line N: から始まるメッセージが出ます。 Mermaid 11.17.2 で、よく起きる書き間違いを実際に描画して得たメッセージです。Expecting の後に「来るはずだったもの」、got の後に「実際に来たもの」が出ます。

書き間違い	エラー文（要点）	直し方
全角コロン `W->>A： POST /login`	`Expecting 'TXT', got 'NEWLINE'`	半角の `:` にする
コロンがない `W->>A POST /login`	`Expecting 'TXT', got 'NEWLINE'`	矢印の後に `:` を入れる
`alt` の `end` がない	`Expecting ... 'end', ... got '1'`	枠ごとに `end` を書く（`'1'` は入力の終わりを表す内部の記号）
`opt` に `else` を書いた	`Expecting ... 'end', ... got 'else'`	`opt` を `alt` に変える
文中のセミコロン `W->>A: 一覧; 件数`	`Expecting ... 'SOLID_ARROW' ... got 'NEWLINE'`	`;` は行の区切りなので `#59;` と書く
キーワードの打ち間違い `alte 成功`	`Expecting ... 'SOLID_ARROW' ... got 'NEWLINE'`	`alte` が登場人物名と解釈されている。`alt` に直す
alt の枝ごとに `-` で閉じた	`Trying to inactivate an inactive participant (A)`	枝の中で閉じず、`end` の後に `deactivate A`
`create participant J` の直後の矢印の受け手が J でない	`The created participant undefined does not have an associated creating message after its declaration.`	`create` の次の行を `A->>J: 生成` のように J 宛てにする

全角コロンのときの実際のメッセージです。^ の位置がエラーの場所を示します。

Parse error on line 4:
...  W->>A： POST /login
-----------------------^
Expecting 'TXT', got 'NEWLINE'

end を書き忘れたときのメッセージです。「end を含む候補を待ったまま、入力が終わった」という意味です。

Parse error on line 10:
...       A-->>W: 401
---------------------^
Expecting 'SPACE', 'NEWLINE', 'INVALID', 'create', 'box', 'end', 'autonumber',
'activate', 'deactivate', 'title', ... 'loop', 'rect', 'opt', 'alt', 'par',
'critical', 'break', 'else', 'participant', ... got '1'

エラーにはならないものの、表示が意図と変わる書き方もあります。

書き方	起きること	直し方
`W->>A: 注文 #123 を確認`	`#` 以降が消えて「注文」とだけ表示される	`#35;` と書く（`注文 #35;123 を確認`）
`alt [一致]`	`[[一致]]` と二重の括弧になる	括弧を書かない
登場人物の名前に空白（`participant 認証 API`）	描画はされるが、矢印で毎回 `認証 API->>…` と書く必要がある	`participant A as 認証 API` と別名を付ける
2 行に分けたい文	1 行に長く表示される	`<br/>` で改行する
行頭の `%%`	その行はコメントとして無視される	意図どおり。コードの説明に使う

PlantUML では、構文エラーは画像の中に「Syntax Error?」と表示されます。コマンドラインで -syntax を付けて標準入力から渡すと、ERROR と行番号、Syntax Error? (Assumed diagram type: sequence) が出ます（全角コロンの例で、PlantUML 1.2026.8 の出力です）。-checkonly は、エラーがあるときだけ Some diagram description contains errors と表示して終了コード 200 を返しました。なお PlantUML は alt の end が無くても構文エラーにならず、枠が図の最後まで伸びます。

生成 AI が出したコードのエラーを直す手順は、関連記事「生成AIでMermaid図を作るプロンプト集｜図の種類別とエラーの直し方」で扱っています。

Mermaid と PlantUML の構文対応表

Mermaid のコードを PlantUML に（またはその逆に）書き換えるときの対応表です。 矢印の ->> の意味が逆であること、participant の別名の順番が逆であることに気をつけます。

要素	Mermaid	PlantUML	補足
図の宣言	`sequenceDiagram`	`@startuml` 〜 `@enduml`	GitLab の ```plantuml では `@startuml` が省ける
登場人物	`participant A as 表示名`	`participant 表示名 as A`	別名と表示名の順が逆
アクター	`actor U as 利用者`	`actor 利用者 as U`
DB・キューの記号	`participant D@{ "type": "database" }`	`database 会員DB as D`、`queue` など	Mermaid は 11 系の新しい構文
同期メッセージ	`A->>B: 処理`	`A -> B : 処理`
非同期メッセージ	`A-)B: 処理`	`A ->> B : 処理`	`->>` の意味が逆
応答	`B-->>A: 結果`	`B --> A : 結果`
消滅の矢印	`A-xB: 削除`	`A -> B !! : 削除`
活性化の開始	`A->>+B: 処理` ／ `activate B`	`A -> B ++ : 処理` ／ `activate B`
活性化の終了	`B-->>-A: 結果` ／ `deactivate B`	`B --> A -- : 結果` ／ `deactivate B`	PlantUML には `return 結果` もある
生成	`create participant C`	`create C` ／ `A -> C ** : 生成`
消滅	`destroy C`	`destroy C` ／ `!!`
ノート	`Note over A,B: 説明`	`note over A, B : 説明`	右・左は `right of`／`left of`
条件分岐	`alt` 〜 `else` 〜 `end`	同じ
任意	`opt` 〜 `end`	同じ
繰り返し	`loop` 〜 `end`	同じ
並行	`par` 〜 `and` 〜 `end`	`par` 〜 `else` 〜 `end`	枝の区切りが違う
打ち切り	`break` 〜 `end`	同じ
割り込み禁止	`critical` 〜 `option` 〜 `end`	`critical` 〜 `end`	`option` は Mermaid 独自
別図の参照	なし（ノートで代用）	`ref over A, B : 図名`
通し番号	`autonumber`	`autonumber`	PlantUML は `autonumber 10 10` で開始と増分
グループの囲み	`box 名前` 〜 `end`	`box "名前"` 〜 `end box`
背景色の範囲	`rect rgb(235,235,235)` 〜 `end`	なし（`skinparam` で色）
区切り線	なし	`== 初期化 ==`
時間の経過	なし（ノートで代用）	`... 10 秒後 ...`
コメント	`%% コメント`	`' コメント`
改行	`<br/>`	`\n`
記号の文字	`#35;`（#）、`#59;`（;）	そのまま書ける

生成 AI にシーケンス図を描かせるプロンプト例

生成 AI は Mermaid・PlantUML のコードを書くのが得意です。登場人物・シナリオ・異常系・粒度・矢印の規則を指定すると、手直しの少ない図になります。出力は必ず描画して確かめます。

新しく描かせる

次の処理のシーケンス図を Mermaid の sequenceDiagram で書くこと。

# 対象
- 会員制の予約サイトの「予約確定」API（POST /reservations）

# 登場人物（左から順に）
- 会員(actor)、予約画面、予約API、予約DB、メール送信

# 描くこと
- 正常系：空き確認 → 予約登録 → 確認メールの依頼（メールは非同期）
- 異常系：満席なら 409、DB エラーなら 503（alt で分ける。枝の条件は重ねない）
- 同期は ->>、非同期は -)、応答は -->> を使う
- 活性化バーは + / - で付け、alt の中では閉じない（end の後に deactivate）
- autonumber を付ける

# 粒度
- 基本設計用。クラス名やメソッド名は出さない
- ライフラインは 5 つ、矢印は 15 本まで

# 最後に
- 図からは読み取れない前提（タイムアウト値、再試行の回数）を箇条書きで挙げること

既存のコードから起こさせる

次のコードから、1 リクエストの流れをシーケンス図（Mermaid）に起こすこと。

# 条件
- 入口は ReservationController.create() 。この 1 リクエストだけを追う
- クラス・サービス・DB・外部 API の境界をまたぐ呼び出しだけを矢印にする
- getter、値の整形、ログ出力は描かない
- 例外で処理が終わる分岐、返すステータスが変わる分岐だけを alt にする
- 非同期の境界（キューへの登録、イベント発行）は -) で描く
- 読み取れなかった点（タイムアウト値、トランザクションの境界）は、推測せずに「不明」として最後に列挙すること

# コード
（ここに貼る）

エラーを直させる

次の Mermaid のコードが「Parse error on line 6: Expecting 'TXT', got 'NEWLINE'」になる。
原因の行と直したコード全体を示すこと。意味は変えないこと。

（ここにコードとエラー文を貼る）

AI の出力は、表示に使う環境（GitHub、Notion、mmdc など）で実際に描画して確かめます。Mermaid は版によって使える構文（create participant、participant D@{...} など）が違います。そのうえで、ガード条件に数字が入っているか、同期と非同期の矢印が使い分けられているかを人が見直します。プロンプトの型は、関連記事「生成AIでMermaid図を作るプロンプト集｜図の種類別とエラーの直し方」で扱っています。

よくある質問

Q. シーケンス図の書き方は？ A. 「登場人物を決めて左から並べる → 正常系の矢印を上から順に描く → 分岐・繰り返しを alt・loop で囲む → エラー・タイムアウトを足す → 粒度を決めて削る」の 5 ステップです。「シーケンス図の書き方の手順（5 ステップ）」の節に、予約確定を例にした途中経過の図があります。

Q. シーケンス図とは何ですか？ A. 登場人物（利用者・画面・API・DB など）のあいだで交わされるメッセージを、時間の順に上から下へ描く UML の図です。「誰が誰に、どの順番で何を送るか」を表します。処理の手順はアクティビティ図、状態の変化は状態遷移図で描きます。

Q. シーケンス図の alt とは？ A. 条件分岐（if／else）を表す枠です。alt 条件 で始め、else 条件 で枝を足し、end で閉じます。どれか 1 つの枝だけが起こります。else 側で何もしないなら、alt ではなく opt を使います。

Q. UML の alt と opt の違いは？ A. alt は「どれか 1 つの枝が必ず起こる分岐」、opt は「条件を満たすときだけ起こり、満たさなければ何もしない」です。else 側に処理があるかどうかで選びます。

Q. シーケンス図のループ（loop）はどう書きますか？ A. loop 条件 〜 end で囲みます。ラベルには「対象の注文 1 件ごと」「最大 3 回（間隔 1 秒・2 秒）」のように、件数・回数・終了条件を数字で書きます。途中で繰り返しをやめる条件は、loop の中に break を置きます。

Q. シーケンス図の矢印の種類は？ A. 同期（実線＋塗りつぶし矢じり：応答を待つ）、非同期（実線＋開いた矢じり：待たない）、応答（破線）、生成（破線が相手の箱に届く）、消滅（×）の 5 種類が基本です。Mermaid では ->>・-)・-->>・create・destroy、PlantUML では ->・->>・-->・create・!! です。

Q. 応答（戻り）の矢印は必ず描く必要がありますか？ A. UML では省略できます。設計書では、何が返るか（ステータス、データ）がレビューの対象になるので描くことが多いです。省略するときは「応答は省略」とノートに書き、エラーの応答だけは残します。

Q. 1 枚のシーケンス図にどこまで入れますか？ A. 目安は 1 シナリオ、ライフライン 4〜6、矢印 15〜20 本、枠の入れ子は 2 段までです。超えるときは、共通部分を別図に切り出し、PlantUML は ref、Mermaid はノートで参照します。

Q. Mermaid と PlantUML のどちらを使いますか？ A. GitHub・Notion・VS Code で Markdown のまま表示したいなら Mermaid、ref や database の記号など UML の表現を細かく使いたいなら PlantUML です。チームの設計書の置き場所で描画できるほうを選びます。

まとめ

シーケンス図は、登場人物のあいだのメッセージを時間順に描く UML の図。1 枚 1 シナリオ
矢印は同期（待つ）・非同期（待たない）・応答（破線）を使い分け、活性化バーで処理中の期間を示す
複合フラグメントは alt・opt・loop・par・break・critical・ref の 7 種類でほぼ書ける。alt の条件は重ねず、数字で書く
書く順番は登場人物 → 正常系 → 分岐・繰り返し → 例外 → 粒度
タイムアウトは戻り矢印ではなくノートで、決済のタイムアウトは再送ではなく状態確認で描く
Mermaid と PlantUML は ->> の意味が逆。構文対応表で書き換える
Parse error は Expecting（来るはずのもの）と got（実際に来たもの）を読む。全角コロン・end 忘れ・opt の else が定番
AI に描かせたら、使う環境で描画して確かめ、条件と矢印の種類を人が見直す

参考・出典

確認日はいずれも 2026年10月16日です。

OMG「Unified Modeling Language (UML) Version 2.5.1」（17 Interactions）：https://www.omg.org/spec/UML/2.5.1/PDF
uml-diagrams.org「Combined Fragment」（相互作用演算子の一覧）：https://www.uml-diagrams.org/sequence-diagrams-combined-fragment.html
Mermaid「Sequence diagrams」：https://mermaid.js.org/syntax/sequenceDiagram.html
mermaid（GitHub、MIT ライセンス）：https://github.com/mermaid-js/mermaid
mermaid-cli（GitHub）：https://github.com/mermaid-js/mermaid-cli
PlantUML「シーケンス図の構文と機能」：https://plantuml.com/ja/sequence-diagram
PlantUML「コマンドライン」：https://plantuml.com/ja/command-line
PlantUML「GraphViz」（Graphviz が要る図の一覧）：https://plantuml.com/ja/graphviz-dot
PlantUML「ライセンス」：https://plantuml.com/ja/license
PlantUML リリース（GitHub）：https://github.com/plantuml/plantuml/releases
GitHub Docs「Creating diagrams」：https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/creating-diagrams
GitLab Docs「GitLab Flavored Markdown」（Mermaid・PlantUML）：https://docs.gitlab.com/user/markdown/
VS Code「May 2026 (version 1.121)」（Mermaid diagrams in Markdown preview）：https://code.visualstudio.com/updates/v1_121
Obsidian Help「Advanced formatting syntax」：https://obsidian.md/help/Editing+and+formatting/Advanced+formatting+syntax
クラスメソッド「Mermaid が Notion で利用出来るようになりました」：https://dev.classmethod.jp/articles/mermaid-markdown-is-supported-in-notion
Atlassian Marketplace「Mermaid Macros for Confluence」：https://marketplace.atlassian.com/apps/1928341778/mermaid-macros-for-confluence
draw.io「Insert a Mermaid diagram」：https://www.drawio.com/docs/manual/insert/insert-mermaid/
draw.io「Insert a PlantUML diagram」：https://www.drawio.com/docs/manual/insert/insert_plantuml/
draw.io Blog「Migrate diagrams from PlantUML to Mermaid and draw.io」：https://www.drawio.com/blog/plantuml-to-mermaid
drawio（GitHub、Apache License 2.0）：https://github.com/jgraph/drawio
Lucidchart「Unlimited diagramming for pennies a day」（無料プランの上限）：https://lucid.co/lucidchart/trial
Lucid Help「Create a sequence diagram with UML markup in Lucidchart」：https://help.lucid.co/hc/en-us/articles/16262874090900
Cacoo「料金プラン」：https://cacoo.com/ja/pricing
Figma「Pricing」：https://www.figma.com/pricing/
Figma Help「Generate boards and diagrams with FigJam AI」：https://help.figma.com/hc/en-us/articles/18706554628119

本記事の内容は、ご自由にお使いください。
ご利用の際は、出典として本ページへのリンクを記載いただけますようお願いします。

（記載例）出典：株式会社RJC「シーケンス図の書き方｜記号・矢印・alt/loop一覧と実務6パターン」

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。

WE ARE HIRING

RJCで一緒に開発しながら、
成長を楽しみませんか？

RJCは、Web・モバイル・AIを活用した開発プロジェクトで、テックリードやPM・PMOも活躍するシステム開発会社です。会社を知る、待遇を確かめる、話を聞いてみる。気になるところ見てみてください！

127日年間休日
12時間平均残業時間
毎日ガチャ遊びココロも大切にする福利厚生。アマギフなどの賞品ラインナップ！

ほかにも、チケットレストラン、書籍読み放題、2年ごとの慰労報奨（休暇 or 金一封）、11期連続の黒字決算。

ABOUT RJC RJCがどんな会社か知る考え方、研修、働き方、福利厚生、社員の前職まで。RJCのことが丸わかり！ RJC丸わかりページへ JOB DESCRIPTION 仕事内容・待遇を見てみる仕事内容、給与・待遇、選考の流れ。経験者も未経験も！応募前に知りたいこと、まとめました！募集要項を見る ENTRY エントリーするエントリーは1〜2分・履歴書不要です。まずは話を聞いてみたい、という方でも歓迎です！エントリーフォームへ

VRAMとは｜確認方法・必要量の目安とLLMの計算式をPythonで解説

2026.10.23

技術 💻

RJC Techチーム

microCMSとは｜使い方・料金・APIとNext.js連携を実例で解説

2026.10.23

技術 💻

RJC Techチーム

Godot Engineとは｜始め方・GDScript・2Dゲームの作り方を解説

2026.10.23

技術 💻

RJC Techチーム

ニュース・ブログ⼀覧ページへ

シーケンス図の書き方｜記号・矢印・alt/loop一覧と実務6パターン

シーケンス図とは：何を描いて、何を描かない図か

シーケンス図の読み方（4 つの約束）

シーケンス図の記号一覧（Mermaid・PlantUML の図つき）

ライフラインとアクター

活性化バー（実行仕様）

メッセージの矢印の種類（同期・非同期・応答・生成・消滅）

自己呼び出しとノート

複合フラグメント alt・opt・loop・par・break・critical・ref の書き方

alt（条件分岐）と条件の書き方

opt（条件を満たすときだけ）

loop（繰り返し）

par（並行）

break（打ち切り）

critical（割り込ませない区間）

ref（別の図の参照）

シーケンス図の書き方の手順（5 ステップ）

ステップ 1：登場人物を決め、左から並べる

ステップ 2：主な流れ（正常系）を上から順に描く

ステップ 3：分岐と繰り返しを枠で囲む

ステップ 4：例外（エラー・タイムアウト）を足す

ステップ 5：粒度を決めて削る

実務パターン 6 つ（完成コード＋図）

パターン 1：ログイン＋認証（alt・活性化バー・autonumber）

パターン 2：外部 API 呼び出しとタイムアウト・再試行（loop・break・ノート）

パターン 3：非同期処理（ジョブキュー）（非同期矢印・par・生成と消滅）

パターン 4：バッチ処理（loop・alt・実行記録）

パターン 5：画面遷移を伴う申込処理（入力 → 確認 → 完了・二重送信防止）

パターン 6：決済（外部決済代行・冪等キー・Webhook）

どこまで描くか：粒度と省略の判断表

省略の仕方

1 枚に収める目安

設計書への載せ方（基本設計・詳細設計・Markdown・画像化）

どの設計書に、何を描くか

Markdown の設計書で描画できる場所

画像化する（Word・Excelに貼る）

ツール比較表（Mermaid・PlantUML・draw.io・Lucidchart・Cacoo・Figma）

よくある間違いと直し方（矢印の向き・応答・活性化バー・alt の条件・Parse error）

描き方の間違い

Mermaid の Parse error の実例と直し方

Mermaid と PlantUML の構文対応表

生成 AI にシーケンス図を描かせるプロンプト例

新しく描かせる

既存のコードから起こさせる

エラーを直させる

よくある質問

まとめ

参考・出典

RJCで一緒に開発しながら、成長を楽しみませんか？

関連記事

VRAMとは｜確認方法・必要量の目安とLLMの計算式をPythonで解説

microCMSとは｜使い方・料金・APIとNext.js連携を実例で解説

Godot Engineとは｜始め方・GDScript・2Dゲームの作り方を解説

Mermaid の `Parse error` の実例と直し方

RJCで一緒に開発しながら、
成長を楽しみませんか？