海外ゲームの名称と製品情報

海外店舗の追加は住所入力だけでは終わらない。同じゲームも国によって名称が違い、メーカーやバージョン分類も合わせる必要がある。2025年後半の海外展開で、この違いが共通の検索とフィルターに影響し始めた。公式ページの名前をそのまま写すと、同じ製品を別々に扱いかねないためだ。

初期情報をすべて手入力せず、メーカーと筐体の公式サイトを読むPython収集プログラムを作った。必要な項目を抽出し、サービスの形式にそろえてバックエンドへ入れる。異なる資料を共通形式へ合わせる処理を正規化という。公式情報の収集と、同じ製品を識別する方法を一緒に準備した。

flowchart TD
    accTitle: 公式資料から参照データまで
    accDescr: 公式の筐体・メーカーページから必要なフィールドを抽出し、正規化して参照テーブルに取り込む。
    S[公式の筐体・メーカーページ] --> E[必要なフィールドを抽出]
    E --> N[共通構造に正規化]
    N --> I[別工程で取り込み]
    I --> R[メーカー・シリーズ・バージョン]

収集資料と共通参照データ

メーカー、シリーズ、バージョンは一店舗だけの情報ではない。複数店舗が使う参照データである。画面の条件分岐に埋め込むと名称修正でコードも変わるため、別の取り込み段階でgame_manufacturer、game_series、game_series_versionへ結び付けた。

国別名称と、世界共通または地域限定の表示範囲もこの段階で保存する。例えば現地名が違っても同じ製品なら関係を維持し、国に合う表示名を選ぶ。画面が元ページを再解釈したり、名称差だけでシリーズを重複作成したりしないためだ。

flowchart TD
    accTitle: 共通の識別と地域別表示
    accDescr: 共通の製品とバージョンに国別名称や表示範囲を持たせ、国別の参照で利用する。
    P[共通の製品とバージョン] --> N[国別の表示名]
    P --> V[グローバル・地域別の表示範囲]
    N --> Q[国別の参照と画面]
    V --> Q

正規化と繰り返し可能な取り込み

収集プログラムは必要項目を選び、製品とバージョンの構造へ合わせる。原文を残せば出典の表現は保持できるが、サービスの項目と関係が完成するわけではない。名称やバージョンの対応先を決める正規化が必要になる。

同じ資料を再投入しても重複しないよう、取り込みは冪等にする。冪等とは同じ入力を繰り返しても同じ結果になる性質だ。資料準備を取得ロジックとは独立して実行できるが、繰り返しが安定しても原資料の正しさまでは保証しない。

flowchart TD
    accTitle: 繰り返し取り込みと現地の事実
    accDescr: 同じ入力を繰り返し取り込んでも同じ参照結果となり、実際の店舗への設置は別途確認する。
    S[同じ公式資料] --> I[冪等な取り込み]
    I --> R[同じ参照データ]
    R --> A[店舗への設置を関連付ける候補]
    A --> C[現地の設置状況を別途確認]

初期資料の活用と設置確認

海外筐体とバージョンの初期資料を手入力だけに頼らず用意できた。国別表示と参照関係で設置ゲームを結び、当時の東南アジア約300〜400店舗の初期資料を準備する基盤にもなった。この数値はその時点の初期収集範囲である。

公式サイトにバージョンがあっても、どの店舗に設置されているかまでは分からない。実際の設置と営業状態は現地資料で確認する必要がある。収集プログラムは製品参照の出発点を作り、利用者が後から現況を確認して直す資料として提供する。

参考：エンジニアリング記録。