投稿者: admin

～AIエージェントによる統計データクレンジングの実践～

本記事は、生成AIとGISを活用した自治体業務の実証シリーズの第5回です。
関連記事

▶ 第1回：自治体GISとAIの融合
▶ 第2回：ArcGIS Onlineと生成AIを連携した人口統計分析の実証
▶ 第3回：生成AIとGISで健康遊具の優先整備地区を抽出してみた
▶第4回：自治体の人材不足はGIS AIで解決できるのか

はじめに

近年、e-Stat APIを利用することで自治体の人口統計を容易に取得できるようになりました。

生成AIやMCPを利用すれば、

・統計データ取得
・CSV出力
・GIS登録

まで自動化することも可能です。

しかし実際に自治体業務で利用しようとすると、単純なAPI連携だけでは解決できない問題が存在します。

今回は和泉市の小地域統計データを用いて、e-Stat APIとGISデータを結合する際に直面した課題を整理します。

---

和泉市データで発生した問題

まずe-Stat APIから2020年国勢調査データを取得しました。

取得結果は以下の通りです。

• 人口CSV：192件

一方でGIS側の小地域ポリゴンは、

• ポリゴン数：183
• ユニークKEY_CODE：162

でした。

この時点で、

「CSV件数とGIS件数が一致しない」

という問題が発生しました。

単純な属性結合では正しく結合できません。

---

落とし穴① 町集計と町丁目が混在している

e-Statには、

府中町

だけではなく、

• 府中町一丁目
• 府中町二丁目
• 府中町三丁目

なども同時に存在します。

さらに、

府中町

は

一丁目～八丁目

の合計値となっています。

つまり、

町集計
＋
町丁目

をそのままGISへ取り込むと、

人口が二重計上されます。

---

落とし穴② KEY_CODEが一意ではない

和泉市小地域ポリゴンを確認すると、

KEY_CODE

だけでは一意になっていませんでした。

例えば、

27219101000_E1
27219101000_E2
27219101000_E3

のように、

同じKEY_CODEでも複数ポリゴンが存在します。

---

落とし穴③ 人口はE1にしか入っていない

統計データを確認すると、

• E1 → 人口あり
• E2 → 0
• E3 → 0

という構造になっていました。

この状態でKEY_CODEだけを使ってJoinすると、

同じ人口が複数ポリゴンへ付与されてしまいます。

結果として人口が重複計上されます。

---

解決策：JOIN_KEYを作成する

今回採用した方法は、

GIS側

JOIN_KEY

KEY_CODE + “_” + KIGO_E

を作成する方法です。

CSV側も同様に、

join_key

area_code_text + “_” + KIGO_E

を生成します。

その結果、

183ポリゴン
↓
183レコード

で正しく結合できるようになりました。

ArcGIS Pro と CSV 結合で発生する schema.ini の落とし穴

前回の和泉市の分析では、小地域ポリゴンと e-Stat API の人口データでコード体系が一致していなかったため、

KEY_CODE = KCODE_JE + KCODE_E

による JOIN_KEY を作成して結合を行いました。

一方、今回の豊島区データでは、小地域ポリゴンの

area_code

と e-Stat API の

KEY_CODE

が同じコード体系であったため、JOIN_KEY を作成せずに直接結合できる状態でした。

ところが、ここで別の問題が発生しました。

それは ArcGIS Pro が CSV を読み込む際に、コード項目を数値型（Double）として認識してしまうことです。

例えば、

13116001001

という小地域コードは、本来は文字列として扱う必要があります。

しかし ArcGIS Pro は CSV を自動判定するため、

小地域ポリゴン
area_code（Text）

人口CSV
KEY_CODE（Double）

という状態になることがあります。

この場合、値は同じでも型が異なるため Join が実行できません。

そこで利用するのが schema.ini です。

CSV と同じフォルダに schema.ini を配置し、

[toshima_demographics_2020.csv]
Format=CSVDelimited
ColNameHeader=True

Col1=municipality_name Text Width 50
Col2=year Long
Col3=KEY_CODE Text Width 20
Col4=area_name Text Width 50
Col5=population_total Long

のように定義します。

重要なのは、

Col3=KEY_CODE Text Width 20

です。

これにより ArcGIS Pro は KEY_CODE を文字列として読み込みます。

結果として、

area_code (Text)
=
KEY_CODE (Text)

となり、正常に Join できるようになります。

なお、インターネット上では

CharacterSet=65001

を記載している例もありますが、ArcGIS Pro では

schema.ini に値が無効なオプションがあります
CharacterSet=65001

というエラーが発生することがあります。

そのため UTF-8 の CSV を利用する場合でも、CharacterSet の指定は行わず、必要なフィールド定義のみを記述する方が安全です。

今回のように自治体によって、

• JOIN_KEY の作成が必要なケース（和泉市）
• KEY_CODE をそのまま利用できるケース（豊島区）

があります。

ただし、どちらの場合でも ArcGIS Pro 上では「文字列として結合できる状態にする」ことが重要であり、そのための手段として schema.ini が有効です。

---

MCP化して分かったこと

今回の検証で分かったのは、

e-Stat APIが利用できること

と

自治体業務で使えるGISデータになること

は全く別問題だということです。

実際には、

• 統計構造の理解
• 秘匿処理の理解
• 小地域コードの理解
• GIS側データ構造の理解

が必要になります。

今回作成したMCPでは、

• 総人口
• 0～14歳人口
• 65歳以上人口
• CSV出力
• GIS結合用JOIN_KEY生成

まで自動化しています。

---

AIにe-Stat APIを読ませても実務データにはならない

生成AIはe-Stat APIを利用できます。

しかし、

APIが返したデータ

＝

実務で利用できるGISデータ

ではありません。

今回の検証では、

豊島区では問題なく動いた処理が、

和泉市では正しく動きませんでした。

原因を追跡すると、

KEY_CODE
↓
KIGO_E
↓
秘匿処理
↓
JOIN_KEY

という統計構造の違いにたどり着きました。

つまり、

AIがデータを取得できること

と

自治体業務で利用できること

の間には大きな差があります。

---

次のステップは「年齢階級」の細分化

現在のMCPでは、

• 総人口
• 0～14歳人口
• 65歳以上人口

を取得しています。

しかし遊具配置を考える場合、

本当に必要なのは

0～14歳

ではありません。

例えば、

