GeoSQL：AIに地図を見せると精度が4倍向上（韓国語）
GeoSQLは、地図の可視化フィードバックをAIエージェントのループに統合し、空間クエリの精度を大幅に向上させる地理空間分析スキルです。テキストのみでは検出できない幾何エラー（ポリゴンの異常、座標のずれなど）を、データベースのスキーマ探索、データベース固有のSQL自動生成、コスト事前チェック（BigQuery）、結果検証、地図レンダリングと自己修正のステップで解決します。ベンチマークでは地図フィードバックにより4倍の精度向上が確認されています。制限として、コスト制御はBigQueryのみ、テストセットが小規模などがあります。
地理データ分析において最も一般的なミスは、数値だけでは絶対に気づかないものです。クエリは正常に実行され、数値ももっともに見えますが、地図に描画すると、ソウルの麻浦区がソウル全体を覆っていたり、同じ地域が二重集計されていることが判明します。GeoSQLは、この「地図を見る」ステップをAIループに組み込みました。
GeoSQLとは？
GeoSQLは、Claude、Codex、GitHub Copilotにインストールする地理空間分析スキルです。「エージェントループに地図を入れよ——テキストだけでは見えないエラーが地図で明らかになる」が理念です。自然言語で質問するとAIが空間SQLを作成し、結果を地図にレンダリングして自己レビューし、異常があれば修正して再実行します。PostGIS、BigQuery、Snowflake、Wherobotsをサポートし、SaaSアカウントなしでオンプレミス運用可能です。
なぜ既存のAIエージェントだけでは不十分か？
AIは地図を見ることができません。通常のエージェントはSQL実行結果をテキストテーブルで受け取ります。たとえば「ロンドンの各地区の学校アクセス分析」を依頼すると、数値結果を受け取り「完了」と報告します。しかし実際には、シティ・オブ・ロンドン（約3km²）という小さな地区がグレーター・ロンドン（約1,572km²）のポリゴンに誤マッピングされている可能性があります。数値では異常に見えませんが、地図に描けば一目瞭然です。テキストのみのエージェントはこのエラーを見逃します。また、空間SQLはデータベースごとに方言が異なります。距離計算ひとつとってもPostGISはST_Distance、BigQueryはST_DISTANCEと異なり、座標系の扱いも違います。さらにビッグデータ空間クエリのコストは予測不能で、一度の全国建物ポリゴンテーブルフルスキャンで数十ドルかかることもありますが、エージェントはコスト検討なしに実行します。
GeoSQLの動作手順
「ソウル江南区で競合コンビニから遠く、人口流動が多い商圏トップ10を地図で表示」という要求を例にします。
- データベース探索：AIがデータベースの実際のメタデータ（テーブルやカラム）を直接読み取り、スキーマを推測しません。Overture MapsのBigQuery・Snowflake共有データセットも自動探索します。
- SQL作成：接続されたDBに適した空間関数を自動選択しSQLを作成します（PostGISならST_Distance、BigQueryならH3グリッド集計など）。
- コスト事前確認（BigQuery）：クエリ実行前にスキャン量を見積もり、デフォルト上限10GiBを超える場合は、検索範囲を狭めたりフィルタを追加して低コストなクエリに自動再作成します。
- 結果検証：クエリ結果からポリゴンなら総面積、ラインなら総長さを計算し、「江南区の総面積がソウルより大きい」など常識的にありえない結果をこの段階でフィルタリングします。
- 地図に描いて見る（核心）：結果をDekart経由でKepler.gl地図にレンダリングし、その地図画像を再びAIに見せます。AIが「このポリゴンが異常に大きい」「この点が海に打っている」などの視覚的エラーを発見したらSQLを修正し最初から再実行します。
GeoSQLチームのベンチマークでは、地図フィードバックループを有効にした場合としない場合で性能差が4倍でした。テキスト検証だけでは通過していた幾何エラーが、地図を見る瞬間にすべて捕捉されました。
Dekart：地図を描画するエンジン
GeoSQLが地図レンダリングに使用するツールがDekartです。Uberが開発したオープンソース地図可視化ライブラリKepler.glのセルフホスティングバックエンドです。一行のDockerコマンド（docker run -p 8080:8080 dekartxyz/dekart）で実行でき、設定不要で即座に動作。社内サーバーでもローカルでも使用可能です。データベース認証はユーザーのローカルCLI（bq、snowなど）を使うため、ウェアハウスのパスワードがAIに渡ることはありません。
実際の使用例
pipまたはプラグインでGeoSQLをインストールし、Dekartを起動後、「/geosql ソウル九老区の主要道路5km半径内のEV充電スタンド密度を表示」のようなプロンプトを入力します。GeoSQLはOverpass APIでデータ収集、Haversine式で密度集計（DuckDB使用）、道路種別ごとに分類してDekart地図にレンダリング。道路種別、セグメント数、平均EV密度のテーブルとインタラクティブ地図が生成され、都心交差点（九老デジタル団地・加山・新道林）に充電スタンドが集中し、京釜高速道路・オリンピック大通り外周では密度が低いことが明確になります。
テキスト専用エージェント vs GeoSQL
テキスト専用エージェント：幾何エラー検出は数値異常のみ、スキーマ推測、DBごとのSQL方言混同、コスト管理なし、出力はテーブル・数値。 GeoSQL：地圖視覚確認、DBから直接スキーマ探索、エンジン別自動SQL選択、実行前コスト見積もり・自動再作成、出力はインタラクティブ地図、性能4倍向上。
限界
- 地図フィードバックはDekart接続時のみ有効。4倍向上はDekart連携時のみ。
- コストガードレールはBigQuery専用。PostGIS・Snowflakeではコスト制御なしで実行。
- ベンチマークはまだ小規模（ロンドン・ベルリン・パリの3都市、8テストケース）。
- 閉鎖ネットワーク環境では追加設定が必要。
まとめ
AIが地図分析でミスする根本原因はクエリ能力不足ではなく、結果を見られないことです。GeoSQLのアプローチは単純です。AIに地図を見せればよいのです。オンプレミス・閉鎖ネットワークで空間データを扱う組織にとって、GeoSQL + Dekartの組み合わせは、データを社内に置きながらAIエージェントレベルの空間分析を行う選択肢の一つとなります。
参照：GeoSQL GitHub、Dekart GitHub、Dekart公式ドキュメント、Kepler.gl。