皆様、こんにちは！
Google Maps Platform のプロフェッショナル集団、ゴーガです。
Geocoding API といえば、住所から緯度経度の座標に変換したり、その逆（リバースジオコーディング）を行ったりするお馴染みの API です。この Geocoding API ですが、待望の次世代バージョン「v4」が一般提供 (GA) されました。
この Geocoding API v4 の GA と同時に、新たに正式リリースされた注目の機能が、今回ご紹介する「目的地を検索する（SearchDestinations）」メソッドです。この SearchDestinations メソッドをうまく活用することで、巨大な商業施設や大型マンションといった「入り口がわかりづらい敷地」でも、ユーザーを迷わせることなく目的地へスムーズに案内できるようになることが期待されています。
今回のブログでは SearchDestinations メソッドによってどのような道案内や UI が実現できるようになるのかを実際に API の検証をしながら整理します。
「SearchDestinations」メソッドで取得できる主要な 4つのデータ
実際のレスポンスデータを確認すると、これまでの緯度経度を中心としたデータに加え、目的地周辺の「コンテキスト（文脈情報）」が豊富に含まれていることが分かります。主なポイントは以下の 4 つです。
1. ビルとテナントの「親子関係」
これまでは、「あるビルの中に、特定の会社や店舗が入っている」という関係性をアプリ側で表現する場合、開発者が自前でデータを紐づけるロジックを組む必要がありました。
しかし、SearchDestinations メソッドでは、レスポンス自体にこの関係性が最初から内包されています。
- 弊社（テナント）を検索した場合: 親にあたる建物情報が返ってくる (containingPlaces)
- ビル（親）を検索した場合: その中に入っているフロアやテナントの情報が返ってくる (subDestinations)
例として、弊社「株式会社ゴーガ」は「渋谷363清水ビル」に入居しています。親子関係が API を使って取得できるようになったことにより、アプリの画面上に「渋谷363清水ビル 内の 株式会社ゴーガ」といった、ユーザーにとって分かりやすい構造的な施設案内をスムーズに表示できるようになります。
例：「株式会社ゴーガ」を目的地としてリクエストした結果
(※要点に絞って解説するため、レスポンスの一部テキストを省略・整形しています)
...
// 1. 検索した目的地「株式会社ゴーガ」の基本情報
"primary": {
"place": "places/ChIJL..(省略)..tj4",
"placeId": "ChIJL..(省略)..tj4",
"displayName": {"text": "株式会社ゴーガ", "languageCode": "ja"},
...
"formattedAddress": "〒150-0002 東京都渋谷区渋谷３丁目６−３ 清水ビル 10F 株式会社ゴーガ",
...
"location": {"latitude": 35.6579915, "longitude": 139.7051629},
...
},
// 2. 親要素（弊社が入居するビル）の情報が containingPlaces 配列にセットされている
"containingPlaces": [
{
"place": "places/ChIJX..(省略)..KMY",
"placeId": "ChIJX..(省略)..KMY",
"displayName": {"text": "渋谷363清水ビル", "languageCode": "ja"},
...
"formattedAddress": "〒150-0002 東京都渋谷区渋谷３丁目６ 渋谷363清水ビル",
...
"location": {"latitude": 35.657881499999995, "longitude": 139.705189},
...
}
],
...
primary 要素に「株式会社ゴーガ」、「株式会社ゴーガ」を内包している場所「渋谷363清水ビル」が containingPlaces にセットされていることがわかります。
それでは、ゴーガが入居している「渋谷363清水ビル」を目的地としてリクエストするとどうなるでしょうか？
例：「渋谷363清水ビル」を目的地としてリクエストした結果
(※要点に絞って解説するため、レスポンスの一部テキストを省略・整形しています)
// 1. 検索した目的地「ビル（親要素）」の基本情報
"primary": {
"place": "places/ChIJX..(省略)..KMY",
"placeId": "ChIJX..(省略)..KMY",
"displayName": {"text": "渋谷363清水ビル", "languageCode": "ja"},
...
"formattedAddress": "〒150-0002 東京都渋谷区渋谷３丁目６ 渋谷363清水ビル",
...
"structureType": "BUILDING",
"location": {"latitude": 35.657881499999995, "longitude": 139.705189},
...
},
// 2. 子要素（ビルに入居するテナント等）の情報が subDestinations 配列にセットされます
"subDestinations": [
{
"place": "places/ChIJL..(省略)..tj4",
"placeId": "ChIJL..(省略)..tj4",
"displayName": {"text": "株式会社ゴーガ", "languageCode": "ja"},
...
"formattedAddress": "〒150-0002 東京都渋谷区渋谷３丁目６−３ 清水ビル 10F 株式会社ゴーガ",
...
},
...
]
...
今度は目的地である「渋谷363清水ビル」が primary としてセットされました。そしてsubDestinations に「株式会社ゴーガ」を含む、ビルに入居しているテナント等の情報がセットされていることが分かります。
2. 出入り口（エントランス）の座標
建物の中心点ではなく、「実際に人間や車両がアプローチすべき出入り口の座標」がデータとして返されるようになりました。これにより、「ここからビルに入ってください」という正確なナビゲーションが可能になります。配送サービスや配車アプリ、あるいは初めて訪問するユーザー向けの案内において特に有効なデータです。
例：「渋谷363清水ビル」を目的地としてリクエストした結果
(※要点に絞って解説するため、レスポンスの一部テキストを省略・整形しています)
...
"entrances": [
{
"location": {"latitude": 35.657995, "longitude": 139.70524179999998},
"tags": ["PREFERRED"],
"place": "places/ChIJX..(省略)..KMY",
},
{
"location": {"latitude": 35.6579919, "longitude": 139.7051426},
"place": "places/ChIJX..(省略)..KMY"
}
],
...
このように、弊社が入居するビルの入り口の座標をピンポイントで取得することができます。さらに、tags 配列に入り口の特性タグがセットされるのもポイントです。目的地として設定した場所が建物自体の場合、その建物のホワイエ（ロビー）エリアにアクセスできる入り口に PREFERRED タグが付与されます。
上記の API レスポンスは 2 つの入り口の情報が含まれており、そのうち一つに対して PREFERRED タグが付与されています。実際に地図上で二つの位置関係を確認したところ、 PREFERRED タグが付与されている方の入り口がビルの正式なエントランス、付いていない方の入り口は同じビルの 1 階に入居しているファミリーマートさんの店舗入り口だということがわかりました。
例：2 つの入り口の位置関係を地図上に表示したもの
オレンジ色の「入口1」がビルのエントランス、「入口2」がファミリーマートさん店舗の入り口
3. 目的地周辺の目印になる場所（ランドマーク）
人間が道案内をする際、たとえば弊社の所在地であれば「渋谷3-6-3」という住所を伝えるよりも、「ドトールコーヒーさんの隣のビル」と伝えた方が直感的に分かりやすい場合があります。
SearchDestinations メソッドは、こうした周辺の目印となるスポットを特定し、関係性を表すテキストを自動的に生成して返してくれます。
弊社の場所を目的地として返ってきたデータには、実際に以下のようなテキストが含まれていました。
- 「ドトールコーヒーショップ 渋谷３丁目北店 の隣」（直線距離：約24m）
- 「セブン-イレブン 渋谷３丁目六本木通り店 の近く」（直線距離：約42m）
わざわざ人が道案内文を書かなくても、API を呼び出すだけで「ドトールコーヒーショップ 渋谷３丁目北店 の隣」とアプリに表示することができるようになります。
例：「渋谷363清水ビル」を目的地としてリクエストした結果
(※要点に絞って解説するため、レスポンスの一部テキストを省略・整形しています)
"landmarks": [
{
"place": {
"place": "places/ChIJ6..(省略)..27s",
"placeId": "ChIJ6..(省略)..27s",
"displayName": {"text": "ドトールコーヒーショップ 渋谷３丁目北店", "languageCode": "ja"},
"primaryType": "cafe",
"formattedAddress": "〒150-0002 東京都渋谷区渋谷３丁目６−２ エクラート渋谷ビル ドトールコーヒーショップ 渋谷３丁目北店"
...
},
"relationalDescription": {"text": "ドトールコーヒーショップ 渋谷３丁目北店 の隣", "languageCode": "ja"},
"tags": ["ARRIVAL", "ADDRESS"],
"straightLineDistanceMeters": 24.286211013793945, // 直線距離
"travelDistanceMeters": 8.93632984161377 // 実際の移動距離
},
{
"place": {
"place": "places/ChIJM..(省略)..Tas",
"placeId": "ChIJM..(省略)..Tas",
"displayName": {"text": "セブン-イレブン 渋谷３丁目六本木通り店", "languageCode": "ja"},
"primaryType": "convenience_store",
"formattedAddress": "〒150-0002 東京都渋谷区渋谷３丁目６−１ イースト渋谷ビル １Ｆ セブン-イレブン 渋谷３丁目六本木通り店"
...
},
"relationalDescription": {"text": "セブン-イレブン 渋谷３丁目六本木通り店 の近く", "languageCode": "ja"},
"tags": ["ARRIVAL"],
"straightLineDistanceMeters": 42.50472640991211,
"travelDistanceMeters": 36.81339645385742
},
...
]
さきほどの出入り口（エントランス）と同様に、ランドマークにもタグが付与されます (tags)。ランドマークのタグの種類は現時点で以下の 2 種類が定義されています。
- ADDRESS: そのエリアで広く知られている場所に付与されます。目的地の「だいたいの場所」を把握するための目印として機能し、通常は目的地から数百メートルほど離れた場所にこのタグが付与されます（上記の例における「渋谷駅」など）。
- ARRIVAL: 目的地への「最終的な到着」をサポートするための場所に付与されます。目的地の直近まで来た際のナビゲーションに役立つ目印で、通常は ADDRESS タグの場所よりも目的地に対してかなり近いスポットに付与されます。
4.ナビゲーションポイント
ナビゲーションを終了（目的地に設定）するのに適した、「道路沿いの具体的なポイント」の情報も API から取得できるようになりました。目的地そのもののピンではなく、アプローチするのに最適な道路沿いの座標が得られるのが特徴です。
弊社が入居するビルを目的地とした際に返ってくるレスポンスを見てみましょう。
(※要点に絞って解説するため、レスポンスの一部テキストを省略・整形しています)
"navigationPoints": [
{
"navigationPointToken": "ChIJW..(省略)..zQ",
"displayName": {"text": "六本木通り", "languageCode": "ja"},
"location": {"latitude": 35.6580148, "longitude": 139.7052436},
"travelModes": ["DRIVE", "WALK"],
"usages": ["DROPOFF", "PICKUP"]
}
]
ビルの目の前には六本木通りがあるので、レスポンスの内容は正しいようです。実際にこの座標を地図上にプロットしてみたら、確かに建物（中心点）とは離れた、アクセスしやすい歩道側にマーカーが打たれました。
ナビゲーションポイント（右上の青緑色のマーカーが表示されている場所）
また、公式のドキュメントには、「そのナビゲーションポイントが何の用途に適しているか」を示す usages 配列がレスポンスに含まれることが記載されています。
レスポンスに含まれる用途の種類については、現在以下の 3 つが定義されています。
- DROPOFF: 目的地での「降車」に適したポイント
- PICKUP: ユーザーを「乗車」させるのに適したポイント
- PARKING: 付近の「駐車場」として利用可能なポイント
先ほどの検証結果を改めて確認すると、usages 配列内に DROPOFF（降車位置）や PICKUP（乗車位置）といったタグが正しく付与されていることが見て取れます。
実装の際に気をつけたほうが良いポイント
実際に SearchDestinations をシステムに組み込む際、API へどのように目的地を渡すか（住所文字列、緯度経度、Place ID）の選択肢があります。
弊社の開発チームでこれら3パターンのリクエスト方法を比較検証してみたところ、最も安定して精度の高い結果が得られたのは「Place ID」でした。（※ちなみに、この記事の検証で使ったリクエスト方法もすべて Place ID を指定しています）
実際、公式ドキュメントでも establishment（店舗・施設）や premise（建物）など、明確な目的地を表す Place ID でのリクエストが推奨されており、住所の範囲（○番〜○番など）のような曖昧な指定はサポート外となっています。
本機能のポテンシャルを最大限に引き出すためにも、対象スポットの Place ID を事前に取得した上でリクエストを送る設計にするのがベストプラクティスと言えそうです。
また、実際のデータ検証を通じて、アプリ側の UI/UX 設計において考慮しておくと良いポイントも見えてきました。
1. ナビゲーションポイントや出入り口のカバー範囲と精度
ナビゲーションポイントや出入り口（エントランス）のデータは、現時点ではすべての場所で完全にマッピングされているわけではなく、スポットの規模や特性によってデータの充実度において差があるようです。しかしながら、データが返ってくるケースにおいては、建物の実際のアクセス経路に即した実用的な位置に配置されていることが確認できました。
2. ランドマークやナビゲーションポイントのアプリ側でのハンドリング
- ランドマークのフィルタリング: 先述の通り、ランドマークには広域を指す ADDRESS タグの場所も含まれるため、目的地から少し離れたスポットが返ってくることもあります。そのため、アプリの画面に表示する際は、目的に応じて「移動距離（straightLineDistanceMeters または travelDistanceMeters）」や「タグ（tags）」を使ってアプリ側で絞り込み処理を挟むと良いかもしれません。
- 現地の交通規制への配慮: API が返してくるナビゲーションポイント（車を寄せる位置など）は、あくまで地図データ上の最適なアプローチポイントです。現地のリアルタイムな交通規制や警察の取り締まりルールまでは保証されない可能性があるため注意が必要です。
これらの特性を踏まえると、API のレスポンスデータをただそのまま画面に表示するのではなく、「アプリ側での適切なデータフィルタリング」や、ドライバー向けアプリであれば「最終的な駐停車の可否は現地の交通規制に従ってください」といった親切な注意書き UI を添えるなど、開発者側での一工夫を組み合わせることが、ユーザーにとって使いやすい位置情報サービスを実現する鍵になりそうです。
まとめ
Geocoding API v4 で登場した新機能 SearchDestinations についてご紹介しました。
今回の記事では、今後挙動が変更される可能性があるため詳しく触れませんでしたが、SearchDestinations にはストリートビュー連携機能や、目的地に関する AI サマリー（※現時点で試験運用版）など、次世代のルート案内を可能にする強力な機能が次々と追加されています。
位置情報サービスやナビゲーションの UX を一段引き上げる可能性を秘めたこの API、ぜひ皆さんも検証してみてはいかがでしょうか。今後も面白い機能や実務に役立つアップデートがあれば、こちらのブログで積極的に発信していきたいと思います。
ゴーガには Google Maps Platform に精通したエンジニアが多く在籍しています。
「そもそも Google Maps Platform って何？」や「Geocoding API v4 への移行を検討しているけどどうすればいい？」など、気になることがありましたらお気軽にご相談ください！
