「自社のサービスやお店を、アプリにしたい」——そんな発注をご検討中の方に向けて書いています。

専門用語はできるだけ翻訳し、「どんな課題に、私たちがどう判断して、どう解決したか」を中心にお伝えします。アプリ・SaaS開発に興味のあるエンジニアの方にも、読み物として楽しんでいただける内容です。

題材は、私たちが自社で企画・開発・運営している、サウナ検索×サ活記録アプリ 「Sauna Sona（サウナソナ）」 です。2026年7月にiOSでリリースしたばかりの新しいアプリで、全国約5,500のサウナ施設に対応しています。この記事では、機能の一覧ではなく、「なぜその機能を、その形で作ったのか」という設計判断を、マーケティングの視点と技術の視点の両面からご紹介します。

📝 3行まとめ
① サウナーの体験は「探すアプリ・記録アプリ・お店ごとのサービス」に分断されている。ここに市場の余白がありました。
② Sauna Sonaは、探す → 行く → 記録する → また行くをひとつにつなぎ、ユーザーには「自分のサ活が貯まる場所」、店舗には「常連化の仕組み」を提供します。
③ この体験を低コスト・短期で立ち上げるための技術選定（iOSネイティブ＋Firebase）まで、理由ごとご紹介します。

課題の見立て ― 人気なのに、体験が“バラバラ”

サウナ・サ活の人気はすっかり定着しました。ではアプリは足りているのか——実は「足りている」のではなく、役割ごとにバラバラなのが実情です。

  • 「今日どこに行くか」を探すアプリ
  • 入ったあとの「ととのい」を記録するアプリやメモ
  • クーポンやスタンプで再訪を促す、お店ごとのLINEやカード

それぞれが別々で、自分のサ活が一か所にたまっていきません。お店から見ても、せっかく来てくれた常連さんに、次に来てもらうための接点が弱い。私たちはこの「分断」そのものを、狙うべき市場の余白だと見立てました。

Sauna Sonaが目指したのは、探すところから、訪問後の記録、そしてまた行くきっかけまでを、ひとつの体験としてつなぐことです。アプリ名の *Sona* は *Sauna*（サウナ）と *Sonar*（ソナー＝探知）を掛け合わせた造語で、「自分に合う一軒を探知する」という世界観を表しています。

💡 発注者の方へ：新しいサービスを考えるとき、私たちはまず「機能が足りない場所」ではなく「体験が途切れている場所」を探します。分断をつなぐこと自体が、そのサービスの独自性になります。

ユーザー向け機能 ― 「自分のサ活が貯まる場所」をつくる

ここが起点です。まずユーザーに使い続けてもらえなければ、後述する店舗向けの仕組みも成り立ちません。機能は、サウナ体験の時間軸（探す→行く→記録する→振り返る）に沿って設計しました。

探す — 今いる場所から、今日行ける一軒を

  • 現在地から近い順に施設を表示。一覧と地図を切り替えて探せます
  • 詳細フィルター：サウナ室・水風呂の温度、外気浴、オートロウリュ、アウフグース、食事処、Wi-Fi、駐車場、タトゥーOK など、サウナーが本当に気にする条件で絞り込み
  • 出張先・旅行先でも、地図から周辺を探せます

行く前に確認する

  • 施設詳細で、設備・営業時間・料金・口コミ・混雑状況・クーポンをまとめて確認
  • 経路案内は Apple マップ／Google マップ／Yahoo!カーナビに連携（車移動の多いサウナーの声を反映）

記録する — サウナ直後でも、こだわり派でも

  • かんたん記録：施設・日付・ととのい度・一言メモを、脱力状態でも数タップで保存
  • 詳細記録：サウナ→水風呂→外気浴をセットごとに記録。よく使う構成はテンプレートで即呼び出し、入力途中は自動下書き保存で消えにくく

振り返る — 続けたくなる“ごほうび”

  • ログブック（月間カレンダー＋タイムライン）で、通った日が色づいていきます
  • 年次まとめ（Sauna Wrapped）で、1年のサ活をカードにしてシェアできます
  • 記録はCSV/JSONでエクスポート可能。自分のデータは自分のもの、という姿勢です

