生成系AIを活用した開発ツールの変貌(EAモデリング設計)

生成系 AI を活用した開発ツールの変貌 (EA ／ BTABoK 設計 ) 土屋明生

大雑把な開発作業の流れ SE 作業配分の目安 ユーザー 要件 コンサル 40% 論理設計 要件定義 仕様理解 仕様書作成 ユーザー 合意形成 ﾄﾞｷｭﾒﾝﾄ 物理設計 20% 40% コード開発 デバック モジュール作成 テストケース消化 モジュール生成 コーディング 技術調査 アーキテクチャ GitHubCpilot の対応範囲 要因分析 設計 テスト設計 Cursor の対応範囲 実行モジュール デプロイ 実行環境 PG 納品 ﾄﾞｷｭﾒﾝﾄ Devine の対応範囲 MS-AutoDev の対応範囲 AGI に期待する範囲 2

GitHubCpilot 等を採用した場合の PDCA サイクル 開発プロジェクト作成：［アーキテクチャ設計］が完了後に PDCA サイクルを開始 ［Ｐ］：ユーザー要件による、コーディング要件を満たすプロンプト作成。 ［Ｄ］：上記プロンプトにより提案されたソースコードの妥当性評価と単体テスト。 ［Ｃ］：実行結果を確認し、必要に応じて修正を行う。 ［Ａ］：＜修正が有る場合＞［Ｐ］に戻る。（エラーコードの解析と是正） ＜修正が無い場合＞実行モジュールを作成して、テストを開始する。 ユーザー 要件 コンサル 論理設計 物理設計 要件定義 技術調査 仕様理解 アーキテクチャ 仕様書作成 設計 物理設計 コード開発 コーディング デバック テストケース消化 モジュール作成 モジュール生成 実行モジュール デプロイ 実行環境 要因分析 GitHubCpilot 等の対応範囲 テスト設計 デバック PDCA サイクルのチャレンジ範囲が狭い 3

プロダクト開発での AI 開発ツールの利用例 一般的な現場開発者の作業配分 40% ユーザー 要件 論理設計 20% 物理設計 コード開発 デバック GithubCpilot 等 要件 定義 論理 設計 ｱｰｷﾃｸﾁｬ 設計 物理 設計 要件 定義 論理 設計 MS-AutoDev 要件 定義 論理 設計 ｱｰｷﾃｸﾁｬ 設計 物理 設計 ｱｰｷﾃｸﾄ 設計 物理 設計 比 較 比 較 ｱｰｷﾃｸﾄ 設計 物理 設計 ﾃｽﾄ 設計 作業軽減範囲 ﾃｽﾄ 実施 ｺｰﾄﾞ ﾚﾋﾞｭｰ コード開発 ﾃｽﾄ 結果 モジュール作成 状態 監視 作業軽減範囲 ﾃｽﾄ / 修正 / ﾌｨｰﾄﾞﾊﾞｯｸ 作業軽減範囲 コード開発 比較 ( 対話 ) コード開発 比較 ( 対話 ) 状態 監視 モジュール作成 状態 監視 ﾃｽﾄ / 修正 / ﾌｨｰﾄﾞﾊﾞｯｸ ｺｰﾄﾞ ﾚﾋﾞｭｰ 実行モジュール デプロイ モジュール作成 修正フィードバック コード開発 Devine 実行環境 40% 状態 監視 モジュール作成 デプロイ作業 状態 監視 デプロイ作業 状態 監視 デプロイ作業 ﾃｽﾄ / 修正 / ﾌｨｰﾄﾞﾊﾞｯｸ Devin 相当の AI Agent が複数同時起動して、権限設定で許可された AI Agent が対話して開発を進める 4

