Next.jsと**Netlify**で作るAI旅行プランナー「Tabidea」の技術スタックと、個人開発としての割り切り

こんにちは、Tabidea 開発者の Tomokichi です。

前回の記事では「ChatGPTとTabideaの違い」というプロダクト思想のコアな部分をお話ししました。 今回は、エンジニアの方向けに少し視点を変えて、Tabidea の裏側をどうやって作っているのか という技術的なお話をしたいと思います。 個人開発（あるいは少人数のスタートアップ）において、技術選定は「できること」と同じくらい「やらないこと（割り切り）」が重要だと考えています。

Tabideaの技術スタック全体像

まずは結論から。現在のTabideaのコアを支える技術スタックは以下のようになっています。

• フロントエンド: Next.js (App Router), React, TypeScript, Tailwind CSS
• バックエンド/BFF: Next.js (Route Handlers)
• インフラ/ホスティング: Netlify
• CDN: Cloudflare
• データベース: Supabase (PostgreSQL)
• AI/LLM: Gemini API (gemini-2.5-flash, gemini-3.0-flash, gemini-3.1pro) をメインに使用し、補助として OpenAI API (gpt-5.4, gpt-5.4-mini) を活用
• 外部API: Google Maps API (Places API, Directions API 等)。ただし、プランの生成自体には Google Maps API は使用していません

見ての通り、非常にオーソドックスでモダンなWebフロントエンド寄りの構成です。 なぜこの構成になったのか、主要なコンポーネントごとの選定理由と「割り切り」について解説します。

1. Next.js + Netlify：「開発体験」と「インフラ管理ゼロ」への全振り

個人開発における最大の敵は「インフラの運用保守」です。 限られた時間の中で、サーバーの死活監視やデプロイパイプラインの構築に時間を使いたくありませんでした。 Next.js と Netlify の組み合わせは、GitHub にプッシュするだけで本番環境がデプロイされ、CDNのエッジネットワークで高速に配信されます。

また、Tabidea はSEOを考慮したランディングページやブログと、動的なアプリケーション部分が混在しています。 Next.js の App Router の機能を活用することで、静的なページは爆速で返しつつ、APIルーティングを使ってBFF的な処理も同一リポジトリで完結できる点が、初期のスピード感を出す上で決定的に重要でした。

2. Supabase：「Firebase の手軽さ」と「SQL の堅牢さ」のいいとこ取り

ユーザーの旅行プランやプロフィール情報を保存するデータベースには、Supabase（PostgreSQL）を採用しています。 最初はFirebase (Firestore) も検討しましたが、旅行プランというデータは「ユーザー」「プラン」「スポット」「経路」など、リレーショナルな構造を持ちます。NoSQLでこれを管理すると、将来的に集計や複雑なクエリが必要になった際に苦労することが目に見えていました。 Supabase は PostgreSQL という堅牢なRDBを使いながらも、Firebase のような手軽なAPIを提供してくれます。

3. OpenAI API ＋ Google Maps API：データの「生成」と「検証」の分離

Tabideaでは「AIの使用は最小限に留め、可能な限りコード側でロジックを制御する」という方針を貫いています。 Tabideaのコア機能は「AIによる旅行プランの生成」ですが、ここで重要なアーキテクチャ上の工夫があります。 LLM（OpenAI API）は、テキストを生成するのは得意ですが、「正確な位置情報」や「リアルタイムの営業時間」「正確な移動時間」を出力するのは苦手です（ハルシネーションを起こしやすい領域です）。

そのため、Tabideaでは以下のように役割を明確に分離しています。

1. LLM: ユーザーの要望に基づき、「どんなスポットを、どういう順序で回るか」の論理的な構成案だけを生成する。
2. Google Maps API: LLMが提案したスポットの正確な座標、営業時間、写真を取得し、さらにスポット間の正確な移動時間と経路を計算してUIに反映する。

このように「AIの創造性」と「外部APIの正確性」を組み合わせることで、面白くて、かつ実現可能な旅行プランを担保しています。