🌐

モデルウェア工学の可能性：生成AIが切り開くシステム開発の未来

2023/06/29に公開

UML

はじめに

ChatGPTなどの大規模言語モデルを使ったチャットAIにプログラムを書かせることができるという事が話題になっています。プログラミングに特化したGithub copilotというサービスを使うと、より直接的にAIによるサポートを受けることができ、ソフトウェア開発にAIによる変革の波が訪れていることは、多くのエンジニアが肌身で感じているところだと思います。

今後もますます、プログラム生成AIの技術は高度化していくことが予見されます。今時点のAIを使いこなすテクニックを身に着けることが、将来の仕事に生かせるのかどうかも分かりません。少なくとも本当にプログラミングだけを行うエンジニアの需要は減少するでしょう。そして、より上流のソフト設計、システム設計、要求分析を行うエンジニアや、実際の人間やモノの動きを伴うテストを行うエンジニアが求められることになると想定されます。

生成AIがプログラミングを肩代わりする時代に、システム開発は大きく形を変えると思います。今は、プログラムをターゲットにするソフトウェア開発の時代です。そしてこれからは、システムモデルをターゲットにする「モデルウェア開発」の時代へのシフトしていくと、私は予想します。

モデルウェア(modelware)とは

モデルウェア(modelware)は、私の造語ですが、これからのシステム開発のキーワードになるものとして考えた名称です。広義にはシステムモデルもソフトウェアに分類できますが、あえてモデルウェアという概念を持ち込みました。

それは、従来のソフトウェア開発、ソフトウェア工学、ソフトウェア設計とは異なる考え方をする必要があるためです。システムモデルはこれまで、モデルベース開発やモデルベース設計と呼ばれるように、ソフトウェア開発をモデルベースで行う、というニュアンスが強いものでした。私はその考え方から発想を変えて、真にシステムモデル自体をターゲットとした開発という視点を持ち込むために、モデルウェア開発やモデルウェア工学という言葉を使いたいと考えています。

従来のソフトウェア開発におけるプログラムも、最終的にハードウェアに書き込まれるマシンコードではなく、エンジニアが読み書きするプログラムをターゲットと捉えることが一般的です。このため、開発におけるどの時点の成果物をターゲットにするかは、絶対的な基準はなく、開発者たちがどう認識するか次第です。モデルウェアという言葉で、私は開発対象がプログラムではなく、システムモデルであることを強く意識づけすることを狙っています。

モデル駆動開発の弱点とAIによる克服

システムモデルを開発の中心に据えるというアイデア自体は、新しいものではありません。一方で、残念ながら日の目を見てこなかったアイデアでもあります。モデル駆動開発という分野が、その代表例です。

システムモデルを書きさえすれば、後はそのモデルから、プログラムが自動生成あるいは半自動生成されるという事が、モデル駆動開発の基本コンセプトです。これによりシステム開発は文章形式のソースコードの長大なファイル群を扱う仕事ではなく、設計がビジュアル化され直感的に把握できるシステムモデルを描画する仕事にできるという目論見です。これが実現できれば、長大なファイルの中に潜むバグを探し回る手間も、大規模化するにつれて構造が複雑化しメンテナンスや拡張が困難になるという問題も解消できるという夢がありました。

モデル駆動開発の弱点

しかし、ふたを開けてみれば、モデル駆動開発には大きな弱点がありました。システムモデルとプログラムとの間にはギャップがあり、そのギャップを埋めるためには、システムモデルをプログラムと同等の詳細レベルまで記述するか、あるいはギャップ部分はエンジニアがプログラムを作って埋めるか、そのどちらかが必要です。これはシステムモデルの表記法や言語表現の良し悪しや技術の成熟度とは無関係の、普遍的な真理です。

そうなると、途端にモデル駆動開発の魅力は減衰します。システムモデルは直感性が高いモデルを扱えることがメリットですが、プログラミングレベルの詳細化には向いていません。そのレベルは、当然ですが、プログラミング言語の方が向いています。

一方で、システムモデルで書ききれない部分をプログラミングで補うということは、モデルの変更を行うことが容易にはできなくなります。モデルを変えてしまうと、ギャップを補完していたプログラムを書き直さなければなりません。しかも、結局多くのバグは、抽象的な構造ではなくそうしたギャップ部分で生まれますので、モデル駆動のアプローチでも、品質を上げることも難しいのです。

