【AI駆動開発｜お弁当予約システム｜設計編】要件を設計に落とし込むプロセス全公開！UI・DB・API設計も…現役エンジニアがAIと設計した結果「いやAI以前は5人x5日(80h)が1人で2.5hて笑」
【AI駆動開発｜お弁当予約システム｜設計編】要件を設計に落とし込むプロセス全公開！UI・DB・API設計も…現役エンジニアがAIと設計した結果「いやAI以前は5人x5日(80h)が1人で2.5hて笑」（GPTにて要約）
「いやこれホント、AI以前の手作業なら 5人×5日＝25人日 かかるところが、AI駆動開発ならスモールスタートで 1人が2.5時間 くらいでプロトタイプ作れちゃう…ってウワサ、本当だったんですね(笑)」
今回の【お弁当予約システム】の設計案は、
経営者の「ヒヤヒヤ」をなくす在庫連動と信頼性
「まず小さく試す」＆「実践ですぐ確認」の精神
たいき堂店長やダイチのような実在感あるペルソナを軸にした具体的フロー
これらを混ぜて、とにかくワクワクと安心感が同居するシステム構成にまとめました。
この設計案を読んだ時点で、「なんだか楽しそうだし、これならうちでも本当にいけそう！」と思っていただければ大成功です。実際に小規模導入で試してみて、さらに必要に応じて機能拡張していきましょう。
AI駆動開発での「設計」取り組みの全体像
結論
AIの力を活用することで、従来は「10人×5日 = 80時間」ほどかかった設計フェーズを、実質「1人×2.5時間」程度で完了するスピード感が実現できるようになった。
結論に至る背景
従来のやり方
設計フェーズでは、要件定義をもとに画面設計・DB設計・API設計などを複数人でじっくり詰めていく。通常は人手でのドキュメント化・レビュー・修正が重なるため、大きな工数（例：80時間程度）がかかる。AIの登場
ChatGPTやClaude、Google Bard(Gemini)など生成AIが、設計書作成の「叩き台」を瞬時に出してくれる。これにより「レビューと微調整がメイン」という形にシフトでき、全体の工数が劇的に減少する。
具体例
10人×5日(=80h) → 1人×2.5時間
複数名でブレスト・仕様調整していた工程を、AIに要件を丸投げすることで短時間に設計書を作成。あとは微調整で済む。動画内でも2時間程度で設計内容を大枠固める
実際、動画ではほぼリアルタイムでAIに聞きながらドキュメントを整備しており、短時間で各種ドキュメントの雛形を得ている。
最終結論
AIを利用することで、要件が複雑でも設計フェーズの初期アウトラインが一気に固まり、作業時間を大幅に圧縮できる。最終的な人間によるレビューは不可欠だが、叩き台生成のスピードアップは大きな武器となる。
開発フェーズ全体の流れと「アジャイル vs ウォーターフォール」
結論
システム開発の基本フェーズは「要件定義 → 設計 → 実装 → テスト → リリース」。これを「まとめて」進めるウォーターフォール方式と「小刻みに」進めるアジャイル方式があり、AI時代でも変わらずこの5つの流れは重要になる。
結論に至る背景
5つのフェーズ
要件定義：何を作るか（目的と機能）
設計：どのように作るか（UI/DB/API/セキュリティ など）
実装：ソースコードを書く
テスト：動作確認・バグ修正
リリース：本番運用へ公開する
アジャイルかウォーターフォールか
ウォーターフォール：大きく一括で要件や設計を完了し、順次移行
アジャイル：要件・設計・実装・テストを小さな単位で繰り返す
AI活用のインパクト
従来、要件定義や設計の「ドキュメントを整える作業」に工数がかかったが、AIに一部委任が可能になり、アジャイルの「短いサイクル」への適性が一層高まる。
具体例
お弁当予約システム
まず最優先すべき機能は「メニュー登録と注文受付」。これだけを素早くアジャイル的に作り、残りは後で継ぎ足すのもあり。AI生成の設計書を見ながらウォーターフォール的にまとめる
動画中では、一気にまとめ上げる形でドキュメントを作成。ただし要件が変わればその都度、AIとやり取りして修正すればアジャイル的にも運用可能。
最終結論
AIによって設計フェーズが早まったとしても、開発フローそのもの（要件定義→設計→実装→テスト→リリース）は普遍。その上で「ウォーターフォールかアジャイルか」はプロジェクト特性に合わせて選択し、AIのアウトプットを活かすとよい。
要件定義のまとめと設計フェーズへの移行
結論
要件定義フェーズで「どのような機能が必要か」をしっかり決めたら、その次は「どう作るか」という設計にすぐ着手できる。要件定義をAIに学習させると、設計のアウトライン生成が格段に楽になる。
結論に至る背景
要件定義の重要性
目的・機能・ユーザー層・使うシーンなどが曖昧だと、設計段階のAIが混乱する。明確な要件があるほど、AIの回答も的確に。要件定義終了のタイミング
動画では、事前に「お弁当屋さんのオンライン予約システム」要件を大まかに洗い出し。それをAIに渡したところ、画面一覧・機能一覧がすぐに提示された。
具体例
予約システムに必要な機能
会員管理（ログイン・登録・プロフィール編集）
メニュー管理（新メニュー登録・在庫設定・価格設定）
注文機能（カート・支払い情報・注文履歴）
管理画面（注文ステータス一覧・売上集計 など）
データの扱い
電話予約を自動化したい
カレンダー日付別でメニューを提示したい
配達先住所が複数あるかどうか、など
最終結論
きちんと要件定義をしておけば、そのままAIに「ここから設計して」と指示を出せる。要件が固まっている分、AIのアウトプットの質が上がり、設計書やドキュメントが一気に自動生成される。
ユーザーストーリーとユーザージャーニーの洗い出し
結論
「私は○○として、××するために△△したい」というユーザーストーリー形式で整理すると、必要な機能が明確化しやすく、AIにも渡しやすい。
結論に至る背景
ユーザー視点での要件整理
システムを使う具体的な立場（一般利用者、管理者、常連客など）からストーリーを描くと、やるべきことを網羅できる。ジャーニーマップの効果
「ログイン → 注文 → 支払い → 受け取り → アフターサービス」などの一連の流れを可視化することで、漏れなく機能を洗い出せる。
具体例
一般ユーザーとして
「会社員として、昼食手配の手間を減らすためにスマホでお弁当予約したい」
「在宅ワーカーとして、確実に時間指定配達したい」
管理者として
「店長として、仕入れや在庫管理を効率化するために予約一覧を簡単に確認したい」
「スタッフとして、注文状況をひと目で把握したい」
最終結論
ユーザーストーリー/ジャーニーをAIに渡すと、自動的に必要画面・機能が一覧化される。設計抜け漏れを減らすためにも、ユーザーストーリー方式は効果的。
画面設計（ワイヤーフレーム）をAIで作る
結論
ワイヤーフレームのドラフト（画面の配置、ボタンの位置など）も、AIに指示すればテキストベースで素早く出力してくれる。そこからサイドバー配置や項目追加などを細かく人間が修正すると効率的。
結論に至る背景
従来の画面設計
1ページごとにUI配置をデザイナーやエンジニアが検討し、PowerPointやXDなどでワイヤーを引く。初期段階の数十枚分はかなり工数がかかる。AIに丸投げできる部分
「ホーム画面、ログイン画面、メニュー一覧、カート、管理者ダッシュボード」など画面名を伝えれば、ざっくりUI構成をテキストで提案してくれる。
具体例
動画内のサンプル
ユーザー向けに「トップページ／メニュー一覧／カート／注文履歴／マイページ」などを列挙 → AIが画面の要素を文字ベースで作図。
管理画面では「ダッシュボード／メニュー管理／注文管理／売上集計などをサイドバーでまとめる」といった構成も自動生成。
サイドバー追加要望
ChatGPTやClaudeに「サイドバーで切り替えたい」とリクエストすれば、そのまま構成図を再提示してくれる。
最終結論
初期ワイヤーフレーム段階はAIに出してもらい、そこに「サイドバーをつけたい」「ボタンは右上」など修正指示を積み重ねると、人力のデザイン工数を大幅に削減できる。
アーキテクチャ設計と技術選定（Next.js / MongoDB など）
結論
AIに「フロントエンドをNext.js、バックエンドをNode.js／TypeScript、データベースをMongoDB、ホスティングはVercel」のように全体構成を質問すると、図式化（マーメイド図など）も含めて短時間でまとめてくれる。
結論に至る背景
アーキテクチャ決定のポイント
フロント：SSR（Server-Side Rendering）で高速表示 → Next.js
データベース：スキーマ変更が柔軟 → MongoDB
デプロイ：無料枠や使いやすさ → Vercel など
AIによるドキュメント生成
PlantUMLやマーメイド形式で構成図を一気に出力。
エラーが出た際はエラーメッセージを伝えると修正案を再提示してくれる。
具体例
構成例
フロントエンド：Next.js + TypeScript + Material UI(MUI)
バックエンド(API)：Next.js のAPI Routes
データベース：MongoDB Atlas
画像保存：AWS S3
デプロイ：Vercel
エラー対応の高速化
「プラントUMLでエラーが出た」→ AIが自動リトライし、正しい記法で再出力
最終結論
「どういう技術を使うか」を決めたら、それをAIに投げると全体図を作り、ファイル構成例や技術スタックの利点・欠点を補足付きで出力してくれる。開発チームの合意形成が圧倒的に早くなる。
データベース設計（ER図・コレクション構造）
結論
MongoDBのようなドキュメント型DBの場合、テーブル（コレクション）をどう分割し、どのように紐付けるかはAIがER図（もしくはそれに近い図）で提案してくれる。最終的にアドミン情報をユーザーコレクションに統合するなど柔軟に検討可能。
結論に至る背景
モデリングの難しさ
ユーザー情報、メニュー情報、注文（オーダー）情報、お知らせ...etc
リレーショナルDBであれば外部キーを使い複雑になるケースが、MongoDBならドキュメントで柔軟に変更できる。
AI提案のバリエーション
管理者を別コレクションで持つ → あるいは「ロール（role）フィールド」をユーザーコレクションに追加して兼用する、など。
具体例
主なコレクション
users：ユーザー基本情報（ロールで管理者・一般ユーザーを区別）
products：お弁当メニュー（名前・価格・在庫など）
orders：注文情報（注文日・ステータス・ユーザーID等）
orderItems：注文詳細（どのメニューを何個注文したか等）
announcements：お知らせ（タイトル・本文・公開日）
ER図の自動生成
動画内では、AIがマーメイド形式やプラントUML形式で関係性を可視化。一部エラーは出るが修正依頼をすると再度生成。
最終結論
DB構造の初期ドラフトをAIに出してもらい、人間が業務フローに合わせて若干手直しする。これで最初のDB設計工数を大幅カットできるうえ、後からの変更にも対応しやすい（MongoDBの強み）。
API設計（エンドポイントとリクエスト/レスポンス定義）
結論
RESTful APIの基本である「GET / POST / PUT / PATCH / DELETE」を、各機能（例: /products, /orders など）ごとにAIが一覧化してくれる。JWT認証やレスポンスの例文まで自動生成が可能。
結論に至る背景
API設計でよくある作業
エンドポイントURL設計
リクエストパラメータとレスポンス構造の決定
認証方式（JWT / OAuth）選定
異常系（エラーハンドリング）定義
AIの役割
要件に応じたURL命名ルールを瞬時に提案。
リクエスト/レスポンスのJSON例を提示。
認証が必要なAPIと不要なAPIをまとめる。
具体例
/auth/login (POST)
入力：{ "email": "...", "password": "..." }
出力：{ "token": "...", "user": {...} }
/products (GET)
入力：なし（またはクエリパラメータ）
出力：[ { "id": ..., "name": "...", "price": ...}, ... ]
/orders/{id} (PATCH)
“PATCH”を使って「部分的にステータスのみ更新」などが可能
最終結論
APIエンドポイント設計は本来頭を悩ますが、AIに「機能一覧・HTTPメソッド・リクエスト/レスポンス例」を聞けばすぐに叩き台が得られる。最終的な業務フローに合わせて修正すれば高効率。
テスト計画・テストケースの自動生成
結論
単体テスト・結合テスト・受け入れテストなどのテスト計画書、そして具体的なテストケース（正常系/異常系・境界値テストなど）もAIに作らせると、初稿が短時間で完成する。
結論に至る背景
テスト工程の重要性
設計と実装が終わった後も、バグを発見して修正する工程は必須。漏れなくテストケースを書き出すのは多大な労力となる。AIによる網羅的提示
「境界値」「エラー時レスポンス」など、通常人が見落としやすいポイントをAIが例示。そこから各チームで微修正して最終化する流れが最適。
具体例
正常系/異常系の例
正常系：ユーザー登録時に正しいメール形式を入力 → ユーザー作成成功
異常系：パスワードに文字数不足 → エラー表示
境界値：商品注文数を10点まで可 → 10はOK, 11でエラー
テストケースIDと入力例
AIが「TC001」「TC002」...のようにIDを割り当て、前提条件、入力データ、期待結果を表形式で出力。200人同時アクセスを想定した負荷テスト
動画では小規模でも、AIに負荷テストの項目出しを求めれば簡易的なシナリオを作ってくれる。
最終結論
テストケースの作成こそ人手だと時間がかかり、漏れが起きやすい。AIの提案をベースに、実システム固有の要件を足して精度を高める形がベスト。
今回の設計まとめとAI活用による未来像
結論
「無から有を生み出す」設計フェーズは、AIが叩き台を生成し、人間がレビューする新しいスタイルへ急速に進化している。特に今回のような予約システムでは、設計全体を“2時間”という短時間で仕上げる事例が示された。
結論に至る背景
設計はエンジニアリングの醍醐味
従来は膨大な時間と労力が必要。要件レビュー、画面設計、DB設計...を何度も会議して詰めていた。AIで削減した工数
ドキュメント作りの初稿 → AIが担当
人間は「補足・修正・レビュー」に注力
→ 従来数十時間～数百時間→数時間まで短縮
具体例
例：10人×2週間(=10人×10日×8h=800h)想定が、1人×数時間で完成
動画内でも「激速すぎて笑う」レベルの成果。実務ではもう少し調整工数は増えるが、それでも圧倒的な削減幅。複雑な設計への展望
金融や医療のように要件が厳密な場合でも、AIの素案をベースに人間がセキュリティ要件を厳格化し、最終設計をまとめる流れが期待される。
最終結論
設計は今後も必要不可欠だが、その初期段階をAIが大半をカバーすることで、エンジニアはより高度な判断・コミュニケーションに集中できる。結果として、より短い期間でより高品質なシステムを開発できる未来像が見えてきた。
まとめ
ステップバイステップでの設計フロー
要件定義 → 2. ユーザーストーリー作成 → 3. 画面設計 → 4. DB設計 → 5. API設計 → 6. テスト計画
AIが得意な領域
文書初稿の作成
図式化（ワイヤーフレーム、ER図、フローチャートなど）
テストケースやエンドポイント定義の雛形
人間の役割
要件の最終判断や優先度付け
AI生成物のレビューと修正
業務固有の仕様に合わせたチューニング
上記のように、AIとエンジニアが協働する新時代の開発スタイルは、短時間でも高品質な設計成果を得られることを動画で実証している。具体的な数値（10人×5日→1人×2.5h など）や事例を見ても分かる通り、工数削減のインパクトは極めて大きく、実務への応用範囲も広いといえるだろう。
前回の要件定義編を踏まえ、UI・DB・API 設計へと一歩踏み込み、どのように「店舗のお悩み」を具体的な仕様に落とし込んだのか解説。
目次と詳細ポイントは以下にまとめていますので、ぜひご活用ください！
▼目次
00:00 冒頭・今回のテーマの確認
01:05 システム開発の5フェーズとAI時代の設計の重要性
04:22 設計で必要な書類の例
35:26 要件定義のまとめ・ユーザーストーリー化
01:01:58 画面設計
01:25:19 システム構成図（アーキテクチャ設計）
01:39:32 データベース設計（ER図・コレクション定義）
02:03:48 API設計
02:18:00 テスト計画・テストケース
02:31:13 まとめ・次回予告
▼この動画のポイント
• 要件定義を設計に落とし込む具体的プロセス
• AI×人間レビューで大幅時短＆高品質
• UI配置・DBスキーマ・API仕様まで一気通貫
• 従来は5人×5日(約80h)→なんと1人で2.5hの驚き
▼この動画の要約
1. AI補助による設計効率化
○ 画面設計・DB設計・API設計をAIが素早く提案
○ 人間が最終チェックを入れることでミスや抜け漏れを最小化
2. リアルなお悩みを反映
○ お弁当屋さん特有の「配達先」「日替わりメニュー管理」などを設計に落とし込み
○ 店舗運営の流れに沿った画面・データ構成を丁寧に検討
3. AI以前の工数との比較
○ 従来は複数人で数日かかっていたドキュメント作成が、AI利用で大幅短縮
○ “最終的に人の目は必須”だが、それでも驚きのスピード感を実感
▼環境・ツール
• ChatGPT: https://chatgpt.com/
• Claude: https://claude.ai/
• Google AI Studio: https://aistudio.google.com/prompts/n...
【お願い】
👍チャンネル登録＆高評価をぜひお願いします！
🎬今後も「AI×プログラミング」や「業務改善」をテーマに最新情報を発信していきます。
▼前回の動画
・【AI駆動開発｜お弁当予約システム｜要件定義編】現役エンジニアがAI活用してお弁当屋さんのリアルなお悩みを解決するために開発してみた結果。。。「結局は人間の目でレビューは必要、それでもAI効果すご！」 - YouTube
URL: • 【AI駆動開発｜お弁当予約システム｜要件定義編】現役エンジニアがAI活用し...
▼あきらパパのSNSをフォローしよう！
• Twitter: / akira_papa_it
• note: https://note.com/akirapapa/
🌟AIエンジニアコミュニティ「RIDE ON AI」
• 最新AI技術の検証
• エンジニア視点でのAI活用
• メンバー同士の知見共有 参加はこちら： / discord
#AI駆動開発 #お弁当予約システム #生成AI #要件定義 #プロダクト開発 #エンジニア
※この動画の内容は2025年2月時点の情報です。
今後のアップデート等により一部機能が変更される場合があります。
前回の記事
エージェントによる業務効率化