2026.09.07 10 人が閲覧（直近 30 日）アーキテクチャ

UMLとは：仕様2.5.1の14種類の図と実務で使う4種類・PlantUMLとMermaidの書き方

UML（Unified Modeling Language）はOMGが管理するモデリング言語で、現行版は2017年12月採択の2.5.1です。仕様書は796頁あり、付録で14種類の図を定義しています。ただ、案件で実際に書くのはそのうち3〜4種類に収まるのが実情です。この記事では、仕様が定める図の分類を原文の記述どおりに整理したうえで、要件定義から詳細設計までの工程別にどの図を書き、どれを書かないかを条件で示します。PlantUMLとMermaidで図をテキスト化し、jarでの一括生成とCIでの構文検証まで動くコードを載せました。UML 2.5で準拠レベルL0からL3が廃止された経緯も、ツール選定の前提として扱います。

まとめ：UML14種類のうち書くのは4種類、着手はユースケース図から

結論から言うと、受託開発で書く価値があるのはユースケース図・クラス図・シーケンス図・状態遷移図の4種類です。残りの10種類は、書いても発注側と開発側の認識差を埋めません。コンポジット構造図やプロファイル図は仕様の網羅性のために存在する記法であって、業務システムの設計書に並べる対象ではありません。

着手順はユースケース図が先です。誰が何をするかを固定しないままクラス図に入ると、業務上の役割ではなく現行テーブルの構造をそのままクラスに写した図ができます。ユースケースを確定させてからクラス図と画面遷移を詰め、外部システムとのやり取りが絡む箇所だけシーケンス図を足す。状態遷移図は、受注・申請・契約のようにステータスを持つ実体が現れたときだけ書きます。

図は画像ファイルではなくテキストで持ってください。PlantUMLかMermaidで.pumlや.mdとして書けば、Gitの差分で設計変更が追え、CIで構文エラーを落とせます。Excelに貼られたPNGは、3か月後にはコードと乖離したまま誰も直しません。この運用の具体は後半で示します。

UML 2.5.1の仕様が定義する14種類の図と、構造図・振る舞い図の2分類

まず押さえるべきは、UMLが「図の描き方」ではなくメタモデルの仕様だという点です。OMGの仕様ページで公開されている版は1.1（1997年12月）から2.5.1（2017年12月）まであり、2.5.1が現行の正式版です。以降の新版は出ていません。

Annex Aが列挙する14種類の図と、大分類が2つしかない理由

図の一覧は仕様本体PDF（全796頁）のAnnex A: Diagramsにあり、この付録はnormative（規定）です。原文は「there are two major kinds of diagram types: structure diagrams and behavior diagrams」と書いており、大分類は構造図と振る舞い図の2つだけです。日本語の解説では構造図7・振る舞い図4・相互作用図3の3分類で説明されることが多いのですが、相互作用図は振る舞い図の下位に置かれた分類で、仕様上の並列カテゴリではありません。

Annex Aが名前を挙げている14種類は、アクティビティ図、クラス図、コミュニケーション図、コンポーネント図、コンポジット構造図、配置図、相互作用概要図、オブジェクト図、パッケージ図、プロファイル図、ステートマシン図、シーケンス図、タイミング図、ユースケース図です。構造図が7種類、振る舞い図が7種類（うち相互作用図が4種類）という内訳になります。

構造図7種類の役割と、業務システムで実際に描かれる2種類の選定基準

構造図は時間に依存しない静的な構造を示す図です。クラス図・オブジェクト図・パッケージ図・コンポーネント図・コンポジット構造図・配置図・プロファイル図の7種類が該当します。このうち業務システムの設計で残るのはクラス図とパッケージ図で、他は用途が限定的です。

クラス図はオブジェクト指向の考え方をそのまま図にしたもので、属性・操作・関連・多重度を持ちます。書き方の詳細はクラス図の記法解説に譲りますが、集約（白抜きの菱形）とコンポジション（塗りつぶしの菱形）の使い分けだけは設計判断に直結します。親を消したときに子も消えるならコンポジションです。プロファイル図はUML自体を拡張するステレオタイプを定義する図で、SysMLのようなプロファイルを自作しない限り出番はありません。

