韓国でAlphaを公開した後、店舗情報の修正依頼が一日に約20件以上届くようになった。内容を読んで保存値を直接直す方式では、依頼が増えるほど管理者の入力も増える。店舗も150か所を超え、ゲームと地域による絞り込みが必要になってきた。

9月2日のBetaは、この状況に対応してFirebaseからPocketBaseへ移す更新である。保存先を選ぶ前に、データをどう分け、管理画面からどう更新するかを一緒に検討した。

修正依頼とデータ構造の拡大

入力フォームがあっても、依頼が自由文なら管理者が意味を読み、反映する項目を探す必要がある。依頼が増えたときに速く処理するには、入力道具と資料の構造をともに整える必要があった。

例えばゲームのシリーズとそのバージョンを同じ概念で扱うと、シリーズで探す際にも版ごとの情報を照合し直すことになる。従来のモデルはこの区分が十分ではなかった。ゲームと地域の条件を提供するには、保存時点でも情報を分ける必要がある。

flowchart TD
    accTitle: 移行を求めた二つの問題
    accDescr: 増えた依頼と検索条件が、手動反映と従来構造の限界を示した。
    A["修正依頼と店舗の増加"] --> B
    B["手動反映とモデル管理の負担"] --> C
    C["関係とAPIの再構成"]

初期入力フォームの原本キャプチャ。データモデルを整理していた当時の入力単位を示す。 韓国語の原画面。当時のAlphaは韓国語のみ対応。

PocketBaseの機能と選択理由

7月からREST APIとSQLデータベースを調べた。REST APIはアドレスと要求方式でデータを読み書きする窓口で、SQLデータベースは構造化した資料を検索する基盤である。認証や管理ツールまで自作すると、移行の範囲は大きくなる。

PocketBaseはSQLiteに認証、REST API、SDKを組み合わせている。SDKはプログラムからAPIを利用する道具だ。関係の整理と管理者編集をつなぐ構成として適していると考えた。シリーズと版のように用途が異なる情報も分けて保存するよう整理した。

flowchart TD
    accTitle: PocketBaseの選択基準
    accDescr: 正規化した保存構造と認証・REST API・SDKを併用する。
    A["SQLiteを基盤に関係を整理"] --> B
    B["認証・REST・SDK"] --> C
    C["管理者編集への接続"]

管理者編集とBetaの探索機能

8月にはFirebase用の管理フォームをPocketBase SDKの要求へ移した。AlphaにもFirebaseへ送信する機能はあったが、今回は整理した関係に沿って項目を更新する。ログインは管理者編集を前提とし、一般利用者のアカウントまで導入したものではない。

このデータで検索、高度なゲームフィルター、広域地域と都市のフィルターを提供する。選択は次回も保持し、ホーム一覧の表示も調整できる。情報提供は別のページへ移る代わりに、表示中の情報のそばでインライン送信できるようにした。

flowchart TD
    accTitle: Betaの読み取りと書き込み
    accDescr: 利用者は条件を絞り、管理者はSDKで更新するが、確認は引き続き必要。
    A["検索・ゲーム・地域フィルター"] --> B
    B["構造化した修正依頼"] --> C
    C["管理者がSDKで反映"] --> D
    D["変更の確認"]

直接更新後の確認と復元

管理者は編集画面から値を更新し、利用者は条件で候補を絞れるようになった。ゲームや地域を探す作業が、店舗の説明を一件ずつ読む方法だけに依存しなくなる。

ただし不適切な変更を元へ戻す機能はまだない。管理者は更新を継続して確認する必要があり、約二日間アクセスしないと認証セッションが消える問題も残る。更新が簡単になった分、誰が何を変えたか確認し、復元する方法を用意する必要がある。

参考：Musecatの開発記録。