豆寄席第52回『AIプログラミング時代のソフトウェアモデリングを考える～ 必要性とアプローチ ～』開催報告
本稿は、豆寄席第52回の開催報告です。
開催概要
| タイトル | AIプログラミング時代のソフトウェアモデリングを考える～ 必要性とアプローチ ～ |
| 講演者 | 小黒 登行（株式会社豆蔵 AIロボティクス事業部 技術コンサルティング部 シニアコンサルタント） |
| 開催日時 | 2026年7月17日（金）18時30分～20時00分 |
| 講演概要 |
現在、生成AIを活用したソフトウェア開発が急速に普及しつつありますが、大量のソースコードが出力されることで、ソフトウェアのブラックボックス化が進みやすくなっています。特に新入社員は、ソフトウェアの構造を深く知らないままでもプログラミングができてしまう環境に晒されています。 「仕様を正しく言語化できる能力」こそがAIプログラミング成功の鍵であると言われ、あたかもソフトウェア構造を検討する必要がなくなるかのように語られることもあります。しかしそれは、外部からの変更要求を受けず、品質責任も伴わない、個人のプログラミングに限られた話ではないでしょうか。また、そうした考え方は、かつてのウォーターフォール開発への回帰を想起させはしないでしょうか。 企業のソフトウェア開発では、後続製品の安定的かつ早期のリリースが求められ、そのための拡張性や保守性が不可欠です。また、ソフトウェアの安全性やセキュリティが重視される場面では、信頼に値する説明責任も求められます。生成AIによって、人間が扱いきれないほどの大量のコードが出力される今だからこそ、「モデリングの時代」と言えるのではないでしょうか。大量生産されるコードの大海で、正しく舵取りをする存在がモデリングです。 モデリングとは、人間が持つ目的や視点に合わせて、認識している対象を抽象化する行為であり、現状は人間にしかできない営みです。では、その人間にしかできないモデリングと、コードの大量生産を得意とする生成AIを、どのように組み合わせていけばよいのでしょうか。 本講演では、この問いについて現状を共有し、これからに向けたアプローチをお話ししたいと思います。 |
講演の流れ
- はじめに：AI開発ループの罠
- AI×モデリングを支えるツール環境の現状
- 設計視点で考える「コードの扱いやすさ」とは？
- AIプログラミング時代だからこそ、人間が「目的や視点」を持つということ
- AIに構造検討の指示を与える
- まとめ
はじめに：AI開発ループの罠
現在、急速に普及してきたAIプログラミングにおいては、AIがコーディングを行い、人間がレビューして次の指示を出すというループが生まれています。しかし、コード量が増えるほど複雑さは指数関数的に増加し、生成AIはこの複雑さ自体を解消してはくれません。そこで「人間がエンジニアリングに基づいて判断を加えながら開発する」と言われてはいるものの、「エンジニアリング」という言葉だけで留まっています。その結果、「何がエンジニアリングなのか？」がよく分からないまま開発を続けてしまい、人間が行う作業としては今までと変わらないどころか、逆に見通しが悪くなっている可能性があるということを説明されました。
AI×モデリングを支えるツール環境の現状
本題に入る前の前提として、現状のAIを活用したモデリング環境には、試行錯誤がしやすいグラフィカルな編集が可能な「UMLモデリングツール（astah*など）」と、テキスト記述のモデル化によってコードとの連携がしやすい「IDE＋UML記述Viewer（PlantUMLなど）」があり、それぞれのメリット・デメリットと使い分けについて紹介されました。
また、ソフトウェア設計に関する最近の論文や各社（オラクル、Amazon、IBM）によると、AIは設計成果物の候補の生成は可能ですが、非機能要件の評価やトレードオフの判断といった最終的な設計判断はできず、依然として人間が修正や肉付けといった部分を担当する必要があるだろうという共通見解が示されています。
設計視点で考える「コードの扱いやすさ」とは？
コードを書く主役が人間からAIにシフトしたとしても、コードの扱いやすさとして重要な「保守性」、「拡張性」、「再利用性」というキーワードは同じであり、目指すべきソフトウェア構造の本質は変わりません。ここで必要となるのがソフトウェアへのモデリングの活用です。モデリングとは情報量を絞る技術であり、ソフトウェア開発においては複数の目的や視点に合わせて大量のソースコードを分割することで、全体の構造を分かりやすくするものであるということを複数の例で説明されました。
では、生成AIにこれらの分割をうまく出来るかというとそうではなく、AIは、Web上の学習データをなぞった「一般論」の出力しかできないため、プロジェクト固有のコンテキストを反映することができません。また、チームにとっての読みやすさや、何を優先すべきかといった「設計の意志」を持っていないため、先述した共通見解の通り、AIを活用できるのは「参考の候補出し」までになるという限界が存在しています。
AIプログラミング時代だからこそ、人間が「目的や視点」を持つということ
AIに丸投げせず、人間が持つべき「目的や視点」の一例として、小黒さんは以下の4つを挙げられています。ただし、実際にはプロジェクトや分野によっても異なるため、重要なのは自分たちの状況に応じた「分割の視点」を明確に持って生成AIに提示することであると強調されました。
また、生成AIとの対話で「目的や視点」を見つければよいのでは、という点については、生成AIがプロダクトに対する意思や方向性を持っておらず、対立する意見をぶつけあうような深い議論が成り立たないという欠点があるため、目的や視点に関する相談相手としてはやはり人間同士が最も適していると結論付けています。
AIに構造検討の指示を与える
具体的にAIを活用して構造検討を行う流れとして、以下の4ステップが提示されました。
- 【議論のネタ出し】： 生成AIに、パッケージ分割する目的や視点を挙げさせる
・ 具体的なシステムの要件などを踏まえて、考えられるパッケージ分割の素案などを挙げてもらう。
・ パッケージ分割のためのエンジニアリングの知識やよくある目的や視点および出力フォーマットを、AIが参考にする情報として別に与えておく。 - 【人間同士で話し合う】： “議論のネタ”を参考にしながら、ソフトウェア構造に取り込むべき目的や視点について、話し合う
・ 製品の企画書でスコープの認識を合わせつつ、AIに生成させた“議論のネタ”を参考に、対話を始める。
・ メンバー間で意見がズレる経験を経て、プロジェクトにとって適切な目的や視点を具体的に思考する。また、それらの優先順位も考える。 - 【設計する】： 生成AIに、人間が検討した目的や視点ごとに、パッケージ分割した図を描かせる（もしくは、人間が描く）
・ 一度にすべての図を出力させるのは難しいため、目的や視点単位で出力させる。 - 【構造を洗練する】： 目的に即した構造になっていると考えられるか確認し、修正を加える
・ 出力した図を見て意図通りの構造になっているかを確認し、モデリングツールやPlantUMLで編集できる場合は、直接編集で修正する。
・ 出力指定との齟齬がでる場合は、指示ファイルの内容を見直す。
まとめ
最後に、講演全体のまとめとして以下で締めくくられました。
- AIが大量生成するコードを分かりやすくするためには、パッケージ分割などで、一度に扱う情報量を減らすことが重要。
- パッケージ分割やクラス分割の仕方は、エンジニアリングの知識（設計原則、デザインパターン、アーキテクチャパターンなど）を用いて考えられる。
- ただし、扱いやすさそのものは、エンジニアリングの知識だけではなく、目的や視点（⇒どうなっていれば扱いやすいのか）が必要。
- 目的や視点は、プロジェクトごとに異なるため、生成AIでは一般論の程度までしかパッケージ分割できない。場合によっては、却って扱いづらい分割になる可能性も十分にある。
- 目的や視点を明らかにしていくには、生成AIとの壁打ちではなく、人間との壁打ちが大切。
所感
AIを使った開発が主流になっていく中で、人間が持つべき目的、視点とは何かという点について改めて考えさせられる内容でした。便利なAIではありますが、ただAIに指示を出すだけでなく、エンジニアリングの知識の活用や人間同士の対話ができてこそ、品質の高いソフトウェアを作りこむことができるのだと感じました。
AIが得意なことと、人間だからできることという、この両者をうまく生かしながら、自身の業務でもモデリングに取り組んでいきたいと思います。
なお、最後の質疑応答の中で、今回の講演の内容を実際にトライしようとする人の中でUMLが分からない人はどこから始めれば良いか？という質問がありました。こちらは、小黒さんも回答されていたとおり、豆蔵のデベロッパーサイト内にモデリングやコードとの対応について紹介している記事がありますので、ぜひご覧ください。
https://developer.mamezou-tech.com/modeling/