AIエージェントとの協業で「施設ポリゴン作成の効率化」を試みた話

はじめに

こんにちは。AI技術開発部の佐竹です。

タクシーアプリ『GO』では、タクシー需要を詳細に分析するため、駅や病院といった施設ごとに「その施設を起終点とする乗降が発生する場所」を地理的な境界（ポリゴン）として定義しています。本記事では、AIエージェントを活用して、この施設ポリゴン作成を効率化している取り組みを紹介します。

なぜ「施設ポリゴン」が必要なのか？

タクシー需要の分析では、地球表面を六角形グリッドに分割するH3 1 などの均一メッシュで面的に需要を可視化する手法が一般的です。一方で、「駅周辺のニーズ」や「医療施設への通院パターン」など、施設を起点とした分析が必要な場面も多々あります。

このような施設起点での分析を行う際、タクシーの乗降データ（緯度経度の点）と施設の「中心点」を直線距離で単純に紐付けると、建物の形状や周辺道路を考慮しないため、大きな問題が生じます。例えば、複数の出入り口を持つ巨大な駅や、広大な敷地を持つ病院の場合、中心点からの距離だけで判定すると、実際には施設を利用していない乗降を拾ってしまったり、逆に正当な利用を取りこぼしてしまったりします。

この精度の粗さを解消し、施設の実態に即した需要を正確に捉えるために、面的な広がりを持つ「施設ポリゴン」が不可欠となります。

施設カテゴリごとに異なる作成の壁

では、既存の地図データや航空写真をなぞれば簡単にポリゴンを作れるかというと、そう単純ではありません。地下空間に複雑に広がる施設や、広大な敷地内に構内道路を持つ施設など、現実の空間構造は多様です。そのため、施設のカテゴリ（駅、病院、商業施設など）によって適切なポリゴンの作成方法が全く異なります。

具体的には、以下のようなアプローチの違いが生じます。

  • 鉄道駅: 国土数値情報の鉄道データ2 を元に、駅の形状などに沿って周囲に一定幅のポリゴンを設定し、地下鉄の駅については、データから直接判定する情報がないため、個別の手作業ではなくAIエージェントで効率的に情報収集・判定した上で、出入口周辺の緯度経度情報からポリゴンを作成
  • 病院: 建物の形状データ（OpenStreetMap3 やOverture Maps4 など）の利用や、それらのデータがない場合でも国土数値情報の医療機関データ5 を元に、病院の病床数や敷地の規模に応じた範囲の拡張を行うことでポリゴンを作成
  • 商業施設・イベント会場: 公開データでの特定が困難なため、AIエージェントで候補施設リストを生成させ、緯度経度を検証したうえでポリゴンを作成

このように、施設カテゴリごとに異なるデータソース・異なるアルゴリズムが必要になります。

Before / After: 従来プロセスの課題と変化

従来も施設ポリゴンの作成自体はSQLで行っていましたが、新しいカテゴリの設計や地域展開の際に、以下のような繰り返し作業がボトルネックになっていました。

BeforeAfter

課題:

  • スケールしない - 新しいカテゴリを追加するたびに同じ手作業が発生し、複数地域への展開も繰り返しになる
  • 属人化 - 「なぜこのパラメータの閾値となったのか」「なぜこのデータソースを選んだのか」の判断根拠が作業者個人のメモにしか存在しない
  • 再現性の欠如 - パラメータやデータソースを見直したい場合、作業をほぼゼロからやり直す必要がある
  • アプローチの試行錯誤が高コスト - 1つのアルゴリズム変更を検証するだけで、SQLの大部分を書き直す必要がある

具体的にどこが変わったのかを示すと、例えば駅ポリゴンの場合:

工程 Before After
施設リストの作成 対象地域内の駅を洗い出し、地図サービスなどで駅の形状やタクシー乗り場の有無などの施設特性を目視確認 AIエージェントにより、ポリゴン作成に必要な特性（地上/地下、タクシー乗り場の有無など）の洗い出しと施設リストの作成を一元化
ポリゴン形状の決定 地図上で可視化しつつ、設計で考慮しきれなかった個別条件をSQL内に直接埋め込む対応と修正を繰り返す（結果として整合性の追跡が困難に） AIエージェントとの壁打ちで、複雑な地理条件を言語化、および仕様変更に強い構造に変更することで、特定の条件のみを独立して検証できる状態を確立
品質確認 ポリゴン形状を目視確認 集計値で俯瞰レビュー、および異常値の確認を行った上で、AIエージェントと壁打ちし、修正

取り組み: AIとの協業プロセス

位置づけ

