コンテンツにスキップ
← インシデント一覧に戻る

大阪府堺市、同一ファイル名で添付を取り違え124人分の連絡先を誤送信 — 上長は個人情報に気づいたが説明を信じて承認

項目内容
発生日2026年6月8日(誤送信日)
対象組織・業界大阪府堺市(自治体・学校施設開放事業)
攻撃手法攻撃なし(共有フォルダ内の同名ファイルによる添付取り違え)
情報源Security NEXT(2026年7月3日)

大阪府堺市は、2026年7月3日、学校施設開放運営委員会の関係者に対するメールで添付ファイルを取り違え、全関係者124人分の連絡先一覧表を誤送信したことを公表しました。

漏えいした情報は氏名・住所・電話番号・メールアドレスの124人分です。本来送るべきだったのは名簿の入力用様式でしたが、共有フォルダ内で入力用様式と個人情報を含む一覧表のファイル名が同一になっており、職員が誤って一覧表を添付しました。誤送信はメール受信者からの連絡によって判明しています。

特に注目すべきは、同市が公表した経緯です。送信前に職員は内容を確認しておらず、承認時に上長が個人情報に気づいたものの、職員の説明を信じてそのまま送信されたとされています。

  • 2026年6月8日: 学校施設開放運営委員会の関係者1人から名簿入力様式の送付を依頼され、メールを作成。共有フォルダ内で同名だった全関係者の連絡先一覧表を誤って添付
  • 同日: 送信前の職員による内容確認は実施されず。承認時に上長が個人情報の存在に気づいたが、職員の説明を信じて送信を承認
  • その後: メール受信者からの連絡により誤送信が判明
  • 判明後: 受信者に削除を依頼し、削除されたことを確認。対象構成員へ謝罪
  • 2026年7月3日: 公表

直接の原因は、共有フォルダ内で入力用様式ファイルと個人情報入りの一覧表ファイルのファイル名が同一だったことによる添付の取り違えです。加えて、送信前の内容確認が行われていなかったこと、承認段階で上長が異常に気づいたにもかかわらず送信が止まらなかったことが、事故の成立に直接寄与しています。

考えられる原因(推測): 同一フォルダ内で同名ファイルは通常共存できないため、拡張子が異なる(例: 様式が .xlsx、一覧表が .xls や .pdf)か、サブフォルダを跨いで同名だった可能性が考えられます。いずれの場合も、ファイル選択ダイアログに表示される名前だけでは両者を判別できません。運用としては、「配布用」と「内部管理用」のファイルが同じ命名規則で同じ場所に置かれていた構造そのものが事故の土壌になっていたと考えられます。

1. ファイル名は「区別できること」が要件

Section titled “1. ファイル名は「区別できること」が要件”

本件の直接原因はきわめて具体的で、それゆえ他組織にも即座に適用できます。外部配布用のファイルと個人情報を含む内部管理用ファイルは、名前だけで確実に区別できるようにする——例えば内部管理用には接頭辞で 【内部】_PII を付す、格納フォルダを物理的に分けてアクセス権も別にする、といった運用です。人の注意力に依存しない設計として、これはコストが最も低い対策のひとつです。

2. 承認プロセスが「気づいたのに止まらなかった」構造

Section titled “2. 承認プロセスが「気づいたのに止まらなかった」構造”

本件で最も重要な事実は、上長が個人情報の存在に気づいていたという点です。つまり検知は機能していました。それでも送信が止まらなかったのは、承認者が「職員の説明を信じた」ためです。これは承認プロセスの構造的欠陥を示しています。承認者が違和感を持った時点で、説明を聞いて納得するのではなく、添付ファイルを開いて中身を確認するというルールが必要です。「これは様式ファイルです」という口頭の説明は、承認の根拠にはなりません。

3. 送信前確認を「省略できないステップ」にする

Section titled “3. 送信前確認を「省略できないステップ」にする”

職員自身は送信前に内容を確認していませんでした。承認フローが存在するにもかかわらず一次確認が省略されていたのは、「上長が見るから自分は見なくてよい」という責任の相互移転が起きていた可能性を示唆します。承認フローを設ける際は、一次確認と承認確認がそれぞれ独立して機能する設計——両者が別の観点で確認する、あるいは承認者側にのみ「添付を開いた」記録を残す——が求められます。

ヤグラの視点 — 誤検知とアナリスト疲弊:「アラートは出ていたが埋もれた」の自治体版

Section titled “ヤグラの視点 — 誤検知とアナリスト疲弊:「アラートは出ていたが埋もれた」の自治体版”

本件は、セキュリティ運用における最も古典的で最も解決が難しい失敗パターンの、極めてわかりやすい実例です。異常は検知されていました。しかし、それが行動につながらなかったのです。

上長は承認時に「個人情報がある」と認識しました。技術的な用語に置き換えれば、これはアラートが正しく発火した状態です。にもかかわらず送信が実行されたのは、担当者の「これは様式です」という説明によって、アラートが誤検知(false positive)として処理されたからです。SOC(セキュリティオペレーションセンター)で日常的に起きているのと同じ現象が、自治体の承認フローの中で起きていました。

この失敗が繰り返される理由は明確です。アラートを精査するコストが高く、業務を止めるコストが目に見える一方で、見逃した場合のコストは事故が起きるまで目に見えないからです。結果として、判断者は「たいてい問題ない」という経験則に寄りかかります。人手で判断している限り、この傾向は避けられません。

ヤグラの AI SOC が扱っているのは、まさにこの領域です。AIがアラートを自然言語で分析・切り分けし、検知から初動までを従来の平均数時間〜数日から平均数分に短縮する。狙いは検知の数を増やすことではなく、「気づいたのに動かなかった」という空白を埋めることにあります。本件のように「気づく」までは成功していた事案は、その空白がどれほど高価かを教えてくれます。

同市は受信者による削除を確認し、対象構成員への謝罪を完了しています。ファイル命名規則の見直し、送信前確認と承認プロセスの実効性確保といった再発防止策の具体化が期待されます。同名ファイルによる添付取り違えは他組織でも起こり得る構造であり、共有フォルダ運用の点検の契機となる事案です。

日時内容
2026-08-03過去アーカイブとして記事化(キュレーション)