振る舞い図7種類のうち相互作用図4種類が占める実務上の位置づけ

振る舞い図はユースケース図・アクティビティ図・ステートマシン図の3つと、相互作用図4種類（シーケンス図・コミュニケーション図・相互作用概要図・タイミング図）で構成されます。仕様は振る舞い図を「メソッド、協調動作、アクティビティ、状態の履歴を含む動的な振る舞いを示す」と定義しています。

相互作用図4種類は、同じ「オブジェクト間のメッセージのやり取り」を別の切り口で見せる図です。時系列で追うのがシーケンス図、関係の構造で見せるのがコミュニケーション図、複数の相互作用の流れを俯瞰するのが相互作用概要図、時間軸上の状態変化を示すのがタイミング図です。実務で書かれるのはほぼシーケンス図だけで、コミュニケーション図はシーケンス図と情報が重複するため二重管理になります。タイミング図は組込みやリアルタイム制御の応答時間を議論する場面に限られます。

UML 2.5での準拠レベル廃止とInfrastructure統合が意味する仕様の変化

2.4.1から2.5への改訂は記法の追加ではなく、仕様書そのものの再編でした。この変更はツールの選び方と、設計書に「UML準拠」と書くときの意味を変えています。

準拠レベルL0からL3の廃止と、ツール選定で使えなくなった基準

仕様本体の6.1 Specification Simplificationは、2.4.1からの変更として準拠レベルの廃止を明記しています。原文は「The compliance levels L0, L1, L2, and L3 have been eliminated, because they were not found to be useful in practice」で、理由は実務で役に立たなかったことです。さらに「A tool either complies with the whole of UML or it does not」と続き、部分実装のツールはどのサブセットを実装したかをベンダー側が宣言すべきだとしています。

そのため「L2準拠のUMLツール」という選定基準は2.5以降は成立しません。ツールを比較するなら、準拠レベルではなく、必要な4種類の図が書けるか、XMI形式でモデルを持ち出せるか、テキスト形式で差分が取れるかで見るほうが実態に合います。

Infrastructure統合と2017年12月以降の更新状況から読む安定度

同じ節に「The UML Infrastructure no longer forms part of the UML specification」とあり、2.4.1まで分冊だったInfrastructureとSuperstructureが1冊に統合されました。Package Mergeの使用もやめ、各メタクラスを1つの節で完結して記述する構成に変わっています。メタモデル自体は2.4.1のSuperstructureからほぼ変わっていません。

2.5.1が採択されたのは2017年12月で、2026年9月時点でそれ以降の正式版は出ていません。9年近く記法が動いていないということは、いま覚えた記法が陳腐化しにくいことを意味します。設計標準として社内に定着させるなら、版の追従コストを心配する必要はほぼない部類です。

PlantUMLでクラス図を書き、jarで一括生成して構文を検証する手順

図をテキストで書く利点は、レビューがコードレビューと同じ土俵に乗ることです。プルリクエストの差分に「多重度を1から0..*に変えた」と出れば、設計変更が見落とされません。ツールの導入手順やインストールはPlantUMLの解説記事で扱っているため、ここでは記法とCI連携に絞ります。

受注管理のクラス図を.pumlで書く：多重度と集約を記述する手順

次は受注・受注明細・顧客の関係を表したクラス図です。PlantUML公式のクラス図ドキュメントの記法に沿っており、そのままorder.pumlとして保存すれば動きます。

@startuml order-class
skinparam classAttributeIconSize 0

class Customer {
  - customerId : String
  - name : String
  + creditLimit() : Money
}

class Order {
  - orderId : String
  - orderedAt : LocalDateTime
  - status : OrderStatus
  + totalAmount() : Money
}

class OrderLine {
  - quantity : int
  - unitPrice : Money
  + subtotal() : Money
}

enum OrderStatus {
  RECEIVED
  CREDIT_CHECKING
  READY_TO_SHIP
  SHIPPED
  REJECTED
}

