生成AIで業務アプリをどこまで作れるのか｜全3回シリーズ 第2回

このウェビナーで得られること

生成AIをシステム開発に使ってみたいものの、「どこまでAIに任せてよいのか」「要件定義や設計まで本当に使えるのか」と迷っている方も多いのではないでしょうか。

本ウェビナーでは、実際に生成AIと一緒に業務アプリの企画・要件定義・設計を進めた経験をもとに、AIが得意な作業と、人間が判断すべきポイントを具体的に整理します。

視聴することで、生成AIを単なるコード生成ツールとしてではなく、要件整理、論点展開、仕様の具体化、細部チェックを支援するツールとして活用する考え方が分かります。

また、AIとの会話をそのまま仕様にせず、要件定義書や決定事項一覧などの成果物にまとめてレビューすることで、認識ずれや下流工程での手戻りを減らすための実践的な進め方も理解できます。

生成AIによって「人が考えなくてよくなる」のではなく、人の役割を作業者から判断者・レビューアへ変えていく。 AI時代のシステム開発で、どこに人間の時間を使うべきかを考えるためのヒントを得られる内容です。

全3回シリーズ 第2回：生成AIと進めるシステム開発の上流工程

本記事は、「生成AIで業務アプリをどこまで作れるのか」全3回シリーズの第2回です。 第1回では、副資材・スペアパーツの補充依頼をQRコードから登録し、承認、発注、納品、完了まで管理する小規模な業務アプリを、生成AIを活用しながら実際に構築した結果をご紹介しました。

今回は、その開発プロセスの中でも、コードを書く前の「企画・要件定義・設計」という上流工程に焦点を当てます。 実際にChatGPTとどのようなやり取りをしながら仕様を具体化したのか、生成AIがどこで役に立ったのか、そして実際に使ったからこそ見えてきた注意点について整理します。

次回となる第3回では、ここまで整理した仕様を実際のコードへ落とし込み、実装・テストまで進めた際に何が起きたのかを取り上げます。

本記事は、「生成AIで業務アプリをどこまで作れるのか」全3回シリーズの第2回です。 第1回では、副資材・スペアパーツの補充依頼をQRコードから登録し、承認、発注、納品、完了まで管理する小規模な業務アプリを、生成AIを活用しながら実際に構築した結果をご紹介しました。

今回は、その開発プロセスの中でも、コードを書く前の「企画・要件定義・設計」という上流工程に焦点を当てます。 実際にChatGPTとどのようなやり取りをしながら仕様を具体化したのか、生成AIがどこで役に立ったのか、そして実際に使ったからこそ見えてきた注意点について整理します。

次回となる第3回では、ここまで整理した仕様を実際のコードへ落とし込み、実装・テストまで進めた際に何が起きたのかを取り上げます。

生成AIに「作りたいもの」を伝えれば、仕様書が自動で完成するのか

今回の開発は、生成AIに「こんなアプリを作りたい」と伝え、そのまま自動的に仕様書やアプリが完成したわけではありません。

最初に入力したのは、 「QRを使って、副資材やスペアパーツの補充依頼を簡単に登録できる仕組みを作りたい」 という大まかな構想でした。

するとChatGPTから、次のような質問が返ってきます。

• 誰がこのシステムを使うのか
• QRコードにはどの情報を持たせるのか
• 数量はユーザーが入力するのか
• 承認は必要なのか
• 同じ品目の重複依頼があった場合はどうするのか

人間が一つずつ回答すると、その回答を前提に次の確認事項が提示されます。 この「AIが質問する → 人間が判断する → 決定内容を文書化する」というサイクルを繰り返しながら、仕様を少しずつ具体化していきました。

今回の実証では、要件定義だけでも約80の確認事項を整理しました。 設計については第1章から第13章までテーマを分けて詳細化しています。 作業時間は、要件定義が約1.3時間、設計が約5.8時間でした。

一つの質問から、多くの仕様が派生する

生成AIとの要件定義で特徴的だったのは、一つの単純な質問から、多くの仕様が枝分かれしていったことです。

たとえば、 「同じ品目・同じ場所について、まだ完了していない補充依頼がある場合、新しい依頼を登録できるようにするか」 という質問があります。

