TRACERYプロダクトマネージャーの haru です。
2025年10月31日（金）に開催された勉強会『BPStudy#218〜生成AI時代のモデリングとは』の第2部では、浅海智晴氏が提唱する「文芸モデル駆動開発*1」をもとに、「AI時代に向けたモデリング」をテーマとしたパネルディスカッションが行われました。本記事ではその時の様子をお伝えします*2。
第1部の浅海智晴氏の登壇資料：AI時代のソフトウェア開発 文芸モデル駆動アプローチ
生成AI時代のモデリングとは
- その１: 文芸モデル駆動開発の知識表現
- その２: 文芸モデル駆動開発のモデリング〜コード生成の流れ（本記事）
- その３: 文芸モデル駆動開発のクラウドへの対応、コンポーネントベース開発の再定義
- その４: AIの悪影響をできるだけ排除し、開発生産性を高める（近日公開）
- その５: 文芸モデル駆動開発における人とAIの共創（近日公開）
- パネラー：
- 浅海 智晴 (あさみ ともはる) 氏：以下、浅海
- Everforthフェロー、TechFirst Leaders 顧問
- 高崎健太郎(たかさき けんたろう) 氏：以下、高崎
- (株)アクティア COO
- 浅海 智晴 (あさみ ともはる) 氏：以下、浅海
- モデレータ：
- 佐藤 治夫(さとう はるお) ：以下、haru
- (株)ビープラウド代表取締役社長、この記事の筆者
- 佐藤 治夫(さとう はるお) ：以下、haru
知識から分析モデル（文芸モデル）を作成する
haru：プロジェクト単位で整理された知識表現であるBoKコンテンツを、MCP*3やRAG*4を介して生成AIに読み込ませます。
その結果、生成AIが生成するのが「文芸モデル」です。
文芸モデルとは分析モデルであり、具体的にはユースケースやエンティティを指します（下図）。
浅海：知識から文芸モデルを完全に自動生成できるとは考えていません。
文芸モデルの作成は、生成AIと人間が協業するプロセスになると想定しています。
文芸モデルは、生成AIが知識をもとにたたき台を生成し、ビジネスエキスパートがその内容を確認・解釈したうえでモデルの修正や補足を行い、フィードバックを重ねて精度を高めていく、というような役割分担を想定しています（下図）。
haru：ユースケースは、システムに求められる振る舞いや機能を表すもので、いわゆるシステム要求・システム要件に相当します。一方、エンティティは、対象となる現実世界を抽象化したドメインモデルです。
エンティティとユースケースの二種類のモデルを明示的に記述することが、文芸モデル駆動開発の出発点になります。文芸モデルは、浅海さんが考案した「CML（Cozy Modeling Language）」という専用の言語を用いて記述されます。
分析モデルからコンセプトモデルを作成する
haru：
分析モデルを「Cozy*5」というモデルコンパイラが読み込み、その内容を抽象化した上位モデルとして「コンセプトモデル（概念モデル）」を生成します。
分析モデルが具体的な要求や構造を表すのに対し、コンセプトモデルは概念や用語の整理に焦点を当てた、より抽象度の高いモデルです。
このコンセプトモデルをもとに、UMLのモデルや用語集が作成されます。
具体的なモデルの例としては、ユースケース図、アクターゴールリスト、クラス図、コンポーネント図などが想定されています。
浅海：従来の開発では、この流れが逆になっていることが多かったと考えています。すなわち、コンセプトモデル→分析モデル→設計モデルという順で作成する、という流れです。
コンセプトモデルが開発をしているうちに捨てられて、その結果、ドメインエキスパートが頭の中で描いている概念と乖離した成果物が作られてしまう、という問題が生じるという問題です。
分析モデルを基点にすれば、そこからコンセプトモデルを抽出できます。
コンセプトモデル自体はプレインテキストとして表現されますが、そこからUMLのモデルを自動生成することが可能であり、概念と分析との断絶を防ぐことができます。
浅海：今まで話に出てきた知識、コンセプトモデル、分析モデルを、ビジネスエキスパート、開発者、そして AI が同じ立場で参照・更新できる共通のモデルとして扱う、というイメージです。
これにより、立場や役割の違いによる認識のズレを抑えながら、議論と開発を進められるようになります。
分析モデルから設計モデルを作成する
haru：図の縦線の左側は、プラットフォームに依存しないモデルの領域です。
MDA*8のように、技術的制約から切り離された形でビジネスの意図や構造を表現する考え方に基づいています。ここには、ビジネスエキスパートが理解しやすいコンセプトモデルや分析モデルが位置づけられます。
一方、縦線の右側は、具体的な技術や実装を前提とした、開発者に馴染みのある設計モデルの領域です。
先ほど、分析モデルからコンセプトモデルを生成するために使用すると紹介したモデルコンパイラCozy では、分析モデル（ユースケース、エンティティ）に加えて、UI コンテキストやデザインコンテキストといった UI 設計に必要な文脈情報を入力することで、UI シナリオ や UI モック などの UI 系の設計成果物が生成されます。
同時に、Scala で実装されたドメインモデルを表現するエンティティのプログラムやコンポーネントも生成されます。
これが「分析モデル・アップ・ダウン」における「ダウン」に該当する部分です。
浅海：UIで採用する技術は、プロジェクトごとにさまざまです。そのため、バウンダリーモデルという概念を用いて、外部のUI 方法論やツール（図中の 「UI Builder」）と接続するための中継モデルを定義しようと考えています。
バウンダリーモデルに該当するのは、図内のUI シナリオや UI モックです。あらかじめバウンダリーモデルとして生成する内容を定義しておき、それを入力としてUI Builder側で具体的な実装を行ってもらう、という連携を想定しています。
設計モデルから実装を作成する
haru：設計モデルを基点として、実装モデルの生成へと進みます。ドメインモデルに該当する部分については、設計モデルの段階でScalaプログラムとして表現されており、そのまま実装モデルとして利用されます。
UIに関するプログラムは、図中にUI Builderと記載された外部ツールによって生成されます。
一方、ドメインモデル以外の仕様に基づいたビジネスロジックや周辺的なプログラムについては、生成AIが担当します。プログラマーは適宜、それらのプログラムを修正します。
ここまでで、知識から分析モデル（文芸モデル）を作成し、複数のモデル作成を経て実装コードの生成までを行いました。
次回は、文芸モデル駆動開発のクラウドへの対応、コンポーネントベース開発について、話が進みます。
*1:自然言語による語りと形式的なモデル構造を統一されたテキスト基盤上で統合するソフトウェア開発手法。従来のモデル駆動開発（MDD）を拡張し、ドキュメントとモデルを単一の整合的ソースとして扱う。 文芸的プログラミング(Literate Programming)の思想をモデル駆動開発に適用している。文芸的プログラミングとは、ドナルド・クヌースが提唱した、プログラムのソースコードと人間向けの解説文書を一体のものとして開発する手法。 プログラムの実行コードと自然言語の説明を同じファイル内で「WEB」のような形式で記述し、それらを分離・生成することで、人間が理解しやすく、かつ完全に整合性の取れたプログラムと文書を同時に作成することを目指す。機械が読めるコードを「後」に作る一般的なアプローチとは異なり、「本を書くようにプログラムを書く」という哲学に基づいている 参照：https://simplemodeling.org/ja/glossary/literate-modeling/literate-model-driven-development.html 、 https://modegramming.blogspot.com/2020/06/
*2:伝わりやすくする目的で、話の流れを一部再構成しています。
*3:Model Context Protocol。Anthropic社が提唱した、AIモデル（LLM）が外部のツールやデータベースと安全かつ効率的に連携するための**共通の通信規格（プロトコル）。AIが個別のAPI仕様を気にせず、共通のルールで情報（コンテキスト）をやり取りできるようにし、AI活用における開発コストと手間を削減し、機能拡張性を高める。
*4:Retrieval-Augmented Generation（検索拡張生成）の略で、生成AIが回答を生成する際に、外部データベースから関連情報を検索・取得して組み込むことで、回答の精度と信頼性を高める技術です。LLM（大規模言語モデル）の学習データだけでは対応できない最新情報や社内固有の知識（規定、マニュアルなど）に基づいた、より正確で根拠のある回答を生成できるようになり、ハルシネーション（事実に基づかない情報を生成する現象）の抑制にもつながる。
*5:浅海さんが開発したモデルコンパイラ。 https://github.com/asami/cozy
*8:Model-Driven Architectureの略称。OMG（オブジェクト・マネジメント・グループ）が提唱する、UMLなどの標準モデルを用いて、ビジネス要件からソースコードまでを自動生成するソフトウェア開発手法。PIM（プラットフォーム独立モデル）とPSM（プラットフォーム特化モデル）を使い分け、モデルを中核に開発することで、特定の環境に依存せず、変化に強く、効率的なシステム構築を目指す。
