はじめに：自治体の生成AI活用は「試す段階」から「運用する段階」へ
自治体における生成AI活用は、職員が個別にチャット型AIを試す段階から、組織として安全に使えるAI基盤を整備する段階へ移りつつあります。人口減少、人手不足、住民対応の複雑化、文書作成業務の増加などを背景に、AIをどのように行政実務へ組み込むかは、今後の自治体経営における重要なテーマです。
その中で注目されているのが、デジタル庁が開発・展開を進めるガバメントAI「源内」です。デジタル庁は、源内を政府職員が安全・安心にAIを活用できる基盤と位置づけ、2026年度中に全府省庁約18万人の政府職員が生成AIを利用可能とする予定を示しています。
さらに2026年4月、源内の一部がOSSとして公開されました。これは、地方公共団体や政府機関が類似のAI基盤を重複して開発することを防ぎ、各機関が自らの要件に応じてAI基盤を運用・発展させることを後押しするものです。
ただし、OSSが公開されたからといって、自治体がそのまま導入すればよいわけではありません。行政情報を扱う以上、技術基盤、セキュリティ、職員研修、業務プロセス、データ管理、調達方針を合わせて設計する必要があります。
ガバメントAI「源内」とは何か
ガバメントAI「源内」は、政府職員が生成AIを行政実務で活用するための基盤です。単なるチャットツールではなく、行政職員が業務特化のAIアプリケーションを安全かつ簡単に利用できる環境を目指して設計されています。
GitHubで公開されている「源内 Web」は、デジタル庁が開発・運用する生成AI利活用基盤であり、行政職員向けの業務特化AIアプリケーションを提供する環境と説明されています。AWSのオープンソース「Generative AI Use Cases」をベースにしつつ、チーム管理、AIアプリ管理、外部マイクロサービス連携、監視・モニタリングなど、行政利用を想定した機能が追加されています。
自治体にとって重要なのは、源内が「完成済みの単体サービス」というより、行政機関が生成AIを安全に使うための設計思想と実装例を示している点です。つまり、自治体が参考にすべきなのは、ソースコードそのものだけではなく、業務特化AIアプリ、権限管理、ログ管理、データ連携、運用ルールを一体で整える考え方です。
なぜ自治体にAI基盤が必要なのか
自治体業務には、住民対応、議会対応、庁内文書作成、要綱・規則の確認、補助金事務、福祉・子育て・防災関連の情報整理など、多くの文書処理業務があります。こうした業務は属人的になりやすく、経験豊富な職員の知識に依存しがちです。
生成AIは、文章の下書き、要約、分類、照会対応、FAQ作成、資料整理などに活用できる可能性があります。しかし、職員が自由に外部AIサービスを使うだけでは、個人情報や未公開情報の入力、回答根拠の不明確さ、利用履歴の管理不足といったリスクが残ります。
そのため、自治体で必要になるのは「AIを使うこと」ではなく、「安全に使える共通基盤を整えること」です。源内OSSは、そのための参考モデルになり得ます。
自治体が確認すべき技術要件
ガバメントクラウドや既存環境との整合性
自治体がAI基盤を構築する場合、まず確認すべきなのは、現在の庁内ネットワーク、基幹業務システム、認証基盤、ガバメントクラウド移行計画との整合性です。
生成AI基盤は、単独で動けばよいものではありません。職員が普段使う端末から安全にアクセスできること、庁内の認証と連携できること、必要に応じて文書管理システムやFAQデータベースと接続できることが重要です。
特に自治体では、LGWAN系、インターネット系、マイナンバー利用事務系など、ネットワーク分離を前提とした環境が存在します。そのため、どの業務でAIを使うのか、どの情報を参照させるのか、どのネットワークから利用するのかを事前に整理しなければなりません。
複数LLMを使い分ける設計
生成AIのモデルは、用途によって得意不得意があります。文章作成に強いモデル、翻訳に向いたモデル、検索拡張生成に適したモデル、軽量でコストを抑えやすいモデルなど、選択肢は一つではありません。
源内の考え方から学べるのは、特定のAIモデルに固定するのではなく、業務内容に応じて複数のLLMを使い分けられる設計です。高度な判断支援が必要な業務と、定型的な文章整形業務では、求められる精度、処理速度、コスト、セキュリティ条件が異なります。
自治体がAI基盤を検討する際は、「どのAIを使うか」だけでなく、「将来、モデルを切り替えられるか」「特定ベンダーに過度に依存しないか」を確認することが重要です。
RAGによる自治体固有情報への対応
自治体業務では、AIの一般知識だけでは不十分です。条例、規則、要綱、庁内マニュアル、過去の答弁、住民向け案内文、FAQなど、自治体ごとの情報に基づいた回答が求められます。
そこで重要になるのが、RAG、つまり検索拡張生成の仕組みです。RAGは、AIにあらかじめ学習されていない内部文書を検索し、その内容を参照しながら回答を生成する仕組みです。
ただし、RAGは文書を入れれば自動的に精度が上がるものではありません。文書の形式、更新頻度、ファイル名、権限設定、古い文書の扱い、回答時の根拠表示などを設計しなければ、誤った回答や古い情報の参照につながる可能性があります。
自治体では、AI導入前に「どの文書をAIに参照させるか」「誰が更新するか」「根拠をどのように表示するか」を決めておく必要があります。
運用面で見落とされやすい課題
業務プロセスを標準化しなければAIは活きない
生成AIは、定型化された業務やルールが明確な作業で効果を発揮しやすい一方、業務手順が部署ごとに異なる場合や、暗黙知に依存している場合は、十分に活用しにくくなります。
たとえば、問い合わせ対応の文章作成にAIを使う場合でも、回答方針、確認すべき根拠資料、決裁ルート、住民へ伝えてよい表現が整理されていなければ、AIの出力をそのまま使うことはできません。
AI導入は、業務改善の道具です。先に業務フローを見える化し、AIに任せる部分、人が確認する部分、管理職が判断する部分を分けることが必要です。
職員のAIリテラシーが成果を左右する
自治体でAI活用を進めるうえで、職員研修は不可欠です。AIは便利な一方で、誤った情報をもっともらしく出力することがあります。また、入力してはいけない情報を職員が理解していなければ、情報管理上の問題が発生する可能性があります。
研修では、単にプロンプトの書き方を教えるだけでは足りません。少なくとも、次のような内容を含める必要があります。
| 研修テーマ | 内容 |
|---|---|
| 生成AIの基本理解 | AIができること、できないこと、誤回答の可能性 |
| 入力ルール | 個人情報、機密情報、未公開資料の扱い |
| 出力確認 | 根拠確認、事実確認、最終責任は人が負うこと |
| 業務別活用 | 文書作成、要約、FAQ、議事録、照会対応など |
| 管理職向け研修 | 利用方針、承認ルール、リスク管理 |
AIを使う職員だけでなく、判断する管理職、情報政策部門、法務・文書管理部門も含めた研修設計が求められます。
OSS活用には保守体制が必要
OSSは無償で利用できる部分がある一方、運用に責任を持つ体制が必要です。ソースコードを利用できても、障害対応、セキュリティアップデート、脆弱性管理、ログ監視、問い合わせ対応を誰が担うのかを決めなければなりません。
源内のGitHubリポジトリでも、Issue対応はサービスの安定運用に影響する致命的な問題に限定され、Pull Requestは受け付けていないとされています。
自治体がOSSを参考にする場合は、庁内で内製するのか、外部事業者に構築・保守を委託するのか、共同利用型の仕組みを検討するのかを整理する必要があります。
セキュリティとガバナンスの設計
入力してよい情報・いけない情報を明確にする
自治体の生成AI活用で最も注意すべきなのは、情報の扱いです。公開済み情報、匿名化された統計データ、庁内で共有可能な一般資料であれば活用しやすい一方、住民の氏名・住所、相談記録、税情報、福祉情報、未公開の政策資料などは慎重な取り扱いが必要です。
導入前には、情報を次のように区分しておくと実務に落とし込みやすくなります。
| 情報区分 | AI入力の考え方 |
|---|---|
| 公開済み情報 | 入力可能な場合が多い |
| 匿名化済み統計 | 個人が特定されない形なら活用しやすい |
| 庁内共有資料 | 機密性に応じて要判断 |
| 個人情報 | 原則として入力不可または厳格な制限 |
| 未公開政策資料 | 取扱権限と公開前情報の管理が必要 |
| 他機関からの照会文書 | 相手方の許可や目的外利用に注意 |
重要なのは、職員個人の判断に任せないことです。入力禁止情報リスト、利用可能な業務範囲、確認手順を文書化し、継続的に更新する必要があります。
ログ管理と説明責任を確保する
行政でAIを利用する場合、あとから利用状況を確認できることも重要です。誰が、いつ、どの業務でAIを使ったのか。どのような出力を得て、それをどのように人が確認したのか。こうした記録がなければ、問題が起きたときに原因を確認できません。
AIの出力は、あくまで判断材料です。最終的な行政判断や住民への回答責任は、人間と組織が負います。その前提を明確にしたうえで、ログ管理、監査、権限管理、承認フローを整えることが、自治体AI活用の信頼性を支えます。
自治体が取り組むべき導入ロードマップ
第1段階：現状業務と課題の棚卸し
最初に行うべきことは、AIツールの比較ではありません。どの部署で、どの業務に時間がかかっているのか、どの文書が属人化しているのか、どの問い合わせが繰り返されているのかを把握することです。
AI導入の目的が曖昧なままでは、使われないシステムになってしまいます。住民対応の迅速化、文書作成時間の短縮、庁内FAQの整備、議会答弁準備の効率化など、具体的な利用場面を絞ることが重要です。
第2段階：データ整備と入力ルールの作成
次に、AIに参照させる文書を整理します。古い資料、重複資料、部署ごとに表現が異なる資料が混在していると、AIの回答品質が安定しません。
同時に、入力禁止情報リスト、利用可能な文書、回答確認ルールを作成します。この段階を飛ばしてAIを導入すると、情報管理上の不安から職員が使えない、または逆に危険な使い方が広がる可能性があります。
第3段階：小さな業務で試行する
導入初期は、全庁展開を急がず、リスクが低く効果を測りやすい業務から試行するのが現実的です。たとえば、公開情報に基づくFAQ案作成、庁内研修資料の要約、会議メモの整理、広報文のたたき台作成などが考えられます。
試行段階では、利用件数だけでなく、作業時間の変化、職員の負担感、出力修正の手間、誤回答の傾向を確認します。
第4段階：全庁展開に向けた運用体制を整える
一定の効果が見えたら、対象部署を広げます。その際には、情報政策部門だけでなく、総務、人事、企画、法務、各業務部門が関与する推進体制が必要です。
AIは導入して終わりではありません。モデルの変更、業務ルールの更新、文書データの追加、職員研修の見直しを継続することで、初めて行政実務に定着します。
まとめ：源内OSSは自治体AI活用の「完成品」ではなく「設計図」である
ガバメントAI「源内」のOSS公開は、自治体にとって大きな参考材料です。行政機関が生成AIを安全に活用するための考え方、業務特化AIアプリの構成、チーム管理、外部連携、監視・運用機能など、実務に近い形で学べる点に価値があります。
一方で、自治体がそのまま導入すれば成果が出るわけではありません。必要なのは、業務の棚卸し、データ整備、情報入力ルール、職員研修、権限管理、ログ管理、保守体制を含めた総合的な設計です。
生成AIは、自治体職員の仕事を置き換えるものではなく、複雑化する行政実務を支える補助線です。源内OSSをきっかけに、自治体は「どのAIを使うか」だけでなく、「どのような行政運営を目指すのか」を改めて考える必要があります。
今後は、自治体単独でAI基盤を構築するだけでなく、複数自治体による共同利用、地域のIT企業との連携、庁内FAQや文書管理との接続、国産LLMの活用なども重要な検討テーマになります。源内OSSは、その第一歩として、自治体のAI活用を実務段階へ進めるための有力な材料になるでしょう。
コメント