離脱を減らす保存して再開できるマルチステップウィザードのパターン

なぜマルチステップウィザードに保存して再開が必要か

マルチステップウィザードは、1つの長いフォームをプロフィール詳細、請求、設定、確認といった小さなステップに分けます。タスクが長い、データが複雑、あるいは明確な順序をたどる必要があるときに役立ちます。うまく設計されていれば、終わりの見えない単一ページよりも軽く感じられます。

それでも人は中断されて離脱します。必要な書類が手元にない、上司の承認を待っている、接続が切れる、電話からラップトップに切り替えるなどです。ウィザードがリスキーに感じられて途中でやめることもあります：間違いやリフレッシュで全部消えるかもしれない、と思われるからです。

保存して再開できれば状況が変わります。ユーザーは不安なく中断でき、後で戻り、正しいステップから進行を失わずに続けられます。チーム側にも利点があります：放置された送信が減り、サポートの会話が明確になり（「下書きを開いて続けてください」）、どこで詰まっているかの可視化も良くなります。

進行がデバイスをまたいでも失われないという約束を守るには、多くのウィザードで次の基本が必要です：

• ユーザーが入力している間に自動で下書きを保存するか、少なくとも次のステップに移るときに保存する。
• 後のステップの項目でブロックせずに部分的に完了を許可する。
• 下書きを見つけやすくする（アカウント領域、メールリマインダー、再開トークンなど）。
• 進捗と不足している項目を明確に示し、責め立てない。

下書きと状態を分かりやすく

保存して再開できるウィザードは、下書きと送信済みレコードという2つの別のものとして扱うと設計が楽になります。

下書きは一時的で変更可能です。送信済みレコードは公式なもので、より厳格なルールに従うべきです。

「状態」はそのレコードが今どんなラベルかを示すだけです。一般的な状態には draft、submitted、approved、rejected、archived などがあります。もし2つしか必要ないなら、まずは draft と submitted から始めてください。その線引きをはっきりさせると、レポーティング、権限、サポートがずっと簡単になります。

各ステップで何を保存するかは、後で本当に再開に必要なものに依存します。そのステップのユーザー入力と、所有者や最終更新日時などの基本メタデータだけを保存しましょう。万が一のためにといって機密情報（フルカードデータ、まだ要求していない書類、後でユーザーを混乱させる社内メモなど）を保存しないでください。

進捗追跡は地味で明確にすべきです。ほとんどの場合、2つのフィールドで足ります：

• current_step（再開時にユーザーが着地する場所）
• completed_steps（すでに終わっているもの）

チームによっては completed_steps をステップIDのリストで保存する人もいれば、単純なカウントを使う人もいます。

実用的なメンタルモデル：

• 下書きデータ：これまでの回答（未完の可能性あり）
• ステータス：draft vs submitted
• 進捗：現在のステップと完了したステップ
• 所有権：ユーザーまたはアカウントID
• タイムスタンプ：created_at、updated_at、submitted_at

いつ下書きを作るべきか？

フローが匿名だったり再開可能リンクを使いたいなら、ウィザードが開いたときにすぐ作ってIDを確保してください。ユーザーがサインインしていて空の下書きを減らしたいなら、最初の実際の「次へ」や「保存」アクションで作るのが良いでしょう。

下書きに適したバックエンドデータモデル

良い下書きモデルは2つのことをうまくこなします：部分入力を壊さずに保存すること、と最終送信を予測可能にすること。もしデータモデルが汚いと、UIが良くてもウィザードは信頼できないものに感じられます。

オプションA：1つのレコードが進化する（status と current_step を持つ）

これは最も単純な方法です。1つのテーブル（または主要エンティティ）にすべて保存し、status（draft/submitted）や current_step（1–6 など）を追加します。各保存は同じレコードを更新します。

フォームが1つの“もの”（1つの申請、注文、プロフィール）にきれいに対応する場合に最適です。

オプションB：下書きと最終レコードを分ける

ここでは、散らかった部分データ用に Draft テーブルを、クリーンで検証済みのデータ用に Final テーブルを持ちます。送信時に Draft から Final を作成し、Draft をロックまたはアーカイブします。

このパターンは、最終データが厳格である必要がある場合（請求、コンプライアンス、レポート）に有効です。下書きを削除しても送信済みレコードに触らないので安全性も高まります。

オプションC：スナップショットやイベント（監査向け）

誰がいつ何を変えたかを記録する必要がある場合は履歴を保存します。一般的な方法は：

