AIプログラミング時代のソフトウェアモデリングを考える

生成AIでコードを大量に生成できる時代でも、人間が保守できる構造を保つにはモデリングが必要です。本講演では、AI×モデリングのツール環境（UMLモデリングツールとPlantUML/Mermaid）の比較、生成AIによる設計に関する論文と各社の見解を紹介し、パッケージ分割で「目的や視点」を人間が決め、AIに候補出しと作図をさせる4ステップのアプローチを解説します。2026年7月17日 豆寄席（株式会社豆蔵）での講演資料。

Transcript

1. AIプログラミング時代の ソフトウェアモデリングを考える ～ 必要性とアプローチ ～ 2026/7/17(金) 18:30～20:00 質疑応答含む @豆蔵Zoom AIロボティクス事業部 シニアコンサルタント 小黒 登行
2. 2 自己紹介 • 小黒登行（Oguro Takayuki） • 株式会社豆蔵 AIロボティクス事業部 技術コンサルティング部 シニアコンサルタント • 様々なメーカーで、エンジニアリングプロセス・ モデリング・アジャイル開発の導入・教育 • 元々は半導体製造装置の開発者⇒開発改善⇒コンサル • 社会活動 • UMTP（UMLモデリング推進協議会）運営委員 • UMTPモデリングフォーラム、 オブジェクト指向カンファレンスなど登壇 • SysML v2訳語研究会 リーダー • 趣味 • 陳氏太極拳小架式（陳氏太極拳協会 普及指導員） Copyright MAMEZO Co.,Ltd. All rights reserved.
3. アジェンダ 【前半：現状の整理と課題提起】 • はじめに：AI開発ループの罠 • AI×モデリングを支えるツール環境の現状 • 生成AIによる設計の潮流：論文と各社の見解 • 設計視点で考える「コードの扱いやすさ」とは？ 【後半：AIを活かすアプローチと実践】 • AI時代だからこそ「目的や視点」を持つということ • AIに構造検討の指示を与える • まとめ Copyright MAMEZO Co.,Ltd. All rights reserved.
4. はじめに：AI開発ループの罠
5. 最近言われていること AIプログラミングでは、人間がエンジニアリングに基づいて 判断を加えながら、開発する 人間が行うループ AIエージェント内部の 作業ループ コーディング ※ 仕様のループについては、 特に触れず、設計のループに ついてのみ取り上げます AIの出力をレビュー 指示を解釈 エンジニアリングに基づいて、 人間が判断する テスト 自身への次の指示を作成 次の指示を検討し、 プロンプトを書く 結局、何がエンジニアリングなのか？ よくわからないまま、これまで通りの開発を続けてしまわないか。 Copyright MAMEZO Co.,Ltd. All rights reserved.
6. AIプログラミングの明暗 【もたらされる恩恵】 • 爆発的なコーディング速度向上 • AIエージェントによる自動デバッグでの作業時間短縮 • 人間がプログラミング言語に詳しくなる必要性が低下し、未経験言語でもプロジェ クトに参加しやすくなった 【顕在化しつつある問題点】 • AIによる想定外のコード修正でデグレードが発生 • 人間が、膨大な生成コードの全体像を把握できず、AIに影響範囲を考慮した指示が できない • 生成コードの安全性を説明できない（生成AIがテストしたから大丈夫？） 【大元にある問題】 複雑性 コード量が増えるほど、複雑さは指 数関数的に増加するが、 生成AIはこの複雑さ自体を解消し てくれない。 人間が理解可能な複雑さ コード量 Copyright MAMEZO Co.,Ltd. All rights reserved.
7. AI×モデリングを支えるツール環境 の現状
8. AI活用モデリング環境の種類 グラフィカル編集 テキスト編集 UMLモデリングツール （ウインドウ一体型） IDE ＋ UML記述Viewer （別ウインドウ型） 有料（本格的な導入が必要） UML準拠で仕様書や設計書に利用可能 図としてのモデル上で、人間の試行錯誤がしやすい 無料（PlantUML / Mermaid Viewerなど） VSCodeなどのIDEと親和性が高く、ソースコー ドを含めて連携しやすい モデルからのコード生成が容易 構造イメージを共有する程度の図に利用可能 （※UML準拠が不十分） 主なモデリングツール 主なモデリングツール astah*, Enterprise Architect PlantUML, Mermaid ※MagicDraw ： 生成AI非対応。生成AIを活用した外部ツールか らAPIで操作してもらうスタンスのため、今回の調査からは除外。 Copyright MAMEZO Co.,Ltd. All rights reserved.
9. AI活用モデリング環境の現状 テキスト記述型（IDE+Viewer）の限界と使い分け テキスト記述が直面する「３つの壁」 ① UMLへの準拠が 不十分なため、コー ドを読み解けるだけ の表現力に限界 ② テキスト表現のた め、人間が、グラフィ カルなイメージで、 試行錯誤できない ③ AIが出力する PlantUML等のコー ドの品質が低い （LLMにより異なる） プロジェクトに合わせた3つの「程度感（選択肢）」 【程度感 ①：イメージ共有】ひとまずPlantUMLで、生成AIに描かせる 「概要程度の情報」として利用するだけなら問題ない 【程度感 ②：コード連携】PlantUMLに「ひと手間」加え、表現力を上げる UMLに準拠させるプロンプトを加え「コードと対応する図を描けるようにする」 【程度感 ③：厳密な設計】専用のモデリングツール×生成AIを組み合わせる 上流をより重視し、「モデリングで品質を上げて、コードを生成する」 Copyright MAMEZO Co.,Ltd. All rights reserved.
10. 生成AIによる設計の潮流：論文と 各社の見解 参考程度の紹介で済ませます
11. 最近の生成AIによるソフトウェア設計に関する論文 • 対象工程 • アーキテクチャ設計、詳細設計 • 論文 • From Requirements to Architecture: An AI-Based Journey to SemiAutomatically Generate Software Architectures (2024) Eisenreichら • → 要求からアーキテクチャ候補を生成可能だが、その判断には設計者が必要 • An LLM-assisted approach to designing software architectures using ADD (2025) Cervantes, Kazman, Cai • → アーキテクチャ候補生成可能だが、非機能要件の評価やトレードオフ判断には設計者が必要 • Systematic Literature Review (2025) Schmidら • → 生成AIは「設計者」ではなく、設計支援ツールとして利用されている • 現状 • 生成AIは、設計成果物の候補を生成することは可能 • 結合度の評価、設計原則への違反などの設計レビューも可能だが、設計者のように非機 能要件の評価や妥当なトレードオフ判断はできない • 生成AIは「設計者」ではなく、設計支援ツール • 生成AIによる最終的な設計判断は困難で、依然として人間が担当する Copyright MAMEZO Co.,Ltd. All rights reserved.
12. 各社の見解 • オラクル 共通見解：人間が修正や肉付け、事前に設計ドキュ メントを書く、レビューとフィードバック、が必要 • 実業務を考えると修正は必要。シンプルな構造は作れる。エンジニアが肉付 けをしていくことでもっと品質が上がる。 • Oracle Japan Marketing Video Channel 『生成AI×データモデリング。設計工程の自動化はどこま で可能か？』2025/12/19 https://www.youtube.com/watch?v=JQRqU0y5o5s • Amazon • 要件を与えてMermaidで設計ドキュメントを作成可能。しかし、人間による 設計レビューとフィードバックによる修正が必要。 • Amazon Web Services Japan公式 『AI Agent 時代のソフトウェア開発の型 ～ Everything as Code で叡智を伝える ～（AWS-57）』 2025/08/13 https://www.youtube.com/watch?v=BFiQUq6bGIo • IBM • 不正確なコードを生成する場合があるため、より包括的なコードレビューが 必要。 • Cole Stryker , Rina Diane Caballar 『開発者のための生成AI：メリットと課題』公開日 2024年03 月6日 更新日 2026年05月21日 https://www.ibm.com/jp-ja/think/topics/generative-aifor-developers Copyright MAMEZO Co.,Ltd. All rights reserved.
13. 生成AIのできることとできないこと • LLMが強い分野の条件 • (a) 膨大なテキストが存在し、十分な学習データがある • (b) 知識が長年利用され、引用・被引用の関係が成熟しており、構造化され ている • (c) 用語の意味が比較的安定している ※ 参考元：栗田 治 シンモデリング宣言シンポジウムでの講演での発言 2026/7/10 • ソフトウェア構造の設計は、形式知になりづらく、あくまで抽象的 に伝達されてきた知識 • そもそも、現在の生成AIが強い分野ではない 論文や各社の見解と同じ Copyright MAMEZO Co.,Ltd. All rights reserved.
14. 設計視点で考える「コードの扱い やすさ」とは？
15. 設計視点で考える「コードの扱いやすさ」とは？ 時代を超えて不変な「分かりやすさ」の価値 人間がコーディングしていた時代 AIがコーディングする時代 目的： 人間が、より安全に、より少な い工数で、機能追加/変更や不 具合修正ができるようにする。 目的： 人間がコードの全貌を素早く把 握し、より少ないトークン（＝コス ト）や、より少ないリスクで、AIに コードを変更をさせる。 キーワード： 【保守性】【拡張性】【再利用性】 結論：結局、時代が変わっても「分かりやすさ」の根源は同じ コードを書く主役が人間からAIにシフトしても、目指すべきソフトウェア構造（保 守性・拡張性・再利用性）の本質は変わりません。 Copyright MAMEZO Co.,Ltd. All rights reserved.
16. モデリングとは、情報量を絞る技術 • 目的や視点に合わせて、不要な情報を捨象して（＝捨てて） 、要点 を伝わりやすくすること 目的のない情報群 その土地を移動する目的で、 代表的な建築物の位置関係 の視点で要素を抽出する ©Google maps ©Google maps Copyright MAMEZO Co.,Ltd. All rights reserved. 目的の駅に到達する 目的から、路線や駅の接続 関係の視点で、要素を抽出する
17. ソフトウェアへのモデリングの活用 • ソフトウェア開発では、ソースコード内で様々なことが求められる。 • 例 「分離して修正しやすい」、「移植しやすくする」、「画面の変更の影響を抑 える」、「製品のバリエーション展開を容易化」 … 目的や視点 目的や視点 目的や視点 目的や視点 ・・・ 大量の ソースコード …………… …………… …………… …………… …………… …………… 鉄道と都バスの 路線図に分けて 読みやすくする が、相互の接続 も理解できる ことに似ている それぞれの目的に即して、コードをクラスやパッケージに分割する Copyright MAMEZO Co.,Ltd. All rights reserved.
18. モデリングで情報量を減らすとは？ どちらも 情報を グループ化している • 例1)パッケージに分ける ドメインA ドメインB • 例2)モジュールを分割する 教員 複数の目的視点の 変数や関数が混在 Copyright MAMEZO Co.,Ltd. All rights reserved. 属性1 属性2 属性3 属性4 属性5 属性6 ・・・ 操作1() 操作2() 操作3() ・・・ ドメインC 校長 ある目的視点の 変数や関数 属性5 属性6 操作5() 操作6() 教員 ある目的視点の 変数や関数 ある目的視点の 変数や関数 担任 属性3 属性4 操作3() 操作4() 属性1 属性2 操作1() 操作2()
19. よくある目的と分離の例 （例１）システムで管理対象となる概念を取り出す （例２）システム全体を、レイヤに分離する （例３）システム全体を、パッケージに分離する （例４）拡張性を踏まえて、ドメインを分離する （例５）保守しやすくクラスを分割する （例６）設計メカニズムを分離する Copyright MAMEZO Co.,Ltd. All rights reserved.
20. （例１）システムで管理対象となる概念を取り出す • システムの対象ドメインから、管理対象の概念を分離する 出典：ジェームス マーチン他 『オブジェクト指向方法序説 基盤編』1995 概念モデリング 分析モデリング 設計モデリング Copyright MAMEZO Co.,Ltd. All rights reserved.
21. （例２）システム全体を、レイヤに分離する • 「ＧＵＩ - 制御ロジック - ハードウェアＩＯ 」「GUI – ビジネスロジッ ク - DB」 などのレイヤに分離する View ex.アーキテクチャパターン Controller Model 概念モデリング 分析モデリング 設計モデリング Copyright MAMEZO Co.,Ltd. All rights reserved.
22. （例３）システム全体を、パッケージに分離する • システムの対象となるドメインを（プロジェクト固有の理解に適し た）サブドメインに分離して、理解しやすくする。 化合物同定ドメイン ex. OOAのサブドメイン分割 ex. 構造化分析のレベル1 データ処理ドメイン 概念モデリング 測定ドメイン 有機化学ドメイン 分析モデリング 設計モデリング Copyright MAMEZO Co.,Ltd. All rights reserved.
23. （例４）拡張性を踏まえて、ドメインを分離する • 抽象的な共通ドメインと、具体的な個別のドメインに分離し、拡張し やすくも既存領域に影響が起きないようにする 抽象ドメイン （共通領域） 具体ドメイン1 ex.OCP(開閉原則) 具体ドメイン2 概念モデリング 分析モデリング 設計モデリング Copyright MAMEZO Co.,Ltd. All rights reserved.
24. （例５）保守しやすくクラスを分割する • クラス/モジュール分割 • 大量の変数や関数を持つクラス/モジュールを、複数に分割して、一度に目 にする範囲や、変更の影響の可能性のある範囲を狭める • モジュールを独立して再利用しやすいようにする • 特に切り離してテストしたい部分を分割する 教員 教員 属性1 属性2 属性3 属性4 属性5 属性6 ・・・ 操作1() 操作2() 操作3() ・・・ 属性1 属性2 操作1() 操作2() 分割 担任 属性3 属性4 操作3() 操作4() ex.SRP(単一責任 の原則) 校長 属性5 属性6 操作5() 操作6() 概念モデリング 分析モデリング 設計モデリング Copyright MAMEZO Co.,Ltd. All rights reserved.
25. （例６）設計メカニズムを分離する • 非機能要件を満たすためのソフトウェアとしての仕組み仕掛けを 分離して、扱えるようにする ：A ：A 通信の集中を解消するメカニズム ：B 待合室メカニズム 通信が集中するとしても、 それは、分けて考える 概念モデリング Copyright MAMEZO Co.,Ltd. All rights reserved. ex.メタファによる設計 分析モデリング ex.デザインパターン 設計モデリング
26. モデリングにエンジニアリングの知識を用いることで、 分かりやすい構造へ…… ならば、これらを生成AIに入力すれば解決？ システム全体のモジュールを、適切なレイヤとドメインに分割 してください。 また、属性と操作の合計数が50を超えるクラスを、分割して 見通しを良くしてください。 ＋ Copyright MAMEZO Co.,Ltd. All rights reserved. ↑
27. 生成AIによる分割の限界 理由①：AIが導くのは「一般論」 • Web上の学習データをなぞった「それらしい形」の出力 • プロジェクト固有の現実・コンテキストは「未反映」 理由②：「設計の意志（※構造決定の方針）」の不在 • 変更予測やチームの読みやすさといった「目的・視点の不在」 • 一般論での分割は、ほとんどの場合、チームが求める見通しの良さ ではない • AIに候補を出させるために、人間は(先の例に挙げたよ うな)エンジニアリングの知識が必要。 • AIを活用できるのは「参考の候補出し」まで。 • 構造決定の方針出しや、最終判断は人間がするもの。 Copyright MAMEZO Co.,Ltd. All rights reserved.
28. AIプログラミング時代だからこそ、 人間が「目的や視点」を持つということ ── AIに丸投げせず、人間が「設計のコントロール権」を握る
29. 人間が持つべき「目的や視点」 視点①：【知識領域】 視点②：【疎結合】 人間は知識領域(=ドメイン)を組 み合わせて思考しており、変更要 求もまた、それに準じて行われる 傾向にある。ソフトウェア構造を同 様に分割すると変更しやすい ドメイン間の依存関係を疎に捉え、 ドメインを跨るときにも、理解しや すいようにする 視点③：【サイズ】 視点④：【拡張性】 1つのクラスやパッケージに要素 を詰め込みすぎず、人間が一度に 把握できる適切なボリュームに収 める。 今後のプロダクトの展開や、予測さ れる機能拡張に関する明確な指 針・ロードマップを持つ これらはあくまで一例に過ぎません。重要なのは、自分たちの状況に 応じた「分割の視点」を明確に持ち、それを生成AIに提示すること Copyright MAMEZO Co.,Ltd. All rights reserved.
30. 生成AIとの対話で「目的や視点」は生まれるのか？ 生成AIとの壁打ち 人間（同僚）との壁打ち 特徴：プロダクトに対する 「意志や方向性」を持たな い。 結果：意見がぶつからないため、 方向性に沿った深い議論が 成り立たない。 特徴：お互いが固有の 「意志や方向性」を持っている。 結果：方向性を持つ意見の「齟齬」が 生まれるからこそ、 自分の方向性が客観的に見え やすくなる。 ソフトウェアを分かりやすくするための 目的や視点は、人間しか持ちえない。 だからこそ、 相談相手に(AIではなく)人間の同僚が適している。 Copyright MAMEZO Co.,Ltd. All rights reserved.
31. AIに構造検討の指示を与える
32. AIを活用した構造検討の流れ STEP-1：【議論のネタ出し】 生成AIに、パッケージ分割する目的 や視点を挙げさせる STEP-2：【人間同士で話し合う】 “議論のネタ”を参考にしなが ら、ソフトウェア構造に取り込むべき目的や視点について、話し合 う。 STEP-3：【設計する】 生成AIに、人間が検討した目的や視点ご とに、パッケージ分割した図を描かせる（もしくは、人間が描く） STEP-4：【構造を洗練する】 目的に即した構造になっていると 考えられるか確認し、修正を加える Copyright MAMEZO Co.,Ltd. All rights reserved.
33. STEP-1：生成AIに、パッケージ分割する目的や視点を挙げさせる 人間からAIへの指示（プロンプト例） 現在、新規に〇〇システムを構築する設計を行っています。 コード生成に移る前に、システム全体を適切なパッケージ構 造に分割したいと考えています。添付ファイルのシステムの 要件および、ファイル◦◦を踏まえて、考えられるパッケージ 分割の目的や視点、その分割の素案を、20個を目安に挙げ てください。 ＋ ↑ ※ 「ファイル◦◦」パッケージ分割のためのエンジニアリングの知識やよく ある目的や視点および出力フォーマットを、ハーネスとして別に与えておく。 Copyright MAMEZO Co.,Ltd. All rights reserved.
34. STEP-2： “議論のネタ”を参考にしながら、ソフトウェア構造に取り込むべき 目的や視点について、話し合う。 よりスムーズに対話を始める • 製品の企画書でスコープの認識を合わせつつ、AIに生成させた “議論のネタ”を参考に、対話を始める。 議論で自身の考えを見直す • メンバー間で意見がズレる経験を経て、プロジェクトにとって適切 な目的や視点を具体的に思考する。 • また、それらの優先順位も考える。 Copyright MAMEZO Co.,Ltd. All rights reserved.
35. STEP-3：生成AIに、人間が検討した目的や視点ごとに、パッケージ分割 した図を描かせる（もしくは、人間が描く） AIに描かせる場合のプロンプト例 ファイル××とファイル△△をインプットとして、パッケージ図およびクラス図を PlantUMLで出力してください。 出力後、あなた自身で設計原則に違反がないか批判 的にレビューしてください。 構造が確定したのち、この設計を絶対に逸脱しない形で各 クラスの実装コードを生成してもらいます。 ↑ ＋ ファイル×× サブドメイン「データ処理」「化合物同定」「有機化学」「測定」 レイヤ設計「MVVM」 …… ファイル△△ ファイルXXからの入力フォーマット PlantUMLでのパッケージ図出力フォーマット Copyright MAMEZO Co.,Ltd. All rights reserved. ※目的・視点は、 フォーマットを決め てファイルに記載。 ※入出力や変換の詳細 な指示は、ファイルに定 義して利用。
36. STEP-4：目的に即した構造になっていると考えられるか確認し、修正を加 える アウトプット（パッケージ図・クラス図）の目視確認 • AIがPlantUMLやモデリングツールで出力した図を見て、「意図通りの構 造になっているか」を確認する。 アウトプットの修正 • モデリングツールやPlantUMLで編集できる場合は、直接編集で修正 • 出力指定との齟齬がでる場合は、指示ファイルの内容を見直す アウトプットの洗練 • パッケージの分割ができたら、その後に、クラス/モジュールを配置した時点 で、再度、パッケージや抽象/具象クラスなどを見直します。 Copyright MAMEZO Co.,Ltd. All rights reserved.
37. まとめ • AIが大量生成するコードを分かりやすくするためには、パッケージ 分割などで、一度に扱う情報量を減らすことが重要 • パッケージ分割やクラス分割の仕方は、エンジニアリングの知識 （設計原則、デザインパターン、アーキテクチャパターンなど）を用 いて考えられる。 • ただし、扱いやすさそのものは、エンジニアリングの知識だけでは なく、目的や視点（⇒どうなっていれば扱いやすいのか）が必要。 • 目的や視点は、プロジェクトごとに異なるため、生成AIでは一般論 の程度までしかパッケージ分割できない。場合によっては、却って 扱いづらい分割になる可能性も十分にある。 • 目的や視点を明らかにしていくには、生成AIとの壁打ちではなく、 人間との壁打ちが大切。 Copyright MAMEZO Co.,Ltd. All rights reserved.
38. 豆蔵エンジニアリング教育 AI協働型設計基礎講座 ── 設計原則と設計を、生成AIと共に実践する 特徴①：設計課題に対する「解決案の検討」の深掘り • 本日のパッケージ分割に留まらず、より具体的な「設計課題」に対して、モデリ ングの手法を用いて最適解（トレードオフ）を導き出す思考法を習得します。 特徴②：生成AIを活用した「設計原則」の厳格な適用 • SOLID原則などの不変の設計原則を、生成AIを「強力な検証パートナー」とし て活用しながら、実際のモデルやコードへと正しく落とし込むための、さまざま な設計アプローチを学びます。 特徴③：今日から現場で使える「AI協働型」の実践演習 • 人間が設計のコントロール権を握り、AIから高品質な設計成果物を引き出すた めの具体的なプロセスとプロンプトワークを、ハンズオンで体感します。 Copyright MAMEZO Co.,Ltd. All rights reserved.
39. 豆蔵 エンジニアリング教育 STEP1: エンジニアリング基礎 エンジニアリング入門講座 ソフトウェアテスティング 入門講座 エンジニアリング基礎講座 要求基礎講座 ソフトウェア 品質保証入門講座 ソフトウェア構成管理 基礎講座 エンジニアリング 技術紹介コース CMM/CMMI 基礎講座 ソフトウェア設計基礎講座 AI協働型 設計基礎講座 プロジェクト管理講座 基礎編 プログラミング基礎講座 STEP2: 手法・技法系講座 オブジェクト指向技術 システムズエンジニアリング オブジェクト指向 オリエンテーション システムズエンジニアリング 入門講座 UML入門講座 MBSE向け システムズ エンジニアリング入門講座 OOプログラミングC++ 演習講座 SysML入門講座 (SysML v1) UML/C・C++ マッピング講座 SysMLモデリング演習講座 (SysML v1) アジャイル開発 アジャイル入門講座 スクラム基礎と実践講座 アジャイル開発のための プロジェクト管理講座基礎編 その他 外注管理基礎講座 UMLによる 設計可視化講座 SysML v2入門講座 設計原則入門 OSSライセンス管理 基礎講座 UMLモデリング演習講座 SysML v2 モデリング演習講座 ISTQB認定テスト技術者 ソフトウェアテスティング 基礎講座 プロダクトライン入門講座 MBSE基礎講座 (システム設計編) C言語基礎講座 テスティング基礎 ワークショップ セキュリティエンジニアリング 入門講座 システムエンジニアリング 実践講座 (セーフティ、セキュリティ編） C++コーディング ・リフレッシュ講座 UMLモデリング添削講座 UseCase入門講座 組込みOOAD講座 静的解析・分析入門講座 デザインパターン入門講座 ソフトウェアバリデーション 入門講座 オブジェクト指向開発 プロセス モデリングアセスメント STEP3: エンジニアリング実践 仕様記述実践講座 ソフトウェアテスティング 実践講座 アーキテクチャ設計講座 【品質講座】 レビュー実践講座 状態遷移設計基礎講座 要求開発実践講座 なぜなぜ分析講座 【品質講座】 品質分析評価技法講座 【品質講座】 原因分析ワークショップ Copyright MAMEZO Co.,Ltd. All rights reserved. プロジェクト体験型 演習講座 システムアシュアランス 入門講座 エンジニアリング 技術紹介コース（車載編） -Foundation Levelトレーニング ワークショップ ライントレース＋衝突回避 ワークショップ イメージスティック ROS2入門講座
40. AIプログラミング到来！ 大航海時代のコードの荒波に、 エンジニアリングという航海術を学ぼう。