LLM/生成AI＆エージェントによるソフトウェア開発の実践と展望（SES2025チュートリアル）

鷲崎 弘宜, 鵜林 尚請, 増田 航太, 徳本 晋, 竹之内 啓太, 斎藤 忍, "LLM/生成AI＆エージェントによるソフトウェア開発の実践と展望", ソフトウェアエンジニアリングシンポジウム2025 (SES2025), 2025年9月18日

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 Programming for 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. 要求と設計にお ける生成AI活用の基本
このシステムは学務に伴う事務作業を効率化するためのものです．
教員，学生，事務職員などが利用する Webシステムであり，ブラウザを通じて，シラバスや履修状況にか
かわる情報を表示したり，成績を管理したりできます．
例：学務情報システム
要求獲得・分析・仕様化・検証 設計
プロンプトパターン
（ペルソナ，テンプレート ，画像生成 ，内省，質問洗練 など）
企業独自の
プロンプトパターン
7

8. 企業開発者の期待（社会人教育の受講生）
•要求獲得時の壁打ち として生成 AIが活用できないか．
•ハルシネーションを逆活用することにより， 思っても見なかっ
た斬新な要求 が獲得できないか．
•ハルシネーションとなるのは人間でも間違いやすい判断であり，
これを要求仕様の不足点として活用できないか．
•生成AIに複数の要求仕様を出力 させその中から一番良いものが
選択出来ないか．














8

9. 要求と設計における生成AI活用の研究動向
Large Language Models for 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. 要求と設計における生成AI活用の実践と留意事項
⚫要求と設計で用いられる文書の多くは，人間が視覚的に情報を把握
しやすいように書かれており，必ずしも 生成AIに読みやすいフォー
マットになっていない ．
⚫基本設計，詳細設計と具体度が高まるにつれ， ドメインや組織に特
化した専門的な様式の文書が増え る．組織内では標準でも，オープ
ンデータの統計的分布に依存する生成 AIとの相性はよく ない．
意味的な構造が表現できるよ
うなテキストマークアップ言
語を使おう！
LLMに対して 文書の読み方を
提示しよう！
14

15. あなたには各機能を実現する詳細処理の内容が記述され
た設計書の一部を与えます． オリジナルの設計書は Excel
形式で記述されていました．
あなたに与えられるデータは CSVであるため，罫線・色
の情報が失われており，あなたは 表の形状や意味から記
述内容の繋がり（ラベル・値の上下関係）を把握 し，情
報を再整理する必要があります．
[ヒント]
・表は複数のカード型のサブ表を内包しています．
・各カードは，メタデータ部分，表ヘッダ部分，表コン
テンツ部分に分かれています．
・メタデータ部分はラベル・値の組と，ヘッダを持つ小
さな表からなりますが，ラベルと値の並び順は縦・横が
混同されており，ラベルの間にも上下関係（抽象 -具体関
係）がある場合があります．
・一部のラベルはマージされているため，空白セルは，
隣接する上や左のセルの値を引き継いでいると解釈され
るべき場合があります．
プロンプトによる 文書の読み方の提示例
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. 要求と設計にお ける生成AI活用のまとめ
17

18. 生成AIによるプログラムの 実装
増田 航太（株式会社 SI&C）
18

19. 生成AIによるプログラム 実装の背景
19
技術革新
我が国の課題
◼ソフトウェア 開発の中核となる「プログラム 実装」を対象にして、全世
界的に生成AIの開発が進む
◼OpenAICodex、ClaudeCodeなど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.,andWang,Y.:Towardsanunderstanding oflargelanguagemodelsin
softwareengineeringtasks,EmpiricalSoftwareEngineering,Volume30,articlenumber50(2025).