• 幼児用すべり台
• 幼児用ブランコ
• スプリング遊具
• 砂場
• おむつ替え設備

などは、

主に0～4歳児を対象としています。

そのため次の段階では、

• 0～4歳人口
• 5～9歳人口
• 10～14歳人口

を取得し、

より実態に即した分析を行う予定です。

---

今後想定される分析の方向性

今回の検証では、小地域単位で人口統計をGISへ結合できることを確認しました。

今後、公園ごとの遊具配置情報や遊具台帳などのデータが利用できれば、人口統計と組み合わせた分析も可能になります。

例えば、

小地域人口
＋
遊具配置情報

を組み合わせることで、

0～4歳人口100人あたりの幼児向け遊具数

といった指標を作成できる可能性があります。

また、

幼児遊具不足指数

=
0～4歳人口
÷
幼児向け遊具数

のような考え方により、

子育て世代が多い地域と遊具配置状況との関係を可視化できる可能性があります。

現在は構想段階ですが、人口統計と公園施設データを組み合わせることで、公園整備や子育て支援施策の検討材料として活用できる可能性があると考えています。

本手法はe-Stat APIを活用しているため、和泉市に限らず他自治体へも適用可能です。

今後は、実際の施設データと組み合わせながら、GISと統計データを活用した政策検討支援についても研究を進めていきたいと考えています。

AIエージェントによるデータ整備という視点

今回の検証は、単にe-Stat APIから人口データを取得したという話ではありません。

実際には、

e-Stat API
↓
統計コードの確認
↓
KEY_CODEの確認
↓
KIGO_Eの確認
↓
秘匿化構造の確認
↓
JOIN_KEY生成
↓
CSV出力
↓
ArcGIS結合

という複数の工程を経ています。

表面的には「人口マップを作成した」ように見えますが、実際に時間を要したのは統計構造の理解とデータ整備でした。

和泉市のケースでは、

・人口CSV：192レコード
・小地域ポリゴン：183ポリゴン
・ユニークKEY_CODE：162件

という状態であり、単純なJoinでは正しく結合できませんでした。

そのため、

・町集計と町丁目の重複確認
・KEY_CODEとKIGO_Eの関係確認
・秘匿化データの確認
・GIS側との整合確認

を行い、最終的にJOIN_KEYを生成することで正しい結合を実現しました。

従来であれば、このような作業は統計担当者やGIS担当者が手作業で調査しながら進める必要がありました。

今回の検証では、生成AIとMCPを活用することで、こうしたデータ整備作業を支援できる可能性を確認しています。

近年は、

オープンデータ
↓
AIエージェント
↓
データクレンジング
↓
GIS分析
↓
意思決定

という流れが重要になりつつあります。

単に地図を作成するだけではなく、分析に利用できるデータ基盤を整備すること自体が価値となる時代へ変化しています。

今回の成果は、e-Stat APIを利用した人口データ取得だけではありません。

統計データを自治体GISで利用できる形へ変換するための知識とノウハウを整理できたことに、大きな意義があると考えています。

---

まとめ

今回の検証は単なるMCP開発ではありません。

統計データを取得するだけではなく、

自治体GISで利用できる形へ変換するための知識を整理するプロセスでした。

e-Stat APIや生成AIが普及しても、

統計構造やGISデータ構造を理解することの重要性は変わりません。

むしろGIS AI時代だからこそ、

「データを取得する技術」

ではなく、

「実務で使えるデータへ変換する知識」

がますます重要になると考えています。

MCPで取得した人口データを用いた試験分析

今回整備したデータを用いて、

• クラスター・外れ値分析
• 最適化ホットスポット分析

を実施しました。

その結果、

65歳以上人口については有意な空間集積が確認された一方、

幼児人口については明確な集積は確認されませんでした。

これは統計データをGISへ正しく結合できたことで初めて実施できる分析であり、今後は公園施設データや遊具配置データと組み合わせることで、より実践的な政策検討へ発展できる可能性があります。

関連記事

▶ 第1回：自治体GISとAIの融合
▶ 第2回：ArcGIS Onlineと生成AIを連携した人口統計分析の実証
▶ 第3回：生成AIとGISで健康遊具の優先整備地区を抽出してみた
▶第4回：自治体の人材不足はGIS AIで解決できるのか

【自治体GIS×生成AIシリーズ】～総務省調査と実証結果から考える次世代の自治体業務～

本記事は、生成AIとGISを活用した自治体業務の実証シリーズの第４回です。

関連記事

▶ 第1回：自治体GISとAIの融合
▶ 第2回：ArcGIS Onlineと生成AIを連携した人口統計分析の実証
▶ 第3回：生成AIとGISで健康遊具の優先整備地区を抽出してみた
▶第5回：e-Stat APIとGISを結合するときの落とし穴

はじめに

総務省が公表した「自治体における生成AI導入状況（令和7年6月30日版）」によると、生成AI導入における最大の課題は「取り組むための人材がいない又は不足している（562件）」であり、次いで「AI生成物の正確性への懸念（522件）」となっています。

自治体では、少子高齢化による職員数の減少や業務量の増加により、限られた人員で多様な行政サービスを維持しなければならない状況が続いています。

一方で、GIS（地理情報システム）や統計分析は、政策立案や施設管理、防災計画などに有効であることが分かっていても、専門職員が不足しているため十分に活用できていないケースも少なくありません。

そこで注目されるのが、生成AIとGISを組み合わせた「GIS AI」です。

本記事では、実際に行った実証結果をもとに、GIS AIが自治体の人材不足にどのように貢献できるのかを考察します。

---

なぜGISは広く活用されないのか

多くの自治体では、GISやダッシュボードは整備されています。

しかし、

・GISソフトの操作が難しい
・データ更新に専門知識が必要
・統計データの取得が手間
・分析結果の解釈が難しい

といった理由から、実際に活用できる職員が限定される傾向があります。

結果として、

「GIS担当者しか使えないシステム」

になってしまうことがあります。

---

GIS AIとは何か

GIS AIとは、

GIS
＋
統計データ
＋
生成AI

を組み合わせた新しい業務支援の考え方です。

従来は職員が行っていた

・統計データの検索
・CSVの取得
・GISへの登録
・分析処理
・地図作成

といった作業を、自然言語の指示から実行できるようにすることを目指します。

---

実証① 人口統計分析の自動化

