33万人の個人情報をAIに投入した社員。本当に問うべきは、その社員のリテラシーなのか？

「またAIで情報漏洩か。だから社員に使わせるな」

こんな話を聞くたびに、僕は少し身構える。重大な事態を軽く見ているからではない。むしろ逆だ。そこで思考が止まれば、次の事故を防ぐための仕事が置き去りになるからだ。

2026年10月23日、パナソニック オペレーショナルエクセレンスは、人事情報システム導入プロジェクトのメンバーが、利用を禁止されていた外部生成AIサービスに個人情報を含むデータをアップロードしたと公表した。

対象は従業員約7万5千人、元従業員約17万8千人、家族約8万1千人。合計すると約33万4千人に及ぶ。

大規模である。

しかも、従業員と元従業員については社員番号、住所、電話番号、メールアドレス、家族については緊急連絡先として登録された氏名などが含まれる。関係者が不安を覚えるのは当然だ。

しかし、ここから「AIは危険」「社員のリテラシー不足」「研修を徹底しよう」と一直線に結論を出すなら、私は待ったをかけたい。

本当に問うべきは、禁止されたAIを使ったことだけなのか。それほど大量の情報が一つの業務の流れから外部サービスへ移せたことを、どう捉えるのか。

「漏洩」という言葉は間違いではない。だが、それで説明は終わらない。

最初に事実を切り分けたい。公式発表によれば、これは外部からの侵入ではなく、プロジェクトメンバーのルール違反によるアップロードだ。

会社は9月29日に個人情報保護委員会へ報告した。アップロード時にAI学習への利用は無効で、履歴は削除された。

サービス事業者の説明では、セキュリティ・法令順守のための保持期間30日を経て、10月25日以降は保持されない。発表時点で一般公開や具体的な不正利用被害は確認されていないという。

だから「何の問題もない」とは言わない。

禁止された外部サービスに個人データが渡ったこと自体が重大な管理上の事象である。現実の被害が未確認であることと、リスクが発生していないことは同義ではない。

一方、「33万人の情報がネットにばらまかれた」「AIが学習して誰にでも回答するようになった」と断定するのも、現在の公表内容とは違う。

個人情報保護法には「漏えい等」という正式な概念がある。報告や本人通知の要否を扱ううえで必要な言葉だ。

ここで僕が問題にしたいのは用語の正誤ではない。「漏洩だ！」と叫ぶことが、原因の説明や対策の設計の代わりになってしまうことだ。

事件のラベルと、事件の構造は別物なのである。

AIがなかった時代にも同じ問題は起きていた

想像してほしい。同じ人事データをExcelに書き出し、私用メールに添付したらどうだろう。USBメモリに入れたら。個人のクラウドストレージに置いたら。委託先に丸ごと転送したら。

どれも「生成AI事故」ではない。しかし、組織の管理範囲を超えてデータが動くという本質は共通している。

誤送信、持ち出し、過剰な共有、業務委託時のデータ授受は、AIの登場以前から企業が抱えてきた課題だ。

生成AIによって新たな論点も生まれた。入力内容がどのように保持・学習・再利用されるか、サービス提供者の管理や国外処理がどうなっているか、といった問題である。

だが「AI固有のリスク」と「従来から存在するデータ管理の弱さ」を混同してはいけない。

もしExcelで同じことが起きたら、私たちはExcelを禁止するのだろうか。メールならメールを禁止するのだろうか。

道具の名前に反応している限り、道具が変わるたびに同じ対策会議を開くことになる。

本当に知りたいのは、その人が何をしようとしていたかだ

発表文からは、プロジェクトメンバーがどんな作業のために外部AIを利用したのかまでは分からない。データの変換か、項目対応の整理か、検証用スクリプトの作成か。

ここを想像で埋めて本人の能力や悪意を決めつけるのは避けるべきだ。

しかし、業務基盤を設計する立場なら、そこを調べる。人事システムの移行では、形式の異なるデータの照合、項目のマッピング、例外処理、大量レコードの検証など、手間のかかる仕事が生まれる。

だからといって無断投入が許されるわけではない。

だが、禁止だけで正規の処理手段が提供されていなかったなら、現場には別の圧力が存在したことになる。

誰に、何の目的で、どの範囲のデータを渡したのか。そもそも生データが必要だったのか。個人識別子を削って処理できなかったか。会社が承認した安全な代替手段はあったか。期限や成果への圧力はどう働いたか。

この問いを出さずに「リテラシーが低い」で終われば、同じ職場の別の誰かが、別の道具で同じことをする。

33万人分を「見られる」と「持ち出せる」は、同じ権限でよいのか

さらに考えたい。プロジェクトの要件上、大量の人事データにアクセスする必要はあったかもしれない。

しかし、アクセスできること、全件を一括で抽出できること、外部へ送信できることは、本来異なる能力だ。

ここに業務設計の核心がある。閲覧・抽出・加工・送信を一つの「担当者の善意」に預けない。