「非公開が既定」という、いちばん大事な設計判断

ここが、私たちが最もこだわった一点です。多くのSNS的アプリは「公開が前提」で作られています。でもサウナーのログには、体重・体調・気分といった本音のメモが含まれます。だから Sauna Sona は、記録は既定で“自分だけに見える”ようにし、項目ごとに公開範囲を選べるようにしました。

「みんなに見せる」を前提にしないことは、機能をひとつ足すより難しい判断でした。でも、安心して本音を書ける場所であることが、記録アプリの継続率に直結すると考えました。

💡 発注者の方へ：ユーザーが本音を預けるサービスでは、「公開が既定か、非公開が既定か」という初期設定ひとつが信頼を左右します。これは技術ではなく姿勢の設計です。

店舗向け機能 ― 「来てくれた人に、もう一度」を仕組みにする

ユーザーの体験が回り始めたら、次はマネタイズです。ここでも発想は集客一辺倒ではありません。新規を集め続けるより、来てくれた人にもう一度来てもらう「常連化」に軸足を置きました。これを月額制の 「店舗プラン（¥4,800／月・税別）」 として提供しています。

  • フォロー（お気に入り）＋本日のロウリュ自動通知 … フォローしてくれた人へ、その日のロウリュ／アウフグース情報を毎朝自動でプッシュ通知。「今日行く理由」を手元に届けます
  • お知らせ配信・クーポン … フォロワーへ直接届く告知。SNSのように流れて消えません
  • チェックイン＆スタンプカード … 通うほど貯まるスタンプで、再来店の動機を“見える化”
  • 現在地の混雑状況 … 店舗だけが答えられる情報を機能に（これは無料で開放）
  • 施設プロフィール編集（紹介文・写真ギャラリー・定休日・駐車場など）も無料
  • 来店分析 … 常連・休眠・初回といった状態を、お店が把握できます

なぜ「混雑状況」と「プロフィール編集」を無料にしたのか

有料機能を並べる中で、この2つはあえて無料にしました。理由は、お店にとって“最初の一歩”のハードルを下げるためです。無料でも施設情報が充実し、混雑を発信できれば、ユーザーの利便性が上がる＝アプリの価値が上がる。そのうえで「もっと集客したい」お店が有料プランに進む、という順番を設計しました。集客のフックは無料で、常連化の仕組みで課金する——これが店舗プランの骨格です。

💡 発注者の方へ：「どこまで無料で、どこから有料か」の線引きは、料金表の問題ではなく成長設計です。無料機能はユーザー価値とサービスの入口を、有料機能は継続課金の理由を担うよう、役割で分けて設計します。

スタンプの不正を「機能」ではなく「設計」で防いだ話

常連化の要になるスタンプカード。ここで一番の論点は不正防止でした。よくある「自分でチェックインボタンを押すだけ」の方式だと、来ていなくてもスタンプが貯まってしまいます。

私たちの判断はこうです。貯める側にだけ、鍵をかける。

  • 貯めるときは、スタッフが客の端末に4桁のキーワードを入力して初めて+1。コードは公開せず、誤入力が続けばロックされ、1営業日1回まで。
  • 使う（特典と引き換える）ときは、コード不要・アプリ操作だけ。理由はシンプルで、「使う＝自分が正当に貯めた残高を減らすだけ」なので、そもそも不正が起きようがないからです。

“両側をガチガチに固める”のではなく、リスクのある側（貯める）にだけ手当てし、リスクのない側（使う）は徹底的に手軽にする。この非対称な設計が、お店の運用負担とユーザーの手間を同時に軽くしました。

💡 発注者の方へ：不正対策は「全部を厳しくする」と現場が回らなくなります。どこにリスクが集中しているかを見極めて、そこだけ締めるのが、使われる仕組みのコツです。

プライバシーを“設計”で守る

来店を記録すれば常連化に使えますが、そこには必ず「お客様の情報を、お店にどこまで渡すか」という論点がついて回ります。