Customer "1" o-- "0..*" Order : places
Order "1" *-- "1..*" OrderLine : contains
Order --> OrderStatus
@enduml

顧客と受注は集約（o--）、受注と受注明細はコンポジション（*--）で書き分けています。顧客を削除しても過去の受注伝票は残す、受注を取り消せば明細も消えるという業務ルールを表すのが、この1文字の違いです。ここを曖昧にしたまま実装に入ると、論理削除の仕様が後から揉めます。

plantuml.jarでのSVG一括生成と-checkonlyによる構文チェック

公式のコマンドラインドキュメントによれば、java -jar plantuml.jar file1 file2 が基本形で、既定の出力はPNGです。ディレクトリを渡せば配下をまとめて処理し、** でディレクトリをまたぐ再帰指定ができます。バージョンは2026年9月5日公開の v1.2026.8 が最新です。

# SVGで一括生成し、docs/uml/out 配下へ出力する
java -jar tools/plantuml.jar -tsvg -o "out" "docs/uml/**/*.puml"

# 画像を作らず構文だけ検証し、1件でも壊れていたら以降を打ち切る
java -jar tools/plantuml.jar -checkonly -failfast2 "docs/uml/**/*.puml"

CIに載せるのは後者です。-checkonly はファイルを生成せず構文検査だけを行い、-failfast2 は事前チェックでエラーを見つけた時点で全体をスキップします。プルリクエストのジョブに次の1ステップを足せば、記法が壊れた図がmainに入らなくなります。

- name: check uml syntax
  run: java -jar tools/plantuml.jar -checkonly -failfast2 "docs/uml/**/*.puml"

jarはリポジトリ内のtools/に置くか、ジョブ内でリリース資産から取得します。Javaランタイムが要るため、GitHub Actionsならactions/setup-javaを前段に挟んでください。

MermaidでUMLをGitHub上に表示し、レビューの場に図を持ち込む構成

PlantUMLはJavaの実行環境が要ります。設計者にJavaを入れさせたくない、あるいはGitHub上でそのまま図を見せたいなら、Mermaidのほうが摩擦が少ない選択です。

GitHubのMarkdownでレンダリングされるクラス図と状態遷移図

GitHub公式ドキュメントは、mermaidという言語識別子を付けたコードブロックがIssues・Discussions・プルリクエスト・wiki・Markdownファイルでレンダリングされると記載しています。つまり図の生成ステップもホスティングも不要で、Markdownを置くだけで設計図がレビュー画面に出ます。

次はMermaid公式のstateDiagramの記法で書いた受注ステータスの状態遷移です。stateDiagram-v2を指定します。

stateDiagram-v2
    [*] --> 受付済
    受付済 --> 与信中 : 与信依頼
    与信中 --> 出荷待ち : 与信OK
    与信中 --> 却下 : 与信NG
    出荷待ち --> 出荷済 : 出荷指示
    出荷待ち --> 取消 : 顧客都合
    出荷済 --> [*]
    却下 --> [*]
    取消 --> [*]

先ほどのクラス図に対応するMermaid版はclassDiagramの記法で書きます。多重度をダブルクォートで囲む点はPlantUMLと共通です。

classDiagram
    class Order {
        -String orderId
        -OrderStatus status
        +totalAmount() Money
    }
    class OrderLine {
        -int quantity
        +subtotal() Money
    }
    class Customer {
        -String customerId
        +creditLimit() Money
    }
    Customer "1" o-- "0..*" Order : places
    Order "1" *-- "1..*" OrderLine : contains

PlantUMLとMermaidの選択基準：実行環境・表現力・成果物の残り方

両者は競合ではなく、置き場所で使い分けます。判断材料を並べます。

観点	PlantUML	Mermaid
実行環境	Java（jarを実行）	Node.js／GitHubは環境不要
最新版（2026年9月時点）	v1.2026.8（2026年9月5日）	11.17.2
対応するUML図	クラス・シーケンス・ユースケース・状態・配置ほか	クラス・シーケンス・状態・ユースケースほか
CIでの構文検証	`-checkonly`で単体実行できる	mermaid-cliでのレンダリング実行が必要
納品物としての図	SVG／PNG／PDF／LaTeXで出力	Markdown同梱が前提（画像化はCLI）

