carto-routing-od-analysis

ルート検索と起終点分析

ルート、移動時間・距離のマトリックス、等時間圏の到達圏（自動車および徒歩モード）を計算し、空間インデックスを使ってODフローパターンを分析します。規模に応じて、次の2つのアクセス方法があります。

• 単発／アドホック（MCP 優先）：1件のルート、1地点の等時間圏、小規模なODマトリックスを扱う場合は、CARTO MCP ツールの route、calculate_isolines、calculate_od_matrix で直接処理できます（それぞれ、対応するモードや範囲タイプを一覧表示する capabilities 操作も備えています）。ワークフローは不要です。これらは、CLI を使用できないサンドボックス化されたチャットホストを含む、あらゆる MCP ホストで実行できます。対話形式のリクエストでは、こちらを優先してください。
• テーブル規模／反復可能：テーブル全体に対する計算や再利用可能なパイプラインには、以下のワークフローパターンを使用してください。開発プロセス、JSON 構造、検証については carto-create-workflow を読み込んでください。これは、MCP の create_workflow／validate_workflow／run_workflow（接続時）と、carto workflows CLI（それ以外）の両方の方法をカバーします。アクセス方法の判断シグナルについては carto-basics/references/access-paths.md を参照してください。

API トークンを使った MCP セッションでは、アドホック／作成用ツールは非表示になり、読み取り／検出のみが可能です。その場合は CLI に切り替えるか、OAuth で再接続してください。

---

手順

主なワークフローパターンは3つあります。ユースケースに応じて選択してください。

パターン	コンポーネント	使用する場面
等時間圏／等距離圏	native.isolines	地点周辺の到達圏ポリゴンが必要な場合（例：「10分以内に到達できる場所すべて」）
OD マトリックス	native.routesodmatrix	起点と終点のすべての組み合わせの移動時間／距離が必要な場合（分析用、ジオメトリなし）
ルート作成	native.routes	OD ペア間の実際のルート線ジオメトリが必要な場合（可視化、詳細な経路）

---

パターン A：等時間圏／等距離圏の生成

パイプライン：

Source Points -> (Filter) -> Isolines -> (Polyfill / Enrich) -> Save

ステップ A1：ソースポイントを読み込む

native.gettablebyname を使って地点（店舗、駅、施設）を読み込みます。

成功条件：ジオメトリ列と一意な地点 ID を含むテーブルがあること。

ステップ A2：等時間圏／等距離圏を生成する

native.isolines では、次の値を指定します。

入力	説明	例
mode	移動モード	car または walk
range_type	範囲の測定方法	time または distance
range	しきい値	時間の場合は秒（例：600 = 10分）、距離の場合はメートル（例：5000 = 5 km）

成功条件：各入力ポイントに、到達可能エリアを表すポリゴンジオメトリが関連付けられていること。

ステップ A3：後処理（任意）

等時間圏／等距離圏の生成後によく行う処理：

• ポリフィル＋エンリッチ：native.h3polyfill で等時間圏／等距離圏のポリゴンを H3 に変換し、人口統計データや POI データでエンリッチします（trade-area-analysis スキルを参照）。
• 重複分析：native.spatialjoin を使って重複する等時間圏／等距離圏を特定し、複数の地点がサービスを提供するエリアを見つけます。
• カバレッジのユニオン：native.dissolve を使ってすべての等時間圏／等距離圏ポリゴンを1つのカバレッジ領域にまとめます。

ステップ A4：保存する

native.saveastable を使って等時間圏／等距離圏のポリゴンまたはエンリッチ済みの結果を保存し、ワークフローを検証してアップロードします（MCP の create_workflow／validate_workflow、または carto workflows create）。

---

パターン B：OD マトリックス（移動時間／距離）

パイプライン：

Origins Table -> ┐
                 ├-> OD Matrix -> (Filter/Aggregate) -> Save
Destinations Table -> ┘

ステップ B1：起点と終点を読み込む

2つの native.gettablebyname ノードを使います。1つは起点用、もう1つは終点用です。どちらにもジオメトリ列が必要です。

成功条件：それぞれにポイントジオメトリと一意な ID を持つ2つのテーブルがあること。

ステップ B2：OD マトリックスを計算する

native.routesodmatrix では、次の値を指定します。

入力	説明
mode	car または walk
起点入力	起点テーブルノードから接続
終点入力	終点テーブルノードから接続

出力列：origin_id、destination_id、duration_s、distance_m。

成功条件：起点と終点のペアごとに、移動時間と距離を含む1行があること。

ステップ B3：フィルタリングまたは集計（任意）

一般的な後処理：

• 最寄りの目的地：native.groupby を使って、出発地ごとに最小の duration_s を求めてから、結合して最寄りの目的地を取得します。
• しきい値によるフィルタリング：native.where を使って、時間または距離の上限以内のペアのみを残します（例：30 分のしきい値の場合は duration_s < 1800）。
• アクセシビリティスコア：native.groupby を使って、出発地ごとにしきい値以内で到達できる目的地の数を数えます。

ステップ B4：保存

native.saveastable を使い、その後、検証してアップロードします（MCP create_workflow または carto workflows create）。

---

パターン C：ルートジオメトリ

パイプライン：

Origins Table -> ┐
                 ├-> Routes -> Save
Destinations Table -> ┘

ステップ C1：出発地と目的地を読み込む

パターン B と同様に、ポイントジオメトリを持つ native.gettablebyname ノードを 2 つ使用します。

ステップ C2：ルートを計算する

native.routes を次のように使用します：

