PLATEAUエージェントとCity Data Toolkitの実装

Transcript

1. OPENING 01 / 20 PLATEAUエージェントと City Data Toolkitの実装 PLATEAUを自然言語と地図から使う city-data-toolkit と city-data-agent で 検索・変換・可視化・ 解析 city-data-toolkit city-data-agent PLATEAU 株式会社MIERUNE / @nokonoko̲1203 / MIERUNE JCT #4
2. ABOUT ME 02 / 20 Satoru Nishio @nokonoko̲1203 Principal Engineering Manager at MIERUNE Inc. 3D WebGIS Point Cloud AWS Community Builder (AI Engineering) Project PLATEAU Advocate Cesium Certified Developer X: twitter.com/nokonoko̲1203 LinkedIn: linkedin.com/in/satoru-nishio
3. ICEBREAK 03 / 20 GISをご存じの方〜〜〜は全員だと思うので、別の質問！ Q ChatGPT や Claude を触ったことがある方？ Q コーディングエージェントに仕事を任せたことがある方？ 最近のエージェントの発達はすごい。調べる・コードを書く・ツールを呼ぶ・結果を見て次を決める、まで 一人でやる。 では、位置情報や地理空間データについてはどうでしょう？
4. PROBLEM 04 / 20 LLMは依頼を理解できるが、住所から正確な位置は割り出せない 位置と計算をLLM自体に任せると、再現も検証もできない。 LLMでできるようになったこと LLM自体では確定できないこと • 曖昧な依頼の解釈 • 住所・地名 → 正確な緯度経度（渋谷駅か、渋谷区か） • 必要な手順の組み立て • 「周辺」の範囲を座標で切り出す • 結果の説明 • 距離・面積・交差などの空間計算 • ツールの呼び出し・コード生成 • 座標参照系の違いと変換 「渋谷駅周辺の建物データを検索して」 → 場所・目的を読みとり、作業できる それらしい値を生成してしまい、再現も検証もできない 最近のエージェントは？ 地図検索やWeb検索で位置を割り出すことはある。ただしそれはLLM本体ではなくツールの能力。何のツールに任せるかが鍵になる
5. APPROACH 05 / 20 位置はデータで確かめ、空間演算はGISで行う LLMは目的を読み取り、手順を 組み立て、結果を見て次を判断する ツールの結果を見て次の行動を決めるところまでが、エージェントの仕事。 依頼を解釈する › ツールを選ぶ › GISで処理する 再現・検証できる計算 › 結果を見る ↺ 観測結果をもとに次の行動を決める GIS TOOL 地名解決 GIS TOOL PLATEAU検索 GIS TOOL Converter GIS TOOL 空間解析 先行研究でも 依頼をGISの手順に変えて既存ツールで実行する方式が評価されている。コードや座標系の誤りは残る。
6. PRIOR WORK 06 / 20 LLM x GISの先行事例には手元のエージェントと、 Webから使う入口から使う 入口がある どちらも、データ接続と専門ツールを組み合わせる構成を参考に。 Microsoft aws-samples Planetary Explorer Geospatial Power Pack Webの対話・可視化を含む参照実装 Kiroを中心とする開発環境 自然言語からデータ選択と地図へつなぐ MCPサーバー MCP・ツール・スキルを組み合わせ、データ取得、GIS github.com/microsoft/Planetary-Explorer github.com/aws-samples/sample-geospatial-kiropower-pack も備える 処理、モデル利用、AWSの計算基盤へつなぐ
7. TARGET 07 / 20 「場所を決める」「都市モデルを探す」「使える形式にする」をひと続きに PLATEAUにはCityGML、検索API・MCP、Pack APIが揃い、LLMから扱いやすい。 場所を決める › 都市モデルを探す › LOCAL ̶ AIクライアント WEB ̶ ブラウザ city-data-toolkit city-data-agent MCP・スキルとして呼び出す。ファイルは 会話と地図から操作し、成果物をWebで保 ローカル作業領域へ 存・配信 使える形式にする DATA PLATEAU CityGML 検索API・MCP CityGML Pack API
8. TOOLKIT 08 / 20 city-data-toolkit は4つのMCP スキルで依頼から処理を組み合わせる 場所と範囲 PLATEAU検索・取得 賢いエージェントは、道具を渡さなくても ある程度たどり着ける 地名検索、地点からBBOX作成、拡 大縮小、移動、BBOXの座標参照系 変換 それでも明示的に用意する理由 作業がぶれない 変換 空間解析 MVT、3D Tiles、GeoPackage 建築物集計・抽出、交差・近接 Webのハーネスから同じ処理を使う 範囲作成 ／ PLATEAU準備 ／ 空間解析
9. DEMO 09 / 20 デモ 「渋谷駅周辺の建物データを検索して」から、抽出件数まで 01 場所と範囲を決める › 02 候補と形式を選ぶ 次のスライドから、この流れの裏側を順に見ていく › 03 変換して地図に載せる › 04 ダウンロード・抽出
10. ARCHITECTURE 10 / 20 ローカルはMCPで動かして保存すれば済むWebでは状態・処理環境・配信が加 わる LOCAL WEB AIクライアント › ブラウザ › 4つのMCP › city-data-agent › 01 状態管理 会話・範囲・候補・地図・成果物の状 態を保持し続ける ブラウザはまず agent につなぎ、状態は そこに集める Toolkit処理・ Converter Container内の Toolkit 処理・Converter 02 処理環境 数分かかるGIS処理は軽量な環境では 動かしづらい Container に置き、接続と処理の安定性 を担保する 専門処理は共有 ̶ 両方とも同じPythonパッケージ › ローカル作業領域 › R2 に保存・配信 03 保存・配信 置いたままでは終われない R2 に保存し、ブラウザから参照・ダウ ンロード・削除できる形にする
11. ARCHITECTURE 11 / 20 WebはMCPを経由せず、agentが所有するContainerに同じ処理を組み込む Webでも4つのMCPを直接呼ぶ、というのはやめる。 採用した案 検討した案 Toolkit を別 Worker にして Service Binding で 呼ぶ › agent（Durable Object）が Container binding で自 分の Container を起動し、その中の Toolkit 処理を呼ぶ 01 境界が増える 02 MCPはAIクライアント向け 03 公開MCPの要件がない 状態・鍵・内部URLの受け渡しが複雑 になる Webでは呼ぶ処理と順序を agent 側 で固定したい 認証や利用制限を持つ必要がない Toolkit は Cloudflare なしで単体で使え、専門処理の修正は一箇所で済む
12. CONVERSATION FLOW 1/5 12 / 20 地名から、確認できる対象範囲へ 「渋谷駅周辺の建物データを検索して」 場所: 渋谷駅 地物型: 建築物 目的: 検索 地点の解決 一意なら初期AOI、複数なら候補を提示 既定範囲 駅・施設は代表点から東西南北250m 、約500m四方 確認・編集 地図で範囲を直し「この範囲で検索」 で確定 難しいところ 地名は曖昧 ̶ 渋谷駅か渋谷区か。範囲の作り方が変わる 「周辺」に定義はない ̶ 既定値は仮置き。地図で直せる必要 がある 外部サービスは揺れる ̶ 0件、複数、自治体全域に広がる 頼まれたのは検索だけ ̶ 勝手に変換・解析へ進まない
13. CONVERSATION FLOW 2/5 13 / 20 検索結果を確認し、次に進むかは利用者が決める 確定した範囲で候補を検索する。変換は、形式を選んで実行したときだけ進む。 候補を確認 確定した範囲でCityGML候補を検索。地物型 ・自治体・年度・メッシュ・LODを表示 変換先を選択 候補ごとの選択欄から形式を選ぶ MVT 3D Tiles GeoPackage 変換を実行 選択だけでは始まらず、変換ボタンで実行。 依頼で形式が確定していれば、エージェント が進める 変換対象はCityGMLファイル全体。範囲外の 地物を含む
14. CONVERSATION FLOW 3/5 14 / 20 CityGML取得 → 変換 → 検査 → 保存・配信確認 Container内で進み、表示用の参照だけを返す。 01 取得 選んだ候補を確認し CityGML Pack API で 取得 02 › 変換 採用版を固定した PLATEAU GIS Converter 03 › 検査 タイル配置・範囲・ズ ーム 形式ごとに 04 › 保存 R2 ／ ローカルは RustFS 05 › 配信確認 静的URLから取得でき るか 地図レイヤーへ ダウンロード成果物へ MVT ̶ 2D表示用にタイルを直接生成し、静的配信 3D Tiles ̶ 3D表 GeoPackage ̶ アセット一覧から取得し、手元の 示用にタイルを直接生成し、静的配信 GISで利用
15. CONVERSATION FLOW 4/5 15 / 20 Cesiumで確認し、成果物を持ち帰る 地図で確認 MVTと3D Tilesを同じシーンで見る レイヤーを操作 表示・透明度・対象範囲への移動・削除 GeoPackageを取得 アセット一覧からダウンロードし、手元のGISで 利用
16. CONVERSATION FLOW 5/5 16 / 20 追加の依頼で建物を抽出する ̶ 解析は建物属性と2次元の幾何形状に基づく 「この範囲の建物から、高さ30m以上のものを抽出して件数を教えて」 抽出 集計 先ほどの候補とAOI 件数・面積・高さ ・階数・用途 を引き継ぎ、属性 条件で抽出。件数 と後続解析用の選 択条件を返す 交差 近接 2次元形状の交差 距離閾値以内の最 近傍参照を対象ご とに
17. HOW IT RENDERS 17 / 20 都市モデル・地形・2Dベクターを、同じ地理空間に載せる MVTと3D Tilesは静的配信したタイルをCesiumが同じシーンで読む。GeoPackageは表示に使わず、ダウンロードして使う。 MVTタイルを 直接生成・保存 CityGML › Converter › › 3D Tilesを 生 成・保存 XYZ形式の URLで 静的配 信 › tileset.json › を 静的配信 MVTDataProvider CesiumJS の › Cesium3DTileset › 同じシーン 都市モデル + 地形 + 2Dベクター GeoPackageを 生成・保存 › ダウンロード 表示には使わない 手元のGISで利用 大きなMVTは、表示範囲と倍率に応じて読み込む範囲・詳細度を調整する。MVTDataProviderはブラウザ内でMVTを描画用データへ変 換する。
18. PRINCIPLES 18 / 20 「地図に追加した」と言えるのは、描画を観測したときだけ 「実在する対象を渡す」「処理結果を検査する」「画面の結果を観測する」の3点。 01 実在する対象を渡す 対象データは保存済みの候補と照合してから処理する 02 処理結果を検査する 変換後はファイルと配信を確認する 03 画面の結果を観測する レイヤーを登録できても、描けたとは限らない。ブラウザ から描画状態を受け取り、描画されたときに表示完了と説 明する。LLMの本文が空なら観測結果をもとに回答を修復 上: レイヤー登録直後 ̶ 変換は完了、可視地物は0 下: 同じ視点で描画後 ̶ rendered 読み込み中 地物なし GISで処理する › エラー 範囲への移動待ち 結果を見る ↺ rendered ブラウザの観測結 果
19. CHALLENGES 19 / 20 継続して使うために残る課題 「変換できた」と「元データが保たれた」は別。実データでの検証を重ねる。 データと品質 継続して使う仕組み 実サービスでの確認 • AOIと変換対象ファイルの範囲差 • GeoPackageのダウンロード • 外部API・LLMへの依存 • 地物・属性の欠落検証 URL更新 • 実データの通し確認 • データごとの高さ整合 • 静的タイル群の公開・更新・削除 • 長時間処理の再開 • 保存量と処理コスト（描画用3D Tilesの追加分） • 本番R2・高密度データでの検証
20. WRAP UP 20 / 20 GISの専門処理へ、会話と地図の入口を作る 01 LLMが依頼を解釈し、GISエンジンが専門処理を担う 02 共通の処理を、ローカルとWebの入口から使う 03 対象・成果物・描画結果を確認して、利用者へ返す 実運用の課題はまだありますが、都市データをこんなふうに使えるとよい、と いう試作の紹介でした。 city-data-toolkit city-data-agent