ユースケース図とは？書き方・構成要素・具体例と要件定義での活用法を解説

「ユースケース図の書き方がわからない」「要件定義でどう活用すればよいか悩んでいる」という声は、システム開発の現場で少なくありません。

ユースケース図は、システムの利用者（アクター）と、システムが提供する機能（ユースケース）の関係を視覚的に整理するUMLの図です。要件定義の初期段階でクライアントや開発チームとの認識合わせに使われることが多く、ITの専門知識がない関係者にも理解しやすい点が特徴です。

本記事では、ユースケース図の定義と構成要素、書き方の5ステップ、ECサイトや勤怠管理システムでの具体例、メリットと注意点、そして要件定義での活用ポイントまでを体系的に解説します。

確認したいポイント	結論	詳細
ユースケース図とは？	利用者とシステム機能の関係を示す図	UMLの振る舞い図の一つで、アクター（利用者）とユースケース（機能）の関係を視覚的に整理します。
構成要素は？	アクター・ユースケース・関連線など	棒人間で表すアクター、楕円で表すユースケース、システム境界、関連線、Include、Extendで構成されます。
どの場面で使うのか？	要件定義フェーズが中心	システム開発の初期段階で、機能要件の整理やクライアントとの認識合わせに活用されます。
書き方の手順は？	5つのステップで作成できる	システム範囲の決定→アクター洗い出し→ユースケース洗い出し→関連線→Include/Extendの順で作成します。

この記事でわかること

・ユースケース図の定義とUMLにおける位置づけ

・アクター・ユースケース・Include・Extendなどの構成要素

・ユースケース図を作成する5つのステップと具体例

・要件定義フェーズでの効果的な活用方法

・作成時に陥りやすい間違いとその対策

システム開発の要件定義や外注でお悩みの方は、まずは無料相談をご利用ください。 ▶ 相談予約はこちら

ユースケース図とは？定義とUMLにおける位置づけ

ユースケース図とは、利用者の視点からシステムがどのように使われるかを表した図です。システムが持つ機能（ユースケース）と、その機能を利用する人や外部システム（アクター）の関係をシンプルな記号で描くことで、システムの全体像を把握しやすくします。

たとえば、ECサイトであれば「顧客」というアクターが「商品を検索する」「商品を購入する」といったユースケースとつながり、「管理者」は「商品を登録する」「在庫を管理する」などのユースケースとつながります。このように「誰が何をするのか」を一目で理解できる点がユースケース図の強みです。

UMLの振る舞い図としての位置づけ

ユースケース図は、UML（Unified Modeling Language：統一モデリング言語）に含まれる13種類の図の一つです。UMLは、ソフトウェアの設計や仕様を統一的な記法で表現するための国際標準（ISO/IEC 19501）であり、日本工業規格（JIS X 4170）にも採用されています。

UMLの図は大きく「構造図」と「振る舞い図」に分かれます。クラス図やオブジェクト図がシステムの静的な構造を表すのに対し、ユースケース図はシステムの動的な振る舞い（＝どのように利用されるか）を表す振る舞い図に分類されます。

出典：IPA（独立行政法人 情報処理推進機構）ソフトウェアエンジニアリング

ユースケース図の構成要素

ユースケース図は、限られた種類の記号だけで作成できるため、他のUML図と比べて習得しやすい図です。ここでは、基本となる構成要素とその役割を整理します。

構成要素	記号	役割
アクター	棒人間（スティックマン）	システムを利用する人や外部システムを表す。システムの外側に配置する
ユースケース	楕円形	システムが提供する機能や振る舞いを表す。動詞を含む名称で記述する
サブジェクト	長方形（システム境界）	システムの範囲を示す枠。ユースケースを囲み、対象範囲を明確にする
関連（Association）	実線	アクターとユースケースの間の基本的なつながりを表す
包含（Include）	破線矢印＋<<include>>	あるユースケースが別のユースケースを必ず含む関係を表す
拡張（Extend）	破線矢印＋<<extend>>	特定の条件下で追加実行されるユースケースを表す
汎化（Generalization）	白三角矢印の実線	アクターやユースケースの継承（親子）関係を表す

