GitHub Pagesで公開した学習用サイトなのに、Microsoft EdgeやWindowsの保護機能で「安全ではない」と表示されることがあります。多くは誤検知ですが、放置すると閲覧者が離脱しやすくなります。原因の切り分けと、Microsoft公式窓口（SmartScreen／WDSI）への申請手順をまとめます。
まず結論：自分で「解除」ボタンを押して終わりではない
GitHub Pagesのような静的サイトでも、閲覧者側の保護機能（Microsoft Defender SmartScreen、Microsoft Defender、組織のネットワーク保護など）でブロックされることがあります。サイトオーナー側で直接ホワイトリストに入れて解除することはできず、Microsoft側の評価（ブロック判定）を更新してもらうのが正攻法です。
切り分けが最重要：「どの仕組み」が危険判定しているのかを先に特定する
「Microsoftに危険と言われた」と一口に言っても、実際には複数の仕組みがあります。申請先を間違えると、何度送っても改善しません。まずは警告の種類を整理しましょう（例：https://soha-stack.github.io/ や https://soha-stack.github.io/project/ など）。
| 表示されやすい場所 | 代表的な警告 | 主な仕組み | 優先する対処 |
|---|---|---|---|
| Microsoft Edgeでサイトを開いた直後 | 「このサイトは安全ではない」「報告されています」などの赤い警告画面 | Microsoft Defender SmartScreen | 警告画面の「詳細」から“安全なサイトとして報告”／SmartScreenフィードバック |
| Edgeでファイルをダウンロードしたとき | 「一般的にダウンロードされていない」「危険な可能性」など | SmartScreen（レピュテーション評価） | 配布物の見直し／必要ならWDSIに提出 |
| Windows セキュリティ／Defenderがブロック | 「脅威を検出しました」「許可されません」など | Microsoft Defender Antivirus / Endpoint | 誤検知としてWDSI（aka.ms/wdsi）へ提出 |
| 会社PC・学校PCだけ見られない | 組織ポリシーによるブロック、URL/IPが遮断される | Defender for Endpoint のネットワーク保護等 | 管理者に相談（指標/許可）＋必要ならWDSI提出 |
| ブラウザに証明書エラーが出る | 「接続はプライベートではありません」など | SSL/TLS（証明書やHTTPS設定） | SmartScreen申請ではなく、証明書・ドメイン設定を修正 |
Edgeで「このサイトは報告されています」と出る場合、まずはSmartScreen（サイト評価）が本命です。SmartScreenは、訪問したページの挙動分析や、報告されたフィッシング/マルウェアサイトの動的リスト照合、さらにレピュテーション（評判）評価などを組み合わせて警告を出します。
なぜGitHub Pagesでも誤検知されるのか：SmartScreenの仕組みを知る
SmartScreenは「悪意のあるコードが入っているか」だけで判断しているわけではありません。Microsoft公式の説明でも、ページの挙動分析や、報告された危険サイトのリスト照合、評判（レピュテーション）による判定が明記されています。つまり、静的HTMLでも「フィッシングっぽい」「詐欺っぽい」見た目や挙動だと、弾かれることがあります。
GitHub Pagesで特に引っかかりやすいパターン（体感ベース）
- /login や /account など、ログイン画面風のページ（練習で作っただけでも“資格情報の収集”に見える）
- 外部の不明なドメインからJavaScriptを読み込んでいる（解析・広告・ウィジェットなど）
- 自動リダイレクト、クリック誘導、全画面表示など「詐欺サイトの典型」に似たUI
- 難読化されたJavaScript（ミニファイ済みでも内容次第で怪しく見える）
- “Microsoft/Windows/Defender”を過剰に模したデザイン（学習用でも誤解されやすい）
特に「学習用にログインフォームを作った」ケースは要注意です。GitHub PagesはHTTPSで配信されるので安心しがちですが、閲覧者の安全機能は内容（見た目・挙動）で止めに来るため、無害でも赤画面になることがあります。
申請前にやっておくと良いセルフチェック（誤検知でも“説明材料”になる）
Microsoftに「誤検知です」と伝えるとき、こちら側で最低限の確認をしておくと話が早いです。自分の安心のためでもありますし、申請コメントの説得力も上がります。
| チェック項目 | 確認のコツ | 問題があった場合の対処 |
|---|---|---|
| 外部スクリプト | HTMLの<script src>を洗い出し、用途と提供元が説明できるか確認 | 不要なら削除／必要でも信頼できる提供元へ変更／自前ホストに切替 |
| リダイレクト | meta refresh、location.href、短縮URLなどが入っていないか | 学習用でもリダイレクトは避け、説明ページを挟む |
| フィッシングに見えるUI | ログイン/決済/本人確認っぽいフォームや文言がないか | 「デモです」「学習用です」を明記し、実在サービスの模倣は避ける |
| 怪しいファイル配布 | exeやzip等を配っていないか（配布するなら署名やハッシュ提示が望ましい） | 配布をやめる／GitHub Releases利用／ハッシュ提示 |
| 改ざんの可能性 | 最近のコミットに不審な差分がないか、依存関係に謎の追加がないか | 不審箇所を削除し、再デプロイしてから申請 |
ここまで見て「特に怪しいものはない」と言えるなら、誤検知の可能性が高く、次の“公式ルートの申請”に進む価値があります。
最優先の対処：Edgeの警告画面から“安全なサイト”として報告する
Edgeで赤い警告画面が出るタイプは、SmartScreenのフィードバック導線が用意されています。Microsoftのサポート情報でも、警告ページからMore information（詳細）→ Report that this site doesn’t contain threats（脅威はないと報告）の流れで報告できると案内されています。
手順（閲覧者として報告する場合）
- Edgeで該当ページを開き、赤い警告画面を表示する
- 画面内の「詳細（More information）」を選ぶ
- 「このサイトに脅威はありません（Report that this site doesn’t contain threats）」を選び、表示されるフィードバックページに従って送信する
手順（サイト所有者として報告する場合）
SmartScreenのFAQでは、サイト所有者・代表者として「正当なサイトなのに警告された」場合に、フィードバックシステムから修正依頼を出せる旨が説明されています。フォーム上で「サイトの所有者/代表者である」選択肢が出ることがあるので、該当する立場で送信すると話が通りやすいです。
併用すると強い：WDSI（Microsoft Security Intelligence）へ誤検知として提出する
SmartScreenの報告に加えて、Defender系の誤検知はMicrosoft Security Intelligence（通称WDSI）の提出窓口にまとめられています。Microsoft Defender for Endpointの公式ドキュメントでも、誤検知は https://aka.ms/wdsi への提出が解決策として案内されています。
WDSIでできること（ざっくり）
- ファイルの誤検知：検体（ZIP等）を提出して再判定してもらう
- URLのブロック（ネットワーク保護等）：URL/IPの検出・ブロックに関するフィードバック導線を使う
WDSIの提出フォームでは「Microsoft Defender Smartscreen」を製品として選択でき、追加情報は英語での記載が推奨される旨も表示されます（見た目はファイル提出中心ですが、SmartScreen関連の評価改善でも参照されることがあります）。
提出先リンク（代表例）
提出で“刺さりやすい”書き方（英語テンプレ）
追加情報欄は長文でなくて構いませんが、次の4点は入れると伝わりやすいです。
- サイトが個人の学習用であること
- 静的HTML/CSS/JavaScriptが中心であること
- マルウェアやフィッシング目的ではないこと
- 誤検知なので再評価してほしいこと
This is my personal learning website hosted on GitHub Pages.
It contains only static HTML/CSS/JavaScript for study purposes.
I believe there is no malicious or phishing content on this site.
Please review and remove the unsafe warning if this is a false positive.Microsoftの提出手順では、提出後にSubmission ID（提出ID）が発行されるので控えておくこと、結果通知のためにサインインまたは有効なメールアドレスの入力が推奨されることが記載されています。
“直したつもり”で残ることがある：キャッシュと反映を疑う
Microsoft側で評価が更新された後でも、端末側に結果が残っていて警告が続くことがあります。Microsoft Learnの説明では、SmartScreenの判定結果は端末にローカル保存され、閲覧データ（キャッシュ）の削除でローカルに保存されたSmartScreenのURLデータが消えることが示されています。検証時は、InPrivateでの確認やキャッシュ削除もセットで行うと切り分けが楽です。
再発防止の“サイト側”改善：誤検知されにくい作りに寄せる
誤検知はMicrosoft側の判定の問題ですが、サイト側を少し整えるだけで再発確率を下げられることがあります。とくにGitHub Pagesは「個人サイト・ポートフォリオ」用途が多いので、次の改善が効きやすいです。
About/連絡先/用途を明記する
- トップに「個人の学習用」「ポートフォリオ」である旨を明記
- 問い合わせ先（XやGitHub、メールなど）を1つ載せる
- ログインフォーム風のページには「デモ」「入力しても送信しない」などの注記
外部スクリプトを減らす（“説明できない”要素を消す）
- よく分からない解析タグ、広告タグ、怪しいウィジェットは外す
- 必要なら、提供元が明確なCDN（公式があるもの）に寄せる
- 自作JSは可能なら自リポジトリに置いて配信する
誤解を招くデザインや文言を避ける
- Windowsの警告画面、Microsoftのログイン画面の“再現”は避ける
- 「ウイルスに感染しました」など、詐欺で多用される煽り文句は学習用でも避ける
- 全画面表示、音声自動再生、不要なポップアップはやめる
企業/学校の端末だけブロックされる場合の考え方
会社PCや学校PCだけブロックされる場合、SmartScreen単体ではなく、Defender for Endpointのネットワーク保護や組織ポリシーが関わっていることがあります。公式ドキュメントでも、誤検知時の回避策としてIndicators（IP/URLなど）の管理が言及されています。個人サイト側でできることには限界があるため、利用者が組織端末なら管理者に相談してもらうのが近道です。
よくある質問
GitHub Pagesなのに、なぜ「危険」扱いされるの？
SmartScreenはページの挙動や報告情報、評判（レピュテーション）など複数の信号から判定します。静的HTMLでも、フィッシングに似た見た目や、怪しく見える外部スクリプトがあると警告対象になり得ます。
自分だけ見られて、他の人は見られない（逆もある）。どっちが正しい？
SmartScreenの判定は端末側に結果が残ることがあり、キャッシュや閲覧履歴の状態、組織ポリシーの有無で見え方が変わることがあります。InPrivateでの確認や、キャッシュ削除でローカルのSmartScreenデータを消して検証すると判断しやすくなります。
SmartScreenをオフにすれば解決する？
自分の動作確認のために一時的にオフにする方法はありますが、閲覧者にそれを求めるのは現実的ではありません。基本は「安全なサイトとして報告」「誤検知として提出」でMicrosoft側の判定を更新してもらうのが王道です。
まとめ：やることを最短ルートに整理
- 最初に「SmartScreenの警告」なのか「Defender/ネットワーク保護」なのかを切り分ける
- Edgeの赤い警告なら、警告画面から“安全なサイト”として報告する
- 誤検知の提出はWDSI（aka.ms/wdsi）も併用し、説明文は簡潔に英語で書く
- キャッシュで残る場合があるので、InPrivate/キャッシュ削除で検証する
- 再発防止として、ログイン風ページや不明な外部スクリプトを減らす
コメント