OneDrive（Web）の右クリックメニューに、削除したはずの「Lumin PDF で開く」が残り続ける——この症状は、ブラウザキャッシュだけでは解決しないことがあります。原因になりやすい“サーバー側キャッシュ”と“Entra ID（旧Azure AD）側の残設定”を、管理者／開発者が確実に潰す手順をまとめます。
現象：File Handler を削除したのに「Lumin PDF で開く」が表示され続ける
Microsoft Entra ID（旧 Azure AD）アプリに PDF 用の OneDrive/SharePoint File Handler を登録していた場合、OneDrive for Business（ブラウザ）や SharePoint Online のドキュメント ライブラリで、ファイルを右クリックしたときのメニューにアクション（例：「Lumin PDF で開く」）が表示されます。
ところが、アプリの addIns（File Handler マニフェスト）を削除したり、File Handler 設定を消したにもかかわらず、特定のテナント／特定ユーザーでだけ表示が残ることがあります。例えば「2024 年 6 月 19 日に File Handler 設定を削除したのに、一部の顧客環境では今も残っている」といった形で長期化するケースもあります。
典型的には、次のように“環境差”として現れます。
- 同じ日に設定を削除したのに、顧客Aは消えて顧客Bは残る
- 同一テナントでも、ユーザーXは消えてユーザーYは残る
- シークレットウィンドウでは消えるのに、普段のブラウザでは残る
前提：これは Windows のエクスプローラーではなく「OneDrive/SharePoint の Web UI」の問題
まず切り分けとして重要なのが、話題の「右クリックメニュー」がどの画面かです。本記事で扱うのは、OneDrive / SharePoint の Web 画面（ブラウザ）に出るファイル操作メニューです。
Windows エクスプローラー（ローカルの右クリック）に出る OneDrive のコンテキストメニューは、同期クライアントや権限（UAC）など別要因が絡むため、対処手順が異なります。Web UI で再現しているかを基準に進めてください。
なぜ消えないのか：File Handler の仕組みと「2つのキャッシュ」
File Handler は、OneDrive/SharePoint 上のファイルに対して「プレビュー」「開く」「カスタムアクション」などを追加できる Microsoft 365 の拡張機能です。File Handler 2.0 では、アプリ登録（Entra ID）にマニフェストをひも付け、OneDrive/SharePoint がその情報を参照して UI を構成します。
ここで厄介なのがキャッシュです。Microsoft Learn では、File Handler は ブラウザ ローカル と サーバー側 の二重でキャッシュされ、更新が反映されるまで 24〜48時間 かかる可能性がある、と明記されています。
さらに、OneDrive Web アプリには セッションキャッシュ があり、最後の OneDrive タブを閉じてブラウザセッションが終わるまで残る、という説明もあります。つまり「ブラウザのキャッシュ削除」だけでなく「OneDrive タブを全部閉じる」までセットでやらないと、見た目が変わらないケースが起こり得ます。
| キャッシュの種類 | どこにあるか | 症状の典型 | 効きやすい対処 |
|---|---|---|---|
| ブラウザ ローカル（ローカルデータ） | 端末のブラウザ | 同じ端末・同じプロファイルでだけ残る | サイトデータ削除、別プロファイル/シークレットで確認 |
| OneDrive Web のセッションキャッシュ | ブラウザのセッション | 更新したはずなのにタブを開きっぱなしだと残る | OneDrive のタブをすべて閉じ、再ログイン |
| サーバー側キャッシュ（テナント/ユーザー） | OneDrive/SharePoint 側 | 複数ユーザー・複数端末でも残る／一部ユーザーだけ残る | forceRefresh / adminForceRefresh で強制更新 |
まずは公式の標準手順を押さえる（実施済みでも「漏れ」確認に有効）
すでに実施済みであっても、チケット対応では「どこまでやったか」がズレやすいポイントです。まずは次が揃っているかを確認してください。
- サーバー側キャッシュ更新：
$forceRefresh=1（ユーザー単位）を実行した - ブラウザのローカルデータ削除（単なる閲覧履歴ではなく、サイトデータを含む）を実施した
- OneDrive のタブをすべて閉じて、セッションキャッシュを確実に終了させた
「ブラウザキャッシュ削除」「別プロファイルで再サインイン」までやっているのに残る場合、次章以降の “より強い” 手順に進むべき状態です。
マルチテナントで起こりやすい理由：App登録と Enterprise application は別物
顧客環境で“消えない”ときに見落としがちなのが、App registrations（アプリ登録） と Enterprise applications（エンタープライズ アプリケーション） の関係です。
Microsoft Learn では、アプリ（Application object）は「グローバルな定義」で、サービス プリンシパル（Service principal）は「特定テナント内のローカル表現」と説明されています。また、マルチテナントアプリは、同意した各テナントにサービス プリンシパルが作成されるため、顧客テナント側では Enterprise applications として管理されます。
この構造のため、開発者が自社テナントでマニフェストを削除しても、顧客テナント側では「Enterprise application が残っている」「割り当てが残っている」などの状態差が出やすく、結果として OneDrive/SharePoint の表示が揃わないことがあります。まずは顧客テナント側の Enterprise applications を確認する、という順番が重要です。
最初に確認するチェックポイント
“消えない”と判断する前に、管理者／開発者側で次を確認してください。ここが曖昧だと、キャッシュ更新をしても「別の場所に残っていた設定」を見落として同じ現象に見えます。
| 確認項目 | 具体的な確認方法 | よくある落とし穴 | 優先度 |
|---|---|---|---|
| File Handler マニフェストが本当に消えているか | アプリ マニフェスト（addIns）や登録手順で、FileHandler 定義が空になっているか確認 | 別環境（ステージ/本番）や別アプリIDの方を消していた | 高 |
| 顧客テナント側に「エンタープライズ アプリ」が残っていないか | 顧客テナントの Entra 管理センターで、該当アプリ（Lumin PDF）が Enterprise applications に存在するか | “アプリ登録を消した”のに、顧客テナントのサービス プリンシパルは別途残っていた | 高 |
| ユーザー/グループ割り当てが残っていないか | Enterprise applications の「Users and groups」で割り当て確認 | 割り当てが残ると利用可能状態が続く（可視性やアクセス管理にも影響） | 高 |
| 現象が OneDrive と SharePoint のどちらで起きているか | 個人の OneDrive（My Files）とサイト ライブラリ（SharePoint）で再現するか比較 | 画面によりキャッシュの参照元や表示ロジックが異なることがある | 中 |
| 影響範囲がテナント全体か、特定ユーザーのみか | 別ユーザーで同じファイルを開き、表示されるかを確認 | ユーザー単位キャッシュに閉じているのにテナント側だけを疑う | 中 |
推奨対処フロー：管理者／開発者側でできる“強い”解消手順
通常のキャッシュ削除で改善しない場合、Entra ID 側の残設定の除去 と、OneDrive/SharePoint 側キャッシュの強制更新 をセットで行うのが最短です。
Entra ID（エンタープライズ アプリケーション）から Lumin PDF を完全に削除する
Microsoft Q&A でも、File Handler を削除したのに UI に残り続ける原因として「サーバー側キャッシュが消えない」ことが挙げられており、対処として アプリの完全削除 と キャッシュ強制更新 が推奨されています。
- 顧客テナントの Entra 管理センターで、該当アプリを検索
- アプリが残っている場合は、割り当て（Users and groups）を解除
- 不要なら Enterprise application 自体を削除（削除できない要件があるなら、少なくとも割り当て解除と File Handler の定義削除を徹底）
補足：ユーザー／グループ割り当ての管理は Entra 管理センターの標準機能で、割り当て・解除手順も公開されています。手順が属人化しないように、顧客向けのスクリーンショット付き手順書にしておくと運用が安定します。
テナント全体のキャッシュ強制リフレッシュ（$adminForceRefresh=1）
Microsoft Learn の手順では、テナント管理者が $adminForceRefresh=1 を付けて呼び出すことで、全ユーザーに影響するアプリ キャッシュ をリフレッシュできると説明されています。変更（割り当て、hidden、アプリ更新など）の可視性に効くため、「一部ユーザーだけ残る／テナント内でバラつく」ときにまず実施するのが定石です。
呼び出し先（例）は次の通りです。
GET https://{tenant}.sharepoint.com/_api/v2.0/drive/apps?$adminForceRefresh=1
Authorization: Bearer {access-token}- 呼び出しは1時間に1回まで（全ユーザーに影響し得るため制限あり）
- アクセストークンは Microsoft Graph ではなく、SharePoint/OneDrive 側のAPI（OneDrive API）用に取得します
- トークンには SharePoint アプリケーションの
MyFiles.WriteまたはSites.Read.All相当の権限が必要です
実務では、顧客テナントの管理者に実行してもらうか、運用委任されている管理アカウントで実行します。影響が広い操作なので、業務時間外に実施する、実施ログを残す、などの運用ルールも併せて決めておくと安心です。
ユーザー単位のキャッシュ強制リフレッシュ（$forceRefresh=1）
テナント全体で更新しても、特定ユーザーの UI にだけ残るケースがあります。その場合は、ユーザーの OneDrive（-my.sharepoint.com）に対して $forceRefresh=1 を付けて呼び出し、ユーザー観点のキャッシュ を再読み込みさせます。
GET https://{tenant}-my.sharepoint.com/_api/v2.0/drive/apps?$forceRefresh=1
Authorization: Bearer {access-token}この API は「キャッシュを更新する指示」を出しますが、レスポンスは“現時点のキャッシュ値”を返す、と説明されています。つまり、呼び出し直後に UI が即座に変わらないことがあるため、次の「セッションの切り直し」とセットで行うのがコツです。
ユーザー側での再サインイン（セッションキャッシュを確実に捨てる）
サーバー側が更新されても、ブラウザに残るセッションキャッシュで表示が継続することがあります。ユーザーには次を依頼してください。
- OneDrive からサインアウト
- OneDrive を開いているブラウザのウィンドウ／タブをすべて閉じる（特に OneDrive のタブ）
- 新しいウィンドウで再度サインインし、OneDrive を開いて右クリックメニューを確認
「サインアウトしたのに変わらない」という報告の多くは、別タブで OneDrive が開いたまま、または同一セッションが残ったままになっているのが原因です。依頼文をテンプレ化し、“タブを全部閉じる”まで含めて案内すると再現率が下がります。
反映確認のおすすめ手順
- シークレット/プライベート ブラウズで OneDrive を開き、同じファイルでメニューを確認（ローカル要因の排除）
- 同一テナントで 別ユーザーでも確認（ユーザー単位キャッシュかどうかの判定）
- OneDrive（My Files）と SharePoint サイト ライブラリの両方で確認（画面差分の判定）
実務でハマりやすいポイントと追加の対処
「アプリは消せない」事情がある場合の現実解
Microsoft Q&A でも、Lumin PDF アプリが別目的で使われていて削除できない、というケースが議論されています。その場合はアプリ自体の削除ではなく、File Handler の定義（addIns）を確実に空にする、そしてキャッシュ更新（adminForceRefresh/forceRefresh）を行う、という進め方になります。
運用上は次のどちらを採用するかを決めておくと混乱が減ります。
| 方針 | メリット | デメリット | 向いているケース |
|---|---|---|---|
| アプリ（Enterprise application）を完全削除 | 最も確実に UI から消える | 他用途で使っている場合は不可 | File Handler 専用アプリとして運用している |
| アプリは残し、addIns だけ撤去＋キャッシュ更新 | 他用途を壊さずに File Handler だけ外せる | キャッシュがしつこい環境では手順が増える | 同一アプリIDで別機能も提供している |
URL の取り違え（.sharepoint.com と -my.sharepoint.com）
adminForceRefresh と forceRefresh は、呼び出すホストが異なります。ここを間違えると「叩いたのに変わらない」の原因になります。
| 目的 | ホスト | パラメーター | 対象 |
|---|---|---|---|
| テナント全体のアプリ キャッシュ更新 | https://{tenant}.sharepoint.com | $adminForceRefresh=1 | 全ユーザー |
| ユーザー観点のキャッシュ更新 | https://{tenant}-my.sharepoint.com | $forceRefresh=1 | 特定ユーザー |
API を叩いたのに消えないときのチェック
- 誤って別テナントのURLを使っていないか（顧客テナント名の取り違え）
- 管理者キャッシュ更新は1時間に1回制限があるため、短時間に繰り返していないか
- ユーザーが OneDrive のタブを開きっぱなしで、セッションキャッシュが残っていないか
Microsoft サポートにエスカレーションするなら、ここまで揃える
キャッシュ更新を試しても一部環境で再現し続ける場合、Microsoft 側で調査が必要になることがあります。エスカレーション前に、少なくとも次の情報を整理すると往復が減ります。
| 収集する情報 | 例 | 目的 |
|---|---|---|
| 影響範囲 | 単一テナント/複数テナント、特定ユーザーのみ/全体 | ユーザーキャッシュかテナントキャッシュかの切り分け |
| 再現画面 | OneDrive（My Files）/ SharePoint ライブラリ | UI の参照元の違いを特定 |
| 実施済み手順 | addIns削除、Enterprise app削除/割り当て解除、adminForceRefresh/forceRefresh 実行の有無 | 二重対応を防ぐ |
| 日時（UTC含む） | File Handler削除日、キャッシュ更新実行日 | バックエンドの伝播状況と突合 |
| スクリーンショット | 右クリックメニューが表示された状態 | “同名の別アプリ”などを除外 |
再発防止：File Handler を安全に撤去するための運用ベストプラクティス
同じ問題を繰り返さないために、File Handler を“入れる”ときだけでなく“外す”ときの運用も設計しておくことが重要です。特にB2B（顧客テナント）で提供する場合、撤去時の負荷が顧客側に発生しやすいからです。
- File Handler 専用のアプリIDを分ける：他機能と同居させると「アプリは消せない」状況になりやすい
- 撤去手順をテンプレ化：Enterprise app の確認→割り当て解除→adminForceRefresh→forceRefresh→再サインイン、を1枚にまとめる
- 段階的な無効化：いきなり削除ではなく、まずユーザー割り当てを外して影響を絞る
- 変更連絡に“最大反映時間”を含める：File Handler は 24〜48時間のキャッシュがあり得ることを前提に、問い合わせ窓口のFAQを整備
よくある質問
forceRefresh を実行したのに、直後のレスポンスに古い情報が返ってきます
仕様として、forceRefresh は「更新を指示する」もので、レスポンスはキャッシュの現在値を返す、と説明されています。呼び出し後に OneDrive のタブを閉じてセッションを切り、再度 OneDrive を開いて UI を確認してください。
adminForceRefresh と forceRefresh はどちらを先にやるべきですか
基本は adminForceRefresh（テナント全体）→ forceRefresh（ユーザー） の順が扱いやすいです。テナント全体の可視性に関わるキャッシュを先に揃え、その後に残る“個別ユーザーだけの問題”を潰す流れが効率的です。
「Lumin PDF で開く」が一部ユーザーにだけ残ります
ユーザー単位のキャッシュが残っている可能性が高いので、forceRefresh の実行と、OneDrive タブを完全に閉じた上での再サインインをセットで実施してください。
まとめ
OneDrive の「Lumin PDF で開く」が消えないときは、単なるブラウザキャッシュではなく、OneDrive/SharePoint 側に残るサーバーキャッシュや、顧客テナント側に残る Enterprise application（割り当て）が根本原因であることが多いです。
対処としては、(1) Entra ID 側の残設定の除去、(2) テナント全体の $adminForceRefresh、(3) ユーザー単位の $forceRefresh、(4) OneDrive タブを閉じる再サインイン、を順に実施することで、再現率の高い解消フローを組めます。
コメント