carto-territory-planning について
CARTO Workflow の構築者向けに、テリトリーの均衡化と施設配置を扱うスキルです。空間データの読み込みや索引付けから最適化、結果の保存までを案内し、需要を連続した区域に配分したり、カバレッジ向上や距離コスト削減を目指す施設選定を支援します。
主な機能
- 01均衡の取れた連続区域の作成
- 02需要や類似性に基づく区域割当
- 03需要カバー率を高める施設選定
- 04加重距離を抑える施設選定
- 05計画ワークフローの保存と検証
活用シーン
- 01売上や業務量に基づく営業区域の分割
- 02人口が均衡したサービス区域の設計
- 03倉庫や緊急対応拠点の立地計画
- 04施設選定と区域割当の組み合わせ
MCP 対応
carto-create-workflow スキルと併用します。MCP サーバー接続時は、create_workflow、validate_workflow、run_workflow ツールでワークフローを作成、検証、実行します。
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ cartodb/ agent-skills --skill carto-territory-planningインストール後、Claude Code で/carto-territory-planningを入力して読み込まれたか確認します。
詳細
テリトリー計画(テリトリーバランシング+位置割り当て)
関連する2つの空間最適化問題を解決する CARTO ワークフローを構築します。エリアをバランスの取れたテリトリー(例:営業地域、サービス区域)に分割することと、カバレッジの最大化またはコストの最小化を実現する施設の最適な位置を見つけることです。
前提条件:開発プロセス、JSON 構造、検証については carto-create-workflow を読み込みます。ここでは、両方のアクセス方法を扱います。接続されている場合は MCP サーバーのワークフローツール(create_workflow、validate_workflow、run_workflow)、それ以外の場合は carto workflows CLI を使用します。ルーティングの手がかりについては carto-basics/references/access-paths.md を参照してください。どちらのコンポーネントにも、接続先への Territory Planning Extension Package のインストールが必要です。
テリトリーバランシング
調査エリアを、需要変数(例:作業量、人口、収益)に基づいてバランスの取れた、空間的に連続するテリトリーに分割します。
パイプライン
Source Data (points) -> Spatial Indexing -> Aggregate per Cell -> Territory Balancing -> Save
ステップ 1:ソースデータの読み込み
native.gettablebyname を使用します。入力は通常、バランス調整の対象となる1つ以上の数値指標を含むポイントデータです。
成功条件:ノードが、ジオメトリ列と数値指標列を含むテーブルを出力します。
ステップ 2:空間インデックスへの変換
native.h3frompoint(または native.quadbinfromgeopoint)を使用して、各ポイントをグリッドセルに割り当てます。
解像度の目安:解像度が高いほどセルは小さくなり、より細かなテリトリーを作成できますが、計算量も増えます。都市レベルの分析では、H3 の解像度 8~9 が一般的です。
成功条件:出力に空間インデックス列(例:h3)が含まれます。
ステップ 3:セルごとの集計
native.groupby を使用し、バランス調整の対象となる指標を含む、セルごとに1行のデータを作成します。
- グループ化対象:空間インデックス列(
h3) - 集計:例:
geom,count,revenue,sum,population,avg
成功条件:セルごとに1行が作成され、需要の数値列と、任意の類似性特徴量が含まれます。
ステップ 4:テリトリーバランシングの実行
native.territorybalancing を次の設定で使用します。
| 入力 | 説明 | 例 |
|---|---|---|
input_table | テーブル入力(前のステップから) | |
index_column | H3 または Quadbin 列 | h3 |
demand_column | テリトリー間でバランス調整する数値列 | geom_count |
similarity_feats | テリトリー内の類似性に使う任意の数値列 | ["sentiment_avg", "popularity_avg"] |
npartitions | 作成するテリトリーの数 | 9 |
keep_input_columns | すべての入力列を出力に含める | true |
成功条件:出力には、テリトリー割り当て列が追加されたすべての入力行が含まれます。各セルは、必ず1つのテリトリーに割り当てられます。
ステップ 5:保存
native.saveastable を使用して結果を保存します。空間インデックス列は CARTO Builder で直接可視化でき、テリトリー ID で色分けできます。
成功条件:検証済みのワークフローを、create_workflow(MCP)または carto workflows create(CLI)でアップロードできます。
位置割り当て
需要のカバレッジを最大化するか、総コストまたは距離を最小化する、候補施設位置の最適な組み合わせを見つけます。
パイプライン
Demand Data (grid/points) -> Candidate Locations -> Location Allocation -> Save
ステップ 1:需要データの読み込み
native.gettablebyname を使用して、需要を表すグリッドまたはポイントのデータセット(例:H3 セルごとの人口、顧客位置)を読み込みます。
成功条件:空間インデックス列と数値の需要列を含むテーブルが作成されます。
ステップ 2:候補位置の読み込み
2つ目の native.gettablebyname を使用して、施設の候補位置(例:既存のインフラ、候補地)を読み込みます。
候補を絞り込む必要がある場合は、native.wheresimplified または native.limit を使用して候補数を減らします。候補数が少ないほど、計算は高速になります。
成功条件:候補地を表す空間インデックス列を含むテーブルが作成されます。
ステップ 3:位置割り当ての実行
目的に応じて、適切なバリアントを選択します。
カバー率の最大化
native.locallocallocation_maximizecoverage を使用します。
| 入力 | 説明 | 例 |
|---|---|---|
demand | 需要値を含むテーブル | |
demand_index_column | 需要テーブル内の空間インデックス列 | h3 |
demand_column | 数値の需要変数 | population |
candidates | 候補地を含むテーブル | |
candidates_index_column | 候補地テーブル内の空間インデックス列 | h3 |
nfacilities | 開設する施設の数 | 5 |
coverageradius | サービス範囲の最大距離(geography の場合はメートル) | 5000 |
成功:半径内でカバーされる需要の合計が最大になるよう、開設する施設と各施設がサービスを提供する需要セルが出力されます。
総コストの最小化
native.locallocallocation_minimizetotalcost を使用します。カバー率の最大化と同じ入力ですが、coverageradius は指定しません。目的は、半径内のカバー率ではなく、移動距離の重み付き合計を最小化することです。
成功:需要地と割り当て先の施設間の重み付き移動距離の合計を最小化するよう、開設する施設が出力されます。
ステップ 4:保存
native.saveastable を使用して結果を永続化します。
成功:検証済みのワークフローは、create_workflow(MCP)または carto workflows create(CLI)でアップロードできます。
注意点
- プロバイダーの大文字・小文字と SQL 方言。 このスキルでは小文字の列名(
h3、geom_count、population、sentiment_avgなど)を使用します。これは BigQuery/Databricks/Postgres/Redshift の慣例です。Snowflake では、引用符で囲んでいない識別子は大文字で表示されるため、H3、GEOM_COUNT、POPULATION、SENTIMENT_AVGとして参照してください。大文字・小文字の規則と SQL 方言の対応については、carto-create-workflow/references/providers/<provider>.mdを参照してください。 - 拡張パッケージが必要です:テリトリーバランシングとロケーション割り当てには、使用する特定の接続に Territory Planning Extension Package がインストールされている必要があります。これはデフォルトでは利用できません。ユーザーがインストールする必要があります。パッケージがない場合、検証は失敗します。
- 候補地が多い場合、ロケーション割り当ての計算コストが高くなります。候補地の数を少なく保つため、地理、容量、その他の基準で候補地を事前に絞り込んでください。候補地が数百件あると処理が遅くなり、数千件あるとタイムアウトする可能性があります。
- カバー半径の単位は、空間参照系によって異なります。通常、geography 型を使用する場合はメートルです。単位が意図したものと一致していることを確認してください。
- テリトリーバランシングでは、空間的な連続性とバランスの間のトレードオフが最適化されます。完全なバランスが保証されるわけではありません。テリトリー内の需要変数は、厳密に同じではなく、おおむね均等になります。
- グリッド解像度の影響:結果は入力グリッドの解像度によって大きく変わります。解像度を上げると境界がより正確になりますが、計算量も増加します。都市規模の場合は H3 解像度 8 から始め、必要に応じて調整してください。
- コンポーネント名は、
native.territorybalancing(「territory」と「balancing」の間にドット区切りはありません)と、native.locallocallocation_maximizecoverage/native.locallocallocation_minimizetotalcost(「local」の接頭辞が重複している点に注意)です。 - 需要データは対象地域を網羅している必要があります。需要グリッドに欠落があると、その地域は最適化の対象になりません。全域を網羅する必要がある場合は、polyfill と COALESCE(value, 0) を使用してください。
リファレンステンプレート
Academy チュートリアル
- テリトリーバランシングのチュートリアル -- Milan POS のユースケースを段階的に解説します
- ロケーションアロケーションのチュートリアル -- ロケーションアロケーションを用いた通信ネットワーク管理について解説します
- AI エージェント + ロケーションアロケーション -- AI エージェントとロケーションアロケーションを使った緊急対応拠点の配置について解説します
よくあるバリエーション
| バリエーション | 方法 |
|---|---|
| 営業テリトリーのバランシング | ポイント -> H3 -> セルごとの売上を集計 -> 売上を需要としてテリトリーバランシングを実行 |
| サービスゾーンの設計 | 人口データを含むグリッド -> テリトリーバランシングで人口が均等なゾーンを作成 |
| 倉庫/デポの配置 | 人口グリッドを需要、既存の倉庫を候補として使用 -> 総コストを最小化 |
| 緊急対応拠点 | 人口グリッドを需要、候補地を候補として使用 -> 対応時間の半径を指定してカバレッジを最大化 |
| 小売ネットワークの拡大 | 顧客密度グリッドを需要、出店候補地を候補として使用 -> カバレッジを最大化 |
| テリトリーとアロケーションの組み合わせ | まずロケーションアロケーションを実行して拠点の配置場所を選び、次にテリトリーバランシングを実行して各拠点にエリアを割り当てる |