はじめに
ソフトウェアアーキテクチャとビジネスプロセスモデリングの複雑な世界において、明確さが何よりも重要です。静的な図であるクラス図はシステムが何で構成されているかを示しますが、何で構成されているかを示しますが、アクティビティ図はどのようにシステムが動作するかを明らかにします。これらは UML(統一モデリング言語)の動的な心臓部であり、開始から完了までの制御とデータのフローを捉えます。
アクティビティ図をアクティビティ図は、エンタープライズロジックのために設計された洗練されたフローチャートと捉えてください。単に手順を列挙するだけでなく、意思決定のポイント、並列プロセス、ループ、および異なるアクターやシステム間の引き継ぎを可視化します。ユーザーのログイン経路の文書化、注文履行パイプラインのマッピング、あるいは複雑なアルゴリズムの設計を行う場合でも、アクティビティ図はビジネス関係者と技術チームの間のギャップを埋める普遍的な言語を提供します。

このガイドでは、バージョン管理が可能で、維持管理が容易で、一貫性のある可視化を実現するテキストベースの図作成ツールであるPlantUMLを用いてこれらの強力な図を作成することに焦点を当てています。以下に示す構文とベストプラクティスを習得することで、抽象的なプロセスを明確で実行可能な視覚モデルに変換できるようになります。
1. 主要な概念と構築ブロック
堅牢なアクティビティ図は、特定の核心要素のセットから構築されています。コードを書く前に、これらの構築ブロックを理解することが不可欠です。

