AIで作ったアプリの引き継ぎ：ログイン・決済・データ権限を整える

画面はできたのに、ログイン、決済、自分のデータの表示で利用者が止まる。実際の操作を一つ選び、調査、修正、公開準備まで追います。

ProApp公開 2026-10-07読了目安：6分

AIツールで登録画面、会員画面、決済ボタンを作っても、他の人が試すとログイン後にホームへ戻る、支払っても使えない、別アカウントと同じデータが見える、といった問題が見つかることがあります。利用者の操作を追い、設定、連携、業務ルール、コードのどこを直すか判断します。

会員アプリの導線を例に、引き継ぎで確認する箇所を紹介します。ログインで本人を確認し、権限でアクセス範囲を決め、決済結果に応じてサービスを利用可能にします。画面の「成功」表示だけでなく、それぞれがつながる必要があります。Supabaseの公式資料も認証と認可を分けて説明しています。

実際の利用を止める問題を一つ再現する

アプリを開いた時点から、使ったアカウント、操作、予定の画面、止まった場所を記録します。例えば支払い後に会員画面へ戻っても「未契約」のままなら、アカウント状態、決済イベント、関連データを合わせて、連携が切れた段階を探します。

コード、配信環境、データサービス、テストアカウントを用意します。テスト環境で再現してから、残す画面や機能、変更する箇所を決めます。画面が完成しているからといって、全体の作り直しが必要とは限らず、連携をすべてそのまま使えるとも限りません。

登録、メール確認、ログイン、パスワード再設定、ログアウトを実際のドメインと端末で通して試します。招待や特定コンテンツから入った場合は、ログイン後にその操作へ戻します。誤ったパスワード、期限切れリンク、切れたセッションにも、次の操作を分かるように示します。

会員にはアクセスできる注文、ファイル、コンテンツだけを表示し、職員や管理者は役割に沿って作業します。一般アカウントを二つ使ってデータを作り、相手の記録や添付資料を開けないか試します。ボタンを隠すだけでなく、データ側でも許可されない取得や変更を拒否する必要があります。

Supabaseを使う場合は、Row Level Securityの公式資料に沿ってテーブルの権限とアクセスルールを確認し、許可と拒否の両方を試します。ファイル保存と管理者操作も別に確認し、一つのテーブルの合格だけでアプリ全体の権限確認を終えないようにします。

利用者が決済画面を離れ、後から戻っても、支払いと会員状態が対応する必要があります。Stripeではサーバーがイベントを受けて記録を更新できます。公式資料は署名確認を求め、同じイベントが複数回届く場合も説明しているため、利用権付与や受注作成では重複への対応が必要です。

テスト環境で成功、失敗、取消、イベントの遅延と再送を試します。利用者には結果を明確に示し、サポート担当者は決済と利用権の履歴を探せるようにします。支払い済みなのに開通しない場合は、再度支払わせず、追跡して復旧できる方法を用意します。

修正した導線、テスト用の役割、合格したケース、残る課題を整理します。公開前にドメイン、設定、バックアップ、配信方法、問題時の復旧方法を確認します。保守担当者が新機能や障害に対応できるよう、コード、サービスアカウント、監視の責任者も明確にします。

ProAppは支払い前にDemoをご用意します。現在のアプリ、機密情報を伏せた問題画面、利用者がしたい操作を基に、残せる部分とつなぎ直す部分を相談できます。一般アカウントでログインし、主要操作を行って、データや会員状態が正しく更新されるか確認します。

ログアウト後の再利用、別アカウント、失敗する操作も確認します。プロダクト担当者は用途に合うか、サポート担当者は問題を履歴から追えるかを見ます。継続して使い、保守できる製品にするため、引き継ぎの細部まで確認します。