SharePoint Onlineで、Microsoft Entra ID（旧Azure AD）から削除したはずのユーザーが、ファイルの「アクセスの管理（Manage Access）」に残り続けることがあります。実はこれは権限が復活しているわけではなく、SharePoint側に残るユーザー記録が原因です。背景と、表示を整理する具体的な手順をまとめます。
結論：残るのは「仕様として起こり得る動き」。まずは落ち着いて切り分ける
先に結論だけ押さえると、Entra ID（Azure AD）でユーザーを削除しても、SharePoint Online側の画面にそのユーザー名が残るケースはあります。多くの場合、これはSharePointがサイト内に保持しているユーザー情報リスト（User Information List）の記録が残ることに起因し、いわゆる孤立ユーザー（orphaned users）として見える、表示上の“残骸”のような状態です。
重要なのは、次の2点を分けて考えることです。
- 本当に権限が残っているのか（セキュリティ上の問題）
- 権限は失われているが表示だけ残っているのか（管理画面の整理の問題）
この記事では、なぜこの現象が起きるのかを仕組みから説明しつつ、UI操作・PowerShellの両面で「アクセスの管理」から見えなくするための実務的な対応策を整理します。
なぜ削除済みユーザーが残るのか：User Information Listという“台帳”がある
SharePoint Onlineは、ユーザーやゲストがサイトに初めてアクセスしたり、共有を受け取ったり、何らかの形でサイト内で解決（Resolve）されたタイミングで、そのサイト（正確にはサイト コレクション）に紐づく非表示リストにユーザー情報を保存します。これがUser Information List（ユーザー情報リスト）です。
User Information Listに記録が残る理由
User Information Listが自動で消えにくい背景には、SharePointの「履歴を保つ」性質があります。たとえば、次のような情報を表示するために、ユーザーの参照が必要になります。
- リストやライブラリの「作成者」「更新者」
- バージョン履歴、コメント、共同編集の履歴
- 過去に共有した相手の表示（共有履歴・監査の文脈）
- People列（ユーザー/グループ列）に保存された過去の値
Entra ID側でユーザーを削除すると、そのユーザーは認証できなくなります。一方でSharePoint側は、過去データの参照を壊さないために、サイト側のユーザー台帳（User Information List）のレコードを自動削除しない設計になっていることがあります。
「アクセスの管理」に表示が残る仕組み
「アクセスの管理（Manage Access）」は、ファイル/フォルダーに対するアクセス経路（リンク・直接付与・グループなど）を可視化する画面です。ここでユーザー名が残る主なパターンは次のとおりです。
- 共有リンク（特定のユーザー）の対象として残っている
- 直接アクセス（Direct access）として権限エントリが残っている
- 画面上の表示名解決のためにUser Information Listの情報が参照され、“ユーザーは存在しないが表示だけ出る”ように見える
いずれのパターンでも、Entra IDから削除済みであれば通常はサインインできず、実アクセスは成立しません。ただし「見た目上の整理」として、管理画面から消したい要望が出るのは自然です。
このように「Entra IDでは削除済みなのに、SharePoint側の画面や一覧に名前が残って見える」状態を、現場では便宜上孤立ユーザー（orphaned users）と呼ぶことがあります。本質は“アクセスできるか”ではなく、“SharePoint側に残るユーザー参照をどう扱うか”です。
放置しても大丈夫？影響の整理（セキュリティと運用）
「削除済みユーザーが残る」という表現は不安を誘います。そこで、影響を表にまとめます。
| 観点 | 起きていること | リスク/影響 | まず確認すること |
|---|---|---|---|
| 認証 | Entra ID上のユーザーが削除されている | 通常はサインイン不可。アクセスは成立しない | アカウントが「削除」か「無効化/ブロック」か |
| 権限 | SharePoint側に過去の権限エントリや共有リンクの情報が残ることがある | 表示上は残るが、削除済みなら実アクセスは不可のケースが多い | 「直接アクセス」「リンク」など、どの経路で表示されているか |
| 監査/履歴 | 作成者・更新者・履歴表示のため、サイト内にユーザー参照が残る | 履歴整合性のため保持されることがある | 履歴を重視する運用か（削除の影響許容） |
| 運用 | 管理者や所有者が画面を見たときに混乱する | 棚卸し時のノイズ、監査対応時の説明コスト | 定期点検の対象にするか、都度クリーンアップするか |
ポイントは、セキュリティ事故＝即危険と直結しないことが多い一方で、運用上はノイズになるため、組織によってはクリーンアップが必要になる点です。
最初にやるべき切り分け：本当に「権限」が残っているのか
ユーザー情報リストの話に入る前に、まずは“権限として残っているのか”を切り分けます。現場で混乱しやすいポイントなので、チェック順を固定しておくと事故が減ります。
切り分けチェックリスト
- 「アクセスの管理」でどの枠に出ているか確認
例：リンク（Links giving access）／直接アクセス（Direct access）／グループ（Groups）など - 共有リンクが残っているなら、リンク自体を削除（停止）できないか
“特定のユーザー”リンクの場合、対象ユーザーが削除済みでもリンクが残っていることがあります - 直接アクセスなら、そのユーザーの権限を削除できないか
画面の「…」メニューに「直接アクセスの削除」などが出る場合があります - ファイル/フォルダーが「固有のアクセス許可」か確認
ライブラリ継承か、アイテム単位で付与が残っているかで対応が変わります - サイト全体の権限画面（サイトのアクセス許可/詳細なアクセス許可）でも残っているか確認
この切り分けで「権限エントリとして残っている」ことが確定したら、まずは権限（または共有リンク）を削除するのが基本です。それでも表示が残る／削除操作がうまくいかない／大量に残っている、といったときに、User Information Listのクリーンアップが現実的な選択肢になります。
UIでクリーンアップする方法：People and Groups（All People）から削除する
「アクセスの管理」から“名前だけ”を消したい場合、サイトに残っているユーザー記録を整理することで解消することがあります。代表的な入口が、次のURLです。
これは、いわゆる「People and Groups」のAll Peopleビュー（そのサイトに解決されたユーザー一覧）にアクセスするためのURLです。ここから対象ユーザーを削除すると、関連する画面の表示が整理されることがあります。
操作前の注意点（ここだけは必ず読む）
- 実行には、通常サイト コレクション管理者や十分な権限が必要です。
- ユーザー情報リストの整理は、過去履歴の表示（作成者/更新者など）に影響する可能性があります。監査・履歴を重視する環境では慎重に行ってください。
- サイトが複数ある場合、User Information Listはサイト（サイト コレクション）ごとに存在します。別サイトの表示は別途対応が必要です。
- 画面キャッシュや反映遅延で、削除後もしばらく表示が残ることがあります。ブラウザーの再読み込み、時間を置く、プライベートブラウズで確認なども併用します。
手順（UI）
- 対象のファイル/フォルダーがあるサイトを開きます（管理対象のサイトURLを確認）。
- ブラウザーのアドレスバーに、
/_layouts/15/people.aspx?MembershipGroupId=0を付けてアクセスします。 - 一覧から対象ユーザーを検索します（表示名、メールアドレス、ログイン名で探せる場合があります）。
- 対象ユーザーを選択し、メニューから「削除」「サイトから削除」「Delete Users」等の操作を実行します（表示言語やUIにより文言は異なります）。
- 「アクセスの管理」画面に戻り、表示が整理されたか確認します。
この方法は「画面から消す」ことが目的です。権限自体の整理が必要な場合は、後述するPowerShellでの権限棚卸しや、共有リンクの再設計（期限付きリンク・ゲスト制御）も併せて検討すると、再発を抑えられます。
PowerShellでクリーンアップする方法：少数の対応から大量一括まで
サイトが多い、削除対象が多い、定期的に棚卸ししたい──こうしたケースではPowerShellの出番です。実務上は、公式のSharePoint Online Management Shellでの削除と、柔軟性の高いPnP PowerShellの2系統を押さえておくと対応範囲が広がります。
方法の比較
| 方法 | 向いているケース | メリット | 注意点 |
|---|---|---|---|
| UI（people.aspx） | 単発/少数、原因切り分け | 直感的、すぐ試せる | 大量処理に不向き、サイトごとに手作業 |
| SharePoint Online Management Shell | サイト管理者が明確、標準寄りで実施したい | Microsoft提供の管理コマンドでシンプル | 対象サイトURLの把握が必要 |
| PnP PowerShell | 一括/自動化、レポート作成、条件付き削除 | 取得系が豊富で棚卸ししやすい | 権限設計・認証方式の整備が必要 |
SharePoint Online Management Shellでの削除例（Remove-SPOUser）
サイト コレクションからユーザーを削除するイメージで、表示を整理できる場合があります。コマンド例は次のとおりです（テナント/認証方式に合わせて調整してください）。
# 事前に SharePoint Online Management Shell を準備
# Connect-SPOService でテナント管理URLに接続してから実行します
$siteUrl = "[https://tenant.sharepoint.com/sites/ProjectA](https://tenant.sharepoint.com/sites/ProjectA)"
$loginName = "[[email protected]](mailto:[email protected])"
# サイト コレクションからユーザーを削除
Remove-SPOUser -Site $siteUrl -LoginName $loginName この方法はシンプルですが、「ログイン名が正確に分からない」「大量に対象がある」「削除対象を条件で絞りたい」といったニーズがあると、PnP PowerShellのほうが運用しやすいことが多いです。
PnP PowerShellでの削除例（Remove-PnPUser）
PnP PowerShellでは、サイトに接続してユーザーを検索し、見つかった場合だけ削除するといった制御が書けます。例：
# 例：サイト配列を回して対象ユーザーを削除（最小構成）
# 実運用ではログ出力や事前確認（Dry Run）を強く推奨します
$sites = @(
"[https://tenant.sharepoint.com/sites/ProjectA](https://tenant.sharepoint.com/sites/ProjectA)",
"[https://tenant.sharepoint.com/sites/ProjectB](https://tenant.sharepoint.com/sites/ProjectB)"
)
$target = "[[email protected]](mailto:[email protected])"
foreach ($site in $sites) {
Connect-PnPOnline -Url $site -Interactive
# まずはサイトに存在するか確認
$u = Get-PnPUser -Identity $target -ErrorAction SilentlyContinue
if ($null -ne $u) {
Remove-PnPUser -Identity $u.LoginName -Force
Write-Host ("Removed: {0} from {1}" -f $u.LoginName, $site)
} else {
Write-Host ("Not found: {0} in {1}" -f $target, $site)
}
} 現場でよくあるのが、同名ユーザーや外部ユーザー（ゲスト）のログイン名が「メールアドレスそのまま」ではないケースです。その場合は、まず Get-PnPUser で一覧を出し、ログイン名（LoginName）を特定した上で削除するのが安全です。
一括作業で事故らないための実務ポイント
- いきなり削除しない：まずは対象ユーザーの抽出レポートを作り、影響範囲（どのサイトに残っているか）を可視化してから実行します。
- 権限棚卸しとセットで：表示を消す前に、共有リンクや直接アクセスが残っていないか（または残っていても問題ないか）を確認します。
- ログを必ず残す：いつ、誰が、どのサイトで、どのユーザーを削除したかをCSV等に出力しておくと、監査対応が楽になります。
- 小さく試してから横展開：まずはテストサイトや影響の少ないサイトで再現→解消を確認してから本番サイトへ広げます。
「自動クリーンアップ」はある？Entra ID削除とSharePointのギャップ
結論として、少なくとも一般に公開されている標準機能としては、Entra ID側でユーザーを削除したら、SharePoint側のUser Information Listも自動的に消えるという統一的な仕組みは用意されていない運用が多いです。
その理由としては、次のような事情が絡みます。
- 履歴・監査の整合性：作成者/更新者などの参照が消えると、過去データの読み取りが難しくなる
- サイト単位の台帳：User Information Listはサイト（サイト コレクション）に紐づくため、テナント全体で一律に消すと副作用が出やすい
- 権限と表示の層が違う：認証（Entra）と、サイトに保存されたユーザー参照（SharePoint）が別レイヤーで動く
機能改善を期待するなら「フィードバック」を残しておく
この挙動は多くの管理者が遭遇するため、同様の要望がフィードバックとして挙がり続けています。組織として改善を後押ししたい場合は、次のルートで要望を残しておくと、社内の困りごとを可視化できます。
- Microsoft 365 管理センターからのフィードバック送信
- 関連するフィードバック/アイデア投稿サイト（Microsoftの公式フィードバック導線）での要望投稿
要望を書くときは「どの画面に残るのか（アクセスの管理／サイトのユーザーなど）」「どの運用で困っているのか（監査、棚卸し、外部共有）」を具体的に添えると、意図が伝わりやすくなります。
とはいえ、運用上の不便は確実にあるため、今後の改善に期待したい領域でもあります。機能改善を追う場合は、Microsoft 365管理センターの告知や関連ロードマップも定期的にチェックしておくとよいでしょう。
再発を減らす運用設計：削除だけで終わらせない
「削除済みユーザーがアクセスの管理に残る」問題は、突き詰めると“共有と権限の運用”が根にあります。クリーンアップは対処療法になりがちなので、同時に再発防止の設計も入れると効果的です。
おすすめの運用フロー（例：退職・委託終了時）
| タイミング | やること | 目的 | ポイント |
|---|---|---|---|
| アカウント停止前 | 共有リンクと直接アクセスの棚卸し | 不要な共有を先に切る | 特定のユーザーリンクは残りやすいので重点確認 |
| 停止/削除当日 | Entra IDでブロックまたは削除 | 認証を確実に止める | まずは“入れなくする”が最優先 |
| 停止/削除後 | 必要に応じてUser Information Listを整理 | 管理画面のノイズを減らす | 履歴影響を許容できる範囲で実施 |
| 月次/四半期 | 外部共有ポリシーと共有リンクの点検 | 再発を抑える | 期限付きリンク、共有範囲制限の見直し |
“表示だけ残る”を前提にした説明テンプレ
監査や情報システム部門の問い合わせでよくあるのが、「画面に残っている＝アクセスできるのでは？」という疑義です。チーム内で説明文を揃えておくと混乱を減らせます。
- 「ユーザーはEntra IDで削除済みのためサインインできず、実アクセスはできません」
- 「SharePointは履歴表示のため、サイト内にユーザー参照が残ることがあります」
- 「必要に応じてサイトのユーザー一覧（All People）から表示を整理します」
よくある質問（現場で詰まりやすいポイント）
削除しても同じ名前がまた出てきます。なぜ？
削除対象が実は別のサイト（別サイト コレクション）に残っていたり、同じ表示名の別ユーザーが存在していたり、共有リンクが別経路で残っているケースがあります。まずは「どのサイトのどのファイルか」を固定し、そのサイトのAll Peopleとそのファイルの共有リンク/直接アクセスをセットで確認すると切り分けが進みます。
“Unknown User”のような表示に変わるだけで、完全に消えません
履歴参照やアイテムの作成者/更新者の整合性を保つために、完全に参照が消えず“未知のユーザー”として残ることがあります。管理画面上のノイズが問題なら、共有リンクや直接アクセスの整理を優先し、履歴表示の完全消去を狙いすぎないほうが運用は安定します。
ゲストユーザー（外部ユーザー）も同じですか？
同様の現象が起きやすいです。外部共有は「特定のユーザー」リンクやゲスト招待の履歴が残りやすく、User Information Listにもレコードが作られます。まずは外部共有の棚卸し（リンクの停止、共有の取り消し）を行い、必要に応じてサイト側のユーザー削除を検討してください。
この操作は安全ですか？やってはいけないケースは？
“安全かどうか”は、何を重視するかで変わります。履歴（作成者/更新者）を厳格に保ちたい、監査で人名表示が必須、という環境では、User Information Listの削除を最小限にし、権限と共有リンクの整理だけで終えるほうが良い場合があります。逆に、履歴よりも運用の分かりやすさを優先する現場では、表示整理の価値が高いこともあります。
まとめ：実務での着地点
- Entra IDでユーザーを削除しても、SharePoint Onlineの「アクセスの管理」に名前が残ることがある。
- 多くはUser Information Listに残る記録が原因で、アクセス権そのものとは切り分けが必要。
- まずは「共有リンク」「直接アクセス」など、権限エントリの整理を優先する。
- 表示整理が目的なら、
/_layouts/15/people.aspx?MembershipGroupId=0（All People）からの削除や、PowerShellによるクリーンアップを検討する。 - 自動クリーンアップに頼りにくい前提で、退職・外部共有の運用フローに“棚卸し＋必要時クリーンアップ”を組み込むと再発が減る。
コメント