入力	説明
mode	car または walk
出発地の入力	出発地のテーブルノードから接続
目的地の入力	目的地のテーブルノードから接続

出力：OD ペアごとに 1 つのルート線ジオメトリ（duration_s、distance_m を含む）。地図上で可視化できます。

ステップ C3：保存

native.saveastable を使い、その後、検証してアップロードします（MCP create_workflow または carto workflows create）。

---

パターン D：OD フロー分析（グリッドベース）

ルーティング API を呼び出さずに、大規模な移動パターン（例：タクシーの移動、自転車の移動、通勤フロー）を分析します。

パイプライン：

Trip Data -> H3 (origin) + H3 (destination) -> Group By (origin_h3, dest_h3) -> Save

ステップ D1：移動データを読み込む

native.gettablebyname を使います。テーブルには、出発地と目的地の両方の座標（例：pickup_lon/lat、dropoff_lon/lat）が必要です。

ステップ D2：出発地と目的地を H3 にインデックス化する

native.selectexpression を使って、出発地と目的地のポイントの両方について H3 セルを計算します：

• 出発地 H3：乗車地点の座標から導出します
• 目的地 H3：降車地点の座標から導出します

別々のジオメトリ列がデータにある場合は、それぞれに native.h3frompoint を使う方法もあります。

ステップ D3：フローを集計する

native.groupby を使って、（origin_h3, destination_h3）のペアごとに移動を数えます：

• グループ化：origin_h3, destination_h3
• 集計：origin_h3,count（OD ペアごとの移動数）

成功：一意な OD セルのペアごとに 1 行となり、移動数が含まれます。フローの可視化にすぐ使えます。

ステップ D4：保存

native.saveastable を使います。

---

注意事項

• プロバイダーの大文字・小文字と SQL 方言。 このスキルでは列名を小文字（origin_id、destination_id、duration_s、distance_m、origin_h3 など）で使用します。これは BigQuery／Databricks／Postgres／Redshift の慣例です。Snowflake では大文字（ORIGIN_ID、DURATION_S、...）で参照してください。大文字・小文字のルールと SQL 方言の対応については、carto-create-workflow/references/providers/<provider>.md を参照してください。
• アイソラインとルーティングコンポーネントは LDS（Location Data Services）のクォータを消費します。一括操作の前に LDS_QUOTA_INFO で利用可能なクォータを確認してください。バッファー（native.buffer）は LDS クォータを消費せず、単純な円形の到達圏を作成する無料の代替手段です。
• OD マトリックスは 二次関数的に増加します。N 個の出発地 x M 個の目的地 = N*M 行です。マトリックスのサイズを管理しやすくするため、入力をフィルタリングするかサンプリングしてください。出発地 1000 件 x 目的地 1000 件の場合、100 万行になります。
• 徒歩モードの実用的な範囲は、車よりもかなり短くなります。徒歩の所要時間が 20～30 分を超えるアイソラインや、距離が数キロメートルを超える OD マトリックスでは、信頼性の低い結果や空の結果が生成されます。
• ルートジオメトリは大きくなる場合があります。分析（時間／距離のみ）が目的であれば、データ量を減らすために、完全なルート（パターン C）よりも OD マトリックス（パターン B）を優先してください。
• 混雑の影響により、時間帯によって車での移動結果が変わります。コンポーネントが対応している場合は departure_time を指定してください。対応していない場合、結果には一般的／平均的な状況が反映されます。
• 近接する場所では、アイソラインポリゴンが重なる場合があります。その後にデータを付加する場合は、空間インデックスにポリフィルしてセルの重複を削除し、二重計上を避けてください。
• OD フローの可視化（パターン D）には、生の座標ではなく H3 セルの中心点を使用すると、集約と可視化がすっきりします。粗い解像度（例：H3 解像度 7～8）は、細かい解像度よりも意味のあるフローパターンを生成します。
• LDS ルーティングコンポーネントには、LDS API アクセスが有効な接続が必要です。接続にこの権限がない場合、検証に失敗することがあります。

---

リファレンステンプレート

リソース	説明
スケーラブルなルーティングのチュートリアル	Workflows でスケーラブルなルーティングを行う手順
OD パターンのチュートリアル	出発地と目的地のパターンを分析するチュートリアル（NYC のタクシーの例）
ルーティングモジュール（BQ）	BigQuery 用 Analytics Toolbox でルーティングモジュールを使用する方法
アイソライン生成テンプレート	Workflow テンプレートを使用して等時間圏を生成する方法
商圏アイソライン（BQ）	BigQuery 用の車／徒歩の所要時間に基づく商圏アイソライン
商圏アイソライン（SF）	Snowflake 用の車／徒歩の所要時間に基づく商圏アイソライン

---

よくあるバリエーション

バリエーション	方法
サービスエリアのカバー率	等時間線（車、複数の範囲（例：5／10／15 分））-> 和集合 -> カバーされる人口の合計を測定
最寄りの施設	OD マトリックス -> 起点ごとにグループ化 -> min(duration_s) -> 結合して最寄りの目的地 ID を取得
アクセシビリティのスコアリング	OD マトリックス -> しきい値でフィルタリング -> 起点ごとに目的地をカウント -> 到達可能な目的地数でスコアを算出
車両のルート計画	デポと配送地点の間のルート -> ルートごとに総距離／所要時間を集計
通勤フロー分析	移動データ -> H3 の起点 + H3 の目的地 -> OD ペアごとにグループ化 -> カウント -> 上位フローを可視化
マルチモーダルの比較	等時間線を 2 回実行（車 + 徒歩）-> カバレッジポリゴンを比較 -> 公共交通機関に依存する地域を特定