| 要素 | 形状 | 目的 |
|---|---|---|
| 開始ノード | ● | フローの開始点を示す(必須) |
| アクション / 活動 | ▭ 角丸 | プロセス内の単一のステップまたはタスク |
| 分岐 / 統合 | ◇ | 分岐条件(はい/いいえまたは多方向) |
| ループ(繰り返し) | ◇→◇ | 条件が満たされるまでアクションを繰り返す |
| フォーク / ジョイン | — | フローを以下に分岐する並列ブランチにし、それらを再度結合する |
| スイムレーン | テーブル列 | 活動以下によってグループ化する責任者 / システム / 部署 |
| 停止ノード | ◉ | フローの終了点を示す(少なくとも1つ必要) |
主要用語
- アクション: プロセス内の原子的なステップ、例:
: 支払い検証;. - 制御フロー: 実行順序を示すアクションを結ぶ矢印。
- 分岐ノード: ガード条件を評価し、次にどの経路を取るかを決定します。
- フォーク/ジョイン: フォーク は並行フロー(並列処理)を起動し、一方、ジョイン はそれらを単一のスレッドに同期します。
- スイムレーン: 責任に基づいて図を分割します。これは、部門間、ユーザー間、またはマイクロサービス間の引き継ぎを示すのに非常に優れています。
2. ダイアグラムの例
以下に、これらの要素を組み合わせて機能的なダイアグラムを作成する方法を示す2つの包括的な例を示します。
例A:フル機能の「注文処理」
機能:スイムレーン、分岐、ループ、およびフォーク
このダイアグラムは、顧客、注文システム、および倉庫を関与させる、完全な電子商取引注文ライフサイクルをモデル化しています。
@startuml
<style>
element { MaximumWidth 150 }
start { Backgroundcolor #00695C }
stop { Backgroundcolor #C2185B }
activity{ Backgroundcolor #81D4FA; MaximumWidth 150 }
diamond { Backgroundcolor #FFB74D; MaximumWidth 80 }
arrow { LineColor #424242; Fontcolor #000000 }
swimlane{ Fontcolor #000000; FontSize 14 }
</style>
title 注文処理アクティビティダイアグラム
|#F0F8FF|顧客|
start
:注文を置く;
|#FFF8E1|注文システム|
:注文を受信;
:支払いを検証;
if (支払い承認?) then (はい)
:注文を確認;
else (いいえ)
:顧客に通知;
stop
endif
|#F0F8FF|顧客|
:確認を確認;
repeat
:注文ステータスを確認;
repeat while (変更要求?) is (はい) not (いいえ)
|#FFF8E1|注文システム|
if (在庫にアイテムがある?) then (はい)
:アイテムを発送;
else (いいえ)
:顧客に遅延を通知;
endif
|#E8F5E9|倉庫|
fork
:アイテムAを梱包;
fork again
:アイテムBを梱包;
end fork
:パッケージを発送;
|#F0F8FF|顧客|
:注文を受信;
stop
@enduml
例B:焦点を当てた「ログイン試行」
機能:分岐、ループ、および早期終了
このダイアグラムは、有効な資格情報、失敗した試行、再試行、およびアカウントのロックアウトを処理するセキュリティロジックに焦点を当てています。

@startuml
<style>
element { MaximumWidth 150 }
start { Backgroundcolor #00695C }
stop { Backgroundcolor #C2185B }
activity{ Backgroundcolor #81D4FA; MaximumWidth 150 }
diamond { Backgroundcolor #FFB74D; MaximumWidth 80 }
arrow { LineColor #424242; Fontcolor #000000 }
swimlane{ Fontcolor #000000; FontSize 14 }
</style>
title ログイン試行アクティビティ図
|#F0F8FF|ユーザー|
start
:認証情報を入力;
|#FFF8E1|認証サービス|
:認証情報を確認;
if (有効?) then (はい)
:セッショントークンを発行;
else (いいえ)
:失敗した試行をログに記録;
repeat
:再入力を促す;
repeat while (残り試行回数?) is (はい) not (いいえ)
if (ロックアウト?) then (はい)
:管理者に通知;
stop
endif
endif
:アクセスを許可;
stop
@enduml
3. PlantUML 構文チートシート
このリファレンスガイドを使用して、効率的に独自の図を作成してください。
' 開始/終了(必須)
start
stop
' 単純なアクション(コロン構文 — 常に ; を含める)
:何かを行います;
' 分岐(唯一有効な形式)
if (条件?) then (はい)
:アクション A;
else (いいえ)
:アクション B;
endif
' ループ
repeat
:繰り返し可能なアクション;
repeat while (続行?) is (はい) not (いいえ)
' 並列フォーク/ジョイン
fork
:並列パス A;
fork again
:並列パス B;
end fork
:結合して続行;
' 泳道(レーンを定義し、その後切り替える)
|#F0F8FF|営業|
:営業でのアクティビティ;
|#FFF8E1|IT|
:IT でのアクティビティ;
4. ガイドラインとハウスルール
図がレンダリング可能で、読みやすく、プロフェッショナルなものとなるように、以下の 10 のルールに従ってください:
- 必須の開始/終了: 常に「
start」で始め、すべての可能なパスが「stop」に到達するようにしてください。目的地のない図は不完全です。 - 分岐の終了: 常に分岐ブロックを「
endif」で終了してください。そうしないと、図は正しくレンダリングされません。 - ループのペア化: すべての「
repeatに対応するwhile 繰り返し。これらは切り離せない構文対です。 - コロン構文: を使用してください
:action;形式を使用してください。 のようなレガシーの略記法は使用しないでください。-> 動作 ->. - 動詞名詞命名法: 可読性を高めるため、動詞名詞のペア(例:単に「Payment」ではなく「Validate Payment」)を使用して動作を明確に命名してください。
- スタイル配置: を配置してください
<style>ブロックを直後に配置してください@startumlの後に、タイトル. - スイムレーンの使用: 複数のアクター、システム、または部署が関与するプロセスでは、責任を明確にマッピングするためにスイムレーンを使用してください。
- 幅の制限: 幅を約 150px 未満に保ってください(
MaximumWidth)を使用して、ラベルが読み取りにくくなるのを防いでください。 - 注釈の回避: 明示的に要求されない限り、図を清潔に保ち、フローに集中させるために注釈要素の使用を避けてください。
- 意味のあるラベル: 説明的な分岐ラベルを選択してください。ただし、
yes/いいえは許容されます。ラベルとしては、承認済み/却下または在庫あり/在庫切れは即座に文脈を提供します。
5. テクニックとコツ
- 泳ぎ路に色分けを適用する: 各泳ぎ路に異なる背景色を使用してください(例に示されている通り)。これにより視認性が向上し、視聴者がどのステップの責任者が誰かを即座に識別できるようになります。
- 並列処理のためだけにフォークを使用する:
フォークは、タスクが本当に独立しており、同時に実行できる場合(例:2つの異なる商品を梱包する)のみ使用してください。逐次的なステップにはフォークを使用しないでください。 - リトライロジックを明示的にモデル化する: ループを の後に配置失敗ケースの後に配置して、リトライロジックを明確にモデル化してください。これにより、開発者やテスターにとってエラー処理パスが明確になります。
- 自然な読み流し: 動作は上から下へ順序付けてください。泳ぎ路は、プロセスの流れに基づいて一貫した左から右の順序で維持してください(例:顧客 → システム → 倉庫)。
- 複雑な分岐: 多方向分岐が必要な場合は、
elseifを使用できますが、可読性を保ってください。複雑なロジックの場合、ネストされたif文の方が、しばしば明確になります。
6. 一般的なユースケース
アクティビティ図は、さまざまな分野で適用可能な多目的なツールです:
- ビジネスプロセスモデリング: 注文履行、従業員オンボーディング、または承認ワークフローの文書化。
- ユースケースの詳細化: 高レベルのユースケースを段階的な行動モデルに拡張する。
- アルゴリズム設計: 複雑な関数、サービス、またはデータ処理パイプラインの制御フローの文書化。
- ワークフロー分析: チーム間の引き継ぎを可視化し、ボトルネックや不明確な責任を特定する。
- エラー処理: フォールバック機構、リトライループ、および失敗時のエクスitsのマッピング。
- 並行処理分析: 競合状態を防ぐために、並列パスで同期(フォーク/ジョイン)が必要な場所を特定する。
- パターン準拠: 実際の実装プロセスを目標標準または規制要件と比較する。
7. 誰が使用するべきか?
| 役割 | それが彼らをどのように支援するか |
|---|---|
| ビジネスアナリスト | 明確なスイムレーンを使用してビジネスワークフローを文書化および再設計し、非効率性を特定する。 |
| ソフトウェアアーキテクト | サービスの制御フローをモデル化し、行動モデルを構造図(クラス/シーケンス)と統合する。 |
| 開発者 | コーディングの前に、複雑なアルゴリズム、状態ロジック、およびリトライフローを設計し、伝達する。 |
| プロダクトオーナー / マネージャー | ステークホルダーをプロセスステップ、意思決定ポイント、およびユーザージャーニーで一致させる。 |
| QAおよびテスター | 分岐、ループ、および並列パスから包括的なテストシナリオを導き出す。 |
| DevOps / SRE | デプロイパイプライン、障害対応戦略、および運用マニュアルを文書化する。 |
| 学生 / 教育者 | 構造化設計の原則と UML 動作モデリングを教え、学ぶ。 |
✅ ダイアグラムを共有する前のクイックチェックリスト
ダイアグラムを確定する前に、この品質保証チェックリストを確認してください:
- 「
開始」が存在し、すべてのパスが「終了」に到達していますか?? - すべての分岐が「
endif」で閉じられていますか?? - ループが対応する「
repeat」/repeat while」のペアで形成されていますか? - フォークが「
fork」/fork again」で開かれ、「end fork」? - で閉じられていますか? すべてのアクションはセミコロン「
;? - 複数のアクターが関与する際にスイムレーンが使用されていますか?
- 「
<style>」ブロックと「タイトル」が上部に正しく配置されていますか?
結論
UML アクティビティ図は単なる見栄えの良い図に過ぎず、コミュニケーション、分析、設計のための不可欠なツールです。PlantUMLを利用することで、これらの図をコードとして作成できるようになり、バージョン管理が可能になり、更新が容易になり、組織全体で一貫性を保つことができます。
単純なユーザーログインから複雑な分散サプライチェーンまで、原則は同じです:開始点と終了点を定義し、意思決定を明確にし、並行性を尊重し、スイムレーンの責任を割り当てます。このガイドで提供される構文チートシートとベストプラクティスにより、あらゆるプロセスを正確かつ明確にモデル化できるようになりました。今日から図の作成を始め、複雑なロジックを理解しやすいワークフローに変えましょう。