AIによる弱点の克服

このシステムモデルとプログラムとの間にあるギャップは、生成AIによって埋められる可能性が見えてきました。

大まかに言えば、今までは、関数やクラスで実現することをコメント文に自然言語で書いて、その自然言語で書いた内容をプログラムに落とし込むという作業がプログラマの作業ルーティンでした。既にGithub CopilotのようなAIサポート型のプログラミングを体験した人はお分かりと思いますが、コメント文を適切に書きさえすれば、生成AIはプログラムのかなり部分を自動生成することが出来ます。

現時点では、まだぎこちないところはあり、書かせたいプログラムによっては思うように生成されないこともありますが、生成AI側の能力向上と、AIサポート型プログラミングのノウハウの蓄積が進めば、コメント文を適切に書くことがプログラマの作業となる日も近いと感じます。

さらに、現時点ではコメント文と同一ファイル内の情報が生成AIが推論に使える情報の範囲だと考えられますが、プロジェクト内のファイル全てを推論に使えるようになったり、プログラム以外の設計情報もアクセスできるようになっていけば、自ずとプログラムの生成能力も向上するでしょう。

また、チャットAIのように真実の検証が難しい問題を扱う応用分野で、AIが信頼性の低い情報を出力することが問題視されています。このことから、プログラムの精製の精度やバグについて懸念する声もあるようですが、真実は異なります。

たしかに、生成されたプログラムの精度が低いケースはあります。しかしながら、チャットAIの応用例とプログラミングは決定的に異なる点があります。それは、プログラミングは、ちょうど将棋やチェスのAIのように、対抗となるプログラムを用意して、比較検証を行って正確性や精度を自動的に確認することが出来る世界だという点です。

通常のプログラミングでは、単体テストや結合テストと呼ばれる工程があります。AIに設計資料やコメント文を与えた時に、プログラム本体を生成させるのと同時に、その単体テストや結合テスト用のプログラムの作成も依頼することが出来ます。人間のエンジニアに網羅的に単体テストを作成させると、その分の開発時間や作業工数が必要になりますが、生成AIの能力を駆使すれば、近い将来はかなり網羅的なテストコードを作成して、生成した目的のプログラムの確からしさもほとんど自動的に検証できるようになるでしょう。

また、単に網羅的なテストコードを書くだけでなく、多角的に別のテストコードも生成してテストをさせることも可能ですし、不具合があれば自動的に再プログラミングも可能です。このようにプログラミングは、将棋やチェスのように強化学習が実現できる応用分野です。このため、並みの人間が行うよりもはるかに高品質なコードを生成できるようになる事は、時間の問題と思われます。

設計ドキュメントとコメント文に基づいたプログラム生成、テストコードの網羅的な生成と自動再プログラミングの実現、および、その作業を通した強化学習による生成AIの精度向上。これらの可能性を考慮すると、おそらく多くの人が想像しているよりも早く、プログラミングという作業は人間が行う作業ではなくなる日が近づいていると考えられます。

この事は、モデル駆動開発の弱点であったシステムモデルとプログラムとの間のギャップが埋まる、という未来が見えてきているという事を意味します。

モデルウェア開発の方法論

生成AIがプログラミングという作業を肩代わりする未来が近づくにつれて、システムモデルを中心にした開発方法論についての議論も活発になるでしょう。モデル駆動開発の研究を行っていたソフトウェア工学の研究者を中心に、研究の再考が進んでいてもおかしくありません。

先に説明したように、私はシステムモデルを中心としたシステム開発は、今までのプログラム中心の考え方から脱却することが重要になると考えています。このため、モデルに基づくソフトウェア開発という消極的な姿勢から離脱するために、あえてモデルウェア開発という言葉でシステム開発を再構築することを提案します。

そして、私はモデルウェア開発において、現在の支配的なオブジェクト指向方法論の影に隠れているアプローチにも光を当てたいと考えています。それは、アスペクト指向とサブジェクトの概念です。

アスペクト指向設計の可能性

アスペクト指向は、現在のところプログラミング言語のレベルで取り入れられている概念です。

