天翔ポータルと電車アプリの開発を進める中、6月14日は少し違う頭の使い方をした日だった。「カフェの空席を予測するサービスは作れないか」という思いつきを、実際に調査・設計してみた記録。
Contents
やったこと
最初に、似たサービスがすでにあるか調べた。これを最初にやる理由は、個人開発で一番怖いのは「半年かけて作ったら大企業が同じものを無料で出していた」というパターンだからだ。先に競合を知れば、最初から「彼らがやらない一点」に絞って作れる。
調べると3タイプに分かれていた。1つ目は店舗にセンサーやカメラを置いて空席状況をリアルタイム表示する最大手のセンサー型サービス。2つ目はユーザー同士で混雑状況をシェアするクラウドソース型アプリ。3つ目はGoogleマップの「混雑する時間帯」のような、過去の位置情報からの統計推定。
ここで電車アプリと全く同じ壁にぶつかった。個人開発者は店内にセンサーを置けない。リアルタイムの絶対データには手が届かない。電車アプリで「列車位置のライセンス制限」にぶつかったのと同じ構造だ。
解決の方向も電車アプリと同じだった。「絶対値（今何席空いているか）は当てにいかず、相対比較（A店とB店、どっちが空いてそうか）だけ答える」に振り切れば、センサーなしでも成立する。
ロジック案として、「店内滞在客数 ≒ 入店レート（時間帯）× 平均滞在時間 − 退店レート」という式を考えた。電車アプリの「ホーム滞留 ≒ 到着レート × 前列車からの経過時間」とほぼ同じ構造の式だ。混雑スコアには時間帯・立地・天候の係数をかけ、LLMには数値の計算をさせず、出た数値を言葉に変換する役割だけ任せる——ここも電車アプリの「計算は数式、言葉はAI」という鉄則をそのまま流用した。
データの入手元も調べた。一番欲しいGoogleの混雑データは、実は公式のPlaces APIには含まれていないという発見があった。代わりに使えそうなのは「BestTime API」で、店舗の混雑を0〜100%のピーク比で返す仕組みだった。これも「絶対値ではなく相対比較」という発想と相性が良い。
気づいたこと
一番の気づきは、電車という全く違うドメインで得た設計思想——「データの壁にぶつかったら、絶対値を諦めて相対比較に振り切る」——が、カフェの空席予測にもそのまま転用できたことだ。これは単発のアイデアではなく、自分の中に再利用可能な「型」が育ってきている証拠だと感じた。今すぐ実装に進む段階ではないが、引き出しの中に置いておく価値のある検討だった。
新規事業検討 / データ分析 / API調査
このブログでは、ローカルLLM・Aider・個人開発の試行錯誤をそのまま記録しています。
