最終更新日：2026年10月5日
fe fe-technology software-engineering uml
まず結論
アクティビティ図（activity diagram）は、処理や業務の実行順序・条件分岐・並行処理などの流れを表すUML図です。
FEの科目Aでは、問題文に次のような表現があれば有力候補になります。
「処理の流れ」「実行順序」「条件による分岐」「ワークフロー」→ アクティビティ図
図の名前だけを暗記するより、何を表したい図なのかで判断するのがポイントです。
直感的な説明
アクティビティ図は、処理の流れを追う図です。
例えば、注文を受けて在庫を確認する業務を考えてみます。
見るべきなのは、
何をする？
↓
次に何をする？
↓
条件によってどちらへ進む？
という動きです。
フローチャートに似ていますが、アクティビティ図はUMLで処理や業務の流れをモデル化するときに使います。
定義・仕組み
アクティビティ図はUML（Unified Modeling Language）の図の一つで、アクティビティの流れを表します。
代表的な要素として、
- 開始
- アクション（処理）
- 制御フロー
- 判断・分岐
- 合流
- 終了
などがあります。
例えば、
開始
↓
申請を受け付ける
↓
内容を確認する
↓
承認できる？
├─ Yes → 承認する
└─ No → 差し戻す
↓
終了
のように、処理の順序と条件による進み方を表せます。
ビジネスでもプログラムでも使える
アクティビティ図は、プログラム内部の処理だけを表す図ではありません。
業務プロセス
→ 申請 → 審査 → 承認
プログラム処理
→ 入力 → 判定 → 出力
どちらも「処理の流れ」という共通点があります。
そのため、ビジネスモデリングでワークフローを表したいという場面でも候補になります。
科目Aでどう出る？
科目Aでは、複数のUML図から目的に合うものを選ばせる問題に注意します。
まず、図の見た目より何を表すかを読み取ります。
→ アクティビティ図
→ オブジェクト図
→ クラス図
→ コンポーネント図
| 問題文で注目する表現 | 選ぶ図 |
|---|---|
| 実行順序、条件分岐、ワークフロー | アクティビティ図 |
| 特定時点のインスタンス間の関係 | オブジェクト図 |
| クラス、属性、クラス間の関係 | クラス図 |
| コンポーネント、部品、依存関係 | コンポーネント図 |
試験中は、
「何という図か？」ではなく「何を表したいのか？」
と考えると選択肢を切りやすくなります。
どんな場面で使う？
アクティビティ図は、処理や業務の流れを整理したい場面に向いています。
例えば、
- 注文から出荷までの業務フロー
- 申請から承認までのワークフロー
- ユーザー登録処理
- 条件によって処理が変わるプログラム
- 複数の処理が並行して進む流れ
などです。
「誰が何を持っているか」という静的な構造よりも、時間とともに処理がどう進むかを見たいときに使う、と考えると分かりやすいです。
よくある誤解・混同
誤解1：クラス図も矢印があるので処理の流れを表す
クラス図の線や矢印は、基本的にクラス間の関係を表します。
アクティビティ図
→ 処理がどう進むか
クラス図
→ システムがどんなクラスで構成されるか
動きか、構造かで切り分けます。
誤解2：オブジェクト図はオブジェクトの動きを表す
名前に「オブジェクト」とありますが、オブジェクト図は主にある時点での具体的なインスタンスとその関係を表す静的な図です。
処理の流れ
→ アクティビティ図
ある時点の具体例
→ オブジェクト図
誤解3：コンポーネント図は処理を部品ごとに並べる図
コンポーネント図の中心は、処理順序ではなくソフトウェアを構成する部品とその依存関係です。
順番・分岐
→ アクティビティ図
部品・依存関係
→ コンポーネント図
誤解4：アクティビティ図はプログラム専用
アクティビティ図は、プログラムの制御フローだけでなくビジネスプロセスや業務ワークフローのモデル化にも利用できます。
問題文に「ビジネスモデリング」と書かれていても、それだけで候補から外さないようにします。
まとめ（試験直前用）
- アクティビティ図は、処理・業務の流れを表すUML図
- 実行順序・条件分岐・ワークフローが重要なキーワード
- オブジェクト図は具体的なインスタンス、クラス図はクラス構造、コンポーネント図は部品と依存関係
- 試験では図の名前より、「何を表したい？」で選ぶ
- ビジネスプロセスにもプログラムの処理にも利用できる
公式の出題範囲やシラバスは、IPA：基本情報技術者試験 から確認できます。