ユースケース記述の書き方｜テンプレートと記入例（基本・代替・例外フロー）

ユースケース記述は、ユースケース図の楕円1つごとに、「誰が・何を達成するために・どんな手順でシステムを使い、うまくいかないときはどうなるか」を文章で書いたものです。 中心は3つのフローです。

確認環境：ユースケースの定義は OMG の UML 2.5.1、テンプレートの項目は Alistair Cockburn の「Basic Use Case Template」の原文で確かめました。記事中の Mermaid の図は Mermaid 12.1.0（@mermaid-js/mermaid-cli 12.0.0、Linux）で描画できることを確かめています（確認日 2026年10月12日）。

ユースケースとユースケース記述

UML 2.5.1 では、ユースケースは「主体（システム）が提供する振る舞いの宣言」として定義されています。 仕様の原文では、ユースケースは "an observable result that is of value for Actors or other stakeholders"（アクターなどにとって価値のある、目に見える結果）を生む振る舞いとされ、システムの内部の構造には触れずに定義すると書かれています。

UML はユースケースの図の書き方は決めていますが、記述の書式（どの項目を書くか）は決めていません。 そのため、記述の項目はプロジェクトごとに決めます。よく使われる元になっているのが、Alistair Cockburn の「Basic Use Case Template」です。この記事の項目も、これをもとにしています。

ユースケース図の書き方と include・extend の違いは、関連記事「ユースケース図の書き方と例｜include・extendの違いとPlantUML」で扱っています。

テンプレートの全項目

必須の項目は、UC-ID・名前・主アクター・事前条件・事後条件・基本フロー・代替フロー・例外フローの8つです。 ほかは、システムの規模や読み手に合わせて足します。右の列は、Cockburn のテンプレートでの項目名です。

代替フローと例外フローの分け方について： Cockburn のテンプレートでは、両方とも「Extensions（拡張）」の1つの欄に書きます。日本のシステム開発の設計書では、「目的を達成できるか」で2つに分けて書くことが多く、この記事もそうしています。テストのとき、例外フローがそのまま「エラーの確認」のテストケースになるからです。

コピペ用テンプレート（Markdown）

## UC-000 ○○を△△する

| 項目 | 内容 |
|---|---|
| 概要 | |
| 対象システム | |
| レベル | 利用者の目的 |
| 主アクター | |
| 副アクター | |
| トリガー | |
| 事前条件 | |
| 事後条件（成功） | |
| 事後条件（失敗） | |
| 関連ユースケース | |

### 基本フロー
1. （アクター）は、〜する。
2. システムは、〜する。
3. 

### 代替フロー
- 2a. （条件）の場合
  1. 
  2. 基本フロー 3 に戻る。

### 例外フロー
- 3e. （条件）の場合
  1. システムは、（メッセージID）を表示する。
  2. ユースケースを終了する。

### 業務ルール・非機能
- BR-001：
- 応答時間：

### 未決事項
- （内容／決める人／期限）

番号の付け方：代替フローは「分かれる手順の番号＋a, b, c」（2a, 2b）、例外フローは「番号＋e」（3e）のように分けると、どの手順から分かれたかが番号で分かります。Cockburn のテンプレートは、Extensions を「主シナリオの手順を参照して1つずつ書く」としています。記号の付け方（a と e の使い分け）は、この記事での決め方です。

記入例1：ログインする

基本フロー 1. 会員は、ログイン画面でメールアドレスとパスワードを入力する。 2. システムは、メールアドレスとパスワードが登録内容と一致することを確かめる。 3. システムは、失敗の回数を0に戻し、最終ログイン日時を記録する。 4. システムは、マイページを表示する。

代替フロー - 1a. 会員が「ログイン状態を保持する」を選んだ場合 1. システムは、手順3のあとに、保持用のトークンを発行する。 2. 基本フロー4に戻る。

例外フロー - 2e. メールアドレスかパスワードが一致しない場合 1. システムは、失敗の回数を1増やす。 2. システムは、「メールアドレスまたはパスワードが違います」（MSG-E001）を表示する。 3. 基本フロー1に戻る。 - 2e-1. 失敗の回数が5回になった場合 1. システムは、アカウントを30分ロックする。 2. システムは、ロックしたことをメールで会員に通知する。 3. ユースケースを終了する。

例外フロー 2e で「どちらが違うか」を表示しないのは、メールアドレスが登録されているかを第三者に知られないようにするためです。このような理由は、業務ルールか備考に残しておくと、後でレビューする人に意図が伝わります。

記入例2：商品を注文する

基本フロー 1. 会員は、カート画面で「購入手続きへ」を選ぶ。 2. システムは、登録済みの届け先と支払い方法を表示する。 3. 会員は、内容を確かめて注文を確定する。 4. システムは、商品ごとに在庫を引き当てる。 5. システムは、決済サービスに支払いの承認を依頼する。 6. 決済サービスは、承認の結果を返す。 7. システムは、注文を「受付済み」で登録する。 8. システムは、注文完了画面を表示し、メール配信サービスに注文確認メールを依頼する。

