シーケンス図の作り方

シーケンス図は、一つのやり取りに参加する役割と、役割の間で交わすメッセージの順序を示すUML図です。参加者を左右に置き、メッセージを上から下へ並べます。IBMの公式資料では、参加者をライフライン、やり取りをメッセージとして表すと説明しています。UMLの規範文書はObject Management Groupの公式ページで確認できます。

この記事では、AIを使って初めてシステムを設計する人が、一つのユースケースからシーケンス図を作り始める手順を説明します。読み終えると、参加者、開始条件、正常経路、代替・失敗経路、同期・非同期、戻り、図の境界を空欄の作図票へまとめられます。

入力として、一つのユースケースが必要です。利用者の目的、正常時と失敗時の期待結果が決まっていなければ、先に要件と受入条件を整理します。この記事ではUML全体、特定の作図ツール、コード、API仕様、状態遷移、データ構造、システム配置、脅威分析は扱いません。シーケンス図を作っても、実装の正しさ、性能、安全性、すべての経路が保証されるわけではありません。

最初に一つのユースケースへ絞る

ユースケースは、特定の利用者がシステムを使って一つの目的を達成する経路をまとめたものです。Ivar JacobsonとAlistair CockburnのUse-Case Foundationでは、成功する経路だけでなく、途中で問題が起きる経路や失敗する経路も含み、実装技術とは独立して記述できるとしています。

最初に、次の項目を一つずつ埋めます。

ユースケースの参照先
利用者が達成したい目的
対象にするシステム
開始前に成立している条件
やり取りを始める出来事
正常に終わったと判断できる状態
失敗で終わったと判断できる状態
今回は扱わない隣接する目的

一枚の図に複数の目的を入れません。「登録して通知し、請求し、集計する」のように目的が連なっている場合は、どこまでが今回のユースケースかを先に決めます。境界を決められなければ、作図を始めず要件の確認へ戻ります。

入力が足りないときは作図を始めない

Use-Case Foundationは、ユースケースを最初の出来事から、価値の実現または実現できなかった失敗までの一つの流れとして扱います。基本となる正常経路と、特別な場合、代替、任意の手順、エラーを含む拡張経路を分けます。

正常経路しか書かれていない、失敗時の終了が分からない、開始条件と開始の出来事が混ざっている場合は、足りない項目を未確認として残します。AIに自然そうな経路を補わせても、要件の根拠にはなりません。

境界と開始条件を決める

図の名前は「対象のユースケース名」にします。次に、どのシステムのやり取りを観察するのかを一文で書きます。シーケンス図の枠はインタラクションフレーム（Interaction frame）と呼ばれ、参加者とメッセージを置く文脈または境界を示します。IBMのシーケンス図解説も、図の要素を置いて振る舞いを観察する境界として説明しています。

対象の内外を一文で書く

境界欄には、次の形で空欄を用意します。

この図は「＿＿＿＿」という目的について、「＿＿＿＿」システムと、その外部にある「＿＿＿＿」の間のやり取りを、開始「＿＿＿＿」から終了「＿＿＿＿」まで扱う。

システムの内側にあるサービスや部品を最初から並べる必要はありません。入力資料に責任や通信の根拠がなければ、ひとまず対象システムを一つの参加者として置きます。内部の責任分割が必要になった時点で、コード設計の考え方など別の設計結果を参照します。

開始条件と開始の出来事を分ける

開始条件は、やり取りを始める前に成立していることです。開始の出来事は、最初のメッセージを発生させる操作や通知です。

作図票では、次を別の欄にします。

事前条件: 開始前に何が成立しているか
開始の出来事: 誰が何をしてやり取りが始まるか
最初のメッセージ: 誰から誰へ何を伝えるか

事前条件がメッセージとして書かれている、または最初の送信者が分からない場合は確定しません。

参加者を役割から選ぶ

Use-Case Foundationでは、アクターをシステムとのやり取りで演じる役割とし、人、組織、ソフトウェアなどを含めます。ユースケースを始める役割が主アクター、システムから利用される役割が支援アクターです。

主アクターと支援アクターを先に置く

参加者候補を次の順で取り出します。

最初の出来事を起こす主アクター
対象システム
対象システムから依頼や照会を受ける支援アクター
入力資料に責任とメッセージの根拠がある内部参加者

アクターは人名や製品名ではなく役割名にします。同じ人が複数の役割を持つ場合も、今回のユースケースで使う役割だけを書きます。

内部参加者は責任の根拠があるものだけにする

名詞が出てくるたびにライフラインを増やすと、データ、画面、処理、役割が混ざります。内部参加者を追加する前に、次の三点を確認します。

この参加者が受け取るメッセージは何か
この参加者が引き受ける責任は何か
その責任の根拠はどの資料にあるか

いずれかを答えられなければ「参加者候補・未確認」とします。ユースケースだけからクラス、サービス、データベース、APIを自動的に確定することはできません。

正常経路をメッセージへ変える

