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

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

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

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

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

作図はコードで持てます。PlantUMLは公式ドキュメントにユースケース図専用の記法（actor／usecase／rectangle）を持ち、本記事にはコピーしてそのまま描画できる例を載せました。一方Mermaidには2026年9月時点で専用のユースケース図が無く、flowchartでの代用になります。この差を知らずにツールを選ぶと、途中で記法を書き直す羽目になります。

ユースケース図は要件定義の初期に効きます。発注者と開発者が、機能の抜けと範囲を短時間で突き合わせられるからです。反面、粒度を誤ると使えない図になります。どの場面で書き、どの場面で書かないかまで、条件付きで言い切ります。

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

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

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

ユースケース図は、UML（Unified Modeling Language）で定義された振る舞い図の一種で、システムに対する機能要求を利用者の目線で表します。UMLの仕様を管理しているのはOMG（Object Management Group）で、UML仕様のバージョン一覧を見ると、正式版の最新は2017年12月発行の2.5.1系です。2.4.1系以降で図の分類が整理され、ユースケース図は振る舞い図の側に置かれています（UML 2.5.1の仕様ページで本文PDFを取得できます）。狙いは、実装の詳細に入る前に「このシステムで何ができるべきか」を関係者全員で合意することです。誰がどの機能を使うのかが一目で分かるため、要求の抜けや、想定していなかった利用者の存在に早い段階で気づけます。フローチャートとは目的が異なり、処理の手順は表しません。

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

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

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

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

「ユースケース」という言葉が指す範囲と、ユースケース記述との関係

検索で「ユースケース」とだけ引くと、UMLの用語と、一般語としての「適用場面・利用シーン」が混ざって出てきます。UMLの文脈でのユースケースは、アクターがシステムを使って達成したい目的の単位を指し、図の上では楕円1つに対応します。図が担うのは一覧性だけです。各ユースケースの中身、つまり事前条件・基本フロー・代替フロー・事後条件は、文章で書く「ユースケース記述（ユースケースシナリオ）」の担当になります。UML仕様上もUseCaseは振る舞いを持つ分類子として定義されており、楕円の記法は表現手段の一つにすぎません。実務で起きる偏りは2種類で、図だけ描いて記述を書かないか、記述だけ書いて全体像を持たないかのどちらかです。語そのものの二つの意味と、記述に書く7項目の書式はユースケースとは何かをUML仕様と記述の書き方から整理した解説にまとめています。判断基準を置くなら、関係する部署が3つ以上またがるなら図から入り、利用者が単一で機能が10未満なら記述だけで足ります。記述を起点に堅牢性分析へつなぐ手法はユースケース駆動開発（ICONIX）の4工程で扱っており、上流の全体像は要件定義の目的・進め方と成果物にまとめました。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

最初のアクター洗い出しで手を抜くと、後工程まで抜けが響きます。「管理者」「運用担当」のように立場で分けて考えると、見落としていた利用者が見つかるはずです。

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

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

作成したユースケース図をレビューする観点と、抜けを見つける確認手順

描き終えた図は、作成者以外の目を1回通します。点検する観点は次の5つに絞れます。

• アクター漏れ：運用担当・保守要員・バッチ起動のスケジューラが枠の外にいるか
• 命名：ユースケース名がアクターの目的になっているか（手段名になっていないか）
• 境界：外部サービス側が持つ機能を、枠の内側に描き込んでいないか
• 関係：include と extend を「消しても基本が成立するか」で再判定したか
• 枚数：1枚10前後を超えていないか、超えたなら業務単位で分割したか

効くのは声に出す確認です。「購入者は商品を検索する」と読み上げて意味が通らない線は、粒度か命名のどちらかが壊れているサインです。レビューの場に業務側の担当者を1人入れておくと、開発側だけでは気づけない例外業務が出てきます。ここで拾えなかった抜けは、外部設計以降で仕様変更として跳ね返るため、図の段階で時間を使ったほうが安く済みます。

PlantUMLでユースケース図をコード化する手順と実行できる記法例

作図ツールで描いた図は、仕様変更のたびに手作業での修正が必要です。テキストから図を生成すればGitで差分が取れ、レビューにも乗ります。ユースケース図を書けるテキスト記法として実用段階にあるのがPlantUMLで、PlantUML公式のユースケース図ドキュメントに記法の一覧が載っています。

PlantUMLでアクター・ユースケース・システム境界を書く記法