22. プログラム実装における生成 AI活用の実践事例
22
オーストラリア・
ニュージーランド 銀行
◼エンジニア 5,000人以上の大規模組織で GitHubCopilotを評価
◼コード品質 ・セキュリティ ・エンジニアの感情面を調査し 、生産性とコード
品質が顕著に向上し 、有効性を確認
東京海上日動システムズ
×日本IBM
◼詳細設計書からプロンプトを生成し 、コード生成に活用するための実証実
験を実施
◼アプリ改修や新規開発において 、平均40%、最大90%の生産性向上を
達成
TOPPAN
ホールディングス
◼社内システム開発に特化したLLMを導入し、LLM活用により最大70%
の業務時間短縮 を確認
◼OSS-LLMを自社サーバーで 稼働させ、高セキュリティ 環境で運用
住友ゴム工業
◼製品開発工程 で複数言語 のカスタムツールを 内製しており、習得や環境
構築に課題があった
◼GeminiCodeAssistを導入し、コード生成・補完・変換を活用し、プロ
グラミング 生成性の向上を実現

23. コード生成に対応するツールと IDE
23
発表者調べ (2025)
ツール名 対応IDE 主要機能 価格（2025年） 推奨ユーザー
GitHubCopilotX VSCode,JetBrainsIDE,
Neovimなど
インライン補完 、CopilotChat、PR作成、テ
スト生成、Agentモード
月額 $10〜
（Pro/Businessあり）
幅広い開発者 、GitHub連携を
重視するユーザー
Cursor 専用IDE
（VSCodeベース）
プロジェクト全体理解 、自然言語指示 、複数
ファイル対応 、Claude連携、Slack連携など
無料（Hobby）/Pro $20〜 中〜上級者、大規模開発 、AIと
の対話型開発を重視
JetBrainsAIAssistant IntelliJIDEA,PyCharm,
WebStormなど
補完、コード説明 、リファクタ、チャット、
言語変換
JetBrains IDEに含まれる
（有料）
JetBrainsIDEユーザー、IDE
統合を重視する人
Codeium VSCode,JetBrainsIDE,
Vim,Jupyterなど
補完、チャット、リポジトリ理解 、
70+言語対応
完全無料（個人利用） 無料で高性能を求める開発者
Tabnine VSCode,JetBrainsIDE,
Eclipse,AndroidStudio
など
補完、API説明、テスト生成 、言語変換 無料/Pro $12/月 プライバシー重視 、オンプレミス
利用者
AmazonQDeveloper VSCode,JetBrainsIDE,
AWSCloud9,CLIなど
補完、セキュリティスキャン 、テスト生成 、OSS
ライセンス補助 、AmazonQチャット
無料（Basic）/Pro $19/月 AWSユーザー 、クラウド連携重
視、セキュリティ重視
ReplitGhostwriter Replit
（WebベースIDE）
補完、エラー解説 、チャット、即時実行 、教育向
け設計
無料/Pro $20/月 初心者、教育用、Web開発入門
者
ClaudeCodeAction GitHubActions
（CI/CD連携）
PR・Issue対応、修正提案 、テスト生成 、自然
言語操作 、CI統合
月額 $17〜（Sonnet）
/$20〜（Opus）
GitHub中心の開発者 、CI/CD
自動化を進めたいチーム
OpenAICodex
(GPT-4o)
VSCode,CLI,ChatGPT
API経由
自然言語からのコード生成 、複数タスク同時処
理、長文文脈対応
ChatGPT Proに含まれる
（$20/月）
高度な自動化や研究開発 、複雑
なコード生成が必要な人

24. コード生成に適した LLM
24
モデル名称 開発元 リリース時期
学習データのうち
コードが占める割合
得意とする言語
Code Llama 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# など)
ReplitAgent Replit 2024年 非公開 80以上の言語
Sourcegraph Cody Sourcegraph 2024年 非公開 25以上の言語 (JavaScript, Python, Go など)
発表者調べ(2025)