• スナップショット：下書きデータの完全コピーを毎回保存する（復元が簡単）。
• イベント：小さな“変更”レコードを保存する（コンパクトだが読み取りはやや難しい）。

承認や争い、規制データが関わるときに使ってください。

繰り返しのセクション（行アイテムや添付ファイルなど）は下書きでよく破綻します。これらは下書きに紐づく子テーブルとしてモデル化し、後で最終レコードに移すようにしましょう。例：オンボーディングで複数の「チームメンバー」や「書類」がある場合、それぞれ独立して保存します。クエリや並び替え、個別検証が不要でなければ配列を1つのフィールドに詰め込むのは避けてください。

ユーザーを苛立たせない部分検証

部分検証はウィザードが役に立つか壁のように感じられるかを分けます。十分に入力できていれば先へ進めるようにしつつ、明らかに壊れた入力が下書きに入るのは避けます。

ほとんどのウィザードは両方を必要とします：

• ステップレベル検証：現在のステップに必要なチェック。
• 最終検証：送信時にすべてのステップを横断してチェック。

未入力（missing）と不正（invalid）を分けて扱うと良いです。下書きでは未入力は問題にならないことが多いですが、不正はブロックするか明確にフラグを立ててください。でないと後で混乱を招きます。

例：空の電話番号は下書きでは許容してよい一方で、文字が混ざった電話番号は拒否するか明確に表示するべきです。

すぐに検証するものと後で検証するもの：

• すぐに検証：フォーマットや基本パース（メールの形、日付フォーマット、数の範囲、そのステップで必須のフィールド）。
• 後で検証：他のステップに依存するビジネスルール（例：与信は会社規模に依存、配送オプションは住所に依存、一意のユーザー名チェックなど）。
• 非同期で検証：外部システムを呼ぶチェック（税ID確認、支払い方法の認可など）。

エラーは具体的でローカルに。"修正して続行"ではなく、該当フィールドを指して何が間違っているか、どう直すかを示してください。警告（エラーではない）がある場合は続行を許可しつつ「注意が必要」バッジをつけましょう。

実用的なパターンとしては、サーバーから構造化されたレスポンスを返します：

• ブロッキングエラー（修正必須）
• 警告（続行可だが強調）
• フィールドパス（UI が該当入力にフォーカスできるように）
• 短いサマリメッセージ（ステップの上部に表示）

ステップバイステップ：保存して再開フローの実装

良い保存して再開するウィザードは最初の画面から機能を始めます。ステップ3まで待ってからレコードを作らないでください。ユーザーが何か意味のあることを入力したら、すぐに下書きを作り継続的に更新できるようにしたいです。

コピーして使える実用フロー

1. ウィザード開始時か最初の実アクションで下書きを作る。 最低限：所有者（ユーザーIDやメール）、status = draft、ステップ1のフィールド（未完でも可）を保存します。
2. 各ステップ後に保存し、長いステップでは自動保存を入れる。 「次へ」でステップのペイロードを永続化します。長いページではフォーカスが外れたときや短い間隔で自動保存して、リフレッシュで進行が消えないようにします。
3. 再開時は現在の下書きを読み込む。 ID（と所有者）で下書きを取得し、UI に事前入力してユーザーが中断した場所から続けられるようにします。
4. 戻る、次へ、スキップを安全に扱う。 最後に完了したステップや許可される経路を保存します。ステップ4がステップ2に依存するなら、UI が無理にスキップしても必須入力がなければ先へ進めないようにしてください。
5. 最終的に1回の送信アクションで完了させる。 全体検証を実行してレコードをロックし、status = submitted にします。

ユーザーを罰しない検証

下書き中は現在のステップに必要な検証だけを行ってください。部分データは "missing" や "needs review" のようなフラグで保存し、すべてをハードエラー扱いしないでください。

再開リンク：仕組みと使うべき場面

再開リンクはワンタイムまたは短期間有効なトークンを含むURLです。誰かが開くと、アプリはそのトークンが指す下書きを探し、有効かを確認してユーザーを正しいステップに戻します。デバイスを切り替えるときに非常に便利です。

典型的な流れはこうです：create draft -> generate token tied to that draft -> store a hashed copy of the token -> send or show the link -> redeem token to resume -> rotate or invalidate the token.

信頼性を保つトークンルール

あらかじめいくつかのルールを決めておくとサポートが悩みません：

• 有効期間： ウィザードの所要時間と機密性に応じて数時間〜数日。
• ローテーション： 再開のたびに新しいトークンを発行する（デフォルトとして良い）、あるいは送信まで1つを維持する。
• ステップ指定： 最後に完了したステップを保存し、リンクが正しい画面に戻す。
• 配信方法： 「リンクをコピー」と「メールで送る」を両方サポートして、電話からデスクトップへ移れるようにする。

