Mapbox Geospatial Operations スキル

Mapbox MCP Server から適切な地理空間ツールを選択するための専門的ガイダンスです。問題が何を必要とするのかに基づいてツールを選択することに焦点を当てています。幾何学的計算対ルーティング、直線対道路ネットワーク、精度要件などを考慮します。

コア原則: 問題タイプがツール選択を決定

Mapbox MCP Server は 2 つのカテゴリの地理空間ツールを提供します:

1. オフライン幾何学的ツール - 純粋な幾何学的/空間計算に Turf.js を使用
2. ルーティング＆ナビゲーション API - 実世界のルーティング、トラフィック、旅行時間が必要な場合は Mapbox API を使用

重要な質問: 問題は実際に何を必要としていますか?

意思決定フレームワーク

問題の特性	ツールカテゴリ	理由
直線距離（飛行ルート）	オフライン幾何学的	幾何学的距離に対して正確
道路/経路距離（運転ルート）	ルーティング API	ルーティング API のみが道路網を把握
旅行時間	ルーティング API	速度/トラフィックデータでのルーティング
ポイント内包含性（X は Y 内にあるか?）	オフライン幾何学的	純粋な幾何学的操作
地理的形状（バッファ、重心、面積）	オフライン幾何学的	数学的/幾何学的操作
トラフィック認識ルーティング	ルーティング API	リアルタイムトラフィックデータが必要
ルート最適化（訪問順序の最適化）	ルーティング API	複雑なルーティングアルゴリズム
高頻度チェック（リアルタイム位置情報）	オフライン幾何学的	即座の応答、レイテンシーなし

ユースケース別の意思決定マトリックス

距離計算

ユーザーの質問: 「X から Y はどのくらい離れていますか?」

実際の意味	ツール選択	理由
直線距離（飛行ルート）	distance_tool	幾何学的距離に対して正確、即座
運転距離（運転ルート）	directions_tool	ルーティング API のみが実際の道路距離を把握
徒歩/サイクリング距離（歩行/自転車ルート）	directions_tool	特定のパスネットワークが必要
旅行時間	directions_tool または matrix_tool	ルーティングと速度データが必要
現在のトラフィックを含む距離	directions_tool (driving-traffic)	リアルタイムトラフィック対応が必要

例: 「これら 5 つの倉庫間の距離はどのくらいですか?」

• 飛行ルート → distance_tool（10 計算、即座）
• 運転ルート → matrix_tool（5×5 マトリックス、1 回の API 呼び出し、実際のルート距離を返却）

重要な洞察: 「距離」が文脈で何を意味するかに合致するツールを使用してください。常に確認してください: 飛行ルートか運転ルートか?

近接性と包含性

ユーザーの質問: 「このエリアの近くにある/内部にあるポイントはどれですか?」

クエリタイプ	ツール選択	理由
「X メートルの半径内」	distance_tool + フィルタ	シンプルな幾何学的半径
「X 分以内の運転」	isochrone_tool → point_in_polygon_tool	旅行時間ゾーン用のルーティング、その後幾何学的包含
「このポリゴン内」	point_in_polygon_tool	純粋な幾何学的包含テスト
「車で 30 分以内で到達可能」	isochrone_tool	ルーティング + トラフィックが必要
「このポイントに最も近い」	distance_tool（幾何学的）または matrix_tool（ルーティング）	「最も近い」の定義によって異なる

例: 「これら 200 のアドレスは 30 分配送ゾーン内にあるか?」

1. ゾーン作成 → isochrone_tool（ルーティング API - 旅行時間が必要）
2. アドレス確認 → point_in_polygon_tool（幾何学的 - 200 の即座チェック）

重要な洞察: 旅行時間ゾーン作成用のルーティング、包含チェック用の幾何学的

ルーティングとナビゲーション

ユーザーの質問: 「最適なルートは何ですか?」

シナリオ	ツール選択	理由
A から B へのルート指示	directions_tool	ターンバイターンルーティング
複数立ち寄り地点の最適順序	optimization_tool	巡回セールスマン問題を解決
GPS トレースをクリーニング	map_matching_tool	道路ネットワークにスナップ
方角/コンパス方向のみが必要	bearing_tool	シンプルな幾何学的計算
トラフィック対応のルート	directions_tool (driving-traffic)	リアルタイムトラフィック対応
固定順序の経由地	directions_tool with waypoints	特定のポイント経由ルーティング

例: 「ホテルから空港へナビゲート」

