普段使っている地図は、実は2つの層が重なってできています。下にあるのはジオメトリです。道路、海岸線、建物のフットプリントなど、地図を地図らしく見せている形状のことです。その上に重なっているのが、地図を実際に役立つものにする層、つまり「ここには何があるのか」という問いへの答えです。この2つ目の層がPOIデータです。
POIはポイントオブインタレスト（point of interest）の略で、POIデータとは人が関心を持つ場所を構造化した記録を指します。22時まで開いている薬局、対応コネクタが合う充電スタンド、加入している保険が使えるクリニック、段差なしで入れるカフェ。これがなければ、地図は街路の絵にすぎません。あることで、地図は検索でき、絞り込みでき、ソフトウェアが判断できる対象になります。
この記事では、POIレコードに実際に何が入っているのか、データはどこから来るのか、なぜ提供元によって品質にこれほど差が出るのか、そしてPOIデータがアプリケーションやAIエージェントでどう使われるのかを扱います。
ポイントオブインタレストの定義
ポイントオブインタレストとは、面や線ではなく単一の点としてモデル化された、名前を持つ場所です。判定基準は、人がそこへ行きたい、あるいはそこにあると知りたいと思うかどうかです。
レストラン、ホテル、病院、ATM、遊び場、展望スポット、ポスト、EV充電器、バス停、リサイクルセンターはすべてPOIです。街路はPOIではありません。線だからです。地区や自治体もPOIではありません。ポリゴンであり、区域の中心を目的地にする人はいないからです。建物は興味深い中間に位置します。ショッピングセンターはそれ自体が1つのPOIであり、同時に内部に数十のPOIを含んでいます。
この最後のケースは掘り下げる価値があります。素朴に作られたデータセットが破綻するのはまさにここだからです。空港の中心に打たれた座標が1つあるだけでは、旅行者を特定のゲート、ラウンジ、レンタカーカウンターまで案内することはできません。良質なPOIデータは、親と子を別々にモデル化したうえで両者をリンクさせています。
POIレコードに含まれる情報
最小構成のPOIは、名称とカテゴリを持つ座標です。ピンを1本描くにはこれで足ります。プロダクトを作るには足りません。
実運用に耐えるレコードには、さらに多くの情報が含まれます。
- 安定したID。 レコード更新のたびにIDが変わるようでは、場所を時系列で追跡することも、自社データベースと突き合わせることもできません。
- 名称（現地表記のバリエーションを含む）。 ブリュッセルの店舗にはフランス語名とオランダ語名の両方が必要になることがあります。アテネの場所にはギリシャ文字表記とローマ字表記の両方が要ります。
- 座標。 その点が何を表しているのか、建物の重心なのか、出入口なのか、住所からの概算補間なのかが示されていることが望ましいです。
- 構造化された住所。 1本の文字列ではなく構成要素に分解されていることで、突き合わせ、検証、国ごとの整形が可能になります。
- カテゴリ。 フリーテキストではなく、定義されたタクソノミーに基づくものです。restaurant という値は使えます。同じ概念に対して4件のレコードが restaurant / eatery / Restaurant / food とばらついている状態は使えません。
- 営業時間。 中休み、季節変動、祝日といった厄介な現実を扱える機械可読フォーマットであることが前提です。
- 連絡先とウェブ情報。 電話番号、ウェブサイト、予約リンクなど。
- 設備とバリアフリーの属性。 車椅子でのアクセス、テラス席、駐車場、利用可能な決済手段、ペット同伴の可否など。
- 出所と鮮度。 そのレコードがどこから来て、いつ最後に検証されたか。
最後の項目は省略されがちで、後から後悔することになるフィールドです。鮮度のシグナルがないPOIデータセットでは、そのレストランが2年前に閉店したかどうかを知る手立てがありません。
POIデータの取得元
大きく3つの供給元があり、実在するデータセットのほとんどはこれらの混合です。
オープンデータ。 OpenStreetMapは、オープンライセンスで公開されているPOIコレクションとしては世界最大で、世界中のコミュニティが直接タグを付けて構築・維持しています。カバレッジは欧州の都市部で非常に優れており、農村部や欧州・北米以外の一部地域ではばらつきが大きくなります。属性の豊かさは目を見張るものがあります。商用の調査員なら手を付けないような項目まで、コントリビューターがタグ付けしているからです。
公的台帳。 法人登記、交通事業者の停留所リスト、医療機関ディレクトリ、学校名簿、地籍記録など。このデータは権威があり、よく維持されていますが、国ごとに互換性のない何十種類ものフォーマットで届き、消費者が気にする属性はほとんど含まれていません。
商用の収集。 ベンダーが上記を集約し、独自のスクレイピングを加え、フィードを購入し、アクセス権を販売します。対価として支払っているのは、多くの場合、生の場所データそのものではなく、それらを統合する作業に対してです。
この統合作業はコンフレーション（conflation）と呼ばれ、難所のほとんどはここに集中しています。同じカフェが3つのソースに、3通りの綴り、わずかに異なる2つの座標、古いままの電話番号1件とともに現れることがあります。それらを同一の場所だと判断し、各属性についてどのバージョンを採用するかを決めること。これがPOIデータベース構築の中で最も難しい部分です。
品質に大きな差が出る理由
2つのデータセットがどちらも4,000万POIを収録していると謳っていても、実務上はまったく別物ということがあります。実際に効いてくる指標は次のとおりです。
- 位置精度。 ピンは建物の上にあるのか、道路上なのか、郵便番号エリアの中心なのか。店舗検索では見た目の問題で済みますが、ラストマイル配送ではドライバーが玄関にたどり着けるかどうかを左右します。
- 属性の充足度。 名称しかない1,000万件のレコードより、営業時間・カテゴリ・バリアフリー情報を備えた200万件のほうが役に立ちます。
- カテゴリの一貫性。 タクソノミーに揺れがあると、作ったフィルタはことごとく取りこぼします。
- 鮮度。 小売と飲食の入れ替わりは速いです。年に1回しか更新されないデータセットは、もう存在しない世界を記述しています。
- 重複率。 コンフレーションが甘いと件数が水増しされ、1店舗に対して3本のピンが立ちます。
提供元を評価するときは、見出しの収録件数は無視して、営業時間を持つレコードの比率と、最後に検証されたのがいつかを尋ねてください。
POIデータの使われ方
店舗検索とロケーター。 最も一般的な用途です。近くの店舗を条件付きで表示するというもので、仕組みについては店舗検索機能の作り方を参照してください。
出店評価と商圏分析。 候補地を中心とした所要時間圏の中で、競合、補完業種、集客施設を数えます。POIデータとアイソクロンの組み合わせは、小売の立地判断の中核です。
物流と配送。 目的地を建物の重心ではなく正確な出入口まで解決し、受け取り側の事業所がそもそも開いているかを把握します。
不動産と物件情報。 物件の周辺に何があるかを記述します。学校、交通機関、店舗、緑地など。これによって物件情報は写真の集まりから、購入検討者やAIが評価できる対象へと変わります。
旅行とローカル発見。 ホテルの近くに何があるかという問いから、旅程の自動生成まで幅広く使われます。
AIエージェント向けのPOIデータ
需要が最も急速に移動しているのがこの領域です。「駅の近くで今開いていて、段差なしで入れる薬局を探して」とアシスタントに尋ねたとき、アシスタントは地図を目を凝らして見るわけにはいきません。必要なのは、プログラムから絞り込めるレコードです。カテゴリが薬局であること、営業時間が現在のタイムスタンプを含むこと、車椅子属性が true であること、座標が駅からの徒歩時間圏内にあること。
これらの条件はすべてPOIの属性です。豊富なPOIソースを持つエージェントは質問に答えられます。名称と座標しか持たないエージェントは推測するしかなく、実世界の場所について推測することこそ、自信たっぷりに間違った推薦が生まれる原因です。
だからこそPOIデータは、タイルとしてではなくツールとしてエージェントに届けられる形が増えています。APIやMCPサーバーを通じて、エージェントは場所を照会し、属性で絞り込み、推論と引用が可能な構造化された結果を受け取れます。
POIデータをプロダクトに組み込む
実務上の判断は3つです。
ライセンス。 そのデータで何が許されているのか、とくにキャッシュ、再配布、地図の外での表示について理解しておいてください。オープンデータにも義務はあります。主に出典表示であり、ライセンスによっては継承条項も付きます。
処理される場所。 欧州で事業を行い、クエリにユーザーの位置情報が含まれるなら、そのクエリがどこで処理されるかはレイテンシだけの話ではなくコンプライアンスの問題です。EU開発者のためのGDPR準拠マップAPIガイドを参照してください。
最新性の保ち方。 ライブAPIに問い合わせるのか、スナップショットを同期するのかを最初に決めてください。スナップショットは高速で予測しやすい一方、取得した瞬間から劣化が始まります。ライブクエリは常に最新ですが、依存関係が1つ増えます。
MapAtlasは、欧州を中心に世界各地でGDPR準拠のPOI検索、場所の詳細、周辺検索を提供しています。オープンな地図データを基盤とし、検索APIとMCPサーバーの両方から利用できるため、同じ構造化レコードが店舗検索にもAIエージェントにも使えます。
まとめ
POIデータは、地図が問いに答えられるようにする層です。1件のレコードは座標に加えて、ソフトウェアが絞り込むための属性、つまり名称、カテゴリ、住所、営業時間、バリアフリー、鮮度で構成されます。供給元はオープンデータ、公的台帳、商用収集の3つで、提供元が加える価値の大部分はそれらをきれいに統合する作業にあります。
データセットは、掲げているピンの数ではなく、属性の厚みと鮮度で判断してください。そしてロードマップのどこかにAIエージェントがあるなら、エージェントが推測なしで絞り込めるかどうかで判断してください。
関連記事
よくある質問
POIデータとは何ですか？
POIデータとは、ポイントオブインタレスト（point of interest）、つまり人が探したり訪れたりする可能性のある具体的な場所についての構造化された情報です。薬局、充電スタンド、学校、ホテル、バス停などがこれにあたります。POIレコードは座標に対して、名称、カテゴリ、住所、営業時間、連絡先、さらにはバリアフリーや設備のフラグといった記述的な属性を結び付けたものです。この層があることで、地図は単なる街路の絵から、検索・絞り込み・プログラムによる判断ができる対象へと変わります。
ポイントオブインタレスト（POI）とは何を指しますか？
ポイントオブインタレストとは、面や線ではなく地図上の一点として表現される、名前を持つ場所のことです。決め手になるのは「人がそこへ行きたい、あるいはその存在を知りたいと思う場所かどうか」という点です。レストラン、ATM、展望スポット、リサイクルセンターはいずれもPOIです。一方、道路や行政界はPOIではありません。これらは線やポリゴンとしてモデル化されるものであり、境界線そのものを目的地にする人はいないからです。
POIレコードにはどのような属性が含まれますか？
最低限のPOIには、安定したID、名称、緯度経度、カテゴリが含まれます。実運用向けのデータセットではさらに多くの属性が加わります。構造化された住所、営業時間、電話番号とウェブサイト、価格帯、車椅子でのアクセス可否、テラス席や駐車場の有無、対応する決済手段、そしてそのレコードが最後に検証された日付などです。実際に使えるPOIデータと単なるピンの一覧を分けるのは、たいていこの属性の厚みです。
POIデータはどこから来るのですか？
大きく3つの供給元があります。1つ目はオープンデータで、その中心はOpenStreetMapです。世界中のコミュニティが場所にタグを付け、その成果が自由なライセンスで公開されています。2つ目は公的・行政的な台帳で、法人登記、交通事業者の停留所リスト、医療機関ディレクトリなどが該当します。3つ目は商用の収集で、ベンダーがデータを集約・収集・購入し、アクセス権を販売するものです。本格的なデータセットはこの3つを組み合わせたうえで、コンフレーション（名寄せ）と検証を行い、重複の統合と矛盾の解消を進めています。
AIエージェントはPOIデータをどう使いますか？
「駅の近くで今開いている薬局を探して」という問いに答えるAIエージェントは、地図の画像から推論することはできません。必要なのは、絞り込みが可能な構造化レコードです。カテゴリが薬局であること、営業時間が現在時刻を含むこと、座標が駅からの所要時間圏内にあること。POIデータはまさにこの条件を提供します。だからこそPOIデータは、画面に描画して人が目で追うものではなく、APIやMCPサーバー経由でエージェントに渡される形が増えているのです。