25. コード生成導入工程のチェック用チャート
25
LLMがコードの実
行環境と同一環境
で利用できるか ？
環境整備にトライ
する、それも無理
なら従来どおり手
入力
利用する開発言語
に適した LLMがあ
るか？
RAG構築にトライ
する、それも無理
なら従来どおり手
入力
LLMは、過去の手
入力の実績と近し
い結果を出力でき
るか？
複数のLLMを比較
する、それも無理
なら従来どおり手
入力
コード生成に適し
た処理を抽出でき
るか？
抽出できるように
構造を整理する、
それも無理なら従
来どおり手入力
LLMでコード生成
を実行可能
No
Yes
No
Yes
No
Yes
No
Yes
開発環境や言語適合性、過去実績の踏襲、処理の適合性など
多角的に導入が可能かチェックが必要

26. コード生成における留意事項
26
プロンプトマネジメント
◼目的に応じて、ゼロショット 、フューショット 、思考の連鎖（CoT）を使い分ける
◼具体例（フューショット ）や論理ステップ（CoT）を与えることにより 、文脈理解力 を
引き出し、仕様準拠性 を高めることができる
ハルシネーション対策
◼コード比率の高いLLMを選択し、プロンプトに 利用ライブラリや API制約、コーディ
ング規約を明示する
◼RAGで最新のAPI仕様や設計文書 を参照可能 にする
コードレビュー
◼人間によるレビューとプロンプト調整を繰り返すフィードバックループを構築する
ことが重要
◼直近ではマルチエージェントによりレビューや 改善提案 の自動化･半自動化も進展
セキュリティ脆弱性
◼インジェクション攻撃や 、ハードコーディングされた認証情報などのセキュリティリ
スクが潜在
◼プロンプトにセキュリティ要件を明示することで 、安全性を高めることができる
著作権
◼生成AIにより作られたコードを 商用利用 する場合、その権利は利用したサービス
の利用規約 に依存（例：OpenAI社は、すべての権利と利益を利用者に譲渡）
◼所属する企業やプロジェクト 、顧客など関係者の同意と許可を得た上で実用する

27. コード生成における RAG活用フローチャート
27
ユーザ入力
（プロンプト）
自然言語による指示入力
検索
設計ドキュメント 、技術仕
様書、ベストプラクティス
などから検索
コンテキスト拡充
検索結果から関連情報を抽
出しプロンプトに追加
コード生成
拡張されたプロンプトを
もとにコード生成
ポストプロセス
CI/CDパイプラインで 静
的解析、既存コードベース
との比較、セキュリティ
チェックを実施
ユーザ確認・修正
ユーザがコードをレビューし 、
必要に応じて検索範囲 を調
整
OK OK
NGNG
問題箇所を修正する指示を追加
検索条件や範囲を修正
プロジェクト 全体で仕様書や設計書などのドキュメント 類や
共有可能 なナレッジを 形式知化し、効率良く再利用することが 重要