地域GIS研究所では、

Codex CLI
＋ e-Stat API
＋ ArcGIS MCP

を利用し、人口統計分析の自動化を検証しました。

職員が

「高齢化率を取得してください」

と指示すると、

・e-Statから統計取得
・属性計算
・ArcGIS Onlineへの登録
・地図化

までを一連の流れとして実行できることを確認しました。

従来であれば複数のサイトやシステムを行き来していた作業を大幅に短縮できます。

---

実証② 健康遊具の優先整備地区の抽出

次に、豊島区をモデルケースとして健康遊具の優先整備地区を抽出しました。

分析では、

・高齢化率
・人口
・既存遊具の配置
・250m利用圏

を組み合わせて評価を行いました。

従来であれば半日程度かかる作業でしたが、統計データ取得からWebマップ作成まで約25分で完了しました。

重要なのは、単なる地図作成ではなく、

「どこに予算を優先投入すべきか」

という政策判断の支援ができた点です。

---

人材を増やすのではなく時間を生み出す

自治体における人材不足は、短期間で解決できる問題ではありません。

しかし、GIS AIは職員の代わりに判断するのではなく、

「判断するための材料を短時間で準備する」

ことができます。

例えばAIが統計取得やGIS更新を行っている間、職員は

・住民対応
・庁内調整
・資料作成

など別の業務を進めることができます。

これは実質的に人材不足を補完する効果を持っています。

---

正確性をどう担保するのか

生成AI活用において最も懸念されるのが正確性です。

今回の実証では、

「推測で人口値を作らない」

というルールを明示しました。

さらに、

・データソースの明示
・統計年次の確認
・利用フィールドの確認

を行い、説明可能な状態を維持しています。

また、MCP Inspectorを利用することで、

・どのデータを参照したか
・どの条件で検索したか
・どのレイヤを更新したか

を確認できます。

これはAI時代のジオプロセシング履歴とも言える仕組みです。

---

今後の可能性

今後は、

「高齢者が多いのに健康遊具が不足している地域は？」

「D判定の樹木が集中している公園は？」

「近くに鉄棒のある公園は？」

といった問いに対して、職員が自然な言葉で質問し、GIS AIが分析結果を提示する環境が現実味を帯びてきています。

これは、専門職だけが扱うGISから、全職員が活用できるGISへの転換を意味します。

---

まとめ

総務省調査によると、自治体における生成AI活用の上位は、

1. 挨拶文作成
2. 議事録要約
3. 企画書案作成
4. メール文作成

となっています。

現在は文書作成支援を中心とした活用が主流ですが、

GISと生成AIを組み合わせることで、

• 統計データの取得
• GISデータの更新
• 空間分析
• 地図作成
• 政策判断支援

までを自然言語で実行できる可能性が見えてきました。

また、総務省調査では導入課題として

• 人材不足（562件）
• AI生成物の正確性への懸念（522件）

が上位に挙げられています。

今回の実証では、

• 推測によるデータ生成を禁止する
• 利用した統計データを明示する
• MCPを利用して処理履歴を確認する

ことで、説明可能性と正確性を確保しながら分析を実施しました。

GIS AIは人材不足を単純に人員増加で解決するものではありません。

むしろ、

• GISの専門性の壁を下げる
• データ整理の時間を削減する
• 分析業務を支援する
• 説明責任を担保する

ことで、限られた人材の能力を最大限活用するための仕組みとして期待されています。

地域GIS研究所では、GIS・統計分析・生成AIを組み合わせた自治体業務への活用について、引き続き実証と研究を進めていきます。

参考資料

• 総務省「自治体における生成AI導入状況（令和7年6月30日版）」

---

関連記事

▶ 第1回：自治体GISとAIの融合
▶ 第2回：ArcGIS Onlineと生成AIを連携した人口統計分析の実証
▶ 第3回：生成AIとGISで健康遊具の優先整備地区を抽出してみた
▶第5回：e-Stat APIとGISを結合するときの落とし穴

【自治体GIS×生成AIシリーズ】～高齢者人口データを活用した公園整備の意思決定支援～

本記事は、生成AIとGISを活用した自治体業務の実証シリーズの第3回です。
関連記事

▶ 第1回：自治体GISとAIの融合
▶第2回：ArcGIS Onlineと生成AIを連携した人口統計分析の実証
▶第4回：自治体の人材不足はGIS AIで解決できるのか
▶第5回：e-Stat APIとGISを結合するときの落とし穴

背景

自治体では、

• 高齢化の進展
• 健康寿命の延伸
• 公園施設の老朽化

が課題となっています。

一方で予算は限られており、

どの公園から整備すべきか

を客観的に判断する必要があります。今回は高齢者人口と健康遊具配置から優先整備地区を抽出する実証を行いました。

今回の目的

豊島区を例に、

65歳以上人口
↓
健康遊具
↓
利用圏

を組み合わせ、

健康遊具の優先整備地区を抽出しました。

分析に使用したデータ

e-Stat

• 2020年国勢調査
• 小地域統計
• 年齢（5歳階級、4区分）別人口から町丁目単位の65歳以上人口

---

ArcGIS Online

• 自社ポータルサイト内の豊島区公園施設データ
• 健康遊具
• 公園名称

---

公園データ

自社のArcGIS Onlineに登録済みの豊島区公園施設データを利用しました。

分析対象は、

• 健康遊具
• 公園名
• 町丁目情報

です。

分析の流れ

---

e-Stat
↓
65歳以上人口
↓
ArcGIS Online
↓
健康遊具
↓
生成AI
↓
ランキング
↓
WebMap

実際に入力したプロンプト

今回の分析では、Codex CLIを利用し、3段階に分けて指示を行いました。

①健康遊具不足ランキングの作成

まず、豊島区遊具施設データと、e-Statの町丁目別高齢者人口を利用し、健康遊具不足ランキングを作成しました。

主な指示内容は以下のとおりです。

• ArcGIS Onlineから豊島区遊具施設データを取得
• 健康遊具のみを抽出
• e-Statから町丁目単位の65歳以上人口を取得
• 町丁目名で結合
• 健康遊具数と高齢者人口から不足度を算出
• CSVおよびMarkdownで出力

この段階で、

「高齢者人口に対して健康遊具が不足している町丁目」

を一覧化しました。

①のプロンプトの詳細

