北陸電力、取引先202件への確認メールで宛先を誤設定 — 共用システムの使用状況照会でアドレスが相互に閲覧可能に

項目	内容
発生日	2026年5月25日
公表日	2026年6月8日
対象組織・業界	北陸電力（電気事業）
事象	共用システムの使用状況確認メールで送信先アドレスを宛先欄に誤設定
影響件数	取引先202件のメールアドレス
情報源	Security NEXT（2026年6月8日）

概要

北陸電力は、2026年5月25日、共用システムの使用状況を確認するメールを取引先202件に送信した際、送信先のメールアドレスを誤って宛先に設定したことを明らかにしました。

これにより、受信者間でそれぞれのメールアドレスが閲覧できる状態となりました。漏えいしたのは取引先202件のメールアドレスです。同社は対象となる取引先にメールで謝罪し、誤送信したメールの削除を依頼しています。

経緯

• 2026年5月25日: 共用システムの使用状況を確認するメールを取引先202件に送信。この際、送信先のメールアドレスを誤って宛先に設定
• 対象となる取引先にメールで謝罪し、誤送信したメールの削除を依頼
• 2026年6月8日: 事案を公表

原因

同社の説明によれば、原因はメール送信時に送信先のメールアドレスを誤って宛先に設定したことです。本来は受信者相互にアドレスが見えない形（BCC）で送るべき一斉照会を、受信者相互に可視となる宛先欄に入力したため、202件のアドレスが相互に閲覧できる状態になりました。

考えられる原因（推測）: 取引先への一斉照会メールで宛先取り違えが起きる経路としては、(a) 取引先管理台帳やシステムの利用者一覧からアドレスを一括コピーし、貼り付け先の欄を誤る、(b) 200件規模の宛先をメールソフトが警告なく受け付ける、(c) 過去の同種照会メールを流用した際に宛先設定だけが引き継がれない、といったパターンが典型です。本件は「共用システムの使用状況確認」という定型的な事務作業の中で発生しており、システムの利用者リストから機械的にアドレスを転記する工程が介在していたと考えられます。ただしこれは公表事実からの推測であり、確定した原因ではありません。

対策

外部からの攻撃は介在しておらず、防御の起点は業務プロセスの設計と、送信操作に対する仕組み側の制約に置かれます。

組織が学ぶべきこと

1. 「取引先アドレス202件」は取引関係の一覧でもある

漏えいしたのはメールアドレスのみですが、本件で相互に可視化されたのは「北陸電力の共用システムを使用している取引先202社の一覧」という関係情報です。電力会社の共用システムを利用する事業者は、工事請負・保守・資材供給などの取引関係にあると推測でき、同一分野の事業者同士は競合関係にあることも珍しくありません。取引先各社にとっては、自社が受注者としてリストに載っていることが他社に見えたことになります。件数と情報種別だけで軽重を判断せず、リストが持つ文脈まで含めて説明を設計する必要があります。

2. 200件規模の宛先を人間の目視で止めるのは無理がある

本件の宛先は202件です。この規模になると、送信前に宛先欄を目視確認しても「TOに入っているか、BCCに入っているか」の判別は画面上で一瞬に見分けにくくなります。誤送信対策として「送信前の確認」を掲げる組織は多いものの、確認の対象が200件並んでいる状態では確認が形式化するのが実情です。実効性のある対策は、(1) 一定件数以上の宛先をTO/CCに設定した時点で送信をブロックする、(2) 一斉照会は専用の配信ツールまたはシステムの通知機能経由に限定し、個別メールソフトからの一斉送信を業務上禁止する、といった仕組み側の制約です。

3. インフラ事業者の取引先照会は定型業務ほど危ない

共用システムの使用状況確認は、定期的に繰り返される定型業務です。定型業務は手順が固まっているため安全に見えますが、同時に「毎回同じだから確認を省略する」圧力が最も強くかかる工程でもあります。誤送信が定型業務の中で発生した場合、注意喚起では次回も止まりません。前回の送信メールを流用する運用が残っているなら、テンプレート側で宛先欄を空にしておく、あるいは宛先設定を人が触らない形（システム側から自動配信）に変えることが、根本的な打ち手になります。

ヤグラの視点 — 役職別・部門別のリアリティ：調達・購買部門に固有のリスクは、画一シナリオでは扱えない

セキュリティ教育の多くは、全社共通の一律シナリオで設計されています。フィッシングメールの見分け方、パスワードの管理、不審な添付ファイルへの警戒——いずれも必要ですが、全社共通であるがゆえに、各部門が実際に抱えている固有のリスクを扱えていません。

本件で誤送信が起きたのは、取引先200社規模に対して定型の照会メールを配信する業務です。これは調達・購買・資材、あるいはシステム運用部門に固有の業務であり、経理や人事や現場保守の担当者は経験しません。同様に、経営層には送金指示を装ったBECのリスクがあり、人事には応募者を装った添付ファイルのリスクがあり、コールセンターには顧客を装った本人確認突破のリスクがあります。部門ごとに攻撃面と事故面がまったく違うのが実情です。

にもかかわらず、多くの組織で訓練は「全社員に同じシナリオを年1回」の形をとります。この設計では、調達部門の担当者が「200社への一斉照会で宛先欄を間違える」という自部門固有のリスクに向き合う機会が生まれません。訓練を実効性のあるものにするには、部門ごとにその部門でしか起きないシナリオを設計し、業務動線に沿った形で繰り返す必要があります。

ただし、部門別の訓練設計をどれだけ精緻にしても、誤送信そのものをゼロにはできません。「200社への一斉照会」という業務が存在する限り、宛先欄を取り違える確率は残ります。だからこそ本件の教訓は二段構えで捉えるべきです。部門固有のリスクを部門の担当者が自覚している状態をつくることが一段目、それでも起きる前提で、宛先件数による送信ブロックのように人の注意力を前提としない制約を業務に埋め込むことが二段目です。訓練だけで止めようとする設計、あるいはツールだけで止めようとする設計は、どちらも同じ場所で破れます。

今後の対応

同社は対象取引先への謝罪と削除依頼を完了しており、現時点で二次利用の報告はありません。同種の取引先向け一斉照会を扱う事業者においても、宛先欄の設定確認と一斉配信手段の見直しを図る契機となる事案です。

更新履歴

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