職員一人ひとりの生成AI利用をすべて台帳へ記録しますか?
原則は業務用途単位で登録し、利用者や対象部署をひも付けます。個々の入力・出力は、用途のリスクと規程に応じて必要な範囲をログや業務記録へ残し、利用台帳へ全文を集約する前提にはしません。
お問い合わせ 自治体内で増える生成AIの利用を、用途・取扱情報・責任者・確認工程・変更履歴まで一元管理する利用台帳の作り方と見直し手順を解説します。

SHORT ANSWER
AI検索や生成AIが一部を引用しても意味が変わらないよう、最初にこの記事の結論を示します。
利用台帳はサービス名の一覧ではなく、生成AIを使う業務ごとに、目的、対象者、取扱情報、責任者、人の確認、外部連携、変更履歴、停止条件を結び付ける管理記録です。
KEY POINTS
導入判断や社内共有に使えるよう、重要点を先に確認できます。
USE-CASE VISIBILITY
同じ生成AIサービスでも、会議資料の要約、住民向け案内の下書き、庁内規程の検索、画像案の作成、外部システムへの登録では、扱う情報、誤りの影響、必要な確認者が異なります。契約中のサービス名だけを一覧にしても、どの課が何の目的で使い、どこまで人が確認しているかは把握できません。反対に、利用者一人ひとりのプロンプトを台帳へ記録すると、件数だけが増え、管理対象が見えにくくなります。
デジタル庁が2026年6月12日に公表した政府向けガイドライン第2.0版は、AI統括責任者、企画者、開発者、提供者、利用者の役割を整理し、生成AIの利活用促進とリスク管理を一体で進める考え方を示しています。対象は国の政府職員であり、全国の自治体へ同じ役職名や手順を一律に義務付けるものではありませんが、組織全体の利用状況とリスク管理を結び付ける際の一次資料として参照できます。
自治体では、既存の情報資産台帳、クラウドサービス管理、契約管理、個人情報ファイル簿、文書管理などを置き換えるのではなく、生成AIの用途をそれらへ接続する索引として利用台帳を設計します。台帳だけに法令・契約上の記録要件を集約できるとは限らないため、正本となる各管理記録へのリンクと主管部署を明示します。
REGISTER DESIGN
登録単位は『一つのAIサービス』でも『利用者一人』でもなく、原則として一つの業務用途です。目的、取扱情報、出力の利用先、確認工程、外部操作のいずれかが異なる場合は記録を分けます。例えば、同じ生成AIで庁内会議の論点を整理する用途と、住民向け通知の下書きを作る用途は、公開範囲と確認者が異なるため別の記録にします。
台帳の目的は項目を埋めることではなく、担当交代、監査、事故、契約更新、機能追加の際に、現時点の利用条件へ戻れるようにすることです。記録には申請時点の計画だけでなく、承認された条件、実際の利用開始日、変更、休止、廃止を残します。資料名や規程名は自由記述だけにせず、正本のURL・文書番号・版へひも付けます。
個人情報保護委員会は、個人情報を含むプロンプト入力について、利用目的の範囲や提供事業者による取扱いの確認を注意喚起しています。『個人情報あり・なし』だけでなく、どの情報区分を、何の目的で、どの環境へ入力できるかを具体化し、目的外利用や不適切な提供にならないかを所管担当が確認します。
REVIEW DEPTH
すべての用途へ同じ申請書と承認経路を求めると、低影響の試行まで停滞し、未申請利用を見つけにくくなります。一方、効率化の名目だけで簡易承認に寄せると、住民の権利、行政判断、個人情報、外部公開へ関わる用途を見落とします。台帳へ登録した後、取扱情報、出力の利用先、外部操作、誤りの影響という4軸で確認の深さを決めます。
デジタル庁のガイドライン第2.0版には高リスク判定シートや利活用ルールのひな形が付属し、利用前後のリスク管理、ログの確認、利用実態の把握、入出力のレビュー等が整理されています。自治体で参照する場合は、そのまま転記して合格とせず、条例、規程、情報分類、業務権限、住民への影響、既存の情報セキュリティ対策へ合わせます。
高影響の用途は、AIを使わない選択肢も残します。住民の権利義務に関わる行政判断、給付・認定・審査、人事評価、生命・身体・安全、個人への不利益、法的見解、外部への自動送信や更新などは、AIの出力だけで決定・実行せず、権限者と必要な専門担当が根拠を確認します。
CHANGE CONTROL
導入時に安全だった用途も、モデル、機能、利用規約、保存条件、参照資料、権限、外部連携、業務手順が変われば、承認時の前提が崩れます。提供事業者の更新情報を確認する担当と、庁内の変更を台帳へ反映する担当を決め、変更前後の条件を残します。変更日だけでなく、影響を確認した項目、再テスト、再承認、利用者への周知を記録します。
小さな変更をすべて同じ会議へ付議する必要はありません。表示だけの変更、出力形式の調整、参照資料の更新、入力可能情報の拡大、外部書込みの追加などを区分し、再確認する範囲を決めます。ただし、影響が分からない変更を『軽微』と推測しません。利用条件やデータ取扱いを確認できない場合は、該当機能を使わず、確認先と期限を台帳へ残します。
IPAが2026年7月31日に公開した生成AIセキュリティの手引書は、企画・開発・提供・利用・運用・廃棄までのライフサイクルと、対象業務や扱う情報に応じた固有リスクの確認を整理しています。変更管理でも、技術更新だけでなく、利用者、業務、情報、運用、廃止までを同じ対象として見直します。
IMPLEMENTATION STEPS
最初から全職員の利用履歴を集めるのではなく、契約、アカウント、ネットワーク許可、庁内アンケート、各課ヒアリングから、現在使われているサービスと用途を洗い出します。同じ用途の重複、未申請、実証終了、担当不在、利用実態なしを区分し、廃止候補を含めて台帳へ登録します。未申請利用を見つけたときは、直ちに個人の責任だけへ寄せず、情報と外部影響を確認し、必要な制限、正式申請、停止のどれへ移すかを判断します。
台帳の主管は一部署でも、内容確認を一部署へ集中させません。業務主管課は目的と出力利用、情報政策・セキュリティは環境と権限、個人情報保護は取扱い、調達・契約は提供条件、監査は記録の再現性を確認するなど、項目ごとに責任を分けます。小規模自治体で兼務する場合も、確認欄と承認欄を分けると判断工程を残せます。
運用開始後は、登録件数だけを成果にしません。台帳と実際のアカウント・契約・連携との差、見直し期限超過、担当不在、休止用途の権限残存、未承認の機能追加、事故時に停止できなかった用途を確認します。本記事は行政実務へ適用するための活用例であり、Lumina Governmentの確認済み導入実績や、特定自治体の運用実績を示すものではありません。
FREQUENTLY ASKED QUESTIONS
記事の要点を、質問と回答の形でも確認できます。
原則は業務用途単位で登録し、利用者や対象部署をひも付けます。個々の入力・出力は、用途のリスクと規程に応じて必要な範囲をログや業務記録へ残し、利用台帳へ全文を集約する前提にはしません。
目的、取扱情報、出力の利用先、人の確認、外部操作が異なる場合は分けます。庁内要約と住民向け通知の下書きでは、誤りの影響と承認者が異なるため、別用途として管理する方が確認しやすくなります。
業務で利用するなら、無料・有料にかかわらず把握対象とします。入力できる情報、利用環境、提供条件、利用者、試行期限、評価、終了時のアカウント・データ処理を決めます。
個人情報は重要な確認項目ですが、それだけでは決まりません。要機密情報、著作権、誤案内、住民への公開、行政判断、外部書込み、自動実行、取り消し可能性も確認します。
一律の間隔だけでなく、モデル・規約・権限・参照資料・連携・業務手順の変更、事故や監査指摘を見直しのきっかけにします。定期棚卸しでは、契約・アカウント・実際の利用と台帳の差、期限超過、担当不在、休止用途を確認します。
PRIMARY SOURCES
制度・製品・提供条件は変更されるため、リンク先の最新表示も併せて確認してください。
CONTACT LUMINA