この記事は、Lovable（React）×Auth0 をつないだ前回(#1)の続編。
今回は、フロントから直接SupabaseのAPI/Edge Functionsを呼んでいた箇所を、自作バックエンドAPI（AWS Lambda＋API Gateway）へ段階的に移していく試行錯誤の記録です。
目標は 「アカウント登録」フローのバックエンド移行（仕様の 見直し＋最小実装＋バックエンドとAuth0への疎通）。
前回の補遺（Auth0連携が即成功した話）
-
Auth0のDomainとClientID を Lovable 側に正しく渡したら、Universal Login → リダイレクト →
useAuth0()でユーザー情報取得がすぐ成功。
※ただし、ユーザ情報取得エンドポイントはないので404。 - 以降のAPI呼び出しでは audience 付きの Access Token を取得して
Authorization: Bearerでバックエンドへ渡す方針に確定（本稿は「登録API」実装が主題）。
今日やること（ゴール）
- 既存の Supabase依存の「アカウント登録」処理を、自作バックエンドAPI に置き換える設計を固める
- フロント → API の入出力フォーマットを定義（Auth0を前提にパスワード取り扱い方針を整理）
-
AWS Lambda(TypeScript) で
POST /api/accounts/registerを実装 - JWT検証（Auth0のAccess Token） と DBの選定方針を決める（最小はモックor簡易DB／次回以降で本格化）
-
フロント実装（Lovable/React） から 新APIを叩く（
getAccessTokenSilently()）
構成図（本回の到達点）
[Browser / Lovable(React)]
│ 1) Login (Auth0)
│ 2) getAccessTokenSilently() ← audience 付き
│ 3) POST /api/accounts/register (Bearer <token>)
▼
[API Gateway] --(JWT検証)--> [AWS Lambda (TypeScript)] --(DB)--> [Aurora/RDS or DynamoDB(検討中)]
メモ：本稿では Lambda 内で JWT 検証まで実装。将来的には Lambda Authorizer へ分離も選択肢。
Q&Aログ（Lovableへの質問と回答）※そのまま掲載
まずは、バックエンドにどのようなAPIを作ればいいのかがわからないので、Lovableに質問します。
知りたいことは「今、フロントエンドからSupabaseに向けてどんなJSON送っているのか？」です。
早速聞いてみます。
Q: アカウント登録を行うバックエンドAPIを作成する。アカウント登録ボタンを押した際のリクエストと情報を教えて
A: 現在のアカウント登録フローを確認しました。現在はフロントエンドで直接Supabaseの認証APIを呼び出していますが、これをバックエンドAPIに移行する提案をします。
現在の登録リクエスト情報
アカウント登録ボタンを押した際に送信される情報:// フォームから送信される基本情報 { "lastName": "string", "firstName": "string", "email": "string", "password": "string", "confirmPassword": "string", "terms": true } // URLパラメータから取得される招待情報 { "token": "string", "type": "system_admin" }以上
Q&Aログ（Lovableへの質問と回答）※そのまま掲載
先の回答を見た感じ、結構ちゃんと出してくれそうな気がしたので思い切って既にLovable側で実装済みの全画面に対してやってもらうことにしました。
Q: 画面側とセットにしたAPI仕様書にして。機能の目的や概要なども書いて。各エンドぽいとでDBに登録して欲しい内容も。AIに食わせて実装するので。
A: 現在実装済みの画面側の機能を詳しく分析し、画面側とセットにしたAPI仕様書を作成いたします。
※出力された仕様書は省略以上
ちょっとした誤字もなんのその。
気にせず全量を出力してくれました。
ということで、次はCodexに作業を頼みます。
Q&Aログ（Codexへの質問と回答）※そのまま掲載
最近のCodexはGPT5に進化したということで、かなり難しいタスクもこなしてくれると聞いています。
それを信じて、先ほどLovableが出した仕様書を全部そのままつっこみます。
Q: 画面情報（概要、目的）とその画面に対応するapi仕様書を送る。バックエンドのAPI側を実装して。認証については、Auth0を使用する。フロントエンドからトークンが送られてくるから、バックエンドではAuth0で検証するようにして。Serverless経由でlamdbaにデプロイするから、ファイル構成もそのようにして。.tsで作って。
A:
以上
Codexが14分も作業をして６個のエンドポイントを作ってくれました。
Codexが出したコードをCursorにインポート
とりあえずコードを何も見ないまま、Codexを信じてCursorにインポートします。
そして、次のように一切何も見ないまま打ち込みます。
すると、わかりましたと色々調べて足りないものを追加してLamdbaにアップロードしてくれました。
ついでにテスト用のURLも教えてくれました。
では、教えてくれたURLにブラウザからアクセスしてみます。
動いたっぽい！！
ここまで自分で書いたコードは、まだ０！！
次回予告
- バックエンド側でトークンの検証を実施できるようにします。
まとめ（今日の到達点）
-
アカウント登録のフローを Auth0前提で再設計し、Lambda(TypeScript) に 最小の
/api/accounts/registerを実装 - Edge Functionは作らず、自作バックエンドへ集約する方針に一本化