【実務で使う生成AI】要件定義からテストまでの活用可能性と課題【SIerに贈る】
【実務で使う生成AI】要件定義からテストまでの活用可能性と課題
0. はじめに
今回の記事では受託開発系システム開発の現場で生成AI(主にChatGPT)を活用する際に、どのように使えるか、どのような課題があるのかを実際に検証した結果をまとめてみました。
私自身はウォーターフォール型でドキュメントを作りながら進める案件が多いため、それを想定した内容になっています。
コーディング関連は既に沢山情報があるので、それ以外を主に検証しました。
結構長い記事なので、要約だけでも読んでいただけると幸いです。
XでもAI情報を発信しています。
よかったらフォローお願いいたします⭐️
1. 要約(by ChatGPT o1)
- 小規模案件なら要件定義からワイヤーフレーム・モック作成、コーディングやテストケース作成まで、生成AIで短時間に“たたき台”を作れそう。
- 大規模案件では、まだまだAIに任せるのは難しく、議事録整理や要件書初稿の作成、画面設計の抜け漏れチェックなど、部分的活用が現実的。
- ワイヤーフレーム作成では、Galileo AIやv0などで即時に画面を生成したり、Figma等に書き出すことで作業を効率化できる部分あり。
- 画面設計書やテストケースの“面倒な書き写し部分”や“基本的なバリデーション記載”などはAIに任せると作業負担を減らせるが、最終的には業務知識のある人間のチェックが必要。
- ハルシネーションなどのリスクがあるため、AIが作った成果物のチェックは不可欠。
加筆修正はしましたが、自分で要約書くのよりは圧倒的に効率化できますね。
2. 要件定義フェーズでの活用
2.1 小さい個人開発レベルの場合
-
小規模の個人開発サービスならChatGPTにやりたいことを渡しただけで、ある程度使えるものを作ってもらえました。
それをベースにすることで短時間で要件をまとめることが可能でした。 - 結構色々ChatGPTが色々考えてくれたので、思考の負荷も減らせました。
- しかし、規模が大きくなってくると、工夫が必要になってきます。
- チャットが長くなりすぎると前提条件を忘れられたりするので、適宜まとめて新しいチャットで始め直す
- 全部一気に要件を整理するのではなく、機能毎に分ける、など
といっても、私は要件定義を仕事でやっているので、導かれ方が分かったり、ゴール(目的とする成果物)が何かも分かっているという状況でした。
業界・業務経験がなかったり、生成AIを使ったことがない人が利用するとなると、手間が増えるかもしれません。
しかし、そういう人こそ生成AIを使って何を考えるべきか等を導いてもらうことで、より上のレベルの要件が作り上げられると思います。
メリット・デメリット(小規模案件向け)
項目 | メリット | デメリット |
---|---|---|
スピード | - ChatGPTなどの生成AIを使うことで、短時間でたたき台を作れる - 初動が早く、アイデア出しを効率化できる |
- 大量の情報を一度に渡すと文脈が混乱しがち - プロンプト設計を知らないと、曖昧な要件や抜け漏れが発生する |
完成度 | - AIが一般的な要件や機能パターンを補完してくれるため、初心者でもある程度の精度を確保できる | - 業務特有のロジック・ドメイン知識は人間が補う必要がある - 出力をそのまま鵜呑みにすると現場と乖離が生じるリスク |
柔軟性 | - 思いついたアイデアを即座に反映しながら要件を深掘りできる | - チャット履歴が肥大化すると情報整理が難しくなり、矛盾の発生率が上がる |
2.2 業務レベルの案件
言うまでもないですが、クライアントがいる案件や複雑な要件になるほど、AIの出番は減ります。
他者間の調整や、本当に必要なことの聞き出し等は生成AIの手に負えるものではないです。
そのため、生成AIは部分的に使う形になるでしょう。
具体例として、以下のように使えそうです。
- 会議内容の文字起こしを要約して議事録を作成
- 議事録から、今回のMTGでまとまった要件を書き上げる
- 要件策定の叩き台作成や整理
- 相談(策定中の要件を渡して「もっと考えるべき点は?」など、指摘をもらう)
- ヒアリングした情報をChatGPT o1などに整理し提案を作成してもらい、提案スライドを生成する(Gamma AIなど)
- 知らない業界の知識を教えてもらう
- 必要になる情報を効率的に集める(ChatGPTのserchGPTやFelo.ai, Perplexityなど)
2.3 新しい価値
生成AIの良いところとして、数秒で生成物を作れるところがあります。
ワイヤーフレームやモックを即時生成することで、以下のようなことができそうで期待しています。
- 画面イメージ(主にワイヤーフレーム)をMTGの場ですぐに生成して議論の参考にできる
- 手書きでもできますが、整ったUIでの画面を見せることで、クライアントがよりイメージしやすくなり、それを元に議論がより進む
- ある程度動くモックをMTGの場ですぐに生成する
- 簡単な動き・機能のあるモックを生成することで、クライアントが完成物をよりイメージしやすくなる
MTG中に画面内容を手で書くのは現実的ではないと思うので、
音声文字起こしツールやChatGPTの音声機能等で画面についての情報を渡し、ワイヤー要素を文字化してもらい
- Galileo AIに渡して画面を生成する
- v0にある程度動くモックを生成してもらう
などで実現できそうです。慣れは要りそうですが・・・
(これの検証に付き合ってくれるお客さんいないかなぁ)
要件定義全体においてこれが占める割合はかなり小さいですが、
「あの会社はいつもすぐにイメージできる資料を出してくれるから、話が早く進むし社内調整用の資料としても助かる」のように、クライアントから見て1つの差別化要素になったらいいなと思っています。
後述の Galileo AI ならこのレベルが一瞬で生成されます。
プロンプトは「a profile setting page」で生成しました
メリット・デメリット(業務レベル)
項目 | メリット | デメリット |
---|---|---|
要件整理 | 大量の要件や議事録情報から要点を抜き出して要約してくれる | プロジェクトが複雑になるほど、最後の整合・落とし込みは結局人間の作業が増える |
新しい価値 | ワイヤーフレームやモックをMTGの場で即時生成して提案力UP | 大規模・複雑要件だと、提示されたWFやモックが実際の要件と乖離していることに気づきにくい場合がある |
2.4 クライアント側でも使えるか?
2.1で軽く触れたように、初心者こそ生成AIを使う効果が高そうです。
一般的にベンダーに依頼する時は、「要求仕様書」を用意するでしょう。
「要求仕様書」の作り方が分からなければ
- どうやって要求仕様書を作ったら良いか、ChatGPTに教えてもらう
- 要求仕様書作成のテンプレを示してもらう
- 必要な質問を段階的に提示してもらう
といった使い方が考えられます。
作り方を知っている場合でも、以下のような使い所はありそうです。
- ブラッシュアップに使う
- べンダーに聞いておいた方が良い点・注意してもらいたい点などを教えてもらう
- ベンターが欲しいと思う内容は?と聞いて、その辺りを厚くする
3. ワイヤーフレームの作成
要件定義で画面一覧や画面項目まで定義できれば、ある程度までならAIでの生成が可能です。
WFの作成にあまりこだわりがなければ、結構AIを使えそうな気がします。
検証には小規模個人開発サービスを考えた時の画面一覧や画面項目を使ってみました。
結果、以下のことはできました。
- v0は、数画面程度なら簡単に機能付きのモックが作れます。
- Galileo AIは本格的なWF生成が可能で、Figmaへの書き出しもできます。
- 業務で実際に使うなら、Galileo AIでWFを生成 → Figmaへ書き出し → 微調整 という流れになりそうです。
- Galileo AIでは画面数が多くても、複数回に分けて生成すれば全画面分のWFが用意できます。
- 凝ったデザインが不要であれば、生成されたWFをそのままコーディングで使えるレベルだと思います。
↓Galileo AIはこのような感じで生成してくれます。
一方、まだ厳しそうなこと
- 普遍的なUIは生成AIの得意とするところだと思われますが、普遍的ではないようなWFを生成するのは難しいかもしれません。
- 一般的な管理画面の「一覧・登録/編集・詳細」レベルは生成できますが、ユーザー側の複数要素が混ざり合った画面などは厳しそうです。
- 複数の画面を複数回に分けて出力した場合、デザインの統一性がなくなる可能性がありそうです。
- 使用するツール次第
- 実務レベルのWFで全てを100点のクオリティで出すことは厳しいので、Figmaへ書き出して調整はすることになりそうです。
- 当然、Figmaでプレビューした際のボタンをクリックしたら画面遷移するなどの動きは人力で設定する必要があります。
メリット・デメリット
項目 | メリット | デメリット |
---|---|---|
作成スピード | - テキストベースの指示で、ワイヤーフレームを即時に生成できる - v0などは簡単な機能付きモックも短時間で作れる |
- プロンプトの質が低いと意図しない要素になる可能性がある - 1度に生成できる画面数には限界がある |
見た目のクオリティ | - 一般的なUI/UXパターンに沿った整ったWFが得やすい - Galileo AI等ではFigma書き出しできるので、後から調整可能 |
- 独自デザインや特殊な画面レイアウトは生成が難しく、結局人力調整が必要 - 出力差でデザイン統一を取りづらい場合がある |
実際の業務との親和性 | - ある程度の機能要件やプロトタイピングを同時に進められる - Figmaエクスポート→微調整のフローで実装初期にも活用可能 |
- 大量の画面や複雑要件では指示や微修正に工数がかかる - Figmaプレビューのクリック連動や画面遷移などの動きが欲しい場合は手作業で付与する必要がある |
4. 画面設計
4.1 前提
- Markdown形式で画面設計書を作成し、検証しました。後工程でAIに読ませたい意図があるためです。
- 私はWFがある状態から画面設計書を書くことが多いので、WFをAIに読み込ませてそこから画面設計書を作っていきました。
画面項目書があれば、それでも同じことができると思います。
4.2 検証結果
- ある程度は書いてくれました。生成されたものに追加指示を与えていく・加筆していくという流れで使えそうです。
- ワイヤーフレームだけを渡すと、さすがに生成される画面設計書のフォーマットがかなりブレたので完成系のサンプルを必ずAIに与えた方が良かったです。
- 処理の記載では、バリデーションチェックやエラーメッセージなど、サンプルや「このプロジェクトのルール例」を示すことで安定して求めるものを書いてくれました。
- 各フィールド定義でも、必須,制限文字数など、何を記載しなければいけないかもサンプルを示すことで安定しました。
4.3 シンプルな画面 vs 複雑な画面
- シンプルな画面だと90点くらいの内容が一発で生成されることもありました。
- しかし、多画面連携や複雑な処理がある場合、AI側も把握しきれず、結局は人間が細部を指定してあげる必要があります。
4.4 レビュー用途として生成AIは使えそう
- 自分で書いた設計書をAIに読ませて、抜け漏れや考慮不足を洗い出してもらうのも有効でした。
- 一般的な観点(ログインIDはユニークチェックが必要など)なら十分に指摘してくれます。
- 一方で、より深い業務ロジックの確認は、既存の資料や独自のレビュー観点をAIに与えないと難しいです。
- 逆にAIにそれらの情報を上手いこと与えればやってくれます。
- 誤字脱字レベルなら当然修正してくれます。
- 工夫すれば、同一機能の設計書をまとめて与えて相互に矛盾がないかのチェックもできるかもしれません。要検証。
4.5 簡単だが面倒なことをやってもらう
- 私の業務ではWFや別紙にある画面要素を画面設計書に書き写して、そこに詳しいフィールド仕様を書いていくのようなケースがあるのですが、その面倒な書写し作業はやってくれました。
- 見れば分かるようなバリデーションチェック条件・エラーメッセージなど、書くのも面倒なものも書いてくれます。
- 当然、自分での修正も必要ですが、最初から自分で書くよりは楽ができました。
メリット・デメリット(画面設計)
項目 | メリット | デメリット |
---|---|---|
初稿作成 | バリデーションチェックやエラーメッセージなどの「めんどくさい部分」を一気に生成してくれる | 大規模案件は結局多くの指示出しが必要 |
レビュー | 抜け漏れや考慮不足のヒントを得やすい | 業務特有のロジックはAIの一般知識だけでは網羅しきれず、人間レビューが必須 |
書式・粒度の統一 | 事前にサンプルのフォーマットを与えることで仕様書の体裁を一貫させられる | サンプルそのもののメンテナンスも必要 |
5. 内部設計~実装フェーズ
設計書をmarkdownで書くのは、AIが理解しやすい形で情報を与えて、より精度高くコーディングしてもらうことが目的でした。
設計書に書く粒度が細かければ細かいほど、精度高くAIがコーディングしてくれることを期待しています。
まだ本格的には検証できていませんが、以前の個人開発で試してみた経験もふまえてできそうなことを記載します。
小さいシンプルな案件ならという条件がつきますが、叩き台として以下のようものは作れそうです。
当然人の手で調整が必要です。
5.1 DB設計・API仕様書
- 画面設計書をAIに読ませると、各画面で必要なテーブルやカラムをある程度洗い出してもらえました。
- API設計も同様に、画面ごとにどんなAPIが必要か整理する叩き台を作ることが可能でしょう。
- 複数画面の設計書からAPI一覧を作成し、各APIを使う予定の画面設計書から、API仕様も書けそうです。
- そのAPI仕様書+画面設計書を使ってAPI自体もある程度作れそうです。
- 実際、以前個人開発で、DB定義書や簡易な仕様書をAIに渡して、Laravel の Migration, Model, Controller のベースを作ってもらいました。
- 自分で0から書くよりは楽ができました。
5.2 フロント側のモック
-
v0を使えば機能付きモックが生成可能です。Reactベースで出力できます。
- v0を本格的に使う場合、APIのつなぎ込みも生成したAPI仕様書をAIに渡せばある程度できそうです。
- デザイン不要なら、v0のコードをほぼ本番用に使えるかもしれません。
- v0はReactベースなので、Reactできないと調整が難しいかもしれません。
- Galileo AIは HTML + Tailwind CSS で出力可能なため、他フレームワークに組み込むなどが比較的実施しやすそうです。
- 少ない画面数でしかやったことがないので、沢山画面を作ったらデザイン感が統一されないかもしれないです。
5.3 AIエージェント使えば設計書からコーディングできない?
もし可能であるならば、設計書を全部丸ごと渡したら全部自動でコーディングしてもらいたいところです。
しかし、さすがにまだ早いですね。
2画面くらいの簡単なToDo Listなら、Clineで画面設計書(o1に生成してもらいました)から自動で生成できました。
そもそも誰も業務レベルの規模でClineが完全に自動でコーディングしてくれるとは思っていないと思いますが、画面数が増えたり複雑さが増せば増すほど、自力での修正箇所が増えると思います。
私はClineに少ししか触れていませんが、実際に業務で使うならば小さい機能単位でClineにコーディングしてもらうとか、そのような使い方になるのでしょうか?
検証していければと思います。
DevinならClineよりももっと上手にできるのですかね?
500ドル/月 は高いので検証すらできないです😭
メリット・デメリット(実装フェーズ)
項目 | メリット | デメリット |
---|---|---|
DB/API設計 | 仕様書からAPI一覧やテーブル定義を自動で洗い出せる | マルチテナントや複雑な依存関係がある場合は結局人力で調整が必要 |
コーディング | 簡単な個人開発レベルならコントローラーやMigrationのベース生成してくれ、0から書くよりは楽ができる | 大きな案件ほどリファクタリング箇所や共通化などの方針が必要となり、コードを生成するにしても指示方針等に工夫が必要になってくる |
フロントモック作成 | - v0でReactベースの機能付きモックを生成可能 - Galileo AIでHTML + Tailwind CSSのコードが生成可能 |
- モックの品質がツール依存であり、ReactやTailwind CSSのスキルがないと調整が困難 - 大規模な画面数ではデザイン統一性の課題が生じる |
6. 単体テスト・結合テスト
さすがにまだテストケースの生成を任せきるのは厳しかったです。
6.1 単体テストケースの作成
- 画面設計書をAIに渡し、「この画面の単体テストを作って」と依頼するとそれなりにテストケースを生成してくれました。
- ただし、それだけだと設計書と同様に粒度やフォーマットが毎回不安定です。
- そのため、サンプル(既存のテストケース例)やルールを与えてから依頼すると良いです。
画面設計書と同じですね。 - 設計書と同じように、抜け漏れチェック等のレビューに使えそうです。
- 見て分かるようなテストケースを作ってくれるだけでも、自分で書く煩わしさから多少解放してくれます。
- 今回は検証できませんでしたが、設計書に加えて大量のサンプルや注意点、技法(境界値分析など)の情報を厚く与えていったら実用レベルに近づくかもしれないです。時間がある時に試してみたいです。
6.2 結合テストケースの作成
おおよそ単体テストと同じですが、結合テストともなると複数画面を跨ることになります。
そうすると、各画面で何をやるかのようなことを指示するのが大変になります。
ちょっと検証してあまり手応えを得られなかったので、また今度検証しようと思います。
6.3 テストの実行
- 現時点では「自動でテスト実行までさせる」のはハードルが高いと思われます。
- 最近話題のbrowser-useで、テストケース渡したら実行してくれないかな〜と期待しています。
自然言語でテストケースが書けるT-DASHは相性が良いかもしれません。
テストケースをT-DASHのフォーマットで生成してT-DASHに流し込めば、できるかもしれません。(別途画面要素とテストケースの紐付けが必要)
ただ、2021年頃にReactのプロジェクトでT-DASHを導入しようとして断念したことがあるので、フレームワークに合う合わないがありそうです。
メリット・デメリット(テストフェーズ)
項目 | メリット | デメリット |
---|---|---|
単体テストケース | シンプルな案件ならAI生成の叩き台でも役立ち、抜け漏れチェックにも使える可能性がある | テスト観点や業務フローをしっかり教えないと“ただの形式的テスト”になる |
7. 今回使用したAIモデル・ツールについて
- 今回はChatGPTで実施しました。
- o1と4oでいくつか試しましたが、結論、o1の圧勝でした。
そりゃそうですよね…深く考えてくれるので。
画面設計の際には、バリデーションチェックやフィールド仕様など、o1の方が細かく考えてくれました。
o1 Proならもっとすごいかもですが、200ドル/月は財布に厳しいです😭
余談ですが、ChatGPTには情報を学習されないモードがあるので、社外秘情報を扱う場合は必ず学習されないように設定しておきましょう。
学習されるモードがONだと、あなたの入力した情報はChatGPTに学習されます。
8. 総括と今後の展望
8.1 明日から使えそうなところ
-
作成したドキュメントのレビュー
- 誤字脱字、一般的なチェック漏れなどの指摘はすぐに得られる。
- その他にも(採用するかはさておき)検討しておいた方が良さそうなこと、もっと詳しく書くべきことをアドバイスしてもらえる。
-
検索AIによるリサーチ
- 調べごとは、SearchGPT/Felo.ai/Perplexityなどで効率的に収集。
-
WF作成への活用
- Galileo AIやvoを使用。
- 最終的に自分でWFを書くにしても、ベースを作ってもらえると楽になる。
8.2 検証での学び
-
小さい案件ならかなり使えそうだと感じました。
次に10〜20画面程度の比較的小〜中規模案件が来れば、上記検証内容をさらにブラッシュアップして効率化・高品質化を狙えると思います。 - 一方で、大きい案件ではまだまだ生成AIに振り切るのは難しいため、完成したドキュメントをレビューさせるなどの部分的活用が現実的でしょう。
また、**「何をどうAIに情報を与えるか」**は、やはり重要な要素でした。
- 詳細に与える情報は当然重要。細かく情報を与えれば精度は上がる。(しかし、細かく考えるならAIいらないジレンマ)
- 指示の仕方も出力結果を左右する。
- サンプルを与えるのも大事。
8.3 今後の展望
生成AIを利用した品質のボトムアップ・均質化の仕組み化への試み
生成AIの強みの一つは、経験が浅い人でも一定レベル以上の成果物を作れるようになることだと考えています。
- 画像生成がわかりやすい例で、絵描きの経験がない人でもそれっぽいイラストを簡単に生成できます。
- 同じように、システム開発に不慣れな新人でも、生成AIが基本の考慮点などを半ば自動で盛り込んだドキュメントを作成してくれる、などをしていけば誰でも一定水準レベル以上の仕事ができる可能性があると信じています。
暗黙知の明文化
- 上級者が「当たり前」として明文化しないようなことも、AIに指示を与えていれば毎回きちんと書いてくれます。
- 例:登録ボタン連打による重複登録を防ぐべき等
- こうした暗黙知を明文化して貯めるだけだと、
- 大量にあって頭に入らない
- 案件によって使える・使えないものがある
のようなことがありますが、大量に貯めて生成AIに使用できるものを判断してもらうということができる可能性がありそうです。
- このようなプロセスを通じて成果物の底上げができると期待しています。
このように、既存の業務の効率化以外にも、スキルを底上げする仕組みを構築していけたら良いなと考えています。
ハルシネーション問題
- 当然AIの出力が正しいかどうかのチェックは必須です。
- ハルシネーションは現段階の生成AIにおいて宿命なので、上級者の最終レビューは欠かせないと思います。
9. まとめ
-
小規模案件なら、要件定義からモック、実装の叩き台、テストケースまで
楽ができる効率化できる可能性がある。 - 大規模案件でも、部分的に生成AIを活用できるところはある。
- 生成AIに成果物を作ってもらいたいなら、サンプルや指示が大切。
- 完成形のサンプルを提示すると、生成物の質や粒度が安定しました。
-
ワイヤーフレームやモック作成は生成AIが活用できそう。
- Galileo AIやv0を使えば、即時にWFや簡易モックを作成できます。
- 生成物が丸々使えるわけではないですが、効率化できそうです。
-
今後の展望
- 生成AIを活用していくことで、経験が浅くても一定水準の成果物を作れる可能性があります。
- それを実現するための仕組み作りを頑張っていきたいです。
- 生成したとてハルシネーションや誤りのチェックは必要で、経験者の最終レビューは欠かせないでしょう。
- 生成AIを活用していくことで、経験が浅くても一定水準の成果物を作れる可能性があります。
おわりに
長文となりましたが、実務での生成AI活用についての現状検証を共有しました。
「新しい技術を実際に業務へ活かすには?」という視点で書きましたので、同じ疑問をお持ちの方の参考になれば幸いです。
軽い気持ちで書き始めたら14,000文字超とかなり長編になってしまいました。
こんな書いたにも関わらず、まだ出してない個人開発のものや、社外秘のものを検証に使ってしまったので具体的にどんな生成物ができたのか書けなかったのが心残りです。
次書くなら生成物もある程度載せたいところです。
もっとも、この記事を書くの大変だったので、続編を書くのは需要(いいね)があったらにしようと思います。。。
XでもAI情報を発信しています。
よかったらフォローお願いいたします⭐️
Xはこちら
最後まで読んでいただき、ありがとうございました!
Discussion