3行まとめ
- 厚生労働省LANシステム（Microsoft 365環境）の更改作業で、委託先である東芝の設定の誤りによりTeamsのチャットデータや共有・個人ファイルが削除され、チャットの一部が復元困難になる事案が公表されました。
- 表面的には「設定ミス」ですが、根にあるのは 保持ポリシーの仕様の取り違え——「保持期間」が削除済みデータだけでなく 現役（運用中）のデータの削除にも効く という仕様の把握だと考えられます。
- この記事では、公式ドキュメントをもとに保持ポリシーの正しい仕様を確認し、IT管理者として設定画面のどこを押さえるべきかを整理します。
はじめに
設定ミスそのものは、正直なところ誰にでも起こりえます。怖いのは、間違った仕様理解のまま設定を組み、その誤りに気づけないまま本番に反映されてしまう ことです。込み入った仕様であっても、削除をともなう設定では「この設定が何に効くのか」を正確に把握するのが、私たちIT管理者の役割になります。
今回は、公表された他社事例を題材に、Microsoft 365 のアイテム保持ポリシーの仕様を公式ドキュメントで確認しながら、どこで理解を取り違えやすいのかを一緒に押さえていきます。あくまで学びの整理であり、当事者を責める意図はありません。公開情報が限られるため推測を含む点も、あらかじめお断りしておきます。
事案の概要（公表されている事実）
まず、公表されている内容（東芝）を確認します。
| 項目 | 内容 |
|---|---|
| 対象システム | 厚生労働省LANシステム（Microsoft 365環境） |
| 発生日 | 令和8年（2026年）4月25日に実施した設定 |
| 影響データ | 令和5年1月4日〜令和7年10月29日（2023/1/4〜2025/10/29）に作成されたTeamsチャット、共有ファイル、個人ファイル |
| 結果 | 上記が削除され、チャットデータの一部が復元困難 |
公表された原因は、要約すると次の2点です。
- 削除されたファイル等を 一時的に保存する領域 の保存期間「のみ」を見直す予定が、職員が 通常利用する領域 の保存期間も誤って設定した。
- データ保存期間の設定変更を 補助的な作業 と位置づけたため、知見者のレビューや製品ベンダーの設計協力を得ずに進めた。テストも実施したが、不十分なテストデータ で行ったため検知できなかった。
注目したいのは、「一時的に保存する領域」と「通常利用する領域」を 別物として考えていた 点です。この2つが実は同じ設定で動く、という仕様の取り違えがあった可能性がうかがえます。これが本記事の本題です。
保持ポリシーの“正しい”仕様を押さえる
ここからが中心です。アイテム保持ポリシーが実際にどう動くのかを公式ドキュメントで確認します。
保持または削除するアイテム保持ポリシーと保持ラベルの詳細（Microsoft Learn） では、3種類の保持設定について説明されています。
| 結果 | 実画面での設定 | 動作 |
|---|---|---|
| 保持のみ | 「特定の期間アイテムを保持」＋終了時「何もしない」／「アイテムを無期限に保持する」 | 削除されない |
| 保持して削除 | 「特定の期間アイテムを保持」＋終了時「アイテムを自動的に削除する」 | 期間経過後に削除 |
| 削除のみ | 「特定の期間が経過したときにのみアイテムを削除」 | 期間経過後に削除（保持なし） |
そして、削除・編集されたデータの 退避先 が次の通りです。
| ワークロード | 退避先（＝「一時的に保存する領域」に相当） |
|---|---|
| SharePoint / OneDrive | 保存先ライブラリ（Preservation Hold library） |
| Exchange メールボックス | 回復可能なアイテム（Recoverable Items）フォルダー |
| Teams チャット / チャネル | 回復可能なアイテム配下の隠しフォルダー SubstrateHolds |
ここが仕様理解のポイントです。保持ポリシーに設定する「保持期間」は、（設定によっては）現役データの削除タイミングにも影響します。また、削除・編集されたデータが保持の仕組みにより保護される期間とも関係します。
たとえば保持期間を短くすると、退避領域の保管が短くなるだけでなく、その期間より古い現役データが削除の対象 になります。しかも保持・削除は コンテナー単位 で対象に継承されます（アイテム保持ポリシーの作成（Microsoft Learn））。
一方で、「削除済みデータを、あとから復元できる期間」を扱う設定は、保持ポリシーの保存期間とは別です（Exchangeの削除済みアイテム保持、SharePoint/OneDriveのごみ箱）。「復元できる期間を確保したい」という要件は、本来こちらで扱う話です。
画面で確認する：管理者が押さえるべきチェックポイント
では、実際の設定画面で「どこを確認すべきか」を見ていきます。込み入っていて直感的とは言いがたい部分もありますが、削除をともなう変更では、各画面で「この設定は何に効くのか」を一つずつ確かめるのが管理者の務めです。画面が悪い、で終わらせず、きちんと把握していきましょう。
入口は、Microsoft Purview ポータルにサインインし、左ナビの データ ライフサイクル管理 → ポリシー → アイテム保持ポリシー です。
ウィザードは「名前 → 管理単位 → 種類 → 保持の設定 → 完了」という流れです。「作成するアイテム保持ポリシーの種類を選択する」画面では、本記事は再現しやすい 「静的」 を選びます。
チェックポイント1：場所の選択
「このポリシーの適用先を選択します」画面で今回は「Teams チャット」と「Teams チャネル メッセージ」をオンにしています。
なお、Teams の場所を選ぶと、Exchange・SharePoint・OneDrive など他の場所は自動的に除外されます（同じポリシーに同居できない仕様です）。共有ファイルや個人ファイルの保持・削除は別ポリシーで設定することになります。本記事はチャットに論点を絞るため、この2つだけを対象にしています。
ここで選んだ場所が、保持・削除の対象になります。Teamsのチャットやチャネルメッセージを選べば、職員が日常的にやり取りしている 現役のメッセージがそのまま対象 に含まれます。「削除済みの退避領域だけを対象にする」という選択肢は、この画面にはありません。なお、Teams固有の保持の挙動はTeams のアイテム保持ポリシーを管理する（Microsoft Learn）もあわせてご確認ください。
チェックポイント2：保持するか、削除するか、その両方か
「コンテンツを保持するか、削除するか、または両方を行うかを決定します」画面（初期値）。既定では「特定の期間アイテムを保持」＋「保持期間の終了時：アイテムを自動的に削除する」、つまり “保持して削除” が選ばれています。開始基準は「アイテムの作成日時」。確認すべきは、(1) 終了時に自動削除が付いているか、(2) 保持期間は何か、(3) 起点が作成日か の3点です。
この画面で、たとえば次のように設定すると、現役データを削除する設定になります。
「事故につながる設定」の例です。「特定の期間が経過したときにのみアイテムを削除」を選び、6か月（0年6か月0日）、削除の基準は「アイテムの作成日時」。「より古いアイテムを削除」という表記は、一見すると “古いデータの片づけ” のように読めますが、実際には 作成から6か月より古い現役チャットがすべて削除されます。なお「保持して削除」を選んでも、保持期間より古い現役データは同様に削除されます。
なお「削除のみ」は保持を伴わない設定のため、退避領域での保護も働きにくく削除後の復元はいっそう難しくなります。これは公表された「チャットの一部が復元困難」という結果とも整合性があります。
公表情報から考えられる事故の流れ（推測）
公表された日付から逆算してみます。設定が実施されたのは2026年4月25日、削除されたデータの作成期間は2023年1月4日〜2025年10月29日でした。
- 設定実施日（2026年4月25日）と、削除対象の 最も新しい作成日（2025年10月29日）の差は、約178日とおよそ半年（6か月）です。
- 削除対象の最も古い作成日は2023年1月4日。これは、システムにデータが存在し始めた時点と考えられます。
- 削除された期間の長さは、およそ2.8年分（約2年10か月）になります。
この数字を先ほどの保持の設定画面に当てはめると、辻褄が合います。「特定の期間が経過したときにのみアイテムを削除（または保持して削除）」＝約6か月、開始基準＝アイテムの作成日時、という設定だったと考えると、作成から半年より古いデータが削除対象になり、データが存在し始めた2023年1月まで遡って、約2.8年分が消えた、という流れです。
つまり、「削除済みデータの保存期間だけを調整するつもり」が、現役チャットを対象にした保持ポリシーに “約半年・自動削除” の設定をしてしまった、というのが、公表内容と仕様、そして日付に整合する一つの見方となります。
ただし、保持期間の具体的な値も、システムの開始時期も、プレスリリースには明記されていません。あくまで公表された日付からの逆算であり、当事者の操作内容を断定するものではない点はご了承ください。
取り違えると、設計も検証も誤りを引き継ぐ
ここで「検証はしたのに、なぜ気づけなかったのか」という疑問がでてきます。保持ポリシーの削除は作成日起点で効きます。検証データに「しきい値より作成日が古いデータ」が含まれていなければ、削除はそもそも再現せず、「問題なし」に見えてしまいます。さらに、間違った仕様理解のまま検証ケースを作ると、間違った設定でも“想定どおり”に見えてしまい、見落とします。「テストした」は「設定が正しい」ことの証明にはなりません。
あくまで正しい仕様理解があってことの設計と検証です。理解が誤っていれば設計も検証もその誤りをそのまま引き継ぎます。
やっておくべき設定 — 「削除」ではなく「保持」を主眼に
では、どう設定すべきだったのか。ポイントは、アイテム保持ポリシー設定の主眼を 「削除（片づける）」ではなく「保持（守る）」 に置くことです。たとえば「1年の保持で運用する」と決めた場合の、あるべき設定の参考例がこちらです（保持期間を一律に「何年」と決められない事情は、後述の「補足」で触れます）。
「特定の期間アイテムを保持」を1年、開始基準は「アイテムの作成日時」、保持期間の終了時は 「何もしない」。これで1年間は確実に保持され、誤って消えることはありません。終了時に「自動的に削除する」を付けないのは、廃棄は内容区分と正規の手続きで判断すべき事項となります。
| 事故につながる設定 | あるべき設定（1年運用の例） | |
|---|---|---|
| 主眼 | 削除（古いものを片づける） | 保持（守る） |
| 選択 | 「特定の期間が経過したときにのみ削除」または「保持して削除」 | 「特定の期間アイテムを保持」 |
| 期間 | 約6か月 | 1年 |
| 開始基準 | アイテムの作成日時 | アイテムの作成日時 |
| 終了時 | アイテムを自動的に削除する | 何もしない |
| 結果 | 作成から半年より古い現役チャットが削除される | 1年は確実に保持。自動削除はしない |
「削除済みの復元期間」は別レイヤーで
そして、今回 “本来やりたかったこと” と思われる「削除済みデータの復元できる期間の調整」は、保持ポリシーではなく別の設定で行います。たとえばメールボックス側であれば、Exchange OnlineのPowerShellで設定する削除済みアイテムの保持期間（RetainDeletedItemsFor）がこれにあたります（Teamsチャットの復元挙動はもう少し込み入っていますが、「別の場所にある設定」という考え方の一例として挙げます）。
Connect-ExchangeOnline
# 現在の設定を確認
Get-Mailbox -Identity user@contoso.com | Format-List RetainDeletedItemsFor
# 削除済みアイテムの復元可能期間を変更（既定14日／最大30日）
Set-Mailbox -Identity user@contoso.com -RetainDeletedItemsFor 30この設定が そもそもPurviewの保持ポリシーとは別の場所にある こと自体が、今回の取り違えを象徴しています。公表された「一時的に保存する領域の保存期間のみを見直す」という意図も、本来はこの 退避領域（削除済みデータ）側の話 で、アイテム保持ポリシーの操作を想定していなかったのではないでしょうか。
よくある誤解と正しい理解
社内（上司や現場）に説明するとき、つまずきやすい誤解を、公式ドキュメントの根拠つきで整理します。
誤解A：「削除アクション付きでも、保持期間を縮めて消えるのは“削除済み”だけ」
正しくは、「削除のみ」「保持して削除」は、作成から指定期間が過ぎた現役コンテンツを削除します。退避領域だけの話ではありません。
誤解B：「削除済みデータの復元できる期間を延ばしたいなら、保持ポリシーの保存期間を変えればいい」
保持ポリシーは コンテナー単位で現役コンテンツに継承される 設定です。削除済みデータの復元可能期間は、Exchangeの削除済みアイテム保持（既定14日・最大30日）やごみ箱といった 別の設定 で扱います。
誤解C：「保持期間の起点は最終更新日だから、最近触ったデータは消えない」
Teamsでは「最終更新日」を選んでも、実際には 常に作成日が使われます（既知の構成上の注意としてドキュメントに明記）。最近やり取りしていても、作成日が古いデータは削除の対象になりえます。
アイテムが最後に変更されたときに保持期間を開始するオプションを選択できますが、アイテムが作成されたときの値が常に使用されます。 編集されたメッセージの場合、元のメッセージのコピーが元のタイムスタンプとともに保存され、この事前編集されたメッセージがいつ作成されたかを識別し、後編集されたメッセージのタイムスタンプが新しくなります。
補足：公的機関ではTeamsチャットの保持期間を何年にすべきか
少し、公的機関ならではの観点を補足します。
業務や意思決定に関わるTeamsチャットは、内容によっては行政文書に当たり、保持すべきものになりえます。判断基準は 組織共用性（職務上作成・取得し、組織的に用いるものとして保有しているか）で、内閣府の電子メールの選別及び手順に関するマニュアルが電子メールについて示す考え方が、チャットにも及ぶと考えられます。
ただし、「チャットだから何年」と一律には定められません。行政文書の保存期間は内容の区分ごとに決まり、一般に1年・3年・5年・10年・30年（歴史的に重要なものは国立公文書館へ移管）といった幅があります（公文書管理制度：内閣府）。さらに、保存期間が満了した行政文書の廃棄には、レコードスケジュールに基づく手続きと内閣総理大臣の同意が必要です。（流石に10年や30年のような扱いはないでしょうが・・・）
そのため、仮に「1年で運用する」と決めた場合でも、設定の主眼は 「保持（守る）」 に置き、期間後の自動削除は慎重に議論されるべきでしょう（前掲の“あるべき設定”）。
業務に関わるチャットを内容を区別せず一律に短期間で自動削除する設計が公文書管理の考え方で適切なのかはもっと詳しい方の意見をお伺いしたいところです。
再発防止のヒント
さて、今回の経緯を読み解いて再発防止策を考えてみると、特別な仕組みを増やすよりも進め方を順番に押さえるのが効果的だと思います。
- まず仕様を正しく理解する：削除をともなう設定変更を「補助作業」と軽く見ず、一次情報で「この設定が何に効くのか」を確認します。
- アプローチ（設計・手順）をレビューする：理解や設計が意図どおりかを、知見者や製品ベンダーなど第三者に確認してもらいます。自分の前提が正しいという思い込みを、ここで一度外します。
- 検証環境で検証する：本番に近い構成・データで、実際に動かして確認します。とくに保持ポリシーは作成日起点で効くため、しきい値より古い作成日のデータを必ず含めること。これが無いと削除は再現せず、「問題なし」に見えてしまいます。
- 検証結果を評価・レビューする：検証して終わりにせず、結果が想定どおりか、意図した範囲だけに効いているかを評価します。できれば結果も第三者の目でレビューします。「検証した」は「正しい」の証明ではない、という前提で結果を見ます。
補足として、削除アクションは安易に付けないこと、そしてネイティブの保持機能はバックアップではないため、重要データは別途バックアップを検討することも押さえておくとよいです。
結局のところ、いちばん効くのは 仕様を正しく理解し、その理解と検証結果を、第三者・一次情報で確かめること だと思います。
まとめ
公開情報が限られるため推測も多くなりましたが、「保持ポリシーの保持期間が、現役データの削除にも効く」という仕様は事実です。ここを取り違えると、設計もテストも、その誤りをまるごと引き継いでしまいます。だからこそ、出発点は正しい仕様理解です。
この機会に、自社のテナントでも保持ポリシーを棚卸しし、削除アクションが、どの場所のどのデータに効いているのか を確認してみてはいかがでしょうか。
