GMAC MEOサービス

日本語

Tiếng Việt

日本語

Tiếng Việt

Appearance

複数箇所計測（ジオグリッドランキング） ​

概要 ​

項目内容
ステータス🔵 提案中
Issue-
担当-

指定エリア内に 格子状（最大 49 点） の計測点を配置し、各点から同一キーワードで Google Places API を呼び出して順位を取得、地図上にヒートマップで可視化 する機能。MEO Dashboard byGMO 相当のサービスレベルを目指す。

項目内容
ベンチマークMEO Dashboard byGMO（公式 の「多地点順位チェック」記述に基づき：最大 49 地点 / 100m〜10km 間隔可変 / PNG + EXCEL 出力）
計測方式Google Places API (New) Text Search locationBias.circle を計測点ごとに切替
主要 KPIAGR / ATGR / SoLV（海外標準）+ 国内向け命名併記
可視化地図ヒートマップ + 集約指標 + 期間比較 + CSV/PNG エクスポート
対象MAPPY（先行）→ GCOR / PIPIT 順次
API 費用$0 維持（Field Mask places.id のみの Basic SKU）

提案内容 ​

背景・課題 ​

  • 現行 Places API 版ランキング取得は 店舗住所の 1 点 での計測のみ（4/17 第2回集計より本番稼働中）
  • Google ローカル検索は 検索者の現在地（Proximity effect）に強く依存、店舗前で 3 位でも 2km 離れると圏外、というケースが 1 点計測では見えない
  • 出張・訪問型ビジネス（清掃・配管・訪問医療など）では、顧客は店舗に来ないため、店舗住所 1 点の順位は実態と乖離
  • 先方より「マップ上で順位が視覚的に見えるように」「GMO のサービスをベンチマーク」と明示要望
  • 国内市場での多地点計測の商品化は 15〜30 ツール中およそ 3〜4 割、空白領域あり
  • GMO TECH 提供の MEO Dashboard byGMO は ITR 調査で 国内売上金額シェア 3 年連続 No.1（出典: GMO IR）。事実上の国内参照仕様

提案するソリューション ​

Google Places API の locationBias を計測点ごとに切替えて呼び出し、各点の順位を保存。マップ画面でヒートマップ表示と集約指標（AGR / ATGR / SoLV）を提供する。

主な特徴：

  • グリッド構成は 3×3 / 5×5 / 7×7 から選択可、間隔も 100m〜10km 可変（GMO の「最大 49 地点 / 100m〜10km」に合わせ、7×7 で同等点数を満たす設計）
  • 計測点ごとに locationBias.circle.center(lat,lng) + radius を動的指定
  • 1 計測点 = 1 レコードで mappy_place_search_rankings 互換のテーブル拡張
  • ヒートマップは 順位帯ごとの色分け + 数値オーバーレイ（GMO 形式踏襲）
  • 海外標準 KPI に 国内呼称を併記（例：SoLV → 「上位3位到達率」）して差別化
  • API 費用は Basic SKU ($0) を維持、コスト増はインフラ側（Fargate / DB / S3）のみ

機能一覧 ​

#機能名説明優先度
1グリッド設定 UI中心点 / N×N / 間隔（100m〜10km）/ 計測対象キーワードの選択高
2計測点座標生成中心点 + グリッド仕様から各点の (lat, lng) を算出高
3多地点 API 呼び出し計測点ごとに locationBias を切替えて Text Search 実行高
4バッチ分割7×7 構成で 6h タイムアウトを超えないよう分割実行高
5DB スキーマ拡張grid_point_id / lat / lng / grid_index 追加高
6ヒートマップ表示Google Maps 上に順位カラーピン + 数値オーバーレイ高
7集約指標表示AGR / ATGR / SoLV + 国内呼称併記高
8期間比較2 時点のヒートマップ並列表示 / 変化量サマリ中
9CSV / PNG エクスポートグリッド結果の数表 + マップ画像中
10GCP マルチプロジェクト拡張バースト制限対策で 5〜6 プロジェクト並列高
11タイムラプス GIF（拡張）期間内ヒートマップのアニメーション出力低

設計検討事項 ​

グリッド仕様 ​

グリッド計測点想定用途1 日あたり検索件数（参考）
3×39都心部・狭商圏約 25 万件
5×525標準（バランス）約 69 万件
7×749GMO 同等点数（49 地点）・広商圏約 135 万件

※ 1 日のキーワード × 店舗 × システム合計 = 約 27,656 件（4/13 実績）を N 倍した試算

