～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で検証
本記事は、生成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で検証
コメントを残す