Downloaded 55 times
![4
留意点
• 計算リソース、ハルシネーション
• 評価の難しさ、ベンチマーク汚染
• プロプライエタリLLM、著作権
LLM活用のSEタスク [Hou+24]
• コード生成・修正が中心
• 要求や設計、マネジメント活用限定的
X. Hou, et al., “Large Language Models for Software Engineering: A
Systematic Literature Review,” ACM TOSEM, 33(8), 2024
情報処理学会 監修, 鷲崎 編著, 家村・石川・鵜林・蛯名・小川・川上・近藤・竹之内・徳本・中川・増田 著, ”生成AIによるソフトウェア開発”, オーム社, 2025年11月予定](https://image.slidesharecdn.com/ses2025-genai-tutorial-250918055630-5fd3a716/75/LLM-AI-SES2025-4-2048.jpg)
![あなたには各機能を実現する詳細処理の内容が記述され
た設計書の一部を与えます．オリジナルの設計書はExcel
形式で記述されていました．
あなたに与えられるデータはCSVであるため，罫線・色
の情報が失われており，あなたは表の形状や意味から記
述内容の繋がり（ラベル・値の上下関係）を把握し，情
報を再整理する必要があります．
[ヒント]
・表は複数のカード型のサブ表を内包しています．
・各カードは，メタデータ部分，表ヘッダ部分，表コン
テンツ部分に分かれています．
・メタデータ部分はラベル・値の組と，ヘッダを持つ小
さな表からなりますが，ラベルと値の並び順は縦・横が
混同されており，ラベルの間にも上下関係（抽象-具体関
係）がある場合があります．
・一部のラベルはマージされているため，空白セルは，
隣接する上や左のセルの値を引き継いでいると解釈され
るべき場合があります．
プロンプトによる文書の読み方の提示例
15](https://image.slidesharecdn.com/ses2025-genai-tutorial-250918055630-5fd3a716/75/LLM-AI-SES2025-15-2048.jpg)
![今後の展望：
AIエージェントによる要求（と設計）の自動化
Elicitron ⚫ 要求獲得をAIエージェントにより自動化するシミュレーションフレームワーク
⚫ ステークホルダーの候補をペルソナとして与えて対話エージェントを作成
⚫ 対話エージェントにインタビューすることによりペルソナから要求を獲得
MARE
⚫ Multi-Agent collaboration for Requirements Engineering
⚫ Elicitron と同様なアプローチだが，要求工学全体をサポートしている
Elicitation Modeling Negotiation Specification Verification Evolution
Elicitron
MARE
[1] Ataei Mohammadmehdi, Cheong Hyunmin, Grandi Daniele, Wang Ye, Morris Nigel, and Tessier Alexander:
Elicitron: An LLM Agent-Based Simulation Framework for Design Requirements Elicitation,
Journal of Computing and Information Science in Engineering. Feb 2025, 25(2): 021012 (2025).
[2] Dongming Jin, Zhi Jin, Xiaohong Chen, and Chunhui Wang:
MARE: Multi-Agents Collaboration Framework for Requirements Engineering, arXiv:2405.03256 (2024). 16](https://image.slidesharecdn.com/ses2025-genai-tutorial-250918055630-5fd3a716/75/LLM-AI-SES2025-16-2048.jpg)
![テストにおける生成AI活用
33
テスト計画
テスト設計・
レビュー
テストケース
準備
テスト実行
テスト報告書
作成
バグ修正・
回帰テスト
どのフェーズに関する論文が多いか？
→テストケース準備、
バグ修正・回帰テストが大半
論文数
[Wang+24]
0 0 46 0 8 50
[Wang+24] J. Wang, “Software Testing With Large Language Models: Survey, Landscape, and Vision,” TSE, 2024.
テスト
工程](https://image.slidesharecdn.com/ses2025-genai-tutorial-250918055630-5fd3a716/75/LLM-AI-SES2025-33-2048.jpg)
![テストにおける生成AI活用の研究動向1：
テストデータ生成
• 研究事例：Faker.jsライブラリでは生成できない文化的背景や
制約を考慮したテストデータを生成
42
[Baudry+24] B. Baudry et al., "Generative AI to Generate Test Data Generators," in IEEE Software, vol. 41, no. 6, pp. 55-64, Nov.-Dec. 2024](https://image.slidesharecdn.com/ses2025-genai-tutorial-250918055630-5fd3a716/75/LLM-AI-SES2025-42-2048.jpg)
![テストにおける生成AI活用の研究動向2：ファジング
• 生成AI利用のポイント
• 研究事例
• ChatAFL[Meng+24]：機械可読ではないプロトコル仕様からテストシナリ
オ・データを構築。従来手法に比べ約5 ～ 6% 高い分岐網羅率を達成
し、新規脆弱性を実プロトコルから発見。
43
シード選択
対象
プログラム
シード集合
モニタリング
テスト実行
エラーが発生
したか？
エラー情報
を出力
Yes
No
エラー情報
カバレッジが
増加したか？
新規シード
追加 Yes
No
シード変異
シード生成
入力
出力
結果評価
[Meng+24] R. Meng. “Large language model guided protocol fuzzing,” NDSS, 2024.
意味的・構造的に有効
な生成・変異が可能
意味的・構造的に有効
な生成・変異が可能
潜在的な異常挙動や
バグ聴講を検知可能](https://image.slidesharecdn.com/ses2025-genai-tutorial-250918055630-5fd3a716/75/LLM-AI-SES2025-43-2048.jpg)
Uploaded byHironori Washizaki
LLM/生成AI＆エージェントによるソフトウェア開発の実践と展望（SES2025チュートリアル）
鷲崎 弘宜, 鵜林 尚請, 増田 航太, 徳本 晋, 竹之内 啓太, 斎藤 忍, "LLM/生成AI＆エージェントによるソフトウェア開発の実践と展望", ソフトウェアエンジニアリングシンポジウム2025 (SES2025), 2025年9月18日
More Related Content
![[Observability conference 2022/3/11] NewsPicks のプロダクト開発エンジニアが実践するスキルとしての SRE](https://cdn.slidesharecdn.com/ss_thumbnails/observabilityconference2022311newspickssre-220310143345-thumbnail.jpg?width=640&height=640&fit=bounds)
![S03_まずはここから！Microsoft 365 E3 でセキュリティの第一歩を踏み出す [Microsoft Japan Digital Days]](https://cdn.slidesharecdn.com/ss_thumbnails/s03microsoft365e3-211028133442-thumbnail.jpg?width=640&height=640&fit=bounds)
![[JAWSBigData#11]Cloudera on AWSと Amazon EMRを両方本番運用し 3つの観点から比較してみる](https://cdn.slidesharecdn.com/ss_thumbnails/dljawsbigdata11clouderaonawsamazonemr3-180207013607-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to LLM/生成AI＆エージェントによるソフトウェア開発の実践と展望（SES2025チュートリアル）
![[四国クラウドお遍路 2024 in 高知] Generative AI with AWS](https://cdn.slidesharecdn.com/ss_thumbnails/generativeaiwithaws-240907082621-b34278af-thumbnail.jpg?width=640&height=640&fit=bounds)
LLM/生成AI＆エージェントによるソフトウェア開発の実践と展望（SES2025チュートリアル）
- 1. LLM/生成AI＆エージェントによる ソフトウェア開発の実践と展望 - 設計からテスト、さらには組織や業界のあり方まで - 鷲崎弘宜（早稲田大学），鵜林 尚請（早稲田大学），増田 航太 （SI&C），徳本 晋（富士通），竹之内 啓太（NTTデータグルー プ），斎藤 忍（NTT） 1 ソフトウェアエンジニアリングシンポジウムSES2025 チュートリアル 2025年9月18日
- 2. 成果ソフト ウェア・文書 ソフトウェア開発×生成AI • 従来ツールでは困難であった広範な一般知識を要する多種多様な一般タスク遂行 • ファインチューニングや文脈内学習により専門・文脈知識を与えて専門タスク遂行 •思考過程、自然な対話、エージェント化 ⇒ 圧倒的に高効率なAI駆動開発、“開発” 者の広がり 2 ソフトウェア・非ソフトウェア 一般知識 ドメイン・組織・プロジェクト・タスク 専門知識 タスク 個別・文脈知識 LLM, VLM 大規模 コーパス 事前学習 訓練済み モデル 個別データ セット ファイン チューニング プロンプト Web・個別 拡張済み プロンプト フィード バック ファインチューニ ング済みモデル 例 例 文脈内学習・RAG 一般タスク成果 個別タスク成果 LLM拡張 拡張モデル 専門タスク成果 情報処理学会 監修, 鷲崎 編著, 家村・石川・鵜林・蛯名・小川・川上・近藤・竹之内・徳本・中川・増田 著, ”生成AIによるソフトウェア開発”, オーム社, 2025年11月予定
- 3. AIエージェントベース開発: MetaGPTの例 3 MetaGPT: Meta Programmingfor A Multi-Agent Collaborative Framework, ICLR 2024 情報処理学会 監修, 鷲崎 編著, 家村・石川・鵜林・蛯名・小川・川上・近藤・竹之内・徳本・中川・増田 著, ”生成AIによるソフトウェア開発”, オーム社, 2025年11月予定
- 4. 4 留意点 • 計算リソース、ハルシネーション • 評価の難しさ、ベンチマーク汚染 •プロプライエタリLLM、著作権 LLM活用のSEタスク [Hou+24] • コード生成・修正が中心 • 要求や設計、マネジメント活用限定的 X. Hou, et al., “Large Language Models for Software Engineering: A Systematic Literature Review,” ACM TOSEM, 33(8), 2024 情報処理学会 監修, 鷲崎 編著, 家村・石川・鵜林・蛯名・小川・川上・近藤・竹之内・徳本・中川・増田 著, ”生成AIによるソフトウェア開発”, オーム社, 2025年11月予定
- 5. 5 生成AIによるソフトウェア開発 設計からテスト、マネジメントまでを全 て変革するLLM活用の実践体系 情報処理学会 監修（ソフトウェア工学研究会レビュー） 鷲崎 編著,家村・石川・鵜林・蛯名・小川・川上・近藤・ 竹之内・徳本・中川・増田 著, オーム社, 2025年11月予定 目次 1. 生成AIの仕組み 2. 生成AIによるソフトウェアの要求 3. 生成AIによるソフトウェアの設計 4. 生成AIによるプログラムの実装 5. 生成AIによるソフトウェアのテスト 6. AIエージェントによるソフトウェア開発の自動化 7. 生成AIの評価 8. 生成AIを活用したプロセスとマネジメント 9. 生成AIによるソフトウェア産業の将来
- 6. 生成AIによるソフトウェアの 要求と設計 鵜林 尚靖（早稲田大学 理工学術院国際理工学センター） 6
- 7.
- 8. 企業開発者の期待（社会人教育の受講生） • 要求獲得時の壁打ちとして生成AIが活用できないか． • ハルシネーションを逆活用することにより，思っても見なかっ た斬新な要求が獲得できないか． •ハルシネーションとなるのは人間でも間違いやすい判断であり， これを要求仕様の不足点として活用できないか． • 生成AIに複数の要求仕様を出力させその中から一番良いものが 選択出来ないか． 8
- 9. 要求と設計における生成AI活用の研究動向 Large Language Modelsfor Software Engineering: A Systematic Literature Review. Xinyi Hou, Yanjie Zhao, Yue Liu, Zhou Yang, Kailong Wang, Li Li, Xiapu Luo, David Lo, John Grundy, Haoyu Wang, ACM Transactions on Software Engineering and Methodology, Volume 33, Issue 8, Article No.220, Pages 1 – 79, 2024. 9
- 10. REBOKと要求におけるSEタスク 要求工学の基礎 要求工学プロセス 要求獲得 要求分析要求仕様化 要求の検証・妥当性の確認・評価 要求の計画と管理 実践の考慮点 Anaphoric ambiguity treatment (4)（前方照応的な曖昧さ） Requirements classification (4) Requirements analysis and evaluation (2) Specification generation (2) Specification formalization (1) Use cases generation (1) Requirements elicitation (1) Coreference detection (1) Traceability automation (1) REBOK 共通知識カテゴリ 一般社団法人情報サービス産業協会REBOK企画WG: 要求工学知識体系 第1版, 近代科学社 (2011). 少ない！ 10
- 11. 要求工学 旗艦国際会議 RE2025の傾向 （データ駆動，データサイエンス，LLM活用へ） ⚫ Research Track（23本中9本がLLM関連） ⚫ RE Next! （15本中5本がLLM関連） ⚫ Industrial Innovation（12本中3本がLLM関連） 本日は最新の情報を紹介！ 注）タイトルにLLMが入っているもののみ（実際にはもっと多い） 11
- 12. 要求獲得（RE2025 論文より） Sallam Abualhaija,Marcello Ceci, Nicolas Sannier, Domenico Bianculli, Salomé Lannier, Martina Siclari, Olivier Voordeckers, and Stanisław Tosza: LLM-assisted Extraction of Regulatory Requirements: A Case Study on the GDPR Alexander Korn, Andreas Vogelsang, and Smuel Gorsch: LLMREI: Automating Requirements Elicitation Interviews with LLMs Christopher Lazik, Ines Nunes, Lars Grunske, Thomas Kosch, Aaron Ziglowski, Charlotte Kauter, Alina Pryma, and Christopher Katins: The Good, the Bad, and the Uncanny: Investigating Diversity Aspects of LLM-Generated Personas for Requirements Engineering Ryota Sugiyama, Hironori Washizaki, Naoyasu Ubayashi, Ryoko Tanahashi, Mai Hirabayashi, Satoshi Okuda, and Ken Toriumi: Continuous Data-Driven Personas Generation: An LLM-based Knowledge Graph Approach LLMとRAGを利用してGDPRに関連する定義済みの法的ソースからプライバシーに 関わる要求を自動で抽出 最小限の人間の介入で要求獲得のためのインタビューを実施するLLMベースの チャットボットLLMREI LLMが生成するペルソナにおいて多様性がどのように考慮されているかを調査した 結果，要求工学にとって意味のあるものに変換できていない可能性がある LLMを用いて収集データを継続的に分析すると共にナレッジグラフを動的に構築・ 更新することにより，ユーザ要求を迅速かつ最新に反映したペルソナを生成 法令 インタ ビュー データ駆動 ペルソナ 12
- 13. 要求仕様化（RE2025 論文より） Taohong Zhu,Lucas Cordeiro, and Youcheng Sun: ReqInOne: A Large Language Model-Based Agent for Software Requirement Specification Generation Ryu Okamoto and Shinji Kusumoto: Towards the Automatic Restructuring of Software Requirements Specifications to Conform to Standards Using Large Language Models 自然言語で記述されたテキストを構造化されたソフトウェア要求仕様書（SRS）に変換するた めに，人間の要求エンジニアの推論を模倣するLLMベースのエージェントReqInOneを提案 （ReqInOneは，要約，要求抽出，要求分類の3つのタスクから構成 ） どのような構造のSRSでも自動的に標準構造（IEEE 830，ISO/IEC/IEEE 29148）に変換する LLMベースのアプローチを提案 SRS 標準構造 A I エージェント 13
- 14.
- 15.
- 16. 今後の展望： AIエージェントによる要求（と設計）の自動化 Elicitron ⚫ 要求獲得をAIエージェントにより自動化するシミュレーションフレームワーク ⚫ステークホルダーの候補をペルソナとして与えて対話エージェントを作成 ⚫ 対話エージェントにインタビューすることによりペルソナから要求を獲得 MARE ⚫ Multi-Agent collaboration for Requirements Engineering ⚫ Elicitron と同様なアプローチだが，要求工学全体をサポートしている Elicitation Modeling Negotiation Specification Verification Evolution Elicitron MARE [1] Ataei Mohammadmehdi, Cheong Hyunmin, Grandi Daniele, Wang Ye, Morris Nigel, and Tessier Alexander: Elicitron: An LLM Agent-Based Simulation Framework for Design Requirements Elicitation, Journal of Computing and Information Science in Engineering. Feb 2025, 25(2): 021012 (2025). [2] Dongming Jin, Zhi Jin, Xiaohong Chen, and Chunhui Wang: MARE: Multi-Agents Collaboration Framework for Requirements Engineering, arXiv:2405.03256 (2024). 16
- 17.
- 18.
- 19. 生成AIによるプログラム実装の背景 19 技術革新 我が国の課題 ◼ ソフトウェア開発の中核となる「プログラム実装」を対象にして、全世 界的に生成AIの開発が進む ◼ OpenAI Codex、Claude CodeなどAIコード生成に対応した多 くのツールが矢継ぎ早にリリース、IDEとの統合も進む ◼ DX加速やＩＴ人材不足により、品質低下や技術的負債が社会的課題 ◼ 経済産業省「2025年の崖」問題において、IT人材不足がDXの推進 と品質維持の両立を困難にしていると指摘 生成AIを活用した「プログラム実装」注目が集まり、 期待値が高まっている
- 20. 生成AIが適したプログラム実装タスク 20 01 02 03 04 05 06 07 08 ► コードの生成/補完 ► コード内のコメント生成 ►API/ライブラリの利用方法の提示 ► コードからのドキュメント生成 ► コードレビュー ► デバッグ支援 ► リファクタリング支援 ► テストケース/テストプログラムの生成 生成A Iが適した プログラミング 自動化および 関連タスクの例 ◼ プログラムコード関連タ スクにおける生成AIの 活用範囲は非常に広い ◼ プログラミングタスクの さまざまなシチュエー ションで恩恵を受けるこ とが可能
- 21. 生成AIのプログラミング応用の定義 21 タスク 定義 LLMの役割 コード生成 ユーザー要求と指定された制約に基づいてソースコードを自動 生成 (補助）コードを生成、開発者にアイデアやプログラミングの「出 発点」を提供 コード要約 開発者がコードを理解し、維持するのを助けるために、明確で、 正確で、役に立つコードコメントを自動的に生成 異なる粒度（例えば関数）を支援したり、コードの意図を説明した りするコード要約 コード翻訳（変換） 異なるプログラミング言語間で、機能やロジックを変えることな くコードを変換すること 補助コード変換、リバースエンジニアリング 欠陥検出 プログラムのクラッシュ、パフォーマンス低下、セキュリティ問題 の原因となるコードエラーを特定し、修正 コードに潜在的な欠陥がないかチェック コード評価・テストコードの静的解析を行い、潜在的な問題や改善点を特定 テストケースを作成したり、コードのパフォーマンス、ユーザビリ ティ、その他の品質特性をテスト コードマネジメント コードの版や開発者情報のマネジメント チーム協調開発、版管理 問い合わせ・相談Q&A ソフトウェア開発者とLLMのやり取り アシスタント、プロンプトエンジニアリング 出展： Zheng, Z., Ning, K., Zhong, Q., Chen, J., Chen, W., Guo, L., Wang, W., and Wang, Y.: Towards an understanding of large language models in software engineering tasks, Empirical Software Engineering, Volume 30, article number 50 (2025).
- 22. プログラム実装における生成AI活用の実践事例 22 オーストラリア・ ニュージーランド銀行 ◼ エンジニア5,000人以上の大規模組織でGitHub Copilotを評価 ◼コード品質・セキュリティ・エンジニアの感情面を調査し、生産性とコード 品質が顕著に向上し、有効性を確認 東京海上日動システムズ ×日本IBM ◼ 詳細設計書からプロンプトを生成し、コード生成に活用するための実証実 験を実施 ◼ アプリ改修や新規開発において、平均40%、最大90%の生産性向上を 達成 TOPPAN ホールディングス ◼ 社内システム開発に特化したLLMを導入し、LLM活用により最大70% の業務時間短縮を確認 ◼ OSS-LLMを自社サーバーで稼働させ、高セキュリティ環境で運用 住友ゴム工業 ◼ 製品開発工程で複数言語のカスタムツールを内製しており、習得や環境 構築に課題があった ◼ Gemini Code Assistを導入し、コード生成・補完・変換を活用し、プロ グラミング生成性の向上を実現
- 23. コード生成に対応するツールとIDE 23 発表者調べ(2025) ツール名 対応IDE 主要機能価格（2025年） 推奨ユーザー GitHub Copilot X VS Code, JetBrains IDE, Neovim など インライン補完、Copilot Chat、PR作成、テ スト生成、Agentモード 月額 $10〜 （Pro/Businessあり） 幅広い開発者、GitHub連携を 重視するユーザー Cursor 専用IDE （VS Codeベース） プロジェクト全体理解、自然言語指示、複数 ファイル対応、Claude連携、Slack連携など 無料（Hobby）/Pro $20〜 中〜上級者、大規模開発、AIと の対話型開発を重視 JetBrains AI Assistant IntelliJ IDEA, PyCharm, WebStorm など 補完、コード説明、リファクタ、チャット、 言語変換 JetBrains IDEに含まれる （有料） JetBrains IDEユーザー、IDE 統合を重視する人 Codeium VS Code, JetBrains IDE, Vim, Jupyter など 補完、チャット、リポジトリ理解、 70+言語対応 完全無料（個人利用） 無料で高性能を求める開発者 Tabnine VS Code, JetBrains IDE, Eclipse, Android Studio など 補完、API説明、テスト生成、言語変換 無料/Pro $12/月 プライバシー重視、オンプレミス 利用者 Amazon Q Developer VS Code, JetBrains IDE, AWS Cloud9, CLI など 補完、セキュリティスキャン、テスト生成、OSS ライセンス補助、Amazon Qチャット 無料（Basic）/Pro $19/月 AWSユーザー、クラウド連携重 視、セキュリティ重視 Replit Ghostwriter Replit （WebベースIDE） 補完、エラー解説、チャット、即時実行、教育向 け設計 無料/Pro $20/月 初心者、教育用、Web開発入門 者 Claude Code Action GitHub Actions （CI/CD連携） PR・Issue対応、修正提案、テスト生成、自然 言語操作、CI統合 月額 $17〜（Sonnet） /$20〜（Opus） GitHub中心の開発者、CI/CD 自動化を進めたいチーム OpenAI Codex (GPT-4o) VS Code, CLI, ChatGPT API 経由 自然言語からのコード生成、複数タスク同時処 理、長文文脈対応 ChatGPT Proに含まれる （$20/月） 高度な自動化や研究開発、複雑 なコード生成が必要な人
- 24. コード生成に適したLLM 24 モデル名称 開発元 リリース時期 学習データのうち コードが占める割合 得意とする言語 CodeLlama 70B Meta 2024年1月 高 Python, C++, Java, PHP, TypeScript, C#, Bash GitHub Copilot GitHub (Microsoft) 継続更新中 非公開 JavaScript, Python, TypeScript, Go, Ruby, Java, C#, C++ Amazon Q Developer Amazon Web Services 2024年 非公開 Python, Java, JavaScript, TypeScript, C#, Go IBM Watsonx Code Assistant IBM 2024年 非公開 Java, COBOL, Python, JavaScript Tabnine Tabnine 継続更新中 非公開 25以上の言語 (JavaScript, Python, Java, C++, C# など) Replit Agent Replit 2024年 非公開 80以上の言語 Sourcegraph Cody Sourcegraph 2024年 非公開 25以上の言語 (JavaScript, Python, Go など) 発表者調べ(2025)
- 25.
- 26. コード生成における留意事項 26 プロンプトマネジメント ◼ 目的に応じて、ゼロショット、フューショット、思考の連鎖（CoT）を使い分ける ◼ 具体例（フューショット）や論理ステップ（CoT）を与えることにより、文脈理解力を 引き出し、仕様準拠性を高めることができる ハルシネーション対策 ◼コード比率の高いLLMを選択し、プロンプトに利用ライブラリやAPI制約、コーディ ング規約を明示する ◼ RAGで最新のAPI仕様や設計文書を参照可能にする コードレビュー ◼ 人間によるレビューとプロンプト調整を繰り返すフィードバックループを構築する ことが重要 ◼ 直近ではマルチエージェントによりレビューや改善提案の自動化･半自動化も進展 セキュリティ脆弱性 ◼ インジェクション攻撃や、ハードコーディングされた認証情報などのセキュリティリ スクが潜在 ◼ プロンプトにセキュリティ要件を明示することで、安全性を高めることができる 著作権 ◼ 生成AIにより作られたコードを商用利用する場合、その権利は利用したサービス の利用規約に依存（例：OpenAI社は、すべての権利と利益を利用者に譲渡） ◼ 所属する企業やプロジェクト、顧客など関係者の同意と許可を得た上で実用する
- 27.
- 28. 実開発への応用と実践的なプロンプト設計 ◼ CoT(Chain-of-Thought:思考の連鎖）におけるプロンプト構成 ① 指示文書（例：あなたは非常に優秀なプログラマです．以下の規約と設計書をもとにソースコードを生成し てください．） ②規約（例：pythonでコーディングすること．） ③ 設計書（テキスト化された具体的な設計情報） ◼プロンプトに必要な設計情報の例（バンクエンドAPI） 28 項目 内容 アプリケーション基本情報 システム名や処理ID、処理概要など API仕様 メソッド種別、ヘッダ、リクエスト形式、 レスポンス形式など 処理フロー 処理のフローチャート テーブル定義 検索対象のデータベースの項目定義 処理詳細 処理フローの詳細を文章で記載
- 29. プログラム実装における生成AI活用の研究・開発動向 29 自律型エージェント ◼ Devin(Cognition)：プログラム開発プロセス全体を自律的に進める。 従来のCopilotのような支援型から一歩進んだ形態 ◼ OpenHands：DevinにインスパイアされたオープンソースのAIツール キット LLMの進化 ◼DeepSeek：Mixture of Experts（MoE）や強化学習を採用した新 アーキテクチャ ◼ Mercury Coder（InceptionLabs）：拡散モデル（dLLM）をベース にした新型LLM。毎秒1,000トークンで従来の10倍以上かつ高精度 体系的調査 ◼ Zibin Zhengら、Juyong Jiangら、Avinash Anandらがコード生 成LLMに関する体系的調査を実施 ◼ タスク・ベンチマークや倫理・環境課題、応用事例を調査 データセットの 限界と課題 ◼ 特定タスク向けの最適化データセットが不足、データセットの品質的な問 題がある ◼ 逆アセンブル、セキュリティ解析など多様なタスクで性能限界があり、今 後は高品質・多様なデータの拡充が不可欠
- 30. プログラム実装における生成AI活用の未来像 30 自動化 ナレッジ コード ドキュメント 生成AI人間 品質責任 創造性 独自性 手足のように使いこなす力 支援・補助 人間は創造性や設計力を磨き、AIが真似できない付加価値を提供 人間と生成AIが協働する未来に向かった進化が鍵
- 31.
- 32.
- 33. テストにおける生成AI活用 33 テスト計画 テスト設計・ レビュー テストケース 準備 テスト実行 テスト報告書 作成 バグ修正・ 回帰テスト どのフェーズに関する論文が多いか？ →テストケース準備、 バグ修正・回帰テストが大半 論文数 [Wang+24] 0 0 460 8 50 [Wang+24] J. Wang, “Software Testing With Large Language Models: Survey, Landscape, and Vision,” TSE, 2024. テスト 工程
- 34.
- 35.
- 36. テストにおける生成AI活用の留意事項 責任ある利用 • 生成AIが提案するテストケースや結果などを過信せず、必ず人間がその妥当性を 確認し、最終的な判断と責任を持つようにします。 透明性の維持 • AIがどのようにテストケースや結果などを導き出したのかを明確に示し、利用者 や関係者がその根拠や妥当性を理解できるようにします。 継続的な監視と改善 •AIを活用したテストの効率や精度を定期的に評価し、問題が起きた場合に早期に 気付いて改善を進められるようにします。 36 誤りを前提とし、人が責任を持つ体制を構築
- 37. テストにおける生成AI活用の実践事例 • テスト仕様書生成の流れ 37 1. テスト ベースの 準備 2.仕様把 握・目的・テ ストアイテム の明確化 3. テスト観 点・テスト 条件の抽出 4. テストケー ス（概要）の 作成 5. テスト ケース（詳 細）の定義 6. テスト仕 様書の最終 レビューと 整合性確認 人による確認・修正 AIによる段階的詳細化＋人による確認・修正
- 38. テストにおける生成AI活用の実践事例 • テスト仕様書生成のプロンプト例（仕様把握・目的・テストア イテムの明確化） 38 - 仕様を要約しテスト範囲・目的を明確化。 -テストアイテム（モジュール/画面/機能）を抽出し、 ITEM-XXX形式でID付与。 - 要求・非機能要求・リスクを抽出し、REQ/NF/RISK- XXX形式で連番ID付与。 - 不明点は「不明」と記録、後日確認。 - 出力形式： ・テストアイテム一覧（ITEM-XXX, 名称/範囲） ・要求・リスク一覧（REQ/NF/RISK-XXX, 名称, 概要） ・テスト目的・完了基準（箇条書き可） - 出力は後工程でのID管理・差分チェックに使用。 - 入力：仕様書、既存リスク資料、非機能要求、プロジェ クト計画（納期・予算等） 要件やテスト観点などにIDを付 与しトレーサビリティを確保 フォーマットを与え、出力を安 定化 より正しい理解につながる意図 の説明や背景知識なども含める
- 39. テストにおける生成AI活用の実践事例 • テスト仕様書生成のプロンプト例（テスト仕様書の最終レ ビューと整合性確認） 39 - Step1～4の成果物（ITEM/REQ/RISK/C/G/Dの各ID） を「テスト仕様書」として章立てでまとめる。 -構成例：①はじめに、②テストアイテム・要求/リスク 一覧、③観点一覧、④ケース(概要)、⑤ケース(詳細)、⑥ トレーサビリティ(REQ→C→G→D)、⑦指摘・修正履歴。 - 全REQ/RISKが最終的に詳細ケース(D-XXX)まで到達し ているか、AIで差分チェック。 - 指摘があればStep2～4を再生成し、最終レビュー後に テスト実行へ移行。 - 差分チェック例：「要求/リスク一覧 vs 詳細ケース一覧 で未カバーIDは？」 - 入力：Step1～4の成果物（ID付き一覧）、レビュー指 摘事項・追加要求 メタ認知的にチェックさせる
- 40. テストにおける生成AI活用の実践事例 • テスト仕様書生成の出力例 40 # **テスト仕様書** ##**1. はじめに** 本テスト仕様書は、学務業務を効率化する Web システム のテスト計画を定義し、各機能の動作確認、非機能要求 の検証、および潜在的リスクの特定を目的としていま す。 ## **2. テストアイテム・要求/リスク一覧** ### **2.1 テストアイテム一覧** | ID | 名称/範囲 | | ---------- | ----------------------------------- | | ITEM-001 | シラバス管理機能 | | ITEM-002 | 履修情報管理機能 | | ITEM-003 | 成績管理機能 | | ITEM-004 | 認証および権限管理機能 | | ITEM-005 | データ検索・フィルタリング機能 | : 人・AI双方が確認しやすい形式で出力
- 41. テストにおける生成AI活用の研究動向1： テストデータ生成 • データ種類 ：数値、テキスト、画像など •用途 ：境界値テスト、ダミーユーザデータ生成、 脆弱性テスト（SQLインジェクション攻撃など） • 適用パターン：典型的には以下2パターン 41 生成AI テストデータ プロンプト データ生成 プログラム 生成AI プロンプト テストデータ パターン1：テストデータを直接生成 パターン2：データ生成プログラムを生成 多様性 コスト 実行時間 コスト 実行時間 多様性
- 42. テストにおける生成AI活用の研究動向1： テストデータ生成 • 研究事例：Faker.jsライブラリでは生成できない文化的背景や 制約を考慮したテストデータを生成 42 [Baudry+24] B.Baudry et al., "Generative AI to Generate Test Data Generators," in IEEE Software, vol. 41, no. 6, pp. 55-64, Nov.-Dec. 2024
- 43. テストにおける生成AI活用の研究動向2：ファジング • 生成AI利用のポイント • 研究事例 •ChatAFL[Meng+24]：機械可読ではないプロトコル仕様からテストシナリ オ・データを構築。従来手法に比べ約5 ～ 6% 高い分岐網羅率を達成 し、新規脆弱性を実プロトコルから発見。 43 シード選択 対象 プログラム シード集合 モニタリング テスト実行 エラーが発生 したか？ エラー情報 を出力 Yes No エラー情報 カバレッジが 増加したか？ 新規シード 追加 Yes No シード変異 シード生成 入力 出力 結果評価 [Meng+24] R. Meng. “Large language model guided protocol fuzzing,” NDSS, 2024. 意味的・構造的に有効 な生成・変異が可能 意味的・構造的に有効 な生成・変異が可能 潜在的な異常挙動や バグ聴講を検知可能
- 44. テストにおける生成AI活用のまとめ • テストケース準備を中心に事例・研究動向を紹介 • AIによる段階的詳細化＋人による確認・修正 •GUIテスト、APIテストなどは商用ツール・サービスも多い • 今後の展望 1. プロジェクト全体を俯瞰する能力 2. 対話型の仕様明確化プロセスの実現 3. テスト目的に応じた多様な手法の選択と自動運用 4. 仕様変更・コード変更への継続的な追従能力 5. 説明可能性と透明性の向上 44
- 45.
- 46.
- 47. 生成 AI 導入で期待できる効果 47 時間軸 人 手 DeveloperExperience （開発者体験） As-Is 成果物の 品質 生成 AI 導入 • 気持ちよく開発 • エンゲージメント向上 具体的な評価観点は SPACE フレームワーク※ など 現状の作業工数 Cost (作業にかかる労務費) 少ない人手 Delivery （リリースまでの期間） 短い期間 Quality （成果物の品質） 高い品質 多くの場合、生成 AI はプロジェクトの QCD の改善を目的として導入される
- 48. 生成 AI 導入がコストに見合うか？ 48 中長期的なツール導入効果を評価するために投資回収モデルが用いられる 回収額(円)= 導入前の労務費(円) × 削減率(%) 時間軸 導入期 維持期 初期投資 回収額 回収額 回収額 投資回収点 維持費 維持費 維持費 コ ス ト ... 累積コスト ※ (傾き)>0 なら長期的にペイする 導入にかかったコスト （環境構築・学習コストなど）
- 49. 生成 AI 導入の進め方 49 取り組む問題を 定義 Define 全体像の把握 Measure 改善箇所の決定 Analyze 生成AIの 導入と検証 Improve 安定的な運用 Control 開発プロセスを生成AI 導入により改善するにはトップダウンなアプローチ が適切。“DMAIC フレームワーク” を例として紹介。
- 50. 生成 AI 導入の進め方– Define フェーズ 50 初期投資 回収額 回収額 回収額 維持費 維持費 維持費 回収額 (= 導入前の労務費 × 削減率 ) を 最大化 する 最大化する （ボリュームゾーンを狙う） 最大化する （効果的な領域を狙う） 投資回収モデル 開発プロセスに生成AIを導入することで解決する問題を明確化。 基本的には、投資回収モデルにおける「回収額」を最大化することが目的。
- 51. 生成 AI 導入の進め方– Measure フェーズ 51 時間軸 人 手 成果物品質 優先度 １位 〃 ２位 〃 ３位 作業A B C D E F G H ここを改善して も仕方ない! 開発プロセスを構成する各作業のボリュームを整理。 特に作業ボリュームの大きなものを改善の対象とする。
- 52. 生成 AI 導入の進め方– Analysis フェーズ 52 改善対象の作業のうち生成 AI により改善できる箇所を特定。 現行プロセスの可視化 1. ユースケースの検討 2 . 改善箇所の選定 3. 作業ボリューム AI による実現性 単体テスト 設計 単体テスト 実装 単体テスト 実行 単体テスト ケース表 単体テスト 作業要領 ユニット 設計書 単体テスト コード 単体テスト 証跡 プログラム コード ユニット 設計書 単体テスト ケース表 要 件 １ 単体テスト ケース表 単体テスト コード 要 件 ２ 単体テスト 作業要領 単体テスト コード 単体テスト 証跡 要 件 ３ プログラム コード 入力 AI への要件 出力 〇 要 件 １ × △ 要 件 ２ × × 要 件 ３ × （従来の自動化が適切）
- 53. 生成 AI 導入の進め方– Improve フェーズ 53 ユースケースに適した生成 AI 技術の導入により開発作業の効率を向上。 開発者の作業を AI で代替するためには開発者の知識を再現することが重 要。 未知 暗黙知 非テキスト テキスト プロジェクト固有情報 既知 形式知 テキスト化 一般知識 開発環境 AI システム 思考 プランニング コンテキスト タスク タスク抽出 理解 形式知化 --- 凡例 --- 人間の営み 情報の流れ AI にとっての 扱いやすさ Easy Hard 環境に作用する 反応を得る 人に問う 回答を得る 見つけて読む 見つけて読む 与えられる 出典：Responsible Software Development in the Era of Generative AI, NTT DATA Group, 2025
- 54. 生成 AI 導入の進め方– Control フェーズ 54 生成 AI 技術の導入後は、期待した効果が持続していることを確認。 時間経過による入出力データの傾向の変化（コンセプトドリフト）に注意。 回収額 回収額 回収額 時間軸 導入期 維持期 初期投資 維持費 維持費 維持費 コ ス ト ... 当初期待していた 投資回収計画 運用後の実態 ⇒ 再検討が必要
- 55. さいごに ~研究コミュニティに向けて~ 55 引用：A ThreeCycle View of Design Science Research, Alan R. Hevner, Scandinavian Journal of Information Systems, 2007 実用的な技術の研究はデザインサイエンスリサーチ(DSR)の知見が参考になります
- 56. © NTT, Inc.2025 チュートリアル： LLM/生成AI＆エージェントによるソフトウェア開発の実践と展望 - 設計からテスト、さらには組織や業界のあり方まで – 「生成AIによるソフトウェア産業の将来」 NTT株式会社 斎藤 忍 2025年9月18日 ソフ ウェアエ ジニアリ グシ ポジウム2025
- 57. © NTT, Inc.2025 57 発表内容 • ソフトウェア開発のソーシングの多様化 • 2030年のソフトウェア開発 • 2030年の開発プロセス
- 58. © NTT, Inc.2025 58 ソーシングの多様性の広がり Machado, Letícia Santos. “Empirical studies about collaboration in competitive software crowdsourcing.” (2018). 匿名性の レベル 報酬タイプの種類 （非匿名性） （無報酬） （支払額確定） （タスク単位支払） （固定給） （匿名性） 従来型のOutsourcingに加えて、ソーシングの新しい形態（Crowdsourcing、 Innersourcing）の産業界での実践が進んでいる
- 59. © NTT, Inc.2025 59 Software development company Developer Developer アウトソーシング（従来型） • クライアントは，開発者を雇用するソフトウェア開発会社に対し開発を依 頼．開発会社内で，マネジメントして開発を行う． • 出来上がったソフトウェアに対して，クライアントがソフトウェア開発会社 に対価を支払う Client Project Developer
- 60. © NTT, Inc.2025 60 クラウドソーシング • クライアントは，要求（タスク）と報酬をプラットフォームを介して公開 • 開発者は、自分にスキル・時期・対価等がマッチする要求を選択し遂行 • クライアントと開発者の間でタスク成果と報酬を交換する Developer pool Client Crowdsourcing Platformer
- 61. © NTT, Inc.2025 61 インナーソーシング • オープンソースコミュニティのようにソースコードを組織内で公開 • 正式にアサインされたプロダクト以外にも自発的にバグを指摘・コードを修正 • 多数＆多様な開発者の参加 で、問題解決が早くなる • 組織内での重複開発が減る • プロジェクト内に閉じてい た専門知識が共有される • 内部リソース活用よるコス ト削減 • 主担当プロジェクト以外の 開発にかかわることで，従 業員の学習意欲が高まる Product A Product B Product C Project A Developer Project B Developer Project C Developer
- 62. © NTT, Inc.2025 62 発表内容 • ソフトウェア開発のソーシングの多様化 • 2030年のソフトウェア開発 • 2030年の開発プロセス
- 63. © NTT, Inc.2025 63 2030年のSW開発 Software Makersによる開発 これまでの開発 「作る人」と「使う人」が分断された専任メンバーによる固定的な活動 Software Makers • 専門的な知識を持たない個人であり、自律型エージェントや高度なAIツールの支援を 受けてソフトウェアの作成プロセスを管理し、それに参加できる人々 • カナダ・クイーンズ大学Ahmed E. Hassan教授らが提唱する「Software Engineering 3.0」のなかでも言及 これからの開発 ユーザが開発の担い手として広く深く参画し、スポットエンジニアも活躍する、 多様な人々による流動的な活動 →「Software Makersによる開発」
- 64. © NTT, Inc.2025 64 2030年のSW開発 Software Makersによる開発 AIとの協働により 開発に必要なスキル・知識のハードルが低下 → ユーザの参画範囲が拡大 PJのオンボーディングコストの低下 → エンジニアのスポット参画が拡大 3つの変化 1. AIが主要面なメンバーに 2. スポットエンジニアの参加 の拡大 3. ユーザが開発タスクの一部 を担う
- 65. © NTT, Inc.2025 65 発表内容 • ソフトウェア開発のソーシングの多様化 • 2030年のソフトウェア開発 • 2030年の開発プロセス
- 66. © NTT, Inc.2025 66 トライ・フープ モデル （Tri-Hoop Model） 「要求実装」「錬成」「ユーザエンハンス」の3つのサイクルを絶え間なく繰り返 すことにより、ソフトウェアを生成し、継続的に改善し続ける 要求実装サイクル • ユーザ企業が中心となり、シ ステム化のゴール，ユーザ要 望，運用状況を分析 • システム化要件を定義すると， AIが動くシステム・モデルを 即座に生成 • ユーザ企業は妥当性を確認 し，リリースタイミングを判断 錬成サイクル • ユーザとAIのインタラクション では実現に時間がかかる部 分をエンジニアが実装 • データの整合性等を検証 ユーザーエンハンスサイクル • 操作性など利用時の気づきを，ユーザ自ら システムへ反映させ利用性を向上 • 修正要望の影響範囲が広い，実現に開発 スキルを要する場合は，要求実装サイクルへ ユーザによる要件の入力・実 装と妥当性確認 エンジニアによる実装と検証 ユーザ自身によるシステムの利用性向上
- 67. © NTT, Inc.2025 67 現在、AIはユーザにそれなりに寄り添ってくれている 今でも • ユーザの（曖昧な）要求を、プロンプトを通じて生成AIとお 話しして、ソフトウェアを作る もう少しすると • ユーザが、既存ソフトウェアと、変更要求をプロンプトを通 じて入力すると、ソフトウェアを直してくれる • 改造開発も精度良くできるようになる
- 68. © NTT, Inc.2025 68 AIがユーザに寄り添わなくなった時、要求エンジニアはどうしよう？ その先は › AIエージェントが自社や自組織にカスタマイズされる › ユーザの曖昧な要求でもOK（ここまでは良く言われている） 更にその先は、、、 • AIエージェントがユーザの要求を、精査して拒否する？ › 「そんなサービス君らの組織に不要でしょ」 › 「この機能、使ってないじゃん。必要あるの」 › そしてAIの主張は正しい › 要求エンジニアは、ユーザとAIのどちらに寄り添うのか？