ブログ

Isochrones API の仕様とパラメータ選定のポイント

2026.07.03
最新アップデート

皆様、こんにちは！
Google Maps Platform のプロフェッショナル集団、ゴーガです。

先日、Isochrones API の紹介記事を公開しましたが、今回は実際にその API を使ってみた内容の投稿になります。本記事では具体的なリクエストの構築、レスポンスの構造などをコードを交えて詳しく解説します。さらに、弊社メンバーが実際にさまざまな条件下で API にリクエストをして検証したリアルな挙動や注意点についてもお届けします。

Isochrones API のリリースステータスについて
本ブログ執筆時点では、Isochrones API はプレビュー版として提供されています。そのため、サポートが限定的である可能性や、今後のアップデートによって仕様が変わる可能性があります。あらかじめご了承の上、最新情報は公式のドキュメンテーションをご確認ください。
https://developers.google.com/maps/documentation/isochrones

リクエスト方法

Isochrones API は、以下のような HTTP POST リクエストを送信して使用します。

HTTP リクエスト

POST https://isochrones.googleapis.com/v1/isochrones:generate?key=YOUR_API_KEY
Content-Type: application/json

リクエストボディ JSON の例

「東京駅から車で 15 分（900 秒）以内に到達できる範囲」を取得する設定にしてみます。

{
  "location": {
    "latitude": 35.68098,
    "longitude": 139.767057
  },
  "travel_duration": "900s",
  "travel_mode": "DRIVE",
  "routing_preference": "TRAFFIC_UNAWARE",
  "enable_smoothing": false,
  "travel_direction": "FROM"
}

主要なパラメータの解説

location または place（必須）
場所を緯度経度もしくは Place ID で指定します。

  • location: 緯度経度（latitude / longitude）をセットして渡します。
  • place: Places API から取得ができる Place ID を指定します。指定する際のフォーマットは places/{PLACE_ID} となります。

travel_duration（必須）
移動時間を秒単位で設定します。
（例: 10 分であれば "600s" のように、末尾に s をつけた文字列で指定します）

travel_mode（必須）
DRIVE、WALK または BICYCLE のいずれかを文字列で指定します。

  • DRIVE: 歩道などを無視し、車が走行できる最寄りの車道を使って等時線を計算します。
  • WALK: なるべく歩道や歩行者専用道路を優先して計算します。
  • BICYCLE: 自転車を使った移動として等時線を計算します。

travel_direction（必須）
FROM と TO のいずれかを文字列で指定します。一方通行の道路や時間帯による渋滞を考慮するため、この2つでは返ってくる等時線の形が変わります。

    • FROM: 指定した場所から出発して、どこまで行けるか
      • ユースケース（ピザのデリバリー）: お店の場所を今出発して、30 分以内に届けられる配達エリアはどこまでか（お店から外へ向かうルート）
    • TO: 指定した場所へ向かって、どこから来られるか
      • ユースケース（不動産）: 勤務先のオフィスに歩いて 30 分以内で通える物件のエリアはどこか（各物件からオフィスへ向かうルート）

routing_preference
travel_mode が DRIVE の時にのみ、等時線を計算する際に「交通状況（渋滞など）」を考慮に入れるかどうかを設定することができます。

  • TRAFFIC_UNAWARE: デフォルトの値です。交通状況（渋滞）を考慮せずに計算します。
  • TRAFFIC_AWARE: リアルタイムの交通状況や渋滞予測を考慮して計算します。

平日の夕方など、より現実的な自動車の到達圏を知りたい場合は TRAFFIC_AWARE をセットするのがおすすめです。

