シーケンス図：その概要と作成方法（2026年ガイド）

分散システムで何かが壊れた場合、最初の質問は通常「何が何と通信し、どの順序でしたのか？」です。これがまさにシーケンス図が答えることです。オブジェクト、サービス、またはユーザーが時間をかけてどのように相互作用するかを示します——見えないコミュニケーションパターンを可視化します。

シーケンス図はソフトウェアチームにとって最も実用的なUMLダイアグラムタイプの1つです。高レベルのアーキテクチャと実際のコードの間のギャップを埋め、API設計、マイクロサービス呼び出しのデバッグ、認証フローの文書化、エンジニアを見慣れないシステムにオンボーディングするのに非常に役立ちます。

シーケンス図とは？

シーケンス図は、参加者（オブジェクト、サービス、ユーザー、またはシステム）が特定のシナリオでどのように互いに通信するかを時間順に示すインタラクションダイアグラムの一種です。垂直軸は下に流れる時間を表します。水平軸は参加者を列挙します。

プロセスのロジックに焦点を当てるフローチャートとは異なり、シーケンス図は複数の参加者間で交換されるメッセージとそれらの交換が発生する順序に焦点を当てます。

基本構造：

Client          Auth Service       Database
  |                  |                 |
  |──── login() ────>|                 |
  |                  |── findUser() ──>|
  |                  |<── userData ────|
  |                  |── verifyPwd()   |
  |<── JWT token ────|                 |
  |                  |                 |

各垂直線はライフラインです。各水平矢印はメッセージです。時間は上から下に流れます。

シーケンス図のUML表記

ライフライン

ライフラインはインタラクションの参加者を表します。上部のボックス（参加者の名前を示す）と下に伸びる破線の垂直線で構成されます。

┌──────────┐   ┌──────────────┐   ┌──────────┐
│  Client  │   │  API Server  │   │  Database│
└────┬─────┘   └──────┬───────┘   └────┬─────┘
     │                │                │
     │  (dashed line continues down)   │

命名規則：

システム/サービス： キャメルケースまたはパスカルケース（PaymentService、AuthAPI）
アクター/ユーザー： 平文名（User、Admin、Customer）
インスタンス： objectName:ClassName表記（order:Order）

メッセージ

メッセージはライフライン間の水平矢印です。4つのタイプ：

メッセージタイプ	矢印スタイル	意味
同期呼び出し	`────────>`	呼び出し元が応答を待つ
戻りメッセージ	`- - - - ->`	同期呼び出しへの応答
非同期メッセージ	`────────>`	呼び出し元が待たない（開いた先端が多い）
セルフコール	矢印がループバック	オブジェクトが自身のメソッドを呼び出す

アクティベーションバー

アクティベーションバー（または実行の発生）はライフライン上の細い長方形で、その参加者がアクティブな場合——リクエストを処理またはロジックを実行——を示します。

     │              │
     │──── call ───>│
     │              ██  <- activation bar (participant is processing)
     │<── return ───│
     │              │

結合フラグメント

結合フラグメントにより、シーケンス図内で条件的および繰り返しのロジックを示すことができます。左上隅にラベルを持つ長方形のボックスとして表示されます。

フラグメント	ラベル	目的
ループ	`loop`	シーケンスを繰り返す（条件または回数を指定）
Alt	`alt`	代替パス——if/elseブロックのような
Opt	`opt`	オプションシーケンス——条件が真の場合のみ実行
Par	`par`	並行実行——シーケンスが同時に発生
Ref	`ref`	別のシーケンス図への参照

Altフラグメントの例：

┌─ alt ─────────────────────────────────────┐
│ [credentials valid]                        │
│   AuthService ──── issue token ───> Client │
├────────────────────────────────────────────┤
│ [credentials invalid]                      │
│   AuthService ──── 401 error ────> Client  │
└────────────────────────────────────────────┘

Loopフラグメントの例：

┌─ loop [for each item in cart] ─────────────┐
│   OrderService ── check stock ──> Inventory│
│   Inventory ─── available? ──> OrderService│
└────────────────────────────────────────────┘

シーケンス図対フローチャート

どちらのダイアグラムもプロセスをモデル化しますが、異なる質問に答えます。

側面	シーケンス図	フローチャート
主な焦点	参加者間のコミュニケーション	単一プロセス内のロジックフロー
軸	時間（垂直）＋参加者（水平）	方向性の矢印で接続されたステップ
示すもの	メッセージ、順序、タイミング	決定、分岐、ループ
複数のアクター	ネイティブ——各々がライフラインを持つ	スイムレーンなしでは可能だが不自然
最適なケース	API、プロトコル、分散システム	アルゴリズム、ビジネスプロセス
並行動作	`par`フラグメントでサポート	表現が難しい
一般的なユーザー	ソフトウェアエンジニア、アーキテクト	ビジネスアナリスト、プロダクトチーム

