ソフトウェア品質特性、意識してますか？AIの真の力を引き出す活用事例 / ai-and-software-quality

こちらのイベントの登壇資料です。
AI コーディングエージェント with AWS　〜「自律的にコードを書くAI」の AWS での始め方徹底ガイド〜
https://pages.awscloud.com/eib-aiml-250522-reg.html

負債分析プロンプト「バグサーチャー」の元ネタはこちらのゲームです。
無料なので遊んでみてね。
『バグハンター2 REBOOT』
https://www.freem.ne.jp/win/game/30836

Transcript

1. © DMM © DMM ソフトウェア品質特性 意識してますか？ AIの真の力を引き出す活用事例 2025/05/22(木) AI コーディングエージェント with AWS 〜「自律的にコードを書くAI」の AWS での始め方徹底ガイド〜 合同会社DMM.com ミノ駆動
2. © DMM 自己紹介 ミノ駆動 ( @MinoDriven ) 合同会社DMM.com プラットフォーム開発本部 第3開発部 DeveloperProductivityGroup DMMプラットフォームの設計を改善し 開発生産性向上を図るのがミッション 2
3. © DMM 著書紹介 『改訂新版 良いコード／悪いコードで学ぶ設計入門』 変更容易性の高い設計を学ぶ、 初級〜中級向け入門書 初版は12刷重版 ITエンジニア本大賞2023技術書部門大賞受賞 台湾版、韓国語版でも翻訳出版 3
4. © DMM 【このセッションの理解目標】 ソフトウェア開発において生成AIの力を引き出すには ソフトウェア品質特性に基づいて指示する必要がある
5. © DMM このようなお悩みを抱えていませんか • AIにソースコードの改善を依頼したが、 「なんか惜しい」回答ばかり • AIがそれっぽいコードを出てくるけど、 こちらが意図した通りのコードではない • 使いこなせている気はするが、 肝心なときにAIが「ズレた」提案をしてくる 5
6. © DMM なぜこうなってしまうのか… 状況を整理しましょう
7. © DMM 我々がやろうとしているのは 生成AIと協働してソフトウェア開発することです
8. © DMM したがってAIと協働するには そもそも「ソフトウェア開発とは」 に立ち返る必要があります
9. © DMM ソフトウェアは、 ただなんとなく開発するものですか？
10. © DMM 違いますよね？ 必ず何らかの要件を定義するはずです
11. © DMM 要件定義では 機能要件と非機能要件がありますよね 要件を定義する以上 要件が適正であるか評価する必要があります それらの評価基準を何と呼ぶか 知っていますか？
12. © DMM それこそが ソフトウェア品質特性 本テーマの最重要概念です
13. © DMM ソフトウェア品質特性とは ソフトウェア品質の評価基準です。 13 品質特性 説明 品質副特性 機能適合性 機能がニーズを満たす度合い 機能完全性、機能正確性、機能適切性 性能効率性 リソース効率や性能の度合い 時間効率性、資源効率性、容量満足性 互換性 他のシステムと情報共有、 交換できる度合い 共存性、相互運用性 使用性 利用者がシステムを満足に利用できる度合い 適切度認識性、習得性、運用操作性、ユーザーエラー防止性、ユー ザーインターフェイス快美性、アクセシビリティ 信頼性 必要なときに機能実行できる度合い 成熟性、可用性、障害許容性、回復性 セキュリティ 不正利用から保護する度合い 機密性、インテグリティ、否認防止性、責任追跡性、真正性 保守性 システムを修正する有効性や効率の度合い モジュール性、再利用性、解析性、修正性、試験性 移植性 他の実行環境に移植できる度合い 適応性、設置性、置換性
14. © DMM 開発プロセスと品質特性の関係性 各開発プロセスは、なんらかの品質特性に寄与します。 例えば以下です。 14 開発プロセス 寄与する品質特性 要求定義 機能適合性など デザインシステムの策定 使用性、再利用性 クエリパフォーマンス改善 性能効率性 リファクタリング 保守性 ロギング実装、モニタリング環境整備 解析性
15. © DMM つまりソフトウェア開発とは 「ソフトウェア品質特性の作り込み、及び向上」 であることに他なりません 間接、直接問わず 必ず何らかの品質特性に寄与することになります
16. © DMM さてここで生成AIとの関わり
17. © DMM 「良いコードとは何か」問題 極端な話、「良いコードを実装して」と生成AIに雑に指示して、 良いコードを実装してくれるでしょうか？ そもそも「良いコード」とは何でしょうか。 性能効率性に優れたコード、保守性に優れたコード、 セキュリティに優れたコード……さまざまです。 何を良くするのか指示が不明確では、 当然生成AIに意図したコードを実装してもらえません。 雑に指示するとパフォーマンスが悪化するコードに書き換えられたり 意図とは異なる変数名に変えられたりすることが実際に起こります。 17
18. © DMM つまり ソフトウェア開発において生成AIの力を引き出すには ソフトウェア品質特性に基づいて指示する必要がある ということです コード実装だけでなく 他全ての開発プロセスでも同じことが言えます
19. © DMM ソフトウェア品質特性に基づいた 2つの活用事例紹介
20. © DMM 事例１ ： 変更容易性（修正性） 生成AIによる技術的負債分析
21. © DMM 変更容易性 変更容易性とは、なるべくバグを埋め込まず、 どれだけ素早く正確にコード変更できるかを示す度合いです。 技術的負債とは、安易な方法を選択したことによる、 将来の追加作業コストの総称です。 複雑で混乱した、変更容易性の低いコードは技術的負債の一種です。 変更容易性の高い理想構造と現状構造とのギャップが負債といえます。 そのため、負債かどうかを判断するには変更容易性の知識が必要です。 21
22. © DMM 負債分析プロンプト「バグサーチャー」 静的解析ツールでは分析困難な技術的負債を高精度で分析する、 AIエージェント用のプロンプト群。 変更容易性に関するさまざまな観点をプロンプトとして実装。 私の思考を模倣するようなプロンプトとなっています。 現状は Cursor + bedrock:claude-3.7-sonnet で動作。 今後どのAIエージェントでも汎用的に使えることを目指しています。 （将来的にはMCPサーバー化する予定） 22
23. © DMM 23 競争力に影響するのでプロンプトは企業秘密です。 ですが参考情報として、このあたりの書籍の知見が ベースになっています。
24. © DMM 24 分析結果（一部抜粋）
25. © DMM 25 静的解析ツールとの負債分析観点比較 静的解析ツールは「コードの意図」がわかりません。 一方、生成AIは意図を推論できます。 生成AIだからこそ可能な負債分析です。 一般的な静的解析ツールの分析観点 コード行数 サイクロマチック複雑度 コード重複 引数の数 etc.. バグサーチャーの分析観点 カプセル化 ドメインロジックの関心の分離 ドメインモデル完全性 技術レイヤ間の関心の分離 各設計パターン毎の設計要件 interface設計 etc..
26. © DMM スケールする負債分析の質と量 例えば約400行ほどのソースコードの負債を洗いざらい分析する場合 • ミノ駆動の目視 : 約15〜30分（ドメイン知識に依存） • バグサーチャー : 約1分 私は変更容易性やリファクタリングを専門としていますが、 私とほぼ同等の精度で、かつ10倍以上の生産性で分析できています。 しかも誰でもバグサーチャーを使えるので、 お手軽に「ミノ駆動の分身」を増やせる体制に。 変更容易性の専門知識のおかげで実現できたと言えます。 26
27. © DMM ちなみに… 「バグサーチャー」は、私が制作したゲーム『バグハンター2 REBOOT』に 登場するアイテム名が由来です。 バグや負債を探知し、可視化するデバイスです。 27 https://www.freem.ne.jp/win/game/30836
28. © DMM 事例２ ： 機能適合性 生成AIによる高品質なテストコード実装
29. © DMM 機能適合性 機能適合性とは、機能がニーズを満たす度合いです。 コードの誤りにより機能しなくなること、 つまり機能適合性の欠陥がバグです。 モジュール単位での欠陥を防ぐ手段のひとつがテストコードです。 29
30. © DMM 生成AIによるテストコード実装 生成AIはテストコードの実装が得意です。 実際「テストコードを実装して」と雑に指示しても、 それなりのテストコードを実装します。 ただし、たびたび以下のようなケースが発生します。 • テストケースの抜け漏れ • 複数の要件を検証するテストケースの実装 （このようなテストは仕様変更に脆く、テストが壊れやすい） 30
31. © DMM 契約による設計 契約による設計とは、正確性（＝機能適合性）の向上を目的に バートランド・メイヤー氏が考案した設計の方法論。 以下の3条件から構成されます。 • 事前条件：メソッド開始時に保証されるべき条件 • 事後条件：メソッド終了時に保証されるべき条件 • 不変条件：常に維持されるべき条件 モジュールの機能適合性を保証するテストはこの3条件の検証が基本。 つまり生成AIに高品質なテストコードを実装させるには、 契約による設計を踏まえる必要があります。 31
32. © DMM 契約による設計に基づくプロンプト実装 32 # 役割 あなたは以下の専門家として振る舞うこと - テストコード - 契約による設計（事前条件、事後条件、不変条件） # 目的 テストコード実装 # 制約 メソッドの事前条件、事後条件、不変条件を検証するテストであること # テスト対象 （ここにテスト対象のメソッドを指定する）
33. © DMM 動作結果の一例 33 Cursor + bedrock:claude-3.7-sonnet 『改訂新版　良いコード／悪いコードで学ぶ設計入門』記載のコードに対し実施
34. © DMM スケールするテストコード実装の質と量 約100行のコードにテストを書く場合、分析も含めて • ミノ駆動の実装 : 20-60分??（ドメイン知識に依存） • 前述のプロンプト: 1分以内 数十倍のオーダーで高速化！ 抜け漏れもなく、テストと検証対象が1:1になっているので、 テストコードの品質も良好。 34
35. © DMM ソフトウェア品質特性に基づいて指示しよう 以上、紹介した2例にあるように、 ソフトウェア品質特性と各特性に深く関係する技術に基づいて 指示することで、生成AIの正確性が向上します。 AI協働でのソフトウェア開発において、品質特性の把握は必須です。 みなさんも普段関与している品質特性をぜひ把握しましょう。 35
36. © DMM 関与する品質特性を生成AIに聞いてみよう 自分の仕事が何の品質特性に関係しているか分からなければ、 以下のプロンプトで生成AIに聞いてみると良いでしょう。 36 # 役割 あなたは以下の専門家として振る舞うこと - ISO/IEC 25010のプロダクト品質モデル - ソフトウェア開発 # 目的 以下について知りたい - 私の業務がどのソフトウェア品質特性に寄与するか - 該当する品質特性を高めるために深く知るべき技術 # 私の業務 (ここに業務内容を列挙する)
37. © DMM ご清聴ありがとうございました