SharePoint Online のドキュメント セットを「移動先（Move to）」で移動したところ、移動先にはちゃんと存在するのに、元の場所には大量の削除アイテムがごみ箱に現れて驚いた――そんな経験をしている管理者・担当者は少なくありません。本記事では、この“コピーして削除”に見える挙動を整理し、同一ライブラリ内でも起きる理由と影響、そして運用でのベストプラクティスまで、現場でそのまま使えるレベルで詳しく解説します。
SharePoint Online の「移動先」で実際に何が起きているのか
まずは、ドキュメント セットに対して「移動先（Move to）」を実行したとき、実際にどのような処理が行われているかを整理します。
対象となるのは「ドキュメント セット」＋配下のすべて
今回の話題の主役は、単一のファイルやフォルダーではなく、ドキュメント セット（Document Set）です。ドキュメント セットは、複数のファイルやフォルダーをひとまとまりの「案件」や「製品」などとして管理するための、SharePoint 固有のコンテンツ タイプです。
- ドキュメント セットそのもの（コンテナ）
- その配下に含まれるすべてのファイル
- その配下のフォルダーと、フォルダー内のファイル
- それぞれに設定されたメタデータ・バージョン履歴・権限
「移動先」を実行すると、上記すべてをまとめて別の場所へ移動させることになります。ここでポイントになるのが、SharePoint Online はこの処理を“コピーして削除”として実装しているとみなすべき、という点です。
観測されている挙動（2025年9月時点）
実機検証の結果として、2025年9月時点で以下の挙動が確認されています。
| 移動パターン | 移動先の状態 | 元の場所の状態 | ごみ箱 |
|---|---|---|---|
| 同一ライブラリ内での「移動先」 （同じドキュメント ライブラリ内の別フォルダーなど） | ドキュメント セットと配下のファイル／フォルダーが 期待どおりに存在 | ドキュメント セットと配下のアイテムは削除済み | 元のドキュメント セットおよび配下アイテムが サイトのごみ箱に入る |
| 別ライブラリへの「移動先」 （同一サイト内の別ライブラリなど） | ドキュメント セットと配下のアイテムが作成される | 元の場所から削除 | 同様に、ごみ箱に元のアイテムが入る |
| 別サイト／別サイト コレクションへの「移動先」 | 新たなサイト側にドキュメント セットが作成される | 元のサイトから削除 | 元サイト側のごみ箱に元のアイテムが入るのが一般的 |
重要なのは、「同一ライブラリ内の移動」であっても、元のアイテムがごみ箱に入る点です。多くのユーザーは、同一ライブラリ内の移動を「単なる場所の付け替え（真の移動）」とイメージしがちです。しかし、ドキュメント セットに関しては、実際にはコピー → 元のアイテムを削除という手順で動作しており、その副作用としてごみ箱に大量のアイテムが現れます。
これは仕様か？「コピー→削除」として見るべき理由
では、この挙動はバグなのか、仕様なのか。公式ドキュメントで明確に「こう動く」と書かれているわけではありませんが、現時点では「設計どおり（by design）として扱うのが妥当」と言えます。
ドキュメント セットが「特別扱い」される理由
ドキュメント セットは通常のファイルやフォルダーよりも多くの情報を抱えています。例えば次のような要素です。
- カスタム メタデータ（案件名、顧客名、期別属性など）
- ドキュメント ID（一意な識別子とリンク先としての役割）
- バージョン履歴（過去版の保持と復元の履歴）
- 固有の権限（案件ごとに異なるアクセス権など）
SharePoint Online はクラウドサービスとして、これらの情報を極力失わずに移動する必要があります。そのため、シンプルな“場所の付け替え”ではなく、「コピーして、新しい場所で整合性を確保してから、元のアイテムを削除する」という安全側の処理になっていると考えるのが自然です。
結果として、ユーザーから見ると次のように見えます。
- 移動先には、ドキュメント セットと中身がすべて存在している
- 元の場所には、アイテムは存在せず、ごみ箱に「削除済み」として並ぶ
つまり、「移動先」ボタンであっても、内部的には“コピー→削除”モデルで動いていると理解するのがポイントです。
過去との違い：「前はごみ箱に入らなかった気がする」問題
実務でよく出る声が、次のようなものです。
- 「2025年1月頃に、別ライブラリ間の移動ではごみ箱に入らなかった記憶がある」
- 「以前は真の移動のように見えていた」
クラウドサービスである SharePoint Online は、テナント単位や時期によって微妙に挙動が異なっていた可能性があります。サービス側の更新や、バックエンド実装の統一などによって、現在は「コピー→削除」に統一されていると考えられます。
このため、運用上は「今どう動いているか」を基準に設計することが重要です。過去の挙動や他テナントの事例ではなく、自分のテナントで必ずテストを行い、それを前提にルールやガイドを作成しましょう。
ごみ箱に与える影響と、現場で起こりがちな誤解
ドキュメント セットの「移動先」が“コピー→削除”として動作することで、現場にはさまざまな影響が出てきます。特に多いのが、ユーザーの誤解と、ごみ箱運用の問題です。
「誤削除されたのでは？」という問い合わせが増える
同じドキュメント セットを何度も移動したり、複数のドキュメント セットをまとめて移動すると、そのたびに元のアイテムがごみ箱にたまっていきます。その結果、ユーザーは次のように感じます。
- 「ごみ箱を見たら大量に削除されていた。誰かが消したのでは？」
- 「いつの間にか案件フォルダーがごみ箱に入っていた」
実際には、正常な移動処理の結果としてごみ箱に入っているだけなのですが、画面上は「削除済み」としか見えないため、誤解を招きやすくなります。
ごみ箱の容量・保持期間にも一時的な負荷がかかる
SharePoint Online のサイトごみ箱には容量制限と保持期間があります。大量のドキュメント セットを移動すると、削除アイテム（＝ごみ箱アイテム）が一時的に急増します。
- 短期間に多くのドキュメント セットを移動 → ごみ箱が急に膨らむ
- ごみ箱の確認・管理にかかる手間が増える
- 保持ポリシー（情報ガバナンス）と組み合わさると、削除のタイミングが読みづらくなる
特に、訴訟ホールドや保持ポリシーを設定している環境では、「削除したつもりでも保持される」「ごみ箱から完全に削除されない」といった動きが加わるため、運用設計の重要度が増します。
誤復元による「重複」と整合性崩れ
ごみ箱に元のドキュメント セットが入っている状態で、ユーザーが不用意に「復元」を行うとどうなるでしょうか。
- 移動先：正しく運用されている最新のドキュメント セット
- 復元した元の場所：古い構造や権限を持つドキュメント セット
このように、同じ案件を表すドキュメント セットが 2 個並ぶ状態が発生します。どちらが「正」とすべきかが分かりづらくなり、ユーザーはどちらにファイルをアップロードするべきか迷ってしまいます。場合によっては、同じ案件ドキュメントが分散して保存されてしまい、監査や検索での重複も発生します。
運用ベストプラクティス：こう設計すればトラブルを減らせる
ここからは、現行挙動を前提にしたうえで、実務で取り入れやすい運用ルールやベストプラクティスを整理します。
ユーザーへの周知：ごみ箱に見えても「正常動作」であることを明示
まず最優先で行いたいのは、「ドキュメント セットの移動後にごみ箱にアイテムが見えても、それ自体は正常動作である」と明示的に伝えることです。具体的には、次のような周知・ガイドが考えられます。
- チームサイト内の「使い方ガイド」ページに、スクリーンショット付きで解説を載せる
- 部門向けの運用マニュアルに、「移動先」と「ごみ箱」の関係を追記する
- IT ヘルプデスクの FAQ に、「移動後にごみ箱にアイテムがあるのは普通です」という項目を追加
ポイントは、「ごみ箱にあるからといって、誰かが削除したとは限らない」「移動操作の副作用である」というメッセージを、ユーザーにもわかる言葉で伝えることです。
ごみ箱と保持ポリシーの管理：大規模移動前には事前確認を
大量のドキュメント セットを移動する前には、ごみ箱容量と保持ポリシーを事前に確認しておくことをおすすめします。
| 確認項目 | ポイント |
|---|---|
| サイトごみ箱の容量 | 同時に移動するドキュメント セット数 × 平均サイズをざっくり見積もり、許容範囲か確認 |
| ごみ箱の保持期間 | どれくらいの期間ごみ箱に残るのかを把握し、事故復元のリスク期間を意識する |
| 保持ポリシー（Retain / Delete） | 情報ガバナンスの設定により、「削除」しても裏で保持されている可能性がある |
特に、移行プロジェクトや大規模なライブラリ整理のタイミングでは、これらを事前に確認し、状況によっては移動を分割して実施するなど、計画的に進めることが重要です。
移動は「小分け」に：段階的な移動でリスクと負荷を抑える
一度に大量のドキュメント セットをまとめて移動すると、次のような問題が発生しがちです。
- ごみ箱が一気に膨らみ、管理が難しくなる
- 誤動作や設定ミスがあった場合、影響範囲が大きくなる
- ユーザーからの問い合わせが集中する
これを避けるために、「小分けにして移動する」運用を徹底することをおすすめします。
- 1 回あたりの移動件数を決めておく（例：1 日 10 セットまでなど）
- 移動後の結果を都度確認しながら、数日に分けて段階的に実施
- 問題があれば、早い段階で運用や手順を修正できる
移動後の品質確認：スポットチェックで「本当に正しく移ったか」を見る
ドキュメント セットは構造が複雑なため、移動後の品質確認（スポットチェック）が欠かせません。すべての案件をフルチェックするのは現実的ではありませんが、代表サンプルに絞って以下を確認しましょう。
- ドキュメント セット自体のメタデータ（案件名、ステータスなど）が正しく残っているか
- 配下ファイルのバージョン履歴が保持されているか
- ドキュメント ID を利用している場合、想定どおり参照できるか
- 権限が想定どおりか（特定ユーザー／グループのアクセス権が失われていないか）
これらをチェックリスト化しておき、移動後に最低限のサンプル検証を行うよう運用ルールに組み込むと安心です。
ごみ箱からの復元は原則禁止：必要な場合は管理者経由にする
もっとも重要なルールのひとつが、「ドキュメント セットを含むアイテムについて、ごみ箱からの復元をユーザーに行わせない」ことです。
- ユーザーには「復元しないでください」と明確に伝える
- どうしても復元が必要なケースは、IT 管理者のみが実施するようにする
- 復元前に、移動先の状態と整合性を確認し、復元後の重複発生を想定したうえで対応する
このルールを徹底することで、重複ドキュメント セットや整合性崩れの発生を大幅に抑えることができます。
代替オプション：あえて「コピー先 → 検証 → 旧側削除」とする手順
運用上、移動のタイミングを厳密にコントロールしたい場合には、あえて次のような手順を取ることも有効です。
- まず「コピー先（Copy to）」で新しい場所にドキュメント セットをコピーする
- 新しい場所で、メタデータ・履歴・権限などを十分に検証する
- 問題がないことを確認したうえで、旧側を計画的に削除する
最終的な結果は「移動先」とほぼ同じですが、検証や周知の時間を確保しやすいというメリットがあります。また、「コピー済み（仮稼働） → 本格稼働 → 旧側の凍結・削除」という段階を踏むことで、ユーザー側の混乱も軽減できます。
よくある質問（FAQ）を押さえておく
現場でよく出る質問と、その回答のポイントを整理します。ヘルプページや FAQ にそのまま流用できる形でまとめておくと便利です。
これは新機能？仕様変更？
Q. これは最近追加された新機能や、仕様変更なのでしょうか？
A. 公式の大々的な告知は確認されていませんが、現行の SharePoint Online では「コピー→削除」が標準挙動として観測されています。過去にはテナントや時期によって異なる挙動を示していた可能性もあるため、現在の実機挙動を基準に運用を設計することが重要です。
バージョン履歴やメタデータは保たれる？
Q. 「コピー→削除」として動作すると、バージョン履歴やメタデータは失われませんか？
A. ドキュメント セットの「移動先」は、整合性を保ちながら新しい場所に内容を再構成することを目的とした処理と考えられます。一般的には、メタデータやバージョン履歴は維持される想定ですが、環境やカスタマイズ状況によって例外もあり得ます。必ず代表サンプルでの検証を行い、自分のテナントでの実際の挙動を確認してください。
復元するとどうなる？
Q. ごみ箱からドキュメント セットを復元すると、どうなりますか？
A. 移動先にすでにドキュメント セットが存在する場合、元の場所にも同名のドキュメント セットが復活し、重複が発生する可能性が高いです。その結果、どちらが最新か分かりづらくなり、ユーザーの混乱やデータの整合性崩れを招きます。復元が本当に必要な場合は、管理者が影響を評価したうえで慎重に実施するべきです。
異なるサイト／サイト コレクション間では？
Q. 異なるサイトやサイト コレクション間で「移動先」を使うときも、同じような動作になりますか？
A. 本記事の主題は主に同一サイト内ですが、異なるサイト／サイト コレクション間でも「コピー→削除」パターンが一般的です。ただし、環境による差異が残る可能性もあるため、本番適用前には必ずテスト用サイトで小規模な検証を行うことをおすすめします。
すぐできる確認手順：自分のテナントの挙動をチェックしよう
最後に、自分の環境でドキュメント セットの「移動先」がどのように動いているかを確認するための、簡単な手順を紹介します。
- テスト用のドキュメント ライブラリを作成するか、既存ライブラリにテスト用のドキュメント セットを作成する
- ドキュメント セットに、複数のファイルとサブフォルダー、いくつかのメタデータ（列）を設定する
- そのドキュメント セットに対して、「移動先」操作を実行し、まずは同一ライブラリ内の別フォルダーに移動してみる
- 移動先で、メタデータ・バージョン履歴・権限などが期待どおりかを確認する
- 元の場所にドキュメント セットが存在しないことを確認し、サイトのごみ箱を開いて、元のアイテムが削除アイテムとして入っているか確認する
- 同様に、別ライブラリや別サイトにもテストとして移動し、挙動の違いがないかを確認する
- 確認結果をもとに、自社用の運用ガイド／マニュアルを更新する
この手順を一度実施しておくだけでも、「現行の仕様を前提にした運用設計」がしやすくなり、現場でのトラブルや問い合わせを大幅に減らすことができます。
まとめ：ドキュメント セットの「移動先」は“コピー→削除”として扱う
本記事で説明してきたように、SharePoint Online におけるドキュメント セットの「移動先」操作は、同一ライブラリ間でも別ライブラリ間でも、“コピー→削除”として動作する現行仕様とみなすべきです。その結果、元の場所のアイテムがサイトのごみ箱に入るため、見かけ上「削除された」ように見えますが、これは正常な挙動です。
運用上は、次のポイントを押さえておくことが重要です。
- ごみ箱にアイテムが多く見えても、「移動の副作用」である場合があるとユーザーに周知する
- 大規模移動の前には、ごみ箱容量と保持ポリシーを確認しておく
- 移動は小分けに実施し、移動後の品質をスポットチェックする
- ごみ箱からの復元は原則禁止とし、例外的な復元は管理者のみが行う
- 必要に応じて、「コピー先 → 検証 → 旧側削除」という段階的な手順も検討する
これらを組み合わせることで、「ごみ箱に入る＝異常」という誤解を取り除きつつ、ドキュメント セットの移動を安全かつスムーズに運用することができます。SharePoint Online の仕様を味方につけ、現場にとって分かりやすく、ガバナンスにも配慮した運用を整えていきましょう。
コメント