結論：「ノリで作る」ではなく4ステップで作れる
「生成AIで1〜2週間でプロトタイプが作れる」という話をすると、「うちの業務でも本当にできるのか」という質問をよく受けます。答えは、下記の4ステップを順に踏めば、業種を問わずプロトタイプは作れるです。
- ユーザーストーリーで「誰が・何を・なぜ」を1行に揃える
- FM法で「何を作るか／作らないか」を3軸で決める
- 残った要件を Gherkin に変換してデモ＝テストの種にする
- Laravel Inertia でフルスタックのプロトタイプを実装する
このパイプラインに乗せる限り、生成AIの「最初の8割を高速に書く」能力をそのまま受け止められます。発注側全体のプロジェクト管理に位置づけた6ステップ版は プロジェクト管理 完全ガイド を参照してください。本記事は、その中でも実装直前の4ステップを掘り下げます。
STEP 1: ユーザーストーリーで「誰が・何を・なぜ」を1行に
最初にやるのは、画面の絵を描くことでも技術選定でもなく、誰の・どんな業務上の動機でこのシステムが必要なのかを1行に落とすことです。これがズレると、後段でいくらAIが速く書いても、現場で使われない機能が量産されます。
形式は「As a 〜 / I want to 〜 / So that 〜」の3要素で揃えます。
店舗マネージャーとして、商品の在庫が閾値を下回った段階で通知を受けたい。なぜなら、発注リードタイム（3日）を確保するため、欠品の3日以上前に気づきたいから。
テンプレートと豊富な実例は ユーザーストーリーの書き方完全ガイド にまとめています。実際に書き出すときは、ユーザーストーリー作成ツール を使うと3要素が揃わない歪なストーリーをツール側で弾けるので、初めてでもブレません。
STEP 2: FM法で「何を作らないか」を決める
ストーリーを書き出すと、たいてい30〜80件くらいに膨らみます。このまま全部作ろうとすると、生成AIで早く書ける8割の利点が消えます。ここで FM法（Functionality Matrix） を挟みます。
FM法は『システムを作らせる技術』（白川克, ISBN 978-4-532-32399-8）で紹介されている手法で、各機能を次の3軸で評価します。
- ビジネス価値（★1〜3）：使われると儲かる／コストが下がるか
- 現場で使えるか（★1〜3）：実際の業務オペレーションに乗るか（書籍の「組織受入態勢」相当）
- 技術コスト（低／中／高）：作る難しさ
1軸でも★1（または技術コスト=高）が付けば「作らない」、★3が2軸以上なら「作る」、それ以外は「後回し」が原則です。詳しい運用は スコープ管理「FM法」の使い方 と 「作ったのに使われない」を防ぐ機能フィルタリング、MoSCoW との比較は 要件の優先順位付け：MoSCoW vs FM法 完全比較 を参照してください。
判定はブラウザだけで動く スコープ管理ツール でそのまま回せます。Story Builder で書き出したMarkdownをそのままインポートできます。
STEP 3: 残った要件を Gherkin に変換する
FMで「作る」と判定された機能だけを、Given / When / Then の形式（Gherkin） に書き直します。Gherkin は3つの役割を1つの記述で兼ねられるので、生成AI時代の要件記述の中心になりつつあります。
- 仕様書として読める（業務担当者が読んで意味が分かる）
- 受入デモのシナリオとしてそのまま動く
- 自動テストのソースとしてCIで常時実行できる
記法は Gherkin入門｜Given/When/Thenでシナリオテストを書く・読むための完全ガイド を見れば1時間で書けるようになります。「ストーリーは書けるけど Gherkin は手が止まる」という場合は、EARS記法 をワンクッション挟むと変換が直線になります。EARS から Gherkin、デモ、テストまでを生成AIで一直線に繋ぐ手順は EARS×Gherkin｜要件定義からデモ／シナリオテストまでを生成AIで一直線につなぐ にまとめてあります。
STEP 4: Laravel Inertia でプロトタイプを実装する
ここまで来れば、実装は Laravel + Inertia.js + React の組み合わせが最短です。理由は4つあります。
- 認証・権限・キュー・スケジューラ・管理画面が標準機能で揃っており、業務システムの「最初に必要になる8割」を自分で書かずに済む
- SPA の操作感を保ったまま、API 設計・OpenAPI・JWT などの境界の設計を後回しにできる（Inertia がコントローラ→React を直結する）
- Eloquent と Blade／Inertia は生成AIにとってサンプル量が多い領域で、コード生成の精度が高くなりやすい
- 本番運用に向かうとき、Laravel のままそのままスケールできる（プロトタイプで作ったコードを捨てる必要がない）
Next.js + 任意のORM の構成でも作れますが、認証・権限・queue・cron・admin あたりを自前で組む工数が乗るため、「1〜2週間でプロトタイプ」のスピードは出にくくなります。プロトタイプ段階ではフルスタックで完結する組み合わせを選ぶのが基本です。
ここから先が「90対90ルール」の領域
4ステップで動くプロトタイプは作れます。ただし、動く＝完成ではないことは意識しておく必要があります。Tom Cargill が提唱した 90対90ルールは次のような経験則です。
The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.
（最初の9割のコードが開発時間の9割を消費し、残り1割のコードがさらに9割の時間を消費する）
業務システムでこの「残りの10%」に当たるのは、例外処理／同時編集の競合解決／文字コード／タイムゾーン／権限の境界条件／本番データのリカバリ手順などです。生成AIで一気に書ける領域ではないので、プロトタイプで止めるか・本番化するかの意思決定がここで必要になります。
プロジェクト全体の期間は別の話
プロトタイプ実装が1〜2週間でも、企画 → 要件定義 → プロトタイプ → 検証 → 本格開発 → テスト → 本稼働の全体期間は短くなりません。小規模で3〜6ヶ月、中〜大規模で半年〜1年超が目安です。生成AIで縮むのは「実装フェーズ」であって、合意形成・検証・運用設計は同じだけ必要だからです。全工程の進め方は 生成AI開発の進め方｜PoCからプロトタイプ・本番までの全工程 と システム開発を段階的に進める方法｜MVP・プロトタイプ活用法 を参照してください。
まとめ
「生成AIで本当にプロトタイプ作れるのか」に対する Beekle の答えは、ユーザーストーリー → FM → Gherkin → Laravel Inertia の4ステップに乗せれば作れる、です。各ステップに対応する記事と無料ツールが揃っているので、最初にやるべきは「STEP 1 を Story Builder で書き出すこと」だけです。
- STEP 1 → ユーザーストーリー作成ツール／書き方完全ガイド
- STEP 2 → スコープ管理ツール／FM法の使い方
- STEP 3 → Gherkin入門／EARS×Gherkin ワークフロー
- STEP 4 → 本記事の「STEP 4: Laravel Inertia」セクション
発注側のプロジェクト管理全体での位置づけは プロジェクト管理 完全ガイド を参照してください。