ログの出力、エラー処理、セキュリティなど、ソフトウェア全体、あるいはシステム全体に共通的な側面（アスペクト）で、設計した内容をプログラムに反映したいという要望は、多くのシステムにおいて一般的です。

オブジェクト指向設計では、システムをオブジェクトに分解して設計することでカプセル化による設計全体の見通しが良くなるという利点がある一方で、こうしたシステム全般を横断する側面を扱うことが苦手でした。

そこで、プログラミング言語にアスペクトという概念を導入し、どのクラスやオブジェクトでもログを出力する際にはログのアスペクトで定義した関数をコールするという事を可能にします。特定のタイプのエラー処理を行う際はエラー処理のアスペクト、セキュリティ処理はセキュリティのアスペクト、という具合です。そしてアスペクトの設計を変更したり不具合を修正する際には、アスペクト単位で修正すれば、それがシステム全体に反映できるというものです。

システムモデルに対するアスペクト指向設計アプローチ

私は、このアスペクト指向の考え方である複数のオブジェクトやクラスをまたがるアスペクトを扱うという考え方を、プログラミング言語レベルだけでなく、モデル設計レベルにも持ち込むことが重要だと考えています。また、単にログやエラー処理やセキュリティのようなシステムワイドで共通化されるようなアスペクトだけでなく、局所的なアスペクトも柔軟にモデルとして定義するというアスペクトの応用範囲の拡張も必要だと考えています。

システムモデルのレベルで、複数のオブジェクトやクラスにまたがる局所的なアスペクトを定義する、という考え方を、文章でお伝えすることは難しさがあります。ここでは簡潔な説明を試みます。

オブジェクト指向に基づいたモデリング言語であるUMLでは、継承関係を表すクラス図、処理の流れを示すシーケンス図やアクティビティ図、状態を表現する状態遷移図、包含関係を示すパッケージ図やコンポーネント図など、システムを様々な観点から写像したモデルを作成します。こうして複雑で多面的なシステムを分析的に表現することが出来ます。

このようにシステムを表現するそれぞれの観点は、複数のクラスやオブジェクトの関係を表すという点でアスペクトです。つまり、既にオブジェクト指向はアスペクトの観点を内包している方法論と言えます。

私が提案するシステムモデルにおけるアスペクト指向設計アプローチは、アスペクトの柔軟性を持ち込むことを目的としています。

先に述べたオブジェクト指向のアスペクトは、固定的であり普遍的なアスペクトです。どのシステムにも適用でき、システム毎に同じアスペクトを用いることができます。これはシステム毎、あるいは設計者毎にバラバラなことを行う事を防ぎ、モデル図やモデル言語、さらにはモデリングツールを共通化するという利点があります。これによりUMLのような１つの体系を学習したエンジニア同士は、共通言語としてシステムモデルを交換して理解したり、モデル作成を分業したり、モデルのメンテナンスを行えるようになります。

一方で、この固定的なアスペクトは不自由であり、モデリングの柔軟性を許しません。例えば関心の分離を行って、システム内の局所的なクラスとメカニズムだけを設計として表現したい場合に、UMLを用いるともどかしさを感じます。

例えば、少数のクラスだけにフォーカスして、簡単な継承と包含関係を示しつつ、そこでの振る舞いにおいて守るべきパターンを簡潔に表現したい場合を考えます。こうした時、クラス図とコンポーネント図とアクティビティ図に書くような内容を、１枚の絵だけで描き切ってしまいたくなることがあります。そのように多面的な情報を盛り込んでも、モデル図が複雑すぎることはなく、かつモデル図を分けて書くよりも可読性やメンテナンス性も高いというケースは良くあります。パワーポイントやエクセルやホワイトボードに描くなら、実際に１枚で書いて表現し、チームメンバーにモデルを理解してもらえます。しかし、UMLは（特にUMLモデリングツールは）それを許しません。

こうしたケースを、アスペクト指向アプローチでは柔軟に扱えるようにします。つまり関心の分離を行い、その関心の範囲内で、柔軟なモデル記述を許します。その関心の範囲がアスペクトです。そして、アスペクトに適したモデル記述を設計者自らが定義をしてモデル化を行えるようにします。

