はじめに
自治体の基幹業務システムがガバメントクラウドへ移行するなか、次の検討課題として浮上しているのが、庁内で利用する生成AI基盤との接続である。
ガバメントクラウドは、迅速性、柔軟性、セキュリティ、コスト効率を備えた政府共通のクラウド利用環境として整備されている。地方公共団体でも、標準準拠システムの移行とともに、その活用が進められている。
一方、ガバメントクラウド上のシステムと生成AIを接続すれば、自動的に安全な行政AIが完成するわけではない。生成AIへ送信するデータの範囲、通信経路、認証、ログ、モデル事業者によるデータ利用、RAGが参照する文書などを個別に設計する必要がある。
本記事では、ガバメントクラウドと自治体向け生成AI基盤を接続する方法を3つのモデルに整理し、それぞれの特徴と導入判断のポイントを解説する。
※本記事の3モデルは、国が定めた公式な標準分類ではなく、自治体が比較検討しやすいように整理した実務上の分類である。
ガバメントクラウドと生成AI基盤の接続が課題になる理由
地方公共団体の基幹業務システム標準化では、住民基本台帳、税、福祉、介護保険、国民健康保険など、20の標準化対象事務が定められている。デジタル庁は、ガバメントクラウドへの移行によって、セキュリティの高度化、災害対策、運用負担の軽減、行政サービスの迅速な提供などを目指している。
しかし、これらの基幹業務には、住民の個人情報や要配慮個人情報など、機密性の高い情報が含まれる。生成AIに入力したデータがどこへ送信され、どの地域に保存され、誰が閲覧でき、モデル学習に使われる可能性があるのかを確認しなければならない。
さらに、自治体のネットワークは一般に、次の領域に分けて管理されている。
- マイナンバー利用事務系
- LGWAN接続系
- インターネット接続系
生成AIサービスの多くはインターネット上のクラウドサービスとして提供される。このため、LGWAN接続系の業務端末から安全に利用するには、無害化、アクセス制御、入力制御、ログ管理などを備えた中継環境が必要になる。
接続設計では「通信できるか」だけでなく、「どの情報を、誰が、何の目的で、どのAI機能へ送信できるか」まで定義しなければならない。
自治体向け生成AI基盤の3つの接続モデル
モデルA：LGWAN・セキュアゲートウェイ経由型
現在の自治体にとって導入しやすいのが、LGWAN接続系からセキュアゲートウェイを経由して生成AIを利用するモデルである。
職員がLGWAN接続端末から入力した文章は、ゲートウェイ上で禁止語句の検査、個人情報の検知、マスキング、ログ記録などの処理を受ける。その後、許可されたAPIを通じて外部の生成AIサービスへ送信される。
LGWAN-ASP型の自治体向け生成AIサービスも、この考え方に近い。
適している業務
- 文案の作成
- 議事録や文章の要約
- 庁内通知の校正
- アイデア出し
- FAQ検索
- 公開情報を使った問い合わせ対応支援
メリット
既存のLGWAN接続端末から利用しやすく、基幹業務システムへ大幅な改修を加えずに導入できる。生成AIへの入力制御をゲートウェイに集約しやすい点も利点である。
注意点
ゲートウェイが存在するだけでは安全性は担保されない。個人情報の検知精度、誤送信時の遮断、ログの保存範囲、生成AI事業者によるデータの二次利用条件を確認する必要がある。
また、このモデルは職員の入力支援には向いているが、基幹業務システムとのリアルタイムなデータ連携には制約がある。
モデルB：ガバメントクラウド内API連携型
ガバメントクラウド上の業務システムと生成AI機能を、APIによって連携させるモデルである。
生成AIサービスやRAG基盤を同一のクラウド環境、または接続可能なクラウド領域に配置し、APIゲートウェイ、プライベート接続、アクセス制御などを使って通信する。
ガバメントクラウド上の異なるCSPや共通サービスを接続する仕組みとして、デジタル庁は「GCAS Connect」の利用ガイドを公開している。ただし、GCAS Connectはネットワーク接続を支援する仕組みであり、それだけで生成AIの情報管理要件が満たされるわけではない。
適している業務
- 申請内容の分類
- 文書の自動要約
- 庁内FAQへの回答
- 過去文書や例規の検索
- 職員向け業務支援
- 定型文書の下書き生成
メリット
データをインターネット上へ広く露出させず、システム間の通信経路を制御しやすい。職員によるコピー・貼り付けを減らし、業務フローの中に生成AIを組み込める。
APIを介して処理内容を標準化することで、入力データ、利用モデル、回答形式、ログの保存などをシステム側で統制できる。
注意点
基幹システムのデータを、そのまま生成AIへ送ってはならない。AIへ渡す前に、必要項目の抽出、匿名化、仮名化、不要項目の削除を行う中間処理層が必要である。
また、VPC間接続やプライベートエンドポイントを利用しても、アクセス権限の設定ミスやAPIキーの漏えいを防げるわけではない。認証、権限、暗号鍵、監視を含む全体設計が求められる。
モデルC：共同利用型・データ主権重視型
都道府県と市町村、複数自治体、地域の支援機関などが、生成AI基盤を共同で利用するモデルである。
国内データセンター、国内リージョン、専用環境、管理可能なLLMなどを採用し、データの保管場所や運用主体を明確にする。地域の共通業務に対応したプロンプト、FAQ、RAG用文書を共同整備する構成も考えられる。
適している業務
- 複数自治体に共通する問い合わせ対応
- 条例、規則、要綱の検索
- 防災情報や地域情報の整理
- 小規模自治体向けの共通AI環境
- 都道府県による市町村支援
メリット
単独ではAI人材や予算を確保しにくい小規模自治体でも、共同調達や共通運用によって生成AIを利用しやすくなる。入力ルール、監査、教育、RAGデータの整備も共同化できる。
注意点
国内にデータを保存するだけで、安全性が確保されるわけではない。運用事業者のアクセス権限、障害時の対応、再委託先、モデル更新、契約終了時のデータ消去まで確認する必要がある。
共同利用では、参加自治体ごとのデータが混在しないテナント分離と、自治体ごとに異なる条例・規則を誤って参照しないための検索範囲制御が重要になる。
3つの接続モデルの比較
| 接続モデル | 主な用途 | 導入しやすさ | システム連携 | 主な注意点 |
|---|---|---|---|---|
| LGWAN・ゲートウェイ経由型 | 文案作成、要約、FAQ | 高い | 限定的 | 入力制御、マスキング、ログ |
| ガバメントクラウド内API連携型 | RAG、業務処理支援 | 中程度 | 高い | API認証、権限分離、データ最小化 |
| 共同利用・データ主権重視型 | 複数自治体の共通業務 | 中程度 | 構成による | テナント分離、運用主体、出口戦略 |
自治体が最初から一つのモデルに統一する必要はない。一般的な文書作成はモデルA、業務システムと連携するRAGはモデルB、小規模自治体の共通基盤はモデルCというように、業務ごとに使い分ける考え方が現実的である。
接続前に確認すべき7つの設計要件
1．情報区分と利用可能業務
最初に、生成AIへ入力できる情報と入力できない情報を定義する。
少なくとも、公開情報、庁内情報、個人情報、要配慮個人情報、特定個人情報、機密情報を区分し、業務ごとの利用可否を整理する必要がある。
2．認証と最小権限
職員IDと生成AIの利用者情報を連携し、所属、役職、担当業務に応じて利用できる機能やRAGの検索範囲を制限する。
共有IDの使用は避け、管理者権限、文書登録権限、一般利用権限を分離することが重要である。
3．APIとネットワーク経路
許可されたAPI以外への通信を遮断し、APIゲートウェイで認証、通信量制御、送信先制限、異常検知を行う。
GCAS Connectや閉域接続を利用する場合も、接続先、経路、障害時の切り分け、監視責任を明確にする。
4．ログと監査証跡
誰が、いつ、どの機能を利用し、どのデータへアクセスしたかを確認できるログを残す。
一方で、プロンプトや回答を無条件に保存すると、ログ自体が個人情報や機密情報の保管場所になる。保存対象、保存期間、閲覧権限、削除方法を事前に決めなければならない。
5．RAGの参照範囲と文書鮮度
RAGでは、回答精度だけでなく、参照文書の正しさが重要である。
文書の所管部署、施行日、有効期限、改訂履歴をメタデータとして管理し、廃止済みの要綱や古い手続資料を検索対象から除外する。回答には根拠となった文書名や該当箇所を表示させる。
6．人による確認
生成AIの回答を、そのまま行政判断や住民向け回答として確定させない。最終判断を行う職員と、確認が必要な業務を明文化する。
特に、給付、課税、福祉、許認可など、住民の権利や利益に影響する業務では、Human-in-the-Loopを前提とした設計が必要である。
7．契約終了時の出口戦略
サービス終了や事業者変更に備え、プロンプト、RAG文書、ベクトルデータ、ログ、評価データを移行可能な形式で取り出せるか確認する。
データ消去証明、バックアップの削除、モデル変更時の再評価についても契約に含める必要がある。
責任分界を契約書と運用表に落とし込む
ガバメントクラウドでは、デジタル庁、自治体、CSP、ASP、運用管理補助者など、複数の主体が関与する。生成AI基盤を加える場合は、AI事業者、RAG構築事業者、回線事業者も含めた責任分界が必要になる。
| 主体 | 主な責任 |
|---|---|
| 自治体 | 利用目的、情報区分、利用者権限、最終判断 |
| AIサービス事業者 | モデル提供、データ処理条件、障害・脆弱性対応 |
| RAG構築事業者 | 文書登録、検索制御、根拠表示、文書更新 |
| CSP・基盤事業者 | クラウド基盤、可用性、基盤側セキュリティ |
| 運用管理補助者 | 設定、監視、バックアップ、インシデント対応 |
| 回線事業者 | 通信経路、帯域、冗長化、回線障害対応 |
「クラウド事業者が守る範囲」と「自治体が設定・監督する範囲」は異なる。調達仕様書だけでなく、運用手順書、障害対応表、連絡体制表にも責任分界を反映させることが重要である。
自治体が進める段階的な導入手順
第1段階：個人情報を扱わない業務から始める
公開情報を使った文章作成、要約、アイデア出しなどから開始し、利用ルールと研修を整備する。
第2段階：庁内文書を使ったRAGを構築する
庁内FAQ、マニュアル、規程などを対象に、アクセス制御と根拠表示を備えたRAGを構築する。文書の鮮度管理も同時に設計する。
第3段階：業務システムとのAPI連携を検証する
利用目的と効果が明確な業務に限定し、個人情報の除去や項目最小化を行ったうえでAPI連携を検証する。
第4段階：監査結果を基に対象業務を拡大する
回答精度だけでなく、誤入力、権限違反、ログ、職員の確認状況、業務時間の変化を評価し、利用範囲を段階的に広げる。
JAICが考える自治体生成AI導入の重要点
自治体向け生成AIでは、製品を選ぶ前に「どの業務を、どの情報で、どこまで支援させるか」を決める必要がある。
高機能な生成AIを導入しても、文書が整理されていなければRAGの回答精度は上がらない。接続経路が安全でも、職員が個人情報を入力すればリスクは残る。ログを取得しても、誰も確認しなければ監査機能は働かない。
必要なのは、ネットワーク、情報管理、業務設計、職員研修を別々に進めるのではなく、一つの運用モデルとして整備することである。
JAICでは、自治体の既存環境や規模に応じて、利用業務の選定、情報区分、生成AI利用ルール、RAG文書整理、職員研修までを一体的に検討することが重要だと考えている。
まとめ
ガバメントクラウドと自治体向け生成AI基盤の接続には、主に次の3つの考え方がある。
- LGWAN・セキュアゲートウェイ経由型
- ガバメントクラウド内API連携型
- 共同利用・データ主権重視型
接続モデルは、技術の新しさではなく、扱う情報、対象業務、システム連携の深さ、自治体の運用能力によって選ぶべきである。
また、ガバメントクラウドや閉域接続を利用していることだけを、安全性の根拠にしてはならない。情報区分、認証、API制御、ログ、RAGの参照範囲、責任分界、人による確認を一体として設計する必要がある。
自治体生成AIの本格活用は、単なるチャットツールの導入ではない。行政情報を安全に流通させ、職員が根拠を確認しながら利用できる、新しい行政情報基盤を構築する取り組みなのである。
コメント