厚労省Teamsデータ消失、設定ミスで750万件復元困難

OpenSSL脆弱性CVE-2026-45447、署名検証でRCEの恐れ インシデント対応

システム更改の「ついで作業」が、約2億件のデータ削除と約750万件の復元不能を招きました。2026年6月12日、厚生労働省と東芝は、LANシステムの更改作業中に発生したMicrosoft 365上のデータ消失を公表しました。原因は不正アクセスではなく、保存期間（リテンション）設定の変更ミス。本来は変更すべきでない本番領域の保存期間まで誤って短く設定したことが引き金でした。情シスにとっては「外部攻撃より、自分たちの運用ミスの方が怖い」を地で行く事案です。

この記事でわかること:

  • 何が起きたのか（削除規模・対象期間・データ種別）
  • なぜ起きたのか（設定ミスの具体的な構造）
  • クラウド移行・更改で同じ轍を踏まないために情シスが押さえるべき勘所

何が起きたのか

厚生労働省のLANシステム更改作業のなかで、委託事業者である東芝が誤った設定を行い、Microsoft Teamsのチャットデータ・共有ファイル・個人ファイルが削除されました。報道（日経クロステック等）によると削除されたデータは約2億件にのぼり、このうち約750万件が復元困難（＝実質的に消失）とされています。

削除されたのは、2023年1月4日から2025年10月29日までに作成されたデータです。削除作業が行われたのは2026年4月25日で、公表まで約1か月半を要しました。消失したデータには行政文書に該当するやりとりが含まれることも確認されており、単なる社内チャットの喪失にとどまらず、公文書管理の観点でも問題を残しています。

項目 内容
公表日 2026年6月12日（厚労省・東芝）
削除実施日 2026年4月25日
対象期間 2023年1月4日〜2025年10月29日に作成されたデータ
データ種別 Teamsチャット、共有ファイル、個人ファイル（行政文書を含む）
削除規模 約2億件（うち約750万件が復元困難）※報道ベース
原因 保存期間（リテンション）設定の変更ミス
情報漏洩 完全削除のため漏洩の可能性はなしと説明

なお、件数の内訳（約2億件・約750万件）は報道による数字で、厚労省の公式発表では「チャットデータの一部が復元困難」とされ具体的な件数は明示されていません。この点は区別して読む必要があります。

なぜ起きたのか — 設定ミスの構造

設定ミスの中身はどんなものだったのか。東芝の説明によれば、本来は「職員が削除したファイルを一時的に保存する領域（ごみ箱に相当する一時保存領域）」の保存期間だけを見直す予定でした。ところが、職員が通常利用する本番領域の保存期間まで誤って変更してしまい、保護されるべきデータが削除対象になったとされています。

ここで言う保存期間（リテンション）とは、データを「いつまで保持し、いつ削除するか」を定めるポリシーのことです。Microsoft 365では保持ポリシーによって、一定期間を過ぎたデータを自動的に削除する運用ができます。便利な反面、適用範囲（スコープ）を取り違えると、生きているデータを一括で消してしまう「武器」にもなり得ます。

さらに見逃せないのが体制面です。東芝は、当初は社内専門家のレビューやベンダー協力を行う想定だったものの、今回の作業が「補助的な作業」と位置づけられていたためレビューを実施せず、テストも不十分だったと認めています。リスクの高い操作が「ついで」「軽微」と過小評価され、通常のチェックを通らなかった——この構図こそが、情シスにとって最大の教訓です。

想定されるリスク — なぜ情シスに刺さるのか

この事案が他人事でないのは、クラウド前提の運用では「削除＝即・永久消失」が起こりやすいからです。オンプレ時代は、テープや別筐体のバックアップが最後の砦になりました。一方、SaaS/クラウドでは保持ポリシーや復元猶予期間（リテンション）こそが事実上のセーフティネットであり、その設定そのものを誤れば、頼みの綱を自分で断ち切ることになります。

  • 「ごみ箱があるから大丈夫」は通用しない: 一時保存領域の設定変更が、本番データの保持期間に波及した。
  • 変更作業の影響範囲が見えにくい: 設定一つがテナント全体・全ユーザーに及ぶ。被害が局所で止まらない。
  • 気づくのが遅れる: 削除は静かに進む。今回も公表まで時間を要した。

現場目線の課題

正直に言えば、「補助的な作業だからレビュー不要」という判断は、現場では日常的に起きているものです。限られた人員と時間のなかで、すべての変更に同じ重さのレビューやテストをかけるのは現実的に難しい。だからこそ「これは軽微」「いつもの作業」という線引きが生まれ、その線引きの誤りが事故につながります。

特にクラウドの管理画面は、チェックボックス一つ・適用先の選択一つで挙動が大きく変わります。GUIの分かりやすさが、かえって「重大な操作をしている」という緊張感を薄れさせる側面もあります。委託事業者に任せる場合でも、どの領域に・どの範囲で・いつ反映されるのかを発注側の情シスが理解しないまま承認していると、今回のように後追いでしか把握できません。ベンダー任せの「お任せ更改」のもろさが露呈した形です。

情シスはどうすべきか

明日からできることは何か。個別の手順を長々と並べるより、まず公的な指針と自組織のルールに立ち返るのが近道です。

  • 変更管理のプロセスを「補助的作業」にも適用する: 影響範囲が本番データやテナント全体に及ぶ操作は、規模の大小にかかわらずレビュー・承認・テストの対象にする。「軽微かどうか」は作業量ではなく影響範囲で判断する。
  • リテンション／保持ポリシーの棚卸し: いま自社のMicrosoft 365等で、どのポリシーがどの範囲に効いているかを可視化する。削除の自動化は便利だが、適用スコープの取り違えが致命傷になる。
  • バックアップとリテンションは別物と認識する: 保持ポリシーは「世代管理されたバックアップ」ではない。重要データは独立したバックアップ手段を持つ。
  • 委託先との責任分界点を明確に: 「誰が・何を・どの権限で操作するか」「本番への反映前に発注側が確認するか」を契約・手順レベルで取り決める。

体制づくりの土台としては、IPAの中小企業の情報セキュリティ対策ガイドラインが参考になります。インシデント発生時の動き方を組織で確認しておきたい場合は、セキュリティインシデント対応 机上演習教材を使った訓練が有効です。あわせて、現場のうっかり操作を減らすための地道なユーザ教育・啓発も欠かせません。

中長期の視点 — クラウド前提の公文書・データ管理

今回は行政文書の一部が失われた点で、可用性（必要なときにデータが使える状態）と記録の保全という、セキュリティの基本要件が問われました。クラウドへ業務が移るほど、「外部からの攻撃を防ぐ」だけでなく「内部の運用ミスでデータを失わない」設計の重要性が増します。保持・削除・復元の各設定をどう統制するか、変更時にどんな歯止めをかけるか——攻撃対策と同じ熱量で、運用統制を整える局面に来ています。

まとめ

  • 厚労省のLAN更改作業で、保存期間（リテンション）設定の変更ミスにより約2億件が削除、うち約750万件が復元困難となった（件数は報道ベース、行政文書を含む）。
  • 原因は外部攻撃ではなく運用ミス。リスクの高い操作が「補助的作業」と過小評価され、レビュー・テストを通らなかったことが背景にある。
  • クラウド前提では削除が即・永久消失につながりやすい。変更管理を影響範囲で判断し、リテンションとバックアップを別物として整える必要がある。

出典

コメント

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