論理設計の重要性 ユーザー 要件 論理設計 物理設計 コード開発 デバック モジュール作成 実行モジュール デプロイ 実行環境 ［従来］ 要件定義 ⇒ 論理設計 ⇒ 物理設計 ⇒ コーディング ・論理設計は、物理設計を行う為の通過点でしかなく、軽んじられていた。 ［近年］ 多種多様なプラットフォーム、フレームワーク、開発言語が出回り、陳腐化すると レガシー化してしまい、スクラッチ＆ビルド化による開発期間の長期化が現れた。 ＜解決策＞ ・論理設計ドキュメントを詳細に記録しておくことで、動作環境や開発環境が変化しても、 設計思想を踏襲する事が可能となる。 ・明確な論理設計ドキュメントから、 AI を利用して新たな Architecture を利用した システム設計が可能となる。 参考： https://www.it-innovation.co.jp/2020/03/11-012851/ を、参照ください。 5

• https://www.it-innovation.co.jp/2020/03/11-012851/

Devin ／ MS-AutoDev を採用した場合の PDCA サイクル ユーザー 要件 論理設計 コンサル 要件定義 要件定義 ﾄﾞｷｭﾒﾝﾄ 物理設計 コード開発 デバック モジュール作成 各工程でＰＤＣＡサイクルをチャレンジする事が可能となる 実行モジュール デプロイ 実行環境 実行モジュール デプロイ ・ PDCA サイクルのチャレンジ範囲が広く、デプロイまでの期間短縮が期待される。 ・その結果、各フェーズの再チャレンジが可能となり、ユーザービリティの向上が期待される。 6

Devin ／ MS-AutoDev が開発現場に与えるインパクト ・半年前、世間一般では、 GithubCpilot の登場が革命的だった。 ⇒ GitHubCpilot では、 [ コーディング ] フェーズのみが対象だった。 一般的な SE 作業の配分 [ 仕様理解 :40%][ コーディング :20%][ テスト :40%] ・ Devin では、 [ 仕様理解 ] から [ テスト ] までのフェーズが対象となり、 大幅な工数削減と、より高いユーザービリティ性の提供が期待できるようになった。 ・ MS-AutoDev は、内部で Devin 相当の AI Agent を同時に複数起動して、 各 AI Agent 間で対話させながらモジュール開発を進める。 これまでの現場におけるスパイラル開発モデルでは、 上流工程で [ 要件定義 ] を行い、 [ ユーザーと合意形成 ] を行うと、開発期間内に手戻りを伴う内容が発生しても、 [ 論理設計 ][ 物理設計 ] に大きな人的工数が必要となる為、期間や費用の面から上位設計の見直しには、 大きなリスクが、ユーザー、 SE 共に発生していた。 Devine の登場により、 [ 論理設計の一部 ] と [ 物理設計 ] を高いパフォーマンスで代替処理を行う為、開発フェーズにおける Try&Error の幅が広がり、 高いユーザービリティ性の追及を行える範囲が、大幅に広がる。 MS-AutoDev では、 Devin 相当の高性能な AI Agent を内部で複数起動し、各 AI Agent がお互いに対話して、最適なシステム設計と開発を進める 事で高品質なシステム開発を期待する事が出来る。 7

MS-AutoDev の論文上にあった概念図 AI Agent の権限範囲と スケジュールを管理 ・ Docker 環境が、 Security の要。 ・ Search ではないニュアンスが気になります。 （内部の Repository に RAG を構成しています） Devin 相当の AI Agent 8

Enterprise Architecture ／ BTABoK の該当範囲 SE 作業配分の目安 ユーザー 要件 コンサル ＢＡ ＤＡ／ＩＡ 40% 論理設計 物理設計 コード開発 要件定義 技術調査 仕様理解 アーキテクチャ 仕様書作成 設計 コーディング 要因分析 テスト設計 40% デバック テストケース消化 モジュール作成 モジュール生成 実行モジュール デプロイ 実行環境 Business Architecture Data Architecture ／ Information Architecture Application Architecture ＡＡ Technology Architecture ＴＡ Enterprise Architecture or BTABoK 20% ユーザー 合意形成 ﾄﾞｷｭﾒﾝﾄ PG 納品 ﾄﾞｷｭﾒﾝﾄ 過去： AI は AA 設計の一部を代替できた 現在： AI は DA と TA の一部及び AA を代替できる様になった 9

