デジタル庁150人分漏えい 作業手順書の曖昧さが原因

インシデント対応

デジタル庁が2026年8月7日、他省庁へ送付したログイン履歴ファイルに、本来含めるべきでない職員150人分の個人情報が記載されていたと公表しました。宛先も送信方法も間違っていません。間違っていたのは「ファイルの中身」で、その引き金は運用作業手順書の曖昧な記載でした。同じ形の事故は、監査対応やグループ会社向けのログ提供でログを抽出している組織なら、どこでも起こり得ます。

この記事でわかること

  • デジタル庁の事案で実際に何が起き、どう発覚したのか
  • なぜ「メール誤送信対策」ではこの類型を防げないのか
  • ログ抽出・データ提供の手順書に何を書けば再発を止められるのか

何が起きたのか

デジタル庁の公表によると、事案の概要は次のとおりです。

項目 内容
公表日 2026年8月7日（デジタル庁）
対象システム 国家資格等情報連携・活用システム
漏えいした情報 各資格管理団体の職員の氏名、ユーザーID、所属等のコード
対象人数 150人
発覚日 2026年7月6日
発覚の経緯 送付先の省庁担当者から「関係者以外の個人情報が記載されている」と連絡があった
原因 運用作業手順書の記載が曖昧なままファイル作成作業を行ったこと
二次被害 送付先で第三者への転送はなく削除済み。二次被害は確認されていないとしている
再発防止策 チェック体制の強化、作業手順書の点検等

国家資格等情報連携・活用システムは、マイナンバーを活用して国家資格関連の手続きをオンライン化する基盤で、複数の省庁・資格管理団体が共同利用しています。今回問題になったのは、そのログイン履歴ファイルです。本来は「送付先の省庁担当課のユーザーのみ」を抽出すべきところ、他の資格管理団体のユーザーまで含んだ状態でファイルが作られ、そのまま送られました。

これは「誤送信」なのか？

いいえ、宛先は正しく、送るべき相手に送っています。誤っていたのは抽出条件、つまり出力されたデータの範囲です。この区別は実務上とても重要です。世の中の漏えい対策の大半は「宛先」と「送信操作」に集中しているからです。

典型的な誤送信対策を並べてみると、今回の類型に効かないことがはっきりします。

  • 宛先の複数人確認：宛先は正しいので発動しない
  • 送信保留・取消機能：送信自体は正しい操作なので止める理由がない
  • 添付ファイルの自動暗号化：中身が過剰でも暗号化されて正しく届くだけ
  • DLP（情報漏えい対策）製品：「省庁間で個人情報を含むログを共有する」という業務自体は正規なので、ポリシーで弾きにくい

つまり、この事故は送信の手前、ファイルを作った瞬間にすでに成立していたということです。防波堤を置くべき場所が、多くの組織で想定しているところより一段上流にあります。

過去には、Excelの非表示行や取り消し忘れのデータがそのまま渡ってしまう事例もありました（非表示データの削除漏れで個人情報4363件を誤送信）。今回も系統は同じで、「ファイルの中身を誰も見ていない」という一点に尽きます。

なぜ手順書の曖昧さが事故になるのか

デジタル庁は原因を「運用作業手順書の曖昧な記載」と説明しています。手順書に悪意も手抜きもありません。おそらく「送付先省庁のログイン履歴を作成する」といった、読めば意味は通るが、抽出条件が一意に決まらない書き方だったのだろうと推測されます（具体的な文言は公表されていません）。

ログ抽出の作業には、少なくとも次の要素があります。

  • 対象期間：いつからいつまでか
  • 対象ユーザーの範囲：どの組織・どのロールまでか
  • 出力する列：氏名や所属を含めるのか、IDだけで足りるのか
  • 絞り込みの実装：どの画面・どのクエリのどの条件で絞るのか
  • 完成後の検証方法：想定外のレコードが混じっていないかをどう確かめるか

このうち一つでも「常識で判断してください」の状態で残っていると、担当者が代わった瞬間に解釈がずれます。手順書の曖昧さは、担当者の練度で吸収されているうちは表面化せず、人が変わったときやシステムが変わったときに一気に事故化するのが厄介なところです。

発覚が「送付先からの指摘」だった意味

今回、誤りに気付いたのは受け取った側の担当者でした。裏を返せば、デジタル庁側では作成時も送付時も検知できていなかったということです。これは外部からの指摘で初めて問題が判明した過去事例（生保協会3.7万件閲覧可能、外部指摘で発覚の教訓）と同じ構図で、幸運に依存した発覚経路です。受け取り手が中身を精査しない相手だったら、そのまま気付かれなかった可能性は十分あります。

