ユースケース図の書き方と例｜include・extendの違いとPlantUML

ユースケース図とは、システムの外にいる利用者や外部システム（アクター）と、システムが提供する機能のまとまり（ユースケース）の関係を1枚に描いたUMLの図です。 「誰が、このシステムで、何をできるのか」を、画面や処理の細部に入る前に関係者とそろえるために使います。

この記事では、記号と4つの関係（関連・include・extend・汎化）を早見表にまとめ、迷いやすい includeとextendの矢印の向きと使い分けを判定表で整理します。題材は架空の図書貸出システムで、PlantUMLのコードを3段階で育てていきます。Mermaidでの書き方と、図に添えるユースケース記述のテンプレートも用意しました。

確認環境：PlantUML 1.2026.8（OpenJDK 21、SVG・PNG出力）／Mermaid 12.1.0（@mermaid-js/mermaid-cli 12.0.0 と Chromium で描画）。掲載したコードは、エラーの例を除き、すべてこの環境で図として出力できることを確認しています。

ユースケース図の記号と関係の早見表

矢印の向きと「必ず実行か条件付きか」の判定表

includeとextendは矢印の向きが逆になります。どちらも「依存している側から、依存されている側へ」矢印を引く、と覚えると迷いません。includeは基本ユースケースが共通部品を必要とするので基本から部品へ、extendは拡張ユースケースが基本を前提にしているので拡張から基本へ向かいます。

includeとextendの違いと使い分け

3つの質問で決める

includeは「共通部品の切り出し」、extendは「条件付きの追加」です。必ず通る流れを1か所でしか使わないなら、切り出さずに基本フローへ書くほうが図が読みやすくなります。

図書貸出システムでの判定例

向きを逆に書いたときの読まれ方

PlantUMLは向きが逆でも図を出力します。レビューでは、矢印を「根元は先を…する」と声に出して読むと気づきやすくなります。

ユースケース図の書き方（5つの手順）

ユースケース名は 「目的語＋動詞」（図書を借りる、蔵書を検索する） の形で、アクターの言葉で書きます。アクターは個人名や役職ではなく、システムに対する役割で名づけます。

PlantUMLで段階的に書く（図書貸出システム）

手順1〜3：アクター・システム境界・ユースケースと関連

@startuml
left to right direction
actor 利用者
actor 司書

rectangle 図書貸出システム {
  usecase "蔵書を検索する" as UC1
  usecase "図書を借りる" as UC2
  usecase "図書を返す" as UC3
  usecase "蔵書を登録する" as UC4
}

利用者 --> UC1
利用者 --> UC2
利用者 --> UC3
司書 --> UC4
@enduml

• left to right direction を付けると、アクターが左、ユースケースが右に並び、数が増えても読みやすくなります。
• rectangle 名前 { … } がシステム境界です。アクターは枠の外に書きます。
• usecase "表示名" as 別名 と別名を付けておくと、あとの関係の行が短く書けます。

手順4：includeとextendを足す

@startuml
left to right direction
actor 利用者
actor 司書

rectangle 図書貸出システム {
  usecase "蔵書を検索する" as UC1
  usecase "図書を借りる" as UC2
  usecase "図書を返す" as UC3
  usecase "蔵書を登録する" as UC4
  usecase "図書を予約する" as UC5
  usecase "利用者を認証する" as UC6
  usecase "延滞を通知する" as UC7
}

利用者 --> UC1
利用者 --> UC2
利用者 --> UC3
利用者 --> UC5
司書 --> UC4

UC2 ..> UC6 : <<include>>
UC5 ..> UC6 : <<include>>
UC7 ..> UC3 : <<extend>>
@enduml

• ..> が破線の矢印です。: <<include>> と書いたラベルは、図では «include» と表示されます。
• 「利用者を認証する」と「延滞を通知する」にはアクターからの関連を引いていません。利用者が直接始めるものではなく、ほかのユースケースの流れの中で実行されるためです。

完成形：汎化・外部システム・拡張点・ノートを入れる

@startuml
left to right direction
skinparam packageStyle rectangle

actor 利用者
actor 学生
actor 教職員
actor 司書
actor "通知サービス" as Mail <<system>>

利用者 <|-- 学生
利用者 <|-- 教職員

