位置情報とマッピング - Amazon Location Service の現行 API で作る地理空間アプリケーション

位置情報アプリケーションを構成する 4 つの部品

配車アプリ、フードデリバリー、物流の追跡、不動産検索、店舗検索。位置情報を扱うアプリケーションは用途が違っても、必要になる部品はおおむね共通しています。地図を画面に描くこと、住所や地名を緯度経度に変換すること (ジオコーディング)、地点間の経路と所要時間を計算すること、そして移動する対象の位置を継続的に記録して特定の区域への出入りを検知すること。この 4 つです。 自前で用意しようとすると、地図データの調達とライセンスの確認、タイルの生成と配信、道路ネットワークを使った経路探索の実装、位置履歴を保持するデータストアの運用が、すべて自分の仕事になります。Amazon Location Service は、この部品群をマネージドサービスとして提供し、地図の描画、場所の検索、経路の計算、位置の追跡とジオフェンスを AWS の API として呼べるようにしたサービスです。 押さえておきたいのは、このサービスの使い方が 2024 年 11 月に大きく変わったという点です。以前は使い始める前にリソースを作る手順が必須でしたが、現行世代ではその手順がなくなり、API キーを 1 本用意すれば呼び出せる形になりました。本記事は現行世代の API を前提に、実際の呼び出し方から料金の考え方までを追います。旧世代で作ったアプリケーションを抱えている場合の移行についても、後半に節を設けます。

2024 年 11 月の世代交代: リソース作成から API キーへ

現行世代の入口を理解するには、まず何がなくなったのかを押さえるのが早道です。旧世代では、住所検索をしたければまずプレイスインデックスというリソースを作り、経路計算にはルート計算機を、地図表示には地図リソースを、それぞれ事前に作成してから名前で参照する必要がありました。リソースを作る段階でデータプロバイダーを選び、以後の呼び出しはそのリソースに紐づくという設計です。 2024 年 11 月に公開された新しい API 群では、この前提が外れました。公式の説明でも、以前は必須だったリソース作成の手順はもう必要なく、API キーを設定することで各種 API を利用できるようになったと明言されています。このときリリースされたのは 10 個の更新 API と 7 個の新規 API、合わせて 17 の新規・強化 API です。 同時に、SDK 上の名前空間も分かれました。場所の検索は geo-places、経路の計算は geo-routes、地図の取得は geo-maps という独立した系統になり、アプリケーションが必要とする系統だけを取り込めます。 API キーの作成は CreateKey で行い、ほかに DescribeKey、ListKeys、UpdateKey、DeleteKey が揃っています。キーの値は v1.public. で始まる文字列で、フロントエンドのコードに埋め込んで使うことが想定されています。埋め込む前提だからこそ、キーには任意の有効期限を設定でき、Web であれば参照元の HTTP リファラー、モバイルであればアプリケーションの識別子によって使用範囲を絞れます。 ただし、API キーで呼べる範囲には線があります。地図、場所、経路の照会系はキーで呼べますが、トラッカーへの位置の書き込みやジオフェンスの管理、そしてキー自体の管理といった操作には、IAM や Amazon Cognito による認可が必要です。公開して構わない照会と、そうでない書き込み・管理を、認可の仕組みごと分けて考えるのが現行世代の設計になります。

Places・Routes・Maps の 3 系統と最初の呼び出し