ArcGIS MCP、e-Stat統計ダッシュボードAPIを使って、豊島区の町丁目単位で「65歳以上人口に対して健康遊具が不足している町目」をランキング表にしてください。

前提：

• 豊島区の遊具施設データは、私のArcGIS Online組織アカウントにアップロード済みです。
• 遊具施設データには、遊具種別を示すフィールドがあるはずです。
• 健康遊具は、遊具種別フィールドの値から「健康遊具」またはそれに相当する種別を判定してください。
• 豊島区公式サイト内には町丁目単位の65歳以上人口データがないため、豊島区サイトから探すのではなく、e-Stat統計ダッシュボードAPIまたはe-Stat APIから町丁目単位の年齢別人口を取得してください。
• 取得できる最新年を使用してください。
• 町丁目名の表記ゆれがある場合は、正規化して結合してください。
• 町丁目境界データが必要な場合は、ArcGIS OnlineまたはLiving Atlasから利用可能な公的境界データを検索してください。

作業手順：

1. ArcGIS MCPで、私のArcGIS Onlineコンテンツから豊島区の遊具施設データを検索してください。
2. レイヤ構造を確認し、町丁目名フィールド、遊具種別フィールド、公園名フィールドを特定してください。
3. 健康遊具のみを抽出し、町丁目単位で件数を集計してください。
4. e-Stat統計ダッシュボードAPIまたはe-Stat APIから、豊島区の町丁目単位の65歳以上人口を取得してください。
5. 町丁目名をキーに、65歳以上人口と健康遊具数を結合してください。
6. 以下の指標を計算してください。

• 65歳以上人口
• 健康遊具数
• 65歳以上人口1,000人当たり健康遊具数
• 不足度スコア = 65歳以上人口 / max(健康遊具数, 1)

1. 不足度スコアが高い順にランキング表を作成してください。
2. 結果をCSVとMarkdownの両方で出力してください。

出力項目：

• rank
• 町丁目名
• 65歳以上人口
• 健康遊具数
• 65歳以上人口1,000人当たり健康遊具数
• 不足度スコア
• 該当する公園名
• 備考

注意：

• 町丁目単位の65歳以上人口が取得できない場合は、取得できなかった理由を明記し、代替案として国勢調査小地域、町丁・字等別人口、または住民基本台帳人口の利用可否を整理してください。
• 推測で人口値を作らないでください。
• 結果に使ったデータソース、統計年、フィールド名、結合キーを必ず明記してください。

---

② ランキング指標の改善

初回分析では、

不足度スコア

＝ 65歳以上人口 ÷ 健康遊具数

を採用しました。

しかし、

健康遊具0基の町丁目と1基の町丁目の差が十分に表現できなかったため、指標を改善しました。

追加した内容は以下のとおりです。

• 健康遊具なしフラグ
• 改良版不足度スコア
• 優先度区分（A～D）
• 町丁目内の公園一覧

その結果、

「どの公園が整備候補となるのか」

まで把握できるようになりました。

追加した内容は以下のとおりです。

• 健康遊具なしフラグ
• 改良版不足度スコア
• 優先度区分（A～D）
• 町丁目内の公園一覧

②のプロンプトの詳細

ランキング指標を修正してください。

現在の不足度スコア = 65歳以上人口 / max(健康遊具数, 1) では、
健康遊具0基と1基の差が小さくなっています。

以下の指標を追加してください。

1. 健康遊具なしフラグ
   health_equipment_zero = 1 if 健康遊具数 == 0 else 0
2. 不足度スコア改良版
   shortage_score_v2 =
   65歳以上人口 * 2.0 if 健康遊具数 == 0
   65歳以上人口 / 健康遊具数 if 健康遊具数 >= 1
3. 優先度区分
   A: 65歳以上人口1000人以上 かつ 健康遊具数0
   B: 65歳以上人口1000人以上 かつ 健康遊具数1以下
   C: 65歳以上人口700人以上 かつ 健康遊具数0
   D: その他
4. 町丁目内の公園名一覧
   健康遊具がない場合でも、その町丁目内に存在する公園名を別列に出してください。
   列名は all_park_names としてください。

CSVとMarkdownを再出力してください。

健康遊具不足ランキング結果例

順位	町丁目	65歳以上人口	健康遊具数	優先度
1	東池袋五丁目	1,106	0	A
2	池袋二丁目	1,025	0	A
3	長崎四丁目	987	0	C
4	要町三丁目	956	0	C
5	上池袋三丁目	951	0	C

実際の出力

---

③ WebMapの作成

最後に、ランキング結果を地図化しました。

主な処理内容は以下のとおりです。

• 町丁目ポリゴン取得
• shortage_score_v2との結合
• 優先度A～Dによる色分け
• ポップアップ設定

表示項目は、

• 町丁目名
• 65歳以上人口
• 健康遊具数
• 不足度スコア
• 候補公園一覧

としました。

これにより、

ランキング表だけでは分かりにくい地域的な偏在状況を視覚的に把握できるようになりました。

プロンプト③の詳細

豊島区健康遊具不足ランキングを地図化してください。

現在作成済みのCSVを利用し、

① 町丁目ポリゴンを取得
② shortage_score_v2 を結合
③ A～Dを色分け

A：赤
B：橙
C：黄
D：灰

でWebMapを作成してください。

ポップアップには

・町丁目名
・65歳以上人口
・健康遊具数
・不足度スコア
・候補公園一覧

を表示してください。

③の結果：健康遊具不足ランキング

---

③利用圏を考慮した分析

そこで次に、

健康遊具から250mの利用圏を作成しました。

分析手順は以下のとおりです。

健康遊具ポイント
↓
250mバッファ作成
↓
町丁目ポリゴン
↓
65歳以上人口との重ね合わせ
↓
利用圏内人口割合算出

さらに、

優先度

＝ 65歳以上人口 ×（1 − 利用圏内人口割合）

として再評価しました。

プロンプト④の詳細

豊島区の健康遊具ポイントを使い、250m徒歩利用圏を作成してください。

町丁目ポリゴンごとに、

・65歳以上人口
・健康遊具数
・健康遊具250m圏内人口割合

を算出してください。

新しい優先度を以下で算出してください。

優先度 =
65歳以上人口 × (1 – 利用圏内人口割合)

結果をWebMapとして作成してください。

④の結果：健康遊具250m利用圏分析

---

分析の結果、