Sauna Sona では、店舗に見せるのは 「常連が何人」「しばらく来ていない人が何人」といった集計値が中心で、個人を名指しで並べることを目的にはしていません。必要な“示唆”だけを取り出し、リスクの高い個人情報は持ちすぎない——これは、お客様の信頼を預かるあらゆるサービスに共通する勘所です。

技術の裏側 ― なぜ「iOSネイティブ × Firebase」で軽く作ったか

ここから少しだけ技術の話を。とはいえ大事なのは用語ではなく、「なぜその選択が、体験・コスト・スピードに効くのか」なので、その視点で書きます。

iOSネイティブ（SwiftUI）にした理由 ＝ 体験のため

Sauna Sona はまずiOSネイティブで作りました。理由は明確で、サウナ直後の脱力した状態でも、地図がぬるぬる動き、数タップで記録できる軽快さが、このアプリの生命線だからです。全国5,500件超のピンを地図に出すために、マーカーは軽量にしてクラスタリング（近いピンをまとめる）で表示し、快適さを優先しました。「まずWebで」ではなく「まず一番使う画面を最高に」を選んだ判断です。

バックエンドは Firebase ＝ お金とスピードのため

データの保管・通知・集計を担う“サーバー側”は、Firebase（Googleのクラウド基盤）の上に作りました。最初からフル自作のサーバーは組んでいません。

  • 会員登録・データベース・プッシュ通知という「どのアプリでも必要な土台」は、自前で作らず借りる。これだけで初期の開発期間と費用を大きく圧縮できます。
  • 「フォロワーにだけロウリュ通知を送る」「来店を記録してスタンプを加算する」といった、このサービスの価値そのものにあたる部分だけを、サーバー側の小さなプログラム（Cloud Functions）で作り込みました。
  • 課金まわりは Stripe に任せ、自前実装の事故リスクを避けています。

これは技術自慢ではなく、「当たるか分からないサービスを、最初から重く作りすぎない」という提案です。まず軽く・速く出して、伸びる部分が見えてから作り込む——この順番をおすすめしています。

「データはキャッシュしない」という割り切り

もうひとつ、地味だけれど効いている判断があります。Sauna Sona は施設データを端末にため込まず、常にサーバーから最新を読む設計にしました。サウナは営業時間・料金・設備が変わりやすく、古い情報を見せてユーザーががっかりするのが一番避けたいこと。「速さのためのキャッシュ」より「正しさ」を優先し、データの正しさはFirebase一箇所に集約しました。

💡 発注者の方へ：技術選定は「流行っているか」ではなく「その事業のどこにお金と時間を使うべきか」で決めるものです。土台は借りて、価値の中心にだけ投資する。私たちはこの順番を、設計の最初からご提案します。

拡張しやすさも“設計”しておく

サウナの検索条件は、これからも増えます（新しい設備、新しいトレンド）。そこで絞り込み機能は、条件を1行足すだけで増やせる構造にしてあります。「あとから育てられる」ことを前提に骨格を作っておくと、リリース後の改善が速く・安くなります。作って終わりではなく、運用しながら伸ばせる形にしておくのも、私たちが大事にしている設計です。

私たちが提供できること

Sauna Sona の企画・開発・運営を通じて、私たちはこんなことが得意になりました。

  • 「体験が途切れている場所」から発想する企画・要件定義（探す×記録×常連化のような一体型設計）
  • OMOの設計（来店前・来店中・来店後を、ひとつの体験としてつなぐ）／店舗向けアプリ・SaaS
  • iOSネイティブアプリの開発（地図・記録など、体験の軽快さが要になるプロダクト）
  • Firebaseを使った、低コスト・短期で立ち上げるバックエンド構築、プッシュ通知・スタンプ／ポイントなどのリピート施策の実装
  • プライバシー配慮・不正対策を“設計”で解くアプローチ（個人情報を持ちすぎない／リスクの集中点だけ締める）

「アプリで集客したい」「店舗の業務や常連化をアプリ・SaaSで仕組み化したい」「でも何から作ればいいか分からない」——そのご相談の段階こそ歓迎です。“全部入りで重いアプリ”ではなく、“目的に効いて、続けられるアプリ”を一緒に作りましょう。