現行世代の API は 3 系統に整理されています。 場所を扱う Places は 7 つの操作を持ちます。住所文字列から緯度経度を求める Geocode、緯度経度から住所を求める ReverseGeocode、自由入力のテキスト検索 SearchText、周辺の施設を探す SearchNearby、入力補完のための Autocomplete と Suggest、識別子から詳細を取る GetPlace です。入力補完が 2 つに分かれているのは、確定した住所候補を返したい場面と、検索語そのものの候補を返したい場面が別だからです。 経路を扱う Routes は 5 つです。経路を計算する CalculateRoutes、多対多の所要時間表を作る CalculateRouteMatrix、指定した時間内に到達できる範囲を面で返す CalculateIsolines、複数の立ち寄り先の順序を最適化する OptimizeWaypoints、GPS の点列を道路上に補正する SnapToRoads。配送計画であれば CalculateRouteMatrix と OptimizeWaypoints、商圏分析であれば CalculateIsolines、走行履歴の整形であれば SnapToRoads という対応になります。移動手段の値は操作ごとに異なります。CalculateRoutes では Car、Pedestrian、Scooter、Truck に公共交通の Transit と複合輸送の Intermodal を加えた 6 種類、到達圏や道路スナップなど他の 4 操作では Car、Pedestrian、Scooter、Truck の 4 種類です。いずれも指定しなければ Car で、Scooter はオートバイを含む区分として扱われます。 地図を扱う Maps は 5 つで、スタイル定義を返す GetStyleDescriptor、ベクタータイルの GetTile、ラベル描画用のフォントを返す GetGlyphs、アイコン画像の GetSprites、そして 1 枚の画像として地図を返す GetStaticMap です。メールや PDF に地図を貼りたいだけであれば、GetStaticMap で完結します。 最初の呼び出しは CLI で確かめるのが手軽です。API キーを使う場合は署名が不要なので、--no-sign-request を添えます。

aws geo-places geocode \
  --query-text '東京都渋谷区神宮前 1-1-1' \
  --language ja \
  --key "$ALS_API_KEY" \
  --no-sign-request \
  --region ap-northeast-1

HTTP で直接呼ぶ場合は、POST /v2/geocode に対してキーをクエリパラメータの key で渡し、本文に QueryText や Language を JSON で入れます。公式ドキュメントの表現では、リクエストには API キーか有効な SigV4 署名のどちらかが必要とされています。サーバー側から呼ぶなら通常の IAM 認証、ブラウザやアプリから呼ぶなら API キーという使い分けです。 大量の住所をまとめて検証したい場合は、リクエストを 1 件ずつ投げるのではなく、Amazon Location Service Jobs によって Amazon S3 上のファイルを非同期に処理する経路が用意されています。また、位置の追跡とジオフェンスについては、現行世代でもトラッカーやジオフェンスコレクションというリソースを作成してから使います。リソース作成が不要になったのは地図、場所、経路の照会系である、という理解が正確です。

地図の描画とフロントエンドへの組み込み

地図の描画そのものは MapLibre が受け持ちます。Web では MapLibre GL JS、モバイルでは MapLibre Native が公式に推奨されるレンダラーで、Amazon Location Service 側はスタイル定義とタイルを供給する役です。 Web の実装は、MapLibre のスタイル指定にスタイル記述子の URL を渡すだけで動きます。

import maplibregl from 'maplibre-gl';
import 'maplibre-gl/dist/maplibre-gl.css';

const region = 'ap-northeast-1';
const apiKey = import.meta.env.VITE_ALS_API_KEY;

const map = new maplibregl.Map({
  container: 'map',
  style: `https://maps.geo.${region}.amazonaws.com/v2/styles/Standard/descriptor?key=${apiKey}&color-scheme=Dark`,
  center: [139.7671, 35.6812],
  zoom: 14
});

map.addControl(new maplibregl.NavigationControl());

スタイルは Standard、Monochrome、Hybrid、Satellite の 4 種類から選びます。色調は color-scheme パラメータで Light と Dark を切り替えられ、既定は Light です。この値は大文字と小文字を区別するため、dark と書くと通りません。ほかにも建物の 3D 表示、地形の陰影、等高線の密度、交通状況の重ね合わせといった表現が、記述子の URL に付けるパラメータで制御できます。見た目を変えるためにアプリケーション側のコードを書き直す必要はなく、URL の組み立てを変えるだけで済むということです。 エンドポイントのホスト名は 2 つの形式があります。IPv4 のみの従来形式が service-code.geo.region-code.amazonaws.com、IPv4 と IPv6 の両方に対応するデュアルスタック形式が service-code.geo.region-code.api.aws です。service code は地図が maps、場所が places、経路が routes、ジオフェンスが geofencing、トラッカーが tracking、一括処理のジョブが属する系統が metadata です。IPv6 での接続が要件になっている環境では、後者の形式を選びます。 React で AWS Amplify を使っている場合は、Amplify Geo の UI コンポーネントで地図を出す書き方もあります。

