【個人開発】マッチング型サービスの技術選定
はじめに
マッチング型の求人サービス「おためし転職」を個人開発しました。本記事では、求職者向け（toC）と企業向け（toB）の2つのプラットフォームを構築する上での技術選定と、その理由について解説します。
求職者向けサイト（toC）: https://otame4.work/
企業向けサイト（toB）: https://employer.otame4.work/
技術スタック
インフラ：Cloudflare, Supabase
フロント：Next.js(toC,toB共に)
ORM：Drizzle
認証（工夫した点）
Supabase Auth: 求職者向け（toC）
Better Auth: 企業向け（toB）
技術選定の理由
なぜNext.jsを選んだのか
両サイトでNext.jsを採用した理由は以下の通りです。
開発効率の高さ: ファイルベースルーティングやServer Componentsにより、迅速な開発が可能
SEO対応：求職者向けサイトでは検索エンジン最適化が重要であり、SSRやSSGが標準でサポートされている
共通の開発体験：toC/toB両サイトで同じフレームワークを使うことで、コードの再利用や開発効率の向上が図れる
開発者の慣れ：そして何より私が普段から使っているので、慣れていて開発スピードが早い
Cloudflare + Supabaseの組み合わせ
インフラにCloudflareとSupabaseを選定した背景には、個人開発ならではの制約がありました。(ここまではよくある話)
Cloudflare: グローバルエッジネットワークによる高速配信と、無料枠の充実
Supabase: PostgreSQLベースのフルマネージドサービスで、認証やリアルタイム機能も統合されている
コスト効率: 両サービスとも無料枠が充実しており、初期コストを抑えられる
Drizzle ORMを採用した理由
ORMにDrizzle ORMを選んだのは、OpenNextとの相性とEdge環境での動作が決め手でした。
Edge Runtimeでの動作: Vercel Edge FunctionsやCloudflare Workersなど、Edge環境で動作するORMが必要だった
OpenNextとの互換性: OpenNextでデプロイする際に、従来のNode.js専用ORMでは制約があったが、Drizzleは問題なく動作
軽量で高速: Edge環境ではコールドスタートが重要。Drizzleの小さなバンドルサイズがパフォーマンス向上に貢献
型安全性: TypeScriptとの統合が優れており、Edge環境でも型の恩恵を受けられる
SQLライクな記法: 生SQLに近い記法で直感的に書け、PostgreSQLの機能をフル活用できる
最大の工夫ポイント：認証の分離戦略
本プロジェクトで最も工夫した点は、toC側とtoB側で認証機構を分けたことです。
Supabase Auth（toC側）
求職者向けサイトではSupabase Authを採用しました。
メリット:
- ソーシャルログインの実装が簡単（Google、GitHub、LINEなど多数対応）
- メール認証、パスワードリセットなどの機能が標準搭載
- Supabaseのデータベースと緊密に統合されており、Row Level Security（RLS）との連携が容易
- セットアップが非常に簡単で、認証周りの実装工数を大幅に削減できる
Better Auth（toB側）
企業向けサイトではBetter Authを採用しました。
メリット:
Supabase Authとは独立した認証フローを構築できる。
Organization Pluginによって組織管理の機能も豊富。認証ライブラリというより、サービスの基本パッケージを使っているよう。
おまけ：
Better Authには、Better Auth UIという専用のUIも用意されていて、簡単に画面を作成することができました。(shad/cnをラップして作られている模様)
まとめ
マッチング型サービスの開発において、toC/toBそれぞれの特性に合わせた技術選定を行いました。特に認証機構を分離することで、各ユーザータイプに最適な体験を提供しつつ、将来的な拡張性も確保できました。
個人開発では、コスト効率と開発速度のバランスが重要です。Cloudflare、Supabase、Next.js、Drizzle ORMの組み合わせは、その両方を実現できる優れた選択肢だと感じています。
同じような構成でサービスを作ろうと考えている方の参考になれば幸いです。
Discussion