アプリ開発の上流工程で「試せるところは全部AI」に振り切ってみた話 / 開発者向けブログ・イベント

今回、社内向けのアプリケーションを開発するにあたり、上流工程を担当する機会がありました。せっかくなので「試せるところはすべてAIに任せる」といった方針でAIを使ってみました。実務メモとして、使用したプロンプト例と運用のコツを公開します。使用モデルはChatGPT（GPT-5）です。

背景

社内の顧客管理系スタッフツールを新規開発することになりました。
スケジュールが厳しめだったこともあり、上流工程に割ける時間が限られている状況でした。
「じゃあAIで上流を効率化しよう」と腹をくくり、試行錯誤しながらプロジェクトを進めました。

先に結論（うまくいったこと/難しかったこと）

うまくいったこと

画面UIや構成図をSVGで出力し、編集可能なたたき台を高速で作成できた
そのSVGを足がかりに、詳細設計のたたきや単体テストケースの初版まで作れた
DB設計後の定型チェックを一気に回せた（表記揺れ、型の整合、ルール違反の洗い出し）

難しかったこと

スケジュール作成は挫折（プロンプト設計の詰めが甘く、期待通りにならず）
DB定義書のゼロから生成は非効率だった（要件伝達のコストが高く、自作の方が速い）

画面UIの叩き台をAIに任せてみた

関係者の合意形成と、開発メンバーとの同期のために画面UIのイメージが必要でした。
前提として、今回は社内向けの小規模案件だったため、UIツールで作り込むよりも、納期遵守とスピード優先で「まず形を出す」ことに振り、GPTに依頼してみました。

プロンプト例

一般的な顧客管理用のスタッフツールの画面UIをSVGで生成してください。 

構成要素：
・顧客情報、申請情報、お問い合わせ情報が管理されるアプリ
・サイドメニューとメイン画面の構成
・メイン画面には顧客情報管理画面を表示

ユースケース：
1. 検索条件入力 → 検索実行 → 一覧表示
2. 行クリック → 詳細表示/編集
3. CSVダウンロード、メール送信

ルール：
・すべて日本語ラベル

出力：ダウンロード出来る形でSVGファイルを返すこと。

結果（生成されたSVGファイル）

あっという間にこのクオリティの画像が生成されました。UIデザインのスキルがない自分にはこれは参考になります。ありがたい。
２度３度と出力させてみても、色々な結果が出てきて勉強にもなります。

そして、このSVGファイルをPowerPointで、挿入＞画像から読み込みます。その後、グループ化解除を選択すると各要素を編集可能となります↓

必要な要素の追加、不要な要素の削除、微調整などを行って、さくっと画面UIのイメージを作成できました。

実務メモ

このフローはアプリケーション構成図にも流用できました。
「まず1枚作ってから考える」用途なら、画面遷移図やデータフロー図などにも横展開できそう。
実務では、作った画面イメージをGPTに読み込ませて、詳細設計のたたきや単体テストケースの初版まで発展させて生成させました。

DBテーブル定義書の一次レビューを任せてみた

次はDBテーブル定義書です。
まずは、ゼロから定義書を作ってもらうのを試しましたが、要件を伝えるのに時間がかかってしまい、効率が悪かったため挫折しました。
さらに要件伝達が甘いと、雰囲気のあるものは出るものの、結局全量精査が必要で自分で作った方が速いという結論です。

一方で、完成済み定義書の機械チェックは強力でした。
今回はExcelで作成した定義書を対象に、下記2工程でのチェックを行いました。

(1)同名カラムの型・桁・NOT NULLや命名の揺れを横断比較
(2)命名規則・型統一などのルール準拠を点検。

(1)のプロンプト例

添付のテーブル定義書のExcelをレビューしてください。
各テーブルを横断的に比較し、同じカラム名でデータ型・桁数・NOT NULL条件が異なる箇所や、命名の表記揺れがある箇所を洗い出してください。

出力：
問題一覧（テーブル/カラム/問題/根拠/修正案）

(1)の結果

（実際の出力のため、テーブル名をマスキングしています）
1つ目のチェック。初期のばらつきを一括で潰し、後工程の手戻りを防ぎます。

(2)のプロンプト例

添付のテーブル定義書のExcelをレビューしてください。

各テーブルが下記ルールに沿って定義されているかを確認し、違反している箇所を洗い出してください。

ルール：
・命名規則は小文字＋snake_caseで統一。略語やスペルミスも指摘してください
・主キーは数値のサロゲートキーであること。型はNUMBER(28,0)であること
・時刻型はDATEに統一
・フラグの型はNUMBER(1)で制約はCHECK (col IN (0,1))、NOT NULL、DEFAULT 0であること

出力：
問題一覧（テーブル/カラム/問題/根拠/修正案）

(2)の結果

2つ目のチェック。ルール違反を網羅的に拾ってもらいました。

この2工程で、見落としがちなばらつきを短時間で洗い出せました。

実務メモ

機械的チェックはAI、要件に適合しているかの最終チェックは人の役割として切り分けてレビューしました。
定義書の丸投げは難易度が高かったです。ただし「一般的な会員テーブルに必要なカラム列挙」など部分タスクの支援は有効でした。
定義書のフォーマットを固定しておけば、同プロンプトで同品質の機械チェックを繰り返し適用できます。

最後のまとめ

「試せるところは全部AI」に振り切ったことの学びとしては、うまく回せば上流工程でAIが生きる場面は多いなと気づけました。
上流では、曖昧な要求を形にしていく場面が多いですよね。そこをAIに投げてみると、自分では出せなかったパターンや視点を提案してくれてかなり助けられました。
（記事では割愛していますが、細かいタスクもいろいろお願いしています。通信フローの表をまとめてもらったり、ログ出力仕様を一緒に詰めたり、作成したテストの観点漏れを指摘してもらったり。）

ただ、結局のところ現場や人によって最適解は違うと思います。
今回は社内向けで図の品質基準もゆるめという前提だったので、「AIのたたき台→人の手直し」はハマったなと思っています。
一方で、複雑な前提や厳密さが求められる成果物（DB設計や仕様設計など）は、最初から人が手を動かした方が効率的な場面もあると感じました。

まずは何でも試して、広げていくのがいいんじゃないかなと。
もしどこか一つでも持ち帰ってもらえるポイントがあれば嬉しいです。