Windows 11 に更新した途端、SharePoint の「エクスプローラーで開く（フォルダー階層で使う）」運用が崩れ、リンクが消えたり、クリックしてもブラウザーで開いてしまうケースが増えています。本記事では原因を整理し、WebDAV・Edge の設定・OneDrive 同期で“エクスプローラー運用”へ寄せる現実的な解決策をまとめます。
Windows 11で「SharePointのフォルダー構造リンク」がブラウザーで開く症状を整理
社内に「旧来型の SharePoint サイト（クラシック寄り・エクスプローラー表示前提の運用）」と、「新しい SharePoint（OneDrive 同期や“ショートカット追加”が前提の運用）」が混在していると、PC の OS 更新タイミングで問題が顕在化しやすくなります。
| よくある症状 | 現場での困りごと | 起きやすい環境 |
|---|---|---|
| “エクスプローラー用リンク”が消えた／メニューに出ない | フォルダー階層で辿れず、作業手順が崩れる | Windows 11、モダン UI のライブラリ |
| リンクをクリックするとブラウザーで開く | ファイル操作に時間がかかり、誤操作（ダウンロード乱発等）が増える | 旧リンク（IE 依存）やプロトコルがブロックされている端末 |
| Windows 10 では開けるのに Windows 11 では開けない | 移行した端末だけ手順が異なり、問い合わせが増える | Windows 11（IE 前提の動作が成立しない） |
| ネットワークドライブ割り当てができない／認証がループする | フォルダー運用を続けたいが、接続が安定しない | WebClient 無効、プロキシ/条件付きアクセス、MFA など |
原因：Windows 11で旧来の「エクスプローラー直結運用」が崩れやすい理由
ポイントは、「SharePoint をエクスプローラーで扱う仕組み」が、従来のブラウザー（特に IE 前提の仕組み）から、Edge＋ポリシー＋テナント設定を組み合わせた“管理者が許可する方式”へ寄ってきたことです。Microsoft 365 のサービス側では IE11 のサポート終了以降、従来の“View in File Explorer / Open with Explorer”を推奨せず、OneDrive 同期を推奨する流れが明確になっています。
そのため、昔ながらの「URL をそのままエクスプローラーで開く」「お気に入りに入れていた“エクスプローラー用リンク”を使う」といった運用は、Windows 11 側の既定の関連付けや、Edge の保護（外部アプリ起動・スキーム制御）により、意図どおりに動かないことがあります。特に、ユーザー権限だけで復旧しようとしても、組織のポリシーで止められていると詰みやすいのが現実です。
| 旧来の考え方 | Windows 11 / 現行の考え方 | 結論 |
|---|---|---|
| リンクを押せばエクスプローラーで開く | 既定はブラウザー、必要なら“許可された仕組み”で開く | 「正式な接続手段」に寄せる必要がある |
| IE 前提の仕組みでも社内なら使える | Edge での機能提供はポリシーとテナント設定が前提 | 管理者の関与がほぼ必須 |
| フォルダー階層＝ネットワークドライブが正義 | 日常運用は OneDrive 同期（またはショートカット）が主流 | 長期的には運用移行が最も安定 |
解決策：Windows 11でSharePointをエクスプローラー表示に寄せる3つのルート
結論から言うと、Windows 11 で “URL 直叩きでエクスプローラーを開く” を再現しようとするより、次のいずれかに寄せたほうが再現性が高く、サポートされやすいです。
- 旧来型サイト向け：WebDAV でネットワークドライブ割り当て（WebClient 必須）
- SharePoint Online（モダン）向け：Edge の「View in File Explorer」を管理者が有効化
- 新しい運用向け：OneDrive の「同期」または「OneDrive にショートカットを追加」
旧来型サイト向け：WebDAVでネットワークドライブとして割り当てる
旧来型サイトを“フォルダー階層で運用”している場合、いちばんイメージに近いのが WebDAV でのネットワークドライブ化です。Windows の WebDAV クライアント（WebClient サービス）が動作していることが前提になります。
まず確認したい前提条件
| チェック項目 | 確認方法 | 満たせない場合 |
|---|---|---|
| SharePoint 側が WebDAV 接続を許容している | 同じサイトで他端末が WebDAV で接続できるか、IT 部門に確認 | OneDrive 同期へ移行検討（現実的） |
| 端末で WebClient サービスが有効 | services.msc → WebClient を確認 | ポリシーで無効なら利用者側では不可 |
| 認証方式が WebDAV と相性が悪くない | 条件付きアクセス/MFA の設計を IT 部門に確認 | Edge の「View in File Explorer」や同期へ |
| プロキシ環境で WinHTTP 経由アクセスが詰まらない | 社内プロキシ・バイパス設定の有無を確認 | 資格情報ループ・拒否が出やすい |
WebClient サービスを起動・自動化する
GUI で行う場合：
- Windows の検索で「services.msc」を開く
- 一覧から WebClient を探す
- 状態が「停止」なら開始
- スタートアップの種類を「自動」に変更（運用で毎回止まるのを防ぐ）
PowerShell で行う場合（管理者権限が必要なことがあります）：
Set-Service -Name WebClient -StartupType Automatic
Start-Service -Name WebClientWebDAV パス（DavWWWRoot）の考え方
ネットワークドライブ割り当てでよく使われるのが、次の形式です。
\\{ホスト名}@SSL\DavWWWRoot\{サイトの相対パス}「DavWWWRoot」は WebDAV クライアントに“ここが WebDAV のルートだ”と伝えるためのキーワードとして扱われます。
例（社内例に近いイメージ）：
\\teamsites.company.com@SSL\DavWWWRoot\sites\PACURL から組み立てる目安を表にすると、次のようになります（実際のパスはサイト構成・ライブラリ名で変わります）。
| ブラウザーで開く URL の例 | WebDAV パスの例 | メモ |
|---|---|---|
| https://teamsites.company.com/sites/PAC | \\teamsites.company.com@SSL\DavWWWRoot\sites\PAC | サイト単位（ルート） |
| https://teamsites.company.com/sites/PAC/Shared%20Documents | \\teamsites.company.com@SSL\DavWWWRoot\sites\PAC\Shared Documents | ライブラリ名にスペースがある場合に注意 |
| https://{tenant}.sharepoint.com/sites/ProjectA | \\{tenant}.sharepoint.com@SSL\DavWWWRoot\sites\ProjectA | SharePoint Online でも原理は同様だが、認証設計で詰まりやすい |
ネットワークドライブの割り当て手順
- エクスプローラーを開く
- 「PC」→「ネットワーク ドライブの割り当て」
- ドライブ文字を選ぶ（例：S:）
- フォルダーに WebDAV パスを入力
- 必要なら「別の資格情報を使用して接続」にチェックして認証
- 成功すれば、エクスプローラーに“フォルダー階層”として表示される
WebDAV運用でハマりやすいポイントと対処
WebDAV は「昔ながらの“ファイル共有に寄せた操作”」ができる一方で、SharePoint 本来の機能（バージョン、共同編集、メタデータ、権限の粒度など）とは相性が悪い場面もあります。現場で炎上しやすいところだけ先回りしておきます。
| 症状 | ありがちな原因 | 対処の方向性 |
|---|---|---|
| 資格情報を何度も聞かれる／拒否される | WebClient（WinHTTP）経由のアクセスでプロキシ/認証が噛み合っていない | IT 部門に WinHTTP/プロキシ バイパス・認証方式の確認を依頼（端末側の小手先では限界） |
| 「このリストを Windows Explorer で開けません」系のエラー | WebClient 停止、WebDAV 非対応、または接続要件未達 | WebClient を有効化、もしくは OneDrive 同期へ切り替え |
| 動作が重い／ファイル操作が遅い | WebDAV の特性（大量ファイル、深い階層、ネットワーク品質） | “頻繁に触る領域だけ”同期、運用ルールで対象を絞る |
| 同時編集や履歴が期待どおりでない | エクスプローラー操作は SharePoint の UI 機能を迂回する | 変更管理が必要な領域ほど SharePoint UI / Office 連携で扱う |
なお、WebClient サービスは WebDAV 接続の要であり、Windows の WebDAV リソース連携で利用されます。環境によってはプロキシ構成や認証の影響を受け、資格情報プロンプトやアクセス拒否につながることがあるため、ネットワーク/セキュリティ側の設計が重要です。
SharePoint Online向け：Edgeの「View in File Explorer」を管理者設定で有効化する
SharePoint Online（モダン ライブラリ）で「エクスプローラーに寄せた一時的な操作」をしたい場合は、Microsoft Edge の View in File Explorer を組織で有効化するのが“公式ルート”です。既定ではメニューに表示されないため、Edge のポリシー設定とSharePoint テナント設定の両方が必要になります。
利用条件（満たしていないと“出ない・動かない”）
| 要件 | 内容 | コメント |
|---|---|---|
| Microsoft Edge 93 以降 | View in File Explorer の仕組みが搭載されている | 端末更新で自然に満たすことが多い |
| 組織管理下の Windows | AD ドメイン参加、または管理下の Pro/Enterprise（MDM など） | 個人端末・BYOD は要件で詰まりがち |
| Edge ポリシー ConfigureViewInFileExplorer | 許可するドメインと認証 cookie（rtFa, FedAuth）を指定 | GPO/Intune などで配布 |
| SharePoint テナント設定 | ViewInFileExplorerEnabled を True にする | 管理者が PowerShell で設定 |
Edge 側は「viewinfileexplorer:」スキームを用いて、許可された SharePoint ドメインの WebDAV URL をエクスプローラーへ橋渡しします。許可ドメインと cookie を明示しないと動かないのがポイントです。
管理者が行うこと：Edge ポリシー（ConfigureViewInFileExplorer）
グループポリシー（GPO）または Intune で、Edge のポリシー ConfigureViewInFileExplorer を設定します。基本は「許可する SharePoint のドメイン」と「認証に必要な cookie（rtFa, FedAuth）」を JSON で渡します。
例（概念をつかむためのサンプル）：
[{"cookies": ["rtFa", "FedAuth"], "domain": "sharepoint.com"}]テナント単位で限定したい場合は、ドメインを contoso.sharepoint.com のように指定します（複数指定も可能）。
| 設定場所 | 設定名 | ポイント |
|---|---|---|
| GPO / Intune | Configure the View in File Explorer feature for SharePoint pages in Microsoft Edge | 許可ドメインと cookie を JSON で指定 |
| 端末で確認 | edge://policy/ | 反映後にポリシーが見える（再起動が必要な場合あり） |
管理者が行うこと：SharePoint Online のテナント設定を有効化
SharePoint Online Management Shell でテナント設定を変更し、ライブラリ UI に「View in File Explorer」を表示できるようにします。
Connect-SPOService -Url https://contoso-admin.sharepoint.com
Set-SPOTenant -ViewInFileExplorerEnabled $True注意点として、Management Shell のバージョンが一定以上でないと ViewInFileExplorerEnabled が利用できない旨が案内されています。
利用者が行うこと：ライブラリから「View in File Explorer」を開く
設定が通っていれば、Edge でドキュメント ライブラリを開いたときに、表示メニュー付近から「View in File Explorer」を選べるようになります。さらに、動作には永続 cookie が必要なため、サインイン時の「サインインしたままにしますか？」に Yes を選ぶ必要がある点が重要です。
仕様上の制限：一時フォルダーであることを理解して使う
「View in File Explorer」は、日常的な“同期フォルダー”を作る機能ではありません。エクスプローラーで開く先は一時的なフォルダーで、閉じると維持されません。用途は「一度だけファイルをまとめて移動・コピーしたい」などに向きます。
また、エクスプローラー経由で移動・コピーする場合、バージョン履歴が引き継がれないなどの制約が明記されています。監査や履歴が重要な業務では、SharePoint 側の「移動先」「コピー先」を使う運用も検討してください。
新しい運用向け：OneDrive同期で“エクスプローラー表示”を標準化する
Windows 11 で安定して “エクスプローラーで扱える状態” を作るなら、最終的には OneDrive 同期（Sync）、または OneDrive にショートカットを追加へ寄せるのが最もトラブルが少ないです。Microsoft 側も View in File Explorer を推奨せず、同期クライアントの利用を推奨するスタンスを明確にしています。
同期（Sync）の基本手順
- ブラウザーで SharePoint のドキュメント ライブラリを開く
- 上部メニューの「同期」を選択
- OneDrive アプリが起動し、同期設定が完了すると、エクスプローラーにライブラリが表示される
「OneDrive にショートカットを追加」と「同期」の違い
同じように見えて、運用上は差が出るポイントがあります。Microsoft の案内では、どちらも OneDrive 同期アプリを使って“日常的に使えるフォルダー”を作りますが、ショートカット追加は複数デバイスでの利用やパフォーマンス面に利点がある、という位置付けです。
| 比較項目 | OneDrive にショートカットを追加 | 同期（Sync） |
|---|---|---|
| フォルダーの“常設感” | 常設（OneDrive 配下にショートカットとして残る） | 常設（その端末の同期設定として残る） |
| 利用できる範囲 | 複数デバイスで同じショートカットを使いやすい | 基本的に“その端末”の同期設定 |
| パフォーマンスの傾向 | 改善されたパフォーマンスが期待できる旨の案内 | 一般的な同期 |
| おすすめ用途 | 普段使いの参照・共同作業の入り口を統一したい | その端末でオフライン利用も含めて作業したい |
どの方法を選ぶべきか：現場判断の早見表
「旧サイトのフォルダー運用を維持したい」のか、「Windows 11 を機に運用を正したい」のかで、最適解は変わります。迷ったら次の表で当てはめるのが早いです。
| 手段 | 向いているケース | 管理者対応 | 安定性 | 推奨度 |
|---|---|---|---|---|
| WebDAV ネットワークドライブ | 旧来型サイト、どうしてもフォルダー階層運用を継続したい | WebClient 許可/有効化が必要なことが多い | 環境依存（認証・プロキシで揺れる） | 短期の延命 |
| Edge の View in File Explorer | SPO のモダン ライブラリで一時的にエクスプローラー操作が必要 | Edge ポリシー＋SPO テナント設定が必須 | 条件を満たせば比較的安定 | 限定用途 |
| OneDrive 同期 / ショートカット | 日常運用をエクスプローラーで行いたい（推奨の形） | 利用許可とガイド整備（必要に応じて制御） | 最も安定しやすい | 長期の本命 |
社内ITポリシーでブロックされている場合の“現実的な落としどころ”
質問の追記のように、WebClient の起動や WebDAV の利用、Edge のポリシー変更、テナント設定が 社内 IT ポリシーでブロックされている場合、利用者権限だけでの回避は難しくなります。その場合は「お願いの仕方」を具体化し、IT 部門が判断しやすい材料を揃えるのが最短ルートです。
IT部門に依頼するときの要点（そのまま転記できる形）
| 依頼項目 | 目的 | IT 部門が確認すべき観点 |
|---|---|---|
| WebClient サービスの有効化可否 | 旧サイトを WebDAV でドライブ割当して継続運用したい | セキュリティポリシー、端末標準化、サポート範囲 |
| Edge ポリシー ConfigureViewInFileExplorer の適用 | SPO ライブラリで「View in File Explorer」を使いたい | 許可ドメイン、cookie 指定、監査/運用ルール |
| SPO テナント設定 ViewInFileExplorerEnabled の有効化 | メニュー表示そのものを出したい | 対象テナント、反映範囲、利用部門の限定 |
| OneDrive 同期/ショートカット運用の標準化 | 中長期で問い合わせを減らし、運用を安定させたい | 同期対象の上限設計、端末容量、教育・手順書 |
長期的に効く対策：旧サイトを“同期前提の構造”へ寄せる
旧来型サイトを延命し続けるほど、「OS 更新」「ブラウザー更新」「認証強化（MFA/条件付きアクセス）」の波で、同じトラブルが繰り返されがちです。業務影響が大きいなら、次の方向で“再発しない設計”へ寄せるのが結果的に安くつきます。
- 旧サイトの重要ライブラリを洗い出し、更新頻度・容量・権限構造で棚卸しする
- 利用者が日常的に触る領域は OneDrive 同期/ショートカット前提の運用へ移す
- 「エクスプローラー用リンク」の配布をやめ、SharePoint のライブラリ URL（または Teams のファイルタブ）を正とする
- どうしても必要な“一時的な大量移動”は View in File Explorer を限定的に許可する
現場での事故を減らす運用のコツ
同じ「エクスプローラー表示」でも、手段ごとに“事故ポイント”が違います。ルールを一つ決めるだけで問い合わせが激減することが多いので、次のような形で社内ルールに落とし込むのがおすすめです。
| 運用ルール | 狙い | 現場メリット |
|---|---|---|
| 日常作業は OneDrive 同期/ショートカットを基本にする | 環境差（Windows 10/11）を吸収する | 手順が統一され、教育コストが下がる |
| 大量コピー・移動のときだけ View in File Explorer を使う | 一時フォルダーの特性を踏まえて限定利用 | 目的が明確でトラブルが減る |
| 旧サイトの WebDAV ドライブ割当は“例外対応”にする | 依存を増やさない | OS/認証変更時の影響を抑えられる |
| リンク集は「SharePointのライブラリURL」を正とする | 旧来の“エクスプローラー用リンク”を排除 | 誰でも同じ入口から辿れる |
まとめ：Windows 11では“リンク復旧”より“正規ルートへ寄せる”のが近道
Windows 11 で SharePoint のフォルダー構造リンクがエクスプローラーで開かずブラウザーで開く場合、原因の多くは「旧来の前提が崩れた」ことにあります。短期的には WebDAV のドライブ割当で延命できますが、安定運用を狙うなら Edge の View in File Explorer を管理者設定で整備するか、OneDrive 同期/ショートカットで日常運用を標準化するのが現実的です。組織ポリシーでブロックされている場合は、依頼項目を具体化して IT 部門と合意し、旧サイト依存を段階的に減らすのが最も再発しにくいルートになります。
コメント