enable_smoothing
等時線のポリゴンの輪郭を滑らかにするかどうかを設定します。 true または false で指定します。

  • false: 内部で計算された格子状のマス目の形のポリゴンがそのまま返ってきます。そのため、等時線の縁がギザギザ（階段状）になります。ある地点がエリア内に厳密に含まれているかの判定など、分析の正確性を重視したい場合に最適です。
  • true: セルの角を丸めて滑らかにしたポリゴンを返します。カクカクしていない綺麗な等時線になるため、地図上に美しく描画してユーザーに見せたい場合（ビジュアル重視）に最適です。

例: それぞれ（左）enable_smoothing = false、（右）enable_smoothing = true の時
Isochrones API 8

考察
enable_smoothing を false にした場合に取得できるポリゴンですが、このギザギザした出力形状から、API の内部的なエリア判定のベースには、位置情報の世界でグローバルスタンダードとして広く使われている S2 セルが利用されていることが推測できます。

S2 セル（S2 Geometry）とは？
Google が開発した、地球全体を四角い「マス目（格子）」で細かく区切って管理する仕組みです。地図をデジタルなパズルのように細かく敷き詰めることで、「指定されたエリアに何秒で到達できるか」といった複雑な計算をコンピューターが一瞬で計算できるようにするための世界標準的な技術です。

polygon_fidelity
等時線を計算するためのベースとなる「格子セル（解像度）」のサイズをコントロールします。こちらのパラメータを指定しない（デフォルト）場合は、API が移動時間に応じて最適な解像度を自動で選択（自動モード）します。

  • LOW
    • 大きめの格子セルを使用します。エリア全体をカバーするのに向いていて、大まかな形状のポリゴンになります。また、ポリゴン内部の「穴あき」の発生も抑えることができます。
  • MEDIUM
    • 精度とデータ量のバランスが取れた標準的な解像度です。
  • HIGH
    • 小さめサイズの格子セルを使用します。最も精度の高い形状になりますが、道路網がまばらな場所（大きな公園や、地図に載っていない私有地、工業地帯など）がエリアの真ん中にあった場合、そこが到達できない「穴あき」のポリゴンになりやすい特徴があります。

    解像度（polygon_fidelity）選びのヒントと「穴あき」の対策

    通常の開発においては、API が移動時間に基づいて最適化してくれるデフォルトの「自動モード」や、最も正確な「HIGH」を選択すれば基本的には道路網に沿った綺麗な等時線が返ってきます。

    では、なぜ明示的に LOW や MEDIUM に下げる選択肢があるのでしょうか？公式ドキュメントのベストプラクティスでも触れられているように、ここには「エンドユーザー向けに、地図上の視認性を高めて情報をわかりやすく提示する」という目的があります。
    例えば、道路が少ない広大な敷地（大きな施設や公園、川など）があるエリアをリクエストすると、詳細度が高いゆえに、等時線の中にぽっかりと穴あきができることがあります。
    もし不動産サイトや店舗検索などで、「駅から徒歩 15 分圏内のエリア」をユーザー向けにわかりやすく提示したい場合、厳密にくり抜かれた複雑な形状を表示するよりも、「全体として大まかにこのエリアが対象です」とシンプルに面でカバーして見せる方が、直感的で親しみやすい画面デザインになるケースが多いはずです。また、境界線付近にある周辺のスポットに対しても、ユーザーが興味を持って検討しやすくなる効果が期待できます。
    あえて解像度を少し調整し、先ほど紹介した enable_smoothing = true と組み合わせることで、地図としての視認性とすっきりとした見栄えを保ち、UI/UX を最優先にしたアプローチが可能になります。

    とはいえ、解像度を LOW や MEDIUM にしたとしても完全に「穴あき」をなくすことはできません。また、公式ドキュメントの FAQ にも記載されているように、「穴を自動的に埋めるパラメータ」は API には用意されていないため、どうしても「穴の無いすっきりとした見栄え」や UI/UX を最優先にしたい場合は、フロントエンド側で Turf.js などの GIS ライブラリを用いて、GeoJSON の「外側の座標だけ」を抽出して中の穴をプログラムで閉じることも可能です。実装の手間やデータサイズ（重さ）はそのまま残りますが、データの正確性を保ちつつ、見た目だけを穴なしに制御することは可能です。

