自治体職員向けの研修で、必ず出る質問があります。
「結局、何なら入れていいんですか」
民間向けの解説を読んでも答えが出ません。自治体は判断の出発点が違うからです。
業務で生成AIに情報を入れてよいかでは、個人情報・法令上の守秘義務・営業秘密・契約上の秘密保持義務という4つの枠組みで整理しました。自治体でもこの4つは効きますが、その前に情報セキュリティポリシーによる格付けがあります。
そして格付けの側が、先に答えを出してしまいます。
出発点は「個人情報かどうか」ではありません
総務省の「地方公共団体における情報セキュリティポリシーに関するガイドライン」（令和8年3月版）は、対策基準の 8.3 で自治体機密性2以上の情報を取り扱う場合の、8.4 で取り扱わない場合のクラウドサービスの利用ルールを分けて定めています。生成AIも、この枠組みの中で判断されます。
つまり実務の順序はこうなります。
その情報は、自団体の格付けで何に当たるか。 → その格付けで、そのサービスを使えるか。
個人情報保護法の話は、その後です。格付けの段階で結論が出てしまうことが多いためです。
自治体機密性の5区分
国の「政府機関等のサイバーセキュリティ対策のための統一基準」は情報を機密性1〜3の3段階に格付けしていますが、自治体は5区分になっています。
ガイドラインの図表（令和8年3月版の図表22）は、区分ごとに分類基準と情報資産の例を分けて示しています。ここは分けて読んでください。下の「例」は例示であって、これに載っていなければ違う区分になる、という意味ではありません。
| 区分 | 分類基準（要旨） | 情報資産の例（＜例＞欄） |
|---|---|---|
| 自治体機密性3A | 「行政文書の管理に関するガイドライン」に定める秘密文書に相当する文書 | 極秘文書（秘密保全の必要が高く、その漏えいが国の安全、利益に損害を与えるおそれのある情報を含む行政文書）、秘文書 |
| 自治体機密性3B | 漏えい等が生じた際に、個人の権利利益の侵害の度合いが大きく、事務又は業務の規模や性質上、取扱いに非常に留意すべき情報資産 | データベースや台帳形式になった住民情報を含む個人情報ファイル及びこれに準ずる情報（住民記録システム、税務システム、国民健康保険システム、生活保護システム、農業委員会台帳システム、貸付金償還システム等に保存される住民の個人情報） |
| 自治体機密性3C | 3B以上に相当する機密性は要しないが、基本的に公表することを前提としていないもので、業務の規模や性質上、取扱いに留意すべき情報資産 | 職員としての属性に基づく個人情報／オンライン申請の処理等により、システム処理上一時的にインターネット上に保管されるデータ／文書管理システムの決裁文書として保存されている個人情報／施設設計情報や入札予定価格など非公開情報 |
| 自治体機密性2 | 自治体機密性3に相当する機密性は要しないが、直ちに一般に公表することを前提としていない情報資産 | 政策検討に関する情報 |
| 自治体機密性1 | 自治体機密性2又は機密性3の情報資産以外の情報資産 | 将来公表する予定の文書（白書の案等）／公表された情報 |
判断の順は、分類基準が先です。 例に自分の資料が載っていないときは、基準の文言に当てて考えてください。
同じ個人情報でも、3Bと3Cで扱いが分かれます。 住民記録や税務システムの台帳情報（3B）と、職員の情報や決裁文書に含まれる個人情報（3C）は別の区分です。
なお、国の側では「個人情報は、不開示情報（個人に関する情報で特定の個人を識別できるもの等）に該当するため、機密性2情報となる」と整理されています。個人情報は、それだけで要機密情報です。
入札予定価格が3Cに入っている点も見落とされがちです。 個人情報ではありませんが、非公開情報として同じ区分に置かれています。
約款型のサービスには、機密性2以上を入れられません
ここが最も重要な原則です。ガイドライン 8.3 の【趣旨】は次のとおりです。
事業者等が不特定多数の利用者に対して提供する、画一的な約款や規約等への同意のみで利用可能となるクラウドサービス（ただし、電気通信サービスや郵便、運送サービス等は除く）では、セキュリティ対策やデータの取扱いなどについて自組織への特別な扱いを求めることができない場合が多く、自治体機密性2以上の情報を取り扱う上で必要十分なセキュリティ要件を満たすことが一般的に困難であることから、原則として自治体機密性2以上の情報を取り扱うことはできない
理由は「危ないから」ではありません。 約款に同意するだけで使えるサービスでは、自組織のために条件を変えてもらえないからです。ここを取り違えると、「有名なサービスだから安全なはず」という判断に流れます。問題はサービスの性能ではなく、契約の形です。
国の申合せでも、現在のChatGPTは約款型外部サービスに区分されるサービスであるとされていました。
残るのは自治体機密性1です
約款型のサービスで扱えるのは、自治体機密性1の情報ということになります。公表された情報と、将来公表する予定の文書です。
「それでは何もできない」と受け取られがちですが、実際に回る業務はあります。
- 公表済みの計画・要綱・統計の要約
- 公開されている他団体の事例の整理
- 住民向け公表資料の下書き
- 公開する議事録の整形
判断の順序を変えてください。 「入れられないもの」を数えると禁止事項の一覧になりますが、「機密性1で回せる業務」を先に洗い出すと、使える範囲が具体的に出てきます。
ただし「機密性1だけだから自由」ではありません
ここを飛ばす団体が多いところです。ガイドラインは、自治体機密性2以上を取り扱わない場合についても 8.4 に別の規定を置いています。
自治体機密性２以上の情報を取り扱わない場合であって、クラウドサービス提供先における高いレベルの情報管理を要求する必要がない場合においても、種々の情報を送信していることを十分認識し、リスクを十分踏まえた上で利用の可否を判断して利用することが求められる
8.4 が求めているのは、次の整備です。
- クラウドサービスを利用可能な業務の範囲
- 利用申請の許可権限者と利用手続
- クラウドサービス管理者の指名と利用状況の管理
- 利用の運用手順
そして職員側には、利用するサービスの約款その他の提供条件等から、利用に当たってのリスクが許容できることを確認した上で申請することが、情報セキュリティ責任者には申請を審査して可否を決定し、承認したサービスを記録することが求められています。
機密性1しか入れないとしても、申請・審査・許可・記録は要ります。
これは好みの問題ではありません
国のガイドラインは、業務範囲をあらかじめ特定することを明確に求めています。
不特定多数の利用者に対して提供され、かつ定型約款や規約等への同意のみで利用可能となるクラウドサービス型の生成AIシステムを業務で利活用する場合には、原則として要機密情報を取り扱うことはできない。また、要機密情報を取り扱わない場合であっても、リスクを考慮した上で利用可能な業務の範囲をあらかじめ特定し、個々の利用に当たっては、利用手続に従って、利用目的（業務内容）や利用者の範囲等の企画者からの申請内容を許可権限者が審査した上で利用の可否を決定し、その利用状況について管理することが必要である
「要機密情報を取り扱わない場合であっても」 です。機密性1しか入れないから自由に使ってよい、とはなりません。業務範囲の事前特定、申請、審査、許可、利用状況の管理まで求められています。
これは府省向けの記述です。ただし自治体でも、同じことが自団体のガイドラインの 8.4 から出てきます（上記）。国と自治体で根拠は別ですが、結論は同じ方向を向いています。 アカウントを配って終わり、にはできないということです。
国が府省向けに確定させたこと
自治体向けのルールを考えるうえで、国の側の整理は参考になります。ただし、府省向けのものであって、そのまま自治体に適用されるわけではありません。
「ChatGPT等の生成AIの業務利用に関する申合せ」は、約款型クラウドサービスによる生成AIの業務利用について、次を職員等に周知するとしていました（以下2つの引用は、総務省のワーキンググループ事務局資料が申合せから抜粋した部分によります）。
- 現在のChatGPTは約款型外部サービスに区分されるサービスであること
- 約款型クラウドサービスでは、原則として要機密情報を取り扱うことはできないこと
- 利用に当たっては、組織の規程に則り承認を得る手続きが必要であること
そして約款型でない形態については、次の整理でした。
サービスにおいて生成AIを利用していることの明示／生成AIの出力結果を二次利用する場合の責任の明確化／一般利用者を対象とする場合は検証段階であることの明示とテスト参加の同意の取得等について対応し、「AI 戦略チーム」の了解及び組織規定上の利用承認を得たうえで一部の機密性２情報まで取り扱うことができる
「一部の」であり、「承認を得たうえで」です。 契約形態を非約款型に変えれば制限が外れる、という話ではありません。
了解を出すのは「AI戦略チーム」という特定の主体です。 ここを落として「了解を得れば」と読むと、庁内の誰かの了解で足りるように見えてしまいます。なお総務省の資料には、申合せの第2.1版（令和7年3月25日）によって報告先等が「AI戦略チーム」から「AI戦略推進関係省庁会議幹事会」に変更された旨の注記が付いています。
この申合せに代わるものとして「行政の進化と革新のための生成AIの調達・利活用に係るガイドライン」（デジタル社会推進標準ガイドライン DS-920）が策定されました。申合せ（第2.1版）は廃止されています。
このガイドラインは令和8年6月12日に第2.0版が決定され、令和8年9月1日から施行されています。 以下は第2.0版の記述です（初版は令和7年5月27日。ここで引く部分の骨格は変わっていませんが、文言は動いています）。
要機密情報を取り扱うクラウドサービスを調達する場合はISMAP（政府情報システムのためのセキュリティ評価制度）の原則利用の考え方に基づき、原則としてISMAP等クラウドサービスリストから選定することとされ、府省ごとに生成AIの利活用ルールを策定することが求められています。
ルールのひな形（第2.0版では「生成AIシステム利活用ルール（ひな形Ver2.0）」）では、約款型では要機密情報を原則取り扱わないこと、国外サーバの場合の留意点、個人情報については利用目的のための必要最小限の利活用又は提供であることを確認することなどが示されています。
1つ目の「原則」には、例外の道筋まで書かれています。 ひな形は、例外として要機密情報を取り扱う場合は情報セキュリティポリシーに基づき情報セキュリティ責任者の許可が必要、としています。「原則」で終わらせず、誰の許可で外れるのかまで決めてある書き方です。自団体のルールを書くときも、ここまで書けているかを見てください。
3つ目（個人情報）の書きぶりは覚えておいてください。 ガイドラインのひな形は「利用目的のための必要最小限の利活用又は提供であることを十分に確認すること」としています。「利用目的の範囲内かどうか」ではなく、範囲内であることを前提に、さらに最小限かを問う書き方です。
これは府省向けのひな形の文言ですが、後述する総務省の自治体向けひな形も、同じ言い回しを採っています（「保有個人情報の利用目的のための必要最小限の利用又は提供であることを十分に確認すること」）。自治体でルールを書くときも、この水準で書かれることになります。
ISMAPに載っていれば済む、ではありません。 ガイドラインは「ISMAP等クラウドサービスリストから選定したものであっても、本ガイドラインの対応が不要となるものではないことに注意が必要である」としています。生成AI特有のリスクへの対応は、別に必要だという整理です。
契約の形は2つではなく3つです
ガイドラインは、生成AIシステムの導入類型を「開発の実施有無」と「契約の形態」で整理しています。
| 類型 | 内容 |
|---|---|
| A | 生成AIシステムの個別開発は実施せず、定型約款や規約等への同意によりサービスを利用する（原則、要機密情報を扱わない想定） |
| B | 個別開発は実施せず、定型約款や規約等への同意に加え、個別契約の締結を行う |
| C | 個別開発を実施し、個別契約の締結を行う |
「約款型か、そうでないか」という二分では足りません。 BとCでは求められる対応が違います。庁内でサービスを分類するときは、この3類型で整理してください。
自治体向けのひな形は、すでに出ています
「国の整理を待っている」という前提で止まっている団体があります。待つ段階は終わりました。
- 令和7年7月31日 — 総務省「自治体におけるAIの利用に関するワーキンググループ」の報告書が公表されました。国による支援の方向性として自治体向けガイドラインの策定が挙げられていたものです
- 令和7年12月16日 — 総務省が「自治体におけるAI活用・導入ガイドブック＜導入手順編＞（第4版）」を公表しました。報道資料は「今般、『自治体におけるAIの利用に関するワーキンググループ報告書』（令和7年7月公表）等をもとに、ガイドブックを改訂し、生成AIの利用方法や具体的な利活用事例、利用における留意事項等の記述等を追加しました。また、別添として、自治体が作成する生成AIシステム利用ガイドラインのひな形についても追加しております」としています
つまり、自団体のガイドラインを一から書き起こす必要はありません。 ひな形（「（自治体名）生成AIシステム利用ガイドライン（ひな形Ver1.0）」）が Word 形式で公表されています。
ひな形が実際に採っている構え
読むと分かりますが、ひな形は禁止事項を並べる作りになっていません。 骨格はこうです。
- 使ってよい生成AIシステムを「指定」する。 ひな形は「情報政策担当課が指定する〜とし、これらに該当しない生成AIシステムの利用は禁止する」という形を採り、指定してほしいときは各担当課室から申請する、としています
- 別表で、システムごとに「担当課室・利用者・利用可能な業務の範囲・入力可能な情報」を定める。 入力可能な情報は自治体機密性の分類で書きます
- 別表の記入例は、1つ目のシステムが「自治体機密性2以下の情報」、2つ目が「自治体機密性1の情報」となっています
1つ目に注目してください。 ひな形は、機密性2まで入れられるシステムがありうる前提で書かれています。ただし条件が付きます。
なお、指定の際に、情報政策担当課において、要機密情報を入力可能な生成AIシステムについては、当該生成AIシステムを提供する事業者によって入力データが機械学習に利用されないこと及び（自治体名）の許可なく監査されないことを確認済みである
「約款型だから機密性1まで」と「機密性2を入れられるシステムもある」は、矛盾しません。 前者は画一的な約款のサービスの話で、後者は指定・確認を経たシステムの話です。分けるのは契約と確認の有無であって、サービスの知名度ではありません。
ひな形には、ほかにも実務で効く定めがあります。
- 職員は、利用前に情報政策担当課が指定する研修を必ず受講すること
- 私用デバイスへ私的にインストールした生成AIに職務上知り得た情報を入力してはならないこと
- 保有個人情報を含むプロンプトを入力する場合は、事業者が当該保有個人情報を機械学習に利用しないこと等を十分に確認すること
- 委託先に対しても、委託契約書等に必要な規定を定めることなどにより、ひな形に沿った対応を求めること
- ハルシネーション・著作権侵害などのリスクケースの報告フォームと報告手順（検知内容の報告→対処→対応結果の報告）
4つ目は見落とされがちです。 庁内のルールを作っても、委託先が生成AIで成果物を作ってくる経路が残ります。
「機械学習に利用しないこと等」の「等」も落とさないでください。 学習に使うかは一例です。応答結果の出力以外の目的で取り扱われないかが本体の論点です。
それでも、格付けの当てはめは自団体の仕事です
ひな形の別表に入っているのは記入例だけです。システム名は「具体的な生成AIシステムのサービス名①」という仮の記載のままで、どのシステムに、どの課室が、どの業務で、どの機密性まで入れてよいかは、自団体で埋めるしかありません。 ひな形が出たことで作業がなくなったのではなく、作業の形が決まったということです。
ワーキンググループでは、次のような自治体の声が挙がっていました。
本自治体では、データ処理が国内で完結する仕組みで生成AIを利用している。また、入力データは学習に利用されないようにするとともに、RAGが参照するデータベースは庁舎内のサーバに置いている。このように、万全のセキュリティ対策を講じている。一方で、機密性2以上の情報を生成AIに入力しても問題ないのかの判断がつかないため、機密性2以上の入力は禁止している
対策が足りないのではなく、判断の基準がないから止まっている。 これが多くの団体の実情だと思います。逆に言えば、格付けと業務を突き合わせる作業をすれば、いま使える範囲は確定できます。
庁内でルールを作るときの順序
- 総務省のひな形を出発点にする。 白紙から書かない。第4版のガイドブックと別添のひな形を手元に置いてください
- 自団体の情報セキュリティポリシーで、格付けの区分を確認する。 5区分がそのまま採用されているとは限りません
- 使ってよいサービスを、契約の形で分類する。 上のA・B・Cのどれか。ここが第一の分岐です
- ひな形の別表を埋める。 システムごとに、担当課室・利用者・利用可能な業務の範囲・入力可能な情報（機密性の区分）を書きます。「機密性1の情報を扱う業務」ではなく、業務名で書いてください
- 要機密情報を入れるシステムについては、確認した事実を残す。 ひな形が求めているのは「入力データが機械学習に利用されないこと」「自団体の許可なく監査されないこと」の確認です。確認した、という記録が要ります
- 判断に迷ったときの相談先を決める。 小規模団体では体制の確保が難しく、ワーキンググループでも複数団体の合同や都道府県による設置が論点になっていました
- 見直しの決裁ラインを決める。 ひな形自身が「本ガイドラインの変更は、生成AIの技術進展や、個人情報保護法の改正等の国におけるルール整備の動向等を踏まえて、適時適切に行う」としています
4が要です。 区分の説明だけを配っても、職員は自分の目の前の資料がどれに当たるか判断できません。業務名で示してください。
まとめ
- 自治体は情報セキュリティポリシーの格付けから判断が始まります。個人情報かどうかはその後です
- 自治体機密性は5区分（3A・3B・3C・2・1）。表は分類基準と情報資産の例が分かれています。同じ個人情報でも3Bと3Cで分かれ、入札予定価格など非公開情報も3Cに入ります
- 約款型のサービスには自治体機密性2以上を入れられないのが原則です。理由は危険性ではなく、自組織のために条件を変えてもらえないという契約の形にあります
- 約款型で扱えるのは自治体機密性1（公表された情報、将来公表する予定の文書）。「使える業務」から洗い出す方が実務は進みます
- 機密性2以上を扱わない場合にも、ガイドライン 8.4 が別に適用されます。 業務範囲・許可権限者・利用手続・管理者の指名・運用手順の整備と、申請・審査・記録が要ります。機密性1しか入れなくても、アカウントを配って終わりにはできません
- 国は府省向けにISMAPの原則利用と府省ごとのルール策定を確定させています（DS-920。令和8年9月1日から第2.0版が施行）。ISMAPに載っていても、生成AI特有の対応は別に必要です
- 契約の形はA・B・Cの3類型（約款のみ／約款＋個別契約／個別開発＋個別契約）。二分では足りません
- 自治体向けのひな形は、すでに出ています。 令和7年7月にWG報告書、令和7年12月にガイドブック第4版と別添「生成AIシステム利用ガイドライン（ひな形Ver1.0）」。白紙から書く段階ではありません
- ひな形は指定したシステム以外の利用を禁止する形を採り、別表でシステムごとに業務範囲と入力可能な機密性区分を定めます。機密性2まで入れられるシステムもありうる前提ですが、機械学習に利用されないこと・許可なく監査されないことの確認が条件です
- 別表に入っているのは記入例だけです。 格付けと業務を突き合わせる作業は、自団体でしかできません
区分の当てはめは、実際の文書を見ないと判断できません。自団体の規程に沿ったルールづくりと、職員向けの研修をご相談いただけます。監査で自治体の情報管理の実務を見てきた立場から、いまの規程のままで何ができるかを整理してご提案します。