ユースケース図とは？書き方・洗い出しのコツ・いらないケースまで、実務目線で解説

要件定義の入り口でよく出てくるのが「ユースケース」です。ただ、言葉だけが先に歩いていて、「図をきれいに描くこと」が目的になってしまっている現場を、けっこう見ます。

先に、この記事でいちばん言いたいことを書いてしまいます。

ユースケース図は、きれいに描くための道具ではありません。「誰の・どの目的を・漏れなく」掴むための道具です。

目的は、図の完成ではなく、要求の把握。だから、記法のルールを覚えることより、洗い出しの視点と、そもそも作らなくていい場面の見極めの方が、実務では効きます。順番に書いていきます。

① ユースケースとは何か — 「目的」の単位で捉える

ユースケースとは、利用者がシステムを使って達成したい「目的」を、ひとつの単位として書き出したものです。

ポイントは、操作ではなく目的で捉えることです。

→ ✕「ボタンを押す」「ログインする」「検索する」——これは操作。
→ ○「宿を予約する」「月次レポートを受け取る」「返品を申請する」——これが目的（＝ユースケース）。

操作の単位まで割ってしまうと、数が爆発して、全体を見渡せなくなります。ユースケースは「利用者にとって意味のある達成」の粒度でそろえる。ここがずれると、以降の洗い出しが全部ぶれます。

そして、ユースケース図は、この目的たち（ユースケース）と、それを使う人（アクター）の関係を、1枚に俯瞰した図です。文章で書くのが「ユースケース記述」、関係を絵にするのが「ユースケース図」。まず箇条書きで目的を出し、全体像を掴むために図にする——この順番が自然です。

アクター：システムを使う人や外部システム（例：一般ユーザー、管理者、決済サービス）。
ユースケース：そのアクターが達成したい目的（例：予約する、承認する、通知を受け取る）。

② ユースケースの洗い出し方 — アクター起点と目的起点

洗い出しは、2つの入り口を両方使うと、抜け漏れが減ります。

（A）アクター起点 — まず「誰が使うか」を全部挙げる。そのアクターごとに「このシステムで何を達成したいか」を、目的の単位で書き出していく。利用者の種類を先に固定するので、「あの立場の人の目的を丸ごと忘れていた」という事故が減ります。

（B）目的起点（業務の流れから） — 実際の業務や利用シーンを頭から追いかけ、「ここで何をしたいか」を拾っていく。アクター起点だと出てこない、例外時・イレギュラー時の目的（キャンセル、問い合わせ、エラー時の復旧など）を拾いやすい。

この2つは、片方でもう片方を検算するために使います。アクター起点で出したリストを、業務の流れでなぞって「これで足りているか」を確認する。逆もやる。すると、どちらか一方では気づけない穴が浮かびます。

洗い出しのコツを、現場の言葉で3つ:

→ 粒度をそろえる。「予約する」と「予約ボタンを押す」を同じリストに混ぜない。目的の粒度に統一する。
→ 例外を1階層だけ足す。正常系（予約する）に対して、代表的な異常系（予約を変更する／取り消す）を必ずセットで考える。全部は要らないが、代表は要る。
→ 「誰も使わない目的」を疑う。アクターに紐づかない目的が出てきたら、それは想像で足した機能かもしれません。誰の目的かを言えないものは、いったん外す。

③ ユースケース図の書き方 — 基本ルールと記述例

図の記法は、覚えることは多くありません。要素は4つだけです。

アクター（棒人間）：利用者や外部システム。
ユースケース（楕円）：達成したい目的。
関連線：アクターとユースケースを結ぶ線。「この人がこの目的を使う」を表す。
システム境界（囲みの四角）：どこからどこまでが今回作る対象か。ここが曖昧だと、話が発散します。

書くときの基本ルール:

→ ユースケース（楕円）の中は、動詞＋目的語で書く（「予約する」「承認する」）。名詞だけ（「予約」）にしない。名詞にすると、目的なのか画面なのか機能なのか曖昧になります。
→ システム境界を先に引く。今回の対象外（外部サービスや別システムがやること）を境界の外に置くと、スコープの合意が一気に進みます。
→ include / extend を乱用しない。「共通処理をくくり出す（include）」「例外的に拡張する（extend）」の記法は、便利ですが、図を読めなくする最大の原因でもあります。関係が複雑になってきたら、まず「本当にこの矢印は要るか」を疑う。図の価値は、非エンジニアが一目で読めることにあります。

