AIでWebアプリのユーザーフローを整理する方法｜画面遷移を先に決める

WebアプリをAIと一緒に作るなら、画面を先に増やすより「誰が、どこから入り、何を終えたら成功か」をUser Flowとして固定する方が実装しやすくなります。画面遷移だけでなく、入力、認証状態、保存、権限、失敗時の復帰まで書くと、必要なPage・State・Dataが見えてきます。

この記事では、架空の「質問に答えると候補を絞れるWebアプリ」を例に、Happy Path、Failure Path、State、Route、Data Contract、AIへの依頼文、Prototype QAまで整理します。最終的には、実装前に必要画面と例外を判断できる状態を目指します。

最初にUser Jobと完了条件を一文で決める

「AIアプリを作る」ではFlowになりません。利用者が観察可能なOutcomeまで書きます。

例：

弱い定義：AIツールを探す。

強い定義：利用者が5つの質問へ答え、自分の条件に合う候補3件と選定理由を確認できる。

この完了条件が、最後に必要なResult画面と保存データを決めます。

開始地点も固定する

同じJobでも、TOPから始まるのか、検索結果のLanding Pageから始まるのか、ログイン後のDashboardから始まるのかでFlowが変わります。

Entry Point、認証状態、持っているContextを記録します。URL queryやInvite Codeなど、開始時点で渡されるDataも含めます。

まずHappy Pathだけを書く

最初は例外を全部考えず、最短で成功する流れを作ります。

架空例：

1. Landingへ入る

2. 「診断を始める」

3. 5問へ回答

4. 回答確認

5. Result生成

6. 候補3件と理由を見る

7. 詳細へ進む

この時点で、StepごとにUser Action / Screen / Required Data / Nextを付けます。

User Flow Mapへ変換する

表は横にスクロールできます

Step	User Action	Screen / State	Data	Next / Failure
Start	診断開始	/finder	session_id	Q1
Input	回答する	question step	answers	next / validation error
Review	内容確認	review	answers	submit / back
Process	送信	loading	request_id	result / API error
Complete	結果確認	/result/[id]	result_id	detail / retry

この表から、Route、State、Data、Errorの必要性を逆算できます。

画面とStateを分ける

1画面に複数Stateがあることを忘れないようにします。Form画面ならediting、validating、submitting、error、successがあります。Result画面ならloading、empty、partial、completeがあるかもしれません。

AIにPage一覧だけを作らせると、このStateが抜けやすくなります。各Screenについて「どんな状態を持つか」を別列で出させます。

入力Data Contractを決める

質問フォームなら、Field名、Type、Required、Validation、Default、Allowed Valueを決めます。

例：

use_case: enum / required

budget: number or range / optional

needs_api: boolean / required

language: enum / required

notes: string / optional / max lengthあり

画面を作る前にこのContractがあると、Frontend、API、DBの認識がそろいます。

認証状態でFlowを分岐する

匿名でも使えるのか、保存にはログインが必要なのか、最初から認証必須なのかを決めます。

たとえば診断は匿名、結果保存だけログイン必須なら、Resultまではanonymous Flow、Saveクリック時にAuth Flowへ分岐します。最初からログインを要求するより離脱が少ないかもしれませんが、Product要件で判断します。

権限は画面表示とData操作の両方で考える

ログイン済みでも他人のResultを見られてよいとは限りません。

Flow Mapにowner / member / adminなどRoleを付け、どのRouteへ入れるかだけでなく、どのDataをRead / Updateできるかを明記します。画面を隠すだけでなく、Server側でもAuthorizationが必要です。

Failure Pathを後から追加する

Happy Pathができたら、重要なFailureだけ加えます。

例：

• Required未入力

• Invalid format

• Session expired

• API timeout

• Result generation failed

• Save failed

• Unauthorized

• Resource not found

• Network offline

すべての異常を網羅するのではなく、User Jobを止めるものとDataを壊すものを優先します。

Failureごとに復帰先を決める

Error表示だけで終わるとFlowが切れます。Retry、Back、Edit、Login、Contact Supportなど、次に取れるActionを定義します。

たとえばAPI timeoutなら入力を保持してRetry、validation errorなら該当Fieldへ戻る、UnauthorizedならLogin後に元Routeへ戻す、といった設計です。

保存と再開を設計する

長いFlowでは途中保存が必要かもしれません。

session_id、draft state、updated_atを持つのか、ブラウザだけに保持するのかを決めます。共有端末や複数Device利用があるなら保存先・期限・Privacyも関係します。

「戻る」「ブラウザ更新」「別Tab」「再ログイン」で状態がどうなるかもPrototypeで確認します。

RouteはFlowから決める

必要なStateが見えてからPage / URLを割り当てます。

例：

/finder：開始と質問

/finder/review：確認

/finder/result/[id]：結果

/login：認証

/account/results：保存一覧

Stateごとに別Routeが必要とは限りません。URLで共有・再開したいStateだけRoute化する考え方もできます。

AIへはFlowから成果物を分けて出させる

依頼例：

以下のUser JobとHappy Pathから実装前のUser Flowを作ってください。

出力：

1. Step

2. User Action

3. Screen / Route

4. UI State

5. Required Data

6. Permission

7. Success Next

8. Failure / Recovery

9. Unknown

その後、別表でPage一覧、Data Field一覧、API候補を出してください。存在しない要件を補完せずUnknownに残してください。

画面・Data・APIを一度に混ぜず、FlowをSourceに各設計へ派生させます。

架空例：Failureを含む完成Flow

利用者がQ3で未入力→同画面にerror→入力→Review→Submit→API timeout→回答保持→Retry→Result生成→Saveクリック→未ログイン→Login→元Resultへ復帰→Save完了、まで通れば、主要なStateがかなり見えます。

このように、成功画面だけではなく「途中で失敗してもJobを完了できるか」をFlow QAにします。

Prototypeで最初に見る5点

1. 初見でStartが分かる。

2. Backしても入力が壊れない。

3. Errorから復帰できる。

4. Loginを挟んでもContextが戻る。

5. Complete後に次Actionが分かる。

見た目の完成度より先に、この5点を通します。

DesktopだけでなくMobile Flowも確認する

MobileではKeyboard、Viewport、戻る操作、長いForm、固定CTAなどでFlowが変わることがあります。

同じRouteでも入力完了までの操作数やerror表示が違うため、主要Flowは少なくとも狭いViewportでも通します。

MVPではFlowを減らす

MVPでは、Core Jobに不要な分岐をLaterへ送ります。Social Login、複数保存形式、共有、通知、細かい設定などがなくてもJobが完了するなら、後回しにできます。

User Flowを先に作ると、「この機能がないと完了できないか」でMust / Laterを判断しやすくなります。

実装前Checklist

• User Jobが観察可能なOutcomeになっている

• Entry Pointが決まっている

• Happy Pathが1本通る

• Required Dataが定義されている

• Auth / Permission分岐がある

• Loading / Empty / Error / Successを確認した

• Failureから復帰できる

• 保存・再開の扱いが決まっている

• RouteはFlowから導いている

• PrototypeでJobを最後まで通した

AIものさしの判断

Webアプリの画面遷移は、Page一覧から作るよりUser Jobから作る方が設計しやすくなります。誰がどこから入り、何を入力し、どのStateを通って、何をもって完了するかを先に固定します。

まずHappy Pathを1本だけ作り、User Flow MapへDataとStateを追加してください。その後にFailure / Auth / Permission / Saveを足し、最後にRouteへ変換する。この順なら、AIに画面を大量生成させる前に、本当に必要な画面と例外を絞れます。