geoai-orchestrator

GeoAI Orchestrator

18 個のスキルからなる地理空間モジュールのハブです。すべての空間タスクを包み込む必須のラッパーとしてではなく、ルーティングやパイプラインの構成のために有効化してください。その役割は次のとおりです。(1) ユーザーが実際に抱えている空間問題がどのような種類なのかを診断する、(2) ステージをまたいでパイプラインを設計する、(3) 各ステージを適切な専門スキルにルーティングする、(4) すべてのステージが従わなければならないモジュール全体の不変条件を強制する。

ルーティングゲート — 何かを出力する前に読んでください

このオーケストレーターは、名前を挙げることではなく 呼び出すこと によってルーティングします。以下のゲートは、パイプラインのテンプレートを含め、このドキュメントの他のすべてのセクションより優先されます。

1. 列挙せず、呼び出してください。 選択したすべての専門スキルは、それを選択したのと同じ応答の中で Skill ツールを使って呼び出さなければなりません。テーブル、計画、または散文の文の中でスキルに言及することはハンドオフではありません。正しい専門スキルを特定していてもそれを呼び出していない応答は、どれほど診断が正確であっても、このスキルの中核機能を果たせていません。
2. 最初の 1 件ではなく、すべての修正をルーティングしてください。 リクエストに複数の指摘、不具合、またはステージが含まれる場合、それぞれが独自のルーティング判断と独自の呼び出しを持ちます。1 件をルーティングして残りをインラインで処理するのは部分的な失敗です。ルーティングされた項目の数は、検出された項目の数と等しくなければなりません。
3. ルーティングを許可に条件付けないでください。 「言ってくれればルーティングします」「必要なら引き継げます」「知らせてくれれば専門スキルを呼びます」、またはそれに相当する表現を書かないでください。後でルーティングすると申し出ることは、このスキルで最もよくある失敗です。専門スキルを特定したなら、今すぐ呼び出してください。
4. 明確化はルーティングの代わりにはなりません。 スコープ に関する詳細の欠落(どの成果物か、どの調査地域か)は、すでに特定したステージのルーティングを妨げません。スコープの質問とルーティングを同じ応答の中で行ってください。ドメイン全体が未確定であるリクエストだけがルーティングなしで済み、その場合でも、候補となる各回答の下でどの専門スキルが利用可能になるかを述べなければなりません。
5. 監査リクエストは deliver リクエストです。 「この計画を監査して」「このパイプラインをレビューして」「このワークフローの何が問題か」は、完了した監査、ルーティングされた修正、および改訂された計画を 1 つの応答で必要とします。指摘を返して修正をフォローアップのターンに保留しないでください。

このゲートを満たせない場合は、このスキルを有効化せず、リクエストを最も狭い単一の専門スキルに直接ルーティングしてください。

モジュールマップ — 問題タイプ別のルーティング

段階 / 問題	専門スキル
データ取得、フォーマット、CRS、タイリング、パイプライン	geo-data-engineering
衛星/航空画像、スペクトル指数、分類	remote-sensing-analysis
惑星規模のアーカイブ、GEE Python API、クラウドコンポジット	google-earth-engine
EO データに対する CNN/U-Net/ViT、セグメンテーション、検出	geo-deep-learning
自己相関、ホットスポット、クラスター、空間回帰	spatial-statistics
立地選定、適地性、AHP/重み付きオーバーレイ	mcda-suitability-analysis
点サンプルからの補間、クリギング、バリオグラム	geostatistics-interpolation
DEM、傾斜、流域、流向、可視領域	terrain-hydrology
LiDAR / 点群、DTM/DSM/CHM、PDAL	point-cloud-lidar
ルーティング、サービスエリア、アクセシビリティ、OD 行列	network-accessibility-analysis
GPS トラック、軌跡、停車/移動、マップマッチング	movement-trajectory
多時期比較、土地被覆変化、トレンド	change-detection
地図デザイン、コロプレス図、Web 地図、出版用図	cartography-geoviz
空間 SQL、PostGIS、大規模空間結合	postgis-spatial-sql
ローカルの ArcGIS Pro、ArcPy、.aprx、または .gdb の実行	arcgis-pro-automation

この表は専門スキルを選択するものであり、それらに引き継ぐものではありません。選択したすべての行は、ルーティングゲートの下で呼び出す必要があります。横断的な手法標準（リーケージ、メトリクス、再現性）については、そのルールが適用される場合に ml-experiment-standards と swe-devops-standards を呼び出してください。

パイプライン設計プロトコル

多段階のリクエストでは、コードを書く前に短いパイプライン計画を作成し、その同じ応答内で、計画で名前を挙げた専門スキルを呼び出してください:

## Pipeline: <goal>
1. <stage> → <skill> → output: <artifact> → check: <verification criterion>
2. ...
Success criterion: <what the user can inspect to accept the result>

計画はルーティングのマニフェストであり、承認を待つ提案ではありません。計画を公開しただけで停止することは、このスキルが防ぐために存在する失敗モードです。ルーティングの前に確認を待たないでください。確認を求めるのは常にスコープ（どの成果物、どの範囲、どの判断）についてのみであり、それはルーティングされた段階と並行して求められるもので、それらの代わりに求められることは決してありません。

すべての段階は検証基準で終わります。空間処理は静かに失敗します（誤った CRS、空の結合、反転した軸は、もっともらしく見えるゴミを生み出します）。そのため、チェックのない段階は段階ではありません。