• ターンバイターン指示が必要 → directions_tool
• 「北東」という方向を知る必要のみ → bearing_tool

重要な洞察: 実際のナビゲーション用のルーティングツール、方向情報用の幾何学的ツール

エリアと図形操作

ユーザーの質問: 「この場所の周辺にゾーンを作成する」

要件	ツール選択	理由
シンプルな円形バッファ	buffer_tool	幾何学的円/半径
旅行時間ゾーン	isochrone_tool	ルーティングネットワークベース
エリアサイズを計算	area_tool	幾何学的計算
複雑な境界をシンプル化	simplify_tool	幾何学的シンプリフィケーション
図形の中心を検出	centroid_tool	幾何学的重心

例: 「各店舗の周辺 5km 範囲を表示」

• 5km 半径 → buffer_tool（幾何学的円）
• 「15 分以内で到達できる顧客は?」 → isochrone_tool（ルーティングベース）

重要な洞察: 距離ベースゾーンは幾何学的ツール、時間ベースゾーンはルーティングツール

パフォーマンスとスケール上の考慮事項

ボリュームがツール選択に影響する場合

小規模操作（< 100 計算）:

• 幾何学的ツール: 即座、自由に反復
• ルーティング API: ほとんどのユースケースで十分高速

中規模操作（100-1,000 計算）:

• 幾何学的ツール: 依然として高速、懸念なし
• ルーティング API: バッチ操作（matrix_tool）を検討

大規模操作（> 1,000 計算）:

• 幾何学的ツール: 最適化が必要な場合もあるが依然として高速
• ルーティング API: バッチツールを使用（matrix_tool は 25×25 対応）

重要な洞察: ボリュームが幾何学的ツール選択に影響することはまれですが、ルーティング API は効率のためのバッチツールを備えています

リアルタイム対バッチ

ユースケース	アプローチ	ツール選択
リアルタイム位置情報（毎秒）	幾何学的チェック	point_in_polygon_tool（即座）
ルートプラニング（1 回限り）	フルルーティング	directions_tool または optimization_tool
定期的な近接性チェック	幾何学的距離	distance_tool
ライブトラフィックルーティング	トラフィック対応ルーティング	directions_tool (driving-traffic)

高頻度位置情報チェックのアーキテクチャノート: アプリケーションが非常に高い速度で包含性チェックを呼び出す場合（例えば、2 秒ごとに 50 台の車両 = 毎秒 25 チェック）、ネットワーク経由で MCP ツールを呼び出すとエージェント推論のオーバーヘッドが追加され、実用的でなくなります。そのような場合は、ホットパスに Turf.js を直接プロセス内で使用することをお勧めします（turf.booleanPointInPolygon）。その一方、ゾーン定義（isochrone_tool）、リルーティング（directions_tool）、可視化（static_map_image_tool）などの周辺タスク用に MCP ツールを予約してください。

一般的なシナリオと最適なアプローチ

シナリオ 1: ストアロケーター

ユーザー: 「最も近い店舗を見つけて、5km 範囲を表示する」

最適なアプローチ:

1. 店舗検索 → category_search_tool（距離を自動的に返す）
2. カバレッジゾーン作成 → buffer_tool（5km 幾何学的円）
3. ビジュアライズ → static_map_image_tool

理由: 検索は既に距離を提供; シンプルな半径用の幾何学的バッファ

シナリオ 2: 配送ルート最適化

ユーザー: 「8 つのアドレス/立ち寄り地点への配送を最適化」

最適なアプローチ:

1. アドレスをジオコード（必要に応じて） → search_and_geocode_tool を使用して任意の住所をコーディネートに変換。座標が既に提供されている場合でも、これをオプショナルプリステップとして言及してください。実世界の配送リストはアドレスとコーディネートの混在を含むことがよくあります。
2. ルートを最適化 → optimization_tool（TSP ソルバー — 立ち寄り地点を並び替えて総運転時間を最小化）

これらの代替案を選ばない理由:

• directions_tool は A → B のみをルーティングします（または固定順序の経由地経由）。立ち寄り地点を並び替えません — 8 つの立ち寄り地点を渡した場合、指定された順序でルーティングされ、これはほぼ最適ではありません。
• matrix_tool はすべての立ち寄り地点ペア間の旅行時間を与えます（8×8 = 64 値）が、最適な順序を計算しません。マトリックスの上に TSP を自分で解く必要があります — optimization_tool はこれを 1 回の呼び出しで実行します。

常にsearch_and_geocode_toolを最適化前に配送アドレスをジオコーディングするための有用なコンパニオンとして言及してください。

