はじめに：なぜこのガイドが実務家に共感されるのか
10年以上にわたり企業向けソフトウェア開発の複雑なネットワークを歩んできた者として、UMLモデリングの初期の頃を、懐かしさとややのいら立ちを混ぜて思い出します。図は学術的な演習のように感じられました——紙の上では美しかったものの、スプリント計画やレガシーコード、ステークホルダーの期待といった現実の複雑さとは無関係でした。
その状況は、統合モデリング言語に対するより実用的でツール支援型のアプローチに気づいたことで変わりました。このガイドは単なる理論的な教科書ではありません。実際にこれらの図を用いて本物の製品をリリースし、クロスファンクショナルチームを統一し、高コストなアーキテクチャ的ミスを防ぐ経験から生まれた、14種類すべてのUML図タイプを簡潔に解説した実践的ガイドです。
初心者の開発者であっても、チームのアーキテクチャ文書を理解しようとしている人、要件ワークショップを主導するプロダクトマネージャー、あるいはモデリングツールを評価するベテランアーキテクトであっても、このリソースはあなたが今いる場所に寄り添います。各図の種類を実用性の観点から探求します——何を解決するのか、いつ効果を発揮するのか、そしてVisual Paradigmのような現代的なAI搭載ツールが、正確さを損なわずに作業を加速させる方法についてです。
説明のない専門用語はなし。目的のない図はなし。ただ、今日すぐに使える明確で実行可能なインサイトだけ。
構造図：システムの静的基盤をマッピングする
構造図は、システムの 静的アーキテクチャ を明らかにします——ソフトウェアの基盤を成すクラス、コンポーネント、インフラストラクチャです。建設が始まる前の図面だと考えてください。
1. クラス図
目的： オブジェクト指向設計の基盤であり、クラス、その属性、操作、関係性を可視化する。
主な概念：
-
クラス： 属性（データ）と操作（メソッド）を持つオブジェクトの種類を表す
-
関係性：
-
関連： インスタンス間の接続（例：「PersonはCompanyで勤務」）
-
継承（一般化）： クラスの特殊化を示す「は〜である」階層
-
集約： 「持つ」関係の全体-部分構成
-
多重度： インスタンス数を定義する（例：0..*、1..1）
-
私が使うとき：
-
初期のドメインモデリングおよび要件分析の段階で
-
コアビジネスロジックの実装中に、動的な参照として使用する
-
新メンバーのコードベース構造へのオンボーディングに使用する
-
リファクタリング時に依存関係の影響を可視化する際
プロテクニック： 実装の詳細に飛び込む前に、高レベルのドメインモデルから始めましょう。焦点を絞りましょう——1つのバウンデッドコンテキストごとに1つの図を用意することで、複雑さに圧倒されるのを防げます。
2. コンポーネント図
目的： モジュール化されたソフトウェアコンポーネントがどのように相互に接続して大きなシステムを構成するかを示し、アーキテクチャ上の境界や依存関係を明確にします。
主な概念：
-
コンポーネント： 交換可能で、カプセル化された単位（ライブラリ、サービス、モジュール）
-
インターフェース： コンポーネント間の相互作用を定義する契約（提供される／要求される）
-
依存関係： 依存関係を示す方向性のある関係
-
ポート： コンポーネントの境界上の明示的な相互作用ポイント
-
コネクタ： コンポーネント間の通信経路
使う場面：
-
マイクロサービスやプラグインアーキテクチャを設計するとき
-
サードパーティとの統合ポイントを文書化するとき
-
エンジニアリングリーダーとのシステム分解ワークショップ中
-
プロジェクト間でのコンポーネントの再利用を計画するとき
実際の成果： プラットフォーム移行中にコンポーネント図を使用したことで、チームは初期段階で隠れた結合を発見でき、数週間分の再作業を回避できました。
3. デプロイメント図
目的： 物理的な実行時アーキテクチャをモデル化します——ソフトウェアアーティファクトがハードウェアノードやネットワークインフラにどのようにマッピングされるかを示します。
主な概念：
-
ノード： 物理的または仮想的なハードウェア（サーバー、コンテナ、エッジデバイス）
-
アーティファクト：デプロイ可能なユニット（実行可能ファイル、データベース、構成ファイル）
-
通信関連：ネットワークリンクとプロトコル
-
デプロイ仕様：アーティファクト配置のルール
-
実行時構成：実行トポロジーの静的ビュー
使用する場面：
-
インフラストラクチャとしてのコード計画においてDevOpsと協業する
-
複数環境のデプロイ（開発／ステージング／本番）を文書化する
-
ハイブリッドクラウドまたはエッジコンピューティングアーキテクチャを可視化する
-
分散システムの問題をトラブルシューティングする
ツールの洞察：現代のツールは、デプロイ図を実際のインフラストラクチャ定義（TerraformやKubernetesのマニフェストなど）と同期することで、ドキュメントと実行のギャップを美しく埋め合わせる。
4. オブジェクト図
目的：特定の瞬間におけるオブジェクトインスタンスとその関係性の具体的なスナップショットを捉える。
主な概念：
-
インスタンス：実際の属性値を持つ具体的なオブジェクト
-
インスタンス仕様：実際のデータを示す名前付きオブジェクト
-
リンク：オブジェクトインスタンス間の実行時接続
-
時間的スナップショット：ある瞬間におけるシステム状態を表す
-
具体的 vs. 抽象：型定義だけでなく、データを示す
使用する場面：
-
ステークホルダーのレビューのために、複雑なデータ関係を説明する
-
現実的な例を用いたクラス図設計の検証
-
テスト中に予期しないオブジェクト間の相互作用をデバッグする
-
QAチーム向けのテストシナリオ文書の作成
クラス図との主な違い：クラス図はテンプレートを定義する；オブジェクト図はそのテンプレートの特定のインスタンスが実際に動作している様子を示す。
5. パッケージ図
目的：大規模なシステムを論理的な名前空間に整理し、モジュール間の依存関係を可視化する。
主な概念：
-
パッケージ：関連するクラス、インターフェース、またはサブパッケージをグループ化するコンテナ
-
依存関係：パッケージ間の方向性を持つ関係
-
パッケージのマージ：複数のソースからの要素を統合する
-
レイヤードアーキテクチャ：階層構造を持つアプリケーション構造を可視化する
-
名前空間管理：大規模な環境での名前衝突を防ぐ
使用する場面：
-
モノレポまたはマルチモジュールプロジェクトの構造化
-
新規エンジニアにアーキテクチャ層を伝える
-
リファクタリング中に依存関係の境界を管理する
-
マイクロサービス移行のためのモジュール抽出の計画
ベストプラクティス：エンタープライズアーキテクチャ計画の初期段階でパッケージ図を使用する——コードを書く前から「スパゲッティ依存関係」を防ぐことができる。
6. コンポジット構造図
目的：複雑なクラスやコンポーネント内の部品、ポート、接続子の内部的な協調動作を明らかにする。
主な概念：
-
部品: 全体を構成する構成要素
-
ポート: 外部通信のための定義されたインタラクションポイント
-
コネクタ: 部品間の協働を可能にするリンク
-
役割: 各要素に割り当てられた責任
-
内部構造: 分類子の構成に関するミクロレベルの視点
使用するタイミング:
-
戦略や観察者などの複雑なパターンを設計する際
-
貢献者導入のためのフレームワーク内部のドキュメント作成
-
イベント駆動型システムにおける実行時協働のモデル化
-
レイヤードアーキテクチャにおける委譲関係の明確化
上級テクニック: 複雑な協働の構造と振る舞いを両方示すために、シーケンス図と組み合わせる。
7. プロファイル図
目的: カスタムスタereotype、タグ付き値、制約を通じて、ドメイン固有のUML拡張を可能にする。
主な概念:
-
スタereotype: 特定のドメイン向けにカスタム拡張されたUMLメタクラス
-
タグ付き値: スタereotypeに付随する追加メタデータ
-
メタクラス: 拡張されている標準のUML要素
-
プロファイル: ドメイン向けに選別されたスタereotypeのコレクション
-
制約:有効なステレオタイプ使用を規定するルール
私が使うとき:
-
規制産業（医療、金融）向けにUMLを適応する
-
プラットフォーム固有のモデリング規約の作成（JEE、.NET）
-
ドメインエキスパート向けの内部DSLの構築
-
標準のUML表記が表現力不足のとき
ツールの利点:AI駆動のプロファイル生成は、ドメイン記述に基づいて関連するステレオタイプを提案でき、カスタマイズを加速します。
振る舞い図：動的システム相互作用の記録
振る舞い図は、システムが時間とともにどのように動作するか—静的構造に生命を吹き込むワークフロー、状態変化、メッセージ交換を表す。
8. ユースケース図
目的:ユーザーの視点からシステム機能を記述し、アクターを対象となる機能にマッピングする。
主な概念:
-
アクター:システムとやり取りする外部エンティティ（ユーザー、システム）
-
ユースケース:ユーザー価値を提供する機能の離散単位
-
システム境界:範囲と所有権を定義する長方形
-
関連:アクターと関連するユースケースを結ぶ線
-
関係:
-
包含:一つのユースケースを別のユースケース内で必須で再利用する
-
拡張:基本ユースケースを拡張するオプションの振る舞い
-
一般化:アクターまたはユースケース間の継承
-
使用する場面：
-
製品チームおよびビジネスチームとの要件ワークショップの進行
-
スプリント計画用の共有「機能メニュー」の作成
-
プロジェクト開始時に範囲の境界を特定する
-
非技術的ステークホルダーへのシステム機能の説明
ベストプラクティス：ユースケースを機能指向ではなく、目的指向（「注文を提出する」）に保つ。詳細なフローは別途文書化する。
9. アクティビティ図
目的：順次的および並列的なアクティビティフローを通じて、ワークフロー、ビジネスプロセス、アルゴリズム論理をモデル化する。
主な概念：
-
アクティビティ：アクションステップまたは処理ユニット
-
制御フロー：実行順序を定義する矢印
-
決定ノード：条件分岐のためのダイアモンド
-
マージノード：代替パスの再収束点
-
フォーク／ジョインノード：並列または同時アクティビティのモデル化
-
初期／最終ノード：開始点および終了点
-
スイムレーン：役割またはシステムに責任を割り当てるパーティション
-
オブジェクトノード：アクティビティ間のデータフローを表す
使用する場面：
-
複雑なビジネスルールまたは承認ワークフローの文書化
-
実装前にアルゴリズムの論理を可視化する
-
複数のシステム境界にわたるユーザー体験のステップをマッピングする
-
ボトルネックや並列化の機会を特定する
パワーフィーチャー： スイムレーンは、複数の機能領域にわたるプロセスの所有権を明確に示す——DevOpsおよびアジャイルチームの整合に不可欠である。
10. 状態機械図（状態図）
目的： オブジェクトのライフサイクルを、状態、遷移、および変化を引き起こすイベントを通じて示す。
主な概念：
-
状態： オブジェクトが制約を満たすか、活動を実行している状態
-
遷移： 状態の変化を示す有向エッジ
-
イベント： 遷移を開始するトリガー（信号、時間、条件）
-
アクション： 遷移中または状態内で実行される操作
-
初期／最終状態： ライフサイクルの入力および出力ポイント
-
ガード： 遷移の有効／無効を制御する論理条件
-
エントリ／エグジットアクション： 状態の境界に束縛された活動
使用する場面：
-
UIコンポーネントの挙動をモデル化する（有効／無効／ロード中）
-
注文のライフサイクル管理を設計する（保留 → 出荷済み → 配達完了）
-
プロトコルの状態機械を実装する（TCP、認証フロー）
-
リアクティブシステムにおける予期しない状態遷移のデバッグ
実際の影響： 状態図により、アップグレード中における支払い失敗などのエッジケースを明示的にモデル化したことで、サブスクリプションシステムに深刻なバグが発生するのを防ぐことができた。
11. シーケンス図
目的： オブジェクト間の相互作用を時間の経過とともに詳細に示し、メッセージやメソッド呼び出しの時系列順序に注目する。
主な概念：
-
ライフライン： 時間の経過に沿って参加者を表す垂直の破線
-
アクティベーションバー： オブジェクトが実行中であることを示す長方形
-
メッセージ： 通信を示す水平の矢印：
-
同期的： 実線矢印（呼び出し元は応答を待つ）
-
非同期： 矢印の先が開いている（ブロッキングしない呼び出し）
-
戻り： 応答の流れを示す破線矢印
-
-
時間軸： 時間的な順序を表す垂直方向
-
結合フラグメント： ループ、選択肢、並列領域を表すボックス
-
自己メッセージ： オブジェクトが自分自身に対して呼び出す操作
使用する場面：
-
開発チーム向けの複雑なユースケースシナリオを詳細に記述する
-
API契約やマイクロサービス間の相互作用を文書化する
-
ラス条件や予期しない呼び出し順序のデバッグ
-
エンジニアを重要なシステムワークフローにオンボーディングする
プロのテクニック： 図ごとに1つのハッピーパスに注目する。可読性を保つために結合フラグメントは控えめに使用する。
12. コミュニケーション図（協調図）
目的： 相互作用するオブジェクトの構造的組織とそれらが交換するメッセージに焦点を当てる。
主な概念：
-
オブジェクト： ラベル付きの長方形として表現される参加者
-
リンク： メッセージを交換するオブジェクトを結ぶ線
-
メッセージ： 順序と方向を示す番号付き矢印
-
順序番号： ネストされた呼び出しに使用する階層的番号（1、1.1、1.2）
-
構造的焦点： いつではなく、どのオブジェクトが協働するかに注目する
-
意味的同等性： 順序図と入れ替え可能
使用するタイミング：
-
正確なタイミングよりもオブジェクト間の関係が重要となる場合
-
単純な相互作用のコンパクトな概要を提供する
-
構造的視点から順序図を補完する
-
アーキテクチャレビュー中に協働パターンを検討する
トレードオフの認識： 「誰が誰に話しているか」を把握しやすいが、複雑な時間的シーケンスを追うのは難しい。視聴者のニーズに応じて選択する。
13. 相互作用概要図
目的： 相互作用の流れを高レベルで示すロードマップを提供し、アクティビティ図の制御フローと詳細な相互作用図への参照を統合する。
主な概念：
-
相互作用の発生： 詳細な順序図または通信図への参照
-
制御フロー： 相互作用ノード間のアクティビティ図スタイルの矢印
-
決定/マージノード： 相互作用間の条件付きルーティング
-
フォーク/ジョインノード： 並行する相互作用の分岐
-
抽象化レイヤー： 明確さのためにメッセージレベルの詳細を隠す
-
ナビゲーション： 下位の詳細な図へのハイパーリンク
使用する場面：
-
経営層のステークホルダーにエンドツーエンドのユーザー体験を提示する際
-
数十の相互作用シナリオを伴う複雑なシステムをナビゲートする際
-
大規模なエンタープライズアプリケーションのドキュメントセットを構造化する際
-
高レベルのプロセスマップと技術的な相互作用仕様を橋渡しする際
戦略的価値： 相互作用ドキュメントの「目次」として機能する—スケーリングされた維持管理において不可欠である。
14. 時間図
目的： 明確な時間間隔における正確なタイミング制約と状態変化に焦点を当てる。リアルタイムシステムには不可欠である。
主な概念：
-
軸の反転： 時間は左から右に進む（上から下ではなく）
-
ライフラインの区画： 各オブジェクトまたは状態変数ごとに専用の垂直領域
-
状態タイムライン： 時間経過に伴う状態遷移の視覚的表現
-
期間制約： 遷移または状態における明示的な時間制限
-
時間観測： 重要な時間的チェックポイントのマーカー
-
破壊発生：オブジェクトが存在を終えるポイント
私が使うとき:
-
ハードリアルタイム要件を持つ組み込みシステムの設計
-
IoTデバイスにおけるハードウェア・ソフトウェア間の合図のモデル化
-
分散システムにおけるパフォーマンスSLAの検証
-
プロトコルのタイミング仕様の文書化
ニッチだが重要な点:すべてのプロジェクトで必要というわけではなく、ミリ秒単位の時間に影響する場合にのみタイミング図は不可欠である—時間の制約が契約の一部となるシステムでは見過ごさないでください。
要約表：クイックリファレンスガイド
| 図の種類 | カテゴリ | 焦点 | 主な用途 |
|---|---|---|---|
| クラス | 構造 | 静的型と関係 | システム設計のブループリント |
| コンポーネント | 構造 | ソフトウェアコンポーネント | アーキテクチャ計画 |
| 展開 | 構造 | ハードウェアおよびソフトウェアの配置 | インフラ設計 |
| オブジェクト | 構造 | インスタンスのスナップショット | 例の検証 |
| パッケージ | 構造 | 組織と依存関係 | 大規模システムの組織化 |
| 複合構造 | 構造 | 内部構造 | 詳細なコンポーネント設計 |
| プロファイル | 構造 | UML拡張 | ドメイン固有のモデリング |
| ユースケース | 振る舞い | ユーザーとシステムの相互作用 | 要件収集 |
| アクティビティ | 振る舞い | ワークフローとプロセス | ビジネスプロセスモデリング |
| 状態機械 | 振る舞い | オブジェクトのライフサイクル | 反応型システム設計 |
| シーケンス | 振る舞い | 時間順序付きの相互作用 | 詳細なシナリオモデリング |
| 通信 | 振る舞い | 構造的相互作用 | オブジェクトの協調 |
| 相互作用の概要 | 振る舞い | 高レベルの相互作用フロー | 図間のナビゲーション |
| タイミング | 振る舞い | 時間制約 | リアルタイムシステム設計 |
現場で実証されたベストプラクティス
-
シンプルに始め、慎重にスケーリングする：すべてのプロジェクトで14の図すべてが必要というわけではありません。クラス図とユースケース図から始め、複雑性が求められる段階で他の図を追加してください。
-
完璧さより一貫性を重視する：わずかに不完全でも一貫性のある図のセットは、他の図と矛盾する完璧な1つの図よりも価値があります。
-
早期に協働し、頻繁に反復する：開発者、テスト担当者、ビジネス関係者とドラフトを共有してください。彼らのフィードバックが実際に使われる図を形作ります。
-
ツールを賢く活用する：現代のAI支援ツールは自然言語から初稿を生成できますが、意味的正確性のためには人間によるレビューが不可欠です。
-
「なぜ」を文書化する：設計の根拠を記録するためにノートや制約を使用してください。図が示す内容だけでなく、なぜその選択がされたのかを記録することが重要です。
-
モデルを常に更新する：図を生きている資産として扱いましょう。コードと並行して更新することで、ドキュメントおよびコミュニケーションツールとしての価値を維持できます。
-
対象に合わせて調整する：経営陣向けの図は成果と範囲に注目します。エンジニア向けの図は技術的詳細を含みます。対象に応じて詳細度を調整してください。
結論：UMLを理論からチームの強力な武器へと変える
さまざまなモデル化アプローチを試行錯誤した数年間を経て、UMLの真の力は完璧な図を作ることにあるのではなく、共有された理解を育むことにあります。複雑なアーキテクチャ的決定が、ステークホルダーがその可視化を目にした瞬間に理解されたとき——それがUMLの価値が発揮される瞬間です。
このガイドは、14種類の図を学術的な演習としてではなく、明日から使える実用的なツールとして紹介しました。クラス図でドメインロジックを明確にし、ユースケース図で要件を一致させ、シーケンス図でレースコンディションをデバッグする際など、それぞれがコミュニケーションツールキットにおいて明確な役割を果たします。
私の個人的なワークフローの進化：現在、プロジェクトの開始段階でスコープを合わせるために軽量なユースケース図とパッケージ図から始め、デザインスプリント中にクラス図とコンポーネント図を段階的に追加しています。複雑な機能では、タイミングを確認するためのシーケンス図と構造を把握するためのコミュニケーション図を併用します。デプロイメント図とタイミング図は、インフラ構成計画やパフォーマンスが重要なモジュールで活用されます。
AIの利点：Visual ParadigmのAI搭載ジェネレーターのようなツールは、私のワークフローを変革しました。平易な英語で要件を記述し、クラス図やシーケンス図の初版を取得することで、正確さを損なうことなく探索を加速できます。重要なのは、AIの出力を最終的な成果物ではなく、改善の出発点として扱うことです。
最後の励まし：UMLに圧倒されないでください。現在の課題を解決できる1つの図形式から始めましょう。共有し、改善を繰り返してください。自信がついてきたら、活用する図の種類を広げていきましょう。目標は、図の習得そのものではなく、より明確なコミュニケーション、誤解の減少、そしてより迅速なソフトウェアの提供です。
💡 思い出してください：最も良いUML図とは、読まれ、理解され、実行される図です。シンプルさ、関連性、協働性は、常に詳細な記述よりも優れています。
目的を持ってモデル化する。明確に伝える。自信を持って構築する。🚀
参考
- Visual Paradigm UMLツールの機能：Visual ParadigmのUMLモデリング機能の詳細な概要。すべての13種類の標準UML図のサポート、コード工学、企業統合機能を含む。
- AI搭載UML図生成ガイド：自然言語による記述からVisual ParadigmのAIツールを活用してUML図を生成するためのステップバイステップチュートリアル。実践的な例とワークフローのヒントを含む。
- AI UML図生成ポータル：Visual ParadigmのAI支援図生成機能への別ルートアクセス。テキストから図への変換を可能にし、迅速なプロトタイピングを実現。
- UML AI搭載モデリングの完全ガイド：人工知能がUMLモデリングワークフローをどのように変革しているかを詳細にレビュー。Visual ParadigmのAI統合に関する事例研究と実践的な実装戦略を含む。
- ソフトウェア開発者向けVisual Paradigm：開発者中心のガイド。Visual Paradigmのコード工学、アジャイル統合、現代のソフトウェアチーム向けモデリングのベストプラクティスを強調。
- AIクラス図ジェネレーターのチュートリアル（動画）：Visual ParadigmのAI支援クラス図生成の動画デモ。プロンプト設計、改善、エクスポートワークフローを段階的に説明。
- AIクラス図ジェネレーターのリリースノート：Visual ParadigmのAIクラス図ジェネレーターの公式リリースドキュメント。機能、使用方法、デスクトップ環境との統合について詳細に記載。
- AI UMLジェネレーターの基礎：テキストから図へ：Visual Paradigmのテキストから図へのAIの使い方を基礎から説明。対応する図の種類、プロンプトのベストプラクティス、出力のカスタマイズオプションを網羅。
- AIモデリングチャットボットインターフェース：会話形式でのモデル改善を目的としたインタラクティブなAIチャットボット。手動のドラッグアンドドロップなしで、自然言語によるUML図の編集を可能にする。
- AIパッケージ図ジェネレーターの更新：AI搭載パッケージ図生成のリリース発表。大規模システムの構成や依存関係管理における利用事例を含む。
- OpenDocsによるAIプロファイル図生成：カスタムスタイレ、タグ付き値、ドメイン固有の制約を備えたUMLプロファイル図のAI支援作成を可能にする専用機能。
- AIモデリングチャットボットデモ（動画）: Visual ParadigmのAIチャットボットを活用した会話型モデル編集の動画紹介。自然言語による構造的編集および関係性の修正を実演。
- TOGAFを活用した企業アーキテクチャにおけるAI: AI駆動のUMLモデリングをTOGAF ADMおよびArchiMateと統合し、企業規模のアーキテクチャ計画を実現する上級チュートリアル。
- AIデプロイメント図の例：スマートシティ交通: AIプロンプトエンジニアリングを活用して、スマートシティ交通管理システムのデプロイメント図を生成する実践的な例。
- AIクラス図の精練デモ（動画）: Visual Paradigm内で、反復的なプロンプト入力と手動調整を用いてAI生成されたクラス図を精練する方法を紹介する動画チュートリアル。
- AIアーキテクチャ要素管理（動画）: AIコマンドを活用してアーキテクチャ要素を再編成し、レイヤー間でコンポーネントを移動し、動的に新しい接続を確立するデモ。
- AIユースケース図の精練ツール: シナリオ分析に基づき、自動的に「include」と「extend」関係を提案することで、ユースケース図を強化する専用AIツール。
- AIアシストUMLクラス図生成機能ページ: Visual ParadigmのAIアシストクラス図作成向けガイド付きウィザードについて、範囲定義、エンティティの分離、検証ステップを含む詳細を記載した製品ページ。
- AIクラス図生成ツールインターフェース: 要件から検証済みモデルまで、ステップバイステップのガイド付きでAIアシストクラス図生成ツールに直接アクセス可能。
- TOGAFツールを活用した企業アーキテクチャの最適化: 企業計画のため、Visual ParadigmのUMLおよびAI機能をTOGAFアーキテクチャ開発手法と統合するためのガイド。
- AIアシストクラス図生成ツール（別リンク）: AIクラス図生成機能ページへの冗長リンク。オブジェクト指向設計ワークフローの加速におけるその役割を強調。
- AI図生成の概要: Visual ParadigmのAI図生成機能のハイレベルな概要。複数のUML図タイプおよび利用事例における対応を網羅。
- AIアクティビティ図をデスクトップにインポート: クラウドインターフェースからAI生成されたアクティビティ図をVisual Paradigm Desktopにインポートするためのワークフローを説明するリリースノート。
- AI生成図のエクスポートオプション（動画）: AI生成図のエクスポート形式を紹介する動画チュートリアル。PlantUMLスクリプト、SVG画像、バージョン管理統合用のJSONを含む。