rectangle 図書貸出システム {
  usecase "蔵書を検索する" as UC1
  usecase UC2 as "図書を借りる
  --
  extension points
  貸出中の場合"
  usecase UC3 as "図書を返す
  --
  extension points
  返却期限超過"
  usecase "蔵書を登録する" as UC4
  usecase "図書を予約する" as UC5
  usecase "利用者を認証する" as UC6
  usecase "延滞を通知する" as UC7
}

利用者 --> UC1
利用者 --> UC2
利用者 --> UC3
司書 --> UC4
UC7 --> Mail

UC2 ..> UC6 : <<include>>
UC5 ..> UC6 : <<include>>
UC5 ..> UC2 : <<extend>>
UC7 ..> UC3 : <<extend>>

note right of UC7
  条件：返却日が返却期限を過ぎている
  拡張点：返却期限超過
end note
@enduml

出力した図では、次のように表示されます。

ポイントは3つです。

• アクターの汎化：学生と教職員は、利用者ができること（検索・貸出・返却）をすべて引き継ぎます。学生だけ、教職員だけのユースケースがあれば、それぞれから個別に関連を引きます。
• 外部システムもアクター：メールを送る「通知サービス」のように、対象システムの外にあってやり取りする相手は、人でなくてもアクターとして描きます。
• 拡張点：PlantUMLの公式ページには拡張点専用の書き方が載っていないため、ユースケースの説明文に区切り（--）を入れて「extension points」の欄を作っています。extendの条件はノートに書くと、図だけで「いつ追加されるか」が伝わります。

ユースケース同士の汎化

検索方法のように「やり方の違い」を表したいときは、ユースケース同士の汎化を使います。

@startuml
left to right direction
actor 利用者
rectangle 図書貸出システム {
  usecase "蔵書を検索する" as UC1
  usecase "キーワードで検索する" as UC1a
  usecase "著者名で検索する" as UC1b
}
利用者 --> UC1
UC1 <|-- UC1a
UC1 <|-- UC1b
@enduml

構文エラーになる例

かっこを閉じ忘れると、PlantUMLは行番号つきでエラーを知らせます。

