自治体の生成AIは「どの情報を」「どこのサーバで」処理してよいのか— 機密性区分とリージョンを、最新の総務省ガイドライン・ガイドブックから読み直す

自治体で生成AIの話をすると、必ず二つの質問に行き着きます。

「この情報、AIに入れていいんですか？」 「そのAI、どこの国のサーバで動いてるんですか？」

現場ではこの二つが別々の担当者から別々のタイミングで飛んでくるのですが、公表資料を読み込むと、実は一本の線でつながっています。この一年で参照すべき文書もかなり整備されました。この記事では、最新版をベースに、この二つの論点を実務者目線で整理します。所属団体が特定される記述は避け、一般化した形で書いています。

いま参照すべき文書はどれか

まず、手元に置くべき資料が更新されています。

文書	版・時点	位置づけ
地方公共団体における情報セキュリティポリシーに関するガイドライン（総務省）	令和8年3月27日改定	自治体のポリシーの土台。クラウド利用のルールはここ
自治体におけるAI活用・導入ガイドブック＜導入手順編＞（総務省）	令和7年12月・第4版	生成AIの章が新設。職員向け利用ガイドラインのひな形が別添
行政の進化と革新のための生成AIの調達・利活用に係るガイドライン（デジタル庁）	2.0版・令和8年6月／2.0版の内容は令和8年9月1日施行	政府側のルール。自治体の考え方もこれと整合をとる建付け
AIのセキュリティ確保のための技術的対策に係るガイドライン（総務省）	令和8年3月	LLMを含むAIシステムへの技術的な脅威と対策例
AI事業者ガイドライン（総務省・経済産業省）	第1.2版・令和8年3月31日	AI利活用の共通指針

ガイドブック第4版は、令和7年7月の「自治体におけるAIの利用に関するワーキンググループ報告書」を反映したもので、生成AIの利用方法、ガバナンス体制、要機密情報の取扱い、人材育成が新たに柱として加わりました。現場で最初に読むべきはこれです。

1. 機密性区分と、使えるクラウドの範囲

出発点は情報の格付けです。国の統一基準では機密性1〜3の3段階ですが、自治体側はこれを5段階に細分化しています。ガイドブック第4版は、区分ごとに利用できるパブリッククラウドの範囲を次のように整理しています。

区分	パブリッククラウドサービスの範囲
自治体機密性3A	「行政文書の管理に関するガイドライン」と統一基準に則って取り扱う。極秘文書はインターネットに接続していない電子計算機や媒体等への保存が求められる
自治体機密性3B	ISMAP登録サービスは利用可。8.3で規定されるアクセス制御・暗号化等が必要。加えて第4編（クラウド利用等に関する特則）の追加の対策基準等が必要
自治体機密性3C	同上。ただし情報資産単位のアクセス制御・業務システムログ管理等、β’モデルでインターネット接続系に求められる対策を実施すれば、インターネット接続系での取扱いも可能
自治体機密性2	可（アクセス制御・暗号化等が必要）。ただし画一的な約款等への同意のみで利用可能となるクラウドサービスでは自治体機密性2以上を取り扱えない
自治体機密性1	可

3Bは住民記録・税・国保・生活保護などのシステムに保存される住民の個人情報、3Cは職員の属性に基づく個人情報や文書管理システム上の決裁文書に含まれる個人情報、入札予定価格などの非公開情報です。

実務上の肝は、同じ「個人情報」でも3Bと3Cで求められる対策が違うことです。「個人情報だから一律ダメ」という運用は、この区分をまるごと潰してしまっています。

2. 「約款型は原則ダメ」の本当の意味

表の中でいちばん引用される一節が、機密性2の行にある但し書きです。

セキュリティポリシーガイドライン8.3の解説は、その理由をはっきり書いています。不特定多数の利用者に画一的な約款や規約への同意だけで提供されるクラウドサービスでは、セキュリティ対策やデータの取扱いについて自組織への特別な扱いを求められない場合が多く、必要十分なセキュリティ要件を満たすことが一般的に困難だから、というものです。

つまり、禁止されているのは「生成AI」ではなく「条件交渉ができない契約形態」です。裏を返せば、個別契約で条件を詰められる非約款型なら、話は変わります。政府側でも、非約款型については所定の手続を経たうえで一部の機密性2情報まで扱える整理が続いてきました。「生成AIに機密性2は絶対禁止」は、正確な理解ではありません。

3. リージョンが問われる四つの理由