GIS 6（地理情報システム）領域では、AIエージェントを「意思決定の中核」として活用し、地理空間情報の分析のためのワークフローを自律的に生成・実行する研究 7 など、AIエージェントによる自動化を目指す取り組みが活発に進んでいます。本取り組みはそれらとは異なり、人間が方針を決めてAIエージェントと壁打ちしながら、ロジック検討やSQL実装を共同で行うという協業スタイルです。「AIエージェントに丸投げしてポリゴンが出てくる」のではなく、人間がアルゴリズムの選択やパラメータの判断を行い、AIエージェントにはワークフローやロジックなどの設計の壁打ち、コードの実装を担ってもらうという役割分担です。加えて、公開データとの紐付けが困難なケースではAIエージェントに候補施設リストを生成させ、手作業で検証したうえでSQLに組み込むという使い方もしています。

実際のワークフロー

実際の作業は、以下のサイクルの繰り返しです。

実際のワークフロー

以下、このプロセスの中で体系化したアプローチを説明します。

アプローチ1: 複数データソースの優先順位付き組み合わせ

施設ポリゴン作成で最初にぶつかる問題は、1つのデータソースでは全施設をカバーできないということです。建物の形状データがある施設もあれば、緯度経度の点情報しかない施設もあり、そもそも公開データが存在しない施設もあります。

この問題に対して、カテゴリ横断で共通して採用したのが 「複数データソースに優先順位をつけ、上位で取れなかったものだけ下位のデータソースで補完する」 構造です。

具体的には、各カテゴリで以下の共通パターンで実装しています。

  1. 精度の高いデータソースを最優先に、マッチする施設を処理
  2. マッチしなかった施設だけを次の補完用のデータソースへ送る
  3. 最終的に全データソースの結果を結合して出力

この構造が各カテゴリでどう具体化されるかは異なりますが、共通しているのは以下の点です。

  • 精度が高いデータソースほど優先順位を高くする
  • 施設とデータソースの紐付けは、空間的な近さ（距離閾値内に存在するか）と名称の一致を組み合わせて判定する
  • 施設の種別・特性（地上/地下、施設規模など）によって適したデータソースが異なる場合は、特性を振り分け条件として組み込む

この「優先順位 + 補完」の構造自体は、AIエージェントとの壁打ちの中で自然にできあがりました。最初は1つのデータソースで全件処理しようとして精度が出ず、「取れるものと取れないもので分けて考えましょう」という方向に対話が進んだ結果です。

アプローチ2: 複雑な地理条件の体系化と施設特性を網羅的に捉えるロジックへの落とし込み

ポリゴンの「形状をどう決めるか」は、同じカテゴリ内でも多様な地理的条件が絡み合う複雑な設計問題です。駅ポリゴンでは、地上/地下の区別やロータリーの有無といった主要な地理的バリエーションを設計時に漏れなく考慮する必要があります。従来は、こうした考慮漏れが発覚するたびに、個別条件をSQL内に直接埋め込む対応を繰り返していました。その結果、「この条件だけ変えたい」のに大部分を書き直す必要が生じる状態に陥り、前のロジックとの整合性の追跡も困難になっていました。

この問題の本質は、実装の煩雑さではなくロジック設計が整理されていないことにあります。AIエージェントとの壁打ちで取り組んだのは、頭の中にある複雑な地理条件やドメイン知識を言語化した上で、ポリゴン作成のステップを体系化・再設計することです。「この地理的条件ではどのパターンに分岐するか」「このケースはカテゴリ全体でどう一般化できるか」をAIエージェントとの壁打ちで整理する中で、「このロジックだとこの条件では網羅できない」「このケースは別パターンとして分離が必要」と先回りした指摘により改善を進めることができました。

この壁打ちを通じて、ドメイン知識は以下の3つの明確なステップへ落とし込みました。

  1. データ統合・前処理（ステップ1）: 複数データソースを施設単位に統合し、路線数・地下鉄判定などの属性を付与
  2. 地理的条件を考慮したロジック設計・実装（ステップ2）: 統合データをもとにロジックの設計・実装、パラメータ調整を実施し、ポリゴン形状を確定
  3. パラメータ適用（ステップ3）: 施設周囲の拡張幅・ポリゴンの面積上限などの閾値を適用してフィルタリング

各ステップの役割が明確になったことで、「施設周囲の拡張幅を変える」という変更はステップ3に、「データソースを変える」という変更はステップ1にのみ影響が閉じるようになり、AIエージェントとの壁打ちでも「このパラメータを変えるとどのステップの何が変わるか」を体系的に議論できるようになりました。

なお、パラメータ調整についてはベイズ最適化などで自動チューニングするアプローチも考えられます。しかし、ポリゴンの「良さ」は単一の目的関数で表現しづらい性質があります。需要データにはノイズが多く、「面積が小さすぎて需要を拾えない」と「大きすぎて隣接施設と重なる」のトレードオフは地域・施設規模ごとに異なります。現時点では、人間のドメイン知識をガードレールとして迅速に反映・検証するステップとして、AIエージェントとの手動での繰り返し処理が最も実用的でした。評価指標の設計が固まれば自動チューニングも選択肢になりえます。