import { MapView, Marker } from '@aws-amplify/ui-react-geo';
import '@aws-amplify/ui-react-geo/styles.css';

export default function StoreLocator() {
  return (
    <MapView
      initialViewState={{ latitude: 35.6812, longitude: 139.7671, zoom: 14 }}
    >
      <Marker latitude={35.6812} longitude={139.7671} />
    </MapView>
  );
}

ただし、この書き方は Amplify が構成する地図リソースと Amazon Cognito の認可を前提としており、ここまで説明してきた API キー方式とは資格情報の考え方が別です。既存の Amplify アプリケーションに地図を足すならこちら、現行世代の API を直接使うなら MapLibre にキー付きの記述子 URL を渡す形、という整理をしておくと、認可の設計が中途半端に混ざるのを避けられます。利用者ごとに扱える範囲を制御したい場合や、書き込みを伴う操作を扱う場合は、いずれの構成でも Cognito と IAM の側に寄せることになります。

旧世代 API からの移行と旧手順の位置づけ

既存のアプリケーションが旧世代で動いている場合、コードの見た目はかなり違います。旧世代のジオコーディングは、あらかじめ作成したプレイスインデックスの名前を指定する形でした。

aws location search-place-index-for-text \
  --index-name MyPlaceIndex \
  --text '東京都渋谷区神宮前 1-1' \
  --language ja \
  --region ap-northeast-1

この形では、インデックスを作るときに選んだデータプロバイダーが以後の検索結果を決めます。プロバイダーを変えたければインデックスを作り直す必要があり、検索の品質を比べたいだけでもリソース管理が絡んできました。現行世代の API には --index-name に相当する指定がありません。経路計算のルート計算機名、地図リソース名という指定も同様に存在しないため、移行作業の実態は「リソース名を渡していた箇所を削り、呼び出し先を新しい操作名に置き換える」ことになります。 移動手段の値も変わりました。旧世代は Bicycle、Car、Motorcycle、Truck、Walking の 5 種類でした。現行世代は Car、Pedestrian、Scooter、Truck を基本に、経路計算 (CalculateRoutes) に限り公共交通の Transit と複合輸送の Intermodal が加わります。Walking は Pedestrian へ、Motorcycle は Scooter へ読み替えます。自転車に対応する値は現行世代に含まれていないため、自転車前提の経路を返していたアプリケーションは、移行時に代替の扱いを決める必要があります。 旧世代のドキュメントは消えたわけではなく、docs.aws.amazon.com/location/previous/ 以下にまとまっています。検索で行き当たった手順が現行のものか旧世代のものかは、URL に previous が含まれるかどうかで判別できます。移行の途中で旧手順を確認したいときは、この場所を見ることになります。 Google Maps JavaScript API で書かれたアプリケーションから移ってくる場合には、AWS が公開している Amazon Location Migration SDK という選択肢があります。Google Maps の呼び出しインターフェイスに似せた層を挟み、アプリケーションのビジネスロジックを大きく書き換えないまま、地図の描画や場所の検索を Amazon Location Service 側へ差し替えていくという発想の道具です。一度に全面書き換えができない規模のアプリケーションでは、まずこの層で置き換えの範囲を確かめる進め方が現実的です。

データプロバイダーの選択と利用条件

