本記事のポイント
・astah*で作成したモデルをAIに解析させる方法
・XMLエクスポートの手順とAIへの効果的な提供方法
・AIによるクラス図解析の実例紹介
はじめに
皆さん、こんにちは。近年のAI技術の急速な進化により、私たちのモデリング作業も大きく変わろうとしています。今回から始まる「astah x AI連携シリーズ」では、弊社のモデリングツール「astah*」とAIの連携によって生まれる新たな可能性を探っていきます。
第1回となる今回は「AIによるastah*モデルの解析」に焦点を当て、実際にastah*で作成したモデルをAIに読み込ませ、どのような分析や提案が得られるのかを実例とともに解説します。
AIにastah*モデルを読み込ませるには?
今回は、astah*で作成したモデルをAIに解析させるために、モデル情報をXML形式でエクスポートし、それを活用します。※「PlantUMLプラグイン」を使用して、astah*のモデルをPlantUMLコードに出力したデータも活用できます。
1. XMLエクスポートの手順
- astah*で対象のプロジェクトを開く
- メニューから「ツール」→「XML入出力」→「XMLプロジェクトファイル出力」を選択
- 保存先とファイル名を指定してエクスポート

- XMLエクスポートは、astah* professional版でのみ利用可能です。
▶ astah* professional無料トライアル版のダウンロード - 「XMIエクスポートプラグイン」を使用して出力したXMIでも同様の活用は可能です。
(※出力対象モデルに制限があるため、主にクラス図に限定されます)
2. AIへの効果的な提供方法
AI (ChatGPT, Gemini, Claudeなど)にXMLファイルを渡す際、以下の点に留意すると効果的です。
ファイルサイズの考慮
AIのコンテキスト制限により、大規模なモデルは処理しきれない可能性があります。
必要に応じて、対象部分のみを抽出したプロジェクトを作成することも検討しましょう。
明確な役割設定と指示の記述
AIにファイルを提供する際は、次のような明確で具体的な役割や指示を与えましょう。
あなたは優秀なUMLエキスパートであり、XMLで記述されたUMLモデルを専門としています。
UML XMI形式を深く理解し、モデル要素間の関係性を正確に把握できます。
モデリングツールastah*が出力するXML形式のモデル情報を解析し、その構造を理解することができます。この中のクラス図を解析してください。
具体的な質問の準備
単に「解析して」と指示するよりも、「このクラス構造の設計上の問題点は何ですか?」「このクラスに改善すべき箇所はあるか」といった具体的な問いかけを用意すると、より実践的で良い回答を得られます。
実践!AIによるクラス図解析
それでは、AIがどのようにastah*モデルを解析するのか、実例を通して確認していきましょう。
今回は、シンプルな書籍管理システムのモデルを例に、Claude4 Sonnetによる解析を行いました。
以下のAIの回答は、読みやすさのために、趣旨を保ちつつ整形を加えています。
提供した「書籍管理システム」モデル概要

