氏名を削除すれば住民情報を生成AIへ入力できますか?
氏名を削除しただけでは判断できません。住所、年齢、世帯、相談内容、日時などの組合せから個人を識別できる可能性があります。利用目的、必要最小限、利用環境、契約、規程、再識別可能性を確認し、判断できなければ入力しません。

住民情報を生成AIへ入力する前に、目的、必要最小限、利用環境、契約、承認を順番に確認する方法を解説します。

SHORT ANSWER
住民情報の入力可否は、『氏名を消したか』だけでは決められません。対象業務と利用目的を特定し、情報を使わずに済む方法を先に検討したうえで、必要最小限、許可された環境、契約・規約、保存・学習利用、アクセス権、承認、記録を一件の判断票へまとめます。
自治体のDX・情報政策・情報セキュリティ担当者住民窓口・福祉・税務など住民情報を扱う業務主管課個人情報保護・法務・調達・監査の担当者
KEY POINTS
DECIDE BEFORE INPUT
住民情報を生成AIへ入力してよいかは、サービス名や職員の判断だけでは決めません。最初に、どの業務の、どの工程で、何を作るために、誰の情報を使うのかを一件ずつ特定します。相談記録の要約、通知文の下書き、入力内容の分類では、必要な情報と誤ったときの影響が異なります。
個人情報保護委員会は、行政機関等が個人情報を含むプロンプトを入力する場合、特定された利用目的のための必要最小限の利用または提供であることを十分に確認するよう注意喚起しています。デジタル庁のガイドライン第2.0版も、入力の可否を事前に確認し、判断できない場合は個人情報を含まないプロンプトとする考え方を示しています。
本記事の判断票と手順は、各自治体が自らの法令、条例、規程、情報セキュリティポリシー、契約に照らして検討するための一般的な活用例です。特定自治体で確認済みの導入実績、個別案件の適法性判断、効果保証ではありません。判断に迷う場合は、個人情報保護担当、法務、情報セキュリティ担当へ引き継ぎます。
AVOID & MINIMIZE
目的を定めたら、実データを使わずに同じ目的を達成できないかを先に検討します。文章の形式確認や操作テストであれば、架空の氏名・住所・日付を使ったテストデータで足りる場合があります。制度案内の文案であれば、個別事情を入力せず、公開済みの制度要件だけで下書きを作れることがあります。
実データが必要な場合も、帳票や相談記録を丸ごと入力しません。目的に直接必要な項目だけを抽出し、自由記述、連絡先、識別番号、家族情報、健康・障害・生活状況など、目的に不要な要素を外します。伏字や置換をしただけで安全と決めず、残った項目の組合せから個人が分かる可能性も確認します。
入力しない情報と、入力を止める条件を明記します。マイナンバー、認証情報、秘密鍵など、組織の規程や利用環境で禁止される情報は、担当者の裁量で例外にしません。緊急対応や住民の権利に直接影響する判断は、AIへ渡す前に人が原記録を確認し、正規の業務手順へ戻します。
ENVIRONMENT & CONTRACT
情報を減らしても、利用する生成AIの環境が自治体の業務利用として許可されていなければ入力できません。個人契約のサービス、職員が任意に作成したアカウント、検証用と本番用が混在した環境を、承認済みの業務環境と同じ扱いにしないことが重要です。
個人情報保護委員会は、保有個人情報が応答結果の出力以外の目的で取り扱われる場合、個人情報保護法に違反する可能性があるとし、提供事業者が機械学習に利用しないこと等を十分に確認するよう示しています。利用規約やプライバシーポリシーの表示だけでなく、自治体との契約、設定、再委託、保管場所、保存期間、削除、ログ、事故時の連絡まで確認します。
サービスの仕様や契約が変更されたときに、以前の承認を自動で引き継がない仕組みも必要です。契約・規約の版、確認日、確認者、変更通知の受け手、再確認期限を台帳へ記録し、確認できない項目は『問題なし』ではなく未確認として扱います。
TWELVE-FIELD RECORD
入力判断票は、一つのサービスにつき一枚ではなく、用途ごとに作成します。同じ環境でも、公開資料の要約と、住民相談記録の要約では入力情報、影響、承認者が異なるためです。利用台帳がある場合は用途IDで関連付け、判断根拠と実際の利用記録を追えるようにします。
承認者は、AIの名称だけで可否を判断しません。目的、入力項目、利用環境、契約、出力の使い方、停止条件を確認し、許可、条件付き許可、不許可、専門確認の4区分で結論を残します。条件付き許可では、対象期間、利用者、件数、入力項目、出力用途を具体的に限定します。
入力後は、入力した全文を無制限に複製するのではなく、規程に沿って、案件ID、実施日時、利用者、利用目的、承認番号、出力の確認結果、削除・訂正・事故の有無を記録します。ログの保存内容自体が個人情報を含み得るため、閲覧権限と保存期間も決めます。
業務名・工程・用途ID
利用目的と期待する出力
情報主体と情報の取得元
入力予定項目と除外項目
実データが必要な理由と代替案
利用するサービス・契約・アカウント
保存・学習利用・二次利用の条件
再委託・保管場所・削除の条件
利用者・アクセス権・出力の共有範囲
出力確認者と業務への利用方法
停止・事故連絡・住民対応の手順
承認区分・承認者・期限・次回見直し日
FIVE-STEP OPERATION
最初の対象は、住民の権利や給付を決める工程ではなく、公開情報や架空データで検証でき、人が原記録と出力を照合できる補助工程から選びます。対象課、利用者、期間、入力項目、件数、出力用途を限定し、入力判断票と利用台帳を連携させます。
検証では、個人情報を含まない通常ケースだけでなく、自由記述へ不要な個人情報が混入した場合、複数人の情報が含まれる場合、誤ったデータ、古い規約、権限外の利用者、サービス仕様変更を含めます。入力前に止められるか、誤入力を検知・報告・削除できるかも確認します。
運用開始後は、入力件数ではなく、入力を見送った理由、不要項目の削減、承認差戻し、出力修正、誤入力、削除、問合せ、契約変更を確認します。目的や契約が変わったときは利用をいったん止め、判断票を更新して再承認します。
業務、目的、情報、影響、責任者を決める
実データ不要の方法を試し、入力項目を最小化する
利用環境、契約、保存、学習利用、権限を確認する
入力判断票で条件を限定し、テスト後に利用を開始する
利用、差戻し、事故、変更を追跡し再承認する
FREQUENTLY ASKED QUESTIONS
氏名を削除しただけでは判断できません。住所、年齢、世帯、相談内容、日時などの組合せから個人を識別できる可能性があります。利用目的、必要最小限、利用環境、契約、規程、再識別可能性を確認し、判断できなければ入力しません。
業務利用として許可されたサービス、契約、アカウント、設定であることを確認します。個人契約や任意作成アカウントを、自治体が承認した業務環境の代わりに使いません。まず架空データで目的を検証し、正式な承認経路へ進めます。
学習利用の有無は重要な確認項目ですが、それだけで可否は決まりません。利用目的、必要最小限、応答以外の二次利用、保存、ログ、再委託、保管場所、削除、アクセス権、事故対応、自治体の規程と承認も確認します。
用途、入力項目、利用者、影響、出力の使い方が異なれば再判断します。サービス単位の確認結果は共通資料にできますが、入力判断票は用途ごとに作り、条件付き許可の範囲を明確にします。
自己判断で履歴を消して終わらせず、利用を止め、日時、入力者、情報の範囲、利用環境、出力・共有の有無を保全して、定めた事故連絡先へ報告します。提供事業者への削除・調査依頼や住民対応の要否は、自治体の事故対応手順と専門担当の判断に従います。
公開情報や架空データで検証でき、出力を職員が原資料と照合でき、住民の権利・給付・処分を直接決めない補助工程が候補です。文案の形式確認や公開制度の要点整理など、対象と期間を限定して始めます。
PRIMARY SOURCES
制度・製品・提供条件は変更されるため、リンク先の最新表示も併せて確認してください。
CONTACT LUMINA