長崎市が2026年6月3日に公表した宿泊客情報の漏えい事案は、「テスト環境の管理」という、開発現場では地味に扱われがちな問題が、実際にどれほど深刻なリスクにつながるかを改めて示した事例です。ITmedia NEWSの報道をもとに、事実を整理したうえで現場目線の見解を述べます。
要点
- 長崎市（長崎市）が2026年6月3日、4万3000件超を見込む宿泊客情報の漏えいを発表した。
- 市内アクセスに使われたテスト環境は本来廃止すべき環境だったが、目的外にAI活用システムの高度化などに転用されていた。
- 漏えいした情報には2024年10月時点の法人宛インターネットバンキングダイレクト情報1万1,872件、2021年3月時点の基礎情報1万1,122件、その他の顧客・関係者情報5,751件などが含まれる（証明番号やパスワードは含まれないとしている）。
- 削除すべき顧客データが保管されたまま残っており、かつ不正アクセスを防ぐ仕組みが十分に機能していなかったことが3つの不備として認定された。
- 市は3月24日に外部セキュリティ会社から漏えいの可能性について連絡を受け、調査を開始。テスト環境は警告の本格化を受けて廃止、全関連システムを停止したとしている。
著者見解
今回の事案で特に気になるのは、「廃止すべきテスト環境」がそのまま残り、しかもAI活用システムの高度化という目的外の用途に使われていたという点です。
開発現場では、テスト環境に本番データや類似データを流し込むことが実務上の「手っ取り早い手段」になりやすい場面があります。動作確認のためにリアルなデータが必要、という現場の事情は理解できますが、そのデータをいつ・誰が・どのタイミングで削除するかをルール化していないと、今回のように「残ったままになる」状態が生まれます。
PM・部長の立場で開発プロセスを整備してきた経験から言うと、テスト環境の廃止フローは「作ったときの手順」よりも「終わらせるときの手順」の方が抜けやすい。スプリント終了時や案件クローズ時に「テスト環境のクリーンアップ確認」をチェックリスト化するだけでも、こうしたリスクをかなり減らせます。また、テスト環境への不正アクセスを防ぐ仕組みが「機能していなかった」という点は、目的外転用が重なった結果として権限管理が追いつかなくなった可能性があります。
実務で導入するなら、まず「テスト環境は本番データを扱わない」という原則を明文化し、例外を設ける場合は申請・期限・削除タイミングをセットで管理する体制を整えることが現実的な第一歩だと思います。仕組みを作るだけでなく、チームが納得して運用できる状態にすることが重要です。
出典: 長崎市の漏えい事案、漏えいのテスト環境は「本来廃止すべきだった」 AIを使ったシステムの高度化などに転用されていた