アプローチ3: AIエージェントによる候補施設リストの生成と検証

対応する公開データがない（飲食街など明確な施設や範囲が定義されていない）ケースへの対応や、公開データにないメタ情報（「この駅にタクシー乗り場はあるか？」）が必要な場面があります。こうしたケースでは、複雑なアルゴリズムを構築するよりも、AIエージェントに候補施設リストを生成させて手作業で検証・修正（「生成された施設が存在するか」、「緯度経度のずれがないか」、「施設の抜け漏れがないか」を確認し修正）するほうが現実的でした。そこで、AIエージェントに候補施設リストの生成を依頼し、それらを検証・修正する方法を取りました。

Approach3

依頼例:

東京都のコンサート・スポーツイベント開催施設を100件リストアップしてください。
条件:
- 収容人数5,000人以上のアリーナ・スタジアム・ホールを優先
出力フォーマット例（JSON）:
[{"facility_name": "施設名", "address": "住所", "latitude": 緯度, "longitude": 経度, "capacity": 収容人数}]

ここで重要なのは、AIエージェントの出力をそのまま使っていないことです。出力されたリストには以下のような問題が常に含まれます。 - 現存しない施設（施設が閉館済み、など）が混入する - 緯度経度が正確な位置から大幅にずれている - タクシー需要が大きいと見込まれるが、リストから漏れる施設がある

このため、地図サービスでの目視確認を必ず行い、修正したうえでSQLに組み込みます。AIエージェントの役割は「候補の一次リストを素早く作る」ことであり、最終的な採否判断は人間が行っています。従来は1施設ごとに確認していた作業が、「生成されたリストの検証・修正」に変わった、という意味での効率化です。

ただし、施設の閉館や移転を継続的に検知し、管理する仕組みや、AIエージェントのハルシネーション（実在しない施設の生成や緯度経度の大幅なずれ）に対する手作業による検証コストの低減は引き続きの課題です。

アプローチ4: 知見の蓄積とAIエージェントへの受け渡し

カテゴリを1つ進めるごとに、「うまくいったアプローチ」と「失敗して捨てたアプローチ」の両方が蓄積されます。これをMarkdownファイルとして記録し、次の試行でAIエージェントに受け渡すことで、同じ失敗の繰り返しを防ぎました。

例えば、ある施設カテゴリで複数のアルゴリズム試行を行った際のMarkdownファイルには以下のような記録があります。

## 知見: ポリゴンが大きくなりすぎる問題
- 道路が少ない地域では、切り出されるブロックが街区全体になってしまう
- 面積の上限値を設けて除外する対処を追加
- ただし大学病院など大規模施設では正当に広い場合がある → 施設規模に応じた閾値が必要

## 知見: 対象施設の検索範囲
- 対象地域の内側だけで検索すると、地域境界付近の施設を取りこぼす
- 周辺まで広げると候補が増えすぎてノイズになる
- まず対象地域内で取得し、漏れた施設のみ周辺に広げる2段階方式が安定

このMarkdownファイルをAIエージェントに受け渡すと、「前に試したけどポリゴンの面積上限だけだと不十分で、施設規模に応じて閾値調整を行ったほうがいいと学んだ」という文脈を踏まえたコードを提案してくれるようになります。

さらに、あるカテゴリでまとまった処理フロー全体（データソース、処理ステップ、品質チェック基準、パラメータ体系）をMarkdownで整理しておくことで、次のカテゴリに着手するときにそのファイルをAIエージェントに渡して「同様の構造で、データソースをこれに変えたい」と依頼できます。こうして、1カテゴリ目のアプローチが2カテゴリ目以降の雛形として機能するサイクルが生まれました。

アプローチ5: レビューの仕組み

カテゴリ共通で、SQL実行結果の集計値による俯瞰レビューを行います。全施設を地図上で1つずつ確認するのではなく、以下のような数値で「想定通りか」を確認します。 - 各データソースの適用件数、候補作成リストの対象施設に対する適用比率 - 特定カテゴリにおけるポリゴン面積の過大、過小など異常値の有無

例えば、優先順位の高いデータソースの適用件数が多く、適用比率も高ければ、そのカテゴリにおけるポリゴンの品質が担保される、といった判断を行っています。想定外の件数が出た場合のみ、地図上で個別に可視化して詳細確認します。この「集計で俯瞰後に、異常値のみ目視確認」というレビュー方式自体も、全件分の目視確認が現実的でなくなった時点で自然にこうなったものです。

学び