この柔軟なアスペクトとモデル記述方法の定義は、システムモデル設計者に高い自由度を与えます。その反面、モデル記述からプログラムを自動あるいは半自動生成したり、モデル自体の全体のシステム内での整合性チェックを行うことが、とても難しくなります。このため、これまでこのようなアスペクト指向設計というアプローチは、ソフトウェア設計の手法として目立つことが出来ませんでした。

しかし、実際のシステム設計を行っているエキスパートであれば、誰しもそれと意識しているわけでもなく、このようなアスペクト毎の設計を行っているはずだと私は確信しています。つまり、システム設計の方法としては実用的で現実的な方法ではあるものの、モデルを中心にしたアプローチでは、そのコード生成ツールへの応用の困難さと、属人的なモデル定義の弊害のために主流にはならず、非モデル中心のシステム設計の現場では日常的に使われているという歪みが生じていると私は見ています。

しかし、生成AIの登場で、この問題に光が射してきました。

チャットAIの驚くべき点は、私たちが非標準的な方法で、自由に自然文を入力しても、それをコンピュータであるAIが的確に解釈して扱うことが出来るという点です。このAIの柔軟で高い理解力は、まさにアスペクト指向設計の問題を解消する強力なツールになります。システムモデルの設計者が、適切に関心の分離を行ってアスペクトを取り出し、そのアスペクトで設計のエッセンスを簡潔に表現するモデル定義と必要な補足コメントを自然文で記述すれば、後は生成AIが的確にその設計概念を理解して扱うことが出来ます。

そして、設計者が与えたアスペクトのモデルから、生成AIが理解した内容をUMLのような統一記述言語に変換します。そうすれば、付け加えたアスペクトが全体のシステムと整合性があるか、不足や矛盾がないかをチェックすることが出来ます。さらには、そのUMLのような統一モデルをインプットとして、プログラム生成AIがプログラミングとテストを自動実行してくれます。

このようなアスペクトモデルからUMLへの変換を行う生成AIはもちろんまだありませんが、チャットAIの能力を考えれば、夢物語ではありません。むしろアスペクトを図で書くのではなくプロンプトで表記、UMLの図ではなくXML表現を利用すれば、現時点のチャットAIに対するプロンプトエンジニアリングでもできなくはないのかもしれません。

こうすることで、設計者は本当にシステムの重要な側面だけに集中して設計をこなしていくことが出来ます。そして、アスペクトモデルからオブジェクトモデルの生成、オブジェクトモデルからプログラムとテストコードの生成および自動テスト＆デバッグ、という一連の工程をつなげれば、アスペクトを定義してモデル化するだけで、システムに機能が追加され、即時動くコードが出てくるという世界も見えてきます。

また、人間のエンジニアが、すべてのUMLを充足するだけのアスペクトのモデルを提供する必要もありません。いくつかのコアとなるアスペクトや、局所的なアスペクトをモデル化して与えれば、UML化する際に、生成AIは適宜モデルの補完を行うことが出来るようになるはずです。実際、Github copilotは現時点でもプログラムにおいては驚くほど気持ちよくコードの補完を行ってくれます。これはお絵描きAIが少数の単語から意図したとおりの絵を描いてくれることにも近いものがあります。本質的に重要なところはエンジニアがしっかりとアスペクトモデルを設計し、そこからの類推で埋められる部分は生成AIがしっかり整合的に補完して全体のUMLモデルが作られ、動くコードが出てくる。それがモデルウェア開発の目指す姿です。

サブジェクト（主体）の概念

オブジェクト(客体)だけでなく、サブジェクト(主体)の概念を意識することが、今後のシステム設計者にとって重要になると考えています。

端的に言えば、オブジェクト（客体）は、呼び出し（関数コール）を受ける側のソフトウェアモジュールです。そして、多くの「情報システム」は、人間が情報を入力したり、閲覧や検索などを人間が要求します。従って「情報システム」は、システム自体がオブジェクト（客体）の性質を持っており、人からの入力や要求を待っているところからスタートします。このため、オブジェクトであるシステムを、さらに細かいオブジェクトに分解して再利用性や分担開発を可能にするオブジェクト指向が「情報システム」開発の主流となっているのです。この事は、オブジェクト設計による要求分析やシステム設計のスタート地点であるユースケース図のアクタが、人の形をしている事に端的に表れています。