まず正常に目的へ到達する経路だけを扱います。Use-Case Foundationでは、基本シナリオを正常な価値到達経路とし、各手順にシステムまたはアクターの行為が含まれると説明しています。

一つの手順を送信元と受信先へ分ける

ユースケースの各手順を、次の問いで分解します。

誰が始めるか
誰が受け取るか
何を依頼、通知、照会するか
受信側が判断や処理に使う入力は何か
送信側は何を受け取れば次へ進めるか
その内容は入力資料のどこに書かれているか

「システムが処理する」だけでは送信元と受信先が分かりません。前後の手順から自然に見えても、資料にない参加者や通信を補いません。

メッセージは上から下へ並べる

シーケンス図では、参加者を左右に置き、メッセージを上から下へ順に置きます。作図前に、正常経路を次の表へ移します。

番号	送信元	受信先	メッセージ	入力	同期性	戻り・観測結果	根拠
1					未確認
2					未確認
3					未確認

メッセージ名は「登録」「確認」のような名詞だけで終えず、「登録を依頼する」「結果を返す」のように、受信側に求める行為が分かる形にします。ただし、実際の関数名やAPI名にはしません。

同期・非同期・戻りを確認する

同期か非同期かは、通信技術の名前ではなく、送信側が結果を待たなければ次の手順へ進めないかで判断します。IBMのUMLメッセージ解説では、同期呼び出しは応答まで送信側が待ち、非同期呼び出しは同じ形では送信側を停止させないと説明しています。

送信側が結果を待つか確認する

各メッセージについて、次を確認します。

結果が戻るまで送信側は次へ進めないか
送信後に別の作業を続けられるか
完了、失敗、期限切れを後からどう知るか
順序を守る必要があるか
再試行や重複が起きた場合を誰が扱うか

最初の問いが「はい」なら同期の候補です。送信後に続行し、完了を別の通知や確認で知るなら非同期の候補です。ただし、要件と設計資料で確認できなければ未確認のままにします。

戻る情報が必要なときだけ戻りを残す

戻りは、呼び出し先から呼び出し元へ返る結果です。戻りを描くと、後続の判断に必要な値や失敗が分かりやすくなる場合があります。

すべての戻りを描く必要はありません。次のどれかに当てはまる場合に残します。

戻った値で次の分岐が決まる
成功か失敗かを送信側が判断する
後続のメッセージへ渡す情報が返る
非同期処理の受付と完了を区別する必要がある

「成功」の一語だけでは、何が成功したか分かりません。戻る情報、観測できる結果、失敗理由のうち、後続に必要なものを書きます。

代替・失敗経路を重ねる

正常経路ができたら、代替・失敗経路を一つずつ追加します。Use-Case Foundationは、拡張経路について、基本経路のどこから分かれ、どこへ戻るかを記録できるとしています。失敗で終了する場合は、戻り先ではなく終了条件を書きます。

分岐条件を先に書く

シーケンス図のalt（分岐を表す枠）は、条件によって異なるメッセージ列を表します。IBMのCombined fragment解説では、alt内の各領域にガード条件（Guard condition）を置き、条件が真の領域を実行すると説明しています。

図へaltを描く前に、次の表を埋めます。

経路ID	分岐元の正常手順	分岐条件	実行するメッセージ列	合流先または終了	根拠・未確認
A1
F1				失敗終了:

分岐条件は「エラー時」ではなく、どの結果や状態を観測したときかを書きます。条件が重なる、どの条件にも当てはまらない、判断する参加者が分からない場合は作図を止めます。

合流か終了かを決める

代替・失敗経路の末尾は、次のどれかにします。

正常経路の特定の手順へ戻る
代替の成功条件で終わる
失敗条件で終わる
別のユースケースまたはやり取りへ引き渡す

合流先を「元へ戻る」とだけ書かず、正常経路の手順番号を指定します。一枚で追えない数の分岐がある場合は、主要な経路だけを残し、別の図へ分けます。

一枚に入れる境界を見直す

参加者と分岐を追加した後で、一枚の図から今回の目的を追えるかを確認します。参加者が多い、別の目的が混ざる、独立した長い処理がある場合は分けます。

別のやり取りをrefへ分ける

インタラクション利用（Interaction use）を使うと、別のやり取りをref（参照）の枠で示せます。IBMのInteraction use解説では、複雑なやり取りの順序を小さなやり取りの組合せとして表せると説明しています。

refへ分けるときは、参照先の名前だけでなく次を作図票に残します。

分ける理由
参照先へ渡す入力
参照先から戻る情報
参照先が失敗したときの扱い
参照先を確認する担当者

refへ分けても、元のユースケースがどこで正常終了または失敗終了するかを追えるようにします。

正確な時間は別の要件へ渡す

メッセージを上から下へ並べることは、順序を示します。上下の間隔から秒数や処理時間を読み取りません。IBMのタイミング図解説は、シーケンス図とタイミング図（Timing diagram）を異なる見方として分け、時間、所要時間、時間制約はタイミング図が中心にすると説明しています。

期限、待ち時間、タイムアウト、性能目標が必要なら、値と測定条件を非機能要件へ渡します。この記事の作図票では推測した秒数を入れません。

