散らかった問題文から、明確で実行可能なクラス図へ——数分で完了。
🎯 AI駆動型テキスト解析とは何か?
Visual ParadigmのAI駆動型テキスト解析は、製品マネージャー、ソフトウェアアーキテクト、開発者らが非構造化された自然言語(例:ユーザーストーリー、要件、システム記述など)を構造化されたドメインモデル——特にUMLクラス図に変換する。

エンティティ、属性、関係を手動で特定する代わりに、AIがテキストを解析し、関連する設計要素を抽出し、修正可能な視覚的モデルを提示します。
🔍 コアとなるアイデア:物語 → 名詞 → クラス → 関係 → 図 —自動的に.
✅ 主な利点
| 利点 | 説明 |
|---|---|
| スピードと効率 | 初期モデリング時間を数時間から数分に短縮する。 |
| 一貫性 | チーム間での主観的解釈を最小限に抑える。 |
| 学習支援 | オブジェクト指向設計を学ぶ初心者開発者に最適。 |
| トレーサビリティ | すべての提案には根拠が含まれており、透明で監査可能。 |
| 段階的改善 | AIから始め、VP Onlineで自由に編集 → コードやドキュメントにエクスポート。 |
| ドメインの発見 | 隠れた概念を浮き彫りにする(例:取引, 監査ログ)は、見落としがちなものです。 |
🛠️ ステップバイステップチュートリアル(実際の例付き)
以下の3つの段階的に複雑な例を順を追って見ていきましょう3つの段階的に複雑な例、シンプルなものから企業向けの高機能なものまで。

📘 例1:図書管理システム(スターター)
📝 ステップ1:問題の説明を提供
- 以下の手順へ進んでくださいツール > アプリ > テキスト解析 > 今すぐ開始
- 入力:
図書管理システム - クリック[問題の説明を生成]
👉 AIが生成:
「図書管理システムは、図書館員が本、会員、貸出を管理できるようにします。会員は本を検索し、一度に最大5点まで借りて返却できます。返却期限を過ぎた本には罰金が発生します。各本にはタイトル、著者、ISBN、利用可能状態があります。図書館員は本の追加・削除が可能で、貸出履歴を確認できます。」
✅ 必要に応じて編集してください — 例:「デジタル電子書籍と予約キューのサポートを提供。」
👥 ステップ2:候補クラスの特定
クリック[候補クラスの特定]
| クラス名 | 理由 | 説明 |
|---|---|---|
本 |
繰り返し言及されるコアエンティティ | 物理的・デジタルな本を表す |
会員 |
行動の対象(貸し出し、返却) | 連絡先情報を持つ図書館利用者 |
貸し出し |
行動名詞 → キー取引 | 会員による本の貸し出しを記録する |
図書館員 |
管理作業を実行する役割 | システムを管理するスタッフ |
罰金 |
貸し出し超過の結果 | 金銭的罰則が発生する |
🔁 参照: 「限定されていない名詞」(例: ステータス, 履歴 → あまりに曖昧または属性的なもの)。
✅ すべて承認する、または削除 図書館員 役割が権限を通じて管理される場合(例:使用して ユーザー + 役割フラグ)。
📋 ステップ3:クラスの詳細を特定する
クリック [クラスの詳細を特定する]
出力例:書籍:
- 属性:
isbn: 文字列
タイトル: 文字列
著者: 文字列
貸出可能: ブール値
形式: 列挙型 {実物, デジタル} - 操作:
貸出可能状態を確認する(): ブール値
貸出済みとしてマークする()
返却済みとしてマークする()
について貸出:
- 属性:
貸出日: 日付
返却期限: 日付
返却日: 日付? - 操作:
延滞日数を計算する(): 整数
罰金を適用する()
💡 プロのヒント: 名前を変更する 利用可能 → 状態: BookStatus (列挙型: 利用可能, 貸出中, 予約済み) 拡張性のため
🔗 ステップ4: クラス関係の特定
クリック [クラス関係の特定]
| From → To | 種類 | 多重度 | 説明 |
|---|---|---|---|
会員 — 貸出 |
合成 | 1 → * | 会員は自分の貸出を所有する |
貸出 — 本 |
関連 | 1 → 1 | 各貸出は1冊の本を含む |
貸出 — 罰金 |
オプションのコンポジション | 1 → 0…1 | 貸出が期限を過ぎると罰金が発生する可能性があります |
⚠️ 注意してください:AIが見逃す可能性があります集約対コンポジション。手動で編集してください貸出すべきです参照(所有しない)書籍.
🖼️ ステップ5:図の生成
クリック[図の生成]→ 完全なUMLクラス図が表示されます!