ここからが本題です。「どこのサーバか」が問われる根拠は、ガイドライン上、少なくとも四か所に散らばっています。

(1) 選定条件・セキュリティ要件として明記されている

8.3(3)⑤は、国内法以外の法令・規制が適用されるリスクを評価してクラウドサービス提供者を選定し、必要に応じて情報が取り扱われる場所と契約に定める準拠法・裁判管轄を選定条件に含めなければならないとしています。

さらに8.3(3)⑧(イ)では、セキュリティ要件として**「クラウドサービスで取り扱う情報が保存される国・地域及び廃棄の方法」**を定めなければならないとされています。

リージョンは「気にしたほうがよい事項」ではなく、要件として書くべき事項として明記されている。ここが出発点です。

(2) 委託判断基準として、外国法執行機関のリスクが名指しされている

見落とされがちですが、8.1（業務委託）の解説がかなり踏み込んでいます。委託業務で取り扱う情報に国外の法令等が適用される場合、国内であれば不適切と判断されるアクセス等が行われる可能性がある、と述べたうえで、令状主義や透明性の確保、不利益処分に関する手続といった適切かつ透明性のある手続に則らない形で、外国の法執行機関の命令によりデータセンター内のデータが強制的に開示されるリスクを具体例として挙げています。

海外モデルをAPIで利用する構成は、個人情報保護法上は取扱いの委託として整理されます。であれば、この委託判断基準がそのまま効いてくる。「国内リージョンか否か」をスイッチ一つで判断するより、委託先管理の枠組みに落とし込んで評価するほうが、実務としては応用が利きます。

(3) 機密情報を扱わない場合でも、リージョンは検討事項

ここは重要です。8.4は「自治体機密性2以上の情報を取り扱わない場合」のクラウド利用を規定していますが、その解説では、統括情報セキュリティ責任者が許可する業務の範囲を決める際に検討すべきリスクの例として、クラウドサービス提供者が海外のデータセンター等にサーバを設置している場合、当該サーバに保存されている情報に現地の法令等が適用され、現地の政府等による検閲や接収を受ける可能性があることを挙げています。

つまり、「機密情報を入れないから海外サービスでもいい」という論法は、ガイドラインの建付けとして成立しません。要機密情報を扱わない場合であっても、リージョンは利用可否判断の材料として残ります。

(4) DeepSeekの件は、この論点の実例

令和7年2月3日、個人情報保護委員会事務局から情報提供が出ています。DeepSeek社が提供する生成AIサービスを利用する場合、データが中華人民共和国に所在するサーバに保存され、中華人民共和国の法令が適用される、という内容です。ガイドブック第4版もこれを引用し、国外にサーバ装置を設置している場合は現地法令が適用され、現地の政府等による検閲や接収を受ける可能性に注意する必要がある、と改めて書いています。

論点は「モデルの性能」でも「事業者の善意」でもなく、データの物理的所在と、そこに及ぶ法域でした。リージョンの議論は、突き詰めるとこの一点に帰着します。

なお、内閣官房国家サイバー統括室の「クラウドを利用したシステム運用に関するガイダンス」も、国内外を問わずクラウド利用を検討する際の参照先としてガイドブックに挙げられています。

4. 個人情報を扱うときの確認項目

ガイドブック第4版には、個人情報を含むデータを生成AIで取り扱う際の留意事項が表で整理されています。三つの系統に分かれているのが分かりやすい。

情報セキュリティポリシーの観点

クラウドサービスの利用規定の整備等、組織全体でセキュリティ対策が講じられているか
業務に関わるシステム全体を通じて、ISMAP登録されたものなどセキュリティ対策が講じられているものか
サービス提供事業者の所在国やサーバの設置場所などを踏まえ、どの国の法令が適用されるか確認されているか

個人情報保護法の観点

生成AIへの入力それ自体で特定の個人が識別されるか
利用目的のための必要最小限の利用または提供に留まっているか
個人情報保護法上、本人同意が必要な取扱いか

生成AI特有のリスクの観点

学習データとならない仕様か
生成AIエンジンへ送られたデータの扱い

ガイドブックは、生成AI特有の配慮事項として**入力した要機密情報を学習させない仕組み（オプトアウトの徹底）**が重要だとし、利用するサービスの責任範囲を利用前に整理してリスク対応を検討する必要があるとしています。

5. 「個人情報だから全部ダメ」を、国が明確に否定した

