住所を緯度経度に変換する（国土地理院ジオコーディング）
住所を座標に変換できると、地図表示やデータの空間結合がぐっと楽になります。政府データの多くは緯度経度を入口に取るため、「住所しかない手元のデータ」を座標化しておくと、災害リスクや統計との突き合わせが一気に進みます。逆に、座標から住所を求められれば、GPSログや写真の位置情報に地名を付けて集計する、といった分析も開けます。このガイドでは、国土地理院のデータを使った無料（キー不要）のジオコーディング／逆ジオコーディングの手順と、表記ゆれや測地系といったつまずきやすい点、大量変換を安定させる設計、他の政府データへの橋渡しの仕方までまとめました。
ジオコーディングと逆ジオコーディング
住所・地名から緯度経度を求めるのがジオコーディング、緯度経度から住所を求めるのが逆ジオコーディングです。前者は地図ピンの配置やエリア集計の前処理に、後者はGPSログや写真の位置情報に地名を付ける用途に使います。多くの防災・地理空間APIが座標を入口に取るため、この変換は政府データ活用の下ごしらえとして頻出します。
国土地理院のデータは無料（キー不要）で利用でき、すぐに試せます。まとめて変換する際はレート制限に配慮し、表記ゆれによる候補の取り違えに注意します。1件変換して終わりではなく、大量のリストを回すことを想定して、前処理とキャッシュを設計しておくのがコツです。とくに実データは住所の書き方が一定でないため、前処理の作り込みが変換成功率を左右します。
取得の具体例（パラメータの渡し方）
ジオコーディングは gsi_geocode に address（住所文字列）を渡すだけです。「東京都千代田区霞が関1-3-1」のように渡すと、対応する緯度経度が返ります。番地まで一致しないときは、より粗い住所（町丁目まで）に落として再試行すると当たることがあります。ヒットしない住所は段階的に粗くしていく、という再試行ロジックを組んでおくと一致率が上がります。
逆ジオコーディングは gsi_reverse_geocode に lat / lon を渡します。GPSログやセンサーの座標から、それがどの市区町村・町丁目かを引き当てるのに使います。地図をクリックした地点の住所を表示する、といったUIにも向きます。座標の精度が粗いと隣接エリアの地名を返すことがあるため、入力座標の精度も意識してください。境界付近の座標は特に取り違えが起きやすいので、重要な判定には使わず参考にとどめるのが無難です。
他の政府データと突き合わせるときは、逆ジオコーディングで得た地名から自治体コードを推定し、e-Stat 等の地域コードに橋渡しする、という連携が定番です。座標→行政区画→統計、の順でつなぐと、位置情報を起点にした空間分析の下地ができます。逆に、統計側の住所を座標化してハザード系ツールに渡す、という向きの連携もよく使います。
よくあるつまずき
住所の表記ゆれが最大の難所です。丁目・番地のハイフン表記、ビル名や部屋番号の混在、旧字体・異体字などがあると一致率が下がります。前処理でビル名以下を除去し、全角・半角や漢数字・算用数字を統一してから渡すと精度が上がります。実データはこの前処理の質で結果が大きく変わります。
同名地名や候補が複数ある場合の取り違えにも注意します。似た住所が複数あると意図しない座標が返ることがあるため、重要な用途では返ってきた住所文字列を元の入力と突き合わせて検証してください。番地レベルの完全一致が取れたか、町丁目止まりだったかを記録しておくと、後から精度を評価できます。
大量変換ではレート制限を守り、結果をキャッシュして再変換を避けます。また、座標の測地系（日本測地系／世界測地系）を混在させると数百メートルずれることがあるため、扱う座標系を統一してください。地図表示や他データとの結合で位置がずれる場合、測地系の不一致を疑うと早く原因にたどり着けます。
分析ユースケースと関連ツールの使い分け
①住所リストの地図化：顧客・拠点・店舗の住所一覧を gsi_geocode で座標化すれば、地図上にピンを打つ、エリア別に集計する、商圏を描く、といった可視化ができます。営業エリア分析や店舗網の把握に直結します。座標化さえ済めば、以降の空間処理は一気に楽になります。
②ハザード連携：座標化した地点を、地震ハザードや地質のツール（別ガイド参照）に渡すと、住所ごとの災害リスクを一括評価できます。gsi_geocode が座標を作り、jshis_hazard / geology_at_point がリスクを返す、という連携で、物件選びや拠点のリスク台帳づくりに使えます。
③GPSログの地名付け：gsi_reverse_geocode で移動ログや写真の位置情報に地名を付与すると、行動範囲の集計や地域別レポートが作れます。ジオコーディング（住所→座標）と逆ジオコーディング（座標→住所）は入口と出口が逆なので、手元のデータが住所か座標かで使い分けてください。
大量変換を安定させる設計
1件2件の変換なら気にならなくても、数千件の住所リストを回すとなると、設計次第で成功率も速度も大きく変わります。まず入力側で正規化を徹底します。全角・半角、漢数字と算用数字、丁目・番地のハイフン表記を統一し、ビル名や部屋番号など座標に関係しない部分を除去してから gsi_geocode に渡すと、一致率が目に見えて上がります。
変換結果はキャッシュし、同じ住所を二度変換しないようにします。ヒットしなかった住所は、町丁目まで粗くして再試行する段階的リトライを用意すると、番地不一致による取りこぼしを救えます。レート制限を意識して、一定間隔で呼び出す・失敗時にバックオフする、といった配慮も入れておくと、大量処理でも安定します。
最後に品質チェックを挟みます。返ってきた住所文字列を元の入力と突き合わせ、番地まで一致したか、町丁目止まりだったかを記録しておくと、後から変換精度を評価でき、要修正の住所を洗い出せます。一致度を数値やフラグで持っておけば、精度が低い住所だけを人手で確認する、といった運用も組めます。測地系（日本測地系／世界測地系）を統一しておくことも、他データと結合した際の位置ずれを防ぐ基本で、扱う座標系を最初に一つに決めておくと後々のトラブルを避けられます。
実際に叩いてみる（国土地理院・登録不要）
住所や地名を渡すとGeoJSONで候補が返ります。注意点として、これはあいまい検索のため一致度の低い候補も混ざって返ります（下の実例では『東京駅』に対して先頭に無関係な地名が返っています）。先頭を鵜呑みにせず、properties.title を突き合わせて絞り込むのが実装のコツです。座標は [経度, 緯度] の順であることにも注意します。
curl -s "https://msearch.gsi.go.jp/address-search/AddressSearch?q=東京駅"
# 実際のレスポンス（先頭1件・GeoJSON Feature。あいまい一致のため要注意）
{
"geometry": { "type": "Point", "coordinates": [141.363617, 43.076111] },
"type": "Feature",
"properties": { "addressCode": "", "title": "北海道札幌市東区" }
}出典
元システムエンジニア。Web系アプリ開発6年＋ソリューション9年、IT実務およそ15年。個人開発者として、政府オープンデータや各府省のAPIを実際に叩いて検証し、「何が取れるか」「実装時にどこで詰まるか」「どう活用するか」を一次検証にもとづいて記録しています。
運営者・検証方針について →