ユースケース(ユースケース)
ユーザがシステムを使う具体的シナリオを記述したもの。Clean Architecture の Application 層、UML ユースケース図、要件定義の中核要素として使われる。
概要
ユースケース(Use Case)は、ユーザがシステムを使う具体的シナリオを記述したものを指す。1992 年に Ivar Jacobson が UML(統一モデリング言語)の中核概念として提唱、要件定義の標準手法として確立した。2026 年現在、Robert C. Martin の Clean Architecture や Eric Evans の DDD(ドメイン駆動設計) で「Application 層 / Use Case 層」として再注目され、ビジネスロジックとシステム実装を繋ぐ中核要素となっている。「ユーザ登録ユースケース」「商品購入ユースケース」のように、1 つのユーザの行動単位で粒度を切る。
ユースケースの構成要素(UML 標準)
| 要素 | 説明 |
|---|---|
| Actor | システムを使う人 / 別システム |
| Use Case | アクターが達成したい目的 |
| Precondition | 開始時の前提条件 |
| Trigger | 開始のきっかけ |
| Main Flow | 標準シナリオ |
| Alternative Flow | 別シナリオ |
| Exception Flow | エラー時 |
| Postcondition | 終了時の状態 |
ユースケース記述の典型例
タイトル: ユーザがログインする
アクター: 登録済みユーザ
前提条件: アカウントが作成済み
トリガー: ユーザがログインボタンを押す
メインフロー:
1. システムがログイン画面を表示
2. ユーザがメール + パスワードを入力
3. ユーザが「ログイン」を押す
4. システムが認証情報を検証
5. システムがダッシュボードを表示
代替フロー(4a):
パスワード違い → エラー表示 + 再入力
例外フロー(4b):
3 回失敗 → アカウントロック + 通知メール
事後条件: セッション開始、最終ログイン日時更新
Clean Architecture でのユースケース層
[ Presentation ] → [ Application / Use Case ] → [ Domain / Entity ]
↑
[ Infrastructure / DB / API ] ──────────────────┘
ユースケース層は:
- ビジネスルールに関する Domain Entity を組み合わせ
- Repository インターフェース経由で Infrastructure(DB / API)を呼び出し
- 1 ユースケース = 1 メソッド or 1 クラス
TypeScript 実装例(Clean Architecture)
// Use Case
export class CreateOrderUseCase {
constructor(
private orderRepo: OrderRepository,
private inventoryService: InventoryService,
private notifier: NotificationService,
) {}
async execute(input: CreateOrderInput): Promise<CreateOrderOutput> {
// 1. 商品の在庫確認
const items = await this.inventoryService.checkStock(input.items);
if (!items.allInStock) {
throw new OutOfStockError(items.missing);
}
// 2. ドメインエンティティ作成
const order = Order.create({
userId: input.userId,
items: items.products,
shippingAddress: input.address,
});
// 3. 永続化
await this.orderRepo.save(order);
// 4. 在庫減算
await this.inventoryService.reserveStock(items.products);
// 5. 通知送信
await this.notifier.sendOrderConfirmation(order);
return { orderId: order.id, total: order.totalAmount() };
}
}
DDD のアプリケーションサービス
DDD では「Application Service」と呼ばれるが、Clean Architecture の「Use Case」と同義概念。トランザクション境界を定義し、Domain と Infrastructure を協調させる。
BDD(振る舞い駆動開発)との関係
Feature: ユーザログイン
Scenario: 正しい認証情報でログイン
Given ユーザが登録済みである
And ユーザはログイン画面を開いている
When 正しいメールとパスワードを入力する
And ログインボタンを押す
Then ダッシュボードに遷移する
And セッションが開始される
Cucumber / SpecFlow / behave 等の BDD ツールが Gherkin 記法でユースケースを実行可能テストとして表現。
ユースケース図(UML)
graph LR
User((ユーザ))
Admin((管理者))
UC1[商品検索]
UC2[商品購入]
UC3[在庫管理]
UC4[ユーザ管理]
User --> UC1
User --> UC2
Admin --> UC3
Admin --> UC4
Mermaid / PlantUML / Drawio で描画可能。
ユースケースマップ(User Story Mapping)
Jeff Patton 提唱、ユーザの旅路を時系列で並べ、各ステップに該当する機能(ユースケース)を整理する手法。アジャイル開発で MVP 設計に使う。
主要なユースケース管理ツール
| ツール | 用途 |
|---|---|
| Atlassian Confluence | ドキュメント、要件定義 |
| Notion | 個人 / 中小、汎用 |
| Jira | チケット管理、ユースケース連動 |
| Miro / FigJam | ビジュアル、ホワイトボード |
| StoriesOnBoard | User Story Mapping 専用 |
| Cucumber Studio | BDD 自動テスト連動 |
自作.com(jisaku.com)でのユースケース実装
API(Hono on Bun)で Clean Architecture 採用。
apps/jisakucom-api/src/
├── domain/ # Entity / Value Object
├── application/ # ★ Use Case(121 ファイル)
│ └── use-cases/
│ ├── product/
│ ├── ranking/
│ ├── seo-scoring/
│ └── ...
├── infrastructure/ # Repository 実装
└── presentation/ # HTTP Controller
関連用語との違い
| 用語 | 違い |
|---|---|
| 機能 / Feature | より広い概念、ユースケースは具体行動 |
| ユーザストーリー | アジャイル用、より粒度小 |
| シナリオ | 個別ケース、ユースケースの一部 |
| サービス(DDD) | アプリケーションサービス = ユースケース、Domain Service は別 |
よくある質問
Q1: ユースケースとユーザストーリー、どう使い分け? A: ユーザストーリーは「ユーザとして〜したい、なぜなら〜」の短文形式(アジャイル)。ユースケースは詳細フロー記述(要件定義)。同じ要件を粒度別に表現したものと考える。
Q2: 個人開発で Clean Architecture / Use Case 層は過剰? A: 学習目的なら有効、本気の SaaS は推奨。MVP プロトタイプでは MVC で十分。Clean Architecture は規模拡大 + 長期保守でコストを回収する。
Q3: 1 ユースケースの粒度はどれくらい? A: 「1 つのユーザが 1 つの目的を達成する単位」。例: 「商品購入」は 1 ユースケース、「商品検索 → カート追加 → 購入」は 3 ユースケース。
まとめ
- ユーザの 具体的シナリオを記述 する要件定義 + 設計概念
- 2026 年は Clean Architecture / DDD の Application 層 として再注目
- BDD / User Story Mapping と組み合わせ 要件 + 実装 + テスト を一気通貫で