地図やジオコーディングの結果そのものは、AWS が独自に作っているわけではなく、データプロバイダーから供給されています。提供元は 2026 年 8 月時点で Esri、HERE、そして東南アジアを対象とする GrabMaps です。地図タイルについては、旧世代の地図リソースを経由する場合に限り、これらに加えて Open Data 由来のスタイルも選べます。Open Data は地図の描画に使われるもので、場所の検索や経路の計算には使われません。提供元を 2 社から選ぶものと整理してしまうと、東南アジア向けの選択肢と Open Data のタイルが視野から落ちます。 選定で先に効いてくるのは、品質よりも利用条件です。しかもこの条件は、サービスのドキュメントではなく AWS のサービス条項の側で定められています。Esri のデータは、AWS の書面による同意がない限り、自社の事業資産 (社用車や自社設備など) の追跡や、そのための経路計算に使えません。HERE のデータは、日本の結果を保存できません。GrabMaps は東南アジア向けの提供元で、利用できるリージョンが限られます。加えて、リージョンによって使える操作とスタイルにも差があります。東南アジアを担当する ap-southeast-1 (シンガポール) と ap-southeast-5 (マレーシア) では Geocode が提供されておらず、地図のスタイルも Standard と Monochrome に限られます。対象地域のリージョンで必要な操作が提供されているかは、実装に入る前にリージョン別の提供状況の一覧で確かめるのが確実です。 保存の可否は課金にも直結します。Places の API には IntendedUse というパラメータがあり、SingleUse (単発利用) と Storage (保存) のいずれかを指定します。応答を自社のデータベースへ保存するのであれば、サービス条項に従うために Storage を指定しなければならず、その場合の単価は高くなります。画面に出すだけで保存しないのであれば SingleUse です。位置情報が AWS の外に出ないという一般論で片付けるのではなく、プロバイダーごとの保存制約と IntendedUse の指定という 2 点で確認するのが、実務的な整理になります。

料金の考え方と実際の単価

