ユースケース図とは？UMLの書き方・アクターと関係・要件定義での使い方を解説

ユースケース図とは、システムに対して「誰が」「何をしたいのか」を、利用者の目線で一枚に描き出すUMLの図です。細かい画面や処理には踏み込まず、システムが外部へ提供する機能の範囲を、アクターとユースケースの線でつないで表します。この記事では、ユースケース図の定義と4つの構成要素、関連・包含・拡張・汎化という関係の使い分け、アクターの洗い出しから粒度調整までの作成手順、MermaidやPlantUMLでコードとして管理する方法、そして要件定義工程で使うべき場面と書かない判断までを、設計と実装の現場視点で整理します。

まとめ：ユースケース図の要素・書き方と要件定義での役割

ユースケース図の芯は、システムの内部構造ではなく「外から見た機能の輪郭」を合意するための道具だという点にあります。アクター（利用者や外部システム）とユースケース（機能）を線で結び、システム境界という枠で「どこまでがこのシステムの責任か」を示します。処理の順序やデータ構造は描きません。それは別の図の担当です。

関係の種類は4つ覚えれば足ります。基本の関連、共通処理をくくり出す包含、条件付きで足される拡張、そして似たアクターやユースケースをまとめる汎化です。実務でつまずくのは包含と拡張の取り違えで、本記事では「必ず起きるか、条件付きか」で切り分ける判断基準を示します。

ユースケース図は要件定義の初期に効きます。発注者と開発者が、機能の抜けと範囲を短時間で突き合わせられるからです。反面、粒度を誤ると使えない図になります。1機能を細かく割りすぎた図、逆にシステム全体を1つの楕円で描いた図は、どちらも合意の役に立ちません。どの場面で書き、どの場面で書かないかまで、条件付きで言い切ります。

ユースケース図とは何か：UMLにおける定義と4つの構成要素の意味

まず言葉の範囲をそろえます。ユースケース図は、システムが利用者に提供する機能を、利用者の視点で外側から捉える図です。プログラムの内部ではなく「システムと外部との接点」を描く点が、他のUML図と分かれる出発点になります。

ユースケース図の定義と、アクター視点でシステム要求を表す狙い

ユースケース図は、UML（Unified Modeling Language）で定義された振る舞い図の一種で、システムに対する機能要求を利用者の目線で表します。狙いは、実装の詳細に入る前に「このシステムで何ができるべきか」を関係者全員で合意することです。たとえばECサイトなら、購入者が「商品を検索する」「注文する」、管理者が「在庫を登録する」といった機能を、線で結んだ楕円として並べます。誰がどの機能を使うのかが一目で分かるため、要求の抜けや、想定していなかった利用者の存在に早い段階で気づけます。プログラムのフローチャートとは目的が異なり、処理の手順は表しません。

ユースケース図を構成する4要素（アクター・ユースケース・システム境界・関係）

ユースケース図は、次の4つの要素で組み立てます。記法はシンプルで、要素の意味さえ押さえれば読み書きに迷いません。

• アクター：システムを使う人や外部システム。棒人間の記号で、システム境界の外側に置く
• ユースケース：システムが提供する機能。楕円の中に動詞で書く（「商品を検索する」など）
• システム境界：対象システムの範囲を示す四角い枠。枠の内側がシステムの責任範囲になる
• 関係：アクターとユースケース、あるいはユースケース同士を結ぶ線

アクターは人間だけではありません。決済代行や外部APIといった、システムとやり取りする他システムもアクターとして枠の外に描きます。この「境界の外に利用者、内に機能」という配置そのものが、どこまでを作るのかという合意を可視化します。

UMLの図の中でユースケース図が担う役割と、クラス図・シーケンス図との違い

UMLには十数種類の図がありますが、開発の現場で頻出するのはユースケース図・クラス図・シーケンス図の3つです。役割が重ならないよう、担当を分けて使います。ユースケース図は「何ができるか（機能の輪郭）」、クラス図は「何でできているか（静的な構造）」、シーケンス図は「どう動くか（時間軸の相互作用）」を表します。ユースケース図で機能を洗い出し、その内部をクラス図で構造化し、個々の機能の処理の流れをシーケンス図で追う、という順で詳細化していくのが典型的な流れです。オブジェクト指向でシステムを設計する土台についてはオブジェクト指向のカプセル化・継承・ポリモーフィズムの考え方が下敷きになります。図の種類ごとの役割分担は、システムの全体像を描くシステム構成図の種類と書き方の観点とも通じます。

ユースケース図の関係の種類：関連・包含・拡張・汎化の使い分け

ユースケース図で表現に差が出るのは、線の引き方です。4種類の関係を正しく使い分けられると、図が要求の構造を語り始めます。逆に取り違えると、読み手を混乱させる図になります。

関連（association）と包含（include）で共通処理をまとめる書き方