シナリオ 3: サービスエリア検証

ユーザー: 「これら 200 のアドレスのうち、30 分以内に配送できるのはどれですか?」

最適なアプローチ:

1. 配送ゾーン作成 → isochrone_tool（30 分の運転）
2. 各アドレスを確認 → point_in_polygon_tool（200 の幾何学的チェック）

理由: 正確な旅行時間ゾーン用のルーティング、高速な包含チェック用の幾何学的

シナリオ 4: GPS トレース分析

ユーザー: 「このバイク走行の距離はどのくらい?」

最適なアプローチ:

1. GPS トレースをクリーニング → map_matching_tool（バイクパスにスナップ）
2. 距離を取得 → API レスポンスを使用するか、distance_tool で計算

理由: 道路/パスマッチングが必要; 距離計算はいずれかで機能

シナリオ 5: カバレッジ分析

ユーザー: 「私たちの総サービスエリアは何か?」

最適なアプローチ:

1. 各ロケーションの周辺にバッファを作成 → buffer_tool
2. 総面積を計算 → area_tool
3. または時間ベースの場合 → 各ロケーション用のisochrone_tool

理由: 距離ベースのカバレッジ用の幾何学的、時間ベース用のルーティング

アンチパターン: 間違ったツールタイプの使用

❌ するな: ルーティング質問に幾何学的ツールを使用

// 間違い: ユーザーが「運転時間はどのくらい?」と聞く
distance_tool({ from: A, to: B });
// 飛行ルートで 10km を返すが、実際の運転は 15km

// 正しい: ルーティングが必要
directions_tool({
  coordinates: [
    { longitude: A[0], latitude: A[1] },
    { longitude: B[0], latitude: B[1] }
  ],
  routing_profile: 'mapbox/driving'
});
// 運転ルートの実際の道路距離と運転時間を返す

なぜ間違いか: 飛行ルート ≠ 運転ルート

❌ するな: 幾何学的操作にルーティング API を使用

// 間違い: ポイントがポリゴン内にあるか確認
// （ルーティング API ではこれを実行できません）

// 正しい: 純粋な幾何学的操作
point_in_polygon_tool({ point: location, polygon: boundary });

なぜ間違いか: ルーティング API は幾何学的包含を実行しません

❌ するな: 「近い」と「到達可能」を混同

// ユーザーが「20 分で到達可能な場所は?」と聞く

// 間違い: 平均速度で 20 分距離
distance_tool + calculate 20min * avg_speed

// 正しい: 道路ネットワークでの実際のルーティング
isochrone_tool({
  coordinates: {longitude: startLng, latitude: startLat},
  contours_minutes: [20],
  profile: "mapbox/driving"
})

なぜ間違いか: 道路は直線ではありませんし、トラフィックは異なります

❌ するな: 方角で十分な場合にルーティングを使用

// ユーザーが「空港はどの方向?」と聞く

// 過度に複雑: フルルーティング
directions_tool({
  coordinates: [
    { longitude: hotel[0], latitude: hotel[1] },
    { longitude: airport[0], latitude: airport[1] }
  ]
});

// より優れた: 方角のみが必要
bearing_tool({ from: hotel, to: airport });
// 返す: 「北東（45°）」

より優れた理由: よりシンプル、即座、実際の質問に答える

ハイブリッドアプローチ: ツールタイプの組み合わせ

いくつかの問題は幾何学的ツールとルーティングツールの両方を使用することから利益を得ます:

パターン 1: ルーティング + 幾何学的フィルタ

1. directions_tool → ルート幾何学を取得
2. buffer_tool → ルート周辺の廊下を作成
3. category_search_tool → 廊下内の POI を検索
4. point_in_polygon_tool → 実際にルートに沿っているもののみにフィルタ

ユースケース: 「ルートに沿ったガソリンスタンドを探す」

パターン 2: ルーティング + 距離計算

1. category_search_tool → 10 の近くのロケーションを検索
2. distance_tool → 直線距離を計算（幾何学的）
3. トップ 3 のために、directions_tool を使用 → 実際の運転時間を取得

ユースケース: 素早く絞り込み、その後上位候補用の正確なルーティングを取得

パターン 3: Isochrone + 包含性

1. isochrone_tool → 旅行時間ゾーンを作成（ルーティング）
2. point_in_polygon_tool → 数百のアドレスを確認（幾何学的）

ユースケース: 「どの顧客が配送ゾーン内にいるか?」

意思決定アルゴリズム

