はじめに
こんにちは、ひるげです。
「気になっているカフェの前を通り過ぎて、結局いつものチェーン店に入ってしまう」
そんな経験、ありませんか？
自分自身がこの課題を強く感じていたので、コンフォートゾーン脱出を後押しするアプリ「Roamble」を開発し、昨日Webベータ版を公開しました。
この記事では、Roambleベータ版の開発で実践した技術選定・実装・インフラ構成について紹介します。「個人開発でどう技術を選ぶか」「無料枠でどこまでできるか」に悩んでいる方の参考になれば幸いです。
Roambleとは
Roambleは、現在地周辺のスポットが提案され、実際に訪問すると経験値（XP）が貯まる...
そのループで「新しい場所への一歩」を後押しするWebアプリです。
技術構成の全体像
| カテゴリ | 技術 |
|---|---|
| フロントエンド | React (TypeScript), Vite, Tailwind CSS |
| バックエンド | Go (Gin) |
| データベース | MySQL（TiDB Cloud Starter） |
| キャッシュ | Upstash Redis |
| インフラ | Cloudflare Pages + Cloud Run（東京リージョン） |
| 外部API | Google Maps Places API |
iOS化を見据えた技術選定
Roambleは最初からiOSネイティブアプリ化を視野に入れて開発しています。そのため、技術選定でも将来の移行コストを意識しました。
フロントエンド: React（TypeScript）
最終的にはReact Nativeでネイティブ化する予定です。ReactとReact Nativeはコンポーネントの考え方が共通しているため、Web版で培ったUIロジックやカスタムフックを活かしやすくなります。react-native-web による共通化も選択肢に入ってくるため、最初からReactを選んでおくメリットは大きいです。
バックエンド: Go（Gin）
GoはAPIサーバーとして十分な実績があり、スケーラビリティにも優れています。
フロントエンドをReact Nativeに移行してもバックエンドはそのまま流用できるため、長期的な観点でも安定した選択です。
TinderライクなカードUIの実装
Roambleのコア体験の一つが、カード形式でのスポット提案です。スワイプしながらどこに行くか考えられるTinder風のUIを採用しています。
実装にあたって、こちらのZenn記事のアイデアを参考にしました。特に「カードの移動距離が閾値を超えたら次のカードに飛ばす」という判定ロジックの考え方は非常に参考になりました（コード自体は別途実装しています）。
実装のポイント：
- ドラッグ中のカード角度をリアルタイムに変化させてフィードバック
- 閾値を超えたらアニメーション付きで次カードへ遷移
Duolingoを目標にしたゲーミフィケーション設計
訪問記録の動機付けとして、ゲーミフィケーション要素を取り入れています。ここで参考にしたのがDuolingoです。
Duolingoが習慣化に優れている理由は「小さな成功体験の積み重ね」と「視覚的な進捗表現」にあると思っています。Roambleでも同じ設計思想を採用しました。
実装した要素：
- XP・レベルシステム: 訪問するたびに経験値が貯まり、レベルアップ。称号も変化
- バッジ: 「最初の一歩」「ジャンルコレクター」など、特定の条件を達成すると獲得
「怖かったけど行けた」という体験が数値として積み重なることで、次の一歩を踏み出す理由になる、そういう設計を目指しました。
まだDuolingoの足元にも及びませんが、今後もゲーミフィケーションの強化は続ける予定です。
できるだけ無料でデプロイできる環境選び
インフラ選定については、以前書いた以下の記事で詳しく解説しているので、合わせて読んでいただけると嬉しいです。
Roambleでは上記の記事内でも示した、以下の構成を採用しています。
| カテゴリ | サービス |
|---|---|
| フロントエンド | Cloudflare Pages |
| バックエンド | Cloud Run（東京リージョン） |
| DB | TiDB Cloud Starter |
| キャッシュ | Upstash Redis |
ベータ版の規模（テスター数十人）であれば、この構成で完全無料で運用できるものと考えています。
パフォーマンス改善: Render→Cloud Run移行
開発初期はバックエンドをRenderの無料枠でホストしていましたが、本番公開前にCloud Run（東京リージョン）へ切り替えました。
理由はシンプルで、Renderの無料枠はサーバーがシンガポールにあるため、日本のユーザーへのレスポンスが遅くなる点が気になっていました。
実際に同じAPIエンドポイントでTTFB（Time To First Byte）を計測したところ：
| TTFB | |
|---|---|
| Cloud Run（東京リージョン） | 226ms |
| Render（シンガポール） | 363ms |
約137msの改善。体感でもはっきりわかるレベルの差でした。
Cloud RunはDockerfileをデプロイする形式のためRenderより設定のハードルはやや高いですが、無料枠が月200万リクエストと余裕があり、東京リージョンを選べる点でRoambleには最適でした。
おわりに
Roambleはまだベータ版で、改善したいことが山積みです。ゲーミフィケーションの強化、提案のAI利用やパーソナライズ、そしてiOSネイティブアプリ化を目指しています。
ベータ版リクエストは以下から送信できます。
リクエストフォームの受付は2026年3月14日（土）に締め切る予定です。
使ってみた感想やフィードバックがあればぜひお寄せください。
以上が、Roambleベータ版の技術選定と構成の紹介になります。参考になれば幸いです！