選択肢としては、登録を禁止する、警告だけ表示する、そのまま許可するといった方法があります。 今回の実証では、 「警告は表示するが、本当に追加で必要な場合は理由を選択すれば登録できる」 という方針を選びました。

しかし、ここで仕様は終わりません。 この判断から、さらに次のような論点が派生します。

• 何をもって「重複」と判断するのか
• 品目だけで判定するのか、品目＋使用場所で判定するのか
• 完了済み・取消済み・否認済みの依頼は重複判定から除外するのか
• 追加依頼の理由は自由入力か、リスト選択か
• 誰が理由付きで追加依頼したのか履歴を残すのか
• この仕様をどのようなテストケースにするのか

最初は一つの業務判断だったものが、判定条件、例外処理、入力方法、履歴、画面表示、そしてテストケースへと広がっていきます。

今回の実証を通じて、システム仕様とは、こうした小さな意思決定の集合であることが改めて明確になりました。

生成AIはなぜ多くの論点を出せるのか

生成AIは、一つの論点を複数の判断軸に分解し、それまでに決まった内容に応じて次の論点を展開していくことを得意としています。

たとえば、一つの入力項目について考えるだけでも、 「必須か任意か」 「自由入力かリスト選択か」 「数値か文字か」 「入力エラーの場合はどうするか」 といった論点があります。

さらに「リスト選択」と決めれば、 「固定値のリストか、マスタ参照か」 「検索機能は必要か」 「無効になった選択肢をどう扱うか」 といった次の判断が必要になります。

つまり、生成AIはすべての組み合わせを最初から機械的に並べているというより、現在までに決まった仕様を条件として、次に考えるべき論点を順次広げていくように見えます。

生成AIは仕様を「下・横・上」に見る

今回の経験から、生成AIが仕様を確認する方向を、人間向けに「下・横・上」という3つに分けて整理しました。

下：一つの論点を詳細化する

生成AIが特に得意なのが、一つの論点を細かく分解することです。 入力条件、エラー処理、例外処理、履歴管理など、関連する細かな仕様を次々に展開できます。

横：類似する仕様を比較する

似た項目同士を比較し、 「こちらはリスト選択なのに、なぜこちらだけ自由入力なのか」 といった細かな整合性を確認することも比較的得意です。

上：全体方針との整合性を見る

個別仕様から一度離れて、 「そもそも、このシステムでは入力ミスを減らすことを優先していたのではないか」 と全体方針へ戻って確認することもできます。

ただし、この「上方向」の確認には注意が必要です。 長い会話の中で例外や変更が積み重なると、かなり前に決めた全体方針との正確な整合性を維持し続けることは難しくなる場合があります。

また、生成AIは論点を広げることには強い一方で、 「この規模のシステムなら、ここまで考えれば十分」 という止めどころの判断は、人間が行う必要があります。

「こんなアプリを作って」の一言ではダメなのか

生成AIであれば、「こんなアプリを作ってください」と一度伝えるだけで、それらしいアプリを生成させること自体は可能です。

しかし、その場合、こちらが指定していない部分についてAIが多くの判断を行うことになります。

• どの項目を必須にするのか
• どのような承認方法にするのか
• 入力エラーをどのように処理するのか
• 誰にどの権限を与えるのか
• 例外や重複が発生した場合にどうするのか

AIが補完した内容が、自社の実際の業務に合っている保証はありません。

ワンショットで生成する方法は速い一方で、未指定部分の意思決定をAIへ委ねる割合が高くなります。

一方、対話型で仕様を作る場合は、AIに論点を提示してもらい、人間が一つずつ判断します。 時間は少しかかりますが、自社業務にフィットしやすくなり、下流工程での手戻りも減らしやすくなります。

AIが便利になるほど、人間にも新しい問題が起きる

生成AIを使った上流工程は非常に効率的でしたが、人間側にも新しい課題が見えてきました。

一つは、集中力の問題です。 AIから次々と質問が提示されるため、最初は丁寧に考えていても、長時間続けると十分に吟味せず「それでいいです」と回答してしまう可能性があります。