アクター（利用者や外部システム）

アクターは、システムの外部に存在し、システムと相互作用する人や外部システムを表します。棒人間（スティックマン）の記号で描かれ、システム境界の外側に配置します。

アクターは必ずしも「人」とは限りません。たとえば、決済システムと連携する「外部決済API」や、定期的にデータを送信する「バッチ処理システム」もアクターになり得ます。アクターを正確に特定することが、ユースケース図の品質を左右します。

ユースケース（システムの機能）

ユースケースは、アクターから見たシステムの機能や振る舞いを表します。楕円形の記号で描き、内部に機能名を記述します。

ユースケースの名称は「商品を検索する」「注文を確定する」のように、動詞を含む表現で記述するのが基本です。「検索機能」「注文処理」のように名詞だけで書くと、アクターの目的が伝わりにくくなるため注意しましょう。

Include（包含）とExtend（拡張）の違い

ユースケース間の関係を表す記法として、Include（包含）とExtend（拡張）があります。

Includeは「あるユースケースが別のユースケースを必ず含む」関係です。たとえば「商品を注文する」ユースケースが「認証を行う」ユースケースを必ず含む場合、<<include>>の破線矢印でつなぎます。共通処理を切り出して再利用する際に使います。

Extendは「特定の条件下でのみ実行される追加機能」を表します。たとえば「商品を検索する」ユースケースに対して、条件付きで「詳細フィルタを適用する」ユースケースが実行される場合、<<extend>>でつなぎます。必須ではなくオプションの機能を表現するときに使います。

AI導入やシステム開発に関する詳しいサービス内容は、資料でご確認いただけます。 ▶ 資料請求はこちら

ユースケース図の書き方｜5つのステップ

ユースケース図は、以下の5つのステップで作成できます。ここでは「図書館の蔵書管理システム」を例に、各ステップを解説します。

ステップ1：システムの範囲を決める

最初に、ユースケース図で表現するシステムの範囲（スコープ）を決定します。長方形でシステム境界を描き、上部にシステム名を記載します。「蔵書管理システム」であれば、貸出・返却・蔵書検索はスコープ内、会計処理はスコープ外といった線引きを行います。

ステップ2：アクターを洗い出す

次に、システムを利用する人や外部システムを洗い出します。図書館の例であれば「利用者」「図書館員」「管理者」がアクターとして挙がります。外部の書誌データベースと連携する場合は、そのシステムもアクターになります。

アクターの洗い出しでは、「このシステムを使うのは誰か」「データを送受信する外部システムはあるか」という問いを軸に整理すると、漏れが防ぎやすくなります。

ステップ3：ユースケースを洗い出す

各アクターがシステムを使って達成したい目的（＝ユースケース）を洗い出します。「利用者」であれば「蔵書を検索する」「本を借りる」「本を返す」「予約する」、「図書館員」であれば「貸出処理をする」「返却処理をする」「蔵書を登録する」などが挙がります。

このとき重要なのは、ユースケースの粒度（細かさの度合い）を揃えることです。「本を借りる」と「バーコードをスキャンする」が同列に並ぶと粒度がバラバラになり、図が読みにくくなります。

ステップ4：アクターとユースケースを関連線で結ぶ

アクターとユースケースを実線で結び、「どのアクターがどの機能を使うか」を表現します。1つのアクターが複数のユースケースに関連することも、1つのユースケースに複数のアクターが関連することもあります。

ステップ5：IncludeとExtendを整理する

最後に、ユースケース間にInclude（包含）やExtend（拡張）の関係があれば追加します。たとえば「本を借りる」と「本を返す」がともに「利用者を認証する」処理を含む場合、「利用者を認証する」を独立したユースケースとして切り出し、<<include>>で結びます。

すべてのユースケースにInclude/Extendを設定する必要はありません。共通処理の再利用やオプション機能の表現に必要な場合だけ使うのがポイントです。無理にInclude/Extendを増やすと、図がかえって複雑になります。