代替フロー - 2a. 会員が別の届け先を指定する場合 1. 会員は、届け先を入力する。 2. システムは、郵便番号と住所の形式を確かめる。 3. 基本フロー3に戻る。 - 3a. 会員がクーポンを使う場合（UC-013 に拡張） 1. 会員は、クーポンコードを入力する。 2. システムは、クーポンの有効期限と対象商品を確かめ、割引後の金額を表示する。 3. 基本フロー3に戻る。

例外フロー - 4e. 在庫が足りない商品がある場合 1. システムは、引き当てた在庫を戻す。 2. システムは、足りない商品名と「在庫が足りません」（MSG-E021）をカート画面に表示する。 3. ユースケースを終了する。 - 6e. 決済が承認されない場合 1. システムは、手順4で引き当てた在庫を戻す。 2. システムは、「お支払いを完了できませんでした」（MSG-E022）を表示する。 3. 基本フロー2に戻る（会員は支払い方法を変えられる）。 - 6e-1. 決済サービスから決めた時間内に応答がない場合 1. システムは、決済の状態を「確認中」として注文を保留する。 2. システムは、決済サービスに状態を問い合わせる（UC-090 決済状態を照会する）。 3. ユースケースを終了する。

手順5〜7のように、外部サービスとのやり取りがある箇所は、「応答がない」「遅れて成功が返る」の例外を必ず考えます。 事後条件（失敗）に「二重に請求しない」と書いておくと、この例外の設計が抜けにくくなります。

基本・代替・例外のつながりを図にすると、次のようになります。

flowchart TD
  b1[1 購入手続きへ] --> b2[2 届け先・支払いを表示]
  b2 --> b3[3 注文を確定]
  b2 -. 2a 別の届け先 .-> a2[届け先を入力] --> b3
  b3 -. 3a クーポン .-> a3[クーポンを適用] --> b3
  b3 --> b4[4 在庫を引き当て]
  b4 -- 4e 在庫不足 --> e4([在庫を戻して終了])
  b4 --> b5[5 決済を依頼]
  b5 --> b6{6 承認されたか}
  b6 -- 6e 承認されない --> b2
  b6 -- 6e-1 応答なし --> e6([保留して終了])
  b6 -- 承認 --> b7[7 注文を登録]
  b7 --> b8([8 完了画面・メール])

記入例3：経費の承認を申請する

承認のように、複数のアクターが順番に関わる業務は、「誰の目的か」でユースケースを分けます。 申請者の目的は「申請を出す」、承認者の目的は「申請を判断する」で、別のユースケースになります。

基本フロー 1. 申請者は、経費申請画面で日付・金額・科目・内容を入力し、領収書の画像を添付する。 2. システムは、入力の形式（日付・金額・必須項目）を確かめる。 3. 申請者は、申請を確定する。 4. システムは、金額と科目から承認ルートを決める（BR-031）。 5. システムは、申請を「承認待ち」で登録し、承認者に通知する。

代替フロー - 1a. 申請者が途中で保存する場合 1. システムは、申請を「下書き」で保存する。 2. 申請者は、あとで下書きを開いて基本フロー1から続ける。 - 4a. 金額が 10 万円以上の場合（例） 1. システムは、承認ルートに部長を加える。 2. 基本フロー5に戻る。 - 4b. 承認者が不在に設定されている場合 1. システムは、代理の承認者に通知先を変える。 2. 基本フロー5に戻る。

例外フロー - 2e. 必須項目が入力されていない、または金額が数値でない場合 1. システムは、誤りのある項目と「入力内容に誤りがあります」（MSG-E031）を表示する。 2. 基本フロー1に戻る。 - 4e. 申請者に上長が設定されていない場合（マスタの不備） 1. システムは、申請を「下書き」のまま残す。 2. システムは、「承認者が設定されていません。管理者にお問い合わせください」（MSG-E032）を表示する。 3. ユースケースを終了する。

差し戻し・却下は、承認者のユースケース（UC-032）の代替・例外フローに書きます。 申請者のユースケースに混ぜると、1つの記述に2人の目的が入り、長くなります。申請の状態（下書き → 承認待ち → 承認済み／差し戻し）の移り変わりは、状態遷移図で別に描くと整理できます。関連記事「状態遷移図と状態遷移表の書き方｜テスト設計とMermaid・PlantUML」で扱っています。

粒度の決め方

ユースケース1つは、「主アクターが1回システムを使って、1つの目的を達成する」単位にします。 Cockburn のテンプレートは、レベル（Level）を次の3つから選ぶ形にしています。