健康遊具数だけでは優先度が高く見えた町丁目でも、

近隣公園の利用圏に含まれている場合は優先度が下がることが確認できました。

例えば、

上池袋一丁目

• 65歳以上人口：809人
• 健康遊具数：1基
• 250m圏内人口割合：97.79%

であり、

健康遊具数だけを見ると不足しているように見えますが、

実際にはほぼ全域が健康遊具の利用圏に含まれていました。

一方、

健康遊具利用圏のカバー率が低い町丁目では、

優先的な整備候補として抽出されました。

---

AIによる分析時間

今回の分析では、

• e-Statからの人口取得
• ArcGIS Onlineからの遊具データ取得
• 健康遊具抽出
• 250m利用圏作成
• 人口との空間結合
• 優先順位計算
• Webマップ作成

までを実施しました。

延べ処理時間は約25分でした。

従来であれば、

• 統計データ探索
• CSV加工
• GIS取り込み
• バッファ作成
• 空間集計
• 主題図作成

を手作業で行う必要があり、半日程度を要する作業です。

また、今回の25分の多くはAIとGISが処理を実行している時間であり、職員が画面の前で操作し続ける時間ではありません。

その間に、

• メール対応
• 提案書作成
• 打ち合わせ準備

など他の業務を進めることができます。

---

自治体にとっての価値

今回の分析は、

単に地図を作ることが目的ではありません。

本質は、

「限られた予算をどこへ優先的に投入するか」

を客観的に判断できることです。

例えば、

• 健康遊具
• 遊具更新
• 樹木管理
• 公園施設更新

などの分野に応用できます。

経験や勘だけでなく、

人口構成や利用圏を踏まえた説明可能な意思決定を支援できる点が大きな価値です。

---

おわりに

今回の実証では、

生成AI
×
e-Stat
×
ArcGIS Online

を組み合わせることで、

高齢者人口と健康遊具配置をもとにした優先整備地区の抽出が可能であることを確認しました。

これは単なるGIS分析の自動化ではなく、

統計データと空間情報を活用した政策判断支援の第一歩と考えています。

今後は、他市で進めている公園DXの取り組みにおいても、

• 遊具
• 樹木
• 公園施設

を対象に、

人口構成や利用圏を考慮した維持管理・更新計画への活用を検討していきます。

補足：なぜ「推測で人口値を作らない」と指示したのか

今回の実証では、生成AIに対して

「推測で人口値を作らないでください」（①のプロンプト注意）

という指示を明示的に与えています。

一見すると当たり前のように見えますが、これは自治体業務で生成AIを活用する上で非常に重要な意味を持っています。

1. ハルシネーション（AIの誤生成）を防ぐため

生成AIは、回答に必要な情報が不足している場合でも、もっともらしい内容を生成してしまうことがあります。

例えば人口統計が取得できなかった場合、

「この規模の自治体なら人口は約○万人だろう」

と推測値を作成してしまう可能性があります。

しかし、行政業務では推測値と実データは明確に区別しなければなりません。

そのため本実証では、

「データが取得できない場合は推測せず、その旨を報告する」

というルールを設定しました。

2. 行政で最も求められるのは正確性だから

総務省の調査でも、自治体が生成AI活用において懸念している項目として、

「AI生成物の正確性」

が上位に挙げられています。

今回の実証では、AI自身に数値を考えさせるのではなく、

・e-Stat API
・自治体公開データ
・ArcGIS Online

などの実データを利用し、そのデータをもとに処理を行っています。

つまり生成AIは「答えを作る」のではなく、

「正しいデータを取得し、整理し、分析する」

役割を担っています。

3. 説明責任を確保するため

自治体業務では、

「なぜその結果になったのか」

を説明できることが重要です。

そのため本実証では、

・利用したデータソース
・統計年次
・対象項目
・分析条件

を確認できる状態で処理を行っています。

結果だけではなく、根拠まで追跡できることが行政利用の前提になります。

4. EBPMの品質を維持するため

今回の健康遊具の優先整備地区の抽出では、

250m利用圏人口や高齢化率などの客観的な指標を利用しています。

もし元となる人口値が推測値であれば、分析結果そのものの信頼性が失われます。

限られた予算の中で整備優先順位を判断するためには、

「正しいデータに基づいて分析すること」

が不可欠です。

まとめ

生成AIは非常に強力なツールですが、自治体業務では「それらしい回答」よりも「正しい回答」が求められます。

今回の実証で設定した

「推測で人口値を作らない」

というルールは、生成AIを行政実務で活用するための重要なガードレールです。

今後は、生成AIに判断を任せるのではなく、

・公的データを取得する
・分析を実行する
・結果を説明可能な形で提示する

という役割で活用することで、説明可能で信頼性の高い自治体DXにつながると考えています。

■ 関連記事

▶ 第1回：自治体GISとAIの融合
▶ 第2回：ArcGIS Onlineと生成AIを連携した人口統計分析の実証
▶ 第3回：生成AIとGISで健康遊具の優先整備地区を抽出してみた
▶第4回：自治体の人材不足はGIS AIで解決できるのか
▶第5回：e-Stat APIとGISを結合するときの落とし穴

【自治体GIS×生成AIシリーズ】

本記事は、生成AIとGISを活用した自治体業務の実証シリーズの第２回です。
関連記事

▶ 第1回：自治体GISとAIの融合
▶第3回：生成AIとGISで健康遊具の優先整備地区を抽出してみた
▶第4回：自治体の人材不足はGIS AIで解決できるのか
▶第5回：e-Stat APIとGISを結合するときの落とし穴

自治体では人口統計や地域分析を行う際、
統計データ収集やGIS登録に多くの時間を要します。

具体的な作業

従来は複数のWebサイトやシステムを操作して実施していた作業です。

• 統計データを探す
• CSVをダウンロードする
• GISへ取り込む
• 地図を作成する
• 分析する

そこで今回、

生成AIエージェント（Codex CLI）とArcGIS Onlineを連携し、

・公開情報の調査
・統計データ取得
・GIS登録
・可視化

までを自然言語で実行できるか検証しました。

実際に入力した指示（プロンプト）

プロンプト①

大阪府和泉市の人口推移と高齢化率を取得してください

---

プロンプト②

人口と高齢化率をCSVで出力してください

---

プロンプト③

ArcGIS Onlineへアップロードして
全国市区町村境界と自治体コードでJoinしてください

