東京アプリのコールセンター業務における個人情報の誤送信（1名・氏名/電話番号/メールアドレス）
公表日
東京都公式アプリ「東京アプリ」のコールセンター業務で、利用者1名の氏名・電話番号・メールアドレスが、別の利用者1名にメールで誤って送られました。
対象者は？
対象は東京アプリの利用者1名（利用者A）で、氏名、電話番号及びメールアドレスが別の利用者1名に送られました。公表資料では、これら以外の情報が含まれたとは書かれていません。対象は1名と公表されています（確定も1名）。
公表資料では、対象の1名には経緯の説明と謝罪が行われたとされています。ほかの利用者が対象になったとは発表されていません。詳しくは公式のお知らせをご覧ください。
何が起きたのか
2026年7月9日、ある利用者が東京アプリの問合せフォームから、新規登録の際に電話番号が使えないと連絡しました。コールセンター業務を受託している株式会社ベルシステム24が調べたところ、その電話番号は別の利用者のアカウントで既に登録されていました。7月11日、受託事業者がその別の利用者に電話番号の利用状況を尋ねるメールを送った際、問い合わせた利用者の氏名、電話番号及びメールアドレスが含まれていました。7月14日、返信がないとの連絡を受けたGovTech東京の職員が、やり取りを確認して判明しました。7月15日に東京都デジタルサービス局などが公表しました。
なぜ起きたのか・なぜ広がったのか
公表された原因は、受託事業者がメールを送るとき、複数人で不備がないか確認すべきところ、その確認が十分に行われないまま送付されたことです。外部からの攻撃によるものとは公表されていません。
いまの状況2026-08-07 時点続報待ち
2026年8月7日時点の公表では、問い合わせた利用者に経緯の説明と謝罪が行われ、メールを受け取った利用者には削除が依頼されました。7月15日時点で二次被害等の報告は受けていないとされています。再発防止として、受託事業者にダブルチェックの徹底など教育指導の徹底が指示されました。補償などについては、まだ発表されていません。
企業として考えたいこと
あなたの会社で、お客様の問い合わせをきっかけに別のお客様や第三者へ連絡する場面があるとき、その文面に問い合わせた人の情報が入らないよう、送る前の確認を仕組みとして用意できていますか。
技術的な要約
東京都公式アプリ「東京アプリ」のコールセンター業務を一般財団法人GovTech東京から受託する株式会社ベルシステム24が、2026年7月11日13時24分、利用者Aの個人情報を含むメールを別の利用者Bに誤送信した。漏えいしたのは利用者Aの氏名、電話番号及びメールアドレスで、対象は1名である。利用者Aは7月9日1時23分に、新規登録時に電話番号が使用できないと問合せフォームから連絡していた。7月14日15時19分、GovTech東京職員が受託事業者と利用者Bのやり取りを確認して判明した。原因は、受託事業者が複数人での確認を十分に行わずメールを送付したことである。7月15日時点で二次被害等の報告は受けておらず、ベルシステム24は7月23日に発表した。
公開情報が限られている点について
攻撃の分類
- 侵入口
- 不明公表で確認外部からの侵入ではなく、受託事業者によるメールの誤送信。公式表現は「受託事業者がメールを送付する際、複数人で不備等がないか確認を行うべきところ、当該確認を十分に行わずに送付してしまった」。
- 脆弱性
- 判明している脆弱性はありません
- 攻撃者
- 特定・主張なし
- ATT&CK
- —
影響
- 業務停止
- なし
- データ
- 確定上限 1確定 1人氏名電話メール利用者A1名の氏名、電話番号及びメールアドレスが利用者B1名に誤送信された。7月15日時点で二次被害等の報告は受けていない。
- 波及先
- —
- 金銭影響
- —
- サプライチェーン
- デジタルサービス局とGovTech東京との協働事業に関し、GovTech東京が委託契約した事業者（ベルシステム24）で発生した。
時系列
技術解説
誤送信に至るまでの経緯（公表内容） 事実
2026年7月9日1時23分、利用者Aが東京アプリの問合せフォームから、新規登録時に「入力された電話番号は使用できません」と表示されて手続きが進まないと問い合わせた。受託事業者の調査で、利用者Aの電話番号が別の利用者Bのアカウントで既に登録されていることが確認された。7月11日13時24分、受託事業者が利用者Bに電話番号の利用状況を伺うメールを送った際、その内容に利用者Aの氏名、電話番号及びメールアドレスが含まれていた。対象は利用者A1名で、7月15日時点で二次被害等の報告は受けていないと公表されている。
判明と公表の流れ（公表内容） 事実
7月14日15時19分、受託事業者からGovTech東京に対し、利用者Bから返信がないとの連絡があった。GovTech東京職員が受託事業者と利用者Bのやり取りを確認したところ、メールに利用者Aの個人情報が含まれていることが判明した。7月15日に東京都デジタルサービス局とGovTech東京が公表し、7月23日にベルシステム24も発表した。事故発生後、利用者Aに経緯の説明と謝罪を行い、利用者Bに当該メールの削除を依頼したとされる。再発防止として、受託事業者にダブルチェックの徹底など関係者への教育指導の徹底を指示し、デジタルサービス局及びGovTech東京も委託業務に係る個人情報の適切な管理について改めて注意喚起を行うと公表された。
公表された原因と委託の位置づけ 事実
公表された発生原因は、受託事業者がメールを送付する際、複数人で不備等がないか確認を行うべきところ、その確認を十分に行わずに送付してしまったことである。本件は、デジタルサービス局とGovTech東京との協働事業に関し、GovTech東京が委託契約した事業者において発生した個人情報の漏えい事故として公表されている。ベルシステム24は、東京アプリの運営に関してGovTech東京からコールセンター業務を受託している。公表資料に記載されている原因は上記の送付前確認に関するものである。
業務の構造に着目した見方 解釈
本件は、利用者Aの問い合わせに応じるために、電話番号を登録済みの別の利用者Bへ確認する、という業務の流れの中で起きた。この種の「第三者への照会」は、依頼者の情報をどこまで書いてよいかが曖昧になりやすい場面だと考えられる。公表された原因は送付前の複数人確認の不足だが、確認という人の注意だけに頼る設計では、件数が少ない場面でも同様のことが起こり得る。特定の担当者や組織の落ち度として捉えるより、照会メールの文面や確認手順を仕組みとして整える課題として読むのが建設的だろう。
発覚の経路に関する見方 解釈
公表によれば、誤送信は7月11日、判明は7月14日で、きっかけは利用者Bから返信がないという連絡をGovTech東京が受け、やり取りを確認したことだった。この経路は、送信済みメールの内容を委託元が確認できたことで発見につながった例と読める。一方で、返信がなければ見つかりにくかった可能性も否定できない。ただし公表資料だけでは、送信後の点検の仕組みが他にあったかどうかは分からない。委託元と委託先の間で、送信内容を後から確認できる状態を保つことの意義がうかがえる。
対応
- 封じ込め
- 利用者Aに経緯の説明と謝罪を行い、利用者Bに当該メールの削除を依頼した。再発防止として、受託事業者にダブルチェックの徹底など関係者への教育指導の徹底を指示し、デジタルサービス局及びGovTech東京も委託業務に係る個人情報の適切な管理について改めて注意喚起を行う。
- 公表の仕方
- 2026年7月15日に東京都デジタルサービス局（およびGovTech東京）が公表。7月23日にベルシステム24が発表。
- 当局対応
- —
教訓と対策
| 教訓 | 具体的な対策 |
|---|---|
| 第三者へ送る連絡文に、依頼者本人の個人情報を入れない手順を先に決めておく | 重複登録の照会メールは固定テンプレートを使い、差し込み項目を許可リスト方式にする。氏名・電話番号・メールアドレスは差し込み不可とし、依頼者の情報を自由記述欄から貼り付けられない入力画面にする。 |
| 送信前の人による確認は、運用の依頼だけに頼らず仕組みに組み込む | 外部宛メールはチケット管理システム上で、起票者とは別の担当者が承認するまで送信できないワークフローにする。メール本文の氏名・電話番号・メールアドレスの形式を検知するDLPルールを設け、該当時は送信を保留する。 |
| 重複登録の確認は、相手に他人の情報を示さずに行える設計にする | 登録済みか否かの確認は、利用者Bのアカウントに通知を出す、または認証コードを送る方式に切り替える。依頼者の本人確認は別経路で行い、照会文面には依頼者を特定できる内容を含めない。 |
| 委託元は、委託先が送信した内容を後から確認できる状態を保つ | 委託先の問い合わせ管理ツールで、委託元が送信履歴を閲覧できる権限を持つ。外部宛メールの一定割合を定期的にサンプリング点検し、個人情報の混入を検出する。 |
| 誤送信の発生から判明までの時間を縮める | 返信がない案件や個人情報を含む案件を自動で抽出し、翌営業日に再点検する運用にする。事故の疑いを発見した際の委託先から委託元への報告期限を、委託契約や運用手順書に明記する。 |
自組織などでの確認項目
- 自組織の問い合わせ対応で、ある利用者の情報に基づいて別の利用者や第三者へ連絡する場面はあるか。その際に使う文面は固定されており、依頼者の個人情報が入らない設計になっているか。
- 外部宛メールの送信前に、複数人で確認する手順は、運用上の約束だけでなく、承認なしには送れない仕組みとして実装されているか。送信済みメールを後から点検する手段はあるか。
- 委託先が個人情報の誤送信を起こした場合、自組織はいつ、どの経路で知ることができるか。委託契約に報告期限や送信履歴の閲覧権限が定められているか。
未解明点
- 利用者Bに送られたメールの具体的な文面と、利用者Aの情報がどのような形で含まれていたかは公表されていない。
- 利用者Bがメールを開封したか、また削除依頼に対してどのような対応があったかは公表されていない。
- 個人情報保護委員会など当局への報告の有無や内容は、確認した公表資料には記載がない。
- 再発防止策のうち、送信前確認の仕組みの具体的な変更内容や実施時期は公表されていない。
出典
- 1ScanNetSecurity2026-08-07報道本文確認済
- 2東京都デジタルサービス局2026-07-15公式本文確認済
- 3東京都デジタルサービス局／（一財）GovTech東京2026-07-15公式本文確認済