納品する設計書に図を貼るならPlantUMLです。出力形式が多く、-tpdfで体裁の整った成果物にできます。開発チーム内でだけ回すならMermaidで足ります。両方を混在させると記法の差でレビュー時に混乱するため、リポジトリ単位でどちらかに寄せてください。

受託開発の工程別に書く4種類の図と、書かない10種類の切り分け

ここからは判断の話です。UMLは14種類を網羅する対象ではなく、工程ごとに議論の焦点を絞る道具として使います。以下は業務システム・Webシステムの受託開発を前提にした配分です。

要件定義：ユースケース図で対象範囲とスコープの境界線を引く方法

要件定義で書くのはユースケース図1種類です。目的は機能の網羅ではなく、システムの外と内を分ける線を発注側と共有することにあります。アクターとして書いた外部システムや部署が、契約範囲の外側だと明示できます。

ここで詳細に踏み込むと失敗します。ユースケースを50個に分解した図は、発注側が読めません。ユースケース図の書き方で扱っているincludeやextendの関係も、要件定義の合意形成の場では省いて構いません。粒度は「1画面の一連の操作＝1ユースケース」を上限に、10〜20個に収めるのが読まれる範囲です。

基本設計：クラス図とシーケンス図で外部連携の責務を確定する手順

基本設計ではクラス図とシーケンス図を書きます。クラス図はデータ構造の合意用で、テーブル設計と1対1にはしません。テーブル設計はER図の領分で、クラス図は業務上の概念とその関係を表します。両者を混同すると、中間テーブルがそのままクラスになった読めない図ができます。

シーケンス図は全機能には書きません。外部システムとの通信、決済のような失敗時の巻き戻しが要る処理、非同期処理の3つに絞ります。この3つは、文章で書くと「エラー時は再送」の一行で済ませてしまい、実装時に誰がリトライするのかで揉める箇所です。ライフラインとメッセージで書けば、タイムアウト時の責務が図の上で決まります。

詳細設計とテスト：状態遷移図をテストケース設計の根拠にする方法

状態を持つ実体があるなら状態遷移図を書きます。受注・申請・契約・会員資格のように、ステータス列を持つテーブルが設計に現れたら対象です。前掲のMermaidの例では9本の遷移が定義されており、これはそのままテストケースの一覧になります。

価値が出るのは、図に描かれていない遷移が禁止事項として確定する点です。「出荷済から与信中へは戻らない」と決まれば、その遷移を試すテストが異常系のケースになります。状態遷移図と状態遷移表の使い分けで扱っているように、網羅性を確認したいときは表に変換して空欄を潰します。

書かない10種類の判断：配置図とアクティビティ図を例外とする条件

残る10種類は原則として書きません。オブジェクト図・コミュニケーション図・相互作用概要図・タイミング図・コンポジット構造図・プロファイル図・パッケージ図は、業務システムの受託案件でこれらを書いて議論が前進した場面がほとんどありません。

例外は2つです。配置図は、オンプレミスとクラウドをまたぐ構成やネットワーク分離の要件がある案件で、インフラ担当との合意に使えます。アクティビティ図は、承認フローが多段階に分岐する業務で、BPMN代わりに使う場合に限り有効です。コンポーネント図はマイクロサービス構成の全体像に使えることもありますが、実態としてはC4モデルやシステム構成図のほうが読まれます。

UMLを書かない方が安く済む案件条件と、記法より先に決める粒度

UMLを書く前提で見積もると、案件によっては赤字の原因になります。ここは条件を付けて言い切ります。

書かない方が安い3条件：CRUD中心・短期・発注側に読み手がいない

次の条件に当てはまる案件では、UMLの作図工数を見積もりから外してください。

画面の大半がマスタのCRUDで、業務ルールが「必須入力」「重複禁止」程度に収まる案件。クラス図を書いてもテーブル定義書の再掲になります
開発期間が2〜3か月以内で、要件が固まっており、実装者が3人以下の案件。図の維持コストが認識合わせの利得を上回ります
発注側に図を読む担当者がいない案件。ユースケース図を出しても「よく分かりました」で終わり、合意の証拠になりません。この場合は画面遷移図とワイヤーフレームで代替するほうが伝わります

