TRACERYプロダクトマネージャーの haru です。
2025年10月31日（金）に開催された勉強会『BPStudy#218〜生成AI時代のモデリングとは』の第2部では、浅海智晴氏が提唱する「文芸モデル駆動開発*1」をもとに、「AI時代に向けたモデリング」をテーマとしたパネルディスカッションが行われました。本記事ではその時の様子をお伝えします*2。
第1部の浅海智晴氏の登壇資料：AI時代のソフトウェア開発 文芸モデル駆動アプローチ
生成AI時代のモデリングとは
- その１: 文芸モデル駆動開発の知識表現
- その２: 文芸モデル駆動開発のモデリング〜コード生成の流れ
- その３: 文芸モデル駆動開発のクラウドへの対応、コンポーネントベース開発（本記事）
- その４: AIの悪影響をできるだけ排除し、開発生産性を高める（近日公開）
- その５: 文芸モデル駆動開発における人とAIの共創（近日公開）
- パネラー：
- 浅海 智晴 (あさみ ともはる) 氏：以下、浅海
- Everforthフェロー、TechFirst Leaders 顧問
- 高崎健太郎(たかさき けんたろう) 氏：以下、高崎
- (株)アクティア COO
- 浅海 智晴 (あさみ ともはる) 氏：以下、浅海
- モデレータ：
- 佐藤 治夫(さとう はるお) ：以下、haru
- (株)ビープラウド代表取締役社長、この記事の筆者
- 佐藤 治夫(さとう はるお) ：以下、haru
クラウドプラットフォームへの対応
haru：文芸モデル駆動開発には、クラウドプラットフォームへの対応という観点もあります。「Simple Modeling Reference Profile」 にはどのようなことが定義されるのでしょうか（下図）。
浅海：AWSやGoogle Cloud、Azureといった特定のクラウドサービスに依存した定義ではなく、より抽象度の高いクラウドプラットフォームについて定義します。
そのうえで、Scalaの内部DSLが備える多様な表現力を活用し、それらの定義を入力として、設計モデルや実装コードを自動生成していくことを想定しています。
haru：それが「Scala+Cloud Native Component Framework」ですか？
浅海：はい。Scala と Cloud Native Component Framework を抽象レイヤーとして位置づけ、その下位に各クラウドプラットフォーム向けの具象的なアダプターを定義する構成を採用します。
各クラウドには多様なミドルウェアやサービスが存在し、その選択や利用方法は要件や環境によって異なりますが、こうした差異はすべてアダプター層に閉じ込める想定です。
コンポーネントベース開発
高崎：浅海さんのお話の中で、コンポーネントベース開発に関する話題として、外部のコンポーネントを利用することや、社内のコンポーネントをライブラリとして整備しておくといった説明があったと思います。
その点が、文芸モデル駆動開発の全体像の図（下図）ではどこに位置づけられるのか、少し気になりました。
浅海：文芸モデル駆動開発の全体像としてあげられている図ではCBD（Component-Based Development：以降CBD）の観点は意図的に省略されているのではないでしょうか。
全体の構成を見ると、図で示されている流れとは別のレイヤーで、コンポーネント活用の視点が位置づけられるのではないかと思います。
浅海：AI時代において CBD（Component Based Development）を再定義するうえで、最も重要なのはコンポーネントの再利用性です。
新規開発を最小限に抑え、既存資産を最大限に活かすためには、AIを活用して既存コンポーネントを的確に発見し、正しく理解し、安全に適用できる状態を整えることが不可欠になります。
その前提として、設計意図や利用条件といった知識を、AIが解釈・活用可能な形でプロジェクト内に整備しておく必要があります。
AI時代においてコンポーネントを軸に開発方法論を考えているのには、次の三つの理由があります。
第1に、コンポーネントは入出力の定義が精密に行われ、カプセル化によって内部と外部の境界が明確である点です。
AIは、文脈や仕様が明確に定まっている場合には非常に高い能力を発揮しますが、曖昧な状態では仕様理解に失敗し、最悪の場合、正常な処理を破壊するようなコードを生成してしまう危険性もあります。
コンポーネントという単位は、設計意図や利用条件を明確に定義しやすく、AIの機能不全や暴走を防ぐための「制御可能な境界」として理想的な構造を持っています。
第2に、コンポーネントのカプセル化によって、AIによる誤った修正やソース破壊が起きた場合でも、その影響範囲を限定できる点です。
被害をコンポーネント内部に閉じ込めることができるため、システム全体への波及を防ぎやすくなります。これは、AIを開発プロセスの中心に据えるうえで、品質と信頼性を担保するための極めて重要な性質です。
第3に、AIの活用によってコンポーネントの再利用性が飛躍的に向上すると期待できる点です。
適切なコンポーネントの発見、利用方法の理解、アプリケーションとコンポーネントを接続するためのグルーコードの生成といった作業は、いずれも AIの得意分野です。
新規に作ることを最小限に抑え、既存コンポーネントを的確に適用できる状態を整えることで、CBD本来の価値である「再利用による効率化」を現実的かつ持続的に実現できます。
AIの活用によってコンポーネントの再利用性が高まることで、コンポーネント技術そのものの価値が向上し、結果として開発全体の生産性向上にも寄与すると思います。
ここまでで、文芸モデル駆動開発の図全体の確認が終わりました。
次回は、文芸モデル駆動開発がもたらす価値や、開発生産性を高めるために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:伝わりやすくする目的で、話の流れを一部再構成しています。
