はじめに

今回ハッカソンで作るアプリの技術選定ポイントをまとめようと思います！

ハッカソン期間（1ヶ月・個人開発）でユーザーを獲得(目標)。
そのために「開発スピード」と「ユーザー体験」を最優先に技術を選定した。

MVPスコープは「募集投稿〜参加申請の流れ」に集中し、マッチング機能は対象外に変更とした。

機能: Must

今回使う技術スタック

機能	担当
認証（ログイン・セッション）	Supabase JS Client
DB操作（CRUD）	Prisma

決定：Next.js + TypeScript

理由： AIとGoogle Places APIをサーバーサイドで安全に呼ぶ必要がある。
Next.jsならAPIルートが自然に統合されているため、フロントとバックを1プロジェクトで完結できる。

本当は、次の転職先ではNext.jsのタスク担当になる予定なので、キャッチアップ含めて変更した笑

決定：Prisma + Supabase PostgreSQL

理由： Supabase JS ClientだけでもDB操作は可能だが、SQLライクな記法になりコードの可読性が下がる。
PrismaはTypeScriptファーストなORMで、スキーマ定義→型自動生成の流れが明快。
個人開発でも迷わずに書けることを優先した。

決定：Supabase Auth（JS Client）

理由： DBとAuthが同一サービスで完結するため、ユーザーIDとDBレコードの紐付けが自然にできる。独自認証を実装するコストを省き、開発スピードを確保する。

決定：Vercel

理由： Next.jsの開発元が提供するホスティングのため、デプロイ設定がほぼゼロ。
Prismaのpostinstall設定と環境変数を入れるだけで動く。ハッカソンで余計な設定に時間を使わないため。

決定：Gemini API、無料枠使用・募集文生成のみに限定

理由： ハッカソン期間中のコストをゼロに抑えるため無料枠を使う。
GPT-4系は有料のため除外。Gemini 2.5 Flashは速度と精度のバランスが良く、募集文生成ユースケースに適している。

制約の受け入れ： 無料枠の制限（250リクエスト/日）があるが、Geminiの用途を募集文生成のみに絞ることで枯渇リスクを最小化できる。マッチング機能はMVPスコープ外のため、AI消費の大半を募集文生成に集中できる。

決定：Google Places API（Could機能）

理由： カフェ提案・カフェ情報表示はMustではなくCould。
無料枠（月$200クレジット）でハッカソン規模なら十分賄える。
Must機能が完成した後に着手する。

決定：intentリンク + Webhook POSTの組み合わせ

理由： OAuthは各サービスへのアプリ申請・認証フロー実装が必要。
WebhookはユーザーがURLを1つ設定するだけで直接チャンネル投稿が可能。Twitter/XはintentリンクでAPIキー不要のまま実現できる。

フロー： プロフィールページでWebhook URLを登録 → 募集投稿時にアイコンをクリック → Slack・DiscordはRoute Handler経由でWebhookにPOST → チャンネルに自動投稿。

決定：bulletproof-reactのフォルダ構成を採用

理由： 機能ごとにフォルダを分けるフィーチャーベース構成により、機能追加・修正時に「どこを触ればいいか」が明確になる。
個人開発でも開発が進むにつれてコードが散らかるのを防ぐ。