次のコードはそのままコピーして描画できます。actor が棒人間、usecase が楕円、rectangle がシステム境界に対応し、skinparam packageStyle rectangle で枠線の見た目をそろえます。

@startuml
left to right direction
skinparam packageStyle rectangle

actor "購入者" as customer
actor "決済代行API" as payment_gw

rectangle "ECサイト" {
  usecase "商品を検索する" as UC1
  usecase "注文する" as UC2
  usecase "ログイン認証する" as UC3
  usecase "クーポンを適用する" as UC4

  customer -- UC1
  customer -- UC2
  UC2 ..> UC3 : <<include>>
  UC4 ..> UC2 : <<extend>>
  UC2 -- payment_gw
}
@enduml

実線の -- が関連、破線の ..> にラベルを添えたものが包含と拡張です。矢印の向きが include と extend で逆になっている点を、コード上で見比べると意味が定着します。left to right direction を外すと縦並びになるため、アクターが多い図では入れたままにします。導入方法や .puml 拡張子の扱いはPlantUMLの記法・インストールと使い方で解説しました。

Mermaidでユースケース図を描けるかと、代替になる図の選び方

ここは誤解が多いところです。Mermaid公式のダイアグラム一覧にユースケース図は含まれていません。専用ダイアグラムの追加要望はGitHubのissue 4628として挙がっていますが、2026年9月時点で本体には取り込まれていません。レンダラーの実装は構文案が複数並行して出ており、いずれも未マージのまま議論が続いています。つまり現時点でMermaidに寄せるなら、flowchartで近似することになります。

flowchart LR
  customer(("購入者"))
  subgraph EC["ECサイト"]
    UC1(["商品を検索する"])
    UC2(["注文する"])
    UC3(["ログイン認証する"])
  end
  customer --- UC1
  customer --- UC2
  UC2 -. include .-> UC3

スタジアム形 ([...]) で楕円を、subgraph でシステム境界を代用しています。棒人間の記号とステレオタイプ表記は出せないため、UML記法どおりの図を仕様書の正として残すならPlantUML、READMEに軽く添えるだけならMermaid、という切り分けが実務的です。Mermaidの記法そのものはMermaid記法の使い方とLive Editorでの試し方にまとめています。

作った図をGitで版管理する運用と、レビューで差分を追う手順

.puml や Markdown をリポジトリに置くと、図の変更が行単位の差分として見えます。アクターが1人増えたのか、include の指す先が変わったのかは、プルリクエストの画面で判別可能です。画像はCIで生成し、レビューはテキストで行い、配布物としてだけ画像を出す、という分担にすると図と仕様のずれが起きにくくなります。運用で決めておくべきは3点で、記法ファイルの置き場所、図を更新する責任者、そして仕様変更時に図を先に直すのか実装を先に直すのかの順番です。テキストで設計図を持つ発想はユースケース図に限らず、データ連携図とDFDの粒度・記法でも同じやり方が使えます。

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

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

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

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

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

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

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

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

よくある質問

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

ユースケースとユースケース図は何が違いますか？

ユースケースは、アクターがシステムを使って達成したい目的の単位そのものを指します。ユースケース図は、そのユースケースとアクターの結びつきを1枚に並べた図です。図が示すのは一覧と範囲だけで、各ユースケースの事前条件や基本フロー・代替フローは、文章のユースケース記述に書きます。図と記述はセットで使うもので、どちらか一方では設計の入力になりません。

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

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

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

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

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

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

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

作図に特化したLucidchartやdraw.io、Miro、Visioなどで描けるほか、テキストから図を生成するPlantUMLも使えます。Mermaidは2026年9月時点でユースケース図の専用ダイアグラムを持たず、flowchartでの近似になるため、UML記法どおりに残したい場合はPlantUMLが選択肢です。仕様変更が頻繁で版管理と併せて運用したいならテキスト系、見た目を細かく整えたいならGUIの作図ツールが扱いやすくなります。

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

書けません。処理の順序や条件分岐の流れは表現の対象外で、アクティビティ図やシーケンス図の担当になります。

関連記事

• クラス図とは：ユースケースの内部構造を静的に表すUML図の書き方
• シーケンス図とは：各ユースケースの処理の流れを時間軸で追う図
• ユースケース駆動開発とは：ユースケース記述から設計へ落とすICONIXの4工程
• PlantUMLとは：ユースケース図をテキストで書くための記法とインストール
• 状態遷移図とは：機能ではなく状態が主役になる場面で使う図の書き方