逆に、既存システムの仕様がドキュメント化されていないまま作り直す案件では、UMLを書く工数が回収できます。現行システムの振る舞いをシーケンス図と状態遷移図に起こす作業が、そのまま移行要件の洗い出しになるためです。システムマイグレーション・リプレイスのような刷新案件では、この可視化工程を設計フェーズの前に独立させて見積もることをおすすめします。

記法の正しさより先に決める2点：図の粒度と更新責任の所在と判断基準

作図でもめる原因は記法の誤りではなく、粒度の不統一です。同じ設計書に、システム全体を1枚に収めたクラス図と、1機能を20クラスに分解した図が混在すると、読み手はどの縮尺で読めばよいか分かりません。着手前に「1図あたりのクラスは最大15個」「シーケンス図のライフラインは最大7本」のような上限を決めてください。超えるなら図を分割する合図です。

もう1点が更新責任です。実装フェーズに入ってからクラスを追加したとき、図を直すのは誰か。ここを決めずに始めた設計書は、結合テストの頃には全て嘘になります。テキスト形式で管理し、図の変更をコードと同じプルリクエストに含める運用にすれば、レビュアーが乖離に気づけます。図だけを別フォルダで管理する運用は、更新が止まる典型です。

UMLの学習と導入で実務担当者からよく出る5つの疑問への回答

検索されている質問のうち、実務判断に関わるものへ答えます。

UMLとER図の違いは何ですか？

両者は対象が別です。UMLはシステムの構造と振る舞いを表すモデリング言語で、クラス図は業務上の概念とその関係を表します。ER図はデータベースの実体と関連を表す記法で、正規化やカーディナリティといったテーブル設計の議論に使います。クラス図には操作（メソッド）が書けますが、ER図には書けません。実務では、概念モデルをクラス図、物理設計をER図で分担させ、両者を1対1に対応させないのが定石です。

UMLの図は全部で何種類ありますか？

仕様2.5.1のAnnex Aが列挙しているのは14種類です。内訳は構造図が7種類（クラス・オブジェクト・パッケージ・コンポーネント・コンポジット構造・配置・プロファイル）、振る舞い図が7種類（ユースケース・アクティビティ・ステートマシン・シーケンス・コミュニケーション・相互作用概要・タイミング）です。相互作用図という区分は振る舞い図の下位にあり、シーケンス図を含む4種類がそこに属します。UML 1.xの時代は9種類でした。

UMLは今でも使われていますか？

14種類すべてを書く運用はほぼ残っていませんが、クラス図とシーケンス図の記法は現役です。PlantUMLは2026年9月5日にv1.2026.8がリリースされており、開発は続いています。GitHubのMarkdownがMermaidをレンダリングするようになったことで、むしろ図をテキストで書く機会は増えました。「UMLツールでモデルを一元管理する」使い方が廃れ、「記法だけ借りて軽量に書く」使い方に移ったと捉えるのが実態に近いです。

UMLの準拠レベルはどう確認すればよいですか？

確認する必要はありません。準拠レベルL0からL3はUML 2.5で廃止されました。仕様の6.1に「実務で有用と分からなかったため廃止した」と理由まで書かれています。ツールはUML全体に準拠するかしないかのどちらかで、部分実装ならその範囲をベンダーが宣言すべきだ、というのが現在の仕様の立場です。選定時は、必要な図種が書けるか、XMIで持ち出せるか、テキストで差分が取れるかを見てください。

UMLを無料で書けるツールは何がありますか？

PlantUMLとMermaidが代表格で、どちらもオープンソースです。PlantUMLはjarを実行できる環境があればよく、VS Codeの拡張機能でプレビューできます。MermaidはGitHub上で追加の環境なしにレンダリングされます。GUIで描くならastah* UMLの無償版やdraw.ioがありますが、差分管理ができない点で設計書の維持には向きません。長期に保守する案件ではテキスト形式を選んでください。