Lumina
メニュー
お問い合わせ
PUBLIC SECTOR / ARTICLE 24

自治体の生成AI利用を用途・責任者・変更で一元管理する。

自治体内で増える生成AIの利用を、用途・取扱情報・責任者・確認工程・変更履歴まで一元管理する利用台帳の作り方と見直し手順を解説します。

行政・政治13分で読める一次情報を明示
公開:2026年8月31日最終更新:2026年8月31日発行:株式会社ファーストイノベーション
自治体の生成AI利用を用途・責任者・変更履歴で一元管理する青と銀の利用台帳基盤
PUBLIC SECTOR / ARTICLE 24LUMINA COLUMN / 24

SHORT ANSWER

まず、結論から。

AI検索や生成AIが一部を引用しても意味が変わらないよう、最初にこの記事の結論を示します。

結論自治体の生成AI利用を把握するには、一つのサービスを一行で数えるのではなく、業務上の用途ごとに記録を分け、責任者・取扱情報・確認工程・変更履歴・次回見直し日まで一元管理することが基本です。

利用台帳はサービス名の一覧ではなく、生成AIを使う業務ごとに、目的、対象者、取扱情報、責任者、人の確認、外部連携、変更履歴、停止条件を結び付ける管理記録です。

対象カテゴリ行政・政治読了目安13主な対象自治体のDX・情報政策・情報セキュリティ担当者/生成AIを利用する業務主管課・管理職/調達・契約・個人情報保護・監査の担当者発行元株式会社ファーストイノベーション

KEY POINTS

この記事の、4つの要点。

導入判断や社内共有に使えるよう、重要点を先に確認できます。

  • サービス単位ではなく、目的・情報・確認工程が異なる業務用途ごとに登録する
  • 責任者、利用者、取扱情報、人の確認、外部連携、停止条件を同じ記録へ結び付ける
  • モデル・機能・規約・権限・参照資料・業務手順の変更を再評価のきっかけにする
  • 未申請・休止・廃止を含めて棚卸し、台帳と実際の利用状況の差を解消する

USE-CASE VISIBILITY

サービス一覧では、行政利用の実態が見えない。

同じ生成AIサービスでも、会議資料の要約、住民向け案内の下書き、庁内規程の検索、画像案の作成、外部システムへの登録では、扱う情報、誤りの影響、必要な確認者が異なります。契約中のサービス名だけを一覧にしても、どの課が何の目的で使い、どこまで人が確認しているかは把握できません。反対に、利用者一人ひとりのプロンプトを台帳へ記録すると、件数だけが増え、管理対象が見えにくくなります。

デジタル庁が2026年6月12日に公表した政府向けガイドライン第2.0版は、AI統括責任者、企画者、開発者、提供者、利用者の役割を整理し、生成AIの利活用促進とリスク管理を一体で進める考え方を示しています。対象は国の政府職員であり、全国の自治体へ同じ役職名や手順を一律に義務付けるものではありませんが、組織全体の利用状況とリスク管理を結び付ける際の一次資料として参照できます。

自治体では、既存の情報資産台帳、クラウドサービス管理、契約管理、個人情報ファイル簿、文書管理などを置き換えるのではなく、生成AIの用途をそれらへ接続する索引として利用台帳を設計します。台帳だけに法令・契約上の記録要件を集約できるとは限らないため、正本となる各管理記録へのリンクと主管部署を明示します。

  • 契約中だが、利用業務と責任者が分からないサービス
  • 個人利用から課内利用へ広がった未申請の用途
  • 実証終了後もアカウントや連携が残る休止用途
  • 同じAIでも、公開情報だけを扱う用途と機微情報を扱う用途
  • 下書き支援から自動送信・外部操作へ変わった用途

REGISTER DESIGN

一つの用途につき、14項目を結び付ける。

登録単位は『一つのAIサービス』でも『利用者一人』でもなく、原則として一つの業務用途です。目的、取扱情報、出力の利用先、確認工程、外部操作のいずれかが異なる場合は記録を分けます。例えば、同じ生成AIで庁内会議の論点を整理する用途と、住民向け通知の下書きを作る用途は、公開範囲と確認者が異なるため別の記録にします。

