と聞くと「無料で使える地図」を思い浮かべる方が多いのですが、実務で効いてくるのはそこではありません。OSM の本質は、世界中の地物が構造化されて入っている巨大なデータベースであることです。この記事では、地図を描く話ではなく、データとして取り出して自社データと繋ぐ側面を扱います。
1. OSM は地図ではなくデータベース
見慣れた OSM の地図画面は、データベースの中身を描画した結果のひとつにすぎません。裏側には「この座標に、名前が○○で、種別がコンビニで、営業時間がこうで」という属性付きの構造化データが入っています。地図として眺めるのではなく、問い合わせて取り出す対象として捉え直すと、使い道が大きく広がります。
| 要素 | 意味 | 例 |
|---|---|---|
| node（点） | 1 つの座標を持つ点 | コンビニ、バス停、信号、木 |
| way（線・面） | node を順に繋いだもの。閉じると面になる | 道路、川、建物の輪郭 |
| relation（関係） | 複数の要素をまとめたもの | バス路線、行政界、複数棟の施設 |
| tag（タグ） | 上記に付く `キー=値` の属性 | `amenity=cafe`、`name=○○店` |
すべての意味はタグが担っています。「これは店だ」「これは高速道路だ」という情報は、形状ではなくタグに書かれている。したがって OSM を使いこなすとは、タグ体系に慣れることとほぼ同義です。
2. Overpass API で取り出す
が、データとしての取り出し口です。範囲と条件を指定して、必要な地物だけを取得できます。まずは動く例から。
# bbox は (南緯, 西経, 北緯, 東経) の順。ここでは小さめの範囲を指定するcurl -s https://overpass-api.de/api/interpreter \ --data-urlencode 'data=[out:json][timeout:25];( node["shop"="convenience"](35.68,139.75,35.69,139.77); way["shop"="convenience"](35.68,139.75,35.69,139.77););out center tags;' | head -60
# 使い方のポイント# - [out:json] JSON で受け取る# - node / way 点と面の両方を拾う（店舗は建物として登録される場合もある）# - out center way に対して中心座標を返させる（点として扱いたいとき）# - timeout 共有サーバなので必ず短めに指定するOverpass API は有志が運営する共有サーバです。全国規模の取得をループで叩くような使い方は避けてください。広範囲・大量が必要なら、地域単位の抽出データ（`.osm.pbf`）をダウンロードして手元で処理するのが正しい作法です。API は「探索と小規模取得の道具」と位置づけると迷いません。
3. タグ体系をどう探るか
最初にぶつかるのが「欲しいものがどのタグで表現されているか分からない」という壁です。カフェは `amenity=cafe` ですが、コンビニは `shop=convenience`。同じ「店」でも `amenity` と `shop` に分かれています。この体系は歴史的経緯で決まっており、規則から演繹するのは無理です。
- 公式 Wiki で調べる: タグごとに用法と件数が載っている。まずここ
- 実データから逆引きする: 知っている場所を範囲指定で取得し、実際に付いているタグを見る。これが一番速い
- 表記揺れを前提にする: 同じ意味に複数のタグが使われていることがある。`shop=convenience` と `amenity=convenience` の両方を拾う、といった保険が要る
- `name` に頼らない: 支店名の書き方は投稿者によってばらつく。名寄せは 前処理シリーズ EP.06 の領域
実務では、「まず小さい範囲で取ってタグを眺める」→「条件を確定する」→「本番の範囲で取る」という3段構えが確実です。いきなり広範囲で取ると、条件の誤りに気づくのが遅れます。
4. ライセンス（ODbL）の実務的な意味
ここを飛ばして本番投入するのが最も危険です。OSM のデータは で提供されています。要点は2つ、出典表示と、派生データベースを配布する場合の同一条件公開です。
| 使い方 | 主に問題になる点 | 実務での目安 |
|---|---|---|
| 地図を画面に表示する | 出典表示 | 表示すれば概ね足りる |
| 社内分析に使う | 配布が発生しない | 内部利用は比較的シンプル |
| OSM 由来の属性を足したデータを社外へ配布 | 同一条件公開の要求が及びうる | 法務確認が必須 |
| 製品にデータを組み込んで販売 | 同上 | 法務確認が必須 |
地図として見せるだけの利用と、OSM のデータを自社データに混ぜて外部に渡す利用では、求められることが変わります。この記事は法的助言ではないので、社外配布や製品組み込みを検討する段階で必ず法務に相談してください。逆に言えば、社内の分析用途に限れば導入のハードルはかなり低いということでもあります。
5. 自社データと繋ぐ
OSM の価値が最も出るのが です。共通のキーがなくても、緯度経度さえあれば繋がります。「自社店舗の半径 500m 以内にある競合の数」「配送先が属する行政区」といった問いが、キー設計なしで答えられるようになります。
import math
# 自社拠点（緯度, 経度）STORES = [ {"name": "A店", "lat": 35.6812, "lon": 139.7671}, {"name": "B店", "lat": 35.6895, "lon": 139.6917},]
# Overpass API から取得した地物（ここでは取得済みとして直書き）POIS = [ {"name": "競合1", "lat": 35.6820, "lon": 139.7660}, {"name": "競合2", "lat": 35.6790, "lon": 139.7700}, {"name": "競合3", "lat": 35.6900, "lon": 139.6930},]
def haversine_m(lat1, lon1, lat2, lon2): """2点間の距離をメートルで返す（地球を球とみなす近似）""" r = 6371000.0 p1, p2 = math.radians(lat1), math.radians(lat2) dp = math.radians(lat2 - lat1) dl = math.radians(lon2 - lon1) a = math.sin(dp / 2) ** 2 + math.cos(p1) * math.cos(p2) * math.sin(dl / 2) ** 2 return 2 * r * math.asin(math.sqrt(a))
RADIUS_M = 500for store in STORES: near = [ p for p in POIS if haversine_m(store["lat"], store["lon"], p["lat"], p["lon"]) <= RADIUS_M ] names = "、".join(p["name"] for p in near) or "なし" print(f"{store['name']}: 半径{RADIUS_M}m以内に {len(near)}件（{names}）")面との判定（行政区に含まれるか等）まで行う場合は、地理情報を扱う専用ライブラリを使う方が確実です。その際に必ず確認すべきなのが次章の話です。
6. 座標参照系という落とし穴
地理データで最も多い事故が の不一致です。同じ「緯度経度」でも、どの基準で測った値かが違うと、重ねたときに数百メートル単位でずれます。しかもエラーにはならず、静かにずれるのが厄介です。
- OSM は世界測地系（WGS84 / EPSG:4326）。まずこれを基準に考える
- 日本の公的データは別の系のことがある。取り込み時に必ず確認する
- 距離を測るなら投影が要る: 緯度経度のまま引き算した「距離」は意味を持たない。上のコードで球面距離を使っているのはそのため
- ずれに気づく方法: 既知の地点（駅など）を重ねて目視する。数字だけ見ていると気づけない
7. 何に使えるか
共通しているのは「自社データだけでは分からない周辺の文脈」を足しているという点です。売上データは自社にありますが、その店の周りに何があるかは自社にありません。そこを埋めるのが OSM の役割です。
8. 落とし穴
- 網羅率を測らずに使う: 地域差が大きい。知っている地域で答え合わせしてから本番に使う
- タグを推測で決める: 体系は歴史的経緯で決まっている。実データを見て確定する
- 表記揺れを想定しない: 同義のタグが複数あることがある
- Overpass を大量に叩く: 共有インフラ。広範囲なら抽出データを落として手元で処理
- を確認しない: 静かにずれる。エラーは出ない
- 鮮度を過信する: 有志による更新なので、閉店・新規開店の反映は一様ではない
- ライセンスを後回しにする: 配布・製品組み込みの段階で詰む。先に法務
9. ふくふくの進め方
「自社データだけでは判断材料が足りない」というご相談で、最初に検討するのが OSM です。無償で、範囲を選ばず、社内分析であればライセンス面の障壁も低い。ただし網羅率の確認とライセンスの切り分けを飛ばすと後で困るので、この2つは必ず先に片付ける進め方をしています。
10. ここまでのまとめ
- OSM は地図ではなくデータベース。node / way / relation に tag が付いた構造
- 意味はすべてタグが担う。体系は演繹できないので、実データを見て確定する
- 取り出しは 。ただし共有インフラなので大量取得は抽出データで
- は「表示」と「配布」で要件が変わる。社外配布・製品組み込みは法務確認
- 価値の中心は 。緯度経度さえあればキー設計なしで繋がる
- の不一致は静かにずれる。既知の地点で目視確認する
OSM は「無料の地図」として語られがちですが、実務での価値は自社データに周辺の文脈を足せることにあります。続編では、面との空間結合の実装、網羅率の測り方、抽出データを手元で処理する構成などを、読者リアクションに応じて随時追加していきます。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。