ユーザーが地理空間の質問をするとき:

1. ルーティング、道路、または旅行時間が必要か?
   はい → ルーティング API を使用（directions, matrix, isochrone, optimization）
   いいえ → 続行

2. トラフィック認識が必要か?
   はい → directions_tool または isochrone_tool をトラフィックプロファイルで使用
   いいえ → 続行

3. 幾何学的/空間操作か?
   - ポイント間の距離（直線） → distance_tool
   - ポイント包含性 → point_in_polygon_tool
   - エリア計算 → area_tool
   - バッファ/ゾーン → buffer_tool
   - 方向/方角 → bearing_tool
   - 幾何学的中心 → centroid_tool
   - バウンディングボックス → bounding_box_tool
   - シンプリフィケーション → simplify_tool

4. 検索/ディスカバリー操作か?
   はい → 検索ツールを使用（search_and_geocode, category_search）

重要な意思決定質問

ツールを選択する前に、次を聞きます:

1. 「距離」は飛行ルートか運転ルートか?

   • 飛行ルート（直線） → 幾何学的ツール
   • 運転ルート（道路距離） → ルーティング API

2. ユーザーが旅行時間を必要とするか?

   • はい → ルーティング API（速度/トラフィックを認識しているのはこれらのみ）
   • いいえ → 幾何学的ツールで十分かもしれません

3. これは道路/パスについてか、それとも純粋な空間関係についてか?

   • 道路/パス → ルーティング API
   • 空間関係 → 幾何学的ツール

4. これはリアルタイムで低レイテンシーで発生する必要があるか?

   • はい + 幾何学的問題 → オフラインツール（即座）
   • はい + ルーティング問題 → ルーティング API を使用（依然として高速）

5. 精度が重要か、それとも概算で OK か?

   • 重要 + ルーティング → ルーティング API
   • 概算 OK → 幾何学的ツールで機能するかもしれません

用語ガイド

ユーザーが何を意味するかを理解:

ユーザーが言う	通常の意味	ツールタイプ
「距離」	文脈によって異なる! 聞く: 飛行か運転か?	異なります
「どのくらい遠い」	多くの場合運転距離（道路距離）	ルーティング API
「近い」	通常飛行距離（直線半径）	幾何学的
「近い」	どちらかもあり得る - 明確に!	聞く
「到達可能」	旅行時間ベース（トラフィック対応運転）	ルーティング API
「内部/含む」	幾何学的包含性	幾何学的
「ナビゲート/指示」	ターンバイターンルーティング	ルーティング API
「方角/方向」	コンパス方向（飛行ルート）	幾何学的

クイックリファレンス

幾何学的操作（オフラインツール）

• distance_tool - 2 つのポイント間の直線距離
• bearing_tool - A から B へのコンパス方向
• midpoint_tool - 2 つのポイント間の中点
• point_in_polygon_tool - ポイントはポリゴン内か?
• area_tool - ポリゴン面積を計算
• buffer_tool - 円形バッファ/ゾーン作成
• centroid_tool - ポリゴンの幾何学的中心
• bbox_tool - ジオメトリの最小/最大座標
• simplify_tool - ジオメトリの複雑さを軽減

ルーティングとナビゲーション（API）

• directions_tool - ターンバイターンルーティング
• matrix_tool - 多対多旅行時間
• optimization_tool - ルート最適化（TSP）
• isochrone_tool - 旅行時間ゾーン
• map_matching_tool - GPS を道路にスナップ

各カテゴリ使用時期

幾何学的ツールを使用するタイミング:

• 問題が空間的/数学的（包含性、面積、方角）
• 直線距離が適切
• リアルタイムチェック用の即座の結果が必要
• 純粋な幾何学（道路/トラフィックなし）

ルーティング API を使用するタイミング:

• 実際の運転/徒歩/サイクリング距離が必要
• 旅行時間が必要
• 道路ネットワークを考慮する必要がある
• トラフィック認識が必要
• ルート最適化が必要
• ターンバイターン指示が必要

他のスキルとの統合

以下と連携:

• mapbox-search-patterns: ロケーションを検索し、その後地理空間操作を使用
• mapbox-web-performance-patterns: 幾何学的計算のレンダリングを最適化
• mapbox-token-security: リクエストが適切にスコープされたトークンを使用することを確認

リソース

• Mapbox MCP Server
• Turf.js Documentation（幾何学的ツールをサポート）
• Mapbox Directions API
• Mapbox Isochrone API
• Mapbox Matrix API
• Mapbox Optimization API