✅ その後クリック[Visual Paradigm Onlineで開く]に:
- レイアウトの再配置
- スタereotypeの追加(
«エンティティ»,«境界») - ユースケースやシーケンス図へのリンク
- PNG、PDFとしてエクスポートする、またはJava/Pythonのスタブを生成する
🛒 例2:ECサイトのショッピングカート (中級)
入力プロンプト:
「ユーザーが商品を閲覧し、カートに商品を追加し、プロモコードを適用し、クレジットカードまたはPayPalでチェックアウトし、注文を追跡できるオンラインストア。管理者は在庫を管理し、売上レポートを確認する。」
AIが特定したクラス:
ユーザー,商品,ショッピングカート,カートアイテム,注文,支払い,プロモコード,在庫,管理者
注目すべき関係:
ショッピングカート◇——カートアイテム(集約;カートは アイテムを保有していますが、アイテムはカートと共に破棄されません)注文◆——支払い(組成;支払いは注文ライフサイクルの一部です)プロモコード——注文(0…1 → 1;チェックアウト時にオプション)
得られた知見:
AIは次を提案します:カートアイテム を から分離して商品 — よい!なぜなら:
カートアイテムは数量,追加日時、およびスナップショット 価格のスナップショット(価格変更に対応するため)商品は現在価格,在庫数.
➡️ 一般的なモデル化の誤りを防ぐ:混同することをカタログアイテムとカートの商品行.
🏥 例3:病院の予約システム(上級者向け)
入力プロンプト(現実性を高めるために編集):
「患者は医師と予約をスケジュールする。各予約には日時、種類(例:相談、フォローアップ)、状態(予約済み、完了、キャンセル)がある。医師には専門分野と勤務スケジュールがある。システムは予約の24時間前にお知らせを送信する。看護師は患者の受付を行うことができる。検査結果は診察後に添付される。」
AIのポイント:
| クラス | なぜ重要なのか |
|---|---|
予約 |
中心的なワークフロー・オブジェクト |
医師のスケジュール |
から分離医師→ SRP(単一責任の原則)を尊重 |
リマインダー |
外部の振る舞い → 後でイベント駆動型サービスになる可能性 |
検査結果 |
予約に添付予約に患者ではなく予約に — 追跡可能性! |
スマートな関係性:
予約◆——検査結果(1 → 0…*)
→ 強制する:結果は完了した予約に対してのみ存在します。
隠れた貴重品:
AIがマークする:"type"および"status"予約内の → エンムを提案する:
enum 予約タイプ { 相談, 後続訪問, 疫苗接種 }
enum 予約状態 { 予定済み, サービス受付済み, 完了, キャンセル済み }
✅ デベロッパーはドメインの列挙型と検証ロジックを定義する時間を節約できる。
🚀 バリューを最大化するためのプロのコツ
| ヒント | 適用方法 |
|---|---|
| まず曖昧に始め、その後で洗練する | 最初のプロンプト:"フードデリバリー用アプリ"。次に生成された説明を編集して次を追加:「レストランのオンボーディング、ドライバーの割り当て、リアルタイム追跡、評価システムをサポート。」 |
| ユーザーの物語を入力として使用する | 貼り付け:「顧客として、料理の種類と配達時間でレストランを絞り込めるようにしたい。そうすれば迅速に選択できる。」 → AIが抽出する 料理の種類, 配達時間の見積もり, 絞り込み基準. |
| ユースケースモデリングと組み合わせる | テキスト分析を実行する 最初に クラスを取得する → その後、アクターとユースケースを導出する(例:顧客 → 注文する, ドライバー → 場所の更新). |
| CRCカードで検証 | AIがクラスを提案した後は、チームと迅速にCRC(クラス・責任・協働者)会議を行い、妥当性を確認してください。 |
| コードにエクスポート | VP Online では、図を右クリック →ツール > コード > コード生成(Java、C#、Pythonに対応)。 |
⚠️ 制限事項と対処法
| 制限事項 | 対処法 |
|---|---|
過剰に生成する可能性がある(例:日付, 時間クラスとして) |
「修飾されていない名詞」表を確認 → 属性に統合するか、組み込み型を使用する。 |
| ビジネスルールを推論できない(例:「最大3件のローン」) | 制約を次のように追加する:OCL(オブジェクト制約言語)またはメモ:{ maxLoans = 3 } |
| 曖昧な名詞に対応できない | 入力で明確化する:「‘User’は管理者ではなく顧客を指す」または「‘Session’はログインセッションではなく、カウンセリングセッションを意味する。」 |
| デフォルトでは継承を検出できない | 手動で追加する:患者, 医師, 看護師 → 一般化する 人物 必要に応じて。 |
📊 使用するタイミング(最適な状況)
| シナリオ | なぜ優れているか |
|---|---|
| 初期発見ワークショップ | 原始的なメモから迅速にドメインモデルをホワイトボード化 |
| アジャイルスプリント0 / バックログの見直し | グルーミングの前にエピックを候補クラスに変換 |
| 学術プロジェクト / 卒業研究 | 学生は記法ではなく設計論理に注目する |
| レガシーシステムの近代化 | 古いBRD(ビジネス要件書)を入力してドメインモデルを抽出 |
| クロスファンクショナルな整合性 | ビジネスチームと技術チームが共有語彙を検証 |
🌐 次のステップ:図の先へ
AIで生成したクラス図はあくまで始まりにすぎません。Visual Paradigmでは、次のようなこともできます:
- データベーススキーマを生成 → ERD → SQL DDL
- シーケンス図を導出 操作から(例:
Order.checkout()) - 要件にリンク (例:タイ
applyPromoCode()BRDセクション4.2へ) - VPモデルシミュレーションでシミュレート
- Webポータルとして公開ステークホルダーのレビュー用に
📬 最後の考え
「AIはデザイナーを置き換えるのではなく、 面倒な作業.”
テキスト分析を使って 時間の20%でモデルの80%を正しく得るその後、専門知識を 重要な20%:エッジケース、スケーラビリティ、およびドメイン固有のニュアンス。
📎 試してみますか?
→ ランチ: Visual Paradigm Online
→ アプリ: ツール > アプリ > テキスト分析
ご希望があれば教えてください:
- ダウンロード可能なチートシート(PDF)
- フィンテック、SaaS、IoT、またはヘルスケア分野用のテンプレートプロンプト
- 手動によるCRC/ドメインモデリングとの比較
楽しいモデリングを! 🧩