実用例：誰かが電話で申請を始めて「メールで再開リンクを送る」を選び、家のラップトップで続きをする。各再開でトークンをローテーションすれば、古いリンクは1回使うと無効になり、誤って共有された場合のリスクが下がります。

下書きが送信済みまたは期限切れになったとき

明確に示してください。

• 下書きがすでに送信済みなら、読み取り専用の確認画面を開き、新しい下書きを作る案内を出します。
• 下書きが期限切れなら、一文で何が起きたかを伝え、「最初からやり直す」明確なアクションを提示します。

新しい下書きを黙って作るのは避けてください。ユーザーは元のデータが残っていると思いがちです。

下書きと再開トークンのセキュリティとプライバシー

保存して再開は信頼されてこそ役立ちます。

決してURLに個人や業務データを入れないでください。リンクには意味を持たないランダムトークンだけを含めます。

再開トークンはパスワードのように扱ってください。十分なランダム性で生成し、貼り付けやすい長さにして、データベースにはハッシュのみを保存します。ハッシュ化はログやバックアップが漏れたときの被害を減らします。

再利用可能トークンは便利ですがリスクが高くなります。ワンタイムトークンは安全ですが、古いメールを2回クリックするとユーザーがイライラする可能性があります。実用的な折衷案は、短期間（数時間〜数日）有効な再利用トークンと「新しいリンクを送る」機能を組み合わせることです。

ほとんどのプロダクトに対する穏当なデフォルト：

• トークンハッシュ、作成時刻、有効期限、最終使用時刻を保存する
• トークンを自動的に期限切れにし、古い下書きをスケジュールで削除する
• 再開後にトークンをローテーションする（下書き自体はそのまま）
• 再開試行（成功／失敗）をログに残して調査に備える

アクセス制御はサインイン要否によって変わります。

ウィザードがサインイン済みユーザー向けなら、トークンはオプションにして、再開にはアカウントセッションも要求し、下書きがそのユーザー（または組織）に属していることを確認します。これは「転送されたリンク」での問題を防ぎます。

匿名での再開をサポートする場合は、下書きに含める内容を制限してください。フルの支払い情報や政府発行IDなど、漏れたときに危険な情報は避けます。データを暗号化して保存することや、再開時にマスクされたサマリだけを表示することを検討してください。

基本的な悪用対策も加えましょう。トークンチェックや再開エンドポイントにレート制限をかけ、繰り返し失敗が続くトークンはロックします。

離脱を減らすUIパターン

保存して再開はバックエンドの失敗よりUIで失敗することが多いです。人は、次に何が起きるのか分からないとき、迷っているとき、作業が失われそうだと感じたときに離れます。

まず場所の感覚を明確にしましょう。進捗インジケーターには「会社情報」や「支払い方法」などユーザーにとって認識しやすいステップ名を使い、内部ラベルは避けてください。常に見える位置に置き、完了したステップを罰することなくレビューできるようにします。

保存を感じさせつつ過度に騒がしくしないでください。主要なアクションの近くに小さな「保存済み」表示と「最後の保存：2分前」のタイムスタンプを置くと信頼感が生まれます。保存に失敗したら率直に伝え、次に何をすべきか案内してください。

退出を簡単にしましょう。「後で保存して完了」アクションは普通に置き、タブを閉じても戻ったときに簡単に再開できるようにしてください。

モバイルは離脱が増えやすいので、ステップは小さく、フィールド数を抑え、大きなタップ領域を用意し、フィールドタイプに合ったキーボード（メール、数値、日付）を優先してください。

役立つUIチェックリスト：

• ユーザーにわかるステップタイトルを使い、一貫性を保つ
• メインボタン付近に保存状態と最後の保存時間を表示する
• 「後で完了」を「次へ」と並べて表示し、メニューに隠さない
• 各ステップを1つの意思決定に集中させる
• エラーはインラインで修正でき、ステップ全体をブロックしない

よくある間違いと回避法

最も早く離脱率を上げるのは、ウィザードを最終試験のように扱うことです。ステップ6が未完だからといってステップ1で進行を止めると人は辞めます。保存して再開できるウィザードは寛容に感じさせるべきで、頻繁に保存し、前に進めるようにしてください。

検証に関する間違い

よくある罠は早すぎる過剰検証です。ステップレベルのチェックを行い、厳しいチェックは最終レビューに残しておきましょう。

