生成AIと社内データのセキュリティ|読ませる前の20項目
2026年 9月 14日

生成AIを社内で使う許可は出た。では、どのデータまで読ませてよいのか。この問いで止まっている会社は多いはずです。
全面禁止にすれば安全ですが、使われないか、見えないところで使われるかのどちらかになります。全面許可にすれば、事故が起きたときに範囲が分かりません。必要なのは、渡してよい範囲を先に決めることです。
この記事では、生成AIに社内データを読ませる前のセキュリティ確認を20項目に整理します。点数をつけるためではなく、どこまで渡してよいかを決めるための一覧です。人事データを例に使いますが、考え方は他部門でも同じです。
生成AIに社内データを読ませる前のセキュリティ確認
確認は4区分に分かれます。データそのもの、権限と範囲、委託先と契約、運用と記録です。
順番に意味があります。データの中身が分からないまま契約の話をしても決まりませんし、権限の設計がないまま運用ルールを書いても守れません。上から順に埋めてください。
20項目は多く見えますが、大半は「決まっているか」を問うだけです。決まっていない項目が見つかることに意味があるので、埋まらない欄をそのまま残して構いません。空欄の数が、いま渡せる範囲の狭さを示します。
前提として、総務省と経済産業省が示している「AI事業者ガイドライン」のような公的な整理も出ています。社内ルールを作るときの骨格として使えますが、どのデータを渡すかという具体は、結局自社で決めることになります。
チェック1:データそのもの
最初に見るのは、渡そうとしているファイルの中身です。ファイル名や置き場所ではなく、列を一つずつ見てください。
- 個人情報が含まれるか。 氏名や社員コードだけでなく、組み合わせると個人が特定できる列も含みます。所属・等級・入社年の3つが揃えば、小さな部署では特定できます。
- 要配慮個人情報が含まれるか。 健康診断の結果、休職の理由、ストレスチェックの回答。これらは扱いが別です。渡す対象から外すのが原則です。
- 自由記述が含まれるか。 サーベイのコメント欄には、本人も意識せずに個人が特定できる記述が入ります。要約させると、そのまま出力に現れます。
- 出どころが辿れるか。 その数字が元のどのファイルのどの行から来たか、記録があるかどうか。辿れないデータは、出力の正しさを後から検証できません。
- 保持期限が決まっているか。 渡したデータをいつまで残すのか。決めていないと、退職者のデータが残り続けます。
5項目のうち1つでも「分からない」があるファイルは、いったん対象から外してください。分からないまま渡して、後から確認するのは順序が逆です。実務では、この段階で候補の半分ほどが落ちます。落ちたファイルは、元データから作り直すほうが早いことが多いはずです。
チェック2:権限と範囲
次に、誰がどこまで読めるかを決めます。データの中身より、この区分のほうが後から直しにくいので、早い段階で設計してください。
- 誰が実行できるかが決まっているか。 部署単位か、役職単位か。実行者ごとに読める範囲が変わる設計になっているか。
- 範囲の制御が生成側に効くか。 画面で非表示にしていても、要約文が書いてしまえば同じです。非表示のルールは、集計側ではなく出力側に持たせてください。
- 少人数の区分にしきい値があるか。 「研究所の部長級の女性」のような区分は該当者が数名になります。該当者数そのものも出さないところまで設計します。
- 比較する集団が固定されているか。 順位づけをさせる場合、どの集団の中で順位をつけるかは結果を決めます。プロンプトではなく基盤側に持たせてください。
- 出力の宛先が制御されているか。 同じ内容が、権限の違う相手に同じ形で届いていないか。
この区分で大事なのは、範囲の制御を「指示する人が気をつける」方式にしないことです。書き手が増えれば必ずほころびます。担当が変わったとき、急ぎの依頼で一文が抜けたとき、テンプレートを誰かが複製したとき。受け取る人の権限で出力が変わる仕組みなら、指示は業務の中身だけを書けば足ります。
チェック3:委託先と契約
ここは法務や情報システムと一緒に進める区分です。人事だけで判断せず、契約書の条項に落ちているかまで確認します。
- 入力データが学習に使われるか。 使われない設定になっているか、契約で明示されているか。
- 保存場所と保存期間はどこか。 国内か国外か、ログはどれだけ残るか。
- 再委託があるか。 ある場合、再委託先まで同じ条件が及んでいるか。
- 削除を請求できるか。 渡したデータを消してほしいと言ったとき、応じる手順があるか。
- 事故時の通知義務があるか。 漏えいが起きたとき、いつまでに誰へ知らせるかが契約にあるか。
5項目のどれかに答えが返ってこない場合、その事実を記録に残してください。導入を止める理由になるとは限りませんが、渡すデータの範囲を狭める理由にはなります。回答がない項目の数と、渡す範囲の広さは反比例させるのが安全です。
チェック4:運用と記録
最後は、使い始めたあとの区分です。導入時に決めておかないと、必要になったときには手遅れになります。
- 実行の記録が残るか。 いつ、誰が、どのデータを、どの定義で読んで、何を出したか。
- 定義の版が管理されているか。 指標の定義が変わったとき、いつ変えたかが残るか。残らないと、去年の出力との差を説明できません。
- 出力の再現ができるか。 同じ入力から同じ結果が出るか。出ないなら、説明の根拠になりません。
- 誤りに気づく仕組みがあるか。 エラーが出ない失敗をどう見つけるか。出力の抜き取りより、読ませた範囲の監視のほうが効きます。
- やめる手順が決まっているか。 問題が起きたとき、誰が止めて誰が訂正するか。
記録は監査のためだけではありません。出力がおかしいと気づいたとき、原因がデータなのか定義なのか指示なのかを切り分ける手がかりになります。記録がないと切り分けに時間がかかり、そのあいだ運用を止めることになります。止めている期間のほうが、事故そのものより業務に響くこともあります。
人事データ特有の注意点と、よくある失敗
人事データには、他部門のデータにない事情が2つあります。ひとつは、ほぼすべてが個人に紐づくこと。売上や在庫と違い、集計する前の1行が必ず誰かのものです。もうひとつは、出力が人の処遇に影響しうることです。昇進、配置、評価。間違った出力が判断に混ざると、取り返しがつきません。
だから確認の重心も変わります。漏えい対策だけでなく、「その出力が人の扱いを変えるかどうか」で線を引いてください。変えるなら、決定の主体は人のままにします。
もうひとつ、人事データには時点の問題があります。在籍者の情報は毎月変わるため、渡したデータはその日のうちに古くなります。基準日を明示せずに渡すと、出力にも基準日が入りません。読んだ人は、それがいつの状態か分からないまま判断に使うことになります。
よくある失敗は次のとおりです。
- 匿名化したから安全とみなす。 氏名を消しても、属性の組み合わせで特定できます。列を消すより、区分の粒度を粗くするほうが効きます。等級を3段階にまとめる、年代を10歳刻みにする、といった処理のほうが確実です。
- チェックリストを点数化する。 18項目クリアだから可、という運用にすると、残り2項目が致命的でも通ります。項目ごとに可否を判断してください。
- 一度確認して終わりにする。 委託先の仕様は変わります。契約更新のタイミングで、少なくとも区分3は見直してください。
- 定義を固定しないまま数字を読ませる。 離職率ひとつでも分母の取り方で数字が動きます。定義の置き方は「離職率の計算方法」にまとめました。
- 予兆の検知結果をそのまま通知に流す。 離職の予兆のような出力は、伝わった時点で影響が出ます。扱いは「離職の予兆をデータで捉える」で触れています。
- 比較集団を既定値のまま使う。 候補者の選抜では、順位をつける集団の指定が結果を決めます。確かめ方は「次世代リーダー候補の選抜で女性が少なくなる理由」で扱いました。
Floraの支援:渡す前に、範囲と出どころを固定する
Flora株式会社の「CapLead」は、グループ各社に散在する人事・人的資本のデータを一つの基盤で管理し、指標ごとの定義を版で固定して、元ファイルの行まで遡れる出典を残します。同じ配信設定・同じテンプレートでも、描画の時点で受け取る人のスコープが適用されます。人数の少ない区分は、画面にも書き出しにもメール本文にも出ません。
20項目のうち、区分1と区分2と区分4の大半は、基盤の持ち方で決まります。まず30分、貴社グループのデータの持ち方をお聞かせください。
まとめ
生成AIと社内データのセキュリティは、全面禁止か全面許可かの二択ではありません。データそのもの、権限と範囲、委託先と契約、運用と記録。この4区分20項目で、渡してよい範囲を決めてください。
人事データでは、漏えい対策に加えて「その出力が人の扱いを変えるか」で線を引きます。変えるなら、決定は人が持ちます。20項目を一度に埋める必要はありません。埋まった範囲だけを対象と決めて、そこから始めてください。公表する数字の定義については「女性管理職比率の公表」も参考になります。
--- CTA: 30分ヒアリング(無償)を申し込む → /ja/caplead
よくある質問
全項目を満たさないと、生成AIに社内データを読ませてはいけませんか。
社内で使う生成AIなら、委託先の確認は不要ですか。
匿名化すれば、要配慮個人情報も渡せますか。