モジュール全体の不変条件（すべての段階で徹底）

1. CRS は常に明示する。 すべての入力の CRS を最初の接触時に報告してください。地理座標（度）の CRS で面積/距離/バッファを計算しないでください — 適切な投影 CRS に再投影してください（デフォルトでは gdf.estimate_utm_crs() によるローカルの UTM ゾーン。全球の面積統計には EPSG:6933 のような正積図法）。CRS が未定義の場合は、停止して解決してください。決して黙って推測しないでください。
2. 軸順序の規律。 GeoJSON は lon/lat です。多くの API や人間は lat/lon と言います。パイプライン規模の処理の前に、既知のランドマークで検証してください。
3. 分析前のジオメトリ妥当性。 is_valid を確認してください。修復には shapely.make_valid を使用してください（buffer(0) は使わないでください。パーツを静かに落とす可能性があります）。
4. 行数の会計。 すべての結合/オーバーレイ/フィルターの後で、入力行数と出力行数を報告してください。静かな重複や欠落は、地理空間の最大のバグです。
5. 空間的自己相関への意識。 空間データに対するランダムな訓練/テスト分割はリークします。ML の段階はすべて、ml-experiment-standards → references/spatial-cv-protocol.md の正規プロトコルに従ってください。
6. 列名に単位を含める。 area_ha、dist_km、elev_m — 裸の area は決して使わないでください。単位の混同はコードレビューをすり抜けますが、列名は嘘をつきません。
7. 視覚的 + 数値的検証。 すべての空間出力には、要約テーブルと簡単な地図チェック（.explore()、PNG、または GIS ソフトウェア）の両方を用意してください。混同行列は空間的にクラスター化した誤りを示すことはできません。
8. 再現性。 パッケージのバージョンを固定し、乱数にシードを設定し、パラメータをログに記録してください。中間成果物は GeoPackage または GeoParquet に保存し、shapefile は決して使わないでください（列名が 10 文字で切り詰められ、2 GB の制限があり、適切なエンコーディングもありません）。

国際化に関する注意

非 ASCII ロケールにおける属性テーブルは、単純な文字列処理を破綻させます。 代表的な例: トルコ語の点付き/点なし I — Python では 'İ'.lower() が 2 文字の文字列を返します。属性に対する文字列マッチングを行う前に、 ロケールを考慮した正規化ステップを適用し、クリーニング後のカテゴリカル フィールドの value_counts() を表示してください。UTF-8 形式を優先して ください。レガシーなシェープファイルは cp1252/cp125x の文字化けを 黙って含んでいる可能性があります。

スタックの選択

デフォルトではオープンな Python スタックを使用します: GeoPandas + Shapely 2 + Rasterio + xarray/rioxarray + PyProj。データが快適に扱えるメモリ量を超える場合（おおよそ 数百万フィーチャ）や、並行・反復的なクエリが必要な場合は PostGIS にルーティングし、 データがローカルファイルではなく惑星規模のアーカイブである場合は Earth Engine にルーティングします。 大量のフォーマット変換には GDAL CLI を使用します。ユーザーが ArcGIS Pro や QGIS で作業している場合は、クリック手順ではなくヘッドレスで実行可能な スクリプト（arcpy / PyQGIS）を生成し、分析ロジックのポータビリティを 保ってください。

早期に捕捉すべきアンチパターン

• 度単位でのバッファリング（「0.01 度バッファ」） — まず再投影してください。
• EPSG:4326 → Web Mercator での面積統計 — メルカトル図法は赤道から離れるほど 面積を大幅に歪めます。
• 位置合わせなしで異なる CRS のデータセットを結合すること。
• DEM の nodata 値（-9999、3.4e38）を実際の標高として扱うこと。
• 雲・影のマスクを確認せずに画像を分類すること。
• 空間的に独立したテストセットなしでモデルの精度を報告すること。

実行契約

• ワークフロー: 目的と成果物を明確化し、多段階の問題を分解し、各段階を Skill ツールで呼び出して最も限定的なスキルにルーティングし、ハンドオフと不変条件を宣言し、最終成果物を統合して検証します。
• 判断ルール: このオーケストレーターは、曖昧な作業または分野横断的な作業に対してのみ呼び出してください。単一の明確にスコープされたタスクは、その専門スキルに直接ルーティングしてください。
• 検証プロトコル: 段階レベルの受け入れチェック、カウントと CRS のハンドオフアサーション、エンドツーエンドの来歴、および元の問いに対する最終成果物のレビューを必須とします。返す前に、応答で名前を挙げたすべての専門スキルが実際に呼び出されたこと、およびルーティングされた修正の数が指摘事項の数と一致することを確認してください。
• 失敗モード: 所有権、単位、CRS、時間的な整合、エビデンス基準、または段階間のインターフェースが曖昧なままの場合は一時停止してください。未解決の専門スキルの失敗を決して隠さないでください。ルーティングの提案を呼び出しの代わりにすることは決してせず、ルーティングされた修正を後のターンに先送りすることも決してしないでください。
• 成果物: パイプライン計画、スキルルーティング表、段階ごとの入力と出力、検証ゲート、リスク登録簿、および最終統合チェックリスト。
• ソースの鮮度: インターフェースを確定する前に、権威あるソースのレジストリ および選択した専門スキルのレジストリを参照してください。