シーケンス図とは？UMLの書き方・ライフラインやメッセージ・複合フラグメントを解説

シーケンス図とは、複数のオブジェクトが時間の流れに沿ってどんな順番でメッセージをやり取りするかを表すUMLの図です。システムの「静的な骨格」を描くクラス図に対して、シーケンス図が描くのは「時間軸に沿った動き」です。この記事では、ライフライン・メッセージ・活性化という基本の記法から、同期と非同期メッセージを設計判断として切り分ける考え方、条件分岐や繰り返しを表す複合フラグメント、クラス図との役割分担、MermaidやPlantUMLでコードとして管理する方法、そして設計工程で書くべき場面と過剰設計になる失敗パターンまでを、設計と実装の現場視点で整理します。

まとめ：シーケンス図の構成要素・メッセージの書き方と設計での役割

シーケンス図の芯は、オブジェクト同士がどんな順番で処理を呼び合うかを、時間軸に沿って一枚で追えるようにすることにあります。上部に並べた登場人物からライフラインと呼ぶ縦の点線を下ろし、その間を横向きの矢印（メッセージ）で結びます。矢印は上から下へ時系列に読み、どの処理がどの処理を呼び出したかが一目で読み取れる点が特徴です。

押さえる要素は多くありません。登場人物を表すライフライン、処理が動いている期間を示す活性化（アクティベーション）、命令を伝えるメッセージの3つが土台です。メッセージには、応答を待つ同期と待たない非同期があり、この区別はそのままAPI呼び出しかイベント駆動かという設計判断につながります。条件分岐や繰り返しは、alt・opt・loop・parといった複合フラグメントの枠で囲んで表します。

シーケンス図が効くのは、詳細設計で処理の流れを詰める工程と、複数のサービスやクラスが絡む複雑なやり取りを関係者で合意する場面です。逆に、単純な一本道の処理まで律儀に図にすると、保守されない紙の資料に終わります。どの処理を図にし、どこで手を止めるか、その線引きまで条件付きで言い切ります。静的な構造の側はクラス図が担い、本記事はその構造がどう動くかを描く役割です。

シーケンス図とは何か：UMLにおける定義とクラス図との役割分担

はじめに言葉の範囲をそろえます。シーケンス図は、システムの振る舞いを「誰が、いつ、誰に、何を頼むか」という時間順で捉える図です。部品の設計図であるクラス図とは、描く対象がそもそも違います。

シーケンス図の定義と、時間軸の動きを表すUMLの相互作用図としての位置づけ

シーケンス図は、UML（Unified Modeling Language）で定義された相互作用図の一種で、オブジェクト間でやり取りされるメッセージを、時間の経過に沿って表します。狙いは、実装に入る前に「処理がどんな順番で流れ、どのオブジェクトがどのタイミングで動くか」を設計として固めることです。たとえばECサイトの注文処理なら、利用者・注文画面・在庫サービス・決済サービスといった登場人物を横に並べ、在庫を確認してから決済を呼ぶ、という順序を矢印の並びで描きます。時間の概念を持たないクラス図が「部品の設計図」なら、シーケンス図は「部品がどう連携して動くかの台本」にあたります。

クラス図（静的構造）とシーケンス図（時間軸の動き）の役割分担と使い分け

同じUMLでも、クラス図とシーケンス図は補い合う関係です。クラス図はどんなクラスがあり互いにどうつながるかという静的な構造を表し、シーケンス図はそのクラスたちが実行時にどんな順で呼び合うかという動的な振る舞いを表します。設計では、まずクラス図で登場人物と関係を固め、次にシーケンス図で処理の流れを追う、という順で使うと過不足がありません。両者を照らし合わせると、クラス図に描いた操作が実際にどこから呼ばれるかが見え、逆にシーケンス図で必要になった呼び出しがクラス図の操作漏れをあぶり出します。静的な構造の描き方はクラス図とは何かで詳しく扱っているので、対にして読むと設計の解像度が上がるはずです。なお、そもそもシステムにどんな機能があるかを利用者目線で洗い出す段階にはユースケース図を使い、その機能の内部処理をシーケンス図で詳細化する、という順に進みます。