関連は、アクターとユースケースを結ぶ最も基本の線で、単純な実線で引きます。「購入者」と「商品を検索する」を線で結べば、その利用者がその機能を使うという事実を表します。包含（include）は、複数のユースケースに共通して含まれる処理を、独立したユースケースとしてくくり出す関係です。破線の矢印に <<include>> と添え、矢印の先が共通処理を指します。たとえば「注文する」も「定期購入を設定する」も、どちらも内部で「ログイン認証する」を必ず通るなら、認証を別のユースケースに切り出し、両方から include で結ぶのがこの関係の使い方です。同じ処理を何度も描かずに済み、後から認証手順が変わっても1箇所の修正で足ります。判断の目安は「その処理が呼び出し元で必ず実行されるか」です。必ず通るなら include が向きます。

拡張（extend）と汎化（generalization）で条件分岐と抽象化を表す書き方

拡張（extend）は、特定の条件が成立したときにだけ追加される、任意の処理を表す関係です。破線の矢印に <<extend>> と添え、矢印の向きは include と逆で、追加側から基本のユースケースを指します。「注文する」に対して「クーポンを適用する」を extend で結ぶと、クーポンを持つ利用者のときだけ差し込まれる機能だと表せます。基本の流れはクーポンが無くても完結する、という点が include との決定的な違いです。汎化（generalization）は、似たアクターやユースケースを親子関係でまとめる抽象化です。「一般会員」と「プレミアム会員」を「会員」から汎化で派生させれば、共通する機能を親に持たせ、差分だけを子に描けます。中実の三角矢印で親を指す点が他の関係と見分けるしるしです。

include と extend を取り違えないための判断基準

初学者がもっとも迷うのが include と extend の区別です。矢印の向きと「必ず起きるか、条件付きか」の2軸で切り分けると、迷いが消えます。次の表で対比します。

迷ったら「この処理を消したとき、基本のユースケースは成り立つか」を自問します。成り立たないなら include、成り立つなら extend です。なお実務では、無理に include や extend を多用せず、まず関連だけで全体像を描き、共通化や条件分岐が明らかな箇所にだけ足すのが読みやすさを保つ書き方です。

ユースケース図の書き方：アクター洗い出しから粒度調整までの手順

要素と関係を押さえたら、実際に描く手順に移ります。順番を守ることが、抜けの少ない図への近道です。ここでは作成の流れと、現場で差が出る粒度の決め方、そしてコードで管理する方法までを扱います。

アクターとユースケースを洗い出す5つのステップと作成手順の流れ

ユースケース図は、次の5ステップで組み立てると過不足がありません。上流から順に確定させ、いきなり細部から描き始めないのがこつです。

1. アクターを洗い出す：システムを使う人・役割・外部システムをすべて挙げる
2. ユースケースを列挙する：各アクターが「システムで何をしたいか」を動詞で書き出す
3. システム境界を引く：対象システムの範囲を枠で囲み、内外を仕分ける
4. 関係を結ぶ：アクターと機能を関連で結び、共通処理や条件分岐に include/extend を足す
5. 粒度を調整する：機能の大きさをそろえ、細かすぎ・粗すぎを直す

最初のアクター洗い出しで手を抜くと、後工程まで抜けが響きます。「管理者」「運用担当」のように立場で分けて考えると、見落としていた利用者が見つかるはずです。時間の流れや外部イベントを起点にするアクター（バッチ実行の契機となるスケジューラなど）も忘れずに拾います。

ユースケースの粒度をそろえる基準と、細かすぎ・粗すぎの見極め

ユースケース図の出来を決めるのは、機能の粒度です。粗すぎる図の典型は、システム全体を「ECサイトを運営する」の一つの楕円で描いてしまうもので、これでは要求を語れません。細かすぎる図は逆に、「ボタンを押す」「文字を入力する」といった画面操作まで楕円にしてしまい、数十個のユースケースで埋め尽くされて全体像が消えます。目安は「利用者が達成したい一つの目的で区切る」ことです。「商品を注文する」は目的になりますが、その中の「住所を入力する」は手段なので、ユースケースには上げません。1枚の図に載せるユースケースは、おおむね10前後までに収めると読みやすさが保てます。増えすぎたら、アクターや業務のまとまりで図を分割します。

MermaidやPlantUMLでユースケース図をコードとして管理する方法

作図ツールで描いた図は、仕様変更のたびに手作業で直す手間がかかります。バージョン管理と相性がよいのが、テキストから図を生成するツールです。PlantUMLは (商品を検索する) のような記法でユースケースを、:購入者: でアクターを書き、Gitでdiffを取りながら管理できます。より軽量な選択肢がMermaidで、Markdown内に図の定義を埋め込め、GitHubやドキュメントツールでそのまま描画されるのが強みです。図をコードで持てば、レビューで変更点を追え、実装と仕様のずれを抑えられます。Mermaidの具体的な記法とLive Editorでの試し方はMermaid記法の使い方とシーケンス図・フローチャートの作成にまとめました。ツールで描く前に、まず要素と関係の意味を理解しておくと、生成される図の善し悪しを判断できます。

要件定義でユースケース図を使う判断と、書くべきでない場面の見極め

ここからは立場を明確にします。ユースケース図は万能の図ではありません。効く工程と場面があり、逆に描くこと自体が無駄になる状況もあります。どちらかを見極める基準を、具体的な条件で示します。

要件定義・システム設計工程でユースケース図が効く場面と、成果物としての扱い