「システムAがシステムBに何を言い、いつ言うか？」という質問が重要な場合はシーケンス図を使用します。「このプロセスは次にどんな決定をするか？」という質問にはフローチャートを使用します。

シーケンス図をいつ使うか

API設計とドキュメント

コードを1行も書く前に、シーケンス図でAPIコントラクトを検証できます。機能の呼び出しシーケンスを描き、チームでレビューします。本番環境のバグになる前に、欠けているエンドポイント、不正確なデータの依存関係、曖昧な応答フォーマットを検出できます。

マイクロサービスのコミュニケーション

マイクロサービスアーキテクチャは、単一のユーザーアクションのフローが5つ以上のサービスにまたがることが多いため、推論が難しいです。シーケンス図によりこれが可視化されます：

User       Gateway     OrderSvc    InventorySvc    PaymentSvc    NotifySvc
 |            |            |              |              |             |
 |── POST /order ─────────>|              |              |             |
 |            |            |── check() ──>|              |             |
 |            |            |<── ok ───────|              |             |
 |            |            |── charge() ──────────────────>|             |
 |            |            |<── receipt ──────────────────|             |
 |            |            |── send() ──────────────────────────────────>|
 |<── 201 Created ─────────|              |              |             |

認証フロー

認証フローには複数の関係者（ユーザー、ブラウザ、アイデンティティプロバイダー、リソースサーバー）と厳密な順序要件が含まれます。シーケンス図はOAuthフロー、SAMLアサーション、JWTバリデーションチェーンを文書化する標準的な方法です。

本番インシデントのデバッグ

インシデントが発生した場合、何が起きたかを再構築するには、サービス間の呼び出しを追跡する必要があります。ログとトレースから描いたシーケンス図により、チームは生のログを読むよりも速く障害シーケンスを理解し、根本原因を特定するのに役立ちます。

オンボーディングと知識移転

チームに参加した新しいエンジニアは、シーケンス図を読んで複雑なフローを数分で理解できます。インタラクションが多いシステムでは、コードや散文のドキュメントを読むよりも効率的です。

ステップバイステップ作成ガイド

ステップ1：シナリオを定義する

システム全体ではなく、1つの特定のシナリオを選びます。良いスコープ：

「ユーザーがGoogle OAuthでログインする」
「顧客がカードが拒否された注文をする」
「サービスAがサービスBを呼び出し、タイムアウトする」

避けるべき：「認証システム」（広すぎる）。ダイアグラムごとに1つのシナリオ。

ステップ2：参加者を特定する

このシナリオに関与するすべてのアクターまたはシステムを列挙します。一般的な参加者：

外部アクター： ユーザー、ブラウザ、モバイルアプリ
サービス： APIゲートウェイ、認証サービス、注文サービス
データストア： データベース、キャッシュ、メッセージキュー
サードパーティ： Stripe、Twilio、SendGrid

最初に現れる順に左から右に並べ、開始者を左端に置きます。

ステップ3：メッセージを列挙する

シナリオの各ステップについて、以下を書き留めます：

誰がメッセージを送るか
誰が受け取るか
メッセージが何か（メソッド名、イベント名、または説明）
同期か非同期か

ステップ4：シーケンスを描く

参加者をライフラインとして上部に配置します。メッセージを水平矢印として時系列順（上から下）に描きます。処理時間を示すアクティベーションバーを追加します。条件または繰り返しのロジックを結合フラグメントでグループ化します。

┌──────────┐         ┌──────────────┐         ┌──────────┐
│  Browser │         │  Auth Server │         │  UserDB  │
└────┬─────┘         └──────┬───────┘         └────┬─────┘
     │                      │                      │
     │──── POST /login ─────>│                      │
     │                      ██                      │
     │                      │── SELECT user ───────>│
     │                      │<── user record ────────│
     │                      ██                      │
     │<── 200 + JWT ─────────│                      │
     │                      │                      │

ステップ5：フラグメントと注釈を追加する

シーケンスに条件または繰り返しのロジックがある箇所にalt、loop、またはoptフラグメントを追加します。重要な制約や説明をメッセージラベルにうまく収まらない場合は注釈（UMLでは折りたたまれた長方形として表示）を追加します。

ステップ6：ステークホルダーで検証する

各参加者を所有するエンジニアまたはアーキテクトとダイアグラムを確認します。以下を検証します：

メッセージの順序は正しいか？
戻りメッセージが必要な箇所に含まれているか？
エラーパスが表現されているか？
何か見落としているものはないか？

一般的なパターン

リクエスト-レスポンス

最も基本的なパターン。呼び出し元は同期メッセージを送り、戻りを待ちます。