---

プロンプト④

2020年の高齢化率を色分けしたWebMapを作成してください

AIが自動で行った処理

今回、生成AIは次の処理を自動で実行しました。

自治体名検索
↓
自治体コード取得
↓
e-Stat API接続
↓
人口データ取得
↓
高齢化率計算
↓
CSV作成
↓
ArcGIS Online登録
↓
市区町村境界とのJoin
↓
WebMap作成

従来であれば複数のツールや専門知識が必要だった作業です。

今回得られた結果

今回の検証では、

自治体	人口	高齢化率
和泉市	181,770人	25.85%
豊島区	296,062人	19.77%
岡崎市	378,698人	23.68%
大阪市	2,654,227人	25.50%

を自動取得し、下図のとおりGIS上へ可視化できました。

GISと生成AIの組み合わせが有効な理由

生成AI単体では位置情報を扱うことは得意ではありません。

一方GISは、

• 位置
• 面積
• 距離
• 圏域
• 重ね合わせ

を扱うことに優れています。

今回の検証により、

自然言語
↓
生成AIエージェント
├ Playwright MCP
├ e-Stat API
└ ArcGIS MCP
↓
GIS

を組み合わせることで、

自然言語から空間分析へつなげられる可能性が見えてきました。

具体的な処理内容

Step1

e-Stat統計ダッシュボードAPIから人口データ取得

対象自治体

• 豊島区
• 和泉市
• 岡崎市
• 大阪市

Step2

高齢化率を自動計算

取得した年齢3区分人口から

65歳以上人口
÷
総人口
×100

で高齢化率を算出

---

Step3

ArcGIS Onlineへ自動登録

生成AIがCSVを作成し、

ArcGIS Onlineへアップロード

---

Step4

全国市区町村境界と自動Join

自治体コード（JCODE）を利用し、

境界データと統計データを結合

今回見えてきた可能性

今回の検証では、

単に地図を作るだけではなく、

生成AIが

• 統計データを検索
• APIを利用
• GISへ登録
• 地図化

まで行うことを確認しました。

---

【比較】実行時間の劇的な短縮

今回実施した作業を、従来の手作業と比較してみます。

作業内容	従来	AI活用
e-Statで統計表を探す	20～30分	2分
人口データ取得	20分	2分
高齢化率計算	10分	1分
CSV整形	20分	1分
ArcGIS Online登録	15分	3分
自治体境界とのJoin	20分	3分
WebMap作成	30分	8分
合計	約2～3時間	約20分

今回の検証では、生成AIが統計データの取得からGISへの登録、地図作成までを一連の流れとして実行しました。

従来であればGIS担当者や統計担当者が複数のツールを使い分け2～3時間程度を要します。一方、今回の検証では、自然言語による指示からWebマップ完成まで約20分で実行できました。

ただし、この20分は職員が作業し続ける時間ではありません。

生成AIが統計データ取得、CSV作成、GIS登録、Join、Webマップ作成を順次実行している時間であり、その間、職員は他の業務を進めることができます。

つまり、単純な作業時間短縮だけでなく、「職員が手を離せる時間」が生まれる点に大きな効果があります。

今後、対象データや分析パターンが増えるほど、この効果はさらに大きくなると考えられます。

今回の検証で確認できたこと

今回の実証では、単に人口統計を取得してGISへ登録しただけではありません。

生成AI（Codex CLI）が複数のMCPサーバーやAPIと連携し、

・自治体ホームページの調査
・統計データの取得
・GISデータの更新
・地図化と可視化

までを自然言語から実行できることを確認しました。

これは、従来職員が複数のシステムを操作して行っていた業務を、AIエージェントが支援する新しい業務スタイルの可能性を示しています。

■ 業界動向

2026年にはアジア航測やインフォマティクスも
生成AIとGISを連携した取り組みを発表しています。

今回の検証は、
こうした流れを自治体業務へ適用できるかを
確認するための実証でもあります。

まとめと今後の展望

今回の検証では、生成AIが統計データの取得からGISへの登録、地図作成までを一連の流れとして実行できることを確認しました。

重要なのは単なる作業時間短縮ではなく、職員がデータ収集や加工に費やしていた時間を、分析や政策立案に振り向けられる可能性が見えてきたことです。

今後は、

・高齢者施設の分布分析
・公園施設配置の検討
・防災情報の可視化
・インフラ管理業務

などへの応用も期待されます。

地域GIS研究所では、GIS・統計分析・AIを組み合わせた自治体業務への活用について、引き続き検証と研究を進めていきます。

補足：ハルシネーションを防ぐために実際に行ったプロンプト設計

生成AIを自治体業務へ適用する際、最も重要になるのが「ハルシネーション（もっともらしい誤情報）」への対策です。

総務省の調査でも、自治体が生成AI導入において懸念している課題として「AI生成物の正確性」が上位に挙げられています。

今回の実証では、生成AIに自由に回答させるのではなく、行政実務に耐えられるよう複数の制約条件を与えました。

① 推測による数値生成を禁止する

まず最も重要な指示が、

「推測で人口値を作らないでください」

というルールです。

統計値が取得できない場合にAIが推測値を生成してしまうと、その後の分析結果すべてが誤ったものになります。

そのため、本実証では取得できない場合は推測せず、取得できなかった理由を報告するよう指示しています。

② 根拠となるデータを必ず明示する

分析結果だけを出力させるのではなく、

・データソース
・統計年次
・使用フィールド
・結合キー

を明記するよう指示しています。

これにより、人間が後から検証できる状態を維持しています。

自治体業務では結果だけではなく、「なぜその結果になったのか」を説明できることが重要です。

③ 利用するデータソースを限定する

生成AIは学習データから回答を作成できますが、行政利用では公的統計を利用する必要があります。

そのため、

「e-Stat APIから取得すること」

「自治体公開データを利用すること」

など、利用するデータソースを明示的に指定しています。

これにより、不明確なWeb情報や古い情報を参照するリスクを抑えています。

④ データ欠損時の対応を事前に定義する

統計データが取得できないケースも存在します。

その場合、

「取得できなかった理由を明記する」

「代替可能な統計を整理する」

という対応を行うよう指示しています。

AIに推測をさせるのではなく、人間が判断できる材料を提示させることを重視しています。

⑤ 既存GISデータの構造を確認させる

