logoChibiham
|
cover
📍

ABR-Geocoderを試す

この記事はAIを使用して執筆しています。

目的

  • ABR-geocoderでできることを確認する
  • ABR-geocoderの精度を体感する
  • セットアップと運用の注意点を確認する

ABR Geocoder 概要

公式サイト: https://lp.geocoder.address-br.digital.go.jp/

デジタル庁が提供する、日本国内の住所文字列を正規化し、緯度経度を返すジオコーディングツール。アドレス・ベース・レジストリ（全国の住所マスターデータ）をデータソースとし、政府により月次で更新されるため信頼性が高い。MITライセンスで提供され、オフライン（外部API利用なし）で動作させることができる

主な機能

  • 住所正規化: 「千代田区霞が関１−３−１」→「東京都千代田区霞が関一丁目3番1号」
  • ジオコーディング: 住所から緯度・経度を取得
  • 町字ID付与: 住所の一意識別子を返却
  • 表記ゆれ吸収: 漢数字/算用数字、旧字体/新字体などを統一

技術仕様

  • 言語: Node.js / TypeScript
  • DB: SQLite（ローカルDB、全国データで約50GB）

特徴

  • 無料: オープンソース（MIT License）
  • オフライン動作: 外部API不要
  • 高精度: 政府公式データ使用
  • 定期更新: デジタル庁が月次でデータ更新

ローカルでの起動方法

bash
# Node.js 20以上が必要
npm install -g @digital-go-jp/abr-geocoder

# データのダウンロード（全国データ）
abrg download

# 特定地域のみダウンロード（例：東京都）
abrg download -c 130001

# RESTサーバーとして起動
abrg serve start

# ポートを指定して起動（デフォルトは3000）
abrg serve start -p 8080

ダウンロードの実行について

ローカルでの実行なので、ネットワーク、実行環境にもよるだろうが、ちょうど1hほどかかった

bash
❯ abrg download --debug
download: 1:00:53.900 (h:mm:ss.mmm)

実行してみる

curlでの実行例:

bash
curl 'http://localhost:3000/geocode?address=東京都千代田区霞が関1-3-1' | jq

レスポンス:

json
{
  "query": {
    "input": "東京都千代田区霞が関1-3-1"
  },
  "result": {
    "output": "東京都千代田区霞が関一丁目3-1",
    "score": 0.82,
    "match_level": "residential_block",
    "lat": 35.671555,
    "lon": 139.751467,
    "pref": "東京都",
    "city": "千代田区",
    "oaza_cho": "霞が関",
    "chome": "一丁目",
    "blk_num": "3"
  }
}

テスト結果の要約

様々なパターンの住所でテストを実施した結果、以下の特徴が確認できた:

カテゴリ入力例処理結果
漢数字・算用数字混在六本木６-１０-１6丁目10-1に正規化
全角・半角文字１－７－１1-7-1に正規化
北海道住所北3条西6丁目条丁目形式を正しく認識
京都通り名寺町通御池上るkoazaフィールドに格納
旧字体澁谷区澁谷渋谷区渋谷に正規化
ビル名付き丸の内1-9-1 東京駅othersフィールドに格納
都道府県省略千代田区東京都を自動補完

注意点

住居番号までの完全な登録がない場合がある

千代田区1-9-1 東京駅の出力結果として、othersが-1 東京駅となる。特に大規模ビルの場合、街区番号（1-9）までしか登録されていない可能性がある。

→ ビル名、部屋番号などの抽出も完璧にはできない場合がある

スコアの傾向

入力パターンscore特徴
都道府県明記0.82-0.88高スコア
都道府県省略0.57-0.74低めのスコア
旧字体使用0.5最低値
ビル名付き0.7中程度

実運用の判定基準（目安）:

  • 0.8以上: そのまま信頼
  • 0.6〜0.8: 念のため確認推奨
  • 0.6未満: 入力の見直しを促す

ECRでABR Geocoderを使用する場合の方針

デフォルトで~/.abr-geocoderに関連ファイルが保存される。このフォルダのサイズは、全国データをdownload後で58GB程度。

bash
❯ du -sk .abr-geocoder | awk '{print $1/1024 " MiB"}'
57419.9 MiB

SQLiteとマウントファイルシステムのパフォーマンス影響

docker image build時に全国データを含んだコンテナを生成するのは現実的ではなく（ECRだとImage Layerの最大サイズ制限10GBなので実質的に無理）、ABR Geocoderは内部的にSQLiteを使用しているため、ストレージタイプの選択はパフォーマンスに直結する。

ストレージ選択による影響

ストレージタイプレスポンス時間（目安）推奨用途
EBS gp320-100ms本番環境
EFS50-500ms複数コンテナ共有時
FSx for Lustre15-80ms高性能要求時

SQLite最適化設定

bash
# SQLiteのパフォーマンスチューニング
export SQLITE_TMPDIR=/dev/shm  # メモリ上の一時ファイル
export PRAGMA_CACHE_SIZE=10000  # キャッシュサイズ増加
export PRAGMA_MMAP_SIZE=268435456  # メモリマップサイズ

デプロイ戦略（データ更新）

EBSのボリュームは単一Fargate Taskにしかアタッチできない制約あり（そもそもSQLite接続するので別にした方がよさそうではある）

以下の構成でコスト最適化 / デプロイ時間短縮化 / 可用性担保ができそう:

  • EBSスナップショットを日次バッチ処理で更新
  • スナップショットから作成したvolumeをマウントしたTaskをB/Gデプロイ

abrg update checkの実行

更新可能データの取得基準がわからないが、更新対象ファイルがあると毎回出てしまった。この時の処理時間は3.5min。

bash
❯ abrg update-check
利用可能な更新データ(3793)があります。
続けてデータをダウンロードしますか？ [Y/N]

API実行負荷テスト

直列実行で、ローカル起動したときのテスト。0.015 - 0.060s程度で実行される。あくまでローカル実行なので参考程度。

並列処理についてGitHubに言及があるため、ランタイムはNode.jsのようだがクラスター使用している可能性がある。その場合、CPU数は上げておいた方がいい可能性がある。また、memory使用量もモニタリングして決定した方がよさそう。このあたりは本格的に負荷テストを行って確認した方がよい。

まとめ

以下の構成がよさそう:

  • Fargate + EBSを使用
  • abr-geocoderのデータ更新したEBSスナップショットを作成するバッチ処理を作成
  • B/Gデプロイ。デプロイ時には、最新のスナップショットから作成したEBSボリュームを使用
    • データ更新の反映とabr-geocoder更新をデプロイで実施する