28. 実開発への応用と実践的なプロンプト設計
◼ CoT(Chain-of-Thought:思考の連鎖）におけるプロンプト構成
①指示文書 （例：あなたは非常に優秀なプログラマです．以下の規約と設計書をもとにソースコードを生成し
てください．）
②規約（例：pythonでコーディングすること．）
③設計書（テキスト化された具体的な設計情報）
◼プロンプトに必要な設計情報の例（バンクエンド API）
28
項目 内容
アプリケーション基本情報 システム名や処理 ID、処理概要など
API仕様 メソッド種別、ヘッダ、リクエスト形式、
レスポンス形式など
処理フロー 処理のフローチャート
テーブル定義 検索対象のデータベースの項目定義
処理詳細 処理フローの詳細を文章で記載

29. プログラム実装における生成 AI活用の研究・開発動向
29
自律型エージェント
◼Devin(Cognition)：プログラム開発プロセス全体を自律的に進める 。
従来のCopilotのような支援型から一歩進んだ形態
◼OpenHands ：Devinにインスパイアされたオープンソースの AIツール
キット
LLMの進化
◼DeepSeek：MixtureofExperts（MoE）や強化学習を採用した新
アーキテクチャ
◼MercuryCoder（InceptionLabs）：拡散モデル （dLLM）をベース
にした新型 LLM。毎秒1,000トークンで従来の 10倍以上かつ高精度
体系的調査
◼ZibinZhengら、JuyongJiangら、AvinashAnandらがコード 生
成LLMに関する体系的調査 を実施
◼タスク・ベンチマークや 倫理・環境課題 、応用事例 を調査
データセットの
限界と課題
◼特定タスク向けの最適化データセットが不足 、データセットの品質的な問
題がある
◼逆アセンブル 、セキュリティ解析など多様なタスクで性能限界があり 、今
後は高品質 ・多様なデータの拡充が不可欠

30. プログラム実装における生成 AI活用の未来像
30
自動化 ナレッジ
コード ドキュメント
生成AI 人間
品質責任 創造性
独自性
手足のように使いこなす力
支援・補助
人間は創造性や設計力を磨き、AIが真似できない付加価値を提供
人間と生成AIが協働する未来に向かった進化が鍵

31. 生成AIによる
プログラムのテスト
徳本 晋（富士通株式会社 富士通研究所）
31

32. テストにおける生成 AI活用
32
テスト計画
テスト設計・
レビュー
テストケース
準備
テスト実行
テスト
工程
テスト報告書
作成
バグ修正・
回帰テスト
どのフェーズに 関する論文が多いか？

33. テストにおける生成 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.
テスト
工程

34. テストにおける 生成AI活用
34
テスト計画
テスト設計・
レビュー
テストケース
準備
テスト実行
テスト報告書
作成
バグ修正・
回帰テスト
ユニットテス
トコード 生成
テスト仕様書
生成
テストデータ
生成
ファジング
GUIテスト
APIテスト
静的解析 デバッグ
生成AIが
適用可能 な
タスク・技術
テストケース準備を中心に紹介
テスト
工程

35. テストにおける生成 AI活用の基本
•テストケース準備の主な入出力
35
要求定義
／設計文書
プロダクション
コード
生成AI
テストケース
（テスト仕様書、
テストコード）
テストデータ
入力 出力
AIの扱いやす
いMarkdown
などへ変換
ドキュメント
作成も可能
前工程の成果物を入力し、段階的に
テストケース・データに落とし込む

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. Baudryet al., "Generative AI to Generate Test Data Generators," inIEEE Software, vol. 41, no. 6, pp. 55-64, Nov.-Dec. 2024

43. テストにおける 生成AI活用の研究動向 2：ファジング
•生成AI利用のポイント
•研究事例
•ChatAFL[Meng+24]：機械可読ではないプロトコル仕様からテストシナリ
オ・データを構築。 従来手法に比べ約 5 ～ 6% 高い分岐網羅率 を達成
し、新規脆弱性を実プロトコルから発見 。
43
シード選択
対象
プログラム
シード集合
モニタリング
テスト実行
エラーが 発生
したか？
エラー情報
を出力YesNo
エラー情報
カバレッジが
増加したか？
新規シード
追加
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. 生成AIに基づくソフトウェア開発
のプロセスとマネジメント
竹之内 啓太（NTTデータグループ）
45

46. プロジェクトマネージャーのミッション
ソフトウェア開発プロジェクトの成功には人・技術・プロセスの観点が重要。
ツールの導入だけでなく、それを支える人やプロセスを設計・管理。
46
適切な技術（ツール・環境）が
提供されている
適切な開発プロセスが
定義されている
People
TechnologyProcess
開発者が技術やプロセス
に習熟している

47. 生成 AI 導入で期待できる効果
47
時間軸
人
手
Developer Experience
（開発者体験）
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 Three Cycle 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íciaSantos. “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のどちらに寄り添うのか？