locationBias の動作検証（PoC 必須事項） ​

  • Places API の locationBias は フィルタではなくヒント。指定座標から離れた結果も返りうる
  • 「ユーザが実際にその地点で検索した場合の Google Maps 順位」と完全一致する保証はない
  • 海外ツール（Local Falcon / Geogrid.dev）は UULE 付き Google SERP スクレイピング が主流。Places API 直接方式の多地点計測は 業界的に前例が少ない
  • → PoC で 3〜5 店舗 × 5〜10 キーワード × 25 点 の実測で、点ごとの順位差が妥当か（UULE 方式との一致率）を検証

処理量・所要時間試算 ​

グリッド検索件数/バッチ推定所要時間（3 GCP プロジェクト / 12 スレッド）
3×3248,904 件約 3〜4 時間
5×5691,400 件約 9〜12 時間
7×71,355,144 件約 17〜20 時間（Fargate 6h タイムアウト超過）

→ 7×7 化には以下が必須：

  1. GCP プロジェクトを 5〜6 個に拡張（QPM 3,000〜3,600 / 実効 50〜60 req/s）
  2. バッチを地域分割 or 時間帯分割（1 ジョブ ≤ 6h に収める）
  3. EventBridge トリガを多重化（例：店舗 ID レンジで 4 ジョブに分散）

DB スキーマ拡張案 ​

既存 mappy_place_search_rankings をベースに、計測点情報を持つ親テーブルとリレーション：

sql
-- 計測点グリッド設定
CREATE TABLE mappy_grid_definitions (
  id              BIGINT PRIMARY KEY AUTO_INCREMENT,
  gbp_location_id BIGINT NOT NULL,
  grid_size       TINYINT NOT NULL,                -- 3,5,7
  spacing_meters  INT NOT NULL,                    -- 100〜10000
  center_lat      DECIMAL(10,7) NOT NULL,
  center_lng      DECIMAL(10,7) NOT NULL,
  created_at      DATETIME,
  updated_at      DATETIME,
  INDEX idx_location (gbp_location_id)
);

-- 計測点ごとのランキング
CREATE TABLE mappy_grid_search_rankings (
  id              BIGINT PRIMARY KEY AUTO_INCREMENT,
  grid_def_id     BIGINT NOT NULL,
  grid_index      SMALLINT NOT NULL,               -- 0〜48 (7×7)
  point_lat       DECIMAL(10,7) NOT NULL,
  point_lng       DECIMAL(10,7) NOT NULL,
  keyword_id      BIGINT NOT NULL,
  place_id        VARCHAR(255),
  ranking         SMALLINT NOT NULL,               -- 0=圏外 / 1-60 / 997=error
  ranking_status  VARCHAR(20),
  search_at       DATETIME,
  source          VARCHAR(20) DEFAULT 'grid_api',
  INDEX idx_grid_kw (grid_def_id, keyword_id, search_at)
);

KPI 定義（海外標準 + 国内呼称） ​

略号海外定義国内呼称（案）計算
AGRAverage Grid Rank平均順位（圏内のみ）順位 1〜20 のピンの平均
ATGRAverage Total Grid Rank総平均順位全ピン平均（圏外は 21 換算）
SoLVShare of Local Voice上位 3 位到達率全ピン中 1〜3 位の割合（%）

コスト構造（月額試算） ​

試算の前提（既存実測ベース） ​

項目値
現行 1 日バッチ件数27,656 件（2026-04-13 実測）
現行 1 日所要時間約 92 分（= 1.53 時間）
Fargate 構成1 vCPU + 2 GB（既存 places_api_def）
リージョンap-northeast-1（東京）
Fargate 単価vCPU $0.05056/h + RAM $0.00553/GB-h ＝ $0.06162/h

AWS インフラ月額の増分 ​

項目1 点（現行）3×3 (9 点)5×5 (25 点)7×7 (49 点)
Fargate 実行時間/日1.5 時間約 3.5 時間約 10.5 時間約 18.5 時間
Fargate 費用/月約 $2.8約 $6.5約 $19約 $34
RDS 増分ストレージ/月
（200 B/rec × 49 倍 × 3ヶ月保持）		—+約 $0.6+約 $1.7+約 $3.3
S3 ログ/月
（DEBUG 49 倍、Lifecycle 30日でIA移行）		—+約 $0.3+約 $0.7+約 $1.5
データ転送 OUT
（Fargate → GCP）		微少+約 $1+約 $2.5+約 $4.5
AWS 月額増分合計基準+約 $8〜10+約 $24〜30+約 $43〜50

GCP（Places API）月額 ​

項目試算
Text Search IDs Only SKU 単価$0（Basic SKU = 無料）
7×7 月間リクエスト数約 4,065 万件
API 利用料$0（多地点化しても無料維持）
GCP プロジェクト追加（3 → 5〜6）$0（プロジェクト作成・API 有効化は無料）

→ GCP 側は 7×7 でも完全に $0。海外競合（Local Falcon $25〜、BrightLocal $39〜/月）と比較した大きな差別化要素。