記述例（宿泊予約サービスの一部）

アクター：宿泊者 / 施設管理者 / 決済サービス（外部）
宿泊者のユースケース：宿を検索する、宿を予約する、予約を変更する、予約を取り消す、レビューを書く
施設管理者のユースケース：予約を確認する、料金を設定する、レビューに返信する
決済サービス（外部）：決済を実行する（※システム境界の外）

この粒度で並べると、「宿泊者は予約できるのに、施設管理者はキャンセルに対応できないぞ？」といった関係者間の抜けが、図の上で見えてきます。これがユースケース図の本当の効き所です。

④ ツールの選び方 — 目的に対して過剰にしない

ツールは、「目的に対して過剰にしない」が唯一のコツです。ユースケース図の目的は要求の把握なので、ツールの高機能さは本質ではありません。選ぶ観点は4つで十分です。

予算：無料で始められるか。最初から有償ツールを買う必要はほぼありません。
機能：UML記法にどこまで厳密に対応する必要があるか。多くの現場では、厳密なUMLより「読める図」の方が価値があります。
利用者のスキル：非エンジニアも編集・閲覧するか。するなら、学習コストの低いものを。
共同編集・クラウド：複数人で同時に触るか、レビューで共有するか。ここが要るかどうかで、選択肢が大きく変わります。

図を描くツールに凝るより、「この図で誰と何を合意したいか」を先に決める。ツールは、その合意を助ける範囲で選べば十分です。

⑤ ユースケース図が「いらない」ケース — 作ること自体を目的化しない

最後に、いちばん実務で効く話をします。ユースケース図は、作らなくていい場面があります。

目的は「要求を漏れなく掴む」ことなので、それが別の手段で果たせているなら、図を描く手間は見合いません。作らない方がいい代表的なケース:

→ 関係者が少なく、認識がそろっている。2〜3人で全員が同じ絵を頭に持っているなら、図にするより手を動かした方が速い。
→ 機能が単純。アクターも目的も明らかで、抜け漏れの心配が薄いなら、箇条書きで足りる。
→ すでに別の形で全体像を共有できている。画面遷移図やユーザーストーリー、既存システムの実物があるなら、そちらで代替できることが多い。

逆に、ユースケース図が効くのは「アクターが多い」「関係者の認識がバラバラ」「スコープの線引きで揉めている」ときです。つまり、抜け漏れと認識ズレのリスクが高いときほど、図の価値が上がる。リスクが低いのに律儀に描くのは、ただのコストです。

作ること自体を目的にしない。これが、ユースケース図といちばん上手に付き合うコツだと思っています。

⑥ ユースケースシナリオ（ユースケース記述）の書き方

図が「全体を1枚で俯瞰する」道具なら、ユースケースシナリオは、ユースケース1つぶんの中身を文章で書き下ろしたものです。「ユースケース記述」とも呼ばれ、中身は同じです。そして、ここで書いたシナリオは、そのままテスト設計（ユースケーステスト）の下敷きになります。

書く項目は、次の6つで足ります。

ユースケース名：動詞＋目的語で書く（例：宿を予約する）。
アクター：このユースケースを使う人。
事前条件：始まる前に満たされていること（例：会員登録が済んでいる）。
事後条件：終わったあとに成立していること（例：予約が確定し、確認メールが届いている）。
基本フロー：何事もなくゴールに着くまでの手順。番号つきの1本道で書く。
代替フロー：基本フローから分岐する例外の流れ。どの番号で分岐し、どこへ戻るかだけ書く。

③の宿泊予約サービスの「宿を予約する」で書くと、こうなります。

基本フロー：1. 宿泊者が日付とエリアを指定して宿を検索する → 2. システムが空室のある宿を一覧で表示する → 3. 宿泊者が宿とプランを選ぶ → 4. システムが料金と予約内容を表示する → 5. 宿泊者が確定し、システムが予約を登録して確認メールを送る。

代替フロー：2で空室が1件も無ければ、システムが条件の変更を促して1に戻る。5で決済に失敗したら、予約を確定せずに別の決済手段の選択を求める。

書き方のコツを2つ:

