投稿者: admin

  • PLATEAU LOD1と生成AIで建物単位人口推計は可能か

    ~和泉市を対象とした政策支援モデル構築の試行錯誤~

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

    関連記事

    ▶ 第1回:自治体GISとAIの融合
    ▶第2回:ArcGIS Onlineと生成AIを連携した人口統計分析の実証
    ▶第3回:生成AIとGISで健康遊具の優先整備地区を抽出してみた
    ▶第4回:自治体の人材不足はGIS AIで解決できるのか
    ▶第5回:e-Stat APIとGISを結合するときの落とし穴
    ▶第6回:PLATEAU MCPは自治体GISを変えるのか
    ▶第7回:健康遊具はどこに整備すべきか?生成AIとGISで検証
    ▶第8回:AIの回答は信用できるのか(検証と説明責任)
    ▶第9回:自治体GISにおける人口統計データの構造要件を生成AIで検証する
    ▶第11回:PLATEAU建物人口から見る浸水リスク
    ▶第12回:建物単位人口で見る避難所シミュレーション
    ▶第13回:PLATEAUの建物に人口を配置する
    ▶第14回:PLATEAUを「人口を持つ都市」へ

    はじめに

    国土交通省が推進するPLATEAUは、3D都市モデルとして急速に整備が進んでいます。

    しかし、多くの活用事例は3D表示や景観シミュレーションに留まっており、行政実務に直結する政策支援への活用事例はまだ多くありません。

    そこで今回、

    「PLATEAUのLOD1建物データと公開統計だけを用いて、建物単位の人口を推計できないか」

    という仮説を立て、和泉市を対象に検証を行いました。

    さらに、本検証ではArcGISと生成AIエージェントを組み合わせ、モデル構築プロセスの自動化にも挑戦しました。

    その結果、PLATEAU LOD1建物データと公開統計のみを用いても、人口総量保存率100%を維持しながら、建物単位人口推計モデルを構築できることを確認しました。

    また、LOD1であっても、防災や福祉などの政策立案に活用可能な政策支援モデルを構築できる可能性が示されました。

    一方、その過程では多くの失敗や試行錯誤もありました。

    今回は、その過程も含めて紹介します。


    最初の仮説

    当初の考え方は単純でした。

    1. 国勢調査メッシュ人口を細かなHEXグリッドへ変換する
    2. HEXごとの人口をPLATEAU建物へ配分する
    3. 建物単位人口を推計する

    当初は、より細かな空間表現ができると考え、HEX52(約52m)を採用しました。

    解析イメージは次のとおりです。

    図1:250m人口メッシュ→HEX52→PLATEAU建物

    図2:250m人口メッシュ→HEX52→PLATEAU建物のレイヤ重ね


    最初の失敗 ~HEX52は細かすぎた~

    解析を進めたところ、予想外の問題が発生しました。

    HEX52へ人口を再配置すると、

    建物の存在しないHEXにも人口が割り振られてしまったのです。

    その結果、

    • 建物が存在しないHEXが大量に発生
    • 人口を建物へ配分できない
    • 市全体で約9,000人の人口が取りこぼされる

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

    当初は、

    「建物単位に落とすなら細かいグリッドほど精度が高い」

    と考えていました。

    しかし、実際には逆でした。

    細かすぎるグリッドは、人口を不要に拡散させてしまうことが分かりました。


    改善① ~HEX250への変更~

    そこで、HEX52を廃止し、250m人口メッシュに近いスケールを持つHEX250へ変更しました。

    結果は大きく改善しました。

    • 人口取りこぼし率:約5% → 約0.75%
    • 人口総量保存:ほぼ100%

    細かなグリッドが必ずしも高精度とは限らない。

    これは今回得られた最初の重要な知見でした。

    図3:HEXグリッドサイズの変更による建物の網羅性


    改善② ~面積だけでは人口が偏る~

    次に問題となったのが、建物への人口配分方法です。

    当初は、

    建物交差面積 × 推定階数
    

    を重みとして使用しました。

    しかし、この方法では大規模建物に人口が過剰に集中してしまいました。

    例えば、

    • 小規模住宅:0.2人
    • 大規模建物:200人超

    といった極端な分布が多数発生しました。

    明らかに実態を反映していません。


    改善③ ~対数変換の採用~

    そこで、重みを次のように変更しました。

    WEIGHT =
    log(1 + INTERSECT_AREA)
    × EST_FLOORS_ADJ

    建物面積をそのまま使用するのではなく、交差面積に対数変換を適用しました。

    その結果、小規模住宅にも人口が配分されやすくなり、大規模建物への過度な集中は抑制されました。また、人口0建物や極端な低人口建物の発生も減少し、建物人口分布は一定程度改善しました。

    一方で、対数変換は大きな建物が本来持つ居住容量の差も圧縮します。そのため、大規模集合住宅では人口を過小推計する可能性があることも確認されました。

    この結果から、単純面積比例モデルと対数重みモデルのどちらか一方を採用するのではなく、建物規模や推定階数に応じてモデルを切り替えるハイブリッド型の人口配分モデルが有効であると考えられます。

    図4:面積重みモデルと対数モデルの比較)の比較


    項目面積モデル対数モデル
    最大建物人口546人260人
    中央値1.31人1.69人
    低人口建物数10,179棟7,442棟

    この結果から、

    対数モデルでは、低人口建物が10,179棟から7,442棟へと2,737棟減少(約27%減)した。

    ※総戸数292戸の大規模集合住宅では
    面積モデルの方が実態に近かった

    改善④ ~用途地域別の推定階数~

    さらに、PLATEAUが持つ建物高さ情報(measuredHeight)を利用し、用途地域ごとに標準階高を設定しました。

    例えば、

    • 低層住居系:3.0m
    • 商業地域:4.0m
    • 工業地域:4.5m

    とし、

    推定階数 = 建物高さ ÷ 標準階高

    により建物ごとの推定階数を算出しました。

    LOD1モデルでは建物内部の住戸数や階数情報は保持されていません。しかし、高さ情報と用途地域特性を組み合わせることで、戸建住宅と中高層建築物を区別できるようになり、人口配分モデルに建物規模の違いを反映することが可能となりました。

    その結果、単純な建築面積だけでは表現できない建物の居住容量を考慮した人口配分が実現できました。


    改善⑤ ~AIによるハイブリッド型人口配分モデルの可能性~

    今回、面積重みモデルと対数重みモデルを比較した結果、それぞれに長所と短所が存在することが明らかとなりました。

    例えば、和泉市内の大規模集合住宅「コート和泉府中カリヨン(総戸数292戸)」では、単純面積比例モデルによる推計人口は546人、対数重みモデルでは201人となりました。

    実際の総戸数から推定される居住人口は約600~700人程度と考えられるため、このケースでは面積比例モデルの方が現実に近い結果を示しました。

    一方、戸建住宅や小規模建物では、対数重みモデルを適用することで、極端な低人口建物が大幅に減少することも確認できました。

    このことから、今後は建物規模に応じて人口配分モデルを切り替える「ハイブリッド型人口配分モデル」が有効と考えられます。

    例えば、

    • 推定階数が高い建物
    • 延床面積が大きい建物
    • 集合住宅と推定される建物

    については面積比例モデルを適用し、

    • 一般戸建住宅
    • 小規模共同住宅

    については対数重みモデルを適用する方法が考えられます。

    さらに、こうした建物分類自体をAIが自動的に判定することも可能です。

    AIは、

    • 建物面積
    • 建物高さ
    • 推定階数
    • 用途地域
    • 建物形状
    • 周辺建物との関係

    などの属性をもとに、

    「大規模集合住宅」
    「戸建住宅」
    「商業施設」
    「工場・倉庫」

    といった建物種別を推定し、最適な人口配分モデルを自動的に選択できます。

    将来的には、

    「建物をAIが分類し、建物特性に応じて最適な人口配分モデルを自動適用する」

    という、AIエージェントによる次世代型建物人口推計モデルの実現も期待できます。

    実建物による推計結果の検証

    モデルの妥当性を確認するため、推計人口が最大となった建物を確認しました。

    その結果、推計人口最大の建物は、和泉市内の大規模集合住宅「コート和泉府中カリヨン」であることが分かりました。

    図5:推計人口最大建物「コート和泉府中カリヨン」

    写真:Googleストリートビューより

    このマンションは総戸数292戸の大規模分譲マンションであり、一般的な世帯人数から推定すると、実際の居住人口は600~700人程度と考えられます。

    一方、モデルによる推計結果は次のとおりでした。

    モデル推計人口
    単純面積比例モデル546人
    対数重みモデル201人

    この結果から、大規模集合住宅では対数モデルが過小推計となる可能性があり、面積比例モデルの方が実態に近いことが確認されました。

    ルールベースAI判定が現実的

    例えば、AIエージェントに対し、建物面積、推定階数、用途地域、面積比例モデルによる推計人口を判定材料として与えることで、一定規模以上の集合住宅には面積比例モデルを適用し、それ以外の一般住宅には対数重みモデルを適用するハイブリッド型人口配分が可能になります。

    具体的には、推定階数が8階以上かつ建物面積が800㎡以上の建物、または面積比例モデルによる推計人口が250人を超える建物を「大規模集合住宅候補」と判定し、面積比例モデルを適用する。一方、一般的な戸建住宅や小規模共同住宅には対数重みモデルを適用します。

    このように、AIエージェントが建物属性と周辺条件をもとにモデル選択を自動化することで、単一モデルでは表現しきれない建物特性を反映した人口配分が可能となります。

    検証結果

    最終モデルでは、

    • 対象建物数:75,936棟
    • 人口総量保存:100%
    • 建物人口中央値:1.68人
    • 人口100人超建物:35棟

    という結果となりました。

    人口総量保存監査

    人口配分モデルでは、空間分布が変化しても、元となる人口総量が保存されていることが重要です。

    今回のモデルでは、250m人口メッシュからHEX52、さらに建物単位へ人口を配分する各段階において人口総量監査を実施しました。

    その結果、

    • 配分前人口総数:184,263.85人
    • 配分後建物人口総数:182,790.08人
    • 建物未交差HEX人口(除外人口):1,473.78人

    となり、

    建物人口総数 + 除外人口 = 184,263.85人

    となることを確認しました。

    差分は0人(保存率100%)であり、本モデルにおいて人口総量が完全に保存されていることを確認しました。

    人口総量保存(Mass Preservation)

    は最も重要な監査項目です。

    監査表

    項目人口
    250mメッシュ人口総数184,263.85人
    HEX52人口総数184,263.85人
    建物人口総数182,790.08人
    除外人口1,473.78人
    建物人口+除外人口184,263.85人
    差分0人
    保存率100.0%

    また、住宅・土地統計調査による住宅戸数とも近い値を示し、モデルとして一定の妥当性を確認することができました。


    空き家対策への応用可能性

    さらに、

    建物人口 < 1
    かつ
    推定階数 ≧ 1
    かつ
    建物面積 ≧ 50㎡

    という条件で抽出を行ったところ、

    7,442棟の建物が抽出されました。

    もちろん、これらをそのまま空き家と判定することはできません。

    しかし、建物人口が極めて少ないにもかかわらず、一定規模以上の建物については、空き家または低利用建物である可能性が考えられます。

    今後、

    • 住民基本台帳
    • 固定資産税台帳
    • 水道利用情報
    • 空き家実態調査結果

    などの行政データと連携することで、現地調査対象を大幅に絞り込める可能性があります。

    本手法は、空き家を直接判定するものではなく、

    現地確認を優先的に実施すべき候補建物を抽出する一次スクリーニング手法

    として位置付けられます。

    特に、自治体が保有する既存データと組み合わせることで、従来は全件調査が必要であった空き家対策業務の効率化につながることが期待されます。


    建物単位人口推計が可能にする新たな政策立案

    建物単位で人口を推計できるようになると、従来の町丁目単位やメッシュ単位では困難であった詳細な政策シミュレーションが可能となります。

    例えば、浸水想定区域内に存在する建物を対象に、

    • 建物人口
    • 高齢者人口
    • 推定階数

    を重ね合わせることで、

    「浸水区域内の1階建て住宅に居住する高齢者人口」

    を推計することができます。

    これにより、

    防災分野

    • 要支援者の優先避難対象地域の抽出
    • 個別避難計画策定支援
    • 垂直避難が困難な住宅の把握
    • 浸水深別避難対象人口の推計

    避難所運営

    • 指定避難所ごとの想定避難者数推計
    • 避難所受入可能人数との比較
    • 避難所配置の見直し
    • 避難所不足地域の抽出

    福祉分野

    • 高齢者見守り重点地区の抽出
    • 在宅避難困難者の推計
    • 地域包括ケア計画への活用

    など、建物単位での施策検討が可能となります。

    特に、避難所については、

    「どの避難所に何人が避難するか」

    を建物単位でシミュレーションできるため、避難所受入体制の再構築や、避難所不足地域の抽出など、より現実的な地域防災計画の策定が期待できます。

    図6:PLATEAU LOD1を使った防災シュミレーション 

    本モデルの限界

    本モデルは、PLATEAU LOD1建物データと公開統計のみを用いて建物単位人口を推計する試行モデルであり、いくつかの制約が存在します。

    • 住民基本台帳による建物単位での実測検証は実施していない。
    • 建物用途の推定には用途地域や建物形状を利用しており、実際の利用状況と異なる場合がある。
    • LOD1では建物内部構造や住戸数を表現できないため、大規模集合住宅では推計誤差が生じる可能性がある。
    • 年齢階層別人口は公開統計を建物単位へ按分した推計値であり、実際の居住者属性を直接表現するものではない。

    一方、本研究では人口総量保存監査や実建物との比較を通じて、政策検討に利用可能なレベルの推計精度を確認した。

    今後は、住民基本台帳、固定資産税台帳、住宅・土地統計調査などの行政データと連携し、モデル精度のさらなる向上を目指したい。

    おわりに

    今回の検証を通じて、

    PLATEAUは3D表示のためだけのデータではない

    ことを改めて実感しました。

    LOD1の建物データと高さ情報だけでも、公開統計と組み合わせることで、建物単位人口推計という政策支援モデルを構築できることが確認できました。

    一方で、このようなモデルを構築するには、単純なGIS処理だけでは不十分です。

    グリッド品質の検証、人口総量保存監査、人口配分モデルの比較、実建物との照合など、多数の空間解析と試行錯誤が必要となります。

    今回の検証では、生成AIエージェントを活用することで、こうした試行錯誤の大部分を自動化し、短時間で複数のモデルを構築・比較できる可能性も確認できました。
    具体的には、

    • PLATEAU建物と用途地域の重複判定
    • 建物ごとの代表用途地域の決定
    • 用途地域別標準階高の付与
    • 建物推定階数の自動算出
    • HEXグリッドの品質監査と隙間検出
    • Voronoi分割によるHEXグリッド再構築
    • 人口総量保存監査
    • 面積重みモデルおよび対数重みモデルの自動構築
    • モデル間の差分分析
    • 極端値建物の抽出と実建物との照合
    • 解析結果の監査レポート作成

    などを、自然言語による指示のみで繰り返し実行することができました。

    特に、モデル構築後に問題点を発見し、重み式を変更して再計算を行い、その結果を自動的に比較・監査する一連の試行錯誤を短時間で繰り返せたことは大きな成果でした。

    従来であれば、多数のジオプロセシングツール、Pythonスクリプト、品質確認作業を組み合わせながら数日から数週間を要する解析であっても、生成AIエージェントを活用することで、仮説立案から検証までのサイクルを大幅に高速化できる可能性が確認できました。

    また、面積重みモデルと対数重みモデルを比較した結果、それぞれに長所と短所が存在することが明らかとなりました。今後は、建物規模や用途に応じてモデルを切り替えるハイブリッド型人口配分モデルの検討も進めていきたいと考えています。

    従来の町丁目単位・メッシュ単位の分析では困難であった建物単位の政策立案が可能となります。

    今後は、

    • 高齢者避難支援
    • 空き家対策
    • 公共施設配置評価
    • 都市計画・地域分析

    など、自治体業務へのさらなる応用可能性を検証していきたいと考えています。

    次回予告

    今回構築した建物単位人口データは、単なる人口推計に留まりません。

    次回は、このデータと洪水浸水想定区域を組み合わせ、

    「浸水区域内の低層住宅に居住する人口」

    を建物単位で推計してみたいと思います。

    特に、

    • 浸水区域内の1階建て住宅人口
    • 浸水区域内の高齢者人口
    • 垂直避難が困難な可能性のある建物
    • 避難所ごとの想定避難者数

    などを可視化することで、建物単位人口推計が防災分野にどのように活用できるのかを検証する予定です。

    従来の町丁目単位や250mメッシュ単位では困難であった、

    「どの建物に、どのような支援が必要なのか」

    という視点から、避難支援や避難所配置のあり方を考えていきます。
    図7:次回イメージ図

    関連記事

    ▶ 第1回:自治体GISとAIの融合
    ▶第2回:ArcGIS Onlineと生成AIを連携した人口統計分析の実証
    ▶第3回:生成AIとGISで健康遊具の優先整備地区を抽出してみた
    ▶第4回:自治体の人材不足はGIS AIで解決できるのか
    ▶第5回:e-Stat APIとGISを結合するときの落とし穴
    ▶第6回:PLATEAU MCPは自治体GISを変えるのか
    ▶第7回:健康遊具はどこに整備すべきか?生成AIとGISで検証
    ▶第8回:AIの回答は信用できるのか(検証と説明責任)
    ▶第9回:自治体GISにおける人口統計データの構造要件を生成AIで検証する
    ▶第11回:PLATEAU建物人口から見る浸水リスク
    ▶第12回:建物単位人口で見る避難所シミュレーション
    ▶第13回:PLATEAUの建物に人口を配置する
    ▶第14回:PLATEAUを「人口を持つ都市」へ

  • 自治体GISにおける人口統計データの構造要件を生成AIで検証する

    ~250mメッシュ・HEX・用途地域を用いた健康遊具配置分析の検証~

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

    関連記事

    ▶ 第1回:自治体GISとAIの融合
    ▶第2回:ArcGIS Onlineと生成AIを連携した人口統計分析の実証
    ▶第3回:生成AIとGISで健康遊具の優先整備地区を抽出してみた
    ▶第4回:自治体の人材不足はGIS AIで解決できるのか
    ▶第5回:e-Stat APIとGISを結合するときの落とし穴
    ▶第6回:PLATEAU MCPは自治体GISを変えるのか
    ▶第7回:健康遊具はどこに整備すべきか?生成AIとGISで検証
    ▶第8回:AIの回答は信用できるのか(検証と説明責任)
    ▶第10回:PLATEAU LOD1と生成AIで建物単位人口推計は可能か
    ▶第11回:PLATEAU建物人口から見る浸水リスク
    ▶第12回:建物単位人口で見る避難所シミュレーション
    ▶第13回:PLATEAUの建物に人口を配置する
    ▶第14回:PLATEAUを「人口を持つ都市」へ

    はじめに

    前回の記事では、生成AIとGISを活用した健康遊具配置分析について、その分析過程と説明責任の重要性を検証しました。

    その結果、

    ・人口集計方法の確認
    ・分析手順の再現
    ・MCPによる検証
    ・カバー率の再計算

    を通じて、AIの回答そのものではなく、分析過程を確認することの重要性が見えてきました。

    しかし、新たな疑問も生まれました。

    今回利用した人口データは町丁目単位です。

    GIS分析では一般的な方法ですが、

    本当に人口は町丁目内に均等に存在しているのでしょうか。

    例えば、

    ・河川
    ・池
    ・工業地域
    ・大規模公園

    など、人が居住していない場所も存在します。


    人口モデルを見直す

    第7回では町丁目人口を利用して健康遊具の最適配置を行いました。

    一方で、施設配置のような政策シミュレーションでは、

    人口統計そのものよりも、人口をどこに配置するかという人口モデルの違いが結果を左右する

    ことがあります。

    そこで今回は、町丁目人口を出発点としながら、用途地域を用いて人口分布を補正するモデルを構築し、公園選定結果がどのように変化するかを検証しました。

    HEXグリッドによる人口分布の表現

    用途地域による人口補正を行うことで、町丁目内の人口分布はより現実に近づきます。

    しかし、もう一つ課題があります。

    それは、

    行政界に引きずられる人口分布です。

    町丁目人口は行政統計として整理された単位であるため、どうしても町丁目境界の影響を受けます。

    実際の生活圏は町丁目境界で区切られているわけではありません。

    公園利用、買い物、通学、散歩など、人の行動は行政界を意識せずに連続しています。

    そのため、施設配置を検討する場合には、行政界に依存しない分析単位が望まれます。


    なぜHEXグリッドなのか

    そこで採用したのがHEX(六角形)グリッドです。

    六角形は正方形メッシュと比較して、隣接方向の偏りが少なく、空間分析で広く利用されています。

    特にサービス圏分析や需要分布の可視化では、

    • 境界効果が小さい
    • 隣接関係が均一
    • 滑らかな分布を表現しやすい

    という特徴があります。

    今回の検証では、人口をHEX単位に再配置することで、

    行政界ではなく生活圏に近い形で需要分布を表現することを目指しました。

    なお、生成AIによって作成したHEXグリッド成果物については、ArcGIS Pro上で再監査を実施しました。

    監査の結果、一部縮尺においてグリッドが欠落して見える現象が確認されましたが、レコード数および人口総量は元データと完全に一致していることを確認しています。

    拡大表示ではすべてのHEXが正常に表示されることから、この現象はGeoJSON描画時の表示上の問題であり、人口分析結果そのものには影響しないと判断しました。

    生成AIによる空間分析では、成果物をGIS上で監査するプロセスが不可欠であることも今回の重要な知見となりました。


    人口総量は変えない

    ここで重要なのは、

    人口を移動させても人口総量は変えない

    という点です。

    今回の検証では、

    町丁目人口や250mメッシュ人口を出発点としながら、

    用途地域による重み付けを行い、

    その後HEXへ再配分しています。

    しかし、

    和泉市全体の人口は常に一致するよう管理しています。

    つまり、

    人口を増減させるのではなく、

    人口が存在する可能性の高い場所へ再配置している

    だけです。

    この考え方は、将来的に避難所配置、防犯カメラ配置、街路灯整備など、他の施設配置分析にも応用できます。

    なぜ250mメッシュ人口を使うのか

    用途地域補正やHEXグリッドによって人口分布をより現実に近づけることができます。

    しかし、その出発点となる人口統計自体にも精度の違いがあります。

    これまで利用してきた町丁目人口は、自治体業務でも広く活用されている信頼性の高い統計です。

    一方で、町丁目は行政上の区画であり、人口分布を表現するために設計された単位ではありません。

    そのため、町丁目の面積が大きい場合や、住宅地と非住宅地が混在する場合には、人口分布を詳細に表現することが難しくなります。


    国勢調査メッシュという考え方

    そこで利用したのが国勢調査の250mメッシュです。

    250mメッシュは全国を250m四方の格子で区切り、それぞれのメッシュ単位で人口を集計した統計データです。

    行政界とは無関係なため、

    • 市町村界
    • 町丁目界
    • 用途地域界

    の影響を受けません。

    純粋に「その場所にどれだけ人口が存在するか」を表現できる点が大きな特徴です。


    なぜ250mなのか

    今回利用した250mメッシュは、

    全国的に整備されている人口統計の中でも比較的高い空間解像度を持っています。

    例えば、和泉市全域では約650メッシュが利用対象となりました。

    ここで重要なのは、

    650メッシュで和泉市全域を覆っているわけではない

    という点です。

    国勢調査メッシュは人口が存在する地域を対象とした統計であり、山林や河川など人口が存在しない地域は統計上の対象外となります。

    そのため、

    今回利用した650メッシュは

    「和泉市の人口分布を表現するためのメッシュ」

    であり、

    「和泉市の面積全体を表現するためのメッシュ」

    ではありません。


    メッシュ人口でも課題は残る

    一見すると、

    「250mメッシュ人口を使えば十分ではないか」

    とも考えられます。

    しかし、250mメッシュにも課題があります。

    例えば一つのメッシュの中に、

    • 住宅地
    • 商業施設
    • 工場
    • 公園

    が混在している場合、その人口はメッシュ内に均一に配置されます。

    つまり、

    町丁目より細かくなっただけで、

    依然として

    「どこに人が住んでいるのか」

    という問題は残ります。

    そこで今回の検証では、

    250mメッシュ人口に対しても用途地域による補正を行い、

    さらにHEXグリッドへ再配置することで、

    人口分布の精度向上を試みました。


    今回の検証で確認したかったこと

    今回の目的は、

    単にメッシュ人口を利用することではありません。

    本当に知りたかったのは、

    人口モデルの精度向上が政策判断にどの程度影響するのか

    という点です。

    そこで、

    • 町丁目人口
    • 町丁目人口+用途地域補正
    • 町丁目人口+用途地域補正+HEX
    • 250mメッシュ人口+用途地域補正+HEX

    という4つの人口モデルを作成し、

    健康遊具の最適配置結果がどのように変化するかを比較しました。

    町丁目人口と250mメッシュ人口は完全には一致しない

    ここで一つ補足しておきます。

    今回利用した250mメッシュ人口は、町丁目人口と完全に一致するわけではありません。

    監査の結果、65歳以上人口は

    • 町丁目人口:46,995人
    • 250mメッシュ人口:47,305.739人

    となり、約311人(0.66%)の差が確認されました。

    250mメッシュは行政界とは無関係に配置された格子データであるため、町丁目境界や用途地域境界をまたぐメッシュが多数存在します。

    今回の分析では、これらのメッシュ人口を交差面積に応じて按分しているため、境界付近では人口の再配分が発生します。

    それにもかかわらず差分は0.66%に留まりました。

    これは、

    • 使用した250mメッシュの人口分布が町丁目人口と概ね整合していること
    • 面積按分処理による誤差が限定的であること
    • 用途地域分析に利用する統計基盤として十分な精度を有していること

    を示しています。

    一般的に空間統計では、集計単位を変更すると数%程度の差が生じることも珍しくありません。

    今回の0.66%という差分は、分析結果に実質的な影響を与えない水準であり、250mメッシュ人口を用いた用途地域別人口推計の妥当性を裏付ける結果となりました。


    差分の原因

    当初は市境界処理や人口集計ミスの可能性も考えられました。

    しかし検証の結果、

    • 市境界データの不整合なし
    • 人口総量の集計ミスなし
    • 境界メッシュ按分処理は適正

    であることを確認しています。

    残った差分は、

    国勢調査メッシュ統計特有の

    秘匿処理や統計的な再集約処理

    によるものと判断しました。


    分析への影響

    差分率は0.66%に留まっており、用途地域別人口推計や施設配置検討の結果を左右する水準ではありません。

    そのため本検証では、250mメッシュ人口を十分に利用可能な統計基盤と判断し、以降の分析を進めています。

    今回比較した4つの人口モデル

    今回の検証では、人口モデルを段階的に高度化しながら、公園選定結果への影響を比較しました。

    Case A 町丁目人口

    最も一般的な方法です。

    町丁目人口をそのまま利用し、町丁目内に均等分布していると仮定します。

    町丁目人口

    サービス圏分析

    公園選定

    Case B 町丁目人口+用途地域補正

    町丁目人口を用途地域ごとに再配分します。

    町丁目内の人口分布を、土地利用に応じて補正します。

    町丁目人口

    用途地域補正

    サービス圏分析

    公園選定

    Case C 町丁目人口+用途地域補正+HEX

    用途地域で補正した人口をHEXグリッドへ再配置します。

    行政界の影響を小さくし、生活圏に近い人口分布を表現します。

    町丁目人口

    用途地域補正

    HEX

    サービス圏分析

    公園選定

    Case D 250mメッシュ人口+用途地域補正+HEX

    国勢調査250mメッシュを利用し、さらに用途地域補正とHEX再配置を行います。

    今回の検証で最も高精度な人口モデルです。

    250mメッシュ人口

    用途地域補正

    HEX

    サービス圏分析

    公園選定

    用途地域による人口補正の考え方

    用途地域を利用した人口補正と聞くと、

    「用途地域ごとの人口割合で按分したのではないか」

    と思われるかもしれません。

    しかし今回採用した方法は、それとは異なります。

    重要なのは、

    用途地域別人口比率ではなく、用途地域別人口密度を利用している

    という点です。


    人口比率を使うと何が問題か

    例えば和泉市全体で、用途地域別人口が次のようになっていたとします。

    用途地域人口
    住居系22,769人
    商業系916人
    工業系6,948人

    この場合、

    人口比率は次のようになります。

    用途地域人口比率
    住居系74.3%
    商業系3.0%
    工業系22.7%

    一見すると合理的に見えます。

    しかし、この方法には大きな問題があります。

    人口だけを見ているため、

    用途地域の面積を考慮していない

    のです。


    面積を考慮すると見え方が変わる

    実際には用途地域ごとに面積が異なります。

    今回の和泉市の集計結果は次のようになりました。

    用途地域人口面積
    住居系22,768.820,746,538㎡
    商業系915.5880,003㎡
    工業系6,948.48,172,350㎡

    ここから人口密度を計算します。

    人口密度 = 人口 ÷ 面積

    用途地域人口密度
    住居系0.001097
    商業系0.001040
    工業系0.000850

    すると見えてくるものが変わります。

    用途地域別に人口を見ると、工業系用途地域にも約6,948人が居住していることが分かります。
    ただし、面積を考慮して人口密度で比較すると、工業系用途地域は住居系用途地域より低く、住居系を1.0とした場合の相対値は0.775となります。


    人口密度から相対重みを求める

    そこで今回は、

    住居系の人口密度を基準値1.0としました。

    計算式は次の通りです。

    用途地域重み
    =
    用途地域人口密度
    ÷
    住居系人口密度

    和泉市の場合、

    用途地域自動算出重み
    住居系1.000
    商業系0.948
    工業系0.775
    非居住系0.251

    となりました。

    これは、

    住居系と比較して、

    • 商業系は94.8%
    • 工業系は77.5%
    • 非居住系は25.1%

    の人口密度を持つことを意味します。

    図5 用途地域別人口密度の比較

    住居系用途地域を基準とした場合、商業系用途地域は約95%、工業系用途地域は約78%の人口密度となった。工業系用途地域にも一定の人口が居住しているものの、住居系用途地域ほど高密度ではないことが分かる。

    図6 用途地域別居住人口の比較

    工業系用途地域には約6,948人が居住しており、住宅系用途地域に次ぐ人口規模となっている。用途地域図だけでは把握しにくい居住実態を定量的に確認することができる。

    図7 和泉市工業系用途地域における高齢者人口分布

    工業系用途地域内には約5,500人(推計)の高齢者が居住している。工場や事業所が立地するイメージの強い地域であるが、実際には高齢者が生活する区域も多く含まれていることが分かる。

    特にエリアNo.11では約1,800人の高齢者が居住しており、工業系用途地域であっても福祉、防災、移動支援等の施策を検討する際には重要な対象区域となる。


    なぜ固定係数を使わなかったのか

    当初は、

    用途地域固定重み
    住居系1.0
    商業系0.6
    工業系0.2

    という単純な係数を想定していました。

    しかし今回の実測結果は、

    用途地域自動重み
    住居系1.000
    商業系0.948
    工業系0.775

    でした。

    特に工業系は、

    想定していた0.2ではなく0.775となっています。

    これは、

    和泉市の工業系地域が純粋な工場地帯ではなく、

    住宅や生活施設を含む地域として機能していることを示しています。※実際の用途区分は準工業地域です。


    なぜ自治体ごとに計算する必要があるのか

    もし全国一律で

    住居系 = 1.0
    商業系 = 0.6
    工業系 = 0.2

    を適用すると、

    和泉市では実態よりも工業地域の人口を大幅に過小評価してしまいます。

    逆に都市部では商業地域の人口密度が住居系を上回る可能性もあります。

    つまり、

    同じ用途地域であっても、

    自治体によって人口構造は異なります。

    そのため、

    用途地域補正を行う場合は、

    固定係数を適用するのではなく、

    自治体ごとの人口密度から重みを算出する必要があります。

    今回の検証では、

    人口比率ではなく人口密度を利用することで、

    和泉市の実態を反映した人口モデルを構築することができました。


    4つの人口モデルによる政策判断の比較

    ここまで構築した4つの人口モデルを用いて、健康遊具を追加設置する公園を比較しました。

    比較条件は統一し、

    • 既存健康遊具500m圏
    • 候補公園248箇所
    • 追加設置数3箇所
    • 500mサービス圏
    • Greedy法による最適選定

    を共通条件としています。


    Case A 町丁目人口

    最も一般的な分析方法です。

    町丁目人口をそのまま利用し、町丁目内に均一に人口が分布しているものとして評価しました。

    指標結果
    追加後カバー率42.35%
    改善幅+9.00pt

    選定公園

    1. 鶴山台西公園(159)
    2. 和気6号公園(332)
    3. みたち山2号公園(275)

    Case B 町丁目人口+用途地域補正

    町丁目人口を用途地域別人口密度で補正し、町丁目内の人口分布を再構築しました。

    指標結果
    追加後カバー率45.84%
    改善幅+11.45pt

    選定公園

    1. 鶴山台志保池公園(156)
    2. 中央公園(149)
    3. 和気7号公園(333)

    Case Aとの比較

    項目変化
    追加後カバー率+3.50pt
    改善幅+2.46pt
    選定公園3公園すべて変更

    ここで初めて政策判断が変化しました。

    同じ町丁目人口を使用していても、用途地域を考慮することで優先される公園が入れ替わったことになります。


    Case C 町丁目人口+用途地域補正+HEX

    用途地域で補正した人口をHEXグリッドへ再配置しました。

    指標結果
    追加後カバー率43.71%
    改善幅+11.10pt

    選定公園

    1. 鶴山台志保池公園(156)
    2. 中央公園(149)
    3. 和気7号公園(333)

    Case Bとの比較

    項目変化
    選定公園変化なし
    カバー率微差

    HEX化により人口分布はより滑らかになりましたが、政策判断を変えるほどの差は生じませんでした。


    Case D 250mメッシュ人口+用途地域補正+HEX

    最も高精度な人口モデルです。

    国勢調査250mメッシュ人口を利用し、用途地域補正とHEX再配置を行いました。

    指標結果
    追加後カバー率44.29%
    改善幅+11.51pt

    選定公園

    1. 鶴山台志保池公園(156)
    2. 中央公園(149)
    3. 和気7号公園(333)

    Case Cとの比較

    項目変化
    追加後カバー率+0.58pt
    改善幅+0.40pt
    新規カバー人口+224人
    選定公園変化なし

    250mメッシュを利用することで人口分布の精度は向上しましたが、選定公園は変化しませんでした。


    検証結果から見えたこと

    今回の4段階比較で最も重要な結果は、

    政策判断を変えたのは用途地域補正であり、HEX化や250mメッシュ化ではなかった

    という点です。

    整理すると、

    比較結果
    Case A → B公園選定が変化
    Case B → C公園選定は変化なし
    Case C → D公園選定は変化なし

    つまり、

    単純な町丁目人口モデルから一歩進み、

    用途地域によって人口分布を補正するだけで、政策判断そのものが変わりました。

    一方で、その後のHEX化や250mメッシュ化は分析精度を向上させたものの、今回の和泉市では最終的な意思決定を変えるほどの影響は確認されませんでした。

    この結果は、

    「より細かいデータを使うこと」よりも、

    「人口をどのように空間配置するか」という人口モデルの設計が重要である

    ことを示しています。

    今回の検証から見えたこと

    今回の検証では、

    • 町丁目人口
    • 町丁目人口+用途地域補正
    • 町丁目人口+用途地域補正+HEX
    • 250mメッシュ人口+用途地域補正+HEX

    という4つの人口モデルを比較しました。

    結果として、

    用途地域補正によって政策判断そのものが変化し、

    一方でHEX化や250mメッシュ化は分析精度を向上させるものの、今回の和泉市では最終的な公園選定結果を変えるには至りませんでした。

    これは自治体GISの観点から見ても非常に興味深い結果です。

    ※ HEX成果物については、ArcGIS Pro上で再監査を実施し、人口総量が保持されていることを確認しています。


    生成AIで見えた可能性

    今回、私が最も驚いたのは分析結果そのものではありません。

    この検証過程です。

    通常であれば、

    • 人口統計の収集
    • 用途地域データの整理
    • 人口再配分モデルの作成
    • HEXグリッド生成
    • サービス圏解析
    • カバー率比較
    • 公園選定結果の比較
    • 監査

    を繰り返し実施する必要があります。

    しかも今回は4種類の人口モデルを比較しています。

    従来のGIS業務であれば、相当な工数を要する検証です。


    生成AIとの対話が分析を深めた

    一方、今回は生成AIとの対話を通じて分析を進めました。

    もちろん途中では、

    • レイヤ指定ミス
    • データ参照ミス
    • 推測による誤った処理

    も発生しました。

    しかし、その都度監査を行い、

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

    を確認しながら分析を進めることで、

    最終的には

    用途地域補正が政策判断を変えていた

    という重要な知見に到達しました。

    これは最初から想定していた結論ではありません。

    分析を進める過程で初めて見えてきた結果です。


    生成AIは答えを出すだけではない

    生成AIというと、

    「質問すると答えを返してくれるツール」

    というイメージがあります。

    しかし今回の検証で感じたのは、

    生成AIの価値は答えそのものではなく、

    仮説を作り、検証し、監査しながら知見を深めていくプロセス

    にあるということです。

    実際、

    用途地域補正の必要性

    用途地域別人口密度による重み付け

    HEXの効果

    250mメッシュの効果

    といった論点は、対話を重ねながら徐々に整理されていきました。

    今回の検証では、生成AIが作成したHEX成果物をArcGIS Pro上で監査した結果、一部成果物に不整合が見つかりました。

    しかし、人口総量やレコード数を検証した結果、分析結果そのものには影響しないことを確認しています。

    このことは、生成AIによる空間分析では、AIの結論だけではなく、成果物そのものをGIS上で検証するプロセスが不可欠であることを示しています。

    生成AIとGISを組み合わせた分析では、

    AIによる計算

    成果物出力

    GISによる監査

    再評価

    というプロセスそのものが重要になります。

    HEXグリッドの「真の価値」の再定義

    今回の分析では、町丁目単位で集計した場合とHEXグリッドで集計した場合で、最終的な優先順位に大きな差は見られませんでした。

    そのため、

    「HEXグリッドを使わなくても同じ結果ではないか」

    と思われるかもしれません。

    しかし、HEXグリッドの本当の価値は、今回の順位付け結果そのものではありません。

    HEXグリッドは、行政界に依存しない均一な単位で人口や施設を評価できるため、実際の住民行動に近い分布を表現できます。

    例えば住民は、

    • 公園を利用する
    • スーパーへ買い物に行く
    • 学校へ通学する
    • 散歩をする
    • 医療機関を利用する

    といった行動を行う際に、町丁目や自治会の境界を意識して移動しているわけではありません。

    実際には、行政界をまたいで最寄りの施設を利用しています。

    町丁目単位の分析では、境界付近の人口がどちらの町丁目に属するかによって結果が左右されることがあります。

    一方、HEXグリッドでは均一な空間単位で分析するため、

    「人がどこに住み、どの方向へ移動しやすいのか」

    という実際の生活圏に近い分布を把握できます。


    将来的な活用可能性

    今回の公園分析では結果に大きな差は生じませんでしたが、HEXグリッドの考え方は次のような分析で真価を発揮します。

    • 公園利用圏の分析
    • 買い物弱者対策
    • 通学路安全対策
    • 医療施設の配置検討
    • 高齢者の移動支援
    • 災害時避難行動の分析

    これらはすべて、行政界ではなく「人の行動範囲」が重要になる分野です。

    その意味で、HEXグリッドは単なる集計単位ではなく、

    「行政界で区切られた地域を見る」のではなく、「住民の生活圏を見る」ための分析手法

    と言えるでしょう。

    第9回の結論

    今回の和泉市検証を通じて、

    生成AIは単なる作業自動化ツールではなく、

    GIS分析における「思考の相棒」として機能する可能性を感じました。

    もちろん結果を鵜呑みにしてはいけません。

    監査も必要です。

    しかし適切なデータ指定と検証手順を与えることで、

    従来であれば多大な時間を要した比較検証を短時間で繰り返し実施できることも確認できました。

    そしてその過程で、

    自治体GISにおける人口モデルの構造要件という、当初想定していなかった知見にまで到達することができました。

    次回予告

    今回の分析では、工業系用途地域にも約5,500人の高齢者が居住していることが分かりました。

    しかし、同じ5,500人でも、その人たちはどのような建物に住んでいるのでしょうか。

    次回は国土交通省PLATEAUの3D都市モデルを活用し、

    • 高齢者は低層住宅と中高層建物のどちらに多く居住しているのか
    • 工業系用途地域の建物高さにはどのような特徴があるのか
    • 洪水リスクや地形条件とどのような関係があるのか

    について検証します。

    人口を「地域」で見るだけでなく、「建物」で捉えることで、これまで見えなかった都市構造の実態に迫ります。

    関連記事

    ▶ 第1回:自治体GISとAIの融合
    ▶第2回:ArcGIS Onlineと生成AIを連携した人口統計分析の実証
    ▶第3回:生成AIとGISで健康遊具の優先整備地区を抽出してみた
    ▶第4回:自治体の人材不足はGIS AIで解決できるのか
    ▶第5回:e-Stat APIとGISを結合するときの落とし穴
    ▶第6回:PLATEAU MCPは自治体GISを変えるのか
    ▶第7回:健康遊具はどこに整備すべきか?生成AIとGISで検証
    ▶第8回:AIの回答は信用できるのか(検証と説明責任)
    ▶第10回:PLATEAU LOD1と生成AIで建物単位人口推計は可能か
    ▶第11回:PLATEAU建物人口から見る浸水リスク
    ▶第12回:建物単位人口で見る避難所シミュレーション
    ▶第13回:PLATEAUの建物に人口を配置する
    ▶第14回:PLATEAUを「人口を持つ都市」へ

  • ~健康遊具分析で見えた説明責任とMCPの役割~


    ~AIの分析結果をどう検証するか~

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

    関連記事

    ▶ 第1回:自治体GISとAIの融合
    ▶第2回:ArcGIS Onlineと生成AIを連携した人口統計分析の実証
    ▶第3回:生成AIとGISで健康遊具の優先整備地区を抽出してみた
    ▶第4回:自治体の人材不足はGIS AIで解決できるのか
    ▶第5回:e-Stat APIとGISを結合するときの落とし穴
    ▶第6回:PLATEAU MCPは自治体GISを変えるのか
    ▶第7回:健康遊具はどこに整備すべきか?生成AIとGISで検証
    ▶第9回:自治体GISにおける人口統計データの構造要件を生成AIで検証する
    ▶第10回:PLATEAU LOD1と生成AIで建物単位人口推計は可能か
    ▶第11回:PLATEAU建物人口から見る浸水リスク
    ▶第12回:建物単位人口で見る避難所シミュレーション
    ▶第13回:PLATEAUの建物に人口を配置する
    ▶第14回:PLATEAUを「人口を持つ都市」へ


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

    はじめに

    前回の記事では、生成AIとGISを活用し、和泉市の健康遊具配置について検証しました。

    既存健康遊具の配置状況を可視化し、サービス圏分析や人口統計との重ね合わせを行うことで、健康遊具の整備候補地を抽出しました。

    また、候補公園の中から3公園を選定し、整備効果を試算しました。

    しかし、その後に分析結果を検証したところ、一つの重要な課題が見つかりました。

    それは、

    「AIの回答そのものだけでなく、分析条件や集計方法も検証しなければならない」

    ということです。

    自治体業務では、

    ・どの公園を選んだのか

    だけではなく、

    ・なぜその公園を選んだのか

    ・その数値はどのように算出したのか

    まで説明できなければなりません。

    今回の記事では、健康遊具分析の検証過程を通じて、生成AI活用における説明責任と検証の重要性について紹介します。


    前回記事の結果を再検証した

    前回の記事では、健康遊具を整備する候補公園を抽出し、3公園へ追加整備した場合の効果を試算しました。

    しかし、その後の検証で、

    カバー率の計算に使用していた人口総数の扱いを再確認する必要があること

    が分かりました。

    GIS分析におけるカバー率は、一般的に次の式で求めます。

    カバー率 = サービス圏内人口 ÷ 対象人口 × 100

    つまり、

    ・サービス圏内人口

    ・対象人口

    の両方が正しく定義されていなければなりません。


    検証側にも課題があった

    当初の検証では、

    65歳以上人口

    42,408人

    を分母として利用していました。

    しかし、監査を行った結果、この42,408人は和泉市全体の65歳以上人口ではありませんでした。

    実際には、

    分析途中で作成された中間レイヤの population_65_plus 属性合計

    であり、

    和泉市全体の人口総数とは異なる値でした。

    改めて確認したところ、

    和泉市_人口レイヤの population_65_plus 全183件の合計は

    46,995人

    でした。

    つまり、

    分析条件そのものを見直す必要があったのです。


    正式な条件で再計算した

    そこで、

    和泉市全体の65歳以上人口46,995人を分母として、

    改めて健康遊具のカバー率を計算しました。

    今回採用した方法は、町丁目人口を面積按分する一般的なGIS分析手法です。

    計算式は次の通りです。

    カバー人口 =

    町丁目人口 ×

    (町丁目とサービス圏の重なり面積)

    ÷

    町丁目面積

    この方法で再計算した結果、

    既存健康遊具500mサービス圏内人口

    15,676人

    カバー率

    33.36%

    となりました。

    さらに、

    前回選定した3公園を追加した場合、

    カバー人口

    21,030人

    カバー率

    44.75%

    となりました。

    追加でカバーできる65歳以上人口は

    約5,354人

    でした。

    重要なのは、

    数値が変わったことではありません。

    その数値がどのような前提で算出されたのかを説明できるようになったことです。


    第1回で確認したこと

    本シリーズ第1回では、

    生成AI

    MCP Server

    ArcGIS Online

    という流れを確認しました。

    実際に返却されるJSONを確認し、

    「AIがどのデータを取得しているのか」

    を検証しました。

    これは、

    「AIが見ているデータは正しいのか」

    を確認した作業です。

    その結果、

    MCP経由で取得されるGISデータの信頼性について一定の確認ができました。


    今回確認したかったこと

    しかし、今回問題になったのはデータ取得ではありません。

    取得したデータを、

    AIがどのように利用し、

    どのような集計を行い、

    どのような数値を算出したのかです。

    つまり、

    「AIは何を見ているのか」

    ではなく、

    「その結果をGISとして再現できるのか」

    を検証する段階に入りました。


    MCPとしてGIS処理を整理した

    そこで今回、

    従来GISで行ってきた分析手順を、

    AIが再利用できる形でMCPとして整理しました。

    対象としたのは、

    ・500mサービス圏作成

    ・サービス空白地域抽出

    ・候補公園抽出

    ・町丁目人口との重なり判定

    ・人口集計

    ・カバー率算出

    です。

    これらはGISでは一般的な処理です。

    しかし、

    AIが出した結果を再現しようとすると、

    どの人口を利用したのか

    どの集計方法を採用したのか

    どの分母を使用したのか

    を明確にする必要があります。

    今回の検証では、

    その分析過程を一つずつGIS処理として再現し、

    分析条件を確認しました。

    その結果、

    AIの回答だけでなく、

    検証側で利用していた人口総数の扱いにも課題があることを発見できました。


    MCP Inspectorによる検証

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

    MCP Inspectorは、MCPサーバに登録されたツールや入力条件、返却結果を確認できる専門職員がAIの処理を「査読(検算)」するためのツールです。

    図  MCP Inspectorによる人口保存確認ツールの検証

    このツールは、人口按分前後で総人口が保持されているかを検証するためのツールです。

    入力として、

    ・元人口レイヤ

    ・按分後人口レイヤ

    ・人口フィールド

    などを受け取り、人口総数の差異を確認します。

    今回の検証では意図的に入力パラメータを指定せず実行したところ、

    source_population_field is required

    というエラーが返されました。

    これは単なるエラーではなく、必要なGISデータが存在しない場合は分析を実行しない設計であることを示しています。

    生成AIは不足する情報を推測して回答する場合があるが、本ツールでは必須データが存在しない場合は処理を中断します。

    この仕組みによって、推測ではなくGISデータに基づく分析が保証され、自治体業務では重要な意味を持ちます。

    生成AIは不足する情報を推測して回答することがありますが、行政実務では推測による分析は認められません。

    今回確認したMCPツール群は、必要なGISデータが存在しない場合は処理を実行せず、分析を中断する設計となっていました。

    つまり、推測ではなくデータに基づいて分析を行う思想で構築されていることが確認できたのです。

    今回の検証は44.75%という数値を再計算することが目的ではありません。

    分析過程を構成するGIS処理が、どのような入力を受け取り、どのような条件で実行されるのかを確認することが目的でした。

    このような仕組みによって、AIの回答だけでなく、その背後にある分析過程も検証できるようになります。

    AIへの制約条件

    今回のMCPによる検証では、AIが自由に推論することを避けるため、プロンプトにも制約条件を設定しました。

    主な内容は次の通りです。

    ・推測で人口値を作らないこと

    ・利用した統計年を明示すること

    ・計算式を省略しないこと

    ・データが存在しない場合は不明とすること

    ・GISデータに基づいて判断すること

    自治体業務では説明責任が求められます。

    特に行政では、

    「なぜこの3公園を選定したのか」

    だけでなく、

    「44.75%という数値はどのように算出したのか」

    まで説明できなければなりません。

    その際、AIが示した結果だけを説明することはできません。

    例えば今回であれば、

    ・対象とした65歳以上人口

    ・500mサービス圏の範囲

    ・人口の按分方法

    ・候補公園ごとの新規カバー人口

    ・カバー率の算出過程

    といった中間データまで含めて説明できる必要があります。

    住民説明会や議会において、

    「なぜこの3公園を優先したのか」

    「なぜ44.75%という結果になったのか」

    と問われた際に、AIの回答をそのまま示すのではなく、計算根拠となる人口集計結果や分析過程を即座に提示できることが重要です。

    そのため今回の検証では、AIに結果だけを求めるのではなく、

    ・推測で人口値を作らないこと

    ・利用した統計年を明示すること

    ・計算根拠を示すこと

    ・不明な場合は不明と回答すること

    といった制約条件を設けました。

    これらの制約条件は、AIの自由な推論を制限するためではなく、分析結果の再現性と説明可能性を確保するために設定したものです。

    生成AIを行政実務で活用するためには、回答の正しさだけでなく、その結果に至る過程を説明できることが不可欠だと考えています。

    総務省調査から見える課題

    総務省の自治体向け調査でも、

    生成AI活用の最大の課題として

    「AI生成物の正確性への懸念」

    が挙げられています。

    今回の検証では、AIの回答だけでなく、分析に使用した人口総数や集計条件についても再確認する必要があることが分かりました。

    これは、生成AI活用において回答だけでなく、計算条件や分析過程を確認することの重要性を示しています。

    一方で、

    適切なプロンプト設計

    データ取得の検証

    分析ロジックの検証

    を組み合わせることで、

    生成AIを自治体業務で利用できる可能性も見えてきました。

    MCP化による再利用と自動化

    ここまで読まれた方の中には、

    「AIの回答を人間がこれほど細かく検証しなければならないのであれば、かえって手間が増えるのではないか」

    と感じる方もいるかもしれません。

    確かに今回の検証では、

    ・対象データの確認

    ・サービス圏の作成

    ・人口集計方法の確認

    ・カバー率計算の検証

    など、多くの作業を行いました。

    しかし、今回の目的は毎回人手で検証することではありません。

    重要なのは、検証によって正しい分析手順を明確にし、その手順をMCPツールとして再利用可能な形に整理することです。

    例えば今回の健康遊具分析では、

    ・500mサービス圏作成

    ・サービス空白地域抽出

    ・候補公園抽出

    ・人口集計

    ・カバー率算出

    という一連のGIS分析手順を整理しました。

    一度この手順がMCPツールとして実装されれば、次回以降は生成AIが同じ手順を自動的に実行できるようになります。

    つまり、

    初回
    → 人間が検証しながら分析手順を構築する

    2回目以降
    → MCPツールを利用して同じ分析を短時間で再現する

    という流れになります。

    これは従来のGIS業務におけるモデル構築と同じ考え方です。

    最初は時間をかけて分析手順を設計しますが、一度手順が確立すれば、その後は繰り返し利用することができます。

    今回の検証によって得られた最大の成果は、44.75%という数値そのものではありません。

    むしろ、分析条件を追跡することで、分母の誤りを発見し、再計算できたことに意味があります。

    誰が実施しても同じ手順で同じ結果を再現できる分析フローを構築できたことです。

    将来的には、職員が

    「健康遊具が不足している地域はどこか」

    と自然言語で質問するだけで、

    MCPツール群が自動的に分析を実行し、

    分析結果だけでなく、その根拠となる計算過程まで提示できるようになると考えています。

    次回に向けて

    今回利用した人口データは町丁目人口です。

    町丁目単位では按分で凌ぎましたが、それでも『河川や池に人は住んでいない』という限界があります。

    それ以外にも

    工業地域

    大規模公園

    など、人が居住していない場所にも人口が配分されている可能性があります。

    そこで次回は、

    ・250mメッシュ人口

    ・用途地域

    ・PLATEAU建築物データ

    を活用し、

    より現実に近い人口分布を表現できるのかを検証します。

    おわりに

    今回の検証を通じて見えてきたのは、生成AI活用の本当の課題は回答を得ることではなく、その根拠を確認できる仕組みを持つことだということです。

    今回の健康遊具分析では、AIの回答を検証する過程で、人口集計方法だけでなく、人口総数の扱いについても見直すことになりました。

    自治体業務では、

    「なぜこの公園を選んだのか」

    だけでなく、

    「どの人口を対象としたのか」

    「どのように計算したのか」

    まで説明できる必要があります。

    住民説明会や議会で説明する際も、AIの回答だけではなく、人口集計結果や分析過程を提示できなければなりません。

    今回の検証は、そのための仕組みづくりの第一歩になりました。

    関連記事

    ▶ 第1回:自治体GISとAIの融合
    ▶第2回:ArcGIS Onlineと生成AIを連携した人口統計分析の実証
    ▶第3回:生成AIとGISで健康遊具の優先整備地区を抽出してみた
    ▶第4回:自治体の人材不足はGIS AIで解決できるのか
    ▶第5回:e-Stat APIとGISを結合するときの落とし穴
    ▶第6回:PLATEAU MCPは自治体GISを変えるのか
    ▶第7回:健康遊具はどこに整備すべきか?生成AIとGISで検証
    ▶第9回:自治体GISにおける人口統計データの構造要件を生成AIで検証する
    ▶第10回:PLATEAU LOD1と生成AIで建物単位人口推計は可能か
    ▶第11回:PLATEAU建物人口から見る浸水リスク
    ▶第12回:建物単位人口で見る避難所シミュレーション
    ▶第13回:PLATEAUの建物に人口を配置する
    ▶第14回:PLATEAUを「人口を持つ都市」へ

  • 健康遊具はどこに整備すべきか?生成AIとGISで検証してみた

    ~和泉市の町丁目人口データを活用した施設配置分析の実践~

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

    関連記事

    ▶ 第1回:自治体GISとAIの融合
    ▶第2回:ArcGIS Onlineと生成AIを連携した人口統計分析の実証
    ▶第3回:生成AIとGISで健康遊具の優先整備地区を抽出してみた
    ▶第4回:自治体の人材不足はGIS AIで解決できるのか
    ▶第5回:e-Stat APIとGISを結合するときの落とし穴
    ▶第6回:PLATEAU MCPは自治体GISを変えるのか
    ▶第8回:AIの回答は信用できるのか(検証と説明責任)
    ▶第9回:自治体GISにおける人口統計データの構造要件を生成AIで検証する
    ▶第10回:PLATEAU LOD1と生成AIで建物単位人口推計は可能か
    ▶第11回:PLATEAU建物人口から見る浸水リスク
    ▶第12回:建物単位人口で見る避難所シミュレーション
    ▶第13回:PLATEAUの建物に人口を配置する
    ▶第14回:PLATEAUを「人口を持つ都市」へ

    はじめに

    前回の記事では、e-Stat APIとArcGIS Onlineを連携し、自治体の人口統計データを生成AIから活用できる環境を構築しました。

    今回は、その仕組みを実際の自治体業務へ応用し、

    「健康遊具はどこへ整備すれば最も効果的なのか」

    というテーマで分析を行いました。

    対象としたのは大阪府和泉市です。

    高齢化の進展に伴い、健康増進を目的とした健康遊具の需要は今後さらに高まることが予想されます。

    和泉市には数百の公園があります。

    その中から、どの公園へ健康遊具を整備すれば
    最も多くの高齢者が利用できるのかを
    職員が一つひとつ検討するのは容易ではありません。

    しかし、

    ・現在どこに健康遊具があるのか

    ・どの地域がサービス圏から外れているのか

    ・新たに整備するならどこが最適なのか

    を客観的に判断することは容易ではありません。

    そこで今回は、
    人口統計と公園データを用いて
    整備効果の高い公園を自動的に抽出できるか
    健康遊具の適正配置分析の検証を行いました。


    分析に使用したデータ

    今回利用した主なデータは以下のとおりです。

    公園データ

    和泉市内の公園位置データ

    健康遊具データ

    既存健康遊具設置公園

    人口データ

    e-Stat APIから取得した町丁目人口データ

    分析環境

    ・ArcGIS Online

    ・ArcGIS MCP Server

    ・Codex CLI

    ・生成AI

    AIへの指示と分析ルール

    今回は生成AIを利用していますが、AIが推測で分析結果を作成しないよう、事前に複数の制約条件を設定しています。

    特に自治体業務では、分析結果の説明責任が求められるため、データの出典や計算根拠を明確にすることを重視しました。

    主な制約条件

    • 人口値を推測で作成しないこと
    • 実在する統計データのみ利用すること
    • 利用した統計年を明示すること
    • 計算式を省略しないこと
    • 分析結果の根拠となるデータを示すこと
    • データが存在しない場合は「不明」と回答すること
    • GISレイヤを直接確認せずに推測で判断しないこと
    • ArcGIS Online上の実データを参照して分析すること

    実際に使用したプロンプトの一部

    分析に使用する人口データは
    令和2年国勢調査を利用すること。

    人口値を推測で補完しないこと。

    統計年を明示すること。

    計算式を省略しないこと。

    データが存在しない場合は
    推測で回答せず、その旨を明記すること。

    分析結果はArcGIS Online上の実データに基づくこと。

    STEP1 現在の健康遊具配置を可視化する

    まずは既存健康遊具の設置状況をマップ上へ表示しました。

    プロンプト

    和泉市の既存健康遊具ポイントを抽出してください。

    対象:
    ・健康遊具のみ

    実施内容:
    ・健康遊具ポイントを表示
    ・公園名を表示
    ・設置箇所数を集計

    成果物:
    AI_STEP1_既存健康遊具

    今回は可視化のみ。
    分析は行わない。

    【図1 既存健康遊具配置図】

    可視化してみると、市域全体に配置されているように見えます。

    しかし、

    「本当に市民全体が利用しやすい配置なのか」

    は、この段階では分かりません。


    STEP2 サービス圏分析を実施

    次に健康遊具から500m圏をサービス圏として設定しました。

    500mは徒歩圏としてよく利用される距離です。

    プロンプト

    既存健康遊具ポイントから
    500mサービス圏を作成してください。

    条件:
    ・重複可
    ・徒歩圏の近似として500mを使用

    成果物:
    AI_STEP2_健康遊具サービス圏

    出力:
    ・サービス圏ポリゴン
    ・カバー人口集計

    【図2 健康遊具サービス圏】

    サービス圏を重ねると、一定範囲はカバーできているものの、市域内にはサービス圏が届いていない地域が存在することが分かりました。


    STEP3 空白地域を抽出

    既存サービス圏を除外し、健康遊具が利用しにくい地域を抽出しました。

    プロンプト

    和泉市行政界から
    健康遊具サービス圏を除外してください。

    目的:
    健康遊具未整備地域の抽出

    成果物:
    AI_STEP3_空白地域

    出力:
    ・空白地域ポリゴン
    ・面積集計

    【図3 健康遊具空白地域】

    ここで空白地域に居住する高齢者人口を集計しました。

    分析の結果、令和2年国勢調査に基づく和泉市の65歳以上人口は46,995人でした。

    既存健康遊具500mサービス圏内人口は15,676人、
    サービス圏外人口は31,319人でした。

    健康遊具カバー率 =

    健康遊具500m圏内の65歳以上人口
    ÷
    市内65歳以上人口
    ×100

    = 15,676 ÷ 46,995 ×100

    = 33.36%

    つまり、市内高齢者の約7割が健康遊具の徒歩圏外に居住していることが分かりました。

    これにより、

    「どこに不足しているか」

    が視覚的に把握できるようになります。

    しかし、

    不足地域が分かっても、

    「どこへ整備すれば最も効果的なのか」

    はまだ分かりません。


    STEP4 人口データと重ね合わせる

    そこで町丁目人口データを重ね合わせました。

    プロンプト

    空白地域と町丁目人口を重ね合わせてください。

    対象:
    ・65歳以上人口

    実施内容:
    ・空白地域内人口を集計
    ・人口密度を算出

    成果物:
    AI_STEP4_空白地域人口

    出力:
    ・人口ランキング
    ・人口分布マップ

    空白地域の中でも人口規模には差があります。

    同じ面積でも、

    人口が多い地域と少ない地域では整備効果が異なります。

    つまり、

    空白地域の広さではなく、

    「どれだけの市民がサービス圏外にいるのか」

    が重要になります。


    STEP5 AIによる候補地抽出

    この約15,800人を対象に、どの公園へ整備すると最も効果的なのかを検証しました。

    ここで生成AIとMCPを活用しました。

    AIは人間のように地図を見るわけではありません。

    MCPを通じてGISデータへアクセスし、

    ・サービス圏

    ・人口データ

    ・公園データ

    を組み合わせて分析します。

    プロンプト

    空白地域内または隣接する公園を抽出してください。

    条件:
    ・健康遊具未設置
    ・空白地域解消効果が期待できる

    評価項目:
    ・周辺高齢者人口
    ・空白地域面積
    ・既存サービス圏との重複

    成果物:
    AI_STEP5_候補公園

    出力:
    候補公園一覧

    その結果、

    空白地域周辺の公園を抽出したところ、
    候補地は248公園となりました。

    しかし、
    すべての公園へ健康遊具を整備することは
    予算面から現実的ではありません。

    【図5 候補公園抽出結果】

    さらに、

    候補公園へ健康遊具を設置した場合のサービス圏も試算しました。

    【図6 候補公園追加後のサービス圏】


    STEP6 最適な3公園を選定

    候補地の中から、最も多くの市民をカバーできる組み合わせをAIが探索しました。

    プロンプト

    空白地域内または隣接する公園を抽出してください。

    条件:
    ・健康遊具未設置
    ・空白地域解消効果が期待できる

    評価項目:
    ・周辺高齢者人口
    ・空白地域面積
    ・既存サービス圏との重複

    成果物:
    AI_STEP5_候補公園

    出力:
    候補公園一覧

    【図7 AI選定結果】

    空白地域周辺の公園を抽出した結果、候補地は248公園となりました。

    しかし、すべての公園へ健康遊具を整備することは現実的ではありません。

    そこで今回の分析では、各公園について500mサービス圏を生成し、

    ・新たにカバーできる65歳以上人口

    ・既存健康遊具サービス圏との重複

    ・他候補地との重複

    を評価しました。

    その結果、248公園の中から、限られた整備数で最も多くの高齢者をカバーできる3公園を選定しました。

    この分析は、従来GISで行われてきたバッファ作成、空白地域抽出、人口集計といったジオプロセシング処理をMCPとして組み合わせて実行したものであり、整備候補地の選定根拠を客観的なデータで説明できる点に特徴があります。

    自治体では、整備要望の多い公園から順番に事業化を検討するケースも少なくありません。しかし、限られた予算の中で整備効果を最大化するためには、「どの公園に設置するか」だけでなく、「何人の市民に効果があるのか」を定量的に把握することが重要です。

    今回の分析では、248公園を同一条件で評価することで、健康遊具整備の優先順位を客観的なデータに基づいて比較できることを確認しました。

    財政効果

    新たに3公園へ健康遊具を整備した場合、

    500m圏内人口は

    15,676人

    21,030人

    へ増加しました。

    カバー率は

    33.36%

    44.75%

    へ改善する結果となりました。

    追加でカバーできる65歳以上人口は約5,354人です。

    改善幅は11.39ポイントとなりました。

    言い換えると、市内のすべての公園へ一律に整備を進めるのではなく、人口分布と既存施設配置を考慮して優先順位を付けることで、少ない整備箇所でも高い事業効果が期待できることが確認できました。


    今回の成果

    今回の検証では、

    ・既存施設の可視化

    ・サービス圏分析

    ・人口統計との重ね合わせ

    ・AIによる候補地選定

    までを一連の流れとして実施できました。

    従来であればGIS担当者が個別に行っていた分析を、生成AIとMCPを活用することで大幅に効率化できる可能性が見えてきました。


    新たな課題も見えてきた

    ここで一つの疑問が生まれました。

    今回利用した人口データは町丁目単位です。

    GIS分析では一般的な方法ですが、

    本当に人口は町丁目内に均等に存在しているのでしょうか。

    例えば、

    ・河川

    ・池

    ・大規模公園

    ・工業地域

    など、人が住んでいない場所も存在します。

    しかし町丁目人口を利用すると、それらの場所にも人口が存在するものとして扱われる場合があります。

    今回の分析では、町丁目人口をサービス圏との重なり面積に応じて按分し、人口を集計しています。

    そのため、従来の単純集計よりも実態に近い分析は可能になりますが、それでも町丁目内の人口分布を完全に再現しているわけではありません。

    つまり、

    分析結果は有効な指標として活用できる一方で、

    人口の分布モデルそのものには改善の余地がある可能性があります。

    ※実際に使用したプロンプトの中に、「推測で人口値を作らないこと」や「計算根拠となる統計年を明示すること」などの制約を含めています。


    次回予告

    今回の分析では、健康遊具の配置候補やカバー率向上効果を確認することができました。

    しかし、その後の検証により、分析結果を評価する際には、

    ・どの人口を対象としたのか

    ・どの集計方法を使用したのか

    ・どのような分析手順で算出したのか

    を確認することの重要性が見えてきました。

    自治体業務では、結果だけでなく、

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

    を説明することが求められます。

    次回は、

    生成AIが導き出した分析結果をどのように検証するのか

    という視点から、

    MCP Inspectorを活用した検証と説明責任について紹介します。

    関連記事

    ▶ 第1回:自治体GISとAIの融合
    ▶第2回:ArcGIS Onlineと生成AIを連携した人口統計分析の実証
    ▶第3回:生成AIとGISで健康遊具の優先整備地区を抽出してみた
    ▶第4回:自治体の人材不足はGIS AIで解決できるのか
    ▶第5回:e-Stat APIとGISを結合するときの落とし穴
    ▶第6回:PLATEAU MCPは自治体GISを変えるのか
    ▶第8回:AIの回答は信用できるのか(検証と説明責任)
    ▶第9回:自治体GISにおける人口統計データの構造要件を生成AIで検証する
    ▶第10回:PLATEAU LOD1と生成AIで建物単位人口推計は可能か
    ▶第11回:PLATEAU建物人口から見る浸水リスク
    ▶第12回:建物単位人口で見る避難所シミュレーション
    ▶第13回:PLATEAUの建物に人口を配置する
    ▶第14回:PLATEAUを「人口を持つ都市」へ

  • PLATEAU MCPは自治体GISを変えるのか

    ~3D都市モデルを自然言語で扱う実証~

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

    追記(2026年8月)
    PLATEAU MCPの建物属性取得について再検証を行い、詳細用途、土地利用分類、指定建ぺい率・容積率など、当初未確認だった属性も取得できることを確認しました。本記事はその結果を踏まえて一部補強しています。

    関連記事

    ▶ 第1回:自治体GISとAIの融合
    ▶第2回:ArcGIS Onlineと生成AIを連携した人口統計分析の実証
    ▶第3回:生成AIとGISで健康遊具の優先整備地区を抽出してみた
    ▶第4回:自治体の人材不足はGIS AIで解決できるのか
    ▶第5回:e-Stat APIとGISを結合するときの落とし穴
    ▶第7回:健康遊具はどこに整備すべきか?生成AIとGISで検証
    ▶第8回:AIの回答は信用できるのか(検証と説明責任)
    ▶第9回:自治体GISにおける人口統計データの構造要件を生成AIで検証する
    ▶第10回:PLATEAU LOD1と生成AIで建物単位人口推計は可能か
    ▶第11回:PLATEAU建物人口から見る浸水リスク
    ▶第12回:建物単位人口で見る避難所シミュレーション
    ▶第13回:PLATEAUの建物に人口を配置する
    ▶第14回:PLATEAUを「人口を持つ都市」へ

    はじめに

    PLATEAUは国土交通省が公開している3D都市モデルです。

    近年、生成AIと外部システムを連携するMCP(Model Context Protocol)が注目されており、GIS分野でも活用が始まっています。

    今回、地域GIS研究所ではPLATEAU MCPを実際に利用し、

    ・どのようなデータが利用できるのか
    ・自然言語でどこまで分析できるのか
    ・自治体業務に活用できる可能性はあるのか

    を検証しました。

    その結果、

    PLATEAU MCPはGIS解析ツールではなく、

    「PLATEAUデータを探索・取得するためのAIインターフェース」

    として非常に有効であることが分かりました。

    また、公共空地の集計や空間検索など、従来であればGIS担当者が複数のツールを操作して行っていた作業を自然言語で実行できる可能性も確認できました。

    本記事では、和泉市を対象に実施した検証内容を紹介します。

    都市データ分析は可能なのかを検証してみました。


    PLATEAU MCPとは

    PLATEAU MCPは、PLATEAUが公開している3D都市モデルをAIエージェントから利用するための仕組みです。

    従来であれば、

    • PLATEAUサイトから対象データを探す
    • CityGMLをダウンロードする
    • ArcGIS ProやQGISへ変換する
    • 必要な属性を抽出する

    といった作業が必要でした。

    PLATEAU MCPでは、

    「和泉市の公共空地を集計してください」

    のような自然言語で指示を出すことができます。

    まず最初に確認したこと

    PLATEAU MCPを導入したものの、

    最初は何ができるのか分かりませんでした。

    そこで最初に次の質問を行いました。

    PLATEAU MCPで利用可能なツール一覧を表示してください

    すると、

    • データセット検索
    • CityGML検索
    • 空間ID検索
    • 建物属性取得

    などの機能が利用できることが分かりました。

    ここで初めて、

    PLATEAU MCPは分析ソフトではなく、PLATEAUデータを探索するためのAIインターフェース

    であることが理解できました。

    ※その後、別自治体の建築物モデルで再検証したところ、PLATEAU MCPは単なるデータセット探索だけでなく、CityGMLに格納された詳細な建物属性まで取得できることが確認できました。
    ただし、取得できる情報量はプロンプトの具体性によって大きく変わります。

    まずはどんなデータがあるのか調べてみた

    最初に次の質問を行いました。

    和泉市のPLATEAUデータセットを調査してください。

    すると、PLATEAU MCPから次の情報が返ってきました。

    地域情報

    項目内容
    地域名和泉市
    地域コード27219
    地域種別CITY
    平面直角座標系EPSG:6674
    利用可能年度2023
    登録年度2024
    PLATEAU仕様4.1
    CityGML取得可能

    利用可能なデータセット

    確認できた主なデータセットは以下のとおりです。

    都市モデル

    • 建築物モデル(bldg)
    • 土地利用モデル(luse)

    防災モデル

    • 洪水浸水想定区域モデル(fld)
    • 土砂災害警戒区域モデル(lsld)

    都市計画モデル

    • 区域区分
    • 用途地域
    • 地区計画
    • 公共空地
    • 都市計画区域
    • 市街地再開発事業
    • 土地区画整理事業
    • 防火地域
    • 特別用途地区

    など


    特に興味深かったのは、

    和泉市の当該PLATEAUデータセットには道路モデル(tran)は存在しなかった

    ことです。

    PLATEAUは全国で同じデータが整備されているわけではなく、自治体ごとに整備状況が異なることも確認できました。


    さらにPLATEAU MCPは、

    このデータがあります

    だけではなく、

    実際に取得できるCityGMLファイルまで示してくれました。

    例えば土地利用モデルでは、

    513544_luse_6697_op.gml
    513553_luse_6697_op.gml

    などのファイルが利用可能であることが分かりました。


    公共空地を分析してみる

    データが存在することが確認できたので、

    次は土地利用モデルを利用して分析を行いました。

    ここで登場するのが公共空地(217)です。

    公共空地とは

    • 公園
    • 緑地
    • 広場
    • 運動場

    などを含む土地利用区分です。

    今回入力したプロンプトは以下です。

    PLATEAU MCPを使って

    公共空地の

    ・件数
    ・面積
    ・分布

    を集計してください

    と質問しました。


    すると、AIは和泉市の土地利用モデル(luse)を探索し、対象となるCityGMLを特定して集計を実施しました。

    使用されたデータ

    項目内容
    自治体大阪府和泉市
    年度2023
    データ種別土地利用モデル(luse)
    対象分類公共空地
    分類コード217
    対象CityGML513543、513544、513553、513554

    件数・面積

    集計結果は以下のとおりです。

    指標
    件数94件
    総面積1,909,271㎡
    総面積190.93ha
    平均面積20,311㎡
    中央値7,838㎡
    最大面積234,272㎡
    最小面積246㎡

    単なる件数集計だけでなく、平均値や中央値まで整理されました。


    メッシュ別分布

    さらに、どのメッシュに公共空地が分布しているかも集計されました。

    メッシュ件数面積
    5135432件13,430㎡
    5135440件0㎡
    51355392件1,895,841㎡
    5135540件0㎡

    結果を見ると、

    公共空地の大部分が513553メッシュに集中している

    ことが分かります。


    空間分布

    さらにAIは重心位置から空間分布まで整理しました。

    区分件数面積
    西部・北側13件153,935㎡
    中部・北側33件606,608㎡
    中部・南側24件597,171㎡
    東部・北側15件350,679㎡
    東部・南側9件200,878㎡

    この結果から、

    • 中部・北側
    • 中部・南側

    に公共空地が多く分布していることが読み取れます。


    面積規模別の特徴

    さらに面積規模別に分類すると、

    • 1,000~10,000㎡の公共空地が最も多い
    • 一方で50,000㎡以上の大規模公共空地は8件しかない
    • しかし面積では全体の約54%を占める

    という特徴も確認できました。


    正直驚いた点

    ここで驚いたのは、私が依頼したのは

    件数
    面積
    分布

    だけだったことです。

    しかし実際には、

    • 件数
    • 総面積
    • 平均値
    • 中央値
    • 最大値
    • メッシュ分布
    • 方位別分布
    • 面積規模別分析

    まで自動的に整理されました。

    AIは何をしていたのか

    実際にはAIは次の処理を行っています。

    土地利用モデル検索

    CityGML特定

    不足データ確認

    データ取得

    ジオメトリ解析

    面積計算

    集計

    結果出力

    利用者は自然言語で質問しただけです。

    AIが実施した処理

    ① 土地利用モデル(luse)を検索

    ② 対象CityGMLファイルを特定

    ③ 不足メッシュを検出

    ④ CityGMLを取得

    ⑤ ジオメトリを解析

    ⑥ 面積を計算

    ⑦ 分布を集計

    ⑧ 結果を整理

    従来であればGIS担当者が複数のツールを使って実施していた作業です。


    空間ID検索も試してみた

    公共空地分析の次に、PLATEAU MCPの特徴的な機能である「空間ID検索」も試してみました。

    今回は和泉市役所周辺を対象に、

    和泉市役所周辺の空間ID検索例を示してください

    と質問しました。

    するとAIは、

    • 市役所の位置情報を取得
    • 緯度経度を十進度へ変換
    • 空間IDを生成
    • 対応するCityGMLを検索
    • 交差する建物を取得
    • 建物属性を取得

    という処理を実施しました。


    生成された空間ID

    市役所位置から生成された空間IDは次のとおりです。

    19/0/459368/208584

    また、周辺8セルを含めた9セル検索も実施されました。


    建物検索結果

    空間IDに交差する建物を検索した結果、

    bldg_6a445e5d-cf54-4a50-8653-b6d8ce7510e2

    という建物が取得されました。

    さらに周辺9セルで検索すると、

    32棟の建物

    が取得されました。


    取得できた建物属性

    取得された建物からは次のような属性が確認できました。

    項目結果
    建物ID27219-bldg-72179
    建物高さ29.4m
    土地利用公益施設用地
    土地利用コード214
    都市計画区域都市計画区域
    区域区分市街化区域
    調査年2023

    さらに、

    • 建物中心座標
    • 建物範囲
    • 標高

    まで取得できました。

    より詳細な建物属性も取得できるのか再検証

    当初の検証では、上表のような基本的な建物属性までを確認しました。
    その後、武蔵村山市の建築物CityGMLを対象に、取得したい属性を具体的に指定してPLATEAU MCPを再検証しました。

    その結果、以下の属性についても実値を取得できました。

    武蔵村山市の取得例

    属性取得例
    建物用途 usage住宅、共同住宅
    建物詳細用途 detailedUsage独立住宅、集合住宅
    土地利用分類 landUseType住宅用地
    指定建ぺい率40%
    指定容積率80%
    調査年2022
    都市計画種別都市計画区域
    屋根外周面積64.26758㎡ など
    地上階数2階
    地下階数0階
    計測高さ6.9m、7.4m、8.0m

    特に、建物詳細用途、指定建ぺい率・容積率といったURO拡張属性まで、PLATEAU MCP経由で取得できた点は重要です。


    正直驚いた点

    ここで興味深かったのは、

    私が知りたかったのは

    市役所周辺の建物

    だけだったことです。

    実際には、

    ・空間IDの生成
    ・空間IDに交差する建物検索
    ・建物属性の取得
    ・土地利用属性の取得
    ・都市計画関連属性の取得

    までが自動的に実行されました。

    従来であれば、

    PLATEAU ViewerやGISソフトを開いて確認していた内容です。


    自治体業務ではどう使えるのか

    今回の結果を見て感じたのは、

    空間IDは単なる研究用途ではなく、自治体業務にも応用できる可能性があるということです。

    例えば、

    • 公共施設台帳との照合
    • 防災施設の位置確認
    • 現地調査地点の管理
    • 3D都市モデルとの連携

    などです。

    一方で、PLATEAUの属性には建物名称が入っていません。

    そのため、

    今回取得した建物を

    「和泉市役所本庁舎」

    と断定するには、

    • 航空写真
    • 公共施設台帳
    • ArcGISの施設データ

    との照合が必要になります。


    処理時間はデータ量によって大きく変わる

    今回の検証では、対象データによって処理時間に大きな差が見られました。

    公共空地(217)の分析では、

    • 対象件数:94件
    • 対象ファイル:4ファイル

    だったため、件数・面積・分布の集計は約3分で完了しました。

    一方で、建築物モデルを対象とした調査では、

    • 建築物数:約64,000棟
    • CityGMLファイル数:81ファイル
    • 対象範囲:和泉市全域

    となり、建物数や利用可能属性の集計に約23分を要しました。

    これはPLATEAU MCPの性能というよりも、解析対象となるCityGMLデータ量の違いによるものです。


    従来作業との比較

    同じ分析を従来のGIS作業で行う場合を考えてみます。

    従来の作業

    • PLATEAUデータ検索:10分
    • CityGML取得:5分
    • ArcGIS Pro変換:15分
    • 属性確認:10分
    • 公共空地抽出:5分
    • 面積計算:5分
    • 集計表作成:10分

    合計:約60分

    MCP+AI

    • 自然言語による指示
    • 自動解析
    • 結果出力

    実行時間:約3分

    もちろん結果確認は必要ですが、調査作業だけで見れば大幅な時間短縮になります。


    実際に使って感じたこと

    今回の検証を通じて感じたのは、

    PLATEAU MCPは「GIS解析エンジン」ではなく、

    「都市データ検索エンジン」

    として非常に優秀だということです。

    特に、

    ・どのデータが存在するのか
    ・どのCityGMLが利用できるのか
    ・どの属性が利用できるのか

    を自然言語で確認できる点は大きなメリットです。

    プロンプト設計も結果を左右する

    今回の再検証で分かったのは、MCPサーバーの能力だけでなく、利用者がどこまで具体的に取得対象を指定するかによって、返ってくる情報量が大きく変わるということです。
    当初の検証では基本属性までの確認でしたが、詳細属性を明示して再度問い合わせることで、より多くのURO属性を取得できました。

    一方で、

    ・統計データとの統合
    ・高度な空間分析
    ・ダッシュボード作成
    ・Webマップ公開

    についてはArcGISなど他のGIS基盤が必要になります。


    今後の可能性

    今回の検証では、

    自治体職員

    PLATEAU MCP

    必要な属性を自然言語で指定

    CityGML取得

    AI解析

    結果確認

    という流れを確認できました。

    今後はさらに、

    ・PLATEAU MCP
    ・ArcGIS MCP
    ・e-Stat API
    ・生成AIエージェント

    を組み合わせることで、

    統計データの取得

    GISデータ整備

    空間分析

    政策判断支援

    までを自然言語で実行できる可能性があります。

    さらに再検証では、質問の仕方を具体化することで、通常の属性確認では表面化しなかった詳細用途、土地利用分類、指定建ぺい率・容積率なども取得できました。

    つまりPLATEAU MCPでは、単に「どの属性がありますか」と聞くだけでなく、
    「detailedUsageを取得してください」
    「指定建ぺい率・容積率を確認してください」
    と取得対象を明示することで、CityGML内部のより詳細な属性まで利用できる可能性があります。

    特に自治体では、人材不足やGIS担当者への業務集中が課題となっています。

    特に、CityGMLのXML構造やURO属性名を職員が完全に理解していなくても、取得したい情報を自然言語で指定し、AIがMCPツールを呼び出して属性を取得できる点は大きな特徴です。

    今回確認できた仕組みは、専門職だけでなく一般職員もGISを活用できる環境につながる可能性があります。よく活用するための入口として非常に有効であることが確認できました。

    次回予告

    PLATEAU MCP単体では分析は完結しません。

    次回は、

    LATEAU MCP
    (データ探索・CityGML特定)

    ArcGIS MCP
    (GIS解析)

    e-Stat API
    (人口統計)

    生成AI

    を組み合わせ、

    統計データ取得からGIS分析までを自然言語で実行できるのかを検証します。

    地域GIS研究所では、生成AIとGISを活用した自治体業務の可能性について、引き続き実証と研究を進めていきます。

    関連記事

    ▶ 第1回:自治体GISとAIの融合
    ▶第2回:ArcGIS Onlineと生成AIを連携した人口統計分析の実証
    ▶第3回:生成AIとGISで健康遊具の優先整備地区を抽出してみた
    ▶第4回:自治体の人材不足はGIS AIで解決できるのか
    ▶第5回:e-Stat APIとGISを結合するときの落とし穴
    ▶第7回:健康遊具はどこに整備すべきか?生成AIとGISで検証
    ▶第8回:AIの回答は信用できるのか(検証と説明責任)
    ▶第9回:自治体GISにおける人口統計データの構造要件を生成AIで検証する
    ▶第10回:PLATEAU LOD1と生成AIで建物単位人口推計は可能か
    ▶第11回:PLATEAU建物人口から見る浸水リスク
    ▶第12回:建物単位人口で見る避難所シミュレーション
    ▶第13回:PLATEAUの建物に人口を配置する
    ▶第14回:PLATEAUを「人口を持つ都市」へ

  • e-Stat APIとGISを結合するときの落とし穴

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

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

    ▶ 第1回:自治体GISとAIの融合
    ▶第2回:ArcGIS Onlineと生成AIを連携した人口統計分析の実証
    ▶第3回:生成AIとGISで健康遊具の優先整備地区を抽出してみた
    ▶第4回:自治体の人材不足はGIS AIで解決できるのか
    ▶第6回:PLATEAU MCPは自治体GISを変えるのか
    ▶第7回:健康遊具はどこに整備すべきか?生成AIとGISで検証
    ▶第8回:AIの回答は信用できるのか(検証と説明責任)
    ▶第9回:自治体GISにおける人口統計データの構造要件を生成AIで検証する
    ▶第10回:PLATEAU LOD1と生成AIで建物単位人口推計は可能か
    ▶第11回:PLATEAU建物人口から見る浸水リスク
    ▶第12回:建物単位人口で見る避難所シミュレーション
    ▶第13回:PLATEAUの建物に人口を配置する
    ▶第14回:PLATEAUを「人口を持つ都市」へ

    はじめに

    近年、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で解決できるのか
    ▶第6回:PLATEAU MCPは自治体GISを変えるのか
    ▶第7回:健康遊具はどこに整備すべきか?生成AIとGISで検証
    ▶第8回:AIの回答は信用できるのか(検証と説明責任)
    ▶第9回:自治体GISにおける人口統計データの構造要件を生成AIで検証する
    ▶第10回:PLATEAU LOD1と生成AIで建物単位人口推計は可能か
    ▶第11回:PLATEAU建物人口から見る浸水リスク
    ▶第12回:建物単位人口で見る避難所シミュレーション
    ▶第13回:PLATEAUの建物に人口を配置する
    ▶第14回:PLATEAUを「人口を持つ都市」へ

  • 自治体の人材不足はGIS AIで解決できるのか

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

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

    関連記事

    ▶ 第1回:自治体GISとAIの融合
    ▶第2回:ArcGIS Onlineと生成AIを連携した人口統計分析の実証
    ▶第3回:生成AIとGISで健康遊具の優先整備地区を抽出してみた
    ▶第5回:e-Stat APIとGISを結合するときの落とし穴
    ▶第6回:PLATEAU MCPは自治体GISを変えるのか
    ▶第7回:健康遊具はどこに整備すべきか?生成AIとGISで検証
    ▶第8回:AIの回答は信用できるのか(検証と説明責任)
    ▶第9回:自治体GISにおける人口統計データの構造要件を生成AIで検証する
    ▶第10回:PLATEAU LOD1と生成AIで建物単位人口推計は可能か
    ▶第11回:PLATEAU建物人口から見る浸水リスク
    ▶第12回:建物単位人口で見る避難所シミュレーション
    ▶第13回:PLATEAUの建物に人口を配置する
    ▶第14回:PLATEAUを「人口を持つ都市」へ

    はじめに

    総務省が公表した「自治体における生成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を組み合わせた自治体業務への活用について、引き続き実証と研究を進めていきます。

    参考資料


    関連記事

    ▶ 第1回:自治体GISとAIの融合
    ▶第2回:ArcGIS Onlineと生成AIを連携した人口統計分析の実証
    ▶第3回:生成AIとGISで健康遊具の優先整備地区を抽出してみた
    ▶第5回:e-Stat APIとGISを結合するときの落とし穴
    ▶第6回:PLATEAU MCPは自治体GISを変えるのか
    ▶第7回:健康遊具はどこに整備すべきか?生成AIとGISで検証
    ▶第8回:AIの回答は信用できるのか(検証と説明責任)
    ▶第9回:自治体GISにおける人口統計データの構造要件を生成AIで検証する
    ▶第10回:PLATEAU LOD1と生成AIで建物単位人口推計は可能か
    ▶第11回:PLATEAU建物人口から見る浸水リスク
    ▶第12回:建物単位人口で見る避難所シミュレーション
    ▶第13回:PLATEAUの建物に人口を配置する
    ▶第14回:PLATEAUを「人口を持つ都市」へ

  • 生成AIとGISで健康遊具の優先整備地区を抽出してみた

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

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

    関連記事

    ▶ 第1回:自治体GISとAIの融合
    ▶第2回:ArcGIS Onlineと生成AIを連携した人口統計分析の実証
    ▶第4回:自治体の人材不足はGIS AIで解決できるのか
    ▶第5回:e-Stat APIとGISを結合するときの落とし穴
    ▶第6回:PLATEAU MCPは自治体GISを変えるのか
    ▶第7回:健康遊具はどこに整備すべきか?生成AIとGISで検証
    ▶第8回:AIの回答は信用できるのか(検証と説明責任)
    ▶第9回:自治体GISにおける人口統計データの構造要件を生成AIで検証する
    ▶第10回:PLATEAU LOD1と生成AIで建物単位人口推計は可能か
    ▶第11回:PLATEAU建物人口から見る浸水リスク
    ▶第12回:建物単位人口で見る避難所シミュレーション
    ▶第13回:PLATEAUの建物に人口を配置する
    ▶第14回:PLATEAUを「人口を持つ都市」へ

    背景

    自治体では、

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

    が課題となっています。

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

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

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

    今回の目的

    豊島区を例に、

    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,1060A
    2池袋二丁目1,0250A
    3長崎四丁目9870C
    4要町三丁目9560C
    5上池袋三丁目9510C

    実際の出力


    ③ 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を連携した人口統計分析の実証
    ▶第4回:自治体の人材不足はGIS AIで解決できるのか
    ▶第5回:e-Stat APIとGISを結合するときの落とし穴
    ▶第6回:PLATEAU MCPは自治体GISを変えるのか
    ▶第7回:健康遊具はどこに整備すべきか?生成AIとGISで検証
    ▶第8回:AIの回答は信用できるのか(検証と説明責任)
    ▶第9回:自治体GISにおける人口統計データの構造要件を生成AIで検証する
    ▶第10回:PLATEAU LOD1と生成AIで建物単位人口推計は可能か
    ▶第11回:PLATEAU建物人口から見る浸水リスク
    ▶第12回:建物単位人口で見る避難所シミュレーション
    ▶第13回:PLATEAUの建物に人口を配置する
    ▶第14回:PLATEAUを「人口を持つ都市」へ

  • ArcGIS Onlineと生成AIを連携した人口統計分析の実証

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

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

    関連記事

    ▶ 第1回:自治体GISとAIの融合
    ▶第3回:生成AIとGISで健康遊具の優先整備地区を抽出してみた
    ▶第4回:自治体の人材不足はGIS AIで解決できるのか
    ▶第5回:e-Stat APIとGISを結合するときの落とし穴
    ▶第6回:PLATEAU MCPは自治体GISを変えるのか
    ▶第7回:健康遊具はどこに整備すべきか?生成AIとGISで検証
    ▶第8回:AIの回答は信用できるのか(検証と説明責任)
    ▶第9回:自治体GISにおける人口統計データの構造要件を生成AIで検証する
    ▶第10回:PLATEAU LOD1と生成AIで建物単位人口推計は可能か
    ▶第11回:PLATEAU建物人口から見る浸水リスク
    ▶第12回:建物単位人口で見る避難所シミュレーション
    ▶第13回:PLATEAUの建物に人口を配置する
    ▶第14回:PLATEAUを「人口を持つ都市」へ

    自治体では人口統計や地域分析を行う際、
    統計データ収集や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分
    自治体境界とのJoin20分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を結合するときの落とし穴
    ▶第6回:PLATEAU MCPは自治体GISを変えるのか
    ▶第7回:健康遊具はどこに整備すべきか?生成AIとGISで検証
    ▶第8回:AIの回答は信用できるのか(検証と説明責任)
    ▶第9回:自治体GISにおける人口統計データの構造要件を生成AIで検証する
    ▶第10回:PLATEAU LOD1と生成AIで建物単位人口推計は可能か
    ▶第11回:PLATEAU建物人口から見る浸水リスク
    ▶第12回:建物単位人口で見る避難所シミュレーション
    ▶第13回:PLATEAUの建物に人口を配置する
    ▶第14回:PLATEAUを「人口を持つ都市」へ

  • 自治体GISとAIの融合

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

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

    関連記事

    ▶第2回:ArcGIS Onlineと生成AIを連携した人口統計分析の実証
    ▶第3回:生成AIとGISで健康遊具の優先整備地区を抽出してみた
    ▶第4回:自治体の人材不足はGIS AIで解決できるのか
    ▶第5回:e-Stat APIとGISを結合するときの落とし穴
    ▶第6回:PLATEAU MCPは自治体GISを変えるのか
    ▶第7回:健康遊具はどこに整備すべきか?生成AIとGISで検証
    ▶第8回:AIの回答は信用できるのか(検証と説明責任)
    ▶第9回:自治体GISにおける人口統計データの構造要件を生成AIで検証する
    ▶第10回:PLATEAU LOD1と生成AIで建物単位人口推計は可能か
    ▶第11回:PLATEAU建物人口から見る浸水リスク
    ▶第12回:建物単位人口で見る避難所シミュレーション
    ▶第13回:PLATEAUの建物に人口を配置する
    ▶第14回:PLATEAUを「人口を持つ都市」へ

    はじめに

    自治体では近年、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件

    でした。

    さらに、

    府中町7丁目
    ↓
    府中町七丁目

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


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

    次に、

    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を結合するときの落とし穴
    ▶第6回:PLATEAU MCPは自治体GISを変えるのか
    ▶第7回:健康遊具はどこに整備すべきか?生成AIとGISで検証
    ▶第8回:AIの回答は信用できるのか(検証と説明責任)
    ▶第9回:自治体GISにおける人口統計データの構造要件を生成AIで検証する
    ▶第10回:PLATEAU LOD1と生成AIで建物単位人口推計は可能か
    ▶第11回:PLATEAU建物人口から見る浸水リスク
    ▶第12回:建物単位人口で見る避難所シミュレーション
    ▶第13回:PLATEAUの建物に人口を配置する
    ▶第14回:PLATEAUを「人口を持つ都市」へ