@startuml
actor 利用者
利用者 --> (図書を借りる
@enduml

Error line 3 in file: bad.puml
Some diagram description contains errors

Mermaidで書く

usecase-beta（Mermaid 12以降）

Mermaidの公式ドキュメントには、v12.0.0以降で使えるユースケース図（usecase-beta）が載っています。同じ図書貸出システムを書くと次のようになり、Mermaid 12.1.0で棒人間のアクター・だ円のユースケース・枠のシステム境界として描画できました。

usecase-beta
    direction LR
    actor User("利用者")
    actor Student("学生")
    actor Staff("教職員")
    actor Librarian("司書")
    actor Mail("通知サービス")

    systemBoundary Library [図書貸出システム]
        UC1("蔵書を検索する")
        UC2("図書を借りる")
        UC3("図書を返す")
        UC4("蔵書を登録する")
        UC5("図書を予約する")
        UC6("利用者を認証する")
        UC7("延滞を通知する")
    end

    Student --|> User
    Staff --|> User
    User --> UC1
    User --> UC2
    User --> UC3
    Librarian --> UC4
    UC7 --> Mail

    UC2 ..> : include UC6
    UC5 ..> : include UC6
    UC5 ..> : extend UC2
    UC7 ..> : extend UC3

includeとextendは、..> : include までがひとまとまりの演算子で、そのあとに相手を書きます。PlantUMLと同じ順（相手を先、ラベルを後）で書くと、Mermaid 12.1.0では次のエラーになりました。

usecase-beta
    actor User("利用者")
    UC2("図書を借りる")
    UC6("利用者を認証する")
    User --> UC2
    UC2 ..> UC6 : include

Error: Error parsing usecase diagram: Expecting token of type --> COLON <-- but found --> 'UC6' <-- at line 6, column 13 [102,105)

名前に beta が付いているとおり、今後の版で書き方が変わる可能性があります。使う前に、表示先のMermaidの版を確認してください。

flowchartで代用する書き方

usecase-beta に対応していない版のMermaidでは、flowchartで近い見た目を作れます。ユースケースを角丸（([ ])）、システム境界を subgraph、includeとextendをラベル付きの点線矢印で表します。

flowchart LR
    user["👤 利用者"]
    student["👤 学生"]
    staff["👤 教職員"]
    librarian["👤 司書"]
    mail["👤 通知サービス"]

    subgraph system["図書貸出システム"]
        UC1(["蔵書を検索する"])
        UC2(["図書を借りる<br>拡張点：貸出中の場合"])
        UC3(["図書を返す<br>拡張点：返却期限超過"])
        UC4(["蔵書を登録する"])
        UC5(["図書を予約する"])
        UC6(["利用者を認証する"])
        UC7(["延滞を通知する"])
    end

    student -->|汎化| user
    staff -->|汎化| user
    user --- UC1
    user --- UC2
    user --- UC3
    librarian --- UC4
    UC7 --- mail

    UC2 -. "«include»" .-> UC6
    UC5 -. "«include»" .-> UC6
    UC5 -. "«extend»" .-> UC2
    UC7 -. "«extend»" .-> UC3

flowchartにはアクターの棒人間や白抜き三角の矢印がないため、アクターは絵文字付きの四角、汎化はラベル付きの矢印で代用しています。拡張点はユースケース名の2行目に書きました。

PlantUMLとMermaidの選び方

ユースケース記述のテンプレート（Markdown）

ユースケース図は「何があるか」の一覧で、流れの中身までは表しません。だ円1つにつき1枚、ユースケース記述を添えると、設計やテストにそのまま使える情報になります。

# UC-00 ユースケース名（目的語＋動詞）

| 項目 | 内容 |
|---|---|
| 概要 | このユースケースでアクターが達成すること（1〜2文） |
| 主アクター | ユースケースを始めるアクター |
| 支援アクター | 途中で関わる外部システムなど（なければ「なし」） |
| 起動のきっかけ | 何が起きたら始まるか |
| 事前条件 | 開始時に成り立っていること |
| 事後条件（うまくいった場合） | 終了時に成り立っていること |
| 事後条件（中断した場合） | 途中で終わったときに保証すること |
| include | 必ず取り込むユースケース |
| 拡張点 | 拡張点の名前と、基本フローのどのステップか |

## 基本フロー

1. アクターは、〜する。
2. システムは、〜する。
3. …

## 代替フロー

- 2a. （ステップ2で〜の場合）
    1. システムは、〜する。
    2. 基本フローのステップ3に戻る。

## 例外フロー

- 3a. （ステップ3で〜の場合）
    1. システムは、〜を表示して、ユースケースを終了する。

## 補足（業務ルール・非機能の要求・未決事項）

- …

記入例：UC-02 図書を借りる

# UC-02 図書を借りる

| 項目 | 内容 |
|---|---|
| 概要 | 利用者が、貸出カウンターの端末で図書を借りる手続きをする |
| 主アクター | 利用者（学生・教職員） |
| 支援アクター | なし |
| 起動のきっかけ | 利用者が端末で「借りる」を選ぶ |
| 事前条件 | 利用者が登録済みである。借りる図書が手元にある |
| 事後条件（うまくいった場合） | 貸出記録が登録され、図書の状態が「貸出中」になり、返却期限が決まっている |
| 事後条件（中断した場合） | 貸出記録は登録されず、図書の状態は変わらない |
| include | UC-06 利用者を認証する |
| 拡張点 | 貸出中の場合（ステップ4） |

## 基本フロー

1. 利用者は、端末で「借りる」を選ぶ。
2. システムは、「UC-06 利用者を認証する」を実行する。
3. 利用者は、図書のバーコードを読み取らせる。
4. システムは、図書の状態が「貸出可」であることを確かめる。
5. システムは、貸出記録を登録し、図書の状態を「貸出中」にする。
6. システムは、返却期限（貸出日の14日後）を表示する。
7. 利用者は、内容を確かめて手続きを終える。

## 代替フロー

- 3a. （ステップ3でバーコードを読み取れない場合）
    1. 利用者は、図書の管理番号を手で入力する。
    2. 基本フローのステップ4に戻る。
- 7a. （ステップ7で続けて別の図書を借りる場合）
    1. 基本フローのステップ3に戻る。

## 例外フロー

- 4a. （ステップ4で図書の状態が「貸出中」の場合。拡張点：貸出中の場合）
    1. システムは、その図書が貸出中であることを表示する。
    2. 利用者が希望すれば、「UC-05 図書を予約する」を実行する。
    3. ユースケースを終了する。
- 5a. （ステップ5で貸出冊数の上限を超える場合）
    1. システムは、上限を超えることを表示し、貸出記録を登録せずに終了する。

## 補足（業務ルール・非機能の要求・未決事項）

- 貸出冊数の上限：学生5冊、教職員10冊。
- 貸出期間：14日。
- 未決事項：返却期限が休館日に当たる場合の扱い。

図の include（UC-06）と拡張点（貸出中の場合）が、記述のステップ2とステップ4にそれぞれ対応しています。図と記述で同じ名前・同じ番号を使うと、どちらかを直したときにもう一方の直し忘れに気づけます。

ユースケース一覧（表計算ソフトに貼れるタブ区切り）

ID  ユースケース名 主アクター   include extend（拡張点） 記述の状態
UC-01   蔵書を検索する 利用者 なし  なし  作成済み
UC-02   図書を借りる  利用者 UC-06   なし  作成済み
UC-03   図書を返す   利用者 なし  なし  作成中
UC-04   蔵書を登録する 司書  なし  なし  作成前
UC-05   図書を予約する 利用者 UC-06   UC-02（貸出中の場合）   作成前
UC-06   利用者を認証する    （他のユースケースから実行）  なし  なし  作成済み
UC-07   延滞を通知する （他のユースケースから実行）  なし  UC-03（返却期限超過）   作成前

つまずきやすい点と直し方

レビューで確認すること

よくある質問

Q. includeとextendのどちらを使うか迷ったら、どうすればよいですか？ A. まず「その流れがなくても元のユースケースは完結するか」を考えます。完結しないなら include、完結するなら extend です。どちらとも言いにくい小さな流れは、切り出さずにユースケース記述の基本フローや代替フローに書くと、図がすっきりします。

Q. 外部システムや定期実行の仕組みもアクターになりますか？ A. なります。アクターは「システムの外にあって、システムとやり取りする役割」なので、人に限りません。この記事の例では「通知サービス」を <<system>> 付きのアクターとして描きました。

Q. ユースケースはいくつくらいが適切ですか？ A. 数に決まりはありませんが、1枚の図で関係者が全体を見渡せることが目安です。だ円が増えて読みにくくなったら、アクターやサブシステムごとに図を分け、細かい手順はユースケース記述に移します。

Q. 拡張点は必ず書く必要がありますか？ A. extendが1つだけで条件が明らかなら、省いても伝わります。同じユースケースに複数のextendがあるときや、条件が複雑なときは、拡張点の名前と条件を書いておくと、どの位置で何が追加されるかを取り違えずに済みます。

まとめ

• ユースケース図は「誰が、このシステムで、何をできるか」を描く図で、アクター・ユースケース・システム境界と4つの関係でできています。
• includeは必ず実行される共通部品、extendは条件付きの追加です。なくても元のユースケースが完結するかどうかで見分けます。
• 矢印はどちらも「依存している側 → 依存されている側」。includeは基本から部品へ、extendは拡張から基本へ向かいます。
• PlantUMLでは rectangle で境界、..> と <<include>>・<<extend>> で関係を書き、拡張点は説明文の区切りで表せます。
• Mermaidは12以降の usecase-beta で専用の図が書け、flowchartでも代用できます。
• だ円1つにつきユースケース記述を1枚。事前条件・事後条件・基本フロー・代替フローを書き、図と同じIDと名前を使います。

参考・出典

• PlantUML「Use Case Diagram」（アクター・ユースケース・rectangle・矢印・ノート・説明文の区切り）: https://plantuml.com/use-case-diagram
• Mermaid「Use Case Diagram」（usecase-beta、v12.0.0以降）: https://mermaid.js.org/syntax/usecase.html
• IBM Documentation「Extend relationships」（拡張から基本への破線矢印、«extend»、拡張点、条件付きの振る舞い）: https://www.ibm.com/docs/en/rational-soft-arch/9.7.0?topic=diagrams-extend-relationships
• IBM Documentation「Include relationships」（基本から包含ユースケースへの破線矢印、«include»、共通の振る舞い）: https://www.ibm.com/docs/en/dma?topic=diagrams-include-relationships

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。