自治体でローカルLLMを導入する現実解: LGWAN・オフライン・個人情報

なぜ自治体でクラウドLLMをそのまま使いにくいのか

多くの自治体のネットワークは、総務省の「三層の対策」と呼ばれる考え方に基づき、マイナンバー利用事務系・LGWAN接続系・インターネット接続系に分離されています。このうちLGWAN（総合行政ネットワーク）は、インターネットとは独立したクローズドな行政専用ネットワークで、外部のクラウドサービスへ直接アクセスできない環境で運用されている端末が多くあります。つまり、一般的なクラウドLLMのAPIをそのまま呼び出す、という前提が成り立たない現場が珍しくありません。

加えて、住民の個人情報を扱う業務では個人情報保護法や各自治体の条例に基づき、データの取り扱いに厳格なルールがあります。「便利だから」という理由だけで、住民データを含むプロンプトを外部のクラウドAPIに送る、という選択は多くの場合できません。

ローカルLLMという選択肢

こうした制約のもとでLLMを活用する現実的な選択肢のひとつが、モデルを外部に一切送信しないローカルLLMです。自庁内、もしくは閉域網内のサーバーでモデルを動かし、推論結果もその中で完結させることで、「データが外に出ない」という要件を技術的に満たせます。

ただし「ローカルで動かせば何でも解決する」わけではありません。モデルの導入・運用にも別の課題があり、それを踏まえた導入設計が必要です。

想定される導入パターン

現実的に検討しやすいのは、次のような「人が最終確認する」ことを前提にした下書き支援の用途です。

• 例規集や過去の答弁・通知文など、庁内文書を対象にした検索・要約支援
• 会議録や議事メモの下書き作成支援
• 問い合わせ対応のFAQ回答案の下書き

いずれも、AIの出力をそのまま公開・送付するのではなく、職員が内容を確認したうえで最終判断する運用が前提になります。

導入のハードル

ローカルLLMの導入では、次のような点が実務上のハードルになりやすいと考えられます。

• ハードウェアの調達: 庁内のIT調達フローに則ったGPUサーバーの選定・予算化が必要です。
• 運用・保守体制: インターネットから切り離された環境でのモデル更新やトラブル対応など、平常時とは異なる運用ノウハウが必要です。
• 職員のリテラシー: 「AIの出力を鵜呑みにしない」という前提を、使う職員全体で共有する必要があります。
• 説明責任・トレーサビリティ: AIが下書きを作成した文書について、最終的に誰がどう確認して公開・使用したかを追跡できる運用ルールが求められます。

判断基準（現実解の考え方）

いきなり全庁展開を目指すのではなく、次のような段階を踏むのが現実的です。

1. 個人情報を含まない業務からパイロット導入する（例規検索、内部文書の要約など）
2. AIの出力は必ず人が確認する運用を前提にする（下書き・たたき台としての位置づけ）
3. 効果とリスクを検証してから、扱う業務範囲を段階的に広げる

「オフラインで動く」という技術的な条件を満たすことと、「実際に安全に運用できる」ことの間には、こうした運用設計のステップが必要です。

実際の自治体案件での導入検証結果は、公開できる範囲が整い次第この記事に追記します。なお、オンプレミス環境でのLLM応答速度・VRAM使用量の実測データ（量子化レベル別）は「ollamaで社内オフラインLLM運用」に掲載しています。

まとめ

自治体でのローカルLLM活用は、LGWANのようなネットワーク構成や個人情報保護の制約を踏まえると、「クラウドLLMをそのまま使う」より一段ハードルが上がります。現実的な解決策は、ローカル環境での実行という技術的な対策に加えて、個人情報を含まない業務からのパイロット導入と、AIの出力を必ず人が確認する運用設計を組み合わせることです。