Google Cloud生成AIが自治体業務をどう変える

紙とPDFに埋もれる審査現場をAIがほどく構図

あなたの自治体案件でも、申請書がPDFで届き、過去の条例や地域計画を何度も突き合わせる場面はないだろうか。英国政府がAI導入を急いだ理由は、まさにその光景にあります。建築許可や改修申請は、書類の量が膨らむほど担当者の判断前処理が重くなり、業務が滞ります。この記事を読んで私が強く受け取ったのは、AIの役割が「判断の代替」ではなく「判断の前段の圧縮」に移ったことです。そこを外すと、公共部門でAIを使う意味は見えません。

英国では2029年までに150万戸の新築住宅を建てる目標が掲げられています。150万戸は住宅供給の総量目標であり、各自治体の審査速度が国家目標の達成可否を左右します。しかも、家屋の増改築などのhouseholder applicationsが年間申請の約70％を占めます。70％という比率は、担当者が日々向き合う定型業務の大きさをそのまま示しています。ここに生成AIを当てる判断は、業務改善ではなく政策遂行の加速策です。

Google Cloudの今回の取り組みは、単なる実証実験ではありません。英国の住宅・地域・地方政府省であるMHCLGと、DSIT、政府の応用AIチームi.AIが、Google DeepMindやFacultyと組み、自治体の実務に耐える形まで仕上げています。公共部門のAI導入は、派手なデモよりも、既存制度との整合性と監査可能性が勝負です。そこを外したAIは、現場では使われません。

ExtractとAPDの2系統で業務を分解した設計

今回の中核は、用途を分けた2つのツールです。1つ目が「Extract」、2つ目が「Augmented Planning Decisions（APD）」です。Extractは、古いPDFや歴史資料に閉じ込められた非構造化データを読み取り、数百ページ規模の文書を数分で構造化データへ変換します。非構造化データとは、検索や集計にそのまま使いにくい文章・画像・PDFのような情報です。これを表形式に直すだけで、現場の検索性と再利用性が一気に上がります。

試験運用は20以上の地方計画当局で行われ、その後、Englandの全自治体へ展開が広がりました。20以上という数字は、単一部署のPoCではなく、複数自治体での差分検証を通過したことを意味します。さらに、Extractは自治体ごとに年255時間の手作業入力削減を見込んでいます。255時間は、週40時間換算でおよそ6週間分の工数です。たった1自治体でも、専門職1人分に近い時間が戻る計算になります。

APDはより踏み込んだ支援を行います。受け取った書類をまとめ、欠落情報を示し、敷地情報を抽出し、国・地方のゾーニング規則を引き当て、住民意見を要約し、最終報告書の下書きまで作ります。つまり、審査の4工程以上を横断して、担当者の手戻りを削る設計です。私はここに、生成AIの実務的な強みがはっきり出ていると見ます。単独タスクの自動化ではなく、業務フロー全体の前処理をまとめて短縮しているからです。

ただし、最終承認や却下は人間が持ちます。APDは報告書の草案を作っても、全文を職員が確認し、修正し、検証します。この「人が最後に署名する」構造は、行政AIで必須です。Lila Ibrahim氏はGoogle DeepMindのChief AI Readiness Officerとして、現場のボトルネック解消を強調しました。Google Cloud側はGeminiモデルをクラウド上に載せ、データ主権を保つ保護環境を用意し、prompt injection攻撃も防ぐ設計を組み込みました。prompt injectionとは、AIに不正な指示を紛れ込ませる攻撃です。公共データを扱うなら、モデル精度より先にこの防御が必要です。

APDのalpha版は、Barnet、Dorset、Camdenの3自治体で稼働しています。3自治体という少数は、制度差の大きい地域での比較検証を重視した段階です。中央政府は2027年までに300超の英自治体へ展開する計画を示しました。300超は、局所最適から制度インフラへの移行を意味します。ここまで来ると、UIの出来よりも、監査ログ、説明責任、例外処理の設計が勝敗を分けます。

日本の自治体DXで最初に効くのは「審査前処理」

日本企業や開発者がこの事例から学ぶべき点は、生成AIをいきなり最終判断に使わないことです。まず効くのは、申請内容の読み取り、関連文書の検索、要約、差分抽出、下書き生成です。現場では「まず担当者の手を空ける」ことが最優先であり、そこを一度は考えたことがあるはずです。自治体だけでなく、建設、不動産、保険、法務でも同じ構図が成立します。

特に日本では、紙文化が残る手続きやPDF添付のやり取りが多く、情報が分散しています。こうした工程にGeminiのような大規模言語モデルを組み込む場合、モデル性能だけでなく、文書管理、権限管理、ログ保存、外部参照の統制が要件になります。AI導入の現場で失敗する原因は、モデルの限界よりも、業務設計の甘さにあります。これは自治体向けに限らない重要な論点です。

また、英国事例は「クラウド上で閉じた環境を作れば、公共部門でも生成AIは回る」という実例になっています。日本の自治体でも、庁内閉域、データ持ち出し制限、監査対応の3点を先に揃えれば、計画業務や文書判定の支援は導入可能です。生成AIを議事録作成ツールで止めるのではなく、業務の滞留を解く装置として設計するべきです。

制度対応が進むほど公共部門AIは実装段階へ進む

今後は、公共部門向けAIの勝負が「導入するか」から「どこまで業務に深く埋め込むか」に移ります。英国は全国展開の道筋を明示しましたが、他国でも同様の流れが起きます。自治体事務の遅延はどこでも共通課題であり、生成AIはその解消手段として採用されます。私は、今後の焦点はモデル名よりも、監査証跡と人手確認をどう標準化するかに移ると見ます。

日本でも、公共DXの現場で同じ設計思想が採用されれば、AIは「運用を壊す存在」ではなく「停滞をほどく基盤」になります。その分岐点はすでに来ています。