また、AIが整理した内容を読んで、実際には十分理解していないにもかかわらず「分かったつもり」になってしまうこともあります。

生成AIは会話を前に進める能力が高いからこそ、間違った前提でも効率よく先へ進んでしまう可能性があります。

さらに、AIが質問・整理・文書化まで行ってくれることで、従来よりも詳細仕様が人間の頭に残りにくくなるという問題もあります。

「AIは仕様を理解しているが、人間自身は細部を十分理解していない」という状態にならないよう、成果物を定期的にレビューすることが重要です。

人間と生成AIは、異なる強みを持つ

今回の実証から、人間と生成AIは競合する存在というより、異なる強みを持つ組み合わせとして考える方が適切だと感じました。

人間は、全体像を抽象化し、 「このシステムで本当に重要なことは何か」 「この仕様はそもそもの目的と合っているか」 といった意味や違和感を捉えることを得意とします。

一方、生成AIは、仕様を具体化し、論点を展開し、類似する仕様を比較し、細かな抜け漏れをチェックすることを得意とします。

• 人間：抽象化、全体観、意味、目的、違和感、意思決定
• 生成AI：具体化、論点展開、比較、細部チェック、文書化

この二つを組み合わせることで、従来よりも効率的に上流工程を進められる可能性があります。

AIとの「会話」だけで終わらせない

生成AIとシステム開発を進めるうえで重要なのが、「途中成果物を作ること」です。

ChatGPTとの会話そのものを仕様として扱うのではなく、節目ごとに次のような成果物へまとめます。

• 要件定義書
• 決定事項一覧
• データ項目定義
• 画面仕様
• 未決事項一覧

その成果物を人間がレビューし、 「現在の正しい仕様はこれです」 と確定します。

次の議論では、その確定済み成果物を生成AIにも参照させます。 これにより、 「以前の会話をすべて覚えていますか」 ではなく、 「現在の仕様書を基準に考えてください」 という進め方ができます。

つまり、生成AI時代になっても成果物が不要になるわけではありません。 むしろ、AIが成果物の作成、更新、チェックを支援できることで、成果物を人間とAIの共通言語としてより活用しやすくなる可能性があります。

生成AIは「作業」を減らすが、「意思決定」をなくすわけではない

今回、企画、要件定義、設計を生成AIと一緒に進めたことで、論点を洗い出し、質問し、整理し、成果物へ落とす作業において、生成AIが非常に強力なサポートになることが分かりました。

一方で、生成AIを使えば要件定義や設計そのものが不要になるわけではありません。

システム仕様は、多数の意思決定の集合です。 AIにすべて任せるということは、その意思決定までAIへ任せることになります。

本当に自社業務に合ったシステムを作るのであれば、人間がレビューし、判断するプロセスは残ります。

生成AIは「作業」を減らすことができます。 しかし、「意思決定」から人間を解放するわけではありません。

AI時代には、人間の役割が単なる作業者から、判断者・レビューアへと変化していくと考えられます。

第3回へ：実装・テストでは何が起きたのか

本シリーズは全3回で構成されています。

第1回では、生成AIを使って小規模な業務アプリを実際に構築した結果をご紹介しました。 今回の第2回では、その裏側にある企画・要件定義・設計の進め方と、人間と生成AIの役割分担について取り上げました。

次回、第3回では、ここまで詰めた仕様を実際にコードへ落とし込み、実装・テストを進める中で何が起きたのかを取り上げます。 生成AIを使った実装のメリットだけでなく、実際に見えてきた課題についても整理していきます。

まとめ

生成AIは、システム開発の上流工程において、論点の洗い出し、仕様の具体化、類似仕様の比較、細部チェック、文書化などを効率化できる強力なサポートツールです。

一方で、AIが効率よく作業を進めてくれるからこそ、人間が仕様を十分理解し、自社業務に合っているかを確認することが重要になります。

「速く進むこと」と「正しく理解して進むこと」は同じではありません。

生成AIに作業を任せながら、人間が判断・レビューを行い、節目ごとに成果物を確定する。 この役割分担が、AI時代のシステム開発における重要な考え方の一つです。