ArcGIS Onlineを利用する場合、

「レイヤを確認する」
「フィールド構造を確認する」
「既存データを検索する」

という手順を先に実施しています。

これにより存在しないフィールド名や誤った属性を前提とした処理を防止できます。

MCPによる透明性の確保

今回の実証では、生成AIだけに処理を任せているわけではありません。

Codex CLIから、

・Playwright MCP
・e-Stat API
・ArcGIS MCP

を利用し、必要なデータ取得や更新処理を実施しています。

さらに、MCP Inspectorを利用することで、AIがどのデータを参照し、どの条件で検索したのかを確認できます。

従来のジオプロセシング履歴と同様に、処理内容を追跡できることも重要な特徴です。

補足のまとめ

生成AIを自治体業務で活用するためには、AIに自由な回答を求めるのではなく、

・推測を禁止する
・根拠を明示する
・データソースを限定する
・検証可能な状態を維持する

といったルール設計が不可欠です。

今回の実証では、生成AIを「回答生成ツール」ではなく、「公的データを扱う業務支援ツール」として利用することで、説明可能で再現性のある分析が可能であることを確認できました。

関連記事

▶ 第1回：自治体GISとAIの融合
▶ 第3回：生成AIとGISで健康遊具の優先整備地区を抽出してみた
▶第4回：自治体の人材不足はGIS AIで解決できるのか
▶第5回：e-Stat APIとGISを結合するときの落とし穴

【自治体GIS×生成AIシリーズ】～自然言語でGISデータを活用する時代へ～

本記事は、生成AIとGISを活用した自治体業務の実証シリーズの第1回です。
関連記事

▶第2回：ArcGIS Onlineと生成AIを連携した人口統計分析の実証
▶第3回：生成AIとGISで健康遊具の優先整備地区を抽出してみた
▶第4回：自治体の人材不足はGIS AIで解決できるのか
▶第5回：e-Stat APIとGISを結合するときの落とし穴

はじめに

自治体では近年、GIS（地理情報システム）の活用が進み、多くの業務で位置情報を活用したデータ整備が行われています。

しかし実際には、

• GISデータは整備されている
• WebGISも導入されている
• ダッシュボードも構築されている

にもかかわらず、

「GIS担当者しか使えない」

という課題を抱える自治体は少なくありません。

GISは本来、位置・空間・時間・属性を統合して分析できる強力な仕組みです。

しかし、その活用には専門知識やGISソフトウェアの操作スキルが必要でした。

今回、地域GIS研究所では ArcGIS Online と AI を連携し、自然言語によってGISデータを検索・分析・更新する検証を実施しました。

対象は和泉市で整備を進めている「遊具マップPOC」です。

検証の結果、従来はGIS担当者が実施していたデータ整備や分析業務を、自然言語によって実行できることを確認しました。

---

今回の検証環境

今回構築した仕組みは以下のとおりです。

職員
↓
自然言語
↓
AI（Codex）
↓
MCP Server
↓
ArcGIS Online
↓
WebMap・FeatureLayer

MCP（Model Context Protocol）は、AIと外部システムを接続する仕組みです。

これによりAIは、

• ArcGIS Onlineの検索
• レイヤ構造の確認
• 属性更新
• 空間分析

を実行できるようになります。

---

従来のGIS業務フロー

遊具不足公園の抽出

例えば、

「人口が多いのに遊具が少ない公園を抽出する」

という分析を行う場合、

従来は以下の作業が必要でした。

遊具レイヤ準備
↓
遊具数集計
↓
町丁目人口データ取得
↓
空間結合
↓
フィールド計算
↓
集計
↓
Excel出力
↓
職員確認
↓
ランキング作成

GIS担当者が ArcGIS Pro を操作しながら実施する典型的な業務です。

---

人口・世帯情報の付与

公園ポリゴンへ人口・世帯を付与する場合は、

公園ポリゴン
↓
町名ポリゴン
↓
Spatial Join
↓
フィールド追加
↓
フィールド計算
↓
目視確認
↓
エラー修正
↓
更新

が必要でした。

表記ゆれや空間誤差がある場合は、職員が個別に確認する必要があります。

---

市民問い合わせ対応

例えば、

「孫に逆上がりを教えたいので、近くに鉄棒のある公園はありますか？」

という問い合わせがあった場合、

遊具マップ（関連記事）の使用環境がある職員は

遊具マップ起動
↓
鉄棒を検索
↓
対象公園確認
↓
位置確認
↓
電話回答

という対応が可能です。

従来の紙台帳やExcel管理と比較すると、大幅な効率化が図られています。

しかし、この場合でも職員は、

逆上がり
↓
鉄棒

という関係を頭の中で判断する必要があります。

また、

高鉄棒
低鉄棒
健康鉄棒

などの違いも理解した上で検索しなければなりません。

---

AIとGISによる検証結果

① 公園遊具の検索

AIに対して、

「青葉台1号公園の遊具を調べて」

と入力すると、

• 遊具数
• 遊具種別
• 関連町丁目
• 人口
• 世帯数

を自動で集計して回答しました。

---

② 人口・世帯の自動補完

AIへ

「和泉市_都市公園レイヤに人口と世帯のフィールドを追加して、和泉市_町名レイヤから転記して」

と指示しました。

結果は、

• 対象公園数：342件
• 空間照合成功：341件
• 表記ゆれ補完：1件
• 未転記：0件

でした。

さらに、

府中町７丁目
↓
府中町七丁目

という表記ゆれも自動で判定し補完しました。

---

③ 公園ポリゴンへの人口付与

次に、

izumi_parkP ポリゴンレイヤに対して、

人口・世帯を付与する作業を実施しました。

結果は、

• 対象：343件
• 更新成功：343件
• 未転記：0件
• 複数町名にまたがる公園：79件

でした。

複数の町丁目にまたがる公園については、

AIが

公園ポリゴン
↓
町名ポリゴン
↓
重なり面積計算
↓
最大面積の町名を採用

という判断を行いました。

これは従来であれば、ArcGIS Proの空間解析によって実施していた処理です。

---

④ 遊具不足公園の抽出

さらに、

「人口が多いのに遊具が少ない公園を抽出して」

という自然文から、

人口・世帯・遊具数・遊具種別を統合し、

遊具整備優先度ランキングを作成しました。

これは単なる検索ではなく、政策判断支援に近い分析です。

---

