対象試験と出題頻度
ユースケース図は、基本情報技術者・応用情報技術者で出題されるテーマです。
UMLのダイアグラム比較問題として定番化しており、「クラス図」「シーケンス図」「アクティビティ図」「状態マシン図」との違いを正確に区別できるかが問われます。
詳細をクリックして確認
基本情報技術者
応用情報技術者
★★★★☆
ランクA（重要）必ず覚えておくべき
用語の定義
情報処理試験を勉強していると、「ユースケース図って何を描く図？クラス図やシーケンス図とどう違うの？」と混乱しがちです。
ユースケース図（Use Case Diagram）とは、一言で言うと
「システムが提供する機能を、利用者（アクター）の視点から整理して表現するUMLの図」
のことです。
イメージとしては、「レストランのメニュー表」です。
メニュー表には「お客様が注文できる料理の一覧」が書かれています。厨房の調理手順や食材の仕入れルートは書かれていません。
ユースケース図も同じで、「このシステムを使う人が何をできるか」だけをシンプルに一覧化した図です。
📊 ユースケース図の基本情報
| 項目 | 内容 |
|---|---|
| 英語名 | Use Case Diagram |
| UMLでの分類 | 振る舞い図（Behavior Diagram） |
| 主な利用工程 | 要求分析・要件定義 |
| 構成要素 | アクター、ユースケース、関連、システム境界 |
解説
システム開発の初期段階では、「このシステムは誰のために、何をするものなのか」を開発チームと利用者の間で共有する必要があります。
しかし、文章だけで要件を書き出すと解釈のズレが起きやすく、抜け漏れも発生します。
この問題を解決するために、利用者とシステム機能の対応関係を視覚的に整理するユースケース図が生まれました。
4つの構成要素
ユースケース図を構成する要素は4つです。
それぞれの役割を正確に区別することが理解の土台になります。
| 要素 | 記号 | 役割 |
|---|---|---|
| アクター | 棒人間（人型） | システムを利用する人や外部システム。人間だけでなく、連携する外部サービスやハードウェアもアクターになり得る |
| ユースケース | 楕円 | アクターがシステムを通じて遂行する単位業務。「商品を検索する」「注文する」のように動詞で記述する |
| 関連 | 実線 | アクターとユースケースのつながりを示す線 |
| システム境界 | 長方形 | 開発対象の範囲を囲む枠。この中がシステム化の対象 |
図解：ECサイトのユースケース図
具体例として、ECサイトを題材にした簡易的なユースケース図を示します。
顧客
ECサイト
管理者
▲ アクター（棒人間）はシステム境界の外側、ユースケース（楕円）は内側に配置する
include（包含）とextend（拡張）
ユースケース間には2種類の特別な関係があります。
include（包含）：あるユースケースが別のユースケースの機能を「必ず」含む関係です。例えば「商品を購入する」は必ず「認証する」を含みます。点線矢印に «include» と記述します。
extend（拡張）：特定の条件を満たしたときだけ追加で実行されるユースケースの関係です。例えば「商品を購入する」に対して、条件次第で「クーポンを適用する」が拡張されます。点線矢印に «extend» と記述します。
include / extend の関係図
↓ «include»
（必ず実行される）
↑ «extend»
（条件次第で実行される）
※ include：基底→包含先へ矢印 ／ extend：拡張側→基底へ矢印
他のUMLダイアグラムとの比較
ユースケース図を正しく位置づけるには、他の主要な図と「何を表現するか」で整理するのが近道です。
| 図の名称 | 何を表現するか | 見分けキーワード |
|---|---|---|
| ユースケース図 | アクターとシステム機能の対応関係 | アクタ、相互作用、要求機能 |
| クラス図 | クラスの属性・操作とクラス間の静的な関連 | 属性、操作、汎化、集約 |
| シーケンス図 | オブジェクト間のメッセージを時系列で表現 | ライフライン、メッセージ、時系列 |
| アクティビティ図 | 処理の制御フロー（フローチャートのUML版） | 制御の流れ、分岐、並行処理 |
| 状態マシン図 | オブジェクトの状態遷移 | トリガ、状態遷移、イベント |
では、この用語が試験でどのように出題されるか見ていきましょう。
💡 ユースケース図の核心を3行で
・システムの機能を利用者（アクター）の視点から整理するUMLの振る舞い図
・構成要素は「アクター（棒人間）」「ユースケース（楕円）」「関連（実線）」「システム境界（長方形）」の4つ
・include（必ず含む）とextend（条件付きで拡張）の2つの関係を区別する
試験ではこう出る！
ユースケース図は、FE・APの午前問題でUMLダイアグラムの比較問題として繰り返し出題されています。
出題パターンは大きく2つに分かれます。
📊 過去問での出題実績
| 試験回 | 出題内容 | 問われたポイント |
|---|---|---|
| FE R3免除 問45 |
ユースケース図の説明として正しいものを選ぶ問題。 | ・「システムとアクタの相互作用」が正解 ・ステートチャート図・クラス図・DFDの説明がひっかけ |
| AP H28秋 午前 問46 |
上記FE R3問45と同一構成の問題（流用）。 | ・FEとAPで同じ問題が出回る典型例 ・選択肢の文言もほぼ同一 |
| AP H27秋 午前 問64 |
要件定義で利用者と業務機能を分離して表現する図を選ぶ問題。 | ・「利用者と業務機能の分離」がユースケース図の特徴 ・アクティビティ図・オブジェクト図・クラス図がひっかけ |
| AP H23秋 午前 問43 |
ユースケース図でシステムと相互作用する外部システムを選ぶ問題。 | ・正解は「アクタ」 ・インスタンス・トリガ・リンクは構成要素ではない |
📝 IPA試験での出題パターン
パターン1：「ユースケース図の説明を選べ」
4つのUMLダイアグラムの説明文が並び、ユースケース図に該当するものを選ぶ形式。ひっかけとして「クラスと関連」（クラス図）、「オブジェクトの状態遷移」（状態マシン図）、「データの流れ」（DFD）の説明が紛れ込む。キーワードは「アクタ」「相互作用」。
パターン2：「構成要素を選べ」
AP H23秋のように、ユースケース図の構成要素として正しいものを問う形式。「アクタ」を選ばせる問題が典型。「インスタンス」「トリガ」はユースケース図の構成要素ではないので除外する。
試験ではここまででOKです。includeやextendの矢印の向きまで問われることはほぼないので、深追いは不要です。
【確認テスト】理解度チェック
ここまでの内容を理解できたか、簡単なクイズで確認してみましょう。
Q. UMLのユースケース図の説明として、最も適切なものはどれでしょうか？
- A. システムに対する要求機能を、利用者や外部システム（アクター）とシステムの相互作用として表現する。
- B. クラスの属性・操作と、クラス間の汎化や集約などの静的な関連を表現する。
- C. オブジェクト間でやり取りされるメッセージの流れを、時系列に沿って表現する。
正解と解説を見る
正解：A
解説：
ユースケース図は、システムが提供する機能（ユースケース）と、それを利用するアクターとの対応関係を表すUMLの振る舞い図です。要件定義の段階で「誰が何をできるか」を視覚的に整理する目的で使われます。
選択肢Bはクラス図の説明です。クラス図はシステムの静的構造を表す構造図であり、利用者視点の機能一覧を描くユースケース図とは役割が異なります。選択肢Cはシーケンス図の説明です。シーケンス図はオブジェクト間のメッセージを時間軸に沿って記述するものであり、アクターとシステム機能の対応を示すものではありません。
よくある質問（FAQ）
Q. ユースケース図のアクターは人間以外もなれますか？
なれます。アクターは「システムと相互作用する外部の存在」を表すため、外部システム（決済サービスや在庫管理システムなど）やハードウェア（バーコードリーダーなど）もアクターとして記述します。AP H23秋 午前問43では、まさにこの点が出題され、「システムと相互作用する外部システムは何か」の正解が「アクタ」でした。
Q. ユースケース図とDFD（データフローダイアグラム）はどう違いますか？
ユースケース図はUMLに属する振る舞い図で、「誰が何をできるか」を利用者視点で表現します。一方、DFDはUMLには含まれない構造化分析の手法で、「データがどこからどこへ流れるか」に着目してプロセス・データストア・データフロー・外部エンティティの4要素で整理します。過去問ではユースケース図の選択肢にDFDの説明（「データの流れに注目してシステムの機能を表現する」）が紛れ込むパターンがあるため、混同しないよう注意してください。
Q. 実務ではユースケース図はどの工程で使いますか？
主に要求分析・要件定義の工程で使います。クライアントやエンドユーザーとの打ち合わせで「このシステムはこういう人がこういう使い方をする」という認識を合わせるためのコミュニケーションツールとして機能します。技術的な詳細を含まないため、非エンジニアにも理解しやすいのが強みです。アジャイル開発ではユーザーストーリーの洗い出しにユースケース図を併用するチームもあります。
Q. ユースケース図の「ユースケース」と「機能」は同じ意味ですか？
厳密には異なります。ユースケースは「アクターがシステムとのやり取りを通じて達成する一連の目的」を指し、単なる機能の羅列ではありません。例えば「ログインする」は機能ですが、ユースケースとしては「認証を経て個人ページにアクセスする」という利用者の目的を表します。ただし、IPA試験の範囲では「システムの機能をアクター視点で表現したもの」と理解していれば得点に支障はありません。