第4版でいちばん大きいのは、たぶんここです。ガイドブックは、自治体業務が住民の個人情報を扱うことが多く丁寧かつ慎重な取扱いが求められると断ったうえで、こう書いています。

個人情報保護法上の提供元基準の下で、扱う情報が個人情報に該当するデータであるからといって、生成AIの利用を全て否定することは、職員の業務効率化や住民サービスの向上にとって必ずしもプラスとなりません。

提供元基準とは、外部に提供する際に提供部分単独では個人情報を成していなくても、提供元で他の情報と容易に照合でき特定の個人を識別できることとなる場合には、提供元に個人情報としての管理を求める考え方です。氏名を黒塗りしても、元データと容易照合可能なら個人情報である、という現場の悩みはここから来ています。

そのうえでガイドブックは、どの業務でどのような個人情報を入力し、その結果どう住民サービスの質の向上につながるのかを丁寧に説明していく姿勢を求め、技術の進展と国の検討状況を踏まえて自団体の情報セキュリティポリシーの見直しを含めた対応を検討することが望まれるとしています。

「国の動向を注視する」という定型句の内側で、実は国のほうが「見直しを検討してよい」と言っている構図です。

6. 実際に線を引いた団体はどうしたか

第4版には、入力データが学習されない市独自の生成AI利用環境において少数の個人情報の入力を可能とした事例が掲載されています。公表されている当該団体の利用ガイドラインを読むと、線の引き方が具体的です。

利用環境が安全であること、議事録の要約や相談記録表の作成など少数の個人情報を含む文章を扱う業務でも効率化が期待されることから、要配慮個人情報を含む保有個人情報の入力を認める
ただし大量の入力は想定しておらず、一連の処理で本人の数が1,000人以上となる個人情報の入力は禁止（複数回に分けた連続処理は合算）
特定個人情報（マイナンバーを含む）は、外部ネットワークと完全に切り離された環境が求められるため対象外

注目すべきは、「入れてよいか／だめか」の二値ではなく、環境の安全性・情報の種類・件数の規模という三つの軸で線を引いていることです。件数で上限を切る発想は、他団体でもそのまま応用できます。

7. 令和8年3月改定で、この部分は変わったか

セキュリティポリシーガイドラインは令和8年3月27日に改定されました。改定のポイントは四つです。

令和6年の地方自治法改正に伴い、令和7年4月1日付で発出された大臣指針案と記載内容が重複する箇所等を第1編総則から削除
機器の廃棄・データ消去について、マイナンバー利用事務系で住民情報を保存する記録媒体の物理的破壊に代わる方法を追加（リユース困難やコストの課題を踏まえたもの）、データ消去作業への職員立会いの範囲を明確化
USBメモリ等の利用におけるリスクへの対処を追記
DNS設定情報を悪用する攻撃等について追記

つまり、クラウド・生成AIに関する8.3／8.4の枠組み自体は動いていません。約款型では原則として自治体機密性2以上を扱えないという建付けも、保存される国・地域を要件として定めるという要求も、そのまま残っています。ここ一年で変わったのは規制ではなく、参照できる材料の量です。

8. 職員向けガイドラインのひな形が出た

第4版の別添として、自治体が作成する職員向け生成AI利用ガイドラインのひな形が示されました。デジタル庁の各省向けひな形をもとに、先行自治体のルールを参考にして作られたものです。ポイントは以下の通りです。

利用前に、情報政策担当課が指定する研修を必ず受講すること
担当課室から説明された利用方法（利用可能な業務の範囲、入力可能な情報を含む）、セキュリティ上の留意点、出力の精度とリスクの程度を理解すること
私用デバイスへ私的にインストールした生成AIに職務上知り得た情報を入力しないこと
利用目的に応じて求められる正確性の水準が異なることを意識し、出力結果を確認すること
安全性・公平性・客観性・中立性に問題がある表現は必ず加除修正すること
生成AI特有のリスクケースが発生した場合は所定の報告フォームで速やかに報告すること

令和6年12月末時点で、生成AI利用ガイドラインを未策定の団体は1,004、導入済みの573団体のうち97団体も未策定でした。ゼロから起案する必要はもうありません。

ガバナンス面では、自治体においてもAIの利活用・リスク管理の責任者を明確にする必要があるとされ、CAIOを置く場合はCIOとの兼務が多くなると想定したうえで、専門的知見から補佐するCAIO補佐官の設置、都道府県による人材確保・派遣や複数団体での共同設置といった現実的な選択肢が示されています。小規模団体の「誰が担うのか」問題への一定の回答です。