台帳の目的は項目を埋めることではなく、担当交代、監査、事故、契約更新、機能追加の際に、現時点の利用条件へ戻れるようにすることです。記録には申請時点の計画だけでなく、承認された条件、実際の利用開始日、変更、休止、廃止を残します。資料名や規程名は自由記述だけにせず、正本のURL・文書番号・版へひも付けます。

個人情報保護委員会は、個人情報を含むプロンプト入力について、利用目的の範囲や提供事業者による取扱いの確認を注意喚起しています。『個人情報あり・なし』だけでなく、どの情報区分を、何の目的で、どの環境へ入力できるかを具体化し、目的外利用や不適切な提供にならないかを所管担当が確認します。

  • 1. 用途ID・正式名称・業務主管課
  • 2. 解決する業務課題と、AIへ任せる範囲
  • 3. 利用サービス・契約・利用環境
  • 4. 利用者・対象部署・アカウント管理者
  • 5. 入力できる情報・入力してはいけない情報
  • 6. 参照ナレッジ・正本・版・更新責任者
  • 7. 出力の利用先・公開範囲・保存先
  • 8. 人が確認する事項・確認者・承認者
  • 9. 外部連携・書込み・自動実行の範囲
  • 10. ログ・記録の範囲、閲覧権限、保存方針
  • 11. 提供事業者・委託先との責任分界と連絡先
  • 12. 停止条件・停止方法・代替業務
  • 13. 承認日・利用開始日・状態・次回見直し日
  • 14. 変更内容・影響確認・再承認・変更実施日

REVIEW DEPTH

用途の影響に応じて、確認の深さを変える。

すべての用途へ同じ申請書と承認経路を求めると、低影響の試行まで停滞し、未申請利用を見つけにくくなります。一方、効率化の名目だけで簡易承認に寄せると、住民の権利、行政判断、個人情報、外部公開へ関わる用途を見落とします。台帳へ登録した後、取扱情報、出力の利用先、外部操作、誤りの影響という4軸で確認の深さを決めます。

デジタル庁のガイドライン第2.0版には高リスク判定シートや利活用ルールのひな形が付属し、利用前後のリスク管理、ログの確認、利用実態の把握、入出力のレビュー等が整理されています。自治体で参照する場合は、そのまま転記して合格とせず、条例、規程、情報分類、業務権限、住民への影響、既存の情報セキュリティ対策へ合わせます。

高影響の用途は、AIを使わない選択肢も残します。住民の権利義務に関わる行政判断、給付・認定・審査、人事評価、生命・身体・安全、個人への不利益、法的見解、外部への自動送信や更新などは、AIの出力だけで決定・実行せず、権限者と必要な専門担当が根拠を確認します。

  • 簡易確認:公開情報による庁内下書きで、訂正可能かつ外部利用しない
  • 標準確認:庁内情報、定型的な対外文案、複数部署利用を含む
  • 強化確認:個人情報・要機密情報、住民向け回答、外部連携を含む
  • 原則限定:権利・安全・行政判断へ直接影響し、自動実行や取り消し困難な操作を伴う

CHANGE CONTROL

承認後も、8つの変化で見直す。

導入時に安全だった用途も、モデル、機能、利用規約、保存条件、参照資料、権限、外部連携、業務手順が変われば、承認時の前提が崩れます。提供事業者の更新情報を確認する担当と、庁内の変更を台帳へ反映する担当を決め、変更前後の条件を残します。変更日だけでなく、影響を確認した項目、再テスト、再承認、利用者への周知を記録します。

小さな変更をすべて同じ会議へ付議する必要はありません。表示だけの変更、出力形式の調整、参照資料の更新、入力可能情報の拡大、外部書込みの追加などを区分し、再確認する範囲を決めます。ただし、影響が分からない変更を『軽微』と推測しません。利用条件やデータ取扱いを確認できない場合は、該当機能を使わず、確認先と期限を台帳へ残します。

