TRACERY Lab.(トレラボ)

TRACERY開発チームが、要件定義を中心として、システム開発で役立つ考え方や手法を紹介します。

AIの悪影響をできるだけ排除し、開発生産性を高める〜生成AI時代のモデリングとは その4

TRACERYプロダクトマネージャーの haru です。

2025年10月31日(金)に開催された勉強会『BPStudy#218〜生成AI時代のモデリングとは』の第2部では、浅海智晴氏が提唱する「文芸モデル駆動開発*1」をもとに、「AI時代に向けたモデリング」をテーマとしたパネルディスカッションが行われました。本記事ではその時の様子をお伝えします*2

第1部の浅海智晴氏の登壇資料AI時代のソフトウェア開発 文芸モデル駆動アプローチ

文芸モデル駆動開発の全体像(浅海氏の資料を元に筆者が作成)

生成AI時代のモデリングとは

  • パネラー
  • モデレータ
    • 佐藤 治夫(さとう はるお) :以下、haru

文芸モデル駆動開発の価値

haru:これまでの議論を踏まえ、文芸モデル駆動開発がもたらす価値を整理します。

第一に記述の基盤をテキストとすることで、人とAIが同じ一次情報を共有し、協調できる基盤が実現する点です。テキストは人にとって読み書きしやすいだけでなく、AIにとっても直接解釈可能な形式です。そのため、MCPなどを通じて、知識やモデルをAIに円滑に受け渡すことができます。

第二に、テキストからコンセプトモデル(概念モデル)をはじめとするビジュアルな成果物が生成される点です。テキストだけでは把握しにくい構造や関係性を、図として可視化することで、人は直観的に理解できます。文芸モデル駆動開発は、テキストの柔軟さとビジュアル表現の理解しやすさを補完関係として統合しています。

第三に、コンセプトモデル、分析モデル、設計モデル、実装モデルが相互の関係性を保ったまま自動的に生成される点です。これにより、モデル間のトレーサビリティが確保され、全体としての一貫性が維持されます。人手でモデルを変換する場合に生じがちな分断や解釈のズレを構造的に防げることが、大きな価値です。

BDD(Behavior Driven Development:振る舞い駆動開発)の活用

haru:一貫性の観点から見ると、実装レベルのプログラムに変更が入った場合、その変更をどのような仕組みで設計モデルや分析モデルといったモデルに反映させるのでしょうか。

人手による追従では限界がありそうですね。

浅海BDD*3の活用を前提に考えています。

BDDで振る舞いの仕様を定義する(図の中央付近)

実装はBDDで記述した仕様に基づいて動作しますが、開発の途中で仕様より先にプログラムを修正すると、仕様と実装の間に不整合が生じます。その結果、BDDで定義した仕様が動作しなくなり、乖離が顕在化します。

この不整合を生成AIに検出させ、差分として明らかになった内容を仕様、すなわちBDDに反映します。さらに、その仕様の背後にあるユースケースなどの上流モデルについても、生成AIの支援を受けながら不整合を検出し、順次反映していきます。

このように、実装の変更を起点として下流から上流へと整合性を回復していくことで、モデル全体の一貫性を保つことを狙っています。

haru:AIが不整合を検出してくれる、ということですね。

AIの悪影響をできるだけ排除し、開発生産性と品質を高める

haru:文芸モデル駆動開発の価値として先ほどモデル間の「一貫性」が挙げましたが、さらに四点目として、「開発生産性の向上」があると考えられます。

分析モデルから設計モデルに至るまで意味的な一貫性が保たれていることで、生成AIは前提を補完・推測する必要がなくなり、モデルに忠実な実装を直接生成しやすくなります。

その結果、生成AIによる実装後の修正や仕様確認といった手戻りが減り、開発者は本来注力すべき設計判断や価値検討に時間を割けるようになります。

このように文芸モデル駆動開発は、モデルの一貫性を土台として生成AIの能力を最大限に引き出し、品質の担保と同時に開発全体の生産性を構造的に高めるアプローチであると言えます。

浅海全体の根底にある思想は、AIの悪影響をできるだけ排除することにあります。

AIは誤る存在である以上、判断や意味づけの中心を担わせるべきではなく、過度に依存することは避けるべきだと考えています。

一方で、構造が明確で、人の意図を機械的に展開できる領域については、AIを積極的に活用する価値があります。

この前提に立つと、エンティティのように構造化しやすい要素は、ほぼ自動生成が可能になります。周辺のアダプターを最小限に記述することだけで済むでしょう。

一方で、ユースケースは、業務の意図や判断の背景を含むため、人が主導して記述すべき部分が多く残ります。

このように、人が担うべき意味解釈の領域と、AIに任せられる構造展開の領域を切り分けることで、AIの利便性を活かしつつ、その悪影響を抑え込むことができます。(下図)

人が担うべき意味解釈の領域と、AIに任せられる構造展開の領域

これが、文芸モデル駆動開発におけるAI活用の基本的な考え方です。

次回は、文芸モデル駆動開発における人とAIの共創について話が進みます。

この記事を書いた人
haru

佐藤治夫。株式会社ビープラウド代表取締役社長。TRACERYのプロダクトマネージャー。エンジニアとして活動を始めて以来、モデリングを中心としたソフトウェアエンジニアリングを実践している。Xアカウント: https://x.com/haru860

*1:自然言語による語りと形式的なモデル構造を統一されたテキスト基盤上で統合するソフトウェア開発手法。従来のモデル駆動開発(MDD)を拡張し、ドキュメントとモデルを単一の整合的ソースとして扱う。 文芸的プログラミング(Literate Programming)の思想をモデル駆動開発に適用している。文芸的プログラミングとは、ドナルド・クヌースが提唱した、プログラムのソースコードと人間向けの解説文書を一体のものとして開発する手法。 プログラムの実行コードと自然言語の説明を同じファイル内で「WEB」のような形式で記述し、それらを分離・生成することで、人間が理解しやすく、かつ完全に整合性の取れたプログラムと文書を同時に作成することを目指す。機械が読めるコードを「後」に作る一般的なアプローチとは異なり、「本を書くようにプログラムを書く」という哲学に基づいている 参照:https://simplemodeling.org/ja/glossary/literate-modeling/literate-model-driven-development.htmlhttps://modegramming.blogspot.com/2020/06/

*2:伝わりやすくする目的で、話の流れを一部再構成しています。

*3:Behavior Driven Development:振る舞い駆動開発は、システムが「どのように振る舞うべきか」を中心に据えて、仕様の記述・実装・テストを一体として進める開発アプローチ。BDDでは、機能要件を「振る舞い」として自然言語に近い形式で記述する。代表的には、Given(前提)、When(操作・出来事)、Then(期待される結果)という構造を用い、「ある前提のもとで、何をすると、どうなるか」を明確に表現する。この記述は、人が読んで理解できる仕様であると同時に、自動テストとして実行可能な形式になる。BDDの特徴は、仕様そのものが実装の正しさを検証する基準になる点にある。実装はBDDで記述された仕様を満たすように作られ、仕様と実装に乖離が生じれば、テストの失敗として検出される。そのため、「仕様書は存在するが実装とはズレている」という状態を構造的に防ぐことができる。またBDDは、開発者だけでなく、企画担当者や業務担当者とも共有できる言語で仕様を記述できるため、関係者間の認識のズレを早期に発見しやすい。