Microsoft Edgeで社内サイトだけSmartScreenに止められるときは、まず「サイト自体が危険判定されたのか」「社内サイトから配るファイルだけが警告対象なのか」「Defender for EndpointやWeb制御で組織的に止めているのか」を切り分けるのが最短です。SmartScreenはURLの評判だけでなく、ページ内容、ダウンロードファイルの署名や普及度、TLS、JavaScriptやリダイレクト、ユーザーからの報告まで見て判定します。 (Microsoft Learn)
そのため、社内ポータルでも「新しく切ったサブドメイン」「Microsoft 365風のログイン画面」「未署名のEXE/MSI配布」「強いブロックポリシー」が重なると止まりやすくなります。しかもMicrosoft Defender for Endpoint（MDE）が有効な環境では、Edgeの SmartScreenAllowListDomains が無視されるため、Defenderポータル側でURL/ドメインのAllow indicatorを作らないと解決しないケースがあります。この記事では、起きやすい条件、確認する設定、復旧手順、再発防止まで実務目線で整理します。 (Microsoft Learn)
まず5分で切り分ける
同じ「SmartScreenに止められた」でも、止まっている場所が違うと対処は変わります。最初は次の3つだけ見れば十分です。 (Microsoft Learn)
- サイト自体が赤い警告画面で開けない
URLの評判、ページ内容、TLS、リダイレクト、ユーザーフィードバックなどを含むサイト判定を疑います。 (Microsoft Learn) - ページは開くが、EXEやMSIのダウンロードだけ止まる
App Reputation系の警告を疑います。未署名、配布実績不足、危険な拡張子の配布が典型です。 (Microsoft Learn) - Edge以外のブラウザーやバックグラウンド通信でも止まる、またはWindows Securityの通知が出る
MDEのNetwork ProtectionやWeb Content Filtering、カスタムインジケーターが原因の可能性があります。 (Microsoft Learn)
社内サイトだけ引っかかりやすい主な原因
新規ドメイン・新規サブドメインで評判が薄い
SmartScreenはURLの評判を見ます。Microsoftは、新規登録ドメイン、悪性履歴、ホスティング事業者、トラフィック量を判定材料に挙げており、既知の信頼を持たないURLやファイルは高リスク寄りに扱われやすいと説明しています。社内でありがちなのは、ポータル更改のたびにサブドメインを変える、クラウド事業者の仮ホスト名をそのまま使う、といったパターンです。 (Microsoft Learn)
ログイン画面・フォーム・スクリプトの挙動がフィッシングに見えやすい
Microsoftのトラブルシュート文書では、欺瞞的なフォーム、悪意あるスクリプト、フィッシングページ、JavaScriptの動き、リダイレクト、難読化、TLSの証明書有効性やプロトコル版数も判定材料に含まれます。社内サイトでは、SSOの前後で画面遷移が多い、外部iframeを埋め込む、見た目が一般的な認証画面に近い、といった構成が誤検知の温床になりやすいです。証明書やTLSの弱さは「それだけで必ずSmartScreenになる」とは言い切れませんが、少なくとも判定材料の1つです。 (Microsoft Learn)
社内配布ファイルが未署名、または配布実績が少ない
SmartScreenはダウンロードファイルを既知の危険ソフト一覧と照合するだけでなく、「よく知られ、頻繁にダウンロードされるファイルか」も見ています。ファイルがその一覧にない場合は警告対象になりやすく、さらにトラブルシュート文書では「機密性の高いファイルのダウンロード」と「署名状態」も判定材料に挙げられています。社内インストーラーをWebポータルから配る運用では、サイト自体は開くのにダウンロードだけ止まる、という形で表面化しやすいポイントです。 (Microsoft Learn)
利用者側ではなく、組織ポリシーで強く止めている
Microsoftは、既定ではSmartScreen警告をユーザーがバイパスできる一方で、組織では高リスク操作を警告ではなくブロックに寄せる設定を推奨しています。実際に PreventSmartScreenPromptOverride が有効なら、利用者はサイト警告を無視できません。つまり「一部端末では進めるのに、管理PCでは完全停止する」という差が出るのは不自然ではありません。 (Microsoft Learn)
まず確認する設定と管理画面
現場で最初に見るべき場所は edge://policy です。ここで適用済みポリシーを確認でき、ローカルポリシーならほぼ即時、Active Directory経由なら gpupdate /force 後にEdgeを再起動して反映を確認できます。 (Microsoft Learn)
特に確認したいのは次の項目です。
- SmartScreenEnabled
SmartScreen自体のオン・オフです。既定ではオンですが、未構成ならユーザー判断になることがあります。 (Microsoft Learn) - PreventSmartScreenPromptOverride
サイト警告の「続行」を禁止する設定です。誤検知時に利用者側で進めなくなる典型項目です。 (Microsoft Learn) - PreventSmartScreenPromptOverrideForFiles
ダウンロード警告の迂回可否を決める設定です。ファイル配布だけ止まるときに見ます。 (Microsoft Learn) - SmartScreenAllowListDomains
指定ドメインを信頼扱いにして、そのドメインのサイト判定とダウンロードチェックを外す設定です。 (Microsoft Learn) - ExemptSmartScreenDownloadWarnings
特定ドメインと特定拡張子に対するApp Reputation警告だけを外す設定です。サイト本体のブロックには効きません。 (Microsoft Learn)
実務では、次の3つを混同しないことが重要です。 (Microsoft Learn)
| 設定 | 効く範囲 | 向いているケース | 注意点 |
|---|---|---|---|
| SmartScreenAllowListDomains | ドメイン単位でサイトとダウンロードのSmartScreenチェックを外す | 完全に信頼できる社内ドメインをまとめて許可したい | MDEが有効な組織では無視される |
| ExemptSmartScreenDownloadWarnings | 特定ドメイン × 特定拡張子のダウンロード警告だけを外す | 社内サイトのEXE/MSIだけ止まる | サイト自体のブロックには効かない。設定時は拡張子を小文字ASCII・先頭ドットなしで書く必要がある |
| PreventSmartScreenPromptOverride | サイト警告の「続行」を禁止する | 利用者に自己判断で迂回させたくない | 誤検知時も利用者側では進めない |
表の内容は各Edgeポリシーの公式仕様に基づきます。 (Microsoft Learn)
見落としやすいのが、MDEを使っている組織では SmartScreenAllowListDomains が無視される点です。公式ドキュメントでも、MDEが有効な場合はMicrosoft Defenderポータルのインジケーターで許可/ブロックを管理するよう明記されています。さらに、Web Content Filtering で止まっている場合も、URL/ドメインの Allow indicator がカテゴリブロックより優先します。 (Microsoft Learn)
「設定したいのに項目が出ない」なら、更新差分も疑ってください。たとえば ExemptSmartScreenDownloadWarnings は Windows 版 Edge 118 以降の対応で、古いEdgeや古いADMXテンプレートでは前提がずれます。また、これらの強制ポリシーは管理対象デバイスを前提とするものが多く、個人端末と管理PCで見え方が違うことがあります。 (Microsoft Learn)
ネットワーク側も最後に確認してください。EdgeのSmartScreen機能には *.smartscreen.microsoft.com、*.smartscreen-prod.microsoft.com、*.urs.microsoft.com などの接続先があり、MDEのNetwork Protectionではクラウド到達性やプロキシ設定が問題になることがあります。特にNetwork ProtectionはOSのプロキシ設定を検出できず、静的プロキシの構成が必要になるケースがあるとMicrosoftは案内しています。 (Microsoft Learn)
最短で復旧する手順
1. まず証拠を集める
最初に残すべきなのは、正確なURL、警告文、日時、利用端末、Edge以外で同じかどうかです。SmartScreenの誤検知、ダウンロード警告、MDEのWeb保護は見た目が似ることがあるため、「社内サイトが開けない」だけでは切り分けが進みません。スクリーンショットと対象URLが揃うだけで、後の申請や再現確認がかなり速くなります。 (Microsoft Learn)
2. 一時回避は“機能に合わせて”最小限で行う
復旧を急ぐときほど、広い例外を作らないことが重要です。サイト全体が止まるなら SmartScreenAllowListDomains、またはMDE環境ならURL/ドメインのAllow indicatorが候補です。ダウンロードだけなら ExemptSmartScreenDownloadWarnings のほうが影響範囲を狭くできます。どちらも「全部オフ」ではなく、対象ドメインや拡張子を絞るのが基本です。Allow indicator はブロックより優先します。 (Microsoft Learn)
3. サイト所有者は Microsoft に誤検知申請する
サイトが安全なのに赤画面が出る場合、Microsoftはブロックページの More information > Report that this site doesn’t contain (malware/phishing) threats から安全サイトとして報告する方法を案内しています。トラブルシュート文書では、サイト所有者はこの方法で申請し、必要なら後続メールに返信して事情を説明する流れが示されています。利用者側しか動けない場合でも、所有者にこの手順を依頼するのが最短です。 (Microsoft Support)
4. 所有者でなくても WDSI で補助申請できる
Microsoftのトラブルシュート文書では、所有者でない利用者でも、所有者と一緒に WDSI submission portal を使って報告できるとしています。ユーザー数が多い社内ポータルでは、情シスだけでなく実際の利用者側の報告も集めたほうが、状況説明がしやすくなります。 (Microsoft Learn)
5. 恒久対処はサイト側を直す
応急処置だけで終わらせると再発しがちです。Microsoftが再発防止策として挙げているのは、HTTPSと有効な証明書の利用、未知のサードパーティiframeの遮断、CSPなどの安全なレスポンスヘッダー、WebShellやトロイの木馬や不審アップロードファイルの定期スキャン、ドメイン評判を落とさない安定運用です。社内サイトでは、これに加えて配布ファイルの署名と配布導線の見直しまでセットでやると効果が出やすいです。 (Microsoft Learn)
管理者向け: どの機能が止めたかをログで見る
Defender for Endpoint を使っているなら、Advanced Hunting で EdgeのSmartScreen と Network Protection を同じ画面で追うと原因が早く見えます。Microsoftは SmartScreenUrlWarning、ExploitGuardNetworkProtectionBlocked、ExploitGuardNetworkProtectionAudited などの ActionType を案内しています。 (Microsoft Learn)
DeviceEvents
| where ActionType in ("SmartScreenUrlWarning","ExploitGuardNetworkProtectionBlocked","ExploitGuardNetworkProtectionAudited")
| extend Parsed=parse_json(AdditionalFields)
| project Timestamp, DeviceName, RemoteUrl, ActionType, InitiatingProcessFileName,
ResponseCategory=tostring(Parsed.ResponseCategory),
DisplayName=tostring(Parsed.DisplayName)
| sort by Timestamp desc
ActionType = SmartScreenUrlWarning なら Edge 側のSmartScreen警告を、ExploitGuardNetworkProtectionBlocked なら Network Protection 側のブロックを優先して追えます。さらに ResponseCategory が CustomBlockList ならカスタムインジケーター、CustomPolicy なら Web Content Filtering、Malicious や Phishing なら脅威フィード由来と見分けやすくなります。 (Microsoft Learn)
やってはいけない対処
SmartScreenを全体オフにしてしまう
SmartScreenは既定でオンで、Microsoftは組織向けには高リスク操作を警告止まりではなくブロックに寄せる構成を推奨しています。社内サイトの1件のために機能全体を切ると、別のフィッシングや悪性ダウンロードまで見逃しやすくなるため、恒久策としては避けるべきです。 (Microsoft Learn)
例外を必要以上に広げる
SmartScreenAllowListDomains は、そのドメインのサイト判定とダウンロードチェックをまとめて外します。ExemptSmartScreenDownloadWarnings も、設定次第では危険な拡張子の警告を広く弱めます。Microsoft自身、すべてのドメインに対する広い抑制は推奨しないと明記しています。社内サイトの復旧でも、対象は最小限のドメイン・拡張子に絞るべきです。 (Microsoft Learn)
ドメインやホスティングを頻繁に変えて“逃げる”
Microsoftは、サイトがブロックされにくくするための対策として、ドメインの評判維持と、ホスティングやDNSの頻繁な変更を避けることを挙げています。短期間でURLを変え続けると、利用者案内も監視も崩れやすく、結果的に誤検知や混乱を増やしやすいです。 (Microsoft Learn)
再発を減らす運用
再発防止は、単発の申請より「運用の型」を作ったほうが効きます。
- 社内ポータルの本番URLはできるだけ固定し、新サブドメイン乱立を避ける。 (Microsoft Learn)
- HTTPSと証明書の有効性を監視し、SSO前後のリダイレクトや外部iframeを減らす。 (Microsoft Learn)
- 配布するEXE/MSIは署名状態と配布導線を見直し、サイトブロックとダウンロード警告を混同しない。 (Microsoft Learn)
- MDE環境では、まず監査モードやレポートで影響を見てから block や Allow indicator を本番展開する。 (Microsoft Learn)
- ポリシー変更後は
edge://policyとgpupdate /forceで反映確認まで含めて手順化する。 (Microsoft Learn)
最後に押さえるべきポイントは3つです。サイト本体が止まっているのか、ダウンロードだけなのか、MDEやWeb制御で組織的に止まっているのかをまず分けること、MDE環境ではEdgeの許可リストよりDefenderのAllow indicatorが正しい解き方になること、恒久対処は例外追加よりサイト側の健全化が本命という3点です。まずは edge://policy で適用状態を確認し、所有者側の誤検知申請と、MDE有無に応じた最小限の許可設定から着手すると失敗しにくいです。 (Microsoft Learn)
コメント