→ 基本フローに分岐を書かない。「もし〜なら」が出てきたら、それは代替フロー行きです。1本道を保つから、正常な流れを一気に追えます。
→ 全ユースケースに書かない。図に載せたユースケースのうち、流れが複雑なもの・関係者で認識が割れそうなものだけをシナリオに落とす。全部に書くのは、図を全部きれいに描くのと同じ過剰品質です。

なお、名前の似たユーザーシナリオは別の道具です。ユースケースシナリオがシステムとのやりとりの手順を定める（仕様に近い）のに対し、ユーザーシナリオは利用者の状況や動機まで含めた物語として書きます。体験の側から設計したいときは、そちらを使ってください。

▼ ユーザーシナリオの書き方はこちら
ユーザーシナリオとは？書き方・例・テンプレートをUXの実務から解説

⑦ ユースケースの例一覧 — 粒度の感覚を掴む

最後に、代表的なシステムでのユースケースの例を一覧にしておきます。「目的の単位」の粒度感は、例をいくつか見るのがいちばん早いからです。

システム	主なアクター	ユースケースの例
ECサイト	購入者／出店者	商品を探す、商品を購入する、返品を申請する／商品を出品する、注文を発送する
経費精算システム	申請者／承認者／経理	経費を申請する／申請を承認する、申請を差し戻す／振込データを出力する
SaaSの管理画面	管理者／一般ユーザー	メンバーを招待する、権限を変更する、利用状況を確認する／自分の設定を変更する
問い合わせ管理	顧客／オペレーター	問い合わせを送る、回答を受け取る／問い合わせに回答する、対応を引き継ぐ

使い方の注意をひとつだけ。この一覧をそのまま流用しないでください。例はどれも「動詞＋目的語」「利用者にとって意味のある達成」の粒度で書いてありますが、あなたのシステムの目的は、あなたの業務の言葉でしか書けません。一覧は粒度の物差しとして使い、中身は②の洗い出しで自分の現場から出す——この使い分けが、いちばん確実です。

まとめ — 図の完成ではなく、要求の把握

もう一度だけ、順番で言い切ります。

→ ユースケースは、操作ではなく目的の単位で捉える。
→ 洗い出しは、アクター起点と目的起点の両方で相互に検算する。
→ 図は、要素4つ・システム境界を先に・include/extendは乱用しない。非エンジニアが一目で読めることが価値。
→ ツールは目的に対して過剰にしない。
→ そして、目的が果たせるなら、作らなくていい。

ユースケース図は、上手な絵のコンテストではありません。誰の・どの目的を・漏れなく掴めているか。その一点に効くから使うのであって、効かない場面で律儀に描くものではない、と考えています。

よくある質問（と僕の答え）

Q. ユースケースとユースケース図は何が違うのですか？

ユースケースは「利用者がシステムを使って達成する目的」を1つの単位として書き出したもの、ユースケース図はそれらとアクター（利用者）の関係を1枚に俯瞰した図です。文章で書くのがユースケース記述、関係を絵にするのが図、と分けて考えると混乱しません。実務では、まず目的を箇条書きで洗い出し、全体像を掴むために図にする、という順番が自然です。

Q. ユースケースの洗い出しは、どこから始めればいいですか？

アクター（誰が使うか）を先に挙げ、そのアクターごとに「このシステムで何を達成したいか」を目的の単位で書き出すのが基本です。目的の粒度は「ログインする」のような操作ではなく、「予約する」「レポートを受け取る」のような、利用者にとって意味のある達成にそろえます。操作単位まで割ると数が爆発し、抜け漏れの確認ができなくなります。

Q. ユースケース図は必ず作らないといけませんか？

いいえ。ユースケース図の目的は要求を漏れなく掴むことなので、目的が果たせるなら作らなくても構いません。関係者が少なく認識がそろっているとき、機能が単純なとき、すでに別の形で全体像を共有できているときは、図にする手間が見合わないことがあります。作ること自体を目的化しないのが、いちばん大事なコツです。

要件定義でユースケースの洗い出しに詰まったら、たいていは「粒度がそろっていない」か「アクターを1種類見落としている」かのどちらかです。まずそこを疑ってみてください。

以上です。

▼ 基礎から確認する
UXデザインとは？何をデザインする仕事か【2026】