UML（統一モデリング言語）を使ってシステム設計を行う際、ユースケース図は欠かせない重要なツールです。
その中でも特に混乱しやすいのが、includeとextendの関係ではないでしょうか。
「どちらを使えばいいのか分からない」「包含関係と汎化の違いが曖昧」といった疑問を持つ方は多いものです。
本記事では、ユースケース図におけるinclude（包含関係）の意味や記述方法、extendとの違い、さらに汎化との使い分けまでを丁寧に解説していきます。
設計の現場でスムーズに使いこなせるよう、基礎から整理していきましょう。
ユースケース図のincludeとは？結論から理解しよう
それではまず、ユースケース図におけるincludeの基本概念について解説していきます。
includeの意味と役割
includeとは、UMLのユースケース図においてあるユースケースが別のユースケースを必ず呼び出す関係を表すものです。
日本語では「包含関係」とも呼ばれ、共通処理を切り出して再利用するために用いられます。
たとえば、「商品を購入する」「注文を確認する」という2つのユースケースがあるとき、どちらも「ログインする」という処理を必ず伴うケースが典型的な例といえるでしょう。
この場合、「ログインする」を独立したユースケースとして切り出し、includeで参照させることで、設計の重複を防ぐことができます。
includeは「必ず実行される共通処理」を切り出すための関係です。
呼び出し元のユースケースが実行されると、includeで指定されたユースケースは必ず実行されます。
includeの記述方法
ユースケース図上でのincludeの記述方法は非常にシンプルです。
矢印の方向は呼び出し元から呼び出し先へ向かうように描き、矢印の上に「«include»」というステレオタイプを記載します。
記述例：「商品を購入する」 ──«include»──→ 「ログインする」
この場合、「商品を購入する」が実行されるとき、「ログインする」は必ず一緒に実行されます。
矢印の向きを逆にしてしまうミスが多いため、「呼び出す側から呼び出される側への矢印」という点をしっかり押さえておきましょう。
includeを使うべき場面とは
includeを使うべき場面は、複数のユースケースで共通して必ず行われる処理が存在するときです。
共通処理を1つのユースケースとしてまとめることで、設計図全体のメンテナンス性が向上します。
「必ず実行される」という点がincludeの大きな特徴であり、条件によって実行されるかどうかが変わる場合は、後述するextendを検討すべきでしょう。
extendとの違いを徹底比較
続いては、includeと混同されやすいextendとの違いを確認していきます。
extendの基本的な意味
extendは、あるユースケースが特定の条件を満たしたときだけ、別のユースケースに拡張される関係を示します。
日本語では「拡張関係」と呼ばれることが多く、オプション的な処理を表現するために用いられます。
たとえば、「注文を確定する」というユースケースにおいて、「ポイントを使用する」という処理は、ユーザーがポイントを持っている場合にのみ実行されます。
このような任意・条件付きの拡張処理を表すのがextendの役割です。
includeとextendの比較表
includeとextendの主な違いを整理すると、以下のようになります。
| 項目 | include（包含） | extend（拡張） |
|---|---|---|
| 実行タイミング | 必ず実行される | 条件を満たした場合のみ実行 |
| 矢印の向き | 呼び出し元 → 呼び出し先 | 拡張側 → 基本ユースケース |
| ステレオタイプ | «include» | «extend» |
| 主な用途 | 共通処理の切り出し | オプション処理の追加 |
| 依存関係 | 呼び出し元が呼び出し先に依存 | 拡張側が基本側に依存 |
このように、実行が必須かどうかという点が最大の違いといえるでしょう。
extendの記述方法と注意点
extendの矢印の向きは拡張する側（オプション処理）から基本ユースケースへ向かいます。
includeとは矢印の向きが逆になるため、混同しないよう注意が必要です。
記述例：「ポイントを使用する」 ──«extend»──→ 「注文を確定する」
「ポイントを使用する」は条件によって実行される拡張処理であり、基本ユースケース「注文を確定する」に向けて矢印を引きます。
「拡張条件（extension point）」を明記することで、どのような条件のときに拡張処理が実行されるかをより明確に表現できます。
汎化との違いと使い分け方
続いては、includeやextendと並んでよく登場する汎化（generalization）との違いと使い分けを確認していきます。
ユースケース図における汎化とは
汎化とは、ユースケース同士、またはアクター同士の継承関係を表す概念です。
オブジェクト指向の「継承」に相当するもので、より汎用的な親ユースケース（または親アクター）と、それを具体化した子ユースケース（または子アクター）の関係を示します。
たとえば、「支払いをする」という親ユースケースに対して、「クレジットカードで支払う」「銀行振込で支払う」という子ユースケースが存在するケースが典型例です。
汎化はinclude・extendとは異なり、ユースケースの「種類の関係」を表します。
「AはBの一種である」という is-a 関係を示すものが汎化です。
include・extend・汎化の三者比較
include、extend、汎化の3つの関係は、それぞれ使うべき場面が異なります。
| 関係 | 表す内容 | 使用場面 |
|---|---|---|
| include（包含） | 必ず実行される共通処理 | 重複する処理を切り出したいとき |
| extend（拡張） | 条件付きのオプション処理 | 任意の処理を追加したいとき |
| 汎化 | ユースケースの継承関係 | 処理の種類を整理・分類したいとき |
この3つを使い分けることで、UMLユースケース図の表現力が大きく向上します。
実務での使い分けのポイント
実務の設計では、以下のような判断フローが使い分けの基準となるでしょう。
「その処理は必ず実行される？」→ Yes → include を使う
「その処理は条件によって実行が変わる？」→ Yes → extend を使う
「その処理は別のユースケースの特殊版？」→ Yes → 汎化を使う
迷ったときは「実行の必然性」「条件性」「種類の関係」という3つの観点で整理すると、適切な関係を選択しやすくなります。
また、includeを多用しすぎると図が複雑になるため、共通化の粒度には注意が必要です。
ユースケース図を正しく描くためのポイント整理
続いては、ユースケース図全体を正しく描くためのポイントを確認していきます。
アクターとユースケースの関係を整理する
ユースケース図を描く際、まず明確にすべきなのはアクター（登場人物・外部システム）とユースケースの関係です。
アクターは「誰がそのシステムを使うのか」を表し、ユースケースは「システムが提供する機能」を表します。
include・extend・汎化などの関係は、この基本的な構造を整理した上で加えていくのが正しい手順といえるでしょう。
先に関係性ありきで設計を進めると、全体の整合性が崩れてしまうため注意が必要です。
よくあるミスとその対策
ユースケース図でよく見られるミスには以下のようなものがあります。
まず、includeとextendの矢印方向を逆に描いてしまうケースが非常に多いです。
includeは「呼び出す側から呼び出される側へ」、extendは「拡張する側から基本ユースケースへ」という矢印の向きをしっかり覚えておきましょう。
また、「条件付きの処理なのにincludeを使ってしまう」という誤りも頻繁に見られます。
矢印の向きを覚える際は、includeは「使う側 → 使われる側」、extendは「追加処理 → 基本処理」という方向で覚えておくと混乱しにくいです。
ユースケース図の品質を高めるコツ
ユースケース図の品質を高めるためには、1つのユースケースに詰め込みすぎないことが大切です。
ユースケースは「ユーザーが達成したい目標」単位で切り出すのが基本であり、処理の詳細はユースケース記述（テキスト）として別途まとめる方法が有効です。
また、関係の種類（include・extend・汎化・関連）を使いすぎると図が読みにくくなるため、本当に必要な関係のみを描くというシンプルさも重要な観点です。
設計の目的や読み手を常に意識しながら、過不足なく情報を表現することがユースケース図の品質向上につながるでしょう。
まとめ
本記事では、ユースケース図のinclude（包含関係）の意味と記述方法、extendとの違い、さらに汎化との使い分けについて詳しく解説しました。
includeは「必ず実行される共通処理」を切り出す関係であり、extendは「条件付きのオプション処理」を表す関係です。
汎化は継承関係を示すものであり、この3つはそれぞれ使い分けることで、UMLユースケース図の表現力を最大限に発揮できます。
矢印の向きや使う場面を整理した上で、実際の設計に活かしていきましょう。
UMLをしっかり使いこなすことで、システム設計の精度とチーム内のコミュニケーション品質が大きく向上するはずです。
ぜひ本記事を参考に、ユースケース図の理解を深めてみてください。