ライフライン・メッセージ・活性化というシーケンス図の3つの基本要素

シーケンス図は、3つの要素さえ読めれば骨格をつかめます。まずライフラインは、登場人物（オブジェクトやアクター）を表す頭部の長方形と、そこから真下に伸びる点線を指します。時系列で先に動くものを左に置くと、図が格段に読みやすくなる点がコツです。次に活性化（アクティベーション）は、ライフライン上に重ねる細い縦長の長方形で、そのオブジェクトが処理を実行している期間を表します。メッセージを受けてから応答を返すまでの長さが、この短冊にあたると考えてください。そしてメッセージは、ライフライン間を結ぶ横向きの矢印で、あるオブジェクトが別のオブジェクトへ出す命令を示します。この3要素が組み合わさり、上から下へ読める処理の台本ができあがります。

シーケンス図のメッセージの種類：同期・非同期・応答と複合フラグメントの書き方

シーケンス図で表現に差が出るのは、矢印の引き分けと、処理のまとまりの囲み方です。メッセージの種類を正しく使い分けられると、図が処理の意図まで語り始めます。

同期メッセージと非同期メッセージを設計判断として切り分ける基準

メッセージの矢印は、応答を待つかどうかで描き分けます。同期メッセージは、塗りつぶした三角の矢じり（実線）で表し、呼び出した側は応答が返るまで処理を止めて待ちます。メソッド呼び出しや、結果を受け取ってから次へ進むAPIリクエストが典型です。非同期メッセージは、開いた矢じり（線状）で表し、呼び出した側は応答を待たずに次の処理へ進みます。メッセージキューへの送信や、イベント通知、バックグラウンドジョブの起動がこれにあたります。応答（リターン）は破線の矢印で、呼び出しに対する戻り値を示す線です。ここで大切なのは、この描き分けが図の見た目の問題ではなく、設計判断そのものだという点です。同期で描けば処理は直列につながって追いやすい反面、呼び出し先が遅いと全体が待たされます。非同期で描けば待ち時間を切り離せる反面、応答の受け取りや失敗時の扱いを別で設計する必要が出ます。シーケンス図の矢印を選ぶ行為は、その処理を同期で組むか非同期で組むかを決める行為とほぼ同じです。オブジェクト間のメッセージがメソッド呼び出しに対応するという前提はオブジェクト指向の考え方を土台にしています。

alt・opt・loop・parで条件分岐や繰り返しを表す複合フラグメントの使い分け

単純な一本道の処理なら矢印を並べるだけで足りますが、条件分岐や繰り返しは複合フラグメントという枠で囲んで表します。枠の左上にラベルを付け、何のまとまりかを示すのが記法です。よく使う4つを押さえれば実務は回ります。altは条件分岐で、複数の条件のうちどれか一つが実行される場合に使い、if-else に相当する枠です。optは省略可能な処理で、条件を満たしたときだけ実行される、else のない分岐を表します。loopは繰り返しで、一覧の各要素を処理するような反復に使います。parは並行処理で、複数のまとまりが同時に走る様子を囲む枠です。これらを入れ子にすれば、実際のコードのフロー制御をかなり忠実に描けます。ただし、フラグメントを深く入れ子にしすぎると、図がコードそのものより読みにくくなる点には注意が要る、というのが実務の勘所です。分岐や繰り返しの中でも、設計判断が要る中核の流れだけをフラグメントで囲み、細部は本文の注釈へ逃がすほうが、図は伝わりやすくなります。

シーケンス図の書き方：処理の流れを洗い出してコードで管理するまでの手順

要素とメッセージの種類を押さえたら、実際に描く手順に移ります。いきなり矢印から書き始めず、登場人物ときっかけを先に決めるのが、破綻しない図への近道です。

登場人物とメッセージを時系列に並べるシーケンス図の基本的な作成手順

シーケンス図は、次の4ステップで組み立てると過不足がありません。処理のきっかけから終わりへ、上から下へ順に確定させます。