Enterprise Architecture ／ BTABoK と UML の対応 ＜対応する UML ＞ ＢＡ Business Architecture ＤＡ or ＩＡ Data Architecture or Information Architecture ＡＡ Application Architecture ＴＡ Technology Architecture Enterprise Architecture or BTABoK ＜概要説明＞ ユースケース図┳表現内容 ：システムの機能、ユーザーとのインタラクション ┗モデル化対象 ：システムが提供する機能、ユーザーの要求 クラス図┳表現内容 ：データの構造、データの関係 ┗モデル化対象 ：データのエンティティ、エンティティの属性、エンティティの関連 状態遷移図┳表現内容 ：システムの機能、ユーザーとのインタラクション ┗モデル化対象 ：システムが提供する機能、ユーザーの要求 ＤＦＤ┳表現内容 ：データの流れ、データの処理プロセス ┗モデル化対象 ：データの流れ、データの処理方法 クラス図┳表現内容 ：システムの静的な構造 ┗モデル化対象 ：システムのコンポーネント、コンポーネント内のクラス、クラス間の関連 シーケンス図┳表現内容 ：オブジェクト間の相互作用、オブジェクト間のメッセージのやり取り ┗モデル化対象 ：アプリケーションの動作、アプリケーションの処理フロー デプロイメント図┳表現内容 ：システムの物理的な配置、ネットワーク構成 ┗モデル化対象：システムの構成、リソースの配置 10

MS-AutoDev のモジュール構成 11

MS-AutoDev の機能構成 12

Devin の機能構成 Docker コンテナ Shell ・環境の構築 ・独自コマンドラインの実行 WorkSpace ・プロジェクト全体を構成 ・プロンプトのやり取り Browser ・必要な情報が不足している場合 Editor ・プログラミング ⇒ Web 検索を行い、必要な情報を収集する ⇒ 必要に応じたコード生成を実行 Planner ・ Agent の実行範囲の設定 ・ Agent の実行権限の設定 作業履歴 ・実行した作業の 履歴を時系列で 確認 13

MS-AutoDev ／ Devian の機能概要 SE 作業配分の目安 ユーザー 要件 UML 成果物 入力 ﾄﾞｷｭﾒﾝﾄ ユースケース図 40% 論理設計 要件定義 ﾄﾞｷｭﾒﾝﾄ ( ﾌﾟﾛﾝﾌﾟﾄ ) 物理設計 クラス図 状態遷移図 ＤＦＤ 20% コード開発 AI Agent ・作業割当 ・権限設定 クラス図 シーケンス図 YAML 形式 で指示 MS-AutoDev 全体管理 ⇒ 各 AI Agent の設定 ・ AI Agent を xx 本設定する ┣ AI Agent 毎に動作権限設定 ┗ AI Agent 毎に目標設定 40% デバック AI Agent ・作業目標 ( 途中 ) モジュール作成 デプロイメント図 実行環境 実行モジュール デプロイ AI Agent ・作業目標 ( 終盤 ) Test ケース （自動生成） 全て Docker コンテナ内で動作 各 AI Agent が会話コマンドで状態通知や確認を求めて来る ┣ talk ：状態の報告、情報共有など ┣ ask ：指示者への相談など ┗ stop ：タスク完了／エラー停止など （ Devin は、 MS-AutoDev の１ Agent 相当） 14

MS-AutoDev に置き換わる可能性のある SE 作業 １．コード生成、アプリ開発、テストコードの生成 ２．コードリファクタリング、既存コードの改善点調査 ３．ドキュメンテーション作業（既存コードを解析してドキュメント作成） ４．ソースコードレビュー、不具合原因の調査・報告 ５．バージョン管理作業 15

これからの SE に求められるスキル １． AI の知識の習得と、適切なプロンプト設計スキル ２．論理設計技術のスキルアップ 適切な論理設計スキルと論理設計から設計思想を読み解くスキル ３．生成されたコードの妥当性を判断できる知識 MS-AutoDev の ask コマンドに適切に回答可能なスキル ４．セキュリティの知識 コマンドやアクセス権限を適切に設定／制御できるスキル 16