特に効いた点:

  • 複雑な処理の高速実装: 複数のアルゴリズム案を並行して試し、各案について数百行のSQLをAIエージェントと共同で高速に作成・修正を進めることができた（手動では2〜3案で妥協していたはず）
  • カテゴリ横展開: 1つのカテゴリでまとまった構造（データソース、処理ステップ、品質チェック基準、パラメータ体系）を別カテゴリに流用できたことで、別カテゴリの展開を効率的に実行できた
  • 知見の外部化: 試行錯誤の過程をMarkdownに記録することで、「前回はこう失敗した」という文脈をAIエージェントに渡せるようになり、属人的な記憶に依存しなくなった
  • 候補施設リストの生成: 公開データがないカテゴリの候補施設作成が、1施設ごとの手作業による調査から一括生成とリストの検証・修正に変わった

効きにくかった点:

  • 局所的な地理問題: 「2つの隣接施設のポリゴンがデータソースの性質で結合してしまう」「地域境界上に立つ施設が処理から漏れる」のような問題は、各地域の土地勘がないと発見できない
  • AIエージェントが生成したデータの品質: 「緯度経度ずれ」や「閉館済み施設の混入」は常に発生し、手作業での検証は省略できなかった
  • パラメータの最適値: 施設周囲の拡張幅やポリゴンの面積上限などの閾値に絶対的な正解は存在せず、最終的には人間のドメイン知識による判断が必要なため、AIエージェントが出せるのは初期値の提案まで

人間とAIエージェントの役割分担

このプロセスにおいて、人間が判断していることとAIエージェントに任せていることの境界は明確でした。

人間が判断したこと: - データソース選定とその優先順位の決定 - ポリゴン作成における各パラメータの最終的な閾値（途中の閾値はAIエージェントが提案） - 局所的な地理問題の発見と対処方針 - AIエージェント出力の最終検証と採否の判断 - どのアルゴリズム案を採用し、どれを捨てるかの判断

AIエージェントに任せたこと: - 複雑な地理条件やドメイン知識を言語化し、体系的なロジックを設計するための壁打ち - 「このロジックだとこの条件では網羅できない」「このエッジケースは別パターンとして分離が必要」など、計算コストや網羅性の観点から設計上の欠陥や見落としを先回りして指摘すること - 体系化された論理構造に基づいた数百行のSQL実装と、条件分岐のSQLへの具体的な落とし込み - 新しいカテゴリに着手する際の、既存カテゴリの論理構造を踏襲した初期実装 - 候補施設リストの一次生成（アプローチ3）

まとめ

施設ポリゴンの作成を通じて実感したのは、AIエージェントは「作業の代行」ではなく「設計の壁打ち + 実装の加速」に関して最も力を発揮するということです。

AIエージェントに「施設ポリゴンを作って」と丸投げしても使える結果は出ません。しかし、「こういう方針でやりたい。前回はこう失敗した。SQLを書いてほしい」と文脈を渡せば、対話的に実装でき、試行錯誤のサイクルが圧倒的に速くなります。

振り返ると、この取り組みで最も価値があったのは「AIエージェントを使ったこと」自体ではなく、AIエージェントと協業するために知識を構造化した結果、属人的だったプロセスが再現可能になったことかもしれません。主要な判断の経緯や、過去に試してうまくいかなかったアプローチが履歴として残っているため、別の人が別のカテゴリに着手するときにも同じ品質で進めやすくなると考えています。

地理空間データの前処理はドメイン知識の比重が高く、完全自動化は難しい領域です。だからこそ、「人間とAIエージェントの役割分担が明確な協業モデル」という形が機能する余地が大きいと考えています。

  1. H3 - Uber社が開発した六角形グリッドの地理空間インデックスシステム。地球表面を階層的な六角形セルに分割し、集計・可視化に用いる。https://h3geo.org/↩
  2. 国土交通省 国土数値情報 鉄道データ（N02） https://nlftp.mlit.go.jp/ksj/gml/datalist/KsjTmplt-N02-v3_1.html↩
  3. OpenStreetMap - 誰でも自由に地図データを編集・利用できる、オープンデータの協働型世界地図プロジェクト。世界中のボランティアによるデータ収集や航空写真のトレースなどを元に構築されている。https://www.openstreetmap.org/↩
  4. Overture Maps - 大手IT企業らが共同で設立し、Linux Foundationの後援で運営されているオープンな地図データ基盤。複数のソースを統合・検証した相互運用性の高いデータを開発者向けに提供している。https://overturemaps.org/↩
  5. 国土交通省 国土数値情報 医療機関データ（P04） https://nlftp.mlit.go.jp/ksj/gml/datalist/KsjTmplt-P04-2020.html↩
  6. GIS (Geographic Information System) - 地理空間データの取得・管理・分析・可視化を行うシステムの総称↩
  7. Li et al., "GIScience in the Era of Artificial Intelligence: A Research Agenda Towards Autonomous GIS", arXiv:2503.23633, 2025↩