ユースケース図の具体例｜ECサイトと勤怠管理システム

ここでは、実務でよく登場する2つのシステムを題材に、ユースケース図の具体的な構成を紹介します。

ECサイトのユースケース図

ECサイトを例にすると、アクターとユースケースは以下のように整理できます。「顧客」は「商品を検索する」「カートに追加する」「注文を確定する」「注文履歴を確認する」、「管理者」は「商品を登録する」「在庫を管理する」「売上レポートを確認する」といったユースケースを持ちます。

Include関係の例としては、「注文を確定する」が「決済処理を行う」を必ず含むケースが挙げられます。Extend関係の例としては、「商品を検索する」に対して「詳細フィルタで絞り込む」が条件付きで実行される場合があります。

また、外部の「決済サービス」をアクターとして追加し、「決済処理を行う」ユースケースと関連線で結ぶことで、外部連携も図上で表現できます。

勤怠管理システムのユースケース図

勤怠管理システムでは、「社員」「承認者（上長）」「人事管理者」がアクターとなります。「社員」は「勤怠を入力する」「休暇を申請する」「打刻を修正する」、「承認者」は「勤怠を承認する」「休暇申請を承認する」、「人事管理者」は「勤怠データを集計する」「就業ルールを設定する」といったユースケースを持ちます。

Include関係としては、「勤怠を入力する」に「入力内容を検証する（バリデーション）」が含まれるケースが典型的です。Extend関係としては、「勤怠を入力する」に対して「打刻忘れの補足入力をする」が条件付きで追加されるケースがあります。

勤怠管理システムのように、アクターの種類が多く権限が異なる場合は、アクターごとにアクセスできるユースケースを明確に分けることが重要です。権限の整理が不十分なまま開発を進めると、後工程でセキュリティ上の問題が発覚する原因になります。

システム開発の要件定義や外注でお悩みの方は、まずは無料相談をご利用ください。 ▶ 相談予約はこちら

ユースケース図を活用するメリットと限界

ユースケース図には明確なメリットがある一方で、万能ではない点も理解しておく必要があります。

ユースケース図を使う4つのメリット

1つ目は、システムの全体像をシンプルに可視化できる点です。少ない記号で構成されるため、ITに詳しくないクライアントや経営層にもシステムの機能範囲が伝わりやすくなります。

2つ目は、要件の漏れや認識のズレを早期に発見できる点です。「このアクターにはこの機能が必要ではないか」「この機能は対象外ではないか」といった議論を、図を見ながら進められます。

3つ目は、テストケースの設計に活用できる点です。各ユースケースがそのままテスト項目のベースになるため、テスト計画の抜け漏れ防止に役立ちます。

4つ目は、ユーザー視点で要件を整理できる点です。「システムがどう動くか」ではなく「利用者が何をしたいか」を起点に要件を整理するため、実際の利用シーンに即した機能設計につながります。

ユースケース図の限界と注意すべきポイント

一方で、ユースケース図には処理の詳細な手順や分岐を表現できないという限界があります。たとえば「商品を注文する」際に在庫切れだった場合の分岐処理や、エラー時のリカバリ手順などは、ユースケース図だけでは表現しきれません。

こうした詳細な処理の流れを表現するには、ユースケース記述（テキストによる補足説明）や、シーケンス図、アクティビティ図といった別のUML図を併用する必要があります。ユースケース図はあくまで「全体像を共有するための図」であり、設計の詳細を記述する図ではない点を理解しておくことが重要です。

要件定義でユースケース図を活用するポイント

ユースケース図は、システム開発の要件定義フェーズで最も効果を発揮する図です。ここでは、要件定義での使い方と、他のUML図との使い分けについて解説します。

要件定義フェーズでの効果的な使い方

要件定義の初期段階では、クライアント自身が「どんなシステムを作りたいか」を明確にできていないケースがほとんどです。ユースケース図を使って「誰が、何を、どのシステムで行うか」を整理すると、クライアントの頭の中にある漠然としたイメージを具体化できます。