(2026 年 8 月時点・米国東部 (バージニア北部) とアジアパシフィック (東京) の 2 リージョンで個別に確認。両リージョン同額) 地図・場所・経路の照会系の料金は、リソースを保有している時間ではなく、呼び出した回数で決まります。地図やインデックスのリソースを作らないこれらの系統では、使っていない期間の固定費は発生しません。後述のとおり、ジオフェンスだけは保有に対する課金があります。 地図タイルは、現行世代の GetTile ではスタイルによらず 1,000 タイルあたり 0.04 USD です。提供元別の単価は旧世代の地図リソースを経由する取得に残っており、Open Data のスタイルだけ 1,000 タイルあたり 0.035 USD になります。1 枚の画像を返す GetStaticMap は 1,000 リクエストあたり 0.50 USD です。1 画面の表示で複数のタイルを取得する点には注意が必要で、ズームやパンの操作が多い UI ほどタイル数は増えます。 場所の検索は 1,000 リクエストあたり、Core が 0.50 USD、Advanced が 1.50 USD です。入力補完の Autocomplete と Suggest の軽量応答には Label という別のバケットがあり、こちらは 1,000 リクエストあたり 0.20 USD です。保存を伴う用途 (IntendedUse に Storage を指定する呼び出し) は 1,000 リクエストあたり 4.00 USD になります。住所をまとめて検証する用途では段階制の単価が適用されます。Advanced の場合、最初の 10 万件が 1,000 件あたり 12.50 USD、次の 40 万件が 9.00 USD、次の 50 万件が 6.50 USD、次の 400 万件が 3.00 USD、500 万件を超える部分が 1.50 USD です。Core には 10.50 USD から 1.00 USD まで下がる別系列の段階単価が用意されています。 経路の計算 (CalculateRoutes) は 1,000 リクエストあたり、Core が 0.50 USD、Advanced が 1.50 USD、Premium が 4.00 USD です。単価の水準は他の操作でも共通ですが、選べるバケットは操作ごとに異なります。所要時間表 (CalculateRouteMatrix) にあるのは Core と Advanced だけ、到達圏、道路スナップ、経由地の最適化にあるのは Advanced と Premium だけです。したがって後者の 3 操作には 0.50 USD の Core がなく、最低単価は 1,000 リクエストあたり 1.50 USD になります。 位置の追跡は、デバイス 1 台あたりの月額ではなく、送った位置の件数で決まります。位置の書き込みは最初の 50 万件が 1,000 件あたり 0.05 USD、次の 450 万件が 0.035 USD、次の 4,500 万件が 0.025 USD、5,000 万件を超える部分が 0.0125 USD です。位置の読み取りとデバイスの削除がそれぞれ 1,000 件あたり 0.05 USD、位置の整合性の評価が 1,000 件あたり 1.00 USD です。10 秒ごとに位置を送る車両を 100 台走らせると 1 日で 86 万件を超えるように、送信間隔の設計がそのまま費用に出ます。 ジオフェンスは呼び出し課金に加えて保有課金を持つ唯一の部品で、登録済みのジオフェンス 1,000 件あたり月額 0.20 USD がかかります。位置とジオフェンスの照合 (位置評価) は段階制で、最初の 25 万件が 1,000 件あたり 0.16 USD、次の 175 万件が 0.11 USD、次の 2,300 万件が 0.07 USD、2,500 万件を超える部分が 0.06 USD です。このほか、ジオフェンスの作成や更新といった管理操作が 1,000 件あたり 0.05 USD、到達予測が 1,000 件あたり 1.75 USD で提供されています。 Core、Advanced、Premium のどれで課金されるかは、リクエストに付けたオプションによって変わります。実際に適用されたバケットは応答の PricingBucket フィールドに入って返るため、見積もりを作る前に、開発中のリクエストがどのバケットに落ちているかを実測しておくと、想定と請求のずれを避けられます。月間の利用額が 5,000 USD を超える規模については、公式の料金ページにボリュームディスカウントの案内があります。 無料で試せる範囲については、書かれている内容が 2 通り併存していることを知っておく必要があります。AWS 全体の新規アカウント向けの無料利用枠は 2025 年 7 月 15 日にクレジット方式へ変わり、最大 200 USD 相当のクレジットを受け取り、無料プランを 6 か月間、クレジットは 12 か月以内に使う形になりました。一方で Location Service の料金ページには、最初の 3 か月間は毎月一定量まで無償という従来型の表も併記されています。どちらが自分のアカウントに適用されるかは作成時期によって変わるため、請求ダッシュボードの無料利用枠の画面で実際の残量を確認してから見積もりを組むのが安全です。

まとめ

現行世代の Amazon Location Service は、プレイスインデックスやルート計算機を作ってから使うサービスではありません。API キーを 1 本用意すれば、Places の 7 操作、Routes の 5 操作、Maps の 5 操作を呼べます。旧世代の手順で書かれた記事やサンプルに行き当たったときは、URL に previous が含まれていないかを確かめると、世代を取り違えずに済みます。 設計時に押さえる点は 3 つに絞れます。1 つ目は認可の切り分けで、公開して構わない照会は API キー、書き込みと管理は IAM や Amazon Cognito に寄せます。2 つ目はデータプロバイダーで、Esri、HERE、GrabMaps、そして地図タイル向けの Open Data のうち、自分の用途がサービス条項で許されている提供元を選び、結果を保存するのであれば IntendedUse に Storage を指定します。3 つ目は課金の単位で、費用はリクエスト数と適用されたバケットで決まるため、PricingBucket を見ながらオプションの付け方を調整するのが効きます。 地図の描画は MapLibre に任せ、見た目はスタイル記述子の URL のパラメータで切り替えます。この分担を理解しておけば、店舗検索のような小さな画面から、車両を継続的に追跡する規模の構成まで、同じ考え方で組み立てられます。