IPAが2026年7月31日に公開した生成AIセキュリティの手引書は、企画・開発・提供・利用・運用・廃棄までのライフサイクルと、対象業務や扱う情報に応じた固有リスクの確認を整理しています。変更管理でも、技術更新だけでなく、利用者、業務、情報、運用、廃止までを同じ対象として見直します。

  • 1. モデル、提供基盤、主要機能、出力特性の変更
  • 2. 利用規約、データ取扱い、保存・削除、処理条件の変更
  • 3. 利用部署、利用者、管理者、委託先、責任分界の変更
  • 4. 入力情報の区分、参照ナレッジ、正本、保存先の変更
  • 5. プラグイン、API、外部検索、書込み、自動実行の追加
  • 6. 出力の利用先、公開範囲、確認者、承認手順の変更
  • 7. 法令、国の方針、条例、規程、契約、業務手順の変更
  • 8. 事故、誤回答、苦情、監査指摘、利用実態とのずれの発見

IMPLEMENTATION STEPS

既存利用を止めずに、6段階で棚卸しする。

最初から全職員の利用履歴を集めるのではなく、契約、アカウント、ネットワーク許可、庁内アンケート、各課ヒアリングから、現在使われているサービスと用途を洗い出します。同じ用途の重複、未申請、実証終了、担当不在、利用実態なしを区分し、廃止候補を含めて台帳へ登録します。未申請利用を見つけたときは、直ちに個人の責任だけへ寄せず、情報と外部影響を確認し、必要な制限、正式申請、停止のどれへ移すかを判断します。

台帳の主管は一部署でも、内容確認を一部署へ集中させません。業務主管課は目的と出力利用、情報政策・セキュリティは環境と権限、個人情報保護は取扱い、調達・契約は提供条件、監査は記録の再現性を確認するなど、項目ごとに責任を分けます。小規模自治体で兼務する場合も、確認欄と承認欄を分けると判断工程を残せます。

運用開始後は、登録件数だけを成果にしません。台帳と実際のアカウント・契約・連携との差、見直し期限超過、担当不在、休止用途の権限残存、未承認の機能追加、事故時に停止できなかった用途を確認します。本記事は行政実務へ適用するための活用例であり、Lumina Governmentの確認済み導入実績や、特定自治体の運用実績を示すものではありません。

  • 1. 契約・アカウント・各課ヒアリングから既存用途を洗い出す
  • 2. サービス名ではなく、目的と確認工程が同じ用途へ整理する
  • 3. 14項目を記入し、不明項目・未確認条件を明示する
  • 4. 4軸で確認の深さを決め、継続・条件付き・停止を承認する
  • 5. 利用者へ許可条件、禁止事項、相談先、変更申告を周知する
  • 6. 台帳と実態を定期照合し、変更・休止・廃止まで更新する

FREQUENTLY ASKED QUESTIONS

よくある疑問を、短く正確に。

記事の要点を、質問と回答の形でも確認できます。

Q01

職員一人ひとりの生成AI利用をすべて台帳へ記録しますか?

原則は業務用途単位で登録し、利用者や対象部署をひも付けます。個々の入力・出力は、用途のリスクと規程に応じて必要な範囲をログや業務記録へ残し、利用台帳へ全文を集約する前提にはしません。

Q02

同じ生成AIサービスなら一つの記録でよいですか?

目的、取扱情報、出力の利用先、人の確認、外部操作が異なる場合は分けます。庁内要約と住民向け通知の下書きでは、誤りの影響と承認者が異なるため、別用途として管理する方が確認しやすくなります。

Q03

試行中の無料サービスも登録対象ですか?

業務で利用するなら、無料・有料にかかわらず把握対象とします。入力できる情報、利用環境、提供条件、利用者、試行期限、評価、終了時のアカウント・データ処理を決めます。

Q04

個人情報を入力しなければ簡易確認でよいですか?

個人情報は重要な確認項目ですが、それだけでは決まりません。要機密情報、著作権、誤案内、住民への公開、行政判断、外部書込み、自動実行、取り消し可能性も確認します。

Q05

利用台帳はどのくらいの頻度で見直しますか?

一律の間隔だけでなく、モデル・規約・権限・参照資料・連携・業務手順の変更、事故や監査指摘を見直しのきっかけにします。定期棚卸しでは、契約・アカウント・実際の利用と台帳の差、期限超過、担当不在、休止用途を確認します。

PRIMARY SOURCES

判断の基準にした、公式情報。

制度・製品・提供条件は変更されるため、リンク先の最新表示も併せて確認してください。

CONTACT LUMINA

自社の業務に合う専用AIを、一緒に整理します。

導入目的、使いたい業務、情報管理、費用まで、まだ具体的でない段階からご相談いただけます。
お問い合わせページへ