空欄の作図票を埋める

次の作図票を複製し、入力資料の参照先を付けて埋めます。空欄は推測で埋めず、未確認事項へ移します。

# シーケンス図作図票

## 1. 対象

- ユースケース名:
- ユースケースの参照先:
- 利用者の目的:
- 対象システム:
- 図に含める範囲:
- 図に含めない範囲:
- 事前条件:
- 開始の出来事:
- 正常終了の条件:
- 失敗終了の条件:

## 2. 参加者

| 役割名 | 主・支援・内部 | 対象の内外 | 責任 | 根拠 | 採用・未確認 |
|---|---|---|---|---|---|
|  |  |  |  |  |  |

## 3. 正常経路

| 番号 | 送信元 | 受信先 | メッセージ | 入力 | 同期・非同期 | 戻り・観測結果 | 根拠 |
|---:|---|---|---|---|---|---|---|
| 1 |  |  |  |  | 未確認 |  |  |

## 4. 代替・失敗経路

| 経路ID | 分岐元 | 分岐条件 | メッセージ列 | 合流先・終了 | 根拠 |
|---|---:|---|---|---|---|
|  |  |  |  |  |  |

## 5. 別のやり取り（ref）

| ref名 | 分ける理由 | 入力 | 戻り | 失敗時 | 確認担当 |
|---|---|---|---|---|---|
|  |  |  |  |  |  |

## 6. 未確認事項

| 項目 | 分からない理由 | 確認先 | 期限 | 確定までの扱い |
|---|---|---|---|---|
|  |  |  |  | 保留 |

作図票から図へ移す

作図票が埋まったら、次の順で図へ移します。

ユースケース名を図の名前にする
対象のやり取りの枠を置く
主アクター、対象システム、支援アクターを左右に置く
根拠がある内部参加者だけを追加する
正常経路のメッセージを番号順に上から下へ置く
同期・非同期を作図票どおりに区別する
後続の判断に必要な戻りだけを置く
代替・失敗経路を分岐条件付きのaltへ移す
分離したやり取りをrefで参照する

この段階で新しい参加者やメッセージが必要になったら、図の上で補わず作図票へ戻します。根拠、同期性、戻り、失敗時を確認してから図を更新します。

AIへ渡す範囲を決める

AIには、入力資料から候補を抜き出し、作図票の各欄へ整理させられます。渡す資料と出力形式を限定します。

AIへ渡す入力

対象ユースケース一件
正常経路と代替・失敗経路
用語集または役割一覧
既に承認された境界や責任の資料
「資料にない内容は未確認とする」という制約

AIに求める出力

各候補の根拠となる文または節
参加者候補と、その責任
正常経路の送信元、受信先、メッセージ
分岐条件、合流先、失敗終了
同期性と戻りの候補
根拠がなく確定できない項目

AIの出力だけで参加者、通信方式、同期性、戻りを確定しません。「一般的には」「おそらく」を根拠にした項目は未確認へ移します。個人情報、秘密情報、認証情報は入力に含めません。

完了条件を確認する

図を最終候補とする前に、次を確認します。

一つの利用者目的だけを扱っている
開始条件、開始の出来事、正常終了、失敗終了が分かる
すべてのライフラインに役割と責任の根拠がある
すべてのメッセージに送信元と受信先がある
正常経路を上から下へ追える
同期・非同期を待機関係から説明できる
必要な戻りと、戻る情報を説明できる
代替・失敗経路に分岐条件と合流先または終了がある
別のやり取りの入力、戻り、失敗時が記録されている
資料にない判断が未確認事項として残っている
正確な時間、API、状態、データ構造、安全性を図だけで保証していない

図に表した呼び出しをAPIの入力・出力・エラー契約へ移す場合は、OpenAPIでAPI仕様を作るへ進みます。正常・代替・失敗経路は、次にソフトウェアテストの種類と選び方へ渡せます。図に新しい内部責任が必要になった場合はコード設計へ戻します。状態、データ、システム配置、脅威分析が必要になった場合は、それぞれ別の設計資料として扱います。

出典

Object Management Group「Unified Modeling Language Specification Version 2.5.1」 — UML 2.5.1の規範文書と正式版。2026年8月20日確認。
Ivar Jacobson and Alistair Cockburn「Use-Case Foundation Version 1.1」 — ユースケース、アクター、基本シナリオ、拡張経路。2026年8月20日確認。
IBM「Sequence diagrams」 — ライフライン、メッセージ順序、インタラクションフレーム。2026年8月20日確認。
IBM「Messages in UML diagrams」 — 送信元・受信先、同期、非同期、戻り。2026年8月20日確認。
IBM「Combined fragments in sequence diagrams」 — alt、領域、ガード条件。2026年8月20日確認。
IBM「Interaction uses in sequence diagrams」 — refによる別のやり取りの参照。2026年8月20日確認。
IBM「UML timing diagrams」 — メッセージ順序と時間・所要時間の区別。2026年8月20日確認。