近くのゲームセンターを数件見るために、すべての店舗情報を先に受け取る必要があるだろうか。件数の少ない初期には、ブラウザーで距離を計算する方式も使えた。しかし韓国から始まったMusecatが今年後半に海外へ広がるにつれ、全件を取得してから近い場所を選ぶ方法を維持しにくくなった。

全件ダウンロードと初回表示

ホーム画面は全店舗を取得し、利用者との距離を計算していた。200件を超えて負担が増え、300件に近づくと初回画面で使わない資料も多く転送された。検索用と距離計算用の一覧は別APIであり、似た資料を二度受け取る場合もあった。

Deltaで使われた2025年7月1日の旧Gamma-Webソースの再現と合成データ。サーバー移行前のホーム画面。当時の日本語ルート。旧クライアントではデモ用翻訳と案内され、一部のラベルとサンプルデータは韓国語のままである。

昨年キーワード検索はサーバーへ移したが、ホームの距離計算には全件が必要だった。今年は初回表示が3秒を超え、約5秒までかかる問題が出た。例えばソウル周辺の検索にも遠方の店舗情報が必要だったのである。海外店舗を追加するほど、その準備段階から長くなる構造だった。

flowchart TD
    accTitle: ブラウザー側の距離計算
    accDescr: 一覧全体を取得してから、ブラウザーが距離と順序を計算していた。
    A["全店舗一覧"] --> B
    B["ブラウザーで取得"] --> C
    C["距離計算と並べ替え"] --> D
    D["近い場所を表示"]

サーバーでの距離計算と検索条件

周辺検索では、基準となる位置と条件が先に決まる。そこでブラウザーがそれらを送り、サーバーが距離計算、絞り込み、並べ替えを終えて結果を返す方式に変えた。画面には選択条件に合う店舗だけを渡す。

DBの変更は別途検討できるが、保存先を変えるだけでは全件取得の必要は残る。今回はその依存を先に減らした。キーワード検索が検索語を送って結果を得るように、周辺検索も位置と条件を使って問い合わせる方式にそろえた。

flowchart TD
    accTitle: サーバーへ移した周辺検索
    accDescr: ブラウザーが位置と条件を送ると、サーバーが結果を選んで返す。
    A["探索位置と条件"] --> B
    B["サーバーの距離計算とフィルター"] --> C
    C["並べ替えた関連結果"] --> D
    D["画面表示"]

検索位置と結果の範囲

サーバーは検索座標と各店舗の距離を計算し、条件に合う候補を近い順に整理する。ブラウザーは返された結果を表示する。全資料を取得してから同じ計算を始める工程がなくなり、必要な結果を直接受け取れる。

検索位置は探索の基準点である。現在地も、これから訪れる地域も指定できる。例えば旅行先の都市を基準にした距離は、現在の自分からの距離ではない。基準を明確にして結果を読めるようにし、検索位置を送っただけで実際の訪問を認証したとも扱わない。

flowchart TD
    accTitle: 計算場所を移した結果
    accDescr: 全件転送を減らす代わりに、サーバーの計算と更新を管理する。
    A["全件転送への依存を除去"] --> B
    B["必要な結果だけ取得"] --> C
    C["サーバー計算とデータ更新の管理"]

転送量とサーバーの処理費用

近くの数件を表示するために、DB全体を送る必要はなくなった。店舗が増えても受信資料を関連結果へ絞れ、距離計算と絞り込みと並べ替えもサーバーに集まる。海外展開のたびに全件一覧の転送を大きくする方式を避けられた。

一方、処理を移した分、リクエストが増えれば候補選択と距離計算の負担はサーバーへ集まる。店舗修正が結果へ反映される時点も管理が必要だ。まず全件を受け取らなければ画面を作れなかった構造を変え、残る費用は実際の要求と使用量を見て確認する方針である。

参考：周辺検索と読み込み構造。