1. 登場人物を洗い出す：処理に関わるアクターやオブジェクト（利用者・画面・サービス・DBなど）を挙げ、動く順に左から並べる
2. きっかけを決める：どのアクションから処理が始まるか（ボタン押下やAPIリクエストなど）を最初のメッセージにする
3. メッセージを時系列に結ぶ：呼び出しを上から順に矢印で描き、同期・非同期・応答を矢じりで描き分ける
4. 条件分岐と繰り返しを囲む：alt・opt・loop・parのフラグメントで、分岐や反復のまとまりを枠に入れる

最初から例外処理やエラー分岐まで盛り込もうとせず、まずは正常系（うまくいく場合）の一本道を描き切るのがコツです。正常系が固まってから、失敗時の分岐をaltで足していくと、図が破綻しません。一度にすべての流れを描こうとせず、一つのユースケースにつき一枚を目安にすると、読める粒度に収まります。

MermaidやPlantUMLでシーケンス図をコードとして管理する方法

作図ツールで描いたシーケンス図は、処理が変わるたびに矢印を引き直す手間がかかります。バージョン管理と相性がよいのが、テキストから図を生成するツールです。Mermaidなら、Markdown内に sequenceDiagram のブロックを書き、A->>B: リクエスト のような一行でメッセージを表せて、GitHubやドキュメントツールでそのまま描画されます。PlantUMLも同様にテキストで記述でき、複合フラグメントや活性化まで細かく表現しながらGitでdiffを取れます。図をコードで持てば、レビューで処理の変更差分を追え、設計と実装のずれを早く検知できるのが利点です。Mermaidの記法とエディタでの試し方はMermaid記法の使い方に、VSCode上で実際にシーケンス図を描く手順はVSCodeでMermaidを使ったシーケンス図の作成方法にまとめています。ツールに任せる前に、メッセージの種類やフラグメントの意味を理解しておくと、生成された図の善し悪しを判断できます。

設計工程でシーケンス図を使う判断と、書くべきでない場面の見極め

ここからは立場を明確にします。シーケンス図は、どんな処理でも必ず描くべき図ではありません。効く場面があり、逆に描くことが手間だけを増やす状況もあります。どちらかを見極める基準を、具体的な条件で示します。

詳細設計・複雑な連携でシーケンス図が効く場面と成果物としての扱い

シーケンス図がもっとも力を発揮するのは、複数のオブジェクトやサービスが絡み合う処理を設計する場面です。マイクロサービス間の呼び出し順、外部APIや決済のような非同期を含むフロー、認証やトランザクションのように順序を間違えると事故になる処理では、流れを図で共有しておくと実装のぶれと考慮漏れを抑えられます。工程全体のどこにシーケンス図という設計成果物が位置づくかはシステム開発の工程と7フェーズの成果物の全体像が判断の土台です。クラス図で静的な構造を固め、その構造がどう動くかをシーケンス図で詰める、という順で使い分けると、設計の抜けを互いに補えます。本記事は、その設計工程で使う振る舞いのモデリング手法そのものを掘り下げる役割です。

シーケンス図を書かない方がよい場面と、過剰設計になりがちな失敗パターン

シーケンス図を描くべきでない場面もはっきりあります。第一に、登場人物が一つか二つで、呼び出しも一本道の単純な処理です。コードを読めば一目で分かる流れを図にしても、保守の手間が増えるだけです。第二に、まだ処理の順序が固まっていない検討初期の段階で、無理に清書すると手戻りで描き直しになります。ありがちな失敗は3つあります。すべてのメソッド呼び出しを漏れなく描こうとして、コードをなぞっただけの巨大で読めない図になること。ゲッターやログ出力のような些末な呼び出しまで矢印にして、本筋の流れが埋もれること。そして図を作ること自体が目的化し、実装が変わっても更新されず、実態と食い違ったまま放置されることです。三つに共通するのは、シーケンス図が処理の合意と設計判断の道具であるという原点を見失っている点にあります。全体を一枚に描き切ろうとせず、判断や合意が要る中核の流れに絞るほうが、図は長く使われます。

受託開発で処理設計を業務要求から一貫して組み立てる体制の作り方