【検証結果】解像度と移動種別ごとの挙動・注意点

(※本検証は現時点のプレビュー版における挙動であり、将来の GA 時には変更される可能性があります)

ここからは、弊社エンジニアが実際に様々なパターンでリクエストを送り、出力結果を比較して見えてきた Isochrones API のリアルな仕様と検証結果を共有したいと思います。

1. 「解像度（polygon_fidelity）」による穴あきの傾向

等時線の中に現れる「到達できないエリア（穴あきポリゴン）」ですが、検証の結果、含まれる穴の数は解像度によって明確に異なり、以下の順に多くなることが分かりました。

LOW < MEDIUM < 自動 < HIGH

基本的には解像度が高くなるほど道路網を厳密にチェックするため穴が増えますが、LOW (低) であっても必ず穴の数が 0 になるわけではないという点は、システムに組み込む上で知っておくべきポイントです。

2. 移動種別ごとの解像度（自動 vs 高）の特性

解像度（polygon_difelity）が、デフォルトの「自動」と、最高精度の「HIGH (高)」でどのような違いが出るかを移動種別ごとに検証しました。

徒歩 (WALK): 一貫して「自動」の方がポリゴンの凹凸が多く、精度が高くなるという面白い結果が出ました。

徒歩・渋谷PARCOから 30 分の到達圏
左: 解像度が「自動」の時、右: 解像度が「高」の時
Isochrones API 2

自転車 (BICYCLE): 基本的には「自動」でも十分な精度ですが、「渋谷PARCO から自転車で 30 分」の条件で検証した際、エリア右上にある公園の凹凸など、ある程度到達圏が広くなると、「自動」よりも「HIGH (高)」の方が精度が高くなる挙動が確認できました。

自転車・渋谷PARCOから 30 分の到達圏
左: 解像度が「自動」の時、右: 解像度が「高」の時 Isochrones API 1

自動車 (DRIVE): 移動時間 15 分までは「自動」と「HIGH (高)」でほぼ同じ形状です。しかし、30 分以上になると明確な差が出ます。「HIGH (高)」は高速道路の形状に正確に沿った等時線が返ってきて精度が高く見えるのに対し、「自動」の場合は高速道路の横側に少し膨らむような大まかな形状になります。

自動車・渋谷PARCOから 30 分の到達圏
左: 解像度が「自動」の時、右: 解像度が「HIGH (高)」の時
Isochrones API 10

3. 徒歩移動かつ非常に狭い範囲での挙動

徒歩移動で「1分」といった狭すぎる範囲を指定した場合、到達圏が設定した解像度によって上下に動いてしまい、結果が安定しない現象が確認されました。また、解像度を「自動」にしていると、指定した中心地点から到達圏がズレて出力されることもあります。

徒歩・渋谷PARCOから 1 分の到達圏
左: 解像度が「自動」の時、右: 解像度が「高」の時Isochrones API 9

4. 地形や移動速度の考慮（坂道・高速道路）

Isochrones API が裏側で「何を考慮して計算しているか」についても、興味深い検証結果が得られました。
上り坂は考慮される :徒歩（自動）モードでの検証時、上り坂を移動することで増加する時間はしっかりと考慮されて等時線が縮んでいました。

北海道函館市の「八幡坂」。徒歩・5 分の到達圏。
左: 北西に伸びる道を歩く場合は約 383m、右: 八幡坂を上る道は約 268mIsochrones API 5

移動速度の動的変化: 自動車モードの際、高速道路沿いに到達圏がグッと長く伸びていることが確認できました。これは単に道路網を辿るだけでなく、道路の種別に応じた「移動速度」もしっかり考慮されて等時線が計算されている証拠です。