現場目線の課題──「ログを出して」は断りにくい

正直なところ、この事故に同情する情シス担当者は多いはずです。監査部門、業務部門、取引先、グループ会社。あちこちから「◯◯のログを出してほしい」と依頼が来ます。多くは正当な依頼で、断る理由もありません。

ところが実態はこうなりがちです。管理コンソールからCSVを落とし、Excelで開いて不要そうな列を消し、期間で絞り、ファイル名を付けて送る。この一連の作業は数分で終わってしまうがゆえに、レビュー対象として認識されない。承認フローに載るのは「ログを提供してよいか」という可否の判断だけで、出来上がったファイルそのものを第三者が見る工程は、たいてい存在しません。

さらに、ログ抽出は担当者が固定化しやすい業務でもあります。「あの人に頼めば出してくれる」状態は、業務としては効率的ですが、手順書が育たない温床にもなります。書かれていないノウハウが多いほど、書かれた手順書は曖昧なまま放置されます。

限られた人員でこれを全部レビューするのは現実的ではありません。だからこそ、全件を人力で見るのではなく、事故ったときの影響が大きいものだけを選んで工程を足すという割り切りが要ります。

情シスはどうすべきか

長大なチェックリストを作るより、まずは公的機関の指針を土台にするのが早道です。ヒューマンエラーによる漏えいは、独自の対策を発明するより、既にまとまっている型を自組織に当てはめるほうが定着します。

そのうえで、今回の類型に的を絞って足すなら次の3点です。

1. 手順書に「抽出条件」を値として書く

「対象者のログを抽出する」ではなく、期間・対象範囲・出力列・絞り込み条件を、そのまま入力できる形で書きます。可能ならクエリや保存済みフィルタとして固定し、担当者が毎回条件を組み立てないようにするのが確実です。手順書の曖昧さは、手順書を丁寧に書くことより、判断の余地そのものを減らすことで消えると考えたほうが実装しやすいはずです。

2. 「送る前に中身を見る」工程を明示的に置く

件数と、対象組織のユニーク値を確認するだけでも、今回のような混入はほぼ捕まります。組織コードの一覧を出して想定外の値が無いか見る、といった軽い検証で十分です。ポイントは、それを作業者本人ではない誰かの工程として手順書に書くことです。過去の誤送付事例でも、この一手間の有無が明暗を分けています（誤送付409件、福岡市の事例に学ぶ漏えい防止策）。

3. そもそも渡す情報を減らせないか確認する

今回漏れたのは氏名・ユーザーID・所属等のコードです。相手が本当に必要としているのが「誰がいつログインしたか」の統計なら、氏名は不要かもしれません。最小権限の原則はアクセス制御だけの話ではなく、外部に渡すデータにも同じように効きます。依頼を受けた時点で「その列は本当に要りますか」と一度返すだけで、事故の上限が下がります。

なお民間企業の場合、要配慮個人情報や不正アクセスが絡む漏えい等では個人情報保護委員会への報告義務が生じ得ます。「実害がなかったから報告不要」と自己判断しないこと（CRM開発会社が侵害、漏えいなしでも報告義務）。

中長期の視点──共同利用システムほど効く

今回のシステムは複数省庁・複数団体が共同利用する基盤でした。共同利用型のシステムは、一つのテーブルに複数組織のデータが同居しているため、抽出条件を一つ間違えると他組織の情報が出てしまうという構造的なリスクを抱えています。これは行政に限った話ではなく、グループ会社で共通の人事システムやSaaSテナントを使っている企業にも当てはまります。

設計段階でできることもあります。管理画面のエクスポート機能自体に「自組織のデータしか出せない」制約をかけておけば、手順書の書き方に依存せず事故を防げます。運用でカバーしている部分のうち、システム側に寄せられるものがないか。棚卸しの価値はありそうです。

まとめ

  1. デジタル庁の事案は「誤送信」ではなく出力データの範囲を誤った類型。宛先確認や送信保留では防げず、対策はファイル作成の工程に置く必要があります。
  2. 原因は運用作業手順書の曖昧な記載。抽出条件を値で書く、あるいは判断の余地を残さない形に固定するのが本質的な対処です。
  3. 発覚は送付先からの指摘でした。自組織で検知できない前提で、送る前に作業者以外が中身を確認する工程を、影響の大きいデータ提供に限ってでも設けるべきです。

出典

タイトルとURLをコピーしました