目的に応じた最小限のデータを渡す。実データを使う場合は承認と記録を残す。個人識別情報を分離する。持ち出し先を制御し、異常な件数や送信を検知する。必要なら検証環境そのものを隔離する。

もちろん、今回の企業がそれらを全く実施していなかったと断定する材料はない。公開情報だけでは、既存のアクセス制御や通信制御、検知の実態は見えない。

僕が示しているのは、この事案から監査・再設計すべき論点だ。

そして、これは「すべてを技術で完全に防げる」という話でもない。人の判断、教育、運用、監督は引き続き必要だ。

ただ、事故を防ぐ最後の壁を人間の注意力だけにしてはならない。

再発防止策が「教育・啓発」で閉じることを恐れる

公式発表では、個人情報の取扱ルールや生成AIサービス利用管理の見直しに加え、教育・啓発を強化するとしている。これは対応の出発点であり、企業が何もしていないという意味ではない。

今後の詳細も見なければならない。

ただし、僕はあらゆる組織に同じ質問をしたい。「次の月曜日、別の担当者が同じ操作をしようとしたとき、何が変わっているのか」

再研修を受け、誓約書に署名し、注意喚起メールを読んだ。だが、同じ範囲のデータを同じ手順で抽出し、同じ経路で外部に送れる。もしそうなら、対策は人の心に期待しただけではないか。

個人情報保護委員会のガイドラインは、安全管理措置を事業の規模、データの性質や量、リスクに応じて講じることを求める。従業者の監督・教育もその一部だが、それだけが全部ではない。

NISTのAIリスク管理の枠組みも、責任あるAI利用を個人の知識問題に還元せず、組織的な統治・把握・測定・管理の課題として扱う。

問うべきは、教育を何回行ったかではない。同じ誤操作が起きても、取り扱う量が小さく、外部に出る前に止まり、異常を検知でき、影響範囲を追える状態になったかどうかである。

「分かったつもり」が対策を明後日の方向へ連れていく

ここには、もう一つの構造がある。私たちは目立つ事象に名前を付けた途端、理解した気になりやすい。

「情報漏洩」「AIリテラシー」「ルール違反」。どれも間違った言葉ではない。しかし名前は分析の入口であって、結論ではない。

業務を変えるなら、まず事象を正確に記述する。次に、道具や当事者の名前を一度外して共通するメカニズムを抽象化する。今回なら「大量の個人データが、正規の利用目的・管理境界を超えて移動できた」という構造だ。

その仮説をExcel、メール、USB、委託先とのデータ授受にも当ててみる。どこまで共通し、どこがAI固有なのかを反証する。

最後に、実際の業務フローへ戻して権限、データ量、承認、代替手段、検知といった具体策に落とす。

事象の観察 → 構造の抽象化 → 他の事例での検証 → 業務への具体化、この往復を経ずに、最初の印象から「AI禁止」「再教育」という施策へ飛ぶのは、原因を見つけたのではなく、思いついた対策に理由を後付けしただけかもしれない。

しかも厄介なのは、そうした結論ほど会議で真顔で語られやすいことだ。

分かりやすい標語と実効性のある統制は違う。僕が嫌なのは厳しい言葉ではない。厳しい言葉の陰で、事故を可能にした条件が手つかずのまま残ることだ。

現場の作業に落としたら何を変えるべきか

抽象化だけでは業務は変わらない。

ここからは、人事データの移行プロジェクトを仮定した設計例を考える。今回の会社の実態を示すものではなく、同種の事故を防ぐための一般的な設計案だ。

例えば、旧システムから新システムへ30万件の従業員・家族情報を移す仕事があるとしよう。担当者は項目マッピングの不一致、重複、文字化け、空欄、例外レコードに悩まされる。締切は迫る。

正規の検証環境では処理に時間がかかる。手元には便利なAIがある。こんな状況を想定すると、単なる「禁止」の弱さが見えてくる。

データの分類

最初に行うのは、データの分類である。氏名や住所を含む実データ、仮名化したテストデータ、件数と項目名だけのメタデータを分ける。

項目マッピングの相談なら、本当に33万人分のレコードが必要なのか。十数件の架空サンプルと定義書で解ける問題はないか。まず利用目的から必要最小限を決める。

操作を分解

次に、操作を分解する。閲覧できる人が、全件ダウンロードまでできる必要はない。全件抽出を許可するなら、目的・対象期間・件数・保存先・有効期限を申請し、承認とログを残す。

社内の隔離された作業環境では処理できても、個人端末や外部クラウドへコピーできないようにする。

送信先の管理

さらに、送信先の管理を考える。「禁止AIのURL一覧」を更新するだけでは、明日登場するサービスを追い切れない。

機密データの外部送信そのものを検知・制御する仕組み、管理されたブラウザー、承認済みの処理先、データ損失防止のポリシーを組み合わせる。

もっとも、暗号化通信や画面経由の持ち出しなど完全には防げない経路もある。技術的統制の限界は残るので、監査と例外管理を併用する。