例：自動車・渋谷PARCOから 30 分の到達圏
高速道路沿いに到達圏が伸びているのが見てわかります
Isochrones API 3

5. セルサイズについて

裏側で使われていると推測される S2 セルですが、公式のドキュメントには具体的なセルに関する記載はありません。今回日本（東京周辺）の座標を使って enable_smoothing = false（ギザギザモード）の状態でセルの 1 辺の長さを地図上で計測してみたところ、おおよその目安が見えてきました。

基本的なセルサイズの目安（日本周辺）

  • HIGH: 辺の長さ 約 62〜64m
  • MEDIUM: 辺の長さ 約 124〜128m
  • LOW: 辺の長さ 約 246〜257m

注意: S2 セルの性質上、計算対象となる国や場所の緯度などによって実際のサイズが若干前後するため、あくまで日本周辺のセルサイズの目安として参考にしてください。

「自動」モードにおけるセルレベルの例外

基本的には「同じ解像度」を指定すれば、どの移動種別でも同じセルレベル（セルサイズ）になります。また、徒歩を除いて、自動車や自転車では「自動」と「HIGH (高)」は同じセルレベルで処理されています。

しかし、唯一の例外として「徒歩の自動モード」だけは、他の移動種別の自動モードよりもセルレベルが高く（セルサイズが小さく）設定されていることが分かりました。先述の『徒歩は一貫して自動の方が精度が高い』という検証結果は、この裏側の仕様（徒歩だけ自動のセルレベルが引き上げられている）が関係しているかもしれません。

パラメータの組み合わせによる「見た目」と「精度」の変化

こここまで紹介した enable_smoothing (滑らかさ) と polygon_fidelity (解像度) ですが、それぞれ独立したパラメータですが、組み合わせることで最終的な等時線の「見た目」と「精度」が大きく変化します。

polygon_fidelity (解像度) が LOW または MEDIUM

  • enable_smoothing = false (ギザギザ): ベースとなる格子セルの形がそのまま出力されるため、やや階段状の輪郭になります。解像度 HIGH と比べると頂点数は抑えられますが、エッジを滑らかにするための追加処理を行わないため、内部の計算結果がそのままダイレクトに反映された形状になります。
  • enable_smoothing = true (なめらか): 大まかなエリアをカバーしつつ、後処理によってセルの角が丸められ、ポリゴンの頂点数（データサイズ）がさらに軽量化されます。「地図上での見やすさ」と「ページの読み込み速度（描画パフォーマンス）」を両立できるため、一般的なエンドユーザー向けの地図表示に適した組み合わせと言えます。

polygon_fidelity (解像度) が HIGH

  • enable_smoothing = false (ギザギザ): 実際の道路網を最も厳密にトレースした、正確な形状を出力します。ポリゴンの輪郭はギザギザになりますが、ある地点がエリア内に含まれているかをシステム側でシビアに判定したい場合など、バックエンドでのデータ処理に最適です。
  • enable_smoothing = true (なめらか): 解像度 HIGH ならではの「道路の終端に沿った詳細な形状」をベースにしながらも、輪郭だけを丸めてきれいな等時線を表示します。高精度な等時線を保ちつつ、地図上での描画負荷を抑えたい画面表示に最適です。

上段: 解像度が LOW (低)、下段: 解像度が HIGH (高)
左: エッジがギザギザ、右: エッジがなめらか
※いずれも「東京駅」から自動車で 15 分のエリアで指定。Isochrones API 4

レスポンス（GeoJSON）の構造

リクエストが成功すると、以下のような GeoJSON (MultiPolygon) 形式のレスポンスが返ってきます。

