SharePoint OnlineのCSP（Content Security Policy）対応で最初に確認すべきことは、外部CDNやインラインスクリプトに依存するSPFxソリューションが止まる可能性があるかです。標準的にJavaScriptをSPFxパッケージ内に含めている場合、影響は比較的限定的です。一方、SPComponentLoader.loadScript()で外部スクリプトを動的に読み込む実装や、Script Editor系のWebパーツでインラインスクリプトを使っている環境では、設定変更または実装変更が必要になります。Microsoft Learnの「Support for Content Security Policy (CSP) in SharePoint Online」は2026年5月8日に更新され、CSPの施行、延期、Trusted script sources、違反ログの確認方法が整理されています。(Microsoft Learn)
SharePoint / OneDriveを管理している組織では、標準機能そのものよりも、SharePointページ上で動くカスタムSPFx、外部ライブラリ、社内ポータル部品、ベンダー製アプリを重点的に点検してください。Microsoft 365のSharePointとOneDriveは、組織のコンテンツ、ナレッジ、アプリケーションを共有・管理するクラウドサービスとして管理対象になるため、展開計画やガバナンスの観点ではセットで確認しておくのが実務的です。(Microsoft Learn)
SharePoint OnlineのCSP対応で何が変わるのか
CSPは、ブラウザーに対して「このページで読み込んでよいスクリプトやリソースの場所」を制御させるセキュリティ機能です。XSS、クリックジャッキング、コードインジェクションなどの攻撃リスクを下げる目的で使われます。SharePoint Onlineでは、このCSPを使って、許可されていない場所からのスクリプト読み込みを制限する方向に進んでいます。(Microsoft Learn)
公式情報では、CSPはSharePoint Onlineでレポートモードとして展開され、CSPの施行開始日として2026年3月1日が示されています。また、既存のSPFxソリューションを確認・更新する時間が必要な場合は、SPO Management Shellで90日間、2026年6月1日まで施行を延期できる設定が用意されています。(Microsoft Learn)
実務上のポイントは、次の3つです。
| 確認項目 | 管理者・開発者が見るべきポイント |
|---|---|
| 施行タイミング | テナントでCSPがレポートのみなのか、施行済みなのか、延期設定を使っているのかを確認する |
| 影響範囲 | SPFxソリューション、外部CDN、動的スクリプト読み込み、インラインスクリプトを洗い出す |
| 対応方法 | Trusted script sourcesへの追加、SPFxパッケージ構成の見直し、インラインスクリプトの外部ファイル化を行う |
重要なのは、「CSP対応＝SharePoint / OneDrive全体が急に使えなくなる」という話ではないことです。影響の中心は、SharePoint Online上で動作するカスタムソリューションや外部スクリプトです。特に、過去に社内ポータルや部門サイトを柔軟にカスタマイズしてきた組織ほど、早めの棚卸しが必要です。
影響を受けやすいSPFxソリューションのパターン
SharePoint Onlineの標準設定では、SharePoint Onlineが自身で利用するスクリプトと、SPFxパッケージ内に含まれるスクリプトは読み込めるように構成されています。新しいSPFxソリューションの既定では、JavaScriptバンドルがパッケージに含まれ、インストール時にサイトのClientSideAssetsフォルダーへ展開されます。(Microsoft Learn)
一方で、外部の場所からスクリプトを読み込む構成では、CSPの影響を受ける可能性があります。
| 実装パターン | CSPでの影響 | 対応の考え方 |
|---|---|---|
| SPFxパッケージ内にJavaScriptを含める | 基本的に影響は小さい | 標準的な構成。まずはこの方式か確認する |
cdnBasePathで外部CDNに配置する | SharePointがTrusted script sourcesへ追加する場合がある | CDNパス、末尾スラッシュ、登録状態を確認する |
externalsで外部ライブラリを読み込む | SharePointがTrusted script sourcesへ追加する場合がある | 利用ライブラリのURLが正しく許可されているか確認する |
SPComponentLoader.loadScript()で動的に読み込む | 既定のCSP設定に影響されやすい | Trusted script sourcesへ手動追加するか、実装を見直す |
| インラインスクリプトを使う | ブロック対象になりやすい | 外部JavaScriptファイルへ移す |
| Script Editor系Webパーツでスクリプトを挿入する | 追加したスクリプトが実行されない可能性がある | HTML表示とスクリプト実行を分けて移行方針を決める |
公式ドキュメントでは、cdnBasePathやexternalsを使うケースでは、SharePointがTrusted script sourcesに値を追加すると説明されています。ただし、SPComponentLoader.loadScript()やインラインスクリプトのような読み込み方は、既定のCSP設定の影響を受けるため注意が必要です。(Microsoft Learn)
管理者が最初に確認すべき設定
CSP施行の延期設定を確認する
CSP施行に対する準備が間に合わない場合、公式ドキュメントでは次のSPO Management Shellコマンドで90日間延期できるとされています。設定後に値を再取得する手順も、設定を正しく保持するための必須ステップとして示されています。(Microsoft Learn)
Set-SPOTenant -DelayContentSecurityPolicyEnforcement $true
(Get-SPOTenant).DelayContentSecurityPolicyEnforcementこの設定は、単に「延期すればよい」というものではありません。延期期間は、影響調査と改修のための猶予です。延期を設定した場合でも、次の作業を並行して進めてください。
| 作業 | 目的 |
|---|---|
| SPFxソリューションの棚卸し | どのアプリが外部スクリプトを使っているか把握する |
| 外部CDNの一覧化 | Trusted script sourcesに追加すべきURLを整理する |
| インラインスクリプトの調査 | ブロックされる可能性が高い実装を先に洗い出す |
| Purviewログの確認 | 実際にCSP違反が出ているページとURLを特定する |
| 検証環境でのテスト | 本番施行前にページ表示やWebパーツ動作を確認する |
Trusted script sourcesを確認する
SharePoint Onlineでは、既定のCSP設定に加えて、SharePoint管理センターのTrusted Script Sourcesに登録された場所をCSPヘッダーへ追加できます。管理画面では、SharePoint Online Admin CenterのAdvancedからScript sourcesへ進み、ソースの追加または編集を行います。(Microsoft Learn)
登録するソースは、できるだけ狭く指定するのが基本です。たとえば、特定のjQueryファイルだけが必要なら、CDN全体ではなく該当ファイルのURLを指定する方が安全です。
| 許可したい範囲 | 指定例 | 判断基準 |
|---|---|---|
| 特定のファイルだけ | https://cdn.jsdelivr.net/npm/[email protected]/dist/jquery.min.js | 最も限定的。バージョン固定したい場合に向く |
| 特定フォルダー配下 | https://cdn.jsdelivr.net/npm/ | 複数ファイルを同一フォルダー配下で使う場合 |
| 特定ドメイン全体 | https://cdn.jsdelivr.net | ドメイン内の複数パスを使う場合 |
| サブドメイン全体 | *.jsdelivr.net | 複数サブドメインを使う場合。ただし範囲が広い |
公式FAQでは、フォルダーを指定する場合は末尾スラッシュが重要で、https://cdn.jsdelivr.net/npm/*のような指定は機能しないと説明されています。また、*、*.domain、'unsafe-inline'、'wasm-unsafe-eval'、'strict-dynamic'のように過度に広いCSP式は許可されません。Trusted Script Sourcesの最大件数は300件です。(Microsoft Learn)
300件上限に近い場合は登録方法を見直す
Trusted Script Sourcesの上限に近い場合、ビルドごとに異なる一意のURLを追加し続ける運用は危険です。自動デプロイで毎回異なるスクリプトURLが追加される構成では、上限に早く到達する可能性があります。公式ドキュメントでは、ワイルドカードなどを使ってソースを統合することや、テナントアプリカタログ由来の自動追加ソースを再同期する方法が示されています。(Microsoft Learn)
Set-SPOTenant -ResyncContentSecurityPolicyConfigurationEntries $true
(Get-SPOTenant).ResyncContentSecurityPolicyConfigurationEntries再同期は最大24時間かかる場合があります。手動追加したTrusted sourcesは削除されず、テナントアプリカタログ由来の自動追加ソースは、重複を避ける形で再構成されます。サイトコレクションアプリカタログ由来の自動追加ソースは、同期ジョブで削除されない点にも注意が必要です。(Microsoft Learn)
開発者が確認すべき実装と修正ポイント
インラインスクリプトは外部ファイル化する
最も優先して見直すべきなのは、インラインスクリプトです。公式ドキュメントでは、インラインスクリプトを使っているSPFxソリューションについて、スクリプトファイルへ移すことが推奨されています。nonce値を取得してインラインスクリプトを許可する方法は利用できないため、インラインのまま回避しようとする設計は避けるべきです。(Microsoft Learn)
見直し対象になりやすい実装は次の通りです。
| 見直し対象 | 例 | 推奨対応 |
|---|---|---|
HTML内のscriptタグ | <script>...</script> | JavaScriptファイルへ移動する |
| イベント属性 | onclick="..."、onload="..." | イベントリスナーで実装する |
javascript: URL | <a href="javascript:..."> | 通常のリンクまたはクリックイベントに置き換える |
document.write()による挿入 | document.write("<script>...") | DOM操作と外部ファイル読み込みに分ける |
innerHTMLでのスクリプト挿入 | element.innerHTML = "<script>..." | サニタイズし、スクリプト実行に依存しない構成へ変える |
社内ポータルでよくある失敗は、「HTMLを表示できるからスクリプトも動くはず」と考えてしまうことです。公式ドキュメントでは、Script Editor Webパーツとその派生では、追加されたHTMLは引き続き機能する一方、ユーザーが追加したスクリプトは実行されないと説明されています。(Microsoft Learn)
cdnBasePathの末尾スラッシュを確認する
cdnBasePathを設定しているSPFxソリューションでは、末尾スラッシュの有無を確認してください。公式ドキュメントでは、cdnBasePathに末尾スラッシュがない場合、Trusted script sourcesに追加されたエントリを手動で更新し、末尾スラッシュを追加する必要があるとされています。将来的には自動化される予定とされていますが、既に追加済みのソリューションでは手動対応が必要です。(Microsoft Learn)
実務では、次のように確認します。
| 確認場所 | 見る内容 |
|---|---|
./config/write-manifests.json | cdnBasePathのURLと末尾スラッシュ |
| SharePoint管理センター | Trusted script sourcesに登録されたURL |
| ブラウザーコンソール | CSP違反としてブロックされているURL |
| Purview監査ログ | BlockedUrlとDocumentUrl |
externalsで読み込むライブラリはバージョン管理も含めて確認する
./config/config.jsonのexternalsに外部ライブラリを定義している場合、対象URLがTrusted script sourcesに正しく登録されているか確認します。たとえば、CDN上のライブラリをバージョン固定で読み込んでいるなら、セキュリティ面ではファイル単位の指定が適しています。複数バージョンを頻繁に切り替える場合は、フォルダー単位やドメイン単位の許可が必要になることもありますが、許可範囲が広がる分だけリスクも増えます。
判断基準は、「運用のしやすさ」ではなく「本当にその範囲のスクリプトを信頼できるか」です。ベンダーCDN、社内CDN、Microsoft 365 CDN、Azure CDNなど、管理主体が異なるソースを同じ扱いにしないようにしてください。
CSP違反の確認方法
ブラウザーの開発者ツールで確認する
CSPに違反するスクリプトが読み込まれると、ブラウザーのコンソールにエラーが出ます。公式ドキュメントの例では、[Report Only] Refused to load the script ...のようなメッセージが表示され、どのCSPディレクティブに違反したか、どのURLが問題になったかを確認できます。(Microsoft Learn)
開発者が見るべきポイントは、エラーメッセージの最初に出てくるブロック対象URLです。長いCSPヘッダーの中に多数の許可済みURLが表示されるため、慣れていないと原因を見失いやすくなります。まずは「どのURLを読み込もうとして失敗したのか」を特定してください。
Microsoft Purviewの監査ログで確認する
SharePoint Onlineでは、CSP違反がブラウザーのコンソールだけでなくMicrosoft Purviewにも記録されます。PurviewのAuditで、Activityのフレンドリ名Violated Content Security Policyまたは操作名ViolatedContentSecurityPolicyを検索すると、CSP違反を確認できます。(Microsoft Learn)
監査ログでは、特に次の2項目が重要です。
| 項目 | 意味 | 使い方 |
|---|---|---|
DocumentUrl | CSP違反が発生したSharePoint Online上のページ | 影響を受けるサイト・ページを特定する |
BlockedUrl | CSP設定に違反したスクリプトURL。インライン起因の場合はinlineを含む | 追加すべきTrusted sourceや修正対象コードを判断する |
管理者はPurviewのログから全体像を把握し、開発者はブラウザーコンソールで個別ページの再現と修正確認を行う、という役割分担が効率的です。
施行前後のテスト方法
公式ドキュメントでは、対象ページのURLにcsp=enforceパラメーターを追加することで、CSP施行時の挙動を検証できるとされています。レポートモードで確認したい場合は、csp=reportを使います。(Microsoft Learn)
| テスト方法 | 用途 |
|---|---|
?csp=report | ブロックせずに違反ログを確認したい場合 |
?csp=enforce | 実際にCSPが施行された状態で動作確認したい場合 |
検証では、単にページが表示されるかだけでなく、Webパーツのボタン、検索、グラフ表示、外部API連携、フォーム送信、タブ切り替えなど、ユーザー操作を伴う機能まで確認してください。スクリプトは初期表示ではなく、クリック後や遅延読み込み時に実行されることが多いためです。
SharePoint / OneDrive管理者向けの影響範囲整理
OneDriveを含めて確認するときは、「OneDrive同期クライアントやファイル保管そのものの設定変更」と「SharePoint Online上で動くページ・アプリのCSP対応」を切り分けることが重要です。今回の公式情報はSharePoint OnlineのCSPとSPFxソリューションが中心です。したがって、OneDrive利用者全員に一律の作業を依頼するより、まずはSharePoint管理センター、アプリカタログ、SPFxソリューション、社内ポータル、外部スクリプト利用箇所を確認する方が効果的です。(Microsoft Learn)
特に確認すべき場所は次の通りです。
| 対象 | 確認内容 |
|---|---|
| テナントアプリカタログ | 登録済みSPFxパッケージ、外部CDN利用、古いWebパーツ |
| サイトコレクションアプリカタログ | 部門単位で追加されたSPFxソリューション |
| 社内ポータル | Script Editor系Webパーツ、埋め込みHTML、外部ウィジェット |
| ベンダー製アプリ | CDN、外部ドメイン、更新予定、CSP対応状況 |
| Microsoft Purview | CSP違反が実際に発生しているページとスクリプト |
| SharePoint管理センター | Trusted script sourcesの登録内容と件数 |
OneDriveの観点では、ユーザーのファイル同期や保存容量よりも、OneDriveやSharePointのWeb画面からアクセスするカスタムページ、共有リンク先、社内ポータルへの導線で問題が出ないかを確認してください。
展開時に失敗しやすいポイント
CSP対応では、設定を追加したのに動かない、原因URLを見間違える、許可範囲を広げすぎる、といった失敗が起きやすくなります。
| 失敗しやすいポイント | 原因 | 対策 |
|---|---|---|
| Trusted sourceを追加したのにリスト画面で反映されない | リストやライブラリのローカルキャッシュの影響 | 時間を置くか、SHIFT+F5またはCTRL+F5で強制更新する |
| CDNフォルダー指定が効かない | 末尾スラッシュや指定形式が不適切 | https://example.com/path/のように正しい形式で指定する |
unsafe-inlineを追加しようとする | インラインスクリプトを許可したい | 許可されないため、外部ファイル化する |
| 300件上限に達する | ビルドごとに異なるURLを登録している | ソースを統合し、必要に応じて再同期する |
Purviewにinline違反が出る | SPFx以外にブラウザー拡張がHTMLを書き換えている場合がある | 該当ページで拡張機能を無効化して再現確認する |
| クラシックページで再現しない | CSPは非クラシックページのスクリプトに施行される | モダンページ側で検証する |
公式FAQでは、リストやライブラリのページではキャッシュの影響で新しいCSPヘッダーがすぐ反映されない場合があり、強制更新で反映を促せると説明されています。また、ブラウザー拡張がページHTMLを書き換えることで、SPFxがないページでもインラインスクリプト違反が出る可能性があります。(Microsoft Learn)
SharePoint Add-insとクラシックページは別枠で考える
公式ドキュメントでは、SPFx WebパーツがクラシックWikiページでホストされている場合、CSPポリシーは適用されないとされています。また、SharePoint Add-insにはCSPは適用されない一方、SharePoint Add-insは2026年4月2日から動作しなくなると記載されています。(Microsoft Learn)
つまり、「CSPでブロックされないから安全」という判断はできません。クラシックページやAdd-insを使っている場合は、CSP対応とは別に、モダンページやSPFxへの移行計画を立てる必要があります。
実務で使えるCSP対応チェックリスト
まずは、次の順番で進めると混乱しにくくなります。
- SharePoint管理センターでTrusted script sourcesの登録内容と件数を確認する
- テナントアプリカタログとサイトコレクションアプリカタログのSPFxソリューションを棚卸しする
cdnBasePath、externals、SPComponentLoader.loadScript()、インラインスクリプトの有無を確認する- Microsoft Purviewで
Violated Content Security Policyを検索し、DocumentUrlとBlockedUrlを一覧化する - 影響の大きいページから
csp=reportとcsp=enforceで検証する - インラインスクリプトは外部ファイル化し、許可ソースは必要最小限で登録する
- 300件上限に近い場合は、登録URLの統合と再同期を検討する
- ベンダー製SPFxアプリは、CSP対応状況と更新版の提供予定を確認する
- OneDrive利用部門には、標準同期ではなくWebページ上のカスタマイズ確認が中心であることを説明する
CSP対応は、単なるセキュリティ設定の追加ではなく、SharePoint / OneDrive環境に残っている「どこからスクリプトを読み込んでいるか」を可視化する機会です。標準的なSPFxパッケージ構成に寄せ、外部スクリプトを最小限にし、Trusted script sourcesを管理しやすい形に整理すれば、将来のセキュリティ更新にも強い環境になります。
まず着手すべきことは、PurviewのCSP違反ログ確認と、アプリカタログ内のSPFxソリューション棚卸しです。そこから、外部CDN、動的ロード、インラインスクリプトの順に優先度を付けて修正すれば、CSP施行後の表示崩れやWebパーツ停止を現実的に防げます。
コメント