9. 実務チェックリスト

調達フェーズ

約款型か非約款型か（ここで扱える情報の上限がほぼ決まる）
推論が行われるリージョン、およびログ・入力データが保存される国・地域
契約上の準拠法と裁判管轄
入力データの学習利用の有無（設定上のオプトアウトではなく、契約上の不使用が望ましい）
データの保存期間と廃棄方法
再委託の有無と、再委託先に同等の条件が担保される仕組み
要機密情報を扱うなら、ISMAPクラウドサービスリスト等からの選定
事業者の資本関係・役員情報、従事者の所属・国籍に関する情報提供
中断・終了時に業務を移行するための対策

運用フェーズ

入力可能な情報の範囲を、機密性区分に紐づけて明文化する（「個人情報禁止」で止めない）
件数・規模の上限を検討する（何人分までなら許容するか）
個人情報らしき入力に対する警告・ブロック機能の設定
操作ログの取得と定期的な確認
研修受講を利用条件にする運用
AI利活用・リスク管理の責任者（CAIO相当）と補佐体制の明確化
用途ごとに求められる正確性の水準と、人の確認プロセスの設計
リスクケースの報告ルートの整備

10. それでも残る、いちばん難しい問い

技術要件を全部満たしても、最後に残るのは判断する人が判断してよいと確信を持てないという問題です。WGでも、国内処理・学習不使用・庁内サーバ上のRAGと万全の対策を講じていながら、機密性2以上を入れてよいか判断がつかないため禁止している、という団体の声が紹介されていました。

ただ、この一年で状況は変わりました。国は「個人情報に該当するからといって生成AIの利用を全て否定することはプラスにならない」と書き、自団体のセキュリティポリシーの見直しを含めた検討が望まれると書き、職員向けガイドラインのひな形まで配りました。判断材料が足りないという言い訳は、だいぶ使いにくくなっています。

WGの論点整理はこう書いていました。

生成AIにおいて要機密情報・個人情報を入力することに伴う流出リスクへの懸念や不安があることを理由にAIそのものの導入や利用の検討を行わないことは、行政効率化の機会を逃していると言えないか。

「リスクがあるから使わない」も「便利だから使う」も、どちらも判断の放棄です。必要なのは、扱う情報の区分ごとに技術要件と契約要件を対応させて線を引き、その線を説明できる状態にすること。自治体には住民監査請求制度があり、利用の正当性を説明する場面もあり得ます。説明できる根拠を持っているかどうかが、最終的な分かれ目になります。

まとめ

自治体の機密性区分は5段階。3Bと3Cで求められる対策は異なり、一律禁止は区分を活かしていない
禁止されているのは生成AIではなく、条件交渉ができない約款型という契約形態
リージョンは「保存される国・地域」として要件に書くべき事項。準拠法・裁判管轄とセットで評価する
ガイドラインは外国法執行機関による強制開示リスクを名指ししており、要機密情報を扱わない場合でもリージョンは検討事項として残る
令和8年3月改定でクラウド・生成AIの枠組み自体は変わっていない。変わったのは参照できる材料の量
国は「個人情報だから全部だめ」を明確に否定し、自団体ポリシーの見直し検討まで踏み込んだ
先行団体は、環境の安全性・情報の種類・件数の規模という三軸で線を引いている

参照資料

総務省「地方公共団体における情報セキュリティポリシーに関するガイドライン」（令和8年3月27日改定）、および「ガイドライン改定（令和8年3月）のポイントについて」
総務省「自治体におけるAI活用・導入ガイドブック＜導入手順編＞」（令和7年12月・第4版）、別添「生成AIシステム利用ガイドライン（ひな形）」
総務省「自治体におけるAIの利用に関するワーキンググループ」報告書（令和7年7月）および第4回事務局提出資料（令和7年5月）
総務省「AIのセキュリティ確保のための技術的対策に係るガイドライン」（令和8年3月）
総務省・経済産業省「AI事業者ガイドライン」（第1.2版・令和8年3月31日）
デジタル庁「行政の進化と革新のための生成AIの調達・利活用に係るガイドライン」2.0版（令和8年6月、2.0版の内容は令和8年9月1日施行）
個人情報保護委員会事務局「DeepSeekに関する情報提供」（令和7年2月3日）
内閣官房国家サイバー統括室「クラウドを利用したシステム運用に関するガイダンス」

※本記事は公表資料に基づく個人的な整理であり、所属団体の見解ではありません。