シーケンス図が真価を発揮するのは、業務システムや基幹システムのように、複数の処理が連携し、長く保守し続ける前提の開発です。処理の順序や同期・非同期の判断を初期に誤ると、後から負荷や障害が顕在化し、切り分けに時間がかかります。とはいえ、業務の要求を破綻しない処理フローへ落とし込むには、システム設計とドメインの理解の両方が要る仕事です。社内に設計を主導できる人材がいない、既存システムの処理連携が複雑で手を入れづらい、といった場面では、外部の伴走が歯止めになります。一創では基幹システム開発として、業務要求を処理フローやクラス構造へ整理する要件定義から、設計・実装・運用までを一貫して支援しています。図を描く技術だけでなく、変更や障害に強い処理設計を業務要求から導くところまで含めた伴走が一創の強みです。

よくある質問

シーケンス図の理解と実務でつまずきやすい点を、5つの質問に絞って整理します。

シーケンス図とクラス図の違いは何ですか？

表す対象が異なります。クラス図はシステムを構成するクラスと属性・操作・関係を表す静的な構造の図で、時間の概念を持ちません。シーケンス図はオブジェクト間のメッセージのやり取りを時間順に表す動的な振る舞いの図で、処理の順序を扱います。設計では、クラス図で部品と関係を固め、シーケンス図でその部品がどう動くかを描く、という補い合う使い方をします。同じシステムを、静止画で見るか、動画で見るかの違いに近いと考えると分かりやすいです。

同期メッセージと非同期メッセージはどう使い分けますか？

応答を待つ必要があるかで判断します。呼び出した結果を受け取ってから次へ進むなら同期（塗りつぶした矢じり）、応答を待たずに処理を続けてよいなら非同期（開いた矢じり）です。データベースへの問い合わせのように結果が必要な処理は同期、メール送信やイベント通知のように結果を待たなくてよい処理は非同期が向きます。この選択は図の見た目でなく、処理を直列にするか並行にするかという設計判断そのものなので、応答の受け取りや失敗時の扱いまで含めて決めます。

複合フラグメント（alt・opt・loop）はどんなときに使いますか？

処理に条件分岐や繰り返しがあるときに使います。altは複数の条件のどれか一つを実行するif-elseに相当し、optは条件を満たしたときだけ動くelseのない分岐、loopは反復処理を表します。並行して動く処理はparで囲むのが基本です。ただし深く入れ子にすると図がコードより読みにくくなるため、設計判断が要る中核の分岐だけを囲み、細部は注釈へ逃がすのが実務のコツになります。まずは正常系を描き、そこへaltで例外分岐を足す進め方がまとまりやすいです。

シーケンス図はどのツールで作成できますか？

作図に特化したツールとして、draw.io、Lucidchart、astah、PlantUMLエディタなどが挙げられます。テキストから図を生成するMermaidやPlantUMLも使え、Gitでのバージョン管理と併せて運用できるのが強みです。処理の変更が頻繁で図を実装と同期させたい場合はMermaidやPlantUML、見た目を細かく整えたい場合はGUIの作図ツールが向きます。チームが図をコードで管理するか資料として管理するかに合わせて選ぶのが実際的です。

シーケンス図はどこまで詳しく書くべきですか？

合意や設計判断が要る中核の流れに絞るのが基本です。すべてのメソッド呼び出しやログ出力まで描くと、コードをなぞっただけの読めない図になり、実装が変わるたびに更新できず放置されます。目安は、一つのユースケースにつき一枚、正常系と主要な例外分岐が追える粒度です。細部はコードに任せ、図は「なぜこの順で呼ぶか」という設計意図が伝わる範囲に留めると、長く使える資料になります。

関連記事

• クラス図とは：シーケンス図と対になる静的構造の図。部品の設計図と動きの台本を対にして読む
• ユースケース図とは：機能の輪郭を洗い出すUML。要件からシーケンス図で詳細化する順の入口
• オブジェクト指向とは：メッセージがメソッド呼び出しに対応する、シーケンス図の土台となる考え方
• システム開発の工程とは：シーケンス図を作る設計がどの工程に位置づくかの全体像
• Mermaid記法の使い方：シーケンス図をコードとして描き、差分管理する手法
• VSCodeでMermaidを使ったシーケンス図の作成方法：エディタ上で実際に描く具体手順