追記: 2026年6月8日の最新情報
このテーマをもう少し広げて見るなら、AWS Databases on Vercelが東京・大阪含むリージョン拡大：v0でAurora PostgreSQL/DSQL/DynamoDBを選ぶ前に確認すべきこと と 次世代Amazon OpenSearch Serverlessとは：AIエージェント検索基盤で確認すべきScale-to-zeroと移行条件 も合わせて確認してください。位置情報アプリをWebアプリとして組む場合に、フロントエンドとAWSデータ基盤のリージョン設計を合わせて確認できます。
2026年6月8日にAmazon Location ServiceのRoutes pricingドキュメントを確認したところ、CalculateRoutesの料金バケットではTransitがCore、IntermodalがPremiumに分類されています。公共交通だけの経路計算と、車・徒歩・タクシーなどを公共交通と組み合わせる複合移動では、費用の見方が分かれます。
Transit: バス、地下鉄、電車、フェリーなど公共交通を中心にした経路計算。料金確認ではCoreとして扱われます。Intermodal: 車、徒歩、タクシー、レンタルなどを公共交通と組み合わせる経路計算。料金確認ではPremiumとして扱われます。
実装前には、Developer GuideのRoutes pricing、公式Pricingページ、レスポンスヘッダーのx-amz-geo-pricing-bucketを合わせて確認すると、PoC後の費用差を見落としにくくなります。
Amazon Location ServiceのRoutes APIに、公共交通を扱うTransitと、複数の交通手段を1つの移動に組み合わせるIntermodalが追加されました。AWSの2026年6月2日発表では、提供リージョンにAsia Pacific (Tokyo)も含まれています。
ただし、ここでいう「東京リージョン対応」は、APIをそのリージョンで利用できるという意味です。日本国内のすべての路線や交通事業者、リアルタイム運行情報まで保証する話ではありません。
この記事では、2026年6月5日JST時点のAWS公式情報をもとに、開発者や導入企業が最初に確認すべき設計ポイントを整理します。本サイトはAmazonおよびAmazon Web Services, Inc.とは非提携です。
3行まとめ
公共交通向けのTransitと、複数の交通手段を組み合わせるIntermodalがRoutes APIに追加されました。
提供リージョンにAsia Pacific (Tokyo)は含まれますが、実際の路線カバレッジは別に確認します。
未対応フィールド、レッグ構造、料金バケット、SDKやCLIの更新状況を先に確認します。
公式発表、Developer Guide、API Reference、Pricingを横断して読むと判断しやすくなります。
- Amazon Location Service Routes APIで、公共交通向けの
Transitと、徒歩・公共交通・タクシー・レンタル・車などを組み合わせるIntermodalが発表されました。 - 提供リージョンにはAsia Pacific (Tokyo)が含まれますが、リージョン提供と日本の路線カバレッジは分けて確認する必要があります。
- 既存の車・徒歩・トラック向けRoutes API実装を流用する場合は、未対応フィールド、レッグ構造、料金バケット、SDK/CLIの更新状況を先に見ておくのが安全です。
Amazonの公式発表を読むときは、発表文だけで「すぐ使える」と判断せず、対象リージョン、Developer Guide、API Reference、Pricingを横断して見るのが基本です。公式ソースへ戻る入口は、固定ページの<a href="https://amzn-watch.blog.mo-gmo.com/source-checks/" rel="noopener">資料・確認ログ</a>にもまとめています。
Amazon Location Service Routes APIに何が追加されたのか
- 1TravelMode追加
CalculateRoutesでTransitとIntermodalを選べるようになった点が発表の中心です。
- 2ルートの考え方
公共交通では駅や停留所、徒歩区間、時刻、路線情報が重要になります。
- 3リージョン確認
APIを呼び出せるリージョンと、実際に扱いたい都市や時間帯の経路品質を分けて確認します。
東京リージョン対応だけでなく、利用予定地点で期待に近い経路が返るかを見ることが重要です。
AWSは2026年6月2日、Amazon Location ServiceのRoutes APIで公共交通とインターモーダル経路に対応したと発表しました。対象はCalculateRoutes操作で、旅行モードとしてTransitとIntermodalを使えるようになった、というのが発表の中心です。
従来のRoutes APIを「車や徒歩のルートを返すAPI」として使ってきたチームにとっては、単なるモード追加以上の意味があります。公共交通では駅や停留所までの徒歩区間、出発・到着時刻、路線情報が重要になります。インターモーダルでは、1つのルート内に徒歩、公共交通、タクシー、レンタル、車などの複数レッグが混ざる可能性があります。
発表の要点は2つの新しい旅行モード
まず押さえたいのは、TransitとIntermodalを同じものとして扱わないことです。
Transitは公共交通を中心にした経路計算です。AWSのDeveloper Guideでは、バス、地下鉄、鉄道、フェリーなどの公共交通ネットワークを使い、停留所や駅までの徒歩レッグを含むと説明されています。つまり、利用者に「公共交通でどう行くか」を出したい場合の入口になります。
Intermodalは、複数の交通手段を1つの移動に組み合わせるモードです。Developer Guideでは、徒歩、公共交通、レンタル、タクシー、車のレッグが出る可能性があると説明されています。パークアンドライド、タクシーアンドライド、ラストワンマイル補完のように、最初から複数手段を前提にした体験で使いやすい設計です。
発表文では、モビリティ、物流、従業員通勤、都市計画といった用途例も示されています。ここで大事なのは、「物流」という語が出ているからといって、トラック制約や配送最適化がそのままTransit/Intermodalに置き換わるわけではない点です。人の移動や施設アクセスを含む業務導線と、車両運行そのものは分けて考える必要があります。
東京リージョン対応と交通カバレッジは分けて読む
AWS What’s Newの提供リージョン一覧には、US East (Ohio)、US East (N. Virginia)、US West (Oregon)、Asia Pacific (Mumbai)、Asia Pacific (Sydney)、Asia Pacific (Tokyo)、Canada (Central)、Europe (Frankfurt)、Europe (Ireland)、Europe (London)、Europe (Stockholm)、Europe (Spain)、South America (Sao Paulo)が含まれています。
日本の読者にとってはAsia Pacific (Tokyo)が入っている点が目を引きます。ただし、ここで確認できるのは、東京リージョンでこの機能が提供対象に入っているという事実です。東京近郊の各路線、地方都市、バス事業者、フェリー、リアルタイム運行情報などの具体的な対応範囲は、今回確認したAWS公式発表だけでは断定できません。
導入前の評価では、次の2つを別々に見るのが実務的です。
- APIとして呼び出せるリージョンに、利用予定リージョンが含まれているか
- 実際に扱いたい都市、施設、駅、停留所、時間帯で期待に近い経路が返るか
前者は発表文で確認できます。後者は、自社の主要地点でサンプルリクエストを投げ、レスポンスのレッグ、時刻、路線名、徒歩区間、代替ルートを確認する領域です。公式発表だけで「日本の公共交通アプリにそのまま使える」と決めるのは早いです。
TransitとIntermodalの違いを設計目線で見る
勝ち負けではなく、サービスで説明したい移動体験に合わせて使い分ける比較です。
TransitとIntermodalの違いは、UIやデータモデルにも影響します。どちらも公共交通に関係しますが、返ってくるルートの考え方が違います。
| 確認軸 | Transit | Intermodal |
|---|---|---|
| 主な目的 | 公共交通を使った点から点への移動 | 複数の交通手段を組み合わせた移動 |
| 主なレッグ | 公共交通、徒歩 | 徒歩、公共交通、レンタル、タクシー、車 |
| 向いている用途 | 来訪案内、通勤経路、施設アクセス | パークアンドライド、タクシー連携、ラストワンマイル |
| 制御の中心 | AllowedModes、ExcludedModes | レッグごとのEnabledFor、AllowedModes、ExcludedModes |
| 注意点 | 未対応トップレベルフィールドがある | 徒歩レッグは接続用に常に有効、TurnByTurnなどに制約がある |
Transitは公共交通中心の経路を計算する
Transit routingでは、公共交通ネットワークを使って経路を計算します。Developer Guideで列挙されている対応モードには、Bus、Subway、CityTrain、Ferry、HighSpeedTrain、LightRail、Monorailなどが含まれています。
実装上のポイントは、交通モードの絞り込みです。Transit routingでは、デフォルトですべての公共交通モードが許可されます。必要に応じてAllowedModesまたはExcludedModesを使えますが、この2つは同じリクエストで併用できません。
たとえば、鉄道と地下鉄だけを候補にしたいのか、フェリーを除外したいのか、バスを含めるのかで、APIに渡す条件とユーザーへの説明が変わります。ユーザーに「公共交通」とだけ見せるのか、「バスを使う」「鉄道だけにする」のように選択肢を出すのかも、先に決めておきたい部分です。
確認項目
Transit routingでは、他の旅行モードと比べて未対応のトップレベルフィールドがあります。Developer Guideでは、Allow、Avoid、Driver、Exclude、OptimizeRoutingFor、SpanAdditionalFeatures、Tolls、Traffic、TravelStepType、Waypointsなどが、Transit設定時に対応しないフィールドとして挙げられています。
既存のCar向けリクエストをそのままTransitへ切り替えると、これらの指定が問題になる可能性があります。最初は最小リクエストでルートが返ることを確認し、その後に必要なオプションを足していく方が安全です。
Intermodalは複数の交通手段を1ルートに混ぜる
Intermodal routingは、1つの移動を複数のレッグに分けて扱うための機能です。Developer Guideでは、IntermodalのレッグとしてPedestrian、Transit、Rental、Taxi、Vehicleが説明されています。Pedestrianは、他のレッグをつなぐ徒歩区間として常に有効で、無効化できません。
Intermodalで重要なのは、どの交通手段をどの区間で許可するかです。たとえば、出発地から駅まではタクシーを許可し、駅から目的地付近までは公共交通、最後は徒歩にしたい場合、ユーザーにとって自然な導線になるかを確認する必要があります。
Developer Guideでは、Transit、Rental、Taxi、Vehicleのレッグについて、EnabledForでFirstLeg、LastLeg、EntireRoute、Noneを使い分けられると説明されています。これにより、車やタクシーをルート全体で許すのか、最初または最後の区間だけにするのかを制御できます。
条件
IntermodalもAllowedModesとExcludedModesを使えますが、Transitと違い、交通手段ごとのレッグ単位で設計する発想が必要です。ユーザーに提示する選択肢と、API側で探索に含める交通手段を同じにすると、画面が複雑になりすぎる場合があります。
たとえば「公共交通優先」「タクシーを最後だけ許可」「車を最初だけ許可」のように、サービス側のプリセットを作る方が使いやすいこともあります。Intermodalは便利な一方で、利用者に説明できない経路を返してしまうと、不安の方が先に立ちます。
既存のCar/Pedestrian/Truck設計から変わるところ
既存のRoutes API実装がある場合、TravelModeを差し替えるだけで本番投入できるとは限りません。まず見るべきは、リクエストで使っているトップレベルフィールドと、レスポンスを前提にしたUIです。
CarやTruck向けの設計では、Avoid、Traffic、Tolls、OptimizeRoutingFor、Waypointsなどを使っていることがあります。TransitやIntermodalでは、Developer Guideに未対応フィールドが明記されています。つまり、既存のリクエストビルダーを共通化しているほど、モードごとのパラメータ分岐が必要になります。
レスポンス側も同じです。車ルート前提のUIは、1本のポリライン、所要時間、距離、曲がり角案内を中心に作られがちです。公共交通やインターモーダルでは、徒歩区間、乗車区間、乗り換え、到着時刻、路線名、レッグごとの説明が必要になります。
評価基準
導入判断では、移動時間だけを比較しない方がよいです。少なくとも、次の観点をサンプル地点で確認します。
- レッグの種類と順序が、ユーザーに説明できるか
- 徒歩区間と公共交通区間をUIで自然に分けられるか
- 出発時刻や到着時刻の指定が期待通り効くか
- 代替ルートの数と内容が、サービスの選択肢として多すぎないか
- 既存のCar/Truck向けオプションが混ざっていないか
- 料金バケットとログ設計を確認できるか
このあたりまで確認して初めて、「新しい旅行モードを入れるだけで済むか」「UIやデータモデルを直す必要があるか」が見えてきます。
使いどころはどこか
オフィス、店舗、イベント会場、病院、キャンパスなどへの公共交通と徒歩の案内に向きます。
駅、駐車場、施設、最終目的地が分かれるサービスではIntermodalの検討余地があります。
車両運行や配送最適化が主目的なら、Truckや既存Routes機能との切り分けが必要です。
Amazon Location Serviceが自動的に業務の最適解を返すわけではなく、用途ごとの検証が必要です。
今回の機能は、消費者向けの地図アプリだけを想定するものではありません。企業の来訪導線、従業員通勤、都市計画、モビリティ連携、フィールド業務など、位置情報を含むアプリケーション全般で検討余地があります。
一方で、Amazon Location Serviceが自動的に自社業務の最適解を返してくれるわけではありません。ユースケースごとに、Transitで足りるか、Intermodalが必要か、既存Routesのままがよいかを分ける必要があります。
従業員通勤、来訪案内、施設アクセス
最も分かりやすい用途は、オフィス、店舗、イベント会場、病院、キャンパスなどへのアクセス案内です。これまで車や徒歩中心の経路しか出していなかったアプリでも、公共交通と徒歩を組み合わせた案内まで広げられます。
たとえば、施設予約、イベント参加、面接案内、法人向け来訪管理などでは、利用者が自家用車ではなく公共交通で移動することも多いです。Transitを使えば、目的地までの公共交通と徒歩の導線を候補にできます。
上振れ
車中心の経路案内では拾えなかった利用者に対して、駅や停留所からの徒歩接続を含めた案内を出せる場面があります。施設の入口が分かりにくい場合、徒歩区間をどう表示するかは利用体験に直結します。
下振れ
期待値が高い領域でもあります。公共交通の時刻、路線名、乗り換え、徒歩区間の精度が利用者の現実とずれると、信頼を落とします。導入前には、自社にとって重要な地点だけでも、実際のルート候補を確認しておく必要があります。
ラストワンマイル、パークアンドライド、タクシー連携
Intermodalが向きやすいのは、移動全体を1つの交通手段だけで完結しないケースです。駅まで車で行く、最寄り駅から目的地まではタクシーを使う、レンタルや徒歩で最後の区間を補う、といった導線が候補になります。
この場合、ユーザーに選ばせる選択肢と、裏側で許可する交通手段を丁寧に設計する必要があります。すべての交通手段を常に許可すると、ユーザーにとって意味の分からないルートが出るかもしれません。
確認項目
最初に見るべきは、EnabledForの設計です。タクシーをFirstLegだけにするのか、LastLegだけにするのか、EntireRouteにするのかで、返るルートの性格は変わります。車を含める場合も、駐車場や乗り換え地点をどう扱うかを決めてから検証した方がよいです。
物流・フィールド業務では万能ではない
AWSの発表文には物流という用途例もあります。ただし、配送ルートや車両運行の最適化をすべてTransit/Intermodalで置き換える、と読むのは危険です。
物流やフィールド業務では、トラック制約、積載、休憩、配送時間帯、複数訪問先、通行規制、作業者のシフトなどが絡みます。Amazon Location Service Routesには、Truck、Matrix Routing、Waypoint Sequencing、Isoline、Snap to Roadsなどの別機能もあります。Transit/Intermodalは、人の移動や複合交通の導線を扱う選択肢として見る方が自然です。
注意点
配送ドライバー向けの最短順序、トラックの通行制限、複数地点の最適化を、TransitやIntermodalに寄せすぎると設計が崩れます。業務アプリでは、「作業者が公共交通で移動する場面」と「車両を最適運行する場面」を分けて、必要なAPIを選ぶべきです。
AWSサービスの更新を設計変更として読む姿勢は、<a href="https://amzn-watch.blog.mo-gmo.com/amzn-18-aws-app-runner-maintenance-ecs-express-mode/" rel="noopener">AWS App Runner新規受付停止後の確認ポイント</a>でも扱いました。サービス名は違っても、発表文、Developer Guide、Pricing、移行・運用条件を分けて読む流れは共通です。
東京リージョンで試す前に見る実装チェックリスト
- 最小リクエスト
同じOriginとDestinationでTransitとIntermodalを別々に試し、レッグや通知を確認します。
- Options追加
DepartureTime、MaxAlternatives、LegGeometryFormat、AllowedModes、ExcludedModesを段階的に足します。
- Intermodal設定
EnabledForをどの区間に使うか、徒歩区間や公共交通区間をUIでどう分けるかを確認します。
- 料金ログ
レスポンスヘッダーのx-amz-geo-pricing-bucketを記録し、検証時点から料金確認につなげます。
既存のCarやTruck向けパラメータをそのまま流用せず、モードごとの差分を見ながら足していきます。
東京リージョンで試す場合も、最初から本番相当の複雑なリクエストを投げる必要はありません。まずは小さく、同じ出発地と目的地でTransitとIntermodalの差を確認します。
| 確認項目 | 見ること |
|---|---|
| リージョン | Asia Pacific (Tokyo)が提供対象に含まれることを発表文で確認する |
| 認証 | API keyまたはSigV4署名の利用方針を決める |
| TravelMode | TransitとIntermodalを別々に試す |
| Options | AllowedModes、ExcludedModes、EnabledForを最小限から足す |
| 未対応フィールド | Avoid、Traffic、Tolls、Waypointsなどをモードごとに確認する |
| レスポンス | レッグ種別、徒歩区間、時刻、路線情報、通知を確認する |
| 料金 | x-amz-geo-pricing-bucketと公式料金ページを見る |
| フォールバック | 返らない、期待と違う、料金が想定と違う場合の代替を決める |
最小リクエストでTravelMode差分を見る
最初は、同じOriginとDestinationでTransitとIntermodalを比べます。CalculateRoutes API Referenceでは、OriginとDestinationが必須パラメータとして説明され、座標はWGS 84形式の[longitude, latitude]で指定します。
この時点で見るのは、正確なアプリ完成形ではありません。ルートが返るか、レッグがどう分かれるか、時刻や路線情報が期待に近いか、通知やエラーが出るかを確認します。
確認項目
小さな検証では、次の順に足していくと差分を追いやすいです。
DepartureTimeまたは到着時刻の扱いMaxAlternativesで代替ルートを出すかLegGeometryFormatをFlexiblePolylineにするかSimpleにするかAllowedModesやExcludedModesで交通モードを絞るか- Intermodalで
EnabledForをどの区間に使うか - レスポンスヘッダーの
x-amz-geo-pricing-bucketを記録するか
実測ログを残す場合は、架空の結果を混ぜないことが重要です。この記事ではAPI実行結果を載せていないため、実測のような書き方はしていません。
既存パラメータをそのまま流用しない
既存のRoutes API実装があるチームほど、共通のリクエスト生成ロジックに注意が必要です。CarやTruck向けに作ったオプションが、TransitやIntermodalでは未対応になることがあります。
Transit routingとIntermodal routingのDeveloper Guideでは、いずれもAllow、Avoid、Driver、Exclude、OptimizeRoutingFor、SpanAdditionalFeatures、Tolls、Traffic、Waypointsなどが未対応フィールドとして示されています。Intermodalではさらに、TravelStepTypeのTurnByTurnが未対応とされています。
注意点
「既存の車ルートAPIにTravelModeだけ追加する」という変更は、コード差分としては小さく見えます。しかし、バリデーション、エラー処理、画面表示、料金ログまで含めると、影響範囲は広がります。
少なくとも、モード別に許可するパラメータをホワイトリスト化し、未対応フィールドを送らない設計にした方が保守しやすいです。
UIとデータモデルはレッグ構造に合わせる
Intermodalの導入で大きく変わるのは、レスポンスをどう見せるかです。単一の車ルートなら、出発地、目的地、距離、所要時間、曲がり角案内で足りる場合があります。複合移動では、区間ごとに意味が違います。
徒歩で駅へ向かう、公共交通に乗る、タクシーで目的地付近へ移動する、最後に徒歩で到着する。こうしたルートを1本の線だけで表示すると、利用者はどこで何をすればよいか分かりません。
評価基準
UI側では、次の要素を検討します。
- レッグごとのアイコンやラベル
- 乗り換え地点と徒歩区間の見せ方
- 出発・到着時刻の表示
- 代替ルート比較の粒度
- ユーザーが選んだ条件とAPI側の探索条件の整合
- ルートが返らなかった場合のメッセージ
このあたりはAPIの成否だけでは判断できません。実際に利用者が見る画面や通知に落とし込んで、初めて導入可否を判断できます。
料金と制約はどこで確認するか
- 1公式Pricing
無料利用枠と、無料枠を超えたリクエスト課金の考え方を確認します。
- 2Routes pricing
CalculateRoutesのCore、Advanced、Premiumの料金バケットを確認します。
- 3PricingBucket
x-amz-geo-pricing-bucketをログに残し、TravelModeやOptionsごとの差を見ます。
- 4本番コスト
ルート数、レッグ数、エラー、通知、主要なTravelModeOptionsを一緒に記録します。
無料枠の確認と本番コストの見積もりは別の作業として扱うと、判断を誤りにくくなります。
Amazon Location Serviceの料金は、サービス全体のPricingページだけでなく、Developer GuideのRoutes pricingも合わせて確認します。今回のTransit/Intermodalでは、料金バケットの扱いを実装時に必ず見たいところです。
Amazon Location Service Pricingページでは、無料利用枠を超えた利用はサービスへのリクエストに応じて課金されると説明されています。また、価格はリクエストパラメータによって変わる可能性があり、Developer GuideのPricingセクションを参照するよう案内されています。
CalculateRoutesは料金バケットを見る
Routes pricingでは、CalculateRoutesにCore、Advanced、Premiumの3つの料金バケットがあると説明されています。CoreはCar、Truck、Pedestrianを、通行料金計算なしで扱うバケットです。AdvancedはScooterなどの代替旅行モードを、通行料金計算なしで扱うバケットとして説明されています。Premiumは通行料金計算をリクエストした場合に適用されます。
ここで注意したいのは、確認時点のRoutes pricing本文が、TransitやIntermodalを名指しで料金バケットに割り当てているわけではないことです。新しい旅行モードは「alternative travel modes」に含まれる可能性がありますが、記事内で単価やバケットを断定するより、実装時に公式ページとレスポンスヘッダーを確認する方が安全です。
根拠
API Referenceでは、成功時のHTTPレスポンスヘッダーとしてx-amz-geo-pricing-bucketが示され、Response ElementsにもPricingBucketが「課金される料金バケット」として説明されています。テスト時はこの値をログに残し、想定と違うバケットになっていないかを見るのが現実的です。
PricingBucketレスポンスをログで見る
料金の確認は、料金表を一度読むだけでは足りません。実際のリクエストがどのバケットに入ったかをログで見る必要があります。
たとえば、Routes pricingでは、LegAdditionalFeatures["Tolls"]またはSpanAdditionalFeatures["TollSystems"]を指定して通行料金計算をリクエストした場合、旅行モードに関係なくPremium価格になると説明されています。TransitやIntermodalの検証でも、追加フィールドが想定外の料金に影響していないかを確認したいところです。
確認項目
検証ログには、少なくとも次を残します。
- リージョン
TravelMode- 主要な
TravelModeOptions LegAdditionalFeaturesとSpanAdditionalFeatures- レスポンスヘッダーの
x-amz-geo-pricing-bucket - ルート数、レッグ数、エラーまたは通知
個人情報や正確な自宅・顧客住所をログに残す必要はありません。検証用の代表地点を使い、費用と仕様の判断に必要な情報だけを残す方が扱いやすいです。
無料枠と本番コストは別に見る
Amazon Location Service Pricingページでは、新規AWS顧客向けのFree Tier creditsや、Amazon Location Serviceの無料利用枠が説明されています。Routesについては、無料利用枠として一定数のRoutesまたはRoute Matrix計算が含まれています。
無料枠は検証の入口として便利です。ただし、本番コストの判断とは分ける必要があります。TransitやIntermodalは、ユーザーが検索条件を変えながら何度もリクエストする可能性があります。代替ルート、時刻変更、交通手段の絞り込み、再検索が増えると、想定よりリクエスト数が増えることがあります。
注意点
料金はAWSの公式ページで変更される可能性があります。この記事では2026年6月5日時点の確認内容をもとに、金額ではなく確認手順を重視しています。最終的な見積もりでは、公式料金ページ、Routes pricing、検証ログ、アプリの予想リクエスト数をセットで見てください。
API Referenceの更新差分にも注意する
- What’s New
TransitとIntermodalが発表された事実と、提供リージョンを確認します。
- Developer Guide
Transit routingとIntermodal routingの使い方、制約、対応モードを確認します。
- API Reference
CalculateRoutesのTravelMode、TravelModeOptions、未対応フィールドの表示を確認します。
- SDK・CLI
実際に使うSDKやCLIで新しい値を扱えるか、本番外の小さなテストで確認します。
2026年6月5日時点の確認では、発表とAPI Reference表示の更新差分にも注意が必要です。
今回の確認で気になった点があります。AWS What’s NewとDeveloper GuideではTransitとIntermodalが追加されたことを確認できます。一方、2026年6月5日時点で確認したCalculateRoutes API ReferenceのTravelMode欄は、表示上のValid ValuesがCar | Pedestrian | Scooter | Truckにとどまり、TransitとIntermodalが見当たりませんでした。
これは、公式発表とAPI Referenceの更新タイミング差である可能性があります。だからといって、What’s Newの発表が無効になるわけではありません。ただし、実装前にはSDK、CLI、API Reference、Developer Guideのどれを根拠にするかを確認しておくべきです。
差分があるときは保守的に扱う
公式ページ同士で表示に差がある場合、記事や設計書では新しい値を断定的な実装手順として書き切らない方が安全です。今回でいえば、発表とDeveloper GuideでTransitとIntermodalの追加は確認できます。一方で、API ReferenceやSDKの表示が追いついていない環境では、ビルドや入力バリデーションで止まる可能性があります。
注意点
実装判断では、公式発表を根拠に検証を始めつつ、実際に使うSDKやCLIで受け付けられるかを別に見る必要があります。ドキュメントのどのページを根拠にしたか、確認日と一緒に残しておくと、後から仕様差分を追いやすくなります。
実装チームが見るべき順番
実装チームには、次の順で確認することをおすすめします。
- What’s Newで発表日、提供リージョン、対象APIを確認する
- Transit routingとIntermodal routingのDeveloper Guideで機能差と制約を確認する
- CalculateRoutes API Referenceで必須パラメータ、レスポンス、エラー、
PricingBucketを確認する - 利用するSDKやCLIで、
TransitとIntermodalが型定義や入力スキーマとして使えるか確認する - 東京リージョンで最小リクエストを投げ、エラー、通知、料金バケットを記録する
この順番なら、公式発表を無視せず、実装時の落とし穴も拾えます。
判断基準
Developer Guideでは機能が説明されているのに、手元のSDKで型定義が追いついていない場合があります。その場合は、SDKの更新、CLIの更新、Raw API呼び出し、または導入時期の調整を検討します。
本番投入前には、CIで使うSDKバージョンと実行環境を固定し、ドキュメント更新だけでなく、自分たちの環境で動くことを確認してください。
この記事の結論として置く判断表
東京リージョン対応だけで即採用とせず、目的と検証ポイントを分けて判断します。
今回のAmazon Location Service更新は、公共交通や複合移動をアプリに組み込みたいチームには大きな選択肢です。一方で、東京リージョン対応を見ただけで即採用と判断するには、まだ確認すべき点があります。
| 判断 | 向いている条件 | 先に見ること |
|---|---|---|
| Transitを試す | 公共交通と徒歩で目的地まで案内したい | 路線情報、徒歩区間、出発・到着時刻、未対応フィールド |
| Intermodalを試す | 車、タクシー、レンタル、公共交通を組み合わせたい | レッグ構造、EnabledFor、UI表示、説明可能性 |
| 既存Routesのまま確認を続ける | 車両運行や配送最適化が主目的 | Truck、Matrix Routing、Waypoint Sequencing、既存機能 |
Transitを先に試すケース
目的地までの公共交通と徒歩の導線を出したい場合は、まずTransitから試すのが自然です。来訪案内、通勤支援、施設アクセス、イベント案内などでは、Transitだけで十分に価値が出る可能性があります。
評価基準
対象地点を数カ所選び、時刻を変えて、利用者が納得できる経路が返るかを見ます。路線名、徒歩区間、所要時間、乗り換え、代替ルートの表示がアプリのUIに収まるかも確認します。
Intermodalを試すケース
車、タクシー、レンタル、公共交通を組み合わせる価値がある場合はIntermodalを検討します。駐車場、駅、施設、最終目的地が分かれているサービスや、モビリティ連携のあるアプリでは候補になります。
評価基準
EnabledForで交通手段を制御したとき、返るルートをユーザーに説明できるかを見ます。便利そうに見えても、なぜその区間だけタクシーなのか、なぜ車を使うのかが説明できない場合、本番UIには向きません。
まだ様子見にするケース
交通データのカバレッジ、料金、レスポンス仕様、SDK対応、UI改修コストが読めない場合は、まず本番外の小さなテストに留めるのが妥当です。特に、日本の個別路線や交通事業者対応を前提にするサービスでは、自社の対象地点での結果確認が欠かせません。
確認項目
様子見にする場合でも、次に何が確認できれば進めるかを決めておきます。たとえば、公式ドキュメントの更新、SDK対応、料金バケットの確認、主要地点でのサンプル結果、ユーザー向けUIの試作などです。
Amazon/AWSの製品・サービス更新を続けて追う場合は、<a href="https://amzn-watch.blog.mo-gmo.com/category/products-services-solutions/" rel="noopener">製品・サービス・ソリューション</a>カテゴリと、<a href="https://amzn-watch.blog.mo-gmo.com/source-checks/" rel="noopener">資料・確認ログ</a>もあわせて確認してください。
Amazon Watch Japanでは、Amazon/AWSの公式発表、製品・サービス更新、噂確認、月次まとめの更新を非提携の立場で追っています。更新通知は<a href="https://amzn-watch.blog.mo-gmo.com/newsletter/" rel="noopener">ニュースレター</a>から受け取れます。
次に読むなら
参照した主な情報源
- Amazon Location Service announces public transit and intermodal routing – AWS What’s New（確認日: 2026年6月5日）
https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-location-service/amazon-location-new-public-transit-intermodal-routing/
- Transit routing – Amazon Location Service Developer Guide（確認日: 2026年6月5日）
https://docs.aws.amazon.com/location/latest/developerguide/transit-routing.html
- Intermodal routing – Amazon Location Service Developer Guide（確認日: 2026年6月5日）
https://docs.aws.amazon.com/location/latest/developerguide/intermodal-routing.html
- Amazon Location Service Routes – Amazon Location Service Developer Guide（確認日: 2026年6月5日）
https://docs.aws.amazon.com/location/latest/developerguide/routes.html
- CalculateRoutes – Amazon Location Service API Reference（確認日: 2026年6月5日）
https://docs.aws.amazon.com/location/latest/APIReference/API_CalculateRoutes.html
- Routes pricing – Amazon Location Service Developer Guide（確認日: 2026年6月5日）
https://docs.aws.amazon.com/location/latest/developerguide/routes-pricing.html
- Amazon Location Service Pricing（確認日: 2026年6月5日）
https://aws.amazon.com/location/pricing/
更新履歴: 2026年6月5日、AWS What’s New、Amazon Location Service Developer Guide、CalculateRoutes API Reference、Routes pricing、Amazon Location Service Pricingを確認して初稿を作成しました。API ReferenceのTravelMode表示には確認時点で更新差が見えるため、本文ではSDK/CLI確認を必須の実装前チェックとして扱っています。