前回の記事では、データの保管場所（データベース）をSupabaseから、より柔軟なサーバーレスPostgreSQL「Neon」へ移行した話をしました。
今回はその続きとして、**「Googleログイン機能（OAuth認証）」**の実装についてお話しします。
Webサービス開発において、認証機能（ID・パスワード管理）はFirebase AuthやSupabase Authといった**BaaS（Backend as a Service）**の機能を使うのが一般的です。これらは開発スピードが速く、非常に便利です。
しかし、本プロジェクトではあえてそれらを使わず、バックエンド（FastAPI）で認証基盤をフルスクラッチ（自前）で構築しました。 なぜあえて「茨の道」を選んだのか？ それは、中長期的な**「システムの拡張性」と「ベンダーロックインの回避」**を実現するためです。
1. なぜ「BaaSの認証」を使わないのか？
既存のBaaS認証は、例えるなら**「家具付きの高級マンション」のようなものです。 入居してすぐに快適な生活（機能）が手に入りますが、「大家さん（プラットフォーム側）」のルールに強く縛られます。**
- ベンダーロックイン（引っ越しができない）: 「家賃が高いから別のマンション（AWSなど）に引っ越したい」と思っても、家具（認証機能）が備え付けなので持ち出せません。引っ越すなら、家具を全部買い直す（作り直す）必要があります。
- データの分断（荷物が分散する）: 大事な書類（ユーザー情報）の一部はマンションの管理室に、残りは自分の部屋にと、保管場所が2箇所に分かれてしまい、管理が複雑になります。
- コストと制限（家賃の値上げ）: 住人（ユーザー数）が増えると追加料金が発生したり、「この部屋の使い方は禁止です」と制限がかかるリスクがあります。
本プロジェクトは長期的な運用を見据えているため、特定の大家さんに依存せず、「家具（認証）」も「荷物（データ）」も自分たちで自由に持ち運べる構成を選びました。
2. 今回実装した「Googleログイン」のアーキテクチャ
今回採用したのは、**「Googleに本人確認（認可）を委託し、入館証（セッション）の発行は自社で行う」**という標準的なOAuth 2.0フローです。
これは**「ホテルのチェックイン」**に例えると分かりやすいでしょう。
- パスポートの確認（Google認証）： フロント（Google）でパスポートを見せ、「本人であること」を確認してもらいます。
- ルームキーの発行（FastAPI）： 本人確認ができたら、ホテル側（自社API）が「自社専用のルームキー（JWTトークン）」を発行して渡します。
- 部屋の利用（Neon）： お客様はルームキーを使って部屋（データベース）に出入りします。
この仕組みの最大のメリットは、部屋（データベース）自体は鍵の仕組みに関知していない点です。 もし将来、ホテルを改装したり部屋（データベース）を別の場所に移したりしても、フロントの業務（認証システム）への影響はゼロです。
3. ビジネス視点でのメリット
エンジニアリングのこだわりだけでなく、ビジネスとしても明確なメリットがあります。
- ポータビリティ（移植性）の確保: システムが特定のベンダーに依存しない「疎結合」な状態であるため、インフラの引越しや構成変更が容易です。将来的なスケールアップに強い設計です。
- ユーザーデータの一元管理: 「メールアドレス登録」も「Googleログイン」も、すべて自社の顧客台帳内で統一されたIDとして管理できます。CRM（顧客管理）や分析基盤との連携がスムーズになります。
- ランニングコストの最適化: 認証ユーザー数による従量課金が発生しません。「大家さん」への支払いを気にせず、ビジネスの規模を拡大できます。
まとめ
「とりあえず動けばいい（PoC）」フェーズでは、家具付きマンション（BaaS）を使うのが正解です。
しかし、サービスが成長し、データの資産価値が高まるフェーズにおいては、「認証基盤（鍵と家具）」を自社でハンドリングできることが強みになります。
見た目の機能は変わりませんが、裏側は変化に強く、拡張性の高いシステムへと進化しています。