« リプレースとアーキテクチャモダナイゼーシヨンの違いの本質は何なのか? | トップページ | なぜ『図解 線形代数: ストラング流直感的理解』は分かりやすいのか?従来の線形代数との決定的な違い »

2026/04/12

AIエージェントとastahが変える真のモデル駆動開発とは何か

20年前のモデル駆動開発の理想が、AIでついに現実できる気がした。
AIエージェントがastahで描いたUMLとソースコードを同期する「Superpowers-UML」プラグインについて、考えたことをラフなメモ書き。

【参考】
オブジェクト指向でなぜつくるのか 第3版

Pythonではじめるクリーンアーキテクチャ SOLID原則/ドメイン駆動設計/テスト駆動開発を実践 (impress top gear) | Sam Keen, 株式会社クイープ |本 | 通販 | Amazon

UMLモデリングの本質 第2版 | 児玉 公信 |本 | 通販 | Amazon

Amazon.co.jp: UMLモデリング入門 : 児玉 公信: 本

図解即戦力 UMLのしくみと実装がこれ1冊でしっかりわかる教科書 | 株式会社フルネス 尾崎 惇史 |本 | 通販 | Amazon

XAstahさん:「ユーザーの一人が、Obraの「Superpowers」エージェントスキル用の拡張機能であるSuperpowers-UMLをリリースしました。これで、Astah Pro + Claude + Astah Pro MCPプラグインを使用して、AIエージェントがUMLモデルでソフトウェアを設計できるようになります。Superpowers-UMLのインストールはこちら:https://t.co/6WuXX9nP0f #AIagents #SoftwareDesign」 / X


takaakit/superpowers-uml: Superpowers-UML modifies Superpowers to ensure a software development workflow in which AI agents design through UML modeling.

Xユーザーのakipiiさん: 「Astah Pro + Claude + Astah Pro MCP Plugin を組み合わせて、AIエージェントがUMLモデリング+Javaプログラミングまでやってくれるみたい。AIエージェントがどこまでモデリングとプログラミングの作業を代替してくれるのか?」 / X

Xユーザーのakipiiさん: 「@sana_ailovetaku 仰る通りモデルとコードが同期して連動する観点はメリットですね。20年前のモデル駆動開発が本来やりたかったことはモデルからソースコードを吐き出して同期させて構成管理する事だった。ようやく時代が追いついてきた印象です」 / X

【1】astahとAIエージェントでモデル駆動開発させるプラグイン紹介が面白かった。

(引用開始)
Superpowers-UMLはSuperpowersを改良し、AIエージェントがUMLモデリングを通じて設計を行うソフトウェア開発ワークフローを実現します。

超能力に関する主な変更点:

AIエージェントは、ソフトウェア設計[1]を含む仕様をUMLモデルとして表現します。
ユーザーとAIエージェントはUMLモデリングを通じて仕様と設計を共同で改良します[1] 。
AIエージェントは、ユーザーが承認したUMLモデルに基づいて実装計画を作成する。
AIエージェントは、実装されたコードと一致するようにUMLモデルを修正します。
このプロジェクトはフックやサブエージェントといったClaude Code固有の機能に依存しているため、Claude Codeのみがサポートされています。
[1] : 将来的には、仕様と設計の成果物は分離される可能性があります。
(引用終了)

【2】20年前のモデル駆動開発と、Superpowers-UMLの違いは何なのか?

20年前のモデル駆動開発では、UMLモデリングツール上でモデルを手作業で描いた後に、ソースを自動生成してシステム開発するやり方だった。
この手法の弱点は2つある。

1つ目は、仕様変更の取込が非常にやりにくいこと。
ちょっとずつ仕様変更を取り込んでソース自動生成してコンパイルしてリリースして、という手順が当時の開発環境ではかなり時間がかかった。
一番嫌なのは、モデルと同期する必要があるためにソースコードを直接変更できないことだ。
よって、フィードバックループそのものに時間が凄くかかっていた。
だから、WF型開発のように、事前に要件や仕様をガチガチに決めた後にモデルを確定して、ソース自動生成させるやり方がほとんどだったように思う。
正直、モデル駆動のありがたみがあまり感じられなかった。

2つ目は、モデルの構成管理、変更管理がやりにくいこと。
モデルの差分を見たいのだが、モデルそのものはバイナリファイルだったり複雑なXMLなので、それらを履歴管理しても、実際のモデルのどの部分が変更されているのか分かりづらい。
人間が理解できるモデルの差分が見たいのに、その表現力がモデリングツール上では弱かった。
ちょっとしたレイアウトの差分を見たいわけではないのに。

【3】しかし、Superpowers-UMLのようなClaudeCodeとAIエージェントの組み合わせにより、ようやくモデル駆動開発が真の意味で実用的になってきたように思える。
つまり、「AIが設計モデルを理解し、モデルとコードを同期させながら開発を進める」という高度なモデル駆動開発が実現可能になったことだ。

AIエージェントが単にテキストを生成するだけでなく、「UMLモデルを介してソフトウェア設計を行う」というワークフローを定義している。
つまり、astah*が持つモデル情報、たとえばクラス図、シーケンス図などをAIが読み取り、修正・追加を自動でやってくれる。
そして、AIがUMLモデルをベースラインとしてソースコードを自動生成してくれる。
一方、ソースコードの変更を直接やっても、AIがモデルにその変更を取り込んで、AIがUMLモデルとソースコードの1対1対応を保証してくれる。

エンジニアは、ソースコードを直接触ってもいいし、モデルを触ってもいい。
モデルとソースコードの同期はAIが保証してくれる。

【4】AIエージェントがモデル駆動開発を保証してくれるなら、どんなメリットがあるのか?

エンジニア観点のメリットは、膨大なソースコードを逐一見る必要はなく、蒸留されたモデルをによりシステム構造を手早く理解でき設計の判断ができることだろう。
AIエージェントがUMLを介して構造を理解しているため、開発者は「どのクラスがどの機能に責任を持つか」を視覚的なモデルを通じてAIと会話できるので、認知負荷を下げられる。

AIがUMLダイアグラムをリアルタイムで更新・チェックするため、設計書が古くなる「ドキュメントの形骸化」を防げる。
また、モデルに基づいたコード生成により、設計意図を正確に実装に反映できる。

開発者同士のレビューでも、モデルを通じてコミュニケーションできるので、曖昧さを排除し、会話を促進してくれる。

【5】そんなことを考えると、モデル駆動開発の理想がようやく時代に追いついて来たと言えるだろう。
プログラミング作業はほぼAIで代替されている現代では、モデルそのもので会話できる基盤が重要になってきているのではないか。
モデルがあれば、エンジニア同士だけでなく、ソフトウェア開発の知識がない一般ユーザと会話できる基盤があるからだ。

この辺りの発想も深めていきたい。


|

« リプレースとアーキテクチャモダナイゼーシヨンの違いの本質は何なのか? | トップページ | なぜ『図解 線形代数: ストラング流直感的理解』は分かりやすいのか?従来の線形代数との決定的な違い »

astahによるUMLモデリング」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



« リプレースとアーキテクチャモダナイゼーシヨンの違いの本質は何なのか? | トップページ | なぜ『図解 線形代数: ストラング流直感的理解』は分かりやすいのか?従来の線形代数との決定的な違い »