代替手段

そして「代替手段」が不可欠だ。禁止されたAIを使うなと言うなら、安全に項目照合や変換コードの検証ができる道具を用意する。

匿名化したサンプルでAIに相談し、実データの処理は社内の承認済み実行環境で行う。これなら現場の生産性とデータ保護は必ずしも対立しない。

操作後も追跡

最後に、操作後も追跡できるようにする。誰が、どのデータセットを、何件、どこへ、いつ出したか。異常な大量抽出や通常と異なる送信先を検出したら誰が判断するか。

業務側、IT、情報セキュリティ、委託先の責任境界はどう分かれるか。インシデント後に初めてログを探すようでは遅い。

防止策を「実装した」と言える判定条件

提案書にはよく「権限管理の徹底」「教育の強化」「監視の高度化」と書かれる。だが、それらは実装の証明にはならない。

業務基盤の設計者としては、最低でも四つのテストをしたい。

第一に、通常業務のテスト。担当者が正規の手順で、必要なデータだけを取得して期限内に仕事を終えられるか。安全だが仕事ができない仕組みは、抜け道を生む。

第二に、誤操作のテスト。担当者が33万人分を一括抽出しようとしたらどうなるか。権限で拒否されるのか、追加承認が必要になるのか、警告が出るだけなのか。警告だけなら、操作を継続できるという事実を受け止める必要がある。

第三に、迂回のテスト。AIではなく個人メール、別のクラウド、ファイル共有サービスに送ろうとしたらどうなるか。AIだけをブロックして、同じデータを別経路に出せるなら、対策の射程が狭すぎる。

第四に、検知・復旧のテスト。事案が起きたと仮定して、何分で検知し、何時間で影響範囲を特定し、誰が外部事業者に削除・保持状況を確認できるか。被害の有無の説明には、観測できる仕組みが必要だ。

測るべき指標も、研修受講率だけではない。実データの全件抽出が必要な業務の割合、例外承認の件数、不要な個人項目を削った割合、異常送信の検知時間、正規の代替手段で処理できた割合などを追う。

これで初めて「再発防止」が施策ではなく結果に近づく。

反証してみる。すべての組織が同じ統制を持つべきなのか

ここまで書くと、何でも厳しく制限すればよいと聞こえるかもしれない。それも危うい。

小さな会社で数件の連絡先を扱う業務に、巨大企業の機密人事基盤と同じ承認階層を持ち込めば、かえって実務は滞る。

逆に、巨大な人事システムで「信頼する社員だから」で全件エクスポートを開放するのも不合理だ。

制御はデータの機微性、件数、利用目的、外部接続、作業頻度、代替手段の有無に応じて設計するべきだ。統制の強さだけでなく、業務の摩擦、例外処理の速度、監督コストとの均衡も評価する。

また、今回の事案で当該メンバーが必要以上のアクセス権を持っていたか、会社の送信制御が存在しなかったかは、今の公開資料からは判断できない。ここを断定すれば、僕自身が批判している「分かったつもり」に陥る。

仮説を事実と取り違えないことも、抽象化と具体化の往復には欠かせない。

「誰が悪いか」より前に「何が可能だったか」を見る

責任追及が不要だと言いたいのではない。ルール違反が確認されたなら、その事実に応じた判断は必要だ。

被害を受ける可能性のある人への説明と救済も欠かせない。

だが、責任追及と原因分析を同じ箱に入れてはいけない。個人の処分が決まったところで、仕組みが変わっていなければ事故の発生条件は残る。

むしろ「犯人がいたから問題が起きた」という物語は、管理責任を見えにくくすることすらある。

僕は業務基盤を構築する仕事をしてきた。現場を責めることよりも、現場が安全に成果を出せる導線を作ることに、時間を使いたい。

ある作業を禁止するなら、代わりにどう仕事を完了させるかまで設計する。権限を絞るなら、正規の承認や例外処理が止まらないようにする。技術的な壁を設けるなら、誰が運用し、誰が例外を判断し、どこに証跡を残すかを決める。

情報セキュリティは「してはいけないこと」のリストではなく、「安全に仕事が進む条件」の設計であるはずだ。

今回の事案を「AIによる33万人の個人情報漏洩」という短い言葉で記憶することは簡単だ。だがそれでは、事故の被害、事実関係、原因、対策の四つが一つに潰れてしまう。

AIを禁止して終わりにするのか。社員を叱って終わりにするのか。それとも、情報を扱う業務の構造を問い直すのか。

僕が本当に怖いのは、誰かが安易に「漏洩だ」と騒ぐことではない。その言葉を聞いた組織が、騒いだだけで対策を済ませた気になることだ。

読者にも問いを残したい。あなたの職場で明日、同じミスが起きたとき、担当者の注意力以外に、事故を止める仕組みは何があるだろうか。

Xでの予告記事

「AIを使うな」で、33万人の個人情報は守れるのか。