ブロッキングせずにガードレールを置きたいなら、ソフト警告（「後で完了できます」）を使い、最終的に何が必要になるかを強調してください。

データとワークフローの間違い

多くのチームは下書きを遅く作りすぎます。ステップ3まで作らないと、初期データが脆弱になります。リフレッシュやタブクラッシュ、ログインタイムアウトで消えやすくなります。安定した識別（アカウントセッションやメール）が取れたらすぐに下書きを作り、各ステップ遷移で保存してください。

所有権をはっきり決めることも重要です。誰が下書きを再開・編集できるのか：元のユーザーのみ、同じ組織内の誰でも、招待された特定のチームメンバーかを決め、そのルールをUIに表示してください。

その他の落とし穴と対策：

• 重複送信：最終送信を冪等にする（同じリクエストを2回送ってもレコードが2つできないように）
• ステップ順の変更：wizard_version を保存し、古い下書きを新しいステップにマッピングする小さな移行ルールを用意する
• 古いデータで再開：最終送信時に重要フィールド（プラン価格など）を再チェックする
• クリーンアップ忘れ：古い下書きやトークンを期限切れにしてスケジュールで削除する
• 監査ログなし：ステータス変更をログに残し、サポートがユーザーを助けられるようにする

リリース前の簡単チェックリスト

出荷前に離脱やサポートチケットを減らす基本を確認してください。

機能チェック

• 再開はデバイスとブラウザを跨いで動作する。
• 全てのステップはウィザードが未完でも保存できる。
• 下書きはリフレッシュ、タイムアウト、タブ閉じで生き残る。
• 明確な最終レビューのステップがある。
• どのステップで人がやめるかが見える（ステップ完了率、ステップごとの時間、一般的な検証エラー）。

安全チェック

再開リンクは一時的なキーです。私的に保ち、時間制限を設け、意図的に共有されない限り安全なものにしてください。

実用的なルール：メールを誤って他人に転送しても、その人が機密下書きデータを見られないように短い有効期限を設定し、高リスクのステップでは再認証を要求します。

現実的な例：6ステップの顧客オンボーディング

B2B のオンボーディングウィザードを6ステップで想像してみてください：会社情報、担当者、請求、コンプライアンス書類、製品セットアップ、最終レビュー。目標はすべてを一度で終わらせることを強制せず、動くアカウントを作ることです。

厄介なのはステップ4（コンプライアンス書類）です。顧客によってはファイルが揃っていないこともあり、上司の承認が必要な場合もあります。そこでウィザードは各ステップ後に下書きを保存し、Draft、Waiting for documents、Waiting for approval、Submitted のような明確な状態を持たせます。

よくある離脱ポイントはステップ3（請求）を終えた直後です。戻ってきたときに空フォームを見せないように、ユーザーは「オンボーディングを再開」画面に着地して、進捗（3/6）、不足しているもの（書類）、そしてステップ4から続けるためのボタンを見る、という流れです。これが保存して再開の核心で、離席を失敗ではなく普通のこととして扱います。

メール招待から始めたりデバイスを切り替える必要がある場合は、再開リンクが正確な下書きとステップにユーザーを戻します（サインインやワンタイムコードでのチェックを組み合わせても良い）。

チーム側では、サポートやセールスが管理画面で下書き進捗を確認できます：どのステップにいるか、どのくらい放置されているか、何が送信を阻んでいるかが見えます。

次の一手：段階的に出して保守しやすくする

小さく始めましょう。既に離脱があるウィザード（チェックアウト、オンボーディング、申請など）を1つ選び、まず下書きを加えてください。ステップ変更時の基本的な「保存」＋自動保存の導入は、デザイン変更よりも早く離脱を減らすことが多いです。

変更前に指標を取り、公開後にまた測定してください。ステップ間の完了率、完了までの時間、離席後に再開した人の割合を追い、サポートチケットや特定ステップでの挙動（同じ2つのステップを行き来する、検証で何度も失敗する等）も監視します。

ウィザードは変わるものと想定してください。新しいステップが追加され、質問が名前変更され、ルールが厳しくなります。古い下書きを壊さない最も簡単な方法は、保存時にバージョンを持たせることです。各下書きに wizard_version を保存し、古い下書きでも開けるように小さな移行ルールを用意してください。

すべてを手作業で作りたくないなら、AppMaster (appmaster.io) のような選択肢があります。Draft エンティティをデータベースにモデル化し、ビジネスプロセスとしてステップロジックを組み立てれば、同じフローをウェブとネイティブモバイルに渡って提供できます。