粒度が合っているかは、次の問いで確かめます。

• 終わったときに、主アクターが「用事が済んだ」と言えるか（言えなければ小さすぎる）
• 1つの記述に、主アクターが2人以上いないか（いれば分ける。記入例3の申請と承認）
• 基本フローの手順に「〜を管理する」「〜を処理する」がないか（中身が決まっていないので、分解する）
• 画面の操作（ボタンを押す、タブを切り替える）が手順になっていないか（UI の手順は画面設計書に書く）

手順の文の書き方

テストケースへのつなぎ方

ユースケース記述は、そのままテストケースの元になります。 基本フローを1件、代替フロー・例外フローをそれぞれ1件以上にすると、どのフローを試したかが表で分かります。

TC-001-04・05 の「4回」「30分後」は、業務ルール BR-001 の境界の値です。 境界の値の選び方は、関連記事「同値分割・境界値分析｜テストケース表とpytestコード例で解説」で扱っています。

受け入れの基準として Given-When-Then の形で書くと、事前条件は Given、手順は When、事後条件は Then に対応します。

Feature: ログインする（UC-001）
  Scenario: 5回続けて失敗するとロックされる（例外 2e-1）
    Given 会員の失敗回数が 4 回である
    When 誤ったパスワードでログインする
    Then アカウントが 30 分ロックされる
    And ロックを知らせるメールが送られる

テストケースの書式は、関連記事「テスト仕様書の書き方｜テストケースの記入例と観点の洗い出し方」で扱っています。要件・ユースケース・テストの対応表は「トレーサビリティマトリクスの作り方 要件・設計・テスト対応表」で扱っています。

画面設計へのつなぎ方

手順の「システムは〜を表示する」と「アクターは〜を入力する」から、画面・項目・メッセージの一覧を作れます。

例外フローの「どの画面に戻るか」が決まっていないと、画面遷移図が描けません。 ユースケース記述の段階で戻り先を書いておくのは、このためです。画面の項目の書き方は、関連記事「画面設計書の書き方｜項目一覧・テンプレート・記入例まとめ」で扱っています。

ユーザーストーリーとの違い

1つのユースケースを、複数のユーザーストーリーに分けて開発することもあります。ユーザーストーリーの書き方は、関連記事「ユーザーストーリーの書き方と例30選｜受け入れ基準Given-When-Then」で扱っています。

よくある質問

Q. ユースケースはいくつ書けばよいですか。 A. 数は、システムの規模と、ユースケース図の楕円の数で決まります。数を目標にするより、「主アクターごとの目的が全部あるか」をユースケース図と機能一覧で照らし合わせて確かめます。

Q. 事前条件と、例外フローの条件は何が違いますか。 A. 事前条件は「システムが確かめなくてよい前提」です。たとえば「ログインしている」を事前条件にすると、ログインしていない場合の処理はこのユースケースでは扱いません。システムが確かめて分岐するもの（在庫があるか）は、事前条件ではなく例外フローに書きます。

Q. バッチ処理もユースケースで書けますか。 A. 書けます。主アクターを「時刻（タイマー）」や「運用者」にし、トリガーに「毎日 2:00」のように書きます。ただし、ジョブの順番や再実行の設計は、バッチ設計書のほうが書きやすいことが多いです。関連記事「バッチ設計書の書き方と項目一覧｜リランと異常終了時の設計サンプル」で扱っています。

Q. 生成AIにユースケース記述を書かせられますか。 A. 下書きは作れます。ただし、業務ルールの値（ロックまでの回数など）や例外の終わり方は、発注者と決める内容です。下書きは「未決事項」の洗い出しに使い、決まった値はレビューで確かめます。設計書の下書きのプロンプトは、関連記事「生成AIで設計書を作るプロンプト集｜要件定義から詳細設計まで」で扱っています。

まとめ

• ユースケース記述は、1つの目的について、手順と、うまくいかないときを文章で書くもの
• UML はユースケースの意味と図を決めているが、記述の書式は決めていない。項目は Cockburn のテンプレートが元になることが多い
• 必須は UC-ID・名前・主アクター・事前条件・事後条件・基本・代替・例外フロー
• 代替＝目的を達成できる別の道、例外＝目的を達成できずに終わる道。分かれる手順の番号で 3a・4e のように書く
• 基本・代替・例外をそれぞれ1件以上のテストケースにし、戻り先の画面を画面設計に引き継ぐ

参考・出典

確認日はいずれも 2026年10月12日です。

• OMG「Unified Modeling Language（UML）Version 2.5.1」：https://www.omg.org/spec/UML/2.5.1
• Webel「UML 2.5.1 UseCase の仕様の抜粋」：https://webel.com.au/node/1718
• Alistair Cockburn「Basic Use Case Template」：https://cs.otago.ac.nz/coursework/cosc461/uctempla.htm

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。