フロントエンド：Google Maps JavaScript API ​

項目試算
Maps JavaScript API 単価$7 / 1,000 ロード（$200/月の無料クレジット込み）
無料枠内ロード数約 28,500 回/月
想定（顧客 200 社 × 月 20 回 ＝ 4,000 ロード）$0（無料枠内）
大量利用時（顧客 1,000 社 × 月 50 回 ＝ 50,000 ロード）約 $150/月（無料枠超過分）

→ 大量利用時は Embed iframe / Static Maps API / キャッシュ戦略 への切替検討が必要。

まとめ：月額追加コスト ​

グリッドAWS 増分GCPフロント合計（月額）
1 点（現行）—$0$0基準
3×3 (9 点)+約 $10$0$0〜約 ¥1,500/月
5×5 (25 点)+約 $30$0$0〜約 ¥4,500/月
7×7 (49 点)+約 $50$0$0〜約 ¥7,500/月

先方説明用ポイント

  • 上記は 顧客 1 社あたりではなく、全店舗バッチ全体での増分
  • 主要競合の月額（数千〜数万円/店舗）と比較して、インフラ側の実コストは実質ほぼ無視できる規模
  • 「API 費用 $0」「インフラ +¥7,500/月程度」で GMO 同等機能が実現可能
  • 顧客課金（例：1 店舗あたり ¥300〜500/月のオプション課金）で十分な粗利確保が見込める

不確実性・要 PoC 確認事項 ​

  1. Fargate バッチ分割時の起動オーバーヘッド（4 並列なら start/stop ×4 で +5〜10 分）
  2. RDS の I/O コスト（書き込み 49 倍時の IOPS 課金。gp3 なら影響小、io1 なら大）
  3. CloudWatch Logs ingest（DEBUG 49 倍は別途課金 $0.50/GB。ログレベル制御で抑制必須）
  4. GCP 側のレート制限で 7×7 を本当に当日中に完了できるか（現状 74% がレート待機）

既存案件・既存実装との関係 ​

  • 現行 Places API ランキング取得 を置換せず拡張。1 点計測（既存）と多地点計測（本案件）を並走
  • 既存案件 #1-2 キーワード上限拡張 と組み合わせると 1 ロケーションあたり 15 KW × 49 点 = 735 件/店舗/日 となるため、PoC 結果次第で順序調整
  • mappy_gbp_locations.data_source に新値（例：3 = grid_api）追加検討

画面モック ​

多地点順位チェック

18
--
21
20
24
18
--
24
12
18
7
20
16
18
--
16
3
3
4
20
24
14
13
2
1
3
7
20
--
14
7
2
3
18
21
18
18
14
13
16
12
--
24
18
--
14
--
24
18
1〜3 位4〜10 位11〜20 位21〜60 位圏外
※ 中心に自店舗が表示されます。斜め方向は対角線距離（約 √2 倍）になります。
集約指標
平均順位
(AGR)
12.5
総平均
(ATGR)
15.2
上位3率
(SoLV)
14%
順位一覧
#135.6580, 139.70161
#235.6580, 139.69612
#335.6625, 139.70162
#435.6535, 139.69613
#535.6535, 139.70163
#635.6580, 139.70713
#735.6625, 139.70713
#835.6535, 139.70714

GMO 実画面の参照

本モックは MEO Dashboard byGMO 公式「多地点順位チェック」 掲載のスクリーンショットを直接確認の上で作成。レイアウト構成（ヘッダー + フィルタ + マップ + 右リスト + ダウンロードボタン）と配色（5 帯：上位緑 / 中位黄 / 下位オレンジ・赤 / 圏外グレー）は GMO 実画面の観察を踏襲。順位帯の閾値（例: 1〜3 / 4〜10）は当社仕様として再設計。

画面構成（GMO 実画面準拠） ​

領域内容GMO 実画面の対応
ヘッダータイトル + ダウンロードボタン一致
フィルタ行ビジネス名 / 検索キーワード / グリッドサイズ / 間隔GMO は「ビジネス名 + キーワード」のみ。当社拡張：グリッドサイズ・間隔のフロント可変
マップ（中央）Google Maps 上に N×N ピン（順位数字入り円）、5 帯配色、中心 = 自店舗一致（49 ピン + 順位数字 + 4〜5 色グラデーション）
右パネルKPI（AGR / ATGR / SoLV）+ 順位リストGMO は順位リストのみ。当社差別化：集約 KPI を明示
マップ注記「中心に自店舗」「斜めは対角線距離（√2 倍）」一致（公式画面の注記そのまま）
ダウンロードCSV / PNG一致（GMO は EXCEL + PNG）

概算工数（AI前提） ​

体制 ​

