Claude CodeのAmazon Location Serviceプラグインで地図とジオコーディングを実装する
AWS提供のAmazon Location Serviceプラグインを入れ、MapLibreの地図表示、住所のジオコーディング、ルート計算をClaude Codeに実装させる手順です。既定の選び方、APIキーの落とし穴もまとめます。
Amazon Location Serviceプラグインは、Amazon Web Servicesが配布するClaude Code用のプラグインです。「地図を出して」「住所を座標にして」「2地点のルートを引いて」と頼むと、Claudeが地図の描画、場所の検索、ルート計算のコードを、AWSの推奨する選び方で書いてくれます。
プラグインの中身はスキルが1つと、AWS MCPサーバーへの接続設定です。この記事では、導入の2通りの経路、スキルが既定で選ぶ認証や地図スタイル、頼み方の例、APIキーまわりの落とし穴を順に扱います。
このプラグインでClaudeに任せられる範囲
マーケットプレイスの説明では、プラグインは6つの領域を支援します。
- MapLibre GL JSによる対話的な地図
- 場所の検索とジオコーディング
- ルートの計算と最適化
- ジオフェンスとデバイス追跡
- 住所の検証
- APIキーの管理
認証設定、SDKの組み込み方、よくある失敗の回避策は、スキルが参照するドキュメントとして同梱されています。参照ドキュメントは用途別に分かれており、住所入力、住所検証、ルート計算、動的な地図、場所検索、Webでの使い方、デバイス追跡、ゾーン通知、そしてGoogleマップからの移行(Android・iOS・Web)です。
発火のきっかけになる語も決まっています。READMEに載っているのは「add a map」「geocode an address」「calculate a route」「location-aware app」「Amazon Location Service」「geospatial」「places search」です。日本語で頼んでも動くかどうかは記載がないので、スキルを確実に呼びたいときは「Amazon Location Serviceで」と一言添えると安全です。
導入は2通り、どちらでも同じプラグインが入る
このプラグインはAWSのリポジトリawslabs/agent-pluginsに入っており、Anthropicが管理するマーケットプレイスclaude-plugins-officialのカタログにも同じ参照先で登録されています。入れ方は2つあります。
Claude Codeへの入れ方
- 1
AWSのマーケットプレイスから入れる
AWSのリポジトリをマーケットプレイスとして追加し、そこから入れます。READMEの手順そのままです。
- 2
Anthropicのマーケットプレイスから入れる
claude.com/marketplaceの詳細ページにある「Claude Code」ボタンは、
@claude-plugins-official形式のコマンドをコピーします。追加の登録は要りません。
/plugin marketplace add awslabs/agent-plugins
/plugin install amazon-location-service@agent-plugins-for-aws後者を選ぶ場合のコマンドは次の形になります。
claude plugin install amazon-location-service@claude-plugins-officialどちらも入るのは同じプラグインです。AWSの他のプラグインもまとめて試すなら、1つ目の経路でマーケットプレイスを登録しておくと、@agent-plugins-for-awsの名前で並べて入れられます。インストール後は/reload-pluginsで現在のセッションに反映できます。@形式やスコープの違いはclaude plugin installの導入経路の記事で扱っています。
マーケットプレイスのページには、Claude Codeでの導入数が3,328件と表示されています。
前提:AWS MCPサーバーの起動に必要なもの
プラグインに同梱された.mcp.jsonは、aws-mcpという名前のMCPサーバーをuvxで起動する設定です。コマンドはmcp-proxy-for-aws@latestを、https://aws-mcp.us-east-1.api.aws/mcpにつなぎます。
つまり、手元にuvx(uvに含まれるコマンド)が必要です。AWSの認証情報も要ります。スキルは認証情報の設定をAWS MCPサーバーのGetting Startedガイドに委ねています。既定以外のリージョンを使うなら、MCP設定の引数に--metadataとAWS_REGION=<リージョン>を足します。
役割の分担も押さえておくと混乱しません。READMEのこのプラグインの欄では、aws-mcpの目的は「AWSのドキュメントとサービスガイダンス」です。地図やジオコーディングのコードそのものはスキルが書き、不足するAPIパラメータの確認にMCPサーバーを使う、という構成です。
頼み方の例とスキルが選ぶ既定値
マーケットプレイスのページは、使い方の例として次のようなプロンプトを挙げています。
- Amazon Location Serviceでウェブアプリにインタラクティブな地図を足す
- 場所検索のオートコンプリートを実装する
- 2つの住所間の運転ルートを計算して地図に表示する
- 住所を座標に変えるジオコーディングを設定する
- 決済フォームに住所検証を足す
頼むときは、既定値を知っておくと指示が短くなります。スキルの「Defaults」節は、利用者が明示しない限り次の選択をするとしています。
| 項目 | 既定 |
|---|---|
| JavaScript SDK | 既定ブラウザのみのアプリはCDNのバンドル版、Reactやビルドツールありのアプリはnpmのモジュール版 |
| API操作 | 既定地図・場所・ルートはリソース不要型(ジオフェンスと追跡は事前のリソース作成が必須) |
| 認証 | 既定地図・場所・ルートはAPIキー、ジオフェンスと追跡はCognito |
| 地図スタイル | 既定Standard |
| 座標の順序 | 既定経度, 緯度 |
上書きも一言でできます。スキルには「Maps/Places/RoutesにはCognitoを使う」「Reactでもバンドル版を使う」という言い方が例示されています。
Claude Code側でも既定を固定しておけます。たとえばプロジェクトのCLAUDE.mdに、次のような規約を書いておく方法です。
## 位置情報機能の規約
- 地図・場所検索・ルートはAmazon Location Serviceを使う
- 認証はAPIキー。キーは環境変数から読み、リポジトリに書かない
- 座標は[経度, 緯度]の順。配列を作るたびに順序をコメントで確認するこれはスキルの既定をプロジェクトの決まりとして重ねる書き方の一例です。経度と緯度の順は、地図ライブラリとAPIの両方で[経度, 緯度]なので、頭の中の「緯度、経度」の習慣と食い違いやすい箇所です。
地図、住所入力、ルートはこう組み立てられる
地図は直接URLでMapLibreに渡す
動的な地図の参照ドキュメントは、スタイル記述のURLをMapLibreに直接渡す書き方を必須としています。
const styleUrl =
`https://maps.geo.${REGION}.amazonaws.com/v2/styles/Standard/descriptor?key=${API_KEY}`;
const map = new maplibregl.Map({
container: "map",
style: styleUrl,
center: [-97.7723, 30.2672], // [経度, 緯度]
zoom: 10,
validateStyle: false,
});これはドキュメントに載っている最小例を、行を折って示したものです。選べるスタイルはStandard、Monochrome、Hybrid、Satelliteの4種類で、URLのStandardの部分を差し替えます。validateStyle: falseは読み込みを速くするための設定で、ドキュメントは検証をオンにすると500ミリ秒以上余計にかかると説明しています。
住所入力は3段階の流れ
住所入力フォームの参照ドキュメントは、次の3段階を示しています。
住所入力でどのAPIを呼ぶか
- Q利用者がまだ入力中ですか?答えが次の確認へ答えがはい
Autocompleteで候補を出します。
- Q候補を選びましたか?答えが次の確認へ答えがはい
GetPlaceにPlaceIdを渡し、詳細を取ります。
候補を選ばず送信した
Geocodeで入力された住所を座標に解決します。
候補の表示にはAddress.Labelを使い、Titleは使わない点も明記されています。Titleは構成要素が逆順で出ることがあり、利用者向けの表示に向かないためです。
ルートは出発地・目的地・移動手段から
ルート計算の参照ドキュメントの最小例は、CalculateRoutesに出発地、目的地、TravelModeを渡すだけです。TravelModeは必須で、Car、Truck、Scooter、Pedestrianから選びます。返り値のRoutes[0].Summaryから距離(メートル)と所要時間(秒)が読めます。複数の出発地・目的地ならCalculateRouteMatrix、到達圏ならCalculateIsolines、立ち寄り順の最適化ならOptimizeWaypointsと、用途別に使い分ける案内になっています。
落とし穴:APIキーのアクション名はIAMと違う
スキルの「Common Mistakes」には7項目が並びます。そのうち実装で最初に詰まりやすいのは、次の3つです。
落とし穴
APIキーの許可アクションにIAM風の名前を書くと拒否される
APIキーのAllowActionsにはgeo-places:Geocodeやgeo-routes:CalculateRoutesのように、geo-maps:・geo-places:・geo-routes:の接頭辞を使います。SDKのクライアント名(@aws-sdk/client-geo-places)や、古いgeo:接頭辞のIAM形式は、リソース不要型のAPIでは通りません。
- 地図の初期化にGetStyleDescriptor APIを呼ばない。前節のスタイルURLを直接渡す
- MapLibreのコンストラクタで
validateStyle: falseを忘れない
もう1つ知っておきたいのは、リソース不要型とリソース必須型の混在です。地図・場所・ルートはリソース不要型を使えば、事前にマップやプレイスインデックスを作らずに済みます。ジオフェンスと追跡はリソース必須なので、トラッカーやジオフェンスコレクションを先に作る必要があります。この違いを頼む前に伝えておくと、Claudeが無駄な構成を作りません。
住所検証は対応国に注意
住所検証は同期のGeocodeではなく、非同期のJobs APIを使います。StartJobにValidateAddressのアクションを指定し、GetJob・ListJobs・CancelJobで進捗を追います。入出力はAmazon S3上のParquetファイルです。
対象はアメリカ、カナダ、イギリス、オーストラリアの4か国のみで、それ以外の国にはGeocodeを使う、とスキルに書かれています。国内向けのサービスで住所の配達可否まで確かめたい場合、このJobs APIでは賄えないという意味です。1件だけ「この住所は解決できるか、どの程度一致したか」を見るなら、GeocodeのMatchScoresで足り、ジョブを立てる必要はないとも説明されています。
使う前に押さえたい注意点
READMEの冒頭には、生成AIは間違えることがあり、出力とコストを確認するよう注意書きがあります。同じ箇所に、後継として「Agent Toolkit for AWS」が公開されたことも書かれています。このリポジトリは引き続き動作し、貢献も受け付けますが、有用なプロジェクトは時間とともに後継へ移っていく、という説明です。
最小権限のAWS認証情報で使う、生成されたコードをデプロイ前に確認する、というベストプラクティスもREADMEに載っています。APIキーはブラウザに渡る値なので、使える操作とリファラー(呼び出し元ドメイン)を絞る設定が前提です。地図の参照ドキュメントも、操作の制限とドメインの制限、公開リポジトリに置かないことを勧めています。
AWSのほかのプラグインとの住み分けも見ておくとよいでしょう。構成の提案から見積もりまでを頼むならDeploy on AWSプラグインの記事、Lambdaを中心に作り込むならaws-serverlessプラグインの記事が対応します。位置情報だけを深掘りしたいときに、このプラグインが受け持ちます。
まとめ
導入はclaude plugin install amazon-location-service@claude-plugins-officialの1行か、AWSのマーケットプレイス経由の2行です。入れた後は、AWS MCPサーバー用のuvxと認証情報が揃っているかが最初の関門になります。
実装の質を左右するのは、頼み方よりも既定値の把握です。APIキー認証、リソース不要型、Standardスタイル、[経度, 緯度]の順という前提を共有し、APIキーのアクション名とスタイルURLの渡し方だけ確認すれば、生成されたコードの大半は読み通せます。