Client          Server
  │                │
  │──── request ──>│
  │                ██
  │<─── response ──│
  │                │

キューを使った非同期メッセージング

イベント駆動型アーキテクチャで使用されます。プロデューサーはコンシューマーがメッセージを処理するのを待ちません。

Producer      Message Queue     Consumer
    │                │               │
    │── publish() ──>│               │
    │<── ack ────────│               │
    │                │── deliver() ──>│
    │                │               ██
    │                │<── done ───────│

エラー処理パターン

常にハッピーパスと並べて失敗パスをモデル化します。

┌─ alt ──────────────────────────────────────────┐
│ [success]                                       │
│   Service ──── 200 OK ─────────────────> Client│
├─────────────────────────────────────────────────┤
│ [not found]                                     │
│   Service ──── 404 Not Found ──────────> Client│
├─────────────────────────────────────────────────┤
│ [server error]                                  │
│   Service ──── 500 Internal Error ─────> Client│
└─────────────────────────────────────────────────┘

タイムアウトとリトライ

┌─ loop [retry count < 3] ─────────────────────────┐
│   Client ──── request ───────────────> Service   │
│   ┌─ opt [no response within 5s] ───────────────┐│
│   │   Client ──── timeout detected              ││
│   └─────────────────────────────────────────────┘│
└───────────────────────────────────────────────────┘

ベストプラクティス

ダイアグラムごとに1つのシナリオ。 すべての可能なパスをカバーしようとするシーケンス図は読めなくなります。ハッピーパス、エラーパス、エッジケースごとに別々のダイアグラムを描きます。

参加者を5〜7に保つ。 7つ以上のライフラインは水平スペースが問題になります。参加者が多い場合は、関連するサービスを1つの参加者にグループ化し、そのグループの内部のための別のダイアグラムを作成します。

同期呼び出しの戻りメッセージを常に含める。 戻り矢印が欠けていると、呼び出し元が応答を受け取らないことを意味します。明示的にしてください。

メッセージに正確なラベルを付ける。 「getMessage()」は「データを取得する」よりも良いです。メソッド名、HTTPの動詞とパス、またはイベント名を含めます。「リクエスト」や「レスポンス」などの曖昧なラベルを避けます。

開始するアクターを示す。 フローの途中からではなく、シーケンスを引き起こすユーザーまたは外部システムから開始します。

注釈は慎重に使用する。 注釈は制約（「200ms以内に完了する必要がある」）には役立ちますが、過剰に使用するとダイアグラムが乱雑になります。

エラーパスを描く。 ハッピーパスは明白です。ダイアグラムは何かが間違った時に何が起こるかも示す場合に価値があります。

一般的なミス

1つのダイアグラムにシステム全体をモデル化する。 これにより読んだり維持したりするには複雑すぎるダイアグラムが生成されます。各ダイアグラムのスコープを1つの特定のインタラクションシナリオに絞ります。

戻りメッセージをスキップする。 戻りなしで発信呼び出しのみを示すと不完全な絵が作られます。同期呼び出しには戻りメッセージを含めます。

シーケンス図をフローチャートと混同する。 意思決定ひし形と分岐矢印を追加すると、ダイアグラムがフローチャートのハイブリッドになります。条件にはaltとoptフラグメントを代わりに使用します。

誤った時間順序。 ダイアグラムの上位に配置されたメッセージは早く発生すると想定されます。対応するリクエストの上に応答を配置することは一般的なエラーです。

メッセージラベルが詳細すぎる。 メッセージラベルの完全なJSONペイロードはダイアグラムを読めなくします。名前にはメッセージラベルを使用します；ペイロードの詳細が重要であれば注釈を追加します。

非同期インタラクションを無視する。 すべてのメッセージを同期として扱うと重要なアーキテクチャの特性が隠れます。非同期メッセージを明示的にマークします。

Flovovaでシーケンス図を作成する

APIフローとサービスのインタラクションを手動で文書化するのは遅いです。Flovovaのシーケンス図メーカーでは、フローを平文で説明してチームと視覚的に編集できる構造化されたダイアグラムを生成できます。「ユーザーがログインフォームを送信し、認証サービスがデータベースに対して資格情報を検証し、成功するとJWTを返す」のような説明を貼り付けて、チームと修正するための動作ダイアグラムを取得します。

まとめ

シーケンス図は、複数の参加者間でのメッセージの順序と方向を理解または伝えたい場合の適切なツールです。API文書化、マイクロサービスのインタラクション設計、認証フロー仕様、インシデントのポストモーテムに優れています。鍵は各ダイアグラムを1つのシナリオにスコープし、ハッピーパスとエラーパスの両方を含め、各参加者を所有する人々と結果を検証することです。シンプルなリクエスト-レスポンスパターンから始め、シナリオが要求する場合のみ複雑さを追加します。