ユースケース図がもっとも力を発揮するのは、要件定義の初期です。発注者と開発者が、システムの機能範囲と利用者を短時間で突き合わせられます。文章だけの要件一覧では見落とす「この利用者のこの機能が抜けている」を、線のつながりが抜けを浮かび上がらせるからです。要件定義から外部設計・内部設計へ進む流れの中で、ユースケース図は後工程の入力になります。ユースケースごとに画面や処理を割り当てていく設計は、抜け漏れを先に潰せる進め方です。工程全体のどこに設計成果物を置くかはシステム開発の工程と7フェーズの成果物の全体像が判断の土台で、要件定義の次に来る設計工程の詳細は外部設計と内部設計の違い・成果物で扱っています。本記事は、その工程で使うモデリング手法そのものを掘り下げる役割です。

ユースケース図を書かない方がよい場面と、ありがちな失敗パターン

ユースケース図を描くべきでない場面もはっきりあります。第一に、機能がごく少ない小規模ツールや、利用者が単一で機能の輪郭が自明なケースです。1アクター・数機能なら、箇条書きの機能一覧のほうが速く正確に伝わります。第二に、内部のデータ処理やバッチ計算が主役のシステムです。利用者との接点が薄い処理は、ユースケース図では表現しきれず、アクティビティ図やシーケンス図が向きます。ありがちな失敗は3つあります。粒度を細かくしすぎて画面操作の羅列になる、include と extend を飾りのように多用して読めなくする、そして図を作ること自体が目的化し、合意形成に使われないまま放置される、というものです。三つに共通するのは、利用者が何をしたいかという原点を見失っている点にあります。図は合意の道具であって、成果物を揃えるための儀式ではありません。

受託開発で業務要求をユースケースへ落とし込む要件定義体制の作り方

ユースケース図が真価を発揮するのは、業務システムや基幹システムのように、複数の部署と役割が絡む開発です。誰がどの機能を使うのかを図で合意しておかないと、後工程で「その業務が抜けていた」という手戻りが起きます。とはいえ、現場の業務を漏れなくユースケースへ落とし込むには、業務ヒアリングとモデリングの両方の経験が要る仕事です。社内に要件定義を主導できる人材がいない、既存の業務フローが複雑で機能の切り出しに迷う、といった場面では、外部の伴走が歯止めになります。一創では基幹システム開発として、業務要求をユースケースや業務フローへ整理する要件定義から、設計・実装・運用までを一貫して支援しています。図を描く技術だけでなく、業務の当事者から要求を引き出す進め方まで含めた伴走が一創の強みです。

よくある質問

ユースケース図の理解と実務でつまずきやすい点を、5つの質問に絞って整理します。

ユースケース図とアクティビティ図の違いは何ですか？

両者は表す対象が異なります。ユースケース図は「システムが誰にどんな機能を提供するか」という機能の輪郭を、静的に描く図です。アクティビティ図は「その機能がどんな順序で処理されるか」という作業や処理の流れを、時間軸に沿って表します。まず何ができるかをユースケース図で洗い出し、個々の処理の流れをアクティビティ図で詳細化する、という補完関係で使うと整理できます。

ユースケース図のアクターは人間だけですか？

いいえ、人間に限りません。アクターは「システムと外部からやり取りする存在」を指すため、決済代行サービスや外部API、定期実行のスケジューラといった他システムもアクターになります。システム境界の外側でシステムと相互作用するものは、人でも機械でもアクターとして棒人間の記号で描きます。

include と extend はどちらを使えばよいですか？

その処理が基本の流れで必ず実行されるなら include、特定の条件下でのみ追加されるなら extend を使います。判断に迷ったら「その処理を消しても基本のユースケースが成立するか」を確かめてください。成立しないなら必須の処理なので include、成立するなら任意の処理なので extend が適切です。無理にどちらかへ当てはめず、まず関連だけで描くのも一つの方法です。

ユースケース図はどのツールで作成できますか？

作図に特化したLucidchartやdraw.io、Miro、Visioなどで描けるほか、テキストから図を生成するPlantUMLやMermaidも使えます。仕様変更が頻繁でバージョン管理と併せて運用したい場合は、コードで管理できるPlantUMLやMermaidが候補です。図の見た目を細かく整えたい場合は、GUIの作図ツールのほうが扱いやすくなります。

ユースケース図に処理の順序は書けますか？

書けません。ユースケース図は「何ができるか」を表す図で、処理の順序や条件分岐の流れは表現の対象外です。処理の順序を表したい場合はアクティビティ図やシーケンス図を使います。ユースケース図で機能を洗い出し、その中身の流れは別の図で詳細化する、という役割分担が基本です。

関連記事

• システム開発の工程とは：ユースケース図を作る要件定義がどの工程に位置づくかの全体像
• 外部設計とは：ユースケース図の次に来る設計工程の成果物と承認観点
• システム構成図とは：システムの全体像を表す別種の図の書き方と使い分け
• オブジェクト指向とは：UMLでのモデリングの土台となる設計の考え方
• Mermaid記法の使い方：ユースケース図やシーケンス図をコードで描く手法