自治体の業務端末、LGWAN接続系、ガバメントクラウド、外部の生成AI基盤を、どの経路で接続するのか。さらに、誰がどのデータを入力できるのか、出力結果を誰が確認するのかまで含めて設計する必要があります。
とくに自治体では、住民の個人情報、税・福祉・子育てに関する情報、公開前の政策情報など、慎重な取り扱いが求められるデータを扱います。そのため、一般企業と同じ感覚でパブリッククラウド上の生成AIへ接続することはできません。
本記事では、ガバメントクラウドと自治体向け生成AI基盤の関係を整理したうえで、代表的な4つの接続モデルと選定基準、安全に導入するための実務手順を解説します。
ガバメントクラウドと生成AI基盤は同じものではない
まず理解しておきたいのは、ガバメントクラウドと生成AI基盤は必ずしも同じものではないという点です。
ガバメントクラウドは、国や地方公共団体がクラウドサービスを共通的に利用するための環境です。クラウド技術を活用し、迅速性、柔軟性、セキュリティ、コスト効率を高めることを目的としています。デジタル庁「ガバメントクラウド」
一方、自治体向け生成AI基盤は、職員が文章作成、要約、検索、翻訳、照会対応などに生成AIを利用するための仕組みです。生成AIの画面だけでなく、次のような機能を含みます。
- 複数の生成AIモデルを呼び出す機能
- 庁内文書を検索するRAG
- 利用者の認証と権限管理
- 入力情報と出力内容のログ管理
- 個人情報や機密情報の検知・遮断
- 利用量や費用の管理
- 不適切な回答を制御するガードレール
したがって、検討すべき対象は「どの生成AIを使うか」だけではありません。自治体ネットワークから生成AI基盤までの通信経路、認証、データ保護、監査、運用責任を一体で設計する必要があります。
なぜ接続モデルの選択が重要なのか
接続モデルによって、安全性、利便性、費用、利用できる生成AIモデル、運用負担が大きく変わります。
通信経路を厳しく制限すれば安全性は高めやすくなりますが、利用できるサービスや機能が限られる可能性があります。反対に、パブリッククラウドへ直接接続すれば最新機能を利用しやすくなる一方、端末管理、アクセス制御、監視体制を自治体側で強化しなければなりません。
重要なのは、最も新しい方式を選ぶことではなく、自団体のネットワーク構成、職員体制、データの機密性、利用目的に合った方式を選ぶことです。
自治体向け生成AI基盤の4つの接続モデル
LGWAN-ASPを経由する閉域網接続モデル
現在の自治体が比較的導入しやすいのが、LGWAN-ASPを経由して生成AIサービスへ接続する方式です。
自治体のLGWAN接続系から閉域網を通り、LGWAN-ASP事業者のゲートウェイを経由して生成AIモデルのAPIを呼び出します。職員の端末からインターネットへ直接通信を出さない構成にできるため、従来のネットワークを大きく変更せずに導入しやすい点が特徴です。
メリット
- 既存のLGWAN接続系を活用しやすい
- インターネットへの直接接続を避けられる
- 自治体向けの入力制御やログ管理が用意されている
- 比較的小規模な自治体でも導入しやすい
注意点
- 利用できるAIモデルや機能が事業者の提供範囲に左右される
- 回線や中継基盤へのアクセス集中が応答速度に影響する
- データ保存場所や再学習の有無を契約で確認する必要がある
- サービス終了時のログや登録データの返却・消去条件が必要になる
まず文章要約や庁内文書の下書きから始めたい自治体には、現実的な選択肢です。
ローカルブレイクアウトによる限定接続モデル
ローカルブレイクアウトとは、LGWAN接続系の基本構成を維持しながら、特定のクラウドサービス向け通信だけを、許可された経路からインターネットへ直接接続する方式です。
生成AI基盤やMicrosoft 365など、業務上必要なサービスへの通信だけを識別し、庁内のプロキシサーバーなどを経由せず外部へ接続します。
ただし、単に特定のURLへの通信を許可するだけでは安全とはいえません。次のような制御が必要です。
- 自治体が契約したテナントだけに接続させる
- 職員の私用アカウントへのログインを禁止する
- 接続先のURLやドメインを限定する
- 職員ID、端末状態、所属、権限に基づいてアクセスを判断する
- 通信内容と利用履歴を監視する
クラウドサービスではIPアドレスが変動することがあるため、IPアドレスだけでなく、URL、ドメイン、アプリケーション、テナントを識別できる制御が重要になります。
向いている自治体
- 現在のLGWAN構成を大きく変更したくない
- 特定の生成AIサービスを低遅延で利用したい
- 接続先制限やテナント制御を運用できる
- 次世代ファイアウォールや監視基盤を整備できる
都道府県WAN・専用線を利用する共同利用モデル
複数の市区町村が、都道府県WANや共同の専用線を利用して、ガバメントクラウドや生成AI基盤へ接続する方式です。
回線やセキュリティ設備を個々の自治体が別々に整備するのではなく、都道府県や広域団体が共通基盤を構築します。小規模自治体にとっては、費用と専門人材の負担を分散できる点が大きな利点です。
メリット
- 回線費用や監視費用を共同化できる
- 専門人材を広域で確保しやすい
- セキュリティ対策を一定水準にそろえられる
- 共通の生成AIサービスを展開しやすい
注意点
- 参加自治体間でIPアドレスが重複する可能性がある
- 障害発生時の責任分界が複雑になる
- 利用ルールや費用負担の調整が必要になる
- 共通仕様が個別自治体の要望に対応できない場合がある
ネットワークを論理的に分離するVRFや、アドレスを変換するNATなどを用いて、自治体ごとの通信と権限を分離する設計が必要です。
パブリッククラウド直結モデル
業務端末をインターネット接続系に配置し、専用線やVPNを使用して、ガバメントクラウドまたは生成AI基盤へ直接接続する方式です。
クラウド事業者が提供する最新の生成AI、RAG、データ分析、API連携などを柔軟に利用できます。その反面、端末がインターネット側に置かれるため、自治体が主体となってゼロトラスト型の多層防御を構築しなければなりません。
必要となる主な対策
- 多要素認証
- 端末の暗号化とEDR
- ID・端末・場所に応じたアクセス制御
- CASBやSASEによるクラウド利用監視
- DLPによる個人情報・機密情報の流出防止
- SOCによる継続監視
- 操作ログと管理者ログの集中管理
自由度は高いものの、専門人材、予算、運用体制を確保できる自治体向けの方式です。
4つの接続モデルを比較する
| 接続モデル | 導入しやすさ | AI機能の自由度 | 自治体側の運用負担 | 主な適用場面 |
|---|---|---|---|---|
| LGWAN-ASP経由 | 高い | 中程度 | 比較的小さい | 小規模導入、文章作成、要約 |
| ローカルブレイクアウト | 中程度 | 比較的高い | 中程度 | 特定SaaS・生成AIの本格利用 |
| 都道府県WAN共同利用 | 調整が必要 | 中程度 | 広域で分担 | 複数自治体による共同導入 |
| パブリッククラウド直結 | 低め | 高い | 大きい | 高度なRAG、データ連携、AIエージェント |
この比較は一般的な傾向です。最終的な安全性や運用負担は、利用サービスと実際のネットワーク設計によって変わります。
接続経路だけでは守れない生成AI特有のリスク
安全な回線を利用していても、職員が個人情報を入力したり、AIが誤った回答を出したりするリスクは残ります。
そのため、ネットワークセキュリティと生成AIガバナンスを分けて考えてはいけません。
入力データを分類する
生成AIへ入力できる情報を、少なくとも次のように分類します。
- 公開情報
- 庁内限りの情報
- 個人情報を含む情報
- 機密性の高い行政情報
- 法令や契約により外部提供が制限される情報
情報区分ごとに、利用できるAIサービス、入力方法、人による確認、ログ保存期間を定めます。
AIによる学習利用を停止する
入力データがAIモデルの学習やサービス改善に使われない契約・設定を確認します。
「学習に使わない」という説明だけで判断せず、会話履歴の保存期間、運用担当者による閲覧可能性、国外移転、バックアップからの消去なども確認が必要です。
AI用のガードレールを設ける
生成AIには、通常のWeb通信とは異なる攻撃があります。代表例が、入力文によってAIの制御を回避しようとするプロンプトインジェクションです。
AI用の防御機能には、次のような役割が求められます。
- 不正な指示の検知
- 個人情報や機密情報のマスキング
- 危険・差別的な出力の制御
- RAGから取得した文書の権限確認
- 入力と出力の監査ログ保存
- 脆弱性や不正利用の継続的な診断
認証と権限管理を共通化する
複数の生成AIツールを部署ごとに導入すると、職員がサービスごとにIDとパスワードを持つことになり、退職者アカウントの削除漏れやパスワードの使い回しが発生しやすくなります。
自治体の統合認証基盤と生成AIサービスをSSOで接続し、異動、休職、退職に合わせて権限を一元的に変更できるようにします。
さらに、単にログインできるかだけでなく、所属部署、職務、扱う情報、端末の安全性に応じて、利用できるAIモデルと機能を制御することが重要です。
RAGでは文書ごとの閲覧権限を引き継ぐ
自治体独自の条例、要綱、マニュアル、議事録、FAQを生成AIから検索できるようにする場合、RAGが有効です。
ただし、文書を一つのデータベースへまとめるだけでは、もともと閲覧権限のない職員に情報が表示される危険があります。
RAGを構築するときは、次の情報を文書単位で管理します。
- 所管部署
- 公開区分
- 閲覧可能な役職・職種
- 適用開始日と失効日
- 根拠となる法令・規程
- 文書の更新責任者
回答には、参照した文書名、該当箇所、更新日を表示し、職員が根拠を確認できるようにします。
接続モデルを選ぶための5つの判断軸
自治体が接続方式を比較するときは、次の5点を整理します。
1．利用業務
文章作成だけなのか、庁内文書検索、住民対応、基幹システムとの連携まで行うのかを明確にします。
2．取り扱う情報
公開情報だけを使うのか、個人情報や機密情報を扱うのかによって必要な安全対策が変わります。
3．求めるAI機能
一つの生成AIモデルで足りるのか、用途に応じて複数モデルを使い分けるのかを決めます。
4．運用できる人材
ネットワーク、クラウド、生成AI、セキュリティを継続的に管理できる体制があるかを確認します。
5．総保有コスト
サービス利用料だけでなく、回線、監視、認証、ログ保管、職員研修、障害対応まで含めて比較します。
自治体が進める導入手順
ステップ1：対象業務を限定する
最初から全庁導入を目指さず、議事録の要約、通知文の下書き、FAQ検索など、効果とリスクを評価しやすい業務を選びます。
ステップ2：情報資産を分類する
対象業務で扱う文書とデータを洗い出し、生成AIへの入力可否を決めます。
ステップ3：現行ネットワークを可視化する
業務端末がどのネットワークにあり、どの認証基盤とプロキシを利用しているかを整理します。
ステップ4：接続モデルを比較する
安全性だけでなく、応答速度、拡張性、運用負担、共同利用の可能性を比較します。
ステップ5：小規模な実証を行う
実データを無条件で使うのではなく、匿名化したデータや公開情報を用いて、回答精度、処理時間、操作性、ログ取得状況を確認します。
ステップ6：運用ルールと技術制御を連動させる
「個人情報を入力しない」という注意書きだけに頼らず、DLP、入力フィルター、権限制御によってシステム側でも防止します。
ステップ7：段階的に対象業務を拡大する
実証結果を評価し、利用部署や接続データを段階的に増やします。重要な判断では、必ず職員が内容を確認するHuman-in-the-Loopを維持します。
調達仕様書に盛り込みたい項目
生成AI基盤の調達では、次の項目を事業者へ明示します。
- データの保存場所と保存期間
- 入力データの学習利用の有無
- 契約終了時のデータ消去方法
- 通信経路と暗号化方式
- SSO・多要素認証への対応
- 利用者、管理者、APIの操作ログ
- 個人情報・機密情報の検知機能
- RAG文書のアクセス権限管理
- 障害・情報漏えい発生時の責任分界
- 利用できる生成AIモデルと変更手続き
- モデルごとの料金と上限設定
- 外部委託先・再委託先の管理
- サービス終了時の移行支援
デジタル庁は2026年6月、技術の進展やユースケースの拡大を反映した「行政の進化と革新のための生成AIの調達・利活用に係るガイドライン第2.0版」を公表しています。自治体が調達要件を検討する際にも、リスク分類やガバナンス体制を考えるための重要な参考になります。デジタル庁「生成AIの調達・利活用ガイドライン第2.0版」
ガバメントAI「源内」から自治体が学べること
デジタル庁は、政府職員向け生成AI利用環境であるガバメントAI「源内」を構築し、2026年度には全府省庁の約18万人を対象とする大規模実証を進めています。デジタル庁「ガバメントAI 源内」
また、「源内」の一部は商用利用可能なライセンスでOSSとして公開されています。自治体や事業者にとっては、行政向け生成AIの画面、API連携、RAG、アプリケーション構成を検討する際の参考になります。デジタル庁「源内のOSS公開」
ただし、OSSを導入すれば安全な生成AI基盤が完成するわけではありません。接続経路、認証、データ管理、監視、責任分界を自治体の環境に合わせて実装する必要があります。
まとめ
ガバメントクラウドと自治体向け生成AI基盤の接続には、主に次の4方式があります。
- LGWAN-ASPを経由する閉域網接続
- ローカルブレイクアウトによる限定接続
- 都道府県WAN・専用線による共同利用
- パブリッククラウドへの直接接続
導入しやすさを重視するならLGWAN-ASP、既存環境を活用しながら特定サービスの利便性を高めるならローカルブレイクアウト、広域で費用と人材を共有するなら共同利用、高度なAI・データ連携を追求するならクラウド直結が候補になります。
ただし、接続経路を決めるだけでは安全な生成AI活用は実現しません。
データ分類、統合認証、入力・出力の監視、RAGの権限管理、ログ保存、人による確認、費用管理まで含めて設計することが重要です。
自治体が目指すべきなのは、最も高度な接続方式ではありません。自団体が継続して管理でき、職員が実務で使い続けられる接続モデルを選ぶことです。
コメント