役割人数担当内容
設計者1名要件確認 → PoC 設計 → AIに設計書作成指示 → レビュー → 製造へ指示
製造者1名ISSUEを元にAIに作成指示 → コードレビュー → テスト実施 → デプロイ

工数内訳 ​

フェーズ1：技術検証 PoC（合計 5.0 人日） ​

#作業項目AIリテイクレビュー工数（人日）担当
1要件確認・PoC 設計書2回0.5日/回1.0設計者
2locationBias 検証スクリプト実装（5×5 = 25 点）2回0.5日/回1.0製造者
33〜5 店舗 × 5〜10 キーワードで実測・データ収集1回0.5日/回1.0製造者
4結果分析（点ごとの順位差・1点 vs 多点比較・UULE 方式との突合）2回0.5日/回1.0設計者
5PoC 報告書作成・先方共有1回0.5日/回1.0設計者

フェーズ2：仕様確定・設計（合計 3.0 人日） ​

#作業項目AIリテイクレビュー工数（人日）担当
6グリッド仕様・KPI 命名・UI ワイヤー確定2回0.5日/回1.0設計者
7DB スキーマ設計（grid_definitions / grid_search_rankings）2回0.5日/回1.0設計者
8バッチ分割設計（7×7 / マルチ GCP プロジェクト構成）2回0.5日/回1.0設計者

フェーズ3：本実装・限定商用展開（合計 12.0 人日） ​

#作業項目AIリテイクレビュー工数（人日）担当
9DB マイグレーション（新 2 テーブル + source 列拡張）1回0.5日/回0.5製造者
10計測点座標生成ロジック + バッチ分割実装3回0.5日/回2.0製造者
11GCP プロジェクト 5〜6 個拡張・キー発行・環境変数整備1回0.5日/回1.0製造者
12Lambda / EventBridge 多重化（地域分割トリガ）2回0.5日/回1.0製造者
13ヒートマップ画面（Google Maps 連携・ピン描画）3回0.5日/回3.0製造者
14集約 KPI 算出 API + 画面表示2回0.5日/回1.5製造者
15CSV / PNG エクスポート1回0.5日/回1.0製造者
16結合テスト（PoC 店舗 → 限定展開）2回0.5日/回1.5製造者
17デプロイ・動作確認・運用ドキュメント1回0.5日/回0.5製造者

合計：20.0 人日（PoC 5.0 + 設計 3.0 + 実装 12.0）

前提条件・制約 ​

  • API 費用は Basic SKU（$0）維持。Field Mask に places.displayName 等を追加する場合は別途課金検討
  • 7×7 構成の実用化には GCP プロジェクト 5〜6 個 + バッチ分割 が前提
  • PoC 結果で locationBias の地点依存性が不十分 と判明した場合、UULE 方式 SERP 取得への切替 を再検討（追加 5〜8 人日）
  • 既存 #1-2 キーワード上限拡張 と並走時は処理量が乗算（15 KW × 49 点）、リリース順序を要調整
  • タイムラプス GIF（拡張機能）は本案件範囲外、後続案件で対応

先方確認事項 ​

  1. 主目的の優先順位：①商圏可視化による提案力強化 ②サービスエリア型顧客の取り込み ③既存顧客への付加価値
  2. グリッド仕様：GMO 相当の 7×7 可変距離 / 固定 5×5 から開始 / 段階移行 — どれを採るか
  3. 対象顧客：全顧客向け機能 / プラン別オプション（追加料金）
  4. リリース時期：繁忙期・決算等の制約有無
  5. PoC 対象店舗：先方側で 3〜5 店舗 × 5〜10 キーワードの選定可否

スケジュール ​

タスク担当日数5/255/265/275/285/295/305/316/16/26/36/46/56/66/76/86/96/106/116/126/136/146/156/166/176/186/196/206/216/226/23
月火水木金土日月火水木金土日月火水木金土日月火水木金土日月火
PoC設計フェーズ1 PoC1d
PoC実装(25点)フェーズ1 PoC1d
PoC実測フェーズ1 PoC1d
結果分析フェーズ1 PoC1d
PoC報告フェーズ1 PoC1d
仕様・KPI・UI確定フェーズ2 設計1d
DBスキーマ設計フェーズ2 設計1d
バッチ分割設計フェーズ2 設計1d
DBマイグレーションフェーズ3 実装1d
計測点生成・バッチ分割フェーズ3 実装2d
GCPプロジェクト拡張フェーズ3 実装1d
Lambda/EventBridgeフェーズ3 実装1d
ヒートマップ画面フェーズ3 実装3d
KPI集計API・画面フェーズ3 実装2d
CSV/PNGエクスポートフェーズ3 実装1d
結合テストフェーズ3 実装2d
デプロイ・動作確認フェーズ3 実装1d