出力したXMLをAIに渡す
astah*から出力したモデル情報のXMLファイルを、AIにそのまま渡します。ファイルアップロードに対応しているAIであれば、ドラッグ&ドロップや添付機能でXMLファイルを直接アップロードできます。
もちろん、XMLファイルの中身をコピーしてテキストとして貼り付ける方法も可能ですが、出力したXMLファイル自体をそのまま渡すほうが手間も少なく、より簡単です。
質問に対する共通の役割設定
あなたは優秀なUMLエキスパートであり、XMLで記述されたUMLモデルを専門としています。
UML XMI形式を深く理解し、モデル要素間の関係性を正確に把握できます。
モデリングツールastah*が出力するXML形式のモデル情報を解析し、その構造を理解することができます。この中のクラス図を解析してください。
クラス図の解析例
質問1:このクラス図の設計上の問題点を指摘してください
[AIの回答]
提供されたXMLファイルを解析し、書籍管理システムのクラス図の設計上の問題点を指摘いたします。
▶ 主要な設計上の問題点
1. クラス間の関連の設計不備
- 問題: UserとBorrowRecordの関連が直接的でない
現在の設計では、UserがborrowHistory(List<BorrowRecord>)を属性として持っているが、UserとBorrowRecordの間に明示的な関連が定義されていません
BorrowRecordがuserIdを持っているにも関わらず、UserクラスとBorrowRecordクラス間の関連線が図に表示されていません - 改善案: UserとBorrowRecord間に1対多の関連を明示的に定義すべきです
2. BookとBorrowRecordの関連不備
- 問題: BookとBorrowRecordの直接的な関連が欠如
BorrowRecordはbookIdを持っているが、BookクラスとBorrowRecordクラス間の関連が定義されていません。これにより、どの本がどの貸出記録に関連しているかが不明確です - 改善案: BookとBorrowRecord間に1対多の関連を定義すべきです
3. Bookクラスの状態管理の問題
- 問題: 本の貸出状態が適切に管理されていない
isAvailable()メソッドはありますが、本の貸出状態を示す属性(例:isAvailableやstatus)がありません。現在貸出中かどうかの状態をどこで管理するかが不明確です - 改善案: Bookクラスに貸出状態を管理する属性を追加すべきです
4. データ型の不適切な使用
- 問題: プリミティブ型の参照
bookIdやuserIdがString型として定義されていますが、通常はより適切な識別子型(例:Long、UUID)を使用すべきです。 XMLではxmi.idref=”1p-be…”でString型を参照していますが、これは設計上適切ではありません
5. ビジネスロジックの不備
- 問題: 貸出・返却の制約が不明確
同一ユーザーが同じ本を複数回借りることができるかどうかの制約が不明
貸出期限の管理ロジックが不完全(returnDateがnullの場合の処理など)
延滞料金の計算ロジックが存在しない
6. メソッドの戻り値型の問題
- 問題: boolean戻り値の意味が不明確
borrowBook()やreturnBook()がbooleanを返すが、失敗時の理由が分からない
例外処理やエラーハンドリングの仕組みが考慮されていない
7. 集約・コンポジション関係の不適切性
- 問題: 関連の多重度と実装の不整合
LibraryとBook/Userの関係で、集約またはコンポジション関係を明確にすべき
現在の1対多の関係では、本やユーザーが複数の図書館に属することができる設計になっている
▶ 推奨される改善案
- 関連の明示的定義: 全てのクラス間の関連を適切に定義
- 状態管理の改善: Bookクラスに貸出状態属性を追加
- エラーハンドリングの改善: 例外クラスや詳細な戻り値型の導入
- データ型の見直し: 適切な識別子型の使用
- ビジネスルールの明確化: 制約条件をモデルに反映
[AI回答ここまで]
総評
AIは単なる表面的な指摘ではなく、UMLの関連線の不備、データ型の適切性、ビジネスロジックの整合性など、実際の設計において重要な観点を網羅的に捉えています。また、各問題点に対して具体的な改善案も提示されており、実務でも有用なレベルの内容といえます。
質問2:このシステムに予約機能を追加するなら、クラス図をどのように拡張すべきですか?箇条書きで教えてください。
[AI回答]
- 書籍管理システムに予約機能を追加する場合のクラス図拡張案
▶ 新規クラスの追加
- Reservationクラス
- 属性
- reservationId: String – 予約ID
- bookId: String – 予約対象の書籍ID
- userId: String – 予約者のユーザーID
- reservationDate: Date – 予約日時
- expirationDate: Date – 予約有効期限
- status: ReservationStatus – 予約状況
- priority: int – 予約順位
- メソッド
- isExpired(): boolean – 予約が期限切れかチェック
- cancel(): boolean – 予約をキャンセル
- fulfill(): boolean – 予約を履行
- 属性
- ReservationStatus列挙型
- 値
- ACTIVE – 有効な予約
- EXPIRED – 期限切れ
- FULFILLED – 履行済み
- CANCELLED – キャンセル済み
▶ 既存クラスの拡張
- Userクラス
- 新規属性
- reservationHistory: List<Reservation> – 予約履歴
- 新規メソッド
- reserveBook(Book): boolean – 書籍を予約
- cancelReservation(Reservation): boolean – 予約をキャンセル
- getActiveReservations(): List<Reservation> – 有効な予約一覧を取得
- 新規属性
- Bookクラス
- 新規属性
- reservationQueue: List<Reservation> – 予約待ち一覧
- 新規メソッド
- getReservationCount(): int – 予約件数を取得
- getNextReservation(): Reservation – 次の予約を取得
- isReservable(): boolean – 予約可能かチェック
- 新規属性
- Libraryクラス
- 新規属性
- reservations: List<Reservation> – 全予約一覧
- 新規メソッド
- addReservation(Reservation): boolean – 予約を追加
- processExpiredReservations(): void – 期限切れ予約を処理
- findReservationByUser(User): List<Reservation> – ユーザー別予約検索
- findReservationByBook(Book): List<Reservation> – 書籍別予約検索
- getReservationQueue(Book): List<Reservation> – 書籍の予約待ち一覧
- 新規属性
▶ 関連の追加
- User ↔ Reservation
- 関連名: makes
- 多重度: User(1) ↔ Reservation(0..*)
- ナビゲーション: 双方向
- Book ↔ Reservation
- 関連名: reserved for
- 多重度: Book(1) ↔ Reservation(0..*)
- ナビゲーション: 双方向
- Library ↔ Reservation
- 関連名: manages
- 多重度: Library(1) ↔ Reservation(0..*)
- ナビゲーション: Library → Reservation
▶ ビジネスルールの考慮事項
- 予約制限ルール
- ユーザーあたりの同時予約可能数の上限設定
- 同一書籍に対する重複予約の禁止
- 既に借りている書籍の予約禁止
- 予約優先順位ルール
- 予約日時順での優先順位設定
- VIPユーザーなどの優先度設定
- 予約有効期限ルール
- 書籍が利用可能になってからの取り置き期間
- 期限切れ時の自動キャンセル処理
▶ 追加検討事項
- 通知機能との連携
- 書籍が利用可能になった際の通知
- 予約期限切れ前の警告通知
- 統計・レポート機能
- 予約状況の統計情報
- 人気書籍の予約ランキング
[AI回答ここまで]
総評
AIの提案は、新しいクラスの追加にとどまらず、既存クラスとの関連性、ビジネスルールの考慮、さらには通知機能や統計機能といった付随する要件まで言及しています。特に、予約機能を追加する際に発生する可能性がある制約やルールを事前に整理している点は、実際のシステム設計において非常に価値の高い視点といえます。実際のシステム開発でも、このレベルの提案であれば、そのまま設計ディスカッションのたたき台として活用できるでしょう。
実践のためのTipsまとめ
・XMLファイルが大きすぎる場合は、関係部分のみを抽出して提供する
・明確かつ具体的なプロンプトを設定することで、精度の高い分析結果を得られる
・AIの回答は必ずしも正解とは限らないため、最終的な判断は設計者自身が行うことが重要
astah* x AI連携を試してみたい方へ
XML出力機能を備えた「astah* professional」の無償トライアルをぜひご利用ください。
astah* professionalの次回アップデート時には、待望のAI連携機能(プラグイン形式)もあわせて提供する予定です。具体的なリリース日や内容については、今後のブログ記事で順次ご紹介してまいりますので、どうぞご期待ください。
また、現在ご利用のライセンスのサポート期間が終了している場合は、最新版へのアップデートのためにも、サポート期間の延長をぜひご検討ください。
次回予告
「astah* x AI連携シリーズ 第1回前編:AIによるastahモデルの解析入門 (クラス図編)」いかがでしたか?
ご意見やご質問があれば、ぜひコメントをお寄せください。
次回は後編として、シーケンス図の解析とAIによる改善提案にフォーカスして解説予定です。
どうぞお楽しみに。