はじめに
人口減少と職員不足が進む小規模自治体にとって、生成AIは単なる文書作成ツールではない。限られた職員数で行政サービスを維持し、制度改正や災害対応、住民からの問い合わせに対応していくための業務基盤になりつつある。
しかし、小規模自治体が単独でAI基盤を構築しようとすると、初期費用だけでなく、情報セキュリティ、調達仕様の作成、利用ルール、職員研修、ログ監査、モデル更新など、多くの課題に直面する。
そこで注目されるのが、都道府県や複数市町村がAI基盤を共同で整備・利用する「共同利用型AI基盤」である。
重要なのは、同じ生成AIサービスをまとめて契約することだけではない。インフラ、ネットワーク、AIモデル、業務アプリ、ガバナンスを共通化しつつ、各自治体のデータと権限を分離する仕組みが必要になる。
本記事では、小規模自治体に適した共同利用型AI基盤の構造と、実証実験で終わらせず社会実装につなげる方法を解説する。
なぜ小規模自治体では単独導入が難しいのか
AI導入には「見えにくい運用業務」がある
生成AIは、サービスを契約して職員にアカウントを配れば定着するものではない。
実際には、次のような業務が継続的に発生する。
- 入力可能な情報と禁止情報の分類
- 利用者アカウントと権限の管理
- プロンプトや回答ログの保存・監査
- 誤回答や情報漏えいが疑われる場合の対応
- AIモデルや利用規約の変更確認
- 庁内文書を検索するRAGのデータ更新
- 職員研修と問い合わせ対応
- 利用状況・費用・効果の測定
職員数の少ない自治体ほど、情報政策部門の担当者が他業務を兼務していることが多い。AIの技術だけでなく、法務、契約、情報管理、業務改善まで一人の担当者に求めることには限界がある。
自治体ごとの個別導入は重複投資を生む
自治体業務には、議事録の要約、通知文案の作成、庁内FAQ、制度説明、条例検索、住民向け回答案の作成など、共通する業務が多い。
それにもかかわらず、自治体ごとに同じような調達仕様書、利用ルール、研修教材、プロンプト、評価基準を一から作成すれば、地域全体で重複投資が発生する。
デジタル庁も、都道府県を中心とした自治体システムの共同調達事例について、参加自治体数や初期費用、年間運用費などを確認できる事例情報を公開している。共同化はAIだけの特殊な考え方ではなく、自治体システム調達全体に共通する選択肢である。デジタル庁「都道府県を中心とした地方自治体システムの共同調達」
共同利用型AI基盤とは何か
共同利用型AI基盤とは、複数の自治体が共通の技術基盤、接続環境、AIモデル、アプリケーション、運用ルールを利用しながら、自治体ごとのデータと利用権限を分離する仕組みである。
小規模自治体に適した構成は、次の5層に分けて考えると整理しやすい。
| 層 | 共同化する内容 | 自治体ごとに管理する内容 |
|---|---|---|
| 基盤層 | クラウド、AIモデル、監視、バックアップ | 利用範囲、予算配分 |
| 接続層 | LGWAN-ASP、認証、通信経路 | 利用者アカウント、端末権限 |
| データ層 | RAG基盤、文書取込機能、検索機能 | 条例、要綱、議事録、庁内資料 |
| アプリ層 | 要約、照会回答、文案作成など | 業務別プロンプト、承認フロー |
| ガバナンス層 | 調達要件、契約条件、監査基準 | 責任者、利用承認、事故対応 |
ポイントは「共通化」と「分離」を同時に実現することである。
共通化だけを優先すると、自治体固有の条例や業務手順に対応できない。一方、個別最適を許しすぎると、共同利用による費用と運用負担の削減効果が失われる。
LGWANとクラウドをどう使い分けるか
LGWAN-ASPは庁内業務との接続に適している
LGWAN-ASPは、LGWANを通じて地方公共団体の職員に行政事務サービスを提供する仕組みである。アプリケーション、ホスティング、通信など複数のサービス区分によって構成されている。J-LIS「LGWAN-ASPについて」
職員が普段使用するLGWAN接続系からAIを利用できれば、ネットワークの切り替えやファイルの手動移動を減らせる。共同利用型AI基盤では、LGWAN-ASPをAI機能への安全な入口として利用する方法が有力である。
また、J-LISはISMAPクラウドサービスリストに登録されたIaaSを利用したLGWAN-ASPホスティングを可能としており、生成AIなどの技術を活用したサービス提供の拡大が期待されている。J-LIS「クラウド利用型LGWAN-ASPの登録開始」
ただし、「LGWANから接続できる」という理由だけで安全性が保証されるわけではない。入力情報の分類、権限管理、保存期間、ログ監査、委託先管理などは別途設計する必要がある。
ガバメントクラウドを使えば自動的に解決するわけではない
ガバメントクラウドは、自治体の標準準拠システムを含む公共情報システムの基盤として整備が進められている。デジタル庁「地方公共団体の基幹業務システムの統一・標準化」
しかし、自治体向けAIをすべてガバメントクラウドに配置すればよい、という単純な話ではない。
共同利用型AI基盤では、次の点を個別に確認する必要がある。
- AIで処理する情報の機密性
- LGWAN接続系との接続方法
- 自治体ごとのデータ分離
- モデル提供事業者へのデータ送信範囲
- 入出力データの保存場所
- 障害時の代替手段
- モデルやクラウド事業者を変更できる設計
- 契約終了時のデータ消去と移行方法
つまり、ガバメントクラウド、LGWAN-ASP、外部クラウドを目的に応じて組み合わせ、責任分界を明確にする必要がある。
国のAI基盤と先進自治体から学べること
ガバメントAI「源内」が示す共通基盤の方向性
デジタル庁は、政府職員が安全にAIを利用するためのガバメントAI「源内」を各府省庁へ展開している。2026年度中には、全府省庁の約18万人が利用可能となる予定である。デジタル庁「ガバメントAI『源内』」
さらに、源内の一部はOSSとして公開された。地方公共団体や政府機関によるAI基盤の重複開発を抑え、特定事業者への依存を軽減することが目的に含まれている。デジタル庁「ガバメントAI『源内』をOSSとして公開」
ただし、小規模自治体がOSSを取得して独自運用するだけでは、サーバー管理やセキュリティ更新の負担が残る。実際の共同利用では、都道府県、広域連合、共同事業体などが運営主体となり、保守まで含めて提供する仕組みが求められる。
東京都「A1」が示すデジタル公共財
東京都とGovTech東京は、職員が専門知識を持たなくても業務用AIアプリを作成できる生成AIプラットフォーム「A1」を整備している。
作成したアプリを組織内で共有できるだけでなく、他自治体で再利用できる「デジタル公共財」とする構想が示されている。GovTech東京「都職員約6万人が生成AI『A1』を利活用開始」
小規模自治体にとって重要なのは、高度なAIモデルを独自開発することではない。他自治体が検証した業務アプリ、プロンプト、評価方法を再利用できる仕組みを作ることである。
自治体固有データにはRAGを活用する
共通の生成AIモデルだけでは、自治体固有の条例、要綱、組織情報、過去の答弁、手続方法を正確に回答することは難しい。
そこで必要になるのが、庁内文書を検索し、関連する根拠をAIへ渡して回答を生成するRAGである。
共同利用型AI基盤では、RAGのエンジンや文書取込機能を共通化しながら、登録文書は自治体ごとの領域に分離する。
RAG運用で確認すべき項目
- 回答に参照文書名と該当箇所を表示できるか
- 廃止された要綱や旧版文書を除外できるか
- 文書の所管課と更新責任者を登録できるか
- 自治体間でデータが混在しないか
- 閲覧権限が回答生成にも反映されるか
- AIが根拠を取得できない場合に回答を保留できるか
- 回答ログから誤りを検証できるか
RAGは誤回答を完全になくす仕組みではない。根拠の確認と職員による最終判断を行いやすくする仕組みとして位置づけることが重要である。
共同利用で標準化すべきガバナンス
デジタル庁は2026年6月、生成AIの技術進展やユースケースの拡大を踏まえ、「行政の進化と革新のための生成AIの調達・利活用に係るガイドライン」を第2.0版へ改定した。デジタル庁「生成AIの調達・利活用に係るガイドライン第2.0版」
共同利用型AI基盤では、このような国の指針を参照し、次の文書を共同で整備する必要がある。
- AI利用規程
- リスク判定基準
- 入力禁止情報一覧
- 調達要件チェックリスト
- 契約チェックリスト
- データ取扱基準
- インシデント対応手順
- ログ保存・監査基準
- AI回答の人による確認基準
- モデル更新時の再評価手順
ただし、共同ルールを導入しても、各自治体の責任がなくなるわけではない。
共同運営主体、参加自治体、システム事業者、AIモデル提供者について、誰が何を監視し、事故発生時に誰が判断するのかを契約と運用手順の両方で明確にする必要がある。
社会実装につなげる段階的な導入方法
第1段階：共同化する範囲を決める
最初にAI製品を選ぶのではなく、複数自治体に共通する業務を整理する。
初期対象としては、文章の校正、要約、会議録整理、企画案の壁打ちなど、個人情報や機密情報を含まない業務が適している。
第2段階：非機微情報で実証する
限定した職員と業務で試行し、回答精度だけでなく、利用頻度、修正時間、問い合わせ件数、研修負担を測定する。
「便利だった」という感想だけで導入判断を行わないことが重要である。
第3段階：自治体固有文書をRAGへ接続する
条例、要綱、マニュアルなどを整理し、文書の更新日、所管課、有効期限、公開区分を付与する。
AI導入の前に文書管理を整備することで、回答精度と説明可能性を高められる。
第4段階：業務アプリを自治体間で共有する
検証済みのプロンプトや業務アプリをカタログ化する。
他自治体がそのまま利用するのではなく、根拠文書、承認経路、住民向け表現などを確認してから採用する。
第5段階：本番運用と継続評価へ移行する
本番運用後も、次の指標を継続的に確認する。
- 月間利用者数と継続利用率
- 業務ごとの処理時間
- AI回答の修正率
- 根拠文書を確認できた割合
- 誤回答・利用停止件数
- 職員からの問い合わせ件数
- 自治体間で再利用されたアプリ数
- 利用者一人当たりの運用費
費用削減だけでなく、業務品質、説明責任、職員負担、住民サービスへの影響を含めて評価することが必要である。
JAICが考える小規模自治体AI導入の要点
小規模自治体に必要なのは、大規模自治体のシステムを小さくしたものではない。
共通部分は都道府県や複数自治体でまとめ、条例、業務手順、住民対応など地域固有の部分だけを各自治体が管理できる構造が必要である。
また、共同利用の目的を「安く契約すること」だけに設定してはならない。調達仕様、利用ルール、研修、文書管理、効果測定まで共同化して初めて、小規模自治体の負担軽減につながる。
JAICは、特定のAI製品を前提にするのではなく、自治体のネットワーク環境、情報分類、職員体制、対象業務を確認したうえで、無理のない接続方式と運用体制を設計することが重要だと考える。
まとめ
小規模自治体における生成AIの社会実装は、個別自治体が単独で高額なAI基盤を保有する形ではなく、共同利用型へ移行していく可能性が高い。
そのためには、次の5つを一体として設計する必要がある。
- クラウドとAIモデルの共同利用
- LGWANなどを利用した安全な接続
- 自治体ごとに分離されたRAG
- 業務アプリとプロンプトの広域共有
- ガバナンスと専門人材の共同化
導入の成否を決めるのは、AIモデルの性能だけではない。誰が運営し、誰がデータを管理し、誰が回答を確認し、問題発生時に誰が対応するのかという運用設計である。
共同利用型AI基盤は、小規模自治体が大規模自治体と同じシステムを使うための仕組みではない。地域の実情を残したまま、高度な技術と専門人材を共有するための新しい行政基盤なのである。
コメント