今回は、赤坂駅から自転車で 20 分で到達できるエリアをリクエストしてみました。解像度 (polygon_fidelity) は MEDIUM (中)、輪郭を滑らかにしない設定 (enable_smoothing=false) にしています。
実際に取得したポリゴンを地図上に描画するとこのようになります。注目していただきたいのは、中心ピンの左側にある「穴あき」です。ここは「迎賓館赤坂離宮」の敷地に当たる場所で、Isochrones API は一般の道路が通っていない（自転車で通り抜けられない）ため「到達できないエリア」として結果を返しています。また、右上の「皇居」エリアも、到達圏に含まれていないことが分かります。
※検証の通り解像度を上げることで、こうした道路のない敷地の「穴」がより多く、厳密に描写されるようになります

例: 自転車・赤坂駅から 20 分の到達圏、解像度 = MEDIUMIsochrones API 7

この時のレスポンスの中身がこちらです（一部座標を省略）。

{
  "isochrone": {
    "geoJson": {
      "type": "MultiPolygon",
      "coordinates": [
        [
          [
            [139.7294382231687, 35.69308679721004],
            ...（1 つ目の巨大な外枠：等時線エリア全体の座標群）...
            [139.7294382231687, 35.69308679721004]
          ],
          [
            [139.72560702872346, 35.6789277897184],
            ...（2 つ目の座標群：これが地図の「赤坂離宮」エリア上でポッカリ空いている「穴」の輪郭）...
            [139.72560702872346, 35.6789277897184]
          ]
        ]
      ]
    }
  }
}

GeoJSON の仕様通り、1 つの大きな外枠を表す配列のすぐ下に、穴の輪郭を形作る 2 つ目の配列が綺麗に格納されて戻ってくるのがわかります。

上記の例では polygon_fidelity を MEDIUM (中) にしましたが、LOW (低) に切り替えるとどうなるでしょうか。実際に叩いて返ってきたレスポンスがこちらです（一部座標を省略）。

{
  "isochrone": {
    "geoJson": {
      "type": "MultiPolygon",
      "coordinates": [
        [
          [
            [139.726884066015, 35.69320871231226],
            ...（外枠の座標群のみ）...
            [139.726884066015, 35.69320871231226]
          ]
        ]
      ]
    }
  }
}

ご覧の通り、MEDIUM (中) の時に存在していた「穴をくりぬくための 2 つ目の配列」が消え、1 つの大きな面（ポリゴン）として綺麗に統合されています。実際に地図上に描画すると次のようになります。

例: 自転車・赤坂駅から 20 分の到達圏、解像度 = LOWIsochrones API 6
「実際の道路網ベースの精度が高い（穴あきあり）等時線」が欲しいのか、それとも「大まかなエリアだけを表示したいのか」によって、polygon_fidelity パラメータを調整する重要性がデータ構造からも一発で分かりますね！

まとめ

いかがでしたでしょうか？ドキュメントを読んだだけでは分からない、「徒歩は自動の方が精度が高い」「自動車の 30 分以上は解像度 = HIGH (高) が活きる」「坂道は考慮されるが陸橋は考慮されない」といった、社内検証ならではの生きた挙動の違いなど、少しでも伝わっていれば嬉しいです。

冒頭でも触れました通り、本 API はまだプレビュー版 のため、今後 GA（一般提供開始）に向けてパラメータの挙動やチューニング、仕様がアップデートされる可能性があります。今後の動向にもぜひ注目していきましょう！

ゴーガには Google Maps Platform に精通したエンジニアが多く在籍しています。
「そもそも Google Maps Platform って何？」や「自分のユースケースに最適な Isochrones API のリクエスト方法」など、気になることがありましたらお気軽にご相談ください！

それでは、また次の記事でお会いしましょう！

その他のブログ

Isochrones API
Isochrones API の試験版がリリースされました
最新アップデート
Maps Grounding Lite
Maps Grounding Lite が登場！AI×地図データの活用がより手軽に
最新アップデート
JSアップデート202605
[Google Maps API] Maps JavaScript API バージョンアップデート 情報！！(2026/05/11)
最新アップデート
ブログ一覧をみる chevron_right