開発側にとっても、ユースケース図はシステムの機能範囲を確定させる根拠になります。図に載っていない機能は「対象外」と明確に線引きできるため、開発途中での「この機能も必要だった」というスコープクリープ（範囲の膨張）を防ぐ効果があります。

システム開発の外注を検討している方は、要件定義の進め方もあわせてご確認ください。

関連記事：要件定義の例｜システム種類別の要件例と書き換え集

他のUML図との使い分け

ユースケース図は「誰が何をするか」を俯瞰するための図であり、処理の詳細を記述するには別のUML図が必要です。以下に、代表的なUML図との使い分けを整理します。

UML図	目的	ユースケース図との違い
クラス図	システムの静的構造を表現する	ユースケース図は機能の「何を」、クラス図は構造の「どう作るか」を表す
シーケンス図	オブジェクト間のやり取りの順序を表す	ユースケース図は機能の全体像、シーケンス図は1つの処理の詳細な流れを表す
アクティビティ図	業務フローや処理の流れを表す	ユースケース図は「誰が何をするか」、アクティビティ図は「処理がどう進むか」を表す
状態遷移図	オブジェクトの状態変化を表す	ユースケース図はユーザー視点、状態遷移図はシステム内部のオブジェクト視点で記述する

実務では、要件定義フェーズでユースケース図を作成し、設計フェーズではクラス図やシーケンス図で詳細を詰めるという使い分けが一般的です。ユースケース図だけで設計まで完結させようとしないことが、品質の高い開発につながります。

AI導入やシステム開発に関する詳しいサービス内容は、資料でご確認いただけます。 ▶ 資料請求はこちら

ユースケース図を作成する際のよくある間違いと対策

ユースケース図はシンプルな図ですが、作成時にいくつかの典型的な間違いが発生しやすい点に注意が必要です。

粒度がバラバラになる

最もよくある間違いは、ユースケースの粒度（細かさ）が統一されていないことです。「商品を購入する」という大きなユースケースと「購入ボタンをクリックする」という画面操作レベルのユースケースが混在すると、図全体が読みにくくなり、全体像の把握という本来の目的が損なわれます。

対策としては、ユースケースを「アクターの目的」レベルに揃えることです。「〇〇を△△する」という形式で記述し、画面操作や内部処理は含めないようにしましょう。細かい処理を記述したい場合は、ユースケース記述やシーケンス図で補足するのが適切です。

Include・Extendを使いすぎる

IncludeやExtendを多用すると、図の線が交差して複雑になり、かえって読みにくくなります。Include/Extendは「共通処理の切り出し」や「オプション機能の明示」が必要な場合に限定し、シンプルさを保つことを優先しましょう。

アクター間の関係を描いてしまう

ユースケース図では、アクター同士の直接的なやり取りは描きません。アクターはあくまでシステムとの関係を示すものであり、アクター間の業務フローを表現したい場合はアクティビティ図やBPMN（ビジネスプロセスモデリング表記法）を使うのが適切です。

システム開発の外注先選びや進め方については、以下の記事で詳しく解説しています。

関連記事：システム開発の外注とは｜メリット・デメリット、費用相場、外注先の種類と選び方を解説

まとめ

ユースケース図は、システムの利用者と機能の関係をシンプルに可視化できるUMLの振る舞い図です。アクター・ユースケース・システム境界・関連線という少ない構成要素で作成でき、ITの専門知識がない関係者にも理解しやすい点が強みです。

書き方は5つのステップ（システム範囲の決定→アクターの洗い出し→ユースケースの洗い出し→関連線→Include/Extendの整理）に沿って進めれば、初めてでも作成できます。粒度を揃えることと、Include/Extendを使いすぎないことが、読みやすいユースケース図を作るポイントです。

ユースケース図は要件定義フェーズで最も効果を発揮しますが、処理の詳細まで表現できるものではありません。設計フェーズに入ったら、クラス図やシーケンス図と組み合わせて活用し、開発の品質を高めていきましょう