市民の問い合わせにAIを活用した場合

AIに対して、

「孫に逆上がりを教えたい」

と入力すると、

AIは質問の意図を理解し、

孫
↓
幼児・小学校低学年

逆上がり
↓
低鉄棒

と解釈します。

さらに、

• 鉄棒の有無
• 公園の位置
• 利用しやすさ

などを考慮しながら候補公園を抽出できます。

つまり、

遊具の種類を検索する

のではなく、

市民がやりたいこと

から適切な公園を探せるようになります。

また、

「3歳の子どもを遊ばせたい」

という問い合わせに対しても、

• 幼児用すべり台
• スプリング遊具
• 砂場

などを持つ公園を抽出できます。

これは遊具マップを市民自身が利用するだけでなく、

職員による問い合わせ対応支援としても活用できます。

---

GISとAIの組み合わせが生み出す価値

GISは、

どこに何があるか

を管理する仕組みです。

一方でAIは、

何をしたいのか

を理解できます。

この二つを組み合わせることで、

位置情報
↓
施設情報
↓
利用目的

を結び付けた新しい行政サービスが可能になります。

---

MCP Inspectorによる説明責任

自治体業務では説明責任が重要です。

今回の検証では MCP Inspector を活用し、

• どのツールを実行したか
• どのデータを参照したか
• どのような更新を行ったか

を確認しました。

AIが処理を実行しても、

その内容を追跡・検証できるため、

自治体業務に求められる透明性を確保できます。

---

GISとAIが変える自治体業務

GISデータは、

• 位置
• 空間
• 時間
• 属性

を持っています。

AIは自然言語を理解します。

この二つを組み合わせることで、

これまでGIS担当者だけが実施していた業務を、

より多くの職員が活用できる可能性があります。

---

今後の可能性

今回の検証は遊具管理を対象としましたが、

同じ考え方は、

• 樹木管理
• 公園施設管理
• 街路灯管理
• 防災施設管理
• 道路台帳管理
• 人流分析

などにも応用できます。

将来的には、

「人口が多いのに遊具が少ない地域は？」

「D判定の樹木が多い公園は？」

「高齢化が進む地域で健康遊具が不足している公園は？」

といった問いに対し、

位置・空間・時間・属性を持つGISデータを生成AIが理解し、

職員が自然文で問い合わせるだけで分析結果を得られる時代が到来すると考えています。

GISは専門職だけのツールから、組織全体の意思決定を支援する基盤へと進化していくでしょう。

---

まとめ

今回の検証では、

GISデータ作成
↓
データ整備
↓
問い合わせ対応
↓
政策判断

までを自然言語で支援できる可能性を確認しました。

これは単なるAIチャットではありません。

位置・空間・時間・属性を持つGISデータを、誰もが自然文で活用できる世界への第一歩です。

地域GIS研究所では、今後も自治体業務における AI × GIS の可能性を検証し、その成果を発信していきます。

業界動向と今回の検証

2026年5月には、アジア航測株式会社が生成AIエージェントを活用した行政向けGIS支援基盤「ALANDIS+GeAI（仮称）」を発表しました。

また、2026年6月には、株式会社インフォマティクスが提供する防災GISサービス「GC Navi」において、生成AIによるチャット機能の提供を開始しています。

このように、GISと生成AIを連携させる取り組みは、行政分野における新たな潮流となりつつあります。

今回の検証では、ArcGIS Onlineと生成AIを連携し、

・GISデータの検索
・属性情報の更新
・空間分析の実行
・問い合わせ対応支援
・政策判断支援

までを自然言語で実行できる可能性を確認しました。

GISは、位置・空間・時間・属性を持つ自治体の重要なデータ基盤です。

これまでGISは専門職が利用するシステムとして発展してきましたが、生成AIとの連携により、今後は職員が自然な文章でGISを活用できる環境へ発展していくことが期待されます。

地域GIS研究所では、GIS・統計・AIを組み合わせた自治体業務への活用について、引き続き検証と研究を進めています。

MCP Inspectorによる説明責任

自治体業務では、

• なぜその結果になったのか
• どのデータを使ったのか
• どのような処理を行ったのか

を説明できることが重要です。

今回の検証では、MCP Inspectorを利用してAIが実行したGIS処理を確認しました。

例えば、

AIへ

「人口が多いのに遊具が少ない公園を抽出して」

と指示した場合、AIは単に文章を生成しているわけではありません。

実際にはArcGIS Online上のGISデータに対して検索処理を実行しています。

---

AIが実際に実行した処理

今回の例では、AIは以下の処理を行いました。

① 施設名レイヤ（Equipment_POC）を参照

② 人口1000人以上のレコードを抽出
   （JINKO >= 1000）

③ 人口順に並べ替え
   （JINKO DESC）

④ 公園名・遊具名・人口・世帯を取得

⑤ 結果を集計して回答

---

MCP Inspectorで確認した実行内容

実際にAIが実行した検索条件

使用ツール
query_layer_with_fields

検索レイヤ
Equipment_POC

検索条件
JINKO >= 1000

並び順
JINKO DESC

取得項目
公園名
遊具名
人口
世帯
町丁目

下図　MCP Inspectorによる実行内容確認例

（PCスクリーンショット）

①入力内容

②出力内容

---

AIはブラックボックスではない

今回の検証では、

AIが

人口1000人以上の遊具を抽出しました

と回答しただけではありません。

その裏側で、

• どのレイヤを使ったのか
• どの条件で検索したのか
• どの結果を取得したのか

まで確認できました。

つまり、

AIの回答
↓
実際のGIS処理

を追跡できます。

---

ArcGIS Proとの関係

従来のGIS業務では、

空間結合
フィールド演算
統計集計

などの処理内容を、

ArcGIS Proの「ジオプロセシング履歴」で確認していました。

MCP Inspectorは、

AIが実行したGIS処理について、

どのツールを使ったか
どのデータを参照したか
どのような結果を返したか

を確認できるため、

AI時代の「ジオプロセシング履歴」や「監査ログ」に近い役割を果たします。

関連記事

▶第2回：ArcGIS Onlineと生成AIを連携した人口統計分析の実証
▶第3回：生成AIとGISで健康遊具の優先整備地区を抽出してみた
▶第4回：自治体の人材不足はGIS AIで解決できるのか
▶第5回：e-Stat APIとGISを結合するときの落とし穴