一方、これは全てのデジタルシステムのことを指していない点に注意が必要です。オブジェクト指向は「情報システム」の開発の方法論の中で登場し、人間が起点になるというシステムを前提に発展してきました。そこには、自律的な「装置」が起点となって構成されるシステムの観点がほとんど抜け落ちているか、後付けて付け足しされている程度の扱いになっています。そこで、内部に処理の起点となる「装置」が存在するシステムも適切に扱えるようにするために、サブジェクト（主体）の概念をシステムモデルの中に取り入れることが重要になる、というのが私の考えです。

Internet of Things(IoT)という言葉がバズワードになっていますが、実際にIoTシステムの需要はますます増えていくことが予想されています。今までは、インターネット検索とWebサイトやWebサービス、メール、SNS等のような、人間のための、人間が起点となるインターネットシステムが主流でした。IoTは「装置」のための、「装置」が起点となるインターネットシステムということが本質です。このため、サブジェクト（主体）の概念をシステム設計で適切に扱えることは、時代の要請でもあります。

残念ながら、サブジェクトの概念をどのようにシステムモデルに取り入れるべきか、また、どのようなサブジェクトの概念を取り入れることで達成したいシステムモデルのどんな品質を向上させる必要があるのかは、私の中で明確に整理できているわけではありません。

ただし、IoTシステム開発に携わっている中で、自律的なスレッドをUMLのシステムモデルの中で記述できない（少なくとも私が知っているバージョンのUMLでは）ことと、他の設計者が完全にこの概念を設計上で見落としている事にもどかしさを感じています。また、細かい笑い話としては、ユースケースの図の人の形をしたアクタの名称が、○○システムという名前になっているという喜劇（悲劇）を見かけることもしばしばです。

主体として自律的に動作するスレッド（これが恐らくシステムにおけるサブジェクト）が表現されていないことの弊害として、リソース競合や、ボタンの掛け違い的な厄介な問題の頻発が挙げられます。始めからシステムの設計図にこうした自律動作するスレッドと、読み書きするリソースや処理の交錯を明示しておけば、多くのリソース競合やボタンの掛け違いは防ぐことが出来るはずです。しかし、現実には設計書に明示されることは少なく、リソース競合やボタンの掛け違いは発生します。厄介なことは、これらはテストのときには問題として検出できず、リリース後に時々発生して、ユーザと私たち設計者を悩ませる問題になる事です。再現性が低い問題との遭遇もよくあり、デバッグがとても難しい問題の代表格（というかほぼ全て）となっています。

モデルウェア開発のように、複雑なシステムであっても生成AIの能力を活かしてシステム開発ができる時代に入った時、そしてIoTのように装置が起点とあるシステムがさらに増加し、そのシステムへの要求も複雑化してきた時には、現在のサブジェクトの概念を書いたシステムモデルの手法のまま突き進むと、こうした厄介な問題を世の中にばら撒いてていくことになりかねません。モデルウェア開発は、そうした問題にもアプローチできる方法論となってほしいという想いがあります。

さいごに

サブジェクトの概念のところで厄介な不具合の話に触れました。こうした不具合への対策として、数学的あるいは論理的な仕様検証技術の適用も視野に入れておくことも重要です。

モデルウェアはモデルでシステムを扱うことが出来るため、直接的か、あるいは逆算的なやり方で、検証対象のシステム仕様を生成し、それを数学的あるいは論理的に厳密に検証するというアプローチにつなげることが出来るかもしれません。それが出来れば、システムが爆発的に複雑化しても、不具合やセキュリティの問題で社会インフラが脅かされるリスクもある程度コントロールできる世界にもなってくるのかもしれません。

これは本質的にシステムの欠点を克服する重大なチャレンジになりますので、設計者としては大いに期待したいと思う反面、すべての不具合が自動的になくせる技術が出てきたら、どうなるのだろう、という想像をしてしまいます。不具合がなくせるなら、要求仕様を書き出してシステムエンジニアリングAIにインプットすれば、翌朝にはバグがなく要求を満たしたシステムが出来ているでしょう。

これは、システムエンジニアという仕事の全てを、AIにバトンタッチできるということを意味しますが、やはり寂寥感は否めません。まだ、もう少し先の未来のことだとは、思っていますが。