Windowsで「Windows によって PC が保護されました」が出る理由

SmartScreen、コード署名、EV/OV証明書、MSIX/Store配布を実務目線で整理

Windowsアプリを作って配布したとき、最初にぶつかりやすい壁が、この警告です。

Windows によって PC が保護されました
Microsoft Defender SmartScreen は認識されないアプリの起動を停止しました。

この警告が出ると、利用者は不安になります。開発者側も「ウイルスではないのに、なぜ止められるのか」「コード署名したのに、なぜまだ警告が出るのか」と悩みます。

この記事では、Windowsアプリ配布時の SmartScreen 警告を、コード署名、EV/OV証明書、MSIX、Microsoft Store、ClickOnce、社内配布の観点で整理します。

1. この記事を一言で

Windowsアプリの配布では、コード署名は必要です。
しかし、コード署名は SmartScreen警告を必ず消す魔法ではありません。

重要なのは、3つの観点を分けて考えることです。

ざっくりした判断の目安はこうです。

この記事の知識マップ

Windowsアプリ配布で出るSmartScreen警告は、コード署名の有無だけでなく発行元とファイルの評判で決まるため、コード署名証明書は警告を軽減しても消し切るわけではない。EV証明書は現在SmartScreen即時回避の目的では推奨されず、本番配布ではAzure Artifact SigningやOV証明書が現実的な選択肢になる。Microsoft Storeに提出したMSIXパッケージはMicrosoftが無償で再署名するため最も安定しやすく、ClickOnceはAuthenticode証明書によるマニフェスト署名で発行元を保証する。SignToolはコード署名とタイムスタンプの付与・検証を担い、タイムスタンプは証明書失効後も署名の有効性を保つ。社内配布ではIntuneやグループポリシーで構成するApp Control for Businessが未署名バイナリの起動失敗を招きうるため、監査モードでの検証を強制適用より先に行うべきである。

flowchart LR
    accTitle: SmartScreenとコード署名の知識マップ
    accDescr: SmartScreen警告の判定材料とコード署名証明書の種類、MSIXやClickOnceなどの配布経路、社内配布でのApp Control for Businessの関係を示す図。
    smartscreen["Windows SmartScreen"]
    code_signing_cert["コード署名証明書"]
    ev_certificate["EVコード署名証明書"]
    group_policy["グループポリシー"]
    intune["Microsoft Intune"]
    msix["MSIX"]
    microsoft_store["Microsoft Store"]
    azure_artifact_signing["Azure Artifact Signing"]
    ov_certificate["OVコード署名証明書"]
    self_signed_cert["アドホックな自己署名証明書"]
    trusted_publisher_store["信頼された発行元ストア"]
    clickonce["ClickOnce"]
    signtool["SignTool"]
    code_signing_timestamp["コード署名のタイムスタンプ"]
    certificate_expiry["証明書の期限切れ"]
    app_control_for_business["App Control for Business(旧WDAC)"]
    managed_installer["マネージドインストーラー"]
    audit_mode["監査モード"]
    unsigned_binary["未署名バイナリ"]
    blocked_app_startup_failure["実行制御によるアプリ起動失敗"]
    code_signing_cert -.->|"軽減する"| smartscreen
    ev_certificate -->|"用いるのは非推奨"| smartscreen
    smartscreen -->|"で構成できる"| group_policy
    smartscreen -->|"で構成できる"| intune
    msix -->|"前提とする"| code_signing_cert
    microsoft_store -.->|"利用する"| msix
    microsoft_store -->|"軽減する"| smartscreen
    azure_artifact_signing -->|"推奨される対応"| msix
    ov_certificate -->|"推奨される対応"| msix
    self_signed_cert -->|"推奨される対応"| msix
    self_signed_cert -.->|"前提とする"| trusted_publisher_store
    clickonce -.->|"前提とする"| code_signing_cert
    signtool -.->|"利用する"| code_signing_timestamp
    code_signing_cert -->|"で確認できる"| signtool
    code_signing_timestamp -->|"軽減する"| certificate_expiry
    app_control_for_business -.->|"利用する"| managed_installer
    audit_mode -->|"より先に行うべき"| app_control_for_business
    app_control_for_business -->|"で構成できる"| intune
    unsigned_binary -.->|"原因になり得る"| blocked_app_startup_failure
    smartscreen -.->|"原因になり得る"| blocked_app_startup_failure

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全20件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2. SmartScreenは「ウイルス判定」だけではない

SmartScreenの警告が出ると、利用者は「危険なアプリなのか」と感じます。

しかし、SmartScreenは単純に「ウイルスかどうか」だけを見ているわけではありません。Microsoft の説明では、ダウンロードされたファイルについて、主にこうした評判情報を見ています。

ここで重要なのは、新しく作ったファイルは、まだ評判がないという点です。

自分たちにとっては正しいアプリでも、Windows側から見ると「初めて見たファイル」です。署名されていても、ファイルハッシュや発行元の評判が十分でない間は、SmartScreen警告が出ることがあります。

つまり、SmartScreen警告はこう捉えると分かりやすいです。

マルウェアと断定された、という意味ではない。
ただし、Windowsがまだ十分に信頼できると判断していない、という意味ではある。

この差を理解しておかないと、「署名したのに直らない」「EV証明書を買ったのに変わらない」という誤解につながります。

3. コード署名は何を保証するのか

コード署名が保証してくれるのは、主に2つです。

1. そのファイルが、表示されている発行元によって署名されたこと
2. 署名後にファイルが改ざんされていないこと

逆に言えば、こうしたことは直接保証しません。

• そのアプリが絶対に安全であること
• そのアプリにバグがないこと
• SmartScreen警告が必ず出ないこと
• 企業ポリシーで必ず許可されること

それでも、コード署名は必須に近いものです。

署名がない場合、利用者には発行元が分かりません。企業環境では、署名なしファイルがApp ControlやEDR、Defender、プロキシ、メールゲートウェイで止められることもあります。自動アップデートを作る場合も、更新ファイルが本物かどうかを検証するために署名が重要になります。

つまり、コード署名は「警告を消すため」だけではなく、配布・更新・監査・企業導入の土台です。

4. EV証明書なら初回から警告が消える、は古い理解

以前は、EVコード署名証明書を使うと、SmartScreenで有利に扱われるという理解が広くありました。

しかし現在は、少なくとも SmartScreen回避だけを目的に EV証明書を買う判断は危険です。Microsoft の開発者向けドキュメント SmartScreen reputation for Windows app developers には、「EV 証明書が SmartScreen をバイパスしなくなりました」「SmartScreen の警告を回避するためだけに EV にプレミアムを支払うことは、もはや正当化されません」と明記されています。同じページの証明書タイプ別の表でも、OV と EV は同じ「有効な証明書 (OV/EV)」の行にまとめられ、初回ダウンロード時の挙動は「評判が蓄積されるまで警告」と書かれています。EVで署名したファイルも、OV証明書と同様に評判が蓄積される前提で考える必要があります。

EV証明書に意味がまったくないわけではありません。

• 企業調達上、より厳格な本人確認が評価される
• 取引先のセキュリティ審査でEVが要求される
• すでにEV証明書を持っているので継続利用する

こうした理由があるなら使ってよいです。

ただし、この目的だけでEV証明書を買うのはおすすめしません。

SmartScreen警告を初回から消したいからEV証明書を買う

この目的なら、まず配布経路、署名方式、初期ユーザーへの説明、更新頻度、Store配布の可否を見直すべきです。

5. 署名方法の選択肢

Windowsアプリ配布でよく出てくる署名・配布の選択肢を整理します。

Microsoft Store / MSIX

一般ユーザー向けに配るなら、最初に検討したいのは Microsoft Store です。

特に MSIX と Store 配布の組み合わせは、証明書管理やSmartScreen警告の面で有利です。Storeに提出されたMSIXパッケージはMicrosoft側で再署名されるため、開発者が個別に証明書を購入・更新する負担も減ります。

ただし、すべてのWindowsアプリがMSIX向きとは限りません。

• Windowsサービスを深く使う
• ドライバが必要
• shell extension がある
• 古いCOM登録やActiveX資産がある
• インストール時に複雑なOS変更が必要

このような場合は、MSIXよりMSIや従来型インストーラーのほうが自然なことがあります。

Azure Artifact Signing

Azure Artifact Signing は、Microsoftが提供するクラウド型のコード署名サービスです。以前は Trusted Signing という名称で、現在は Azure Artifact Signing(Artifact Signing)が正式名称です。Microsoftの製品ページも「Artifact Signing (formerly Trusted Signing)」と表記しています。旧称のまま書かれた記事や社内資料も多いので、検索するときは両方の名前で当たってください。公式ドキュメントは Microsoft Learn: What is Artifact Signing? と Azure: Artifact Signing (formerly Trusted Signing) です。

物理USBトークンを使わず、CI/CDに組み込みやすい点が魅力です。Store外配布の署名方式として有力ですが、利用できる地域やアカウント条件があります。

2026年時点のMicrosoft資料では、組織は米国、カナダ、EU、英国、個人開発者は米国・カナダが対象とされています。日本の法人・個人で使う場合は、利用条件を必ず確認してください。使えない場合は、従来のOVコード署名証明書が現実的な候補になります。

また、Azure Artifact Signingで署名しても、SmartScreenの信頼が即時に付与されるわけではありません。OV証明書と同じく、評判は配布実績に応じて蓄積されます。

OVコード署名証明書

日本の開発者や法人がStore外でWindowsアプリを配布する場合、OVコード署名証明書は今でも現実的な選択肢です。

OV証明書を使うと、利用者には発行元名が表示されます。署名なしよりは明らかに良い状態になります。ただし、新規アプリや新規ファイルではSmartScreen警告が出ることがあります。

OV証明書を使う場合に意識したいのはこのあたりです。

• 発行元名を継続して使う
• 毎回同じ発行元として署名する
• 署名後にファイルを変更しない
• タイムスタンプを付ける
• EXEだけでなく、DLL、MSI、updaterも確認する
• 証明書更新時の移行計画を用意する

自己署名証明書

自己署名証明書は、開発や検証には便利です。

しかし、公開配布では基本的に使えません。利用者のWindowsから見ると、その証明書は信頼済みではないからです。

自己署名証明書が使えるのは、こういう環境です。

• 開発者のローカルPC
• テスターの検証環境
• IntuneやGPOで信頼済み証明書を配布できる社内端末
• 閉域で端末構成を完全に管理できる環境

自己署名証明書を使う場合でも、「いつ削除するか」「誰が信頼済みに入れたか」「本番環境に混ざらないか」を管理する必要があります。

6. 実務では何に署名するべきか

「EXEに署名したから終わり」ではありません。

Windowsアプリ配布では、署名対象をひととおり確認します。

SignTool を使う場合、現在のWindows SDKでは /fd と /td の指定が重要です。典型的には SHA256 を指定します。

signtool sign /fd SHA256 /tr http://timestamp.digicert.com /td SHA256 /a .\MyApp.exe
signtool verify /pa /v .\MyApp.exe

各オプションの意味は次の通りです。

タイムスタンプサーバーの URL は、証明書の発行元が案内しているものを使います。Microsoft の SignTool ドキュメントの例では http://timestamp.digicert.com が、Artifact Signing の署名手順では https://timestamp.acs.microsoft.com が使われています。タイムスタンプを付けておくと、署名時点で証明書が有効だったことが記録されるため、証明書の有効期限が切れた後も署名を使い続けられます。

証明書の指定方法は、環境に応じて使い分けます。

見落としやすいのは、/sm を付けないかぎり SignTool が見るのは実行ユーザーの個人ストアという点です。証明書を「ローカル コンピューター」の証明書ストアに入れたのに /sm を書いていない、ビルドをサービスアカウントで動かしているのに証明書は別のユーザーの個人ストアにある、という理由で「証明書が見つからない」となる例はよくあります。CI で署名する場合は、どのアカウントのどのストアに証明書があるかを最初に確定させてください。

署名できたかどうかは、次の3点で確認します。

• signtool verify /pa /v .\MyApp.exe が成功すること
• そのコマンドの終了コードが 0 であること（PowerShell なら直後に $LASTEXITCODE を見る）
• エクスプローラーでファイルのプロパティを開き、「デジタル署名」タブに発行元とタイムスタンプが表示されること

ポイントは、最終成果物に署名することです。

署名後にEXEを書き換える、ZIP内のファイルを差し替える、インストーラー作成後に埋め込みファイルを変更する、といったことをすると、署名が壊れたり、検証結果が期待と異なることがあります。

ビルドパイプラインでは、この順序を固定します。

ビルド
  ↓
依存ファイルの収集
  ↓
インストーラー / パッケージ作成
  ↓
署名
  ↓
署名検証
  ↓
ハッシュ記録
  ↓
配布

7. 配布方式別の考え方

MSI / EXEインストーラー

MSIやEXEインストーラーで配る場合は、利用者が最初に実行するファイルを必ず署名します。

加えて、インストール後に配置されるEXEやDLLも署名対象として見直します。インストーラーだけ署名されていても、配置後のupdaterやhelperが未署名だと、企業環境では止められることがあります。

考えることはだいたい決まっています。

• インストーラー本体に署名する
• 中に入るEXE/DLLも署名する
• UAC昇格が必要な処理を分離する
• updaterやservice helperを別扱いで監査する
• ダウンロードページのURLを安定させる
• 初期ユーザー向けに発行元名を案内する

MSIX

MSIXは、パッケージとしての一貫性が強い方式です。

Store配布できるなら、SmartScreen警告や証明書管理の面ではかなり扱いやすくなります。一方、社内サイドロードやStore外配布では、MSIXパッケージの署名と証明書信頼をきちんと設計する必要があります。

注意点を挙げておきます。

• 開発・検証は自己署名でもよい
• 本番配布では公開信頼された署名方式を使う
• appxmanifest の Publisher と証明書のSubjectを一致させる
• Store外配布ではSmartScreen警告が出る可能性を想定する
• MSIXに向かないOS統合がないか事前に確認する

ClickOnce

ClickOnceは、WinForms/WPFなどの.NET業務アプリを標準ユーザーに配るときに便利です。

ただし、ClickOnceだからSmartScreen問題が消えるわけではありません。利用者がダウンロードして起動する経路、マニフェスト署名、配布元、更新時のファイル変更が関係します。

ClickOnceで確認するのはこのあたりです。

• アプリケーションマニフェストと配置マニフェストの署名
• 配布元URLまたは共有フォルダの管理
• 更新時の証明書変更の扱い
• 社内プロキシやDefenderで止まらないか
• 初回インストール時の利用者案内

ClickOnceは「簡単に配れる」ことが強みですが、発行元の信頼や配布経路まで含めて設計しないと、現場では止まります。

xcopy / ZIP配布

フォルダを置くだけ、ZIPを展開するだけ、という配布はシンプルです。

閉域や社内ツールでは有効なこともあります。しかし、一般ユーザー向けのWeb配布では、もっともSmartScreenやDefender、Mark of the Webの影響を受けやすい方式でもあります。

ここで出てきた Mark of the Web（MOTW） は、ブラウザーやメールクライアントがダウンロードしたファイルに付ける Zone.Identifier という代替データストリームです。「このファイルはインターネットから来た」という印で、SmartScreen の確認、Office のマクロブロック、PowerShell の実行ポリシー（RemoteSigned）の判定などに使われます。印はエクスプローラーでファイルのプロパティを開き、「セキュリティ」欄の「許可する」をチェックするか、PowerShell の Unblock-File で外せます。ZIP を展開したときに中のファイルへ印が引き継がれるかどうかは、展開に使ったツールによって変わります。詳しくはPowerShellの実行ポリシーとスクリプト署名の「Zone.Identifier（Mark of the Web）と Unblock-File」の章で扱っています。

xcopy配布を使うなら、ここは守っておきたいところです。

• EXE/DLLに署名する
• ZIPだけに頼らず、中身のファイルを検証する
• 配布元を固定する
• バージョン、ハッシュ、更新履歴を明示する
• 自動更新を後付けするなら署名検証を入れる

「インストーラーを作らないから簡単」ではなく、「インストーラーが持つ責任を自分で持つ」と考えるべきです。

独自updater

独自updaterは便利ですが、セキュリティ境界そのものです。

updaterは新しいファイルを取得し、既存ファイルを置き換えます。場合によっては管理者権限で動きます。ここが壊れると、アプリ本体より危険です。

最低限、これだけは確認します。

• 更新metadataに署名する
• metadataにversion、hash、size、channel、expiryを含める
• ダウンロード後にhashと署名を検証する
• 検証失敗時はfail-closedで止める
• rollback手順を用意する
• updater自身の更新方法を決める
• 本番署名鍵を開発環境から分離する

このテーマは、既存記事「自動アップデートのセキュリティ設計」とセットで考えると分かりやすいです。

8. 社内配布ではSmartScreenだけを見ても足りない

社内アプリの場合、よくある誤解があります。

社内だけで使うから、署名はいらない

これは危険です。

社内環境では、SmartScreenだけでなく、いくつもの仕組みが関係します。

特に App Control for Business を使っている環境では、「署名されているか」だけでなく、「その発行元が許可されているか」「managed installer経由か」「ハッシュやパスが許可されているか」が問題になります。

Microsoftの展開ガイドでも、App Controlのポリシー変更は、まず監査モードで展開し、ブロックイベントが想定どおりか確認してから強制モードへ広げる考え方が示されています。

社内配布では、この順序で設計するのが現実的です。

1. 対象端末を分ける
   - 開発者
   - テスター
   - 一部部署
   - 全社

2. 配布経路を決める
   - Intune
   - GPO + ファイル共有
   - 社内ポータル
   - VDI / RemoteApp
   - 閉域の手動配布

3. 信頼ルールを決める
   - 発行元ルール
   - 証明書配布
   - managed installer
   - ハッシュ許可
   - パス許可

4. 監査モードで確認する
   - 何がブロックされるか
   - どのDLLやhelperが漏れているか
   - 更新時に別ファイルとして扱われないか

5. 段階展開する
   - 小さく配る
   - ログを見る
   - 許可ルールを調整する
   - 広げる

社内配布の要点は、SmartScreenの回避ではなく、Windowsにとって説明可能な配布経路にすることです。

9. よくある誤解と正しい考え方

10. 初期リリース時に利用者へどう説明するか

新しいアプリでは、最初の数週間や初期ユーザーでSmartScreen警告が出ることがあります。

このとき、利用者へ単に「警告が出ても実行してください」と案内するのはよくありません。安全な説明には、確認すべき情報を含めます。

案内に入れるべき項目を挙げます。

• 正式なダウンロードURL
• 表示される発行元名
• ファイル名
• バージョン番号
• リリース日
• 必要に応じたSHA-256ハッシュ
• 署名済みであることの確認方法
• 不明な経路から入手したファイルは実行しないこと

たとえば、社内向けならこういう案内が安全です。

このアプリは、社内ポータルの以下ページからのみ配布しています。
表示される発行元名が「○○株式会社」であることを確認してください。
メール添付やチャットで転送されたEXEは実行しないでください。
SmartScreen警告が出た場合は、情報システム部に画面を共有してください。

一般ユーザー向けなら、Microsoft Store配布を優先するか、ダウンロードページに発行元確認の説明を置きます。

警告画面で利用者が行う操作

案内資料には、利用者が実際にどこを押すことになるのかまで書いておきます。SmartScreen の警告ダイアログでは、初期状態で押せるボタンは「実行しない」だけです。実行するには、次の順で操作します。

「Windows によって PC が保護されました」のダイアログ
  → 「詳細情報」を選ぶ
  → アプリ名（ファイル名）と発行元が表示される
  → 「実行」ボタンを押す

Microsoft の開発者向けドキュメントでも、署名がないファイルについて「アプリを実行するには『実行』を選択する必要がある」と説明されています。案内文では、この2段階の操作に加えて、途中で表示される発行元名が自社の名前になっていることを確認してもらうのが要点です。発行元名が「不明な発行元」と出るなら、それは署名されていないか、署名が壊れている状態です。

なお、企業のポリシー設定によっては、この「実行」自体が無効化されていて先へ進めないことがあります。社内向けの案内では、その場合の連絡先も添えておきます。

警告が消えるまでの目安

「どれくらい配れば警告が消えるのか」はよく聞かれますが、Microsoft は具体的なしきい値を公表していません。開発者向けドキュメントにある説明は、「正確なしきい値はないが、幅広い利用者から数週間、数百件のクリーンなインストールが必要な場合がある」というものです。あわせて、次の点も明記されています。

• 一般利用者向けの端末では、評判レビューのためにファイルを手動で提出する仕組みは存在せず、評判はダウンロード実績によって蓄積される
• 企業のIT管理者は、Microsoft Security Intelligence ポータルからファイルを提出できる。社内配布や管理下の端末では、これで信頼の獲得を早められる場合がある
• 同じ証明書で署名し続けると証明書側の評判が育つため、新しいバージョンでは警告が出にくくなることがある。未署名のファイルは、更新のたびにゼロから積み直しになる

つまり、初期リリースは「しばらく警告は出る」前提で案内を用意し、証明書と発行元名を変えずに配布を続けるのが現実的です。

11. 判断フロー

配布方式を決めるときは、この順で考えると迷いにくくなります。

flowchart TD
    A[Windowsアプリを配布する] --> B{一般ユーザー向けか}
    B -->|はい| C{Microsoft Storeに出せるか}
    C -->|はい| D[Store / MSIXを優先]
    C -->|いいえ| E[OV証明書またはArtifact Signingで署名]
    B -->|いいえ、社内向け| F{端末管理があるか}
    F -->|Intune/GPOあり| G[署名 + 証明書配布 + App Control監査]
    F -->|管理なし| H[配布元固定 + 署名 + 利用者案内]
    E --> I[初期SmartScreen警告を想定]
    G --> J[監査モードから段階展開]
    H --> J

実務上の第一候補はこう整理できます。

12. 最低限のチェックリスト

Windowsアプリを公開・配布する前のチェック項目です。

署名

• EXEに署名している
• DLLに署名している
• MSIまたはインストーラーEXEに署名している
• updaterに署名している
• タイムスタンプを付けている
• 署名後にファイルを書き換えていない
• signtool verify で検証している

配布

• 正式な配布URLを決めている
• ダウンロードページに発行元名を表示している
• バージョン番号とリリース日を表示している
• 初期SmartScreen警告が出る可能性を想定している
• Microsoft Storeに出せるか検討した
• Store外配布の場合、OV証明書やArtifact Signingを検討した

更新

• 更新ファイルも署名している
• 独自updaterではmetadataを署名している
• hash、size、versionを検証している
• 失敗時はfail-closedで止まる
• rollback手順がある

社内配布

• Intune / GPO / App Control の有無を確認した
• 証明書配布の方法を決めた
• 監査モードでブロックイベントを見た
• 対象部署を分けて段階展開する
• 更新時に再ブロックされないか確認した

13. まとめ

Windowsアプリは作って終わりではなく、配布したファイルが、Windows、利用者、企業ポリシーから見て「信頼できる形」になっている必要があります。

押さえておきたいのはこのあたりです。

• SmartScreenは、ファイルや発行元の評判を見る
• コード署名は必要だが、警告ゼロを保証しない
• EV証明書は、SmartScreen即時回避目的では選ばない
• 一般配布ではMicrosoft Store / MSIXを優先して検討する
• Store外配布ではOV証明書やArtifact Signingを使い、初期警告を想定する
• 社内配布では、SmartScreenだけでなくIntune、GPO、App Controlまで見る
• updaterは配布機能ではなく、製品のセキュリティ境界として設計する

一言でまとめると、こうです。

Windowsアプリの配布は、「どう置くか」ではなく、「Windowsにどう信頼してもらうか」の設計である。

あわせて読む

• Windowsアプリ配布方式の選定ガイド
• ClickOnce 入門：配布・更新・選定基準
• 自動アップデートのセキュリティ設計
• Windowsアプリ開発における最低限のセキュリティを守るためのチェックリスト
• Windows管理者特権の必要/不要の境界
• Windowsシングルバイナリ化の限界と実践

参考リンク

• Microsoft Learn: SmartScreen reputation for Windows app developers
• Microsoft Learn: Code signing options for Windows app developers
• Microsoft Learn: What is Artifact Signing? - Azure Artifact Signing(旧 Trusted Signing)の概要と現行の正式名称。
• Microsoft Learn: Sign your MSIX package - end-to-end guide
• Microsoft Learn: SignTool.exe
• Microsoft Learn: Deploying App Control for Business policies
• Microsoft Learn: Manage approved apps for Windows devices with App Control for Business policy and Managed Installers in Microsoft Intune

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

「Windows によって PC が保護されました」という警告が出るのはなぜですか？

Microsoft Defender SmartScreen が、そのファイルをまだ十分に信頼できると判断していないためです。SmartScreen は単純なウイルス判定ではなく、発行元の評判、ファイルハッシュの評判、署名の有無、配布経路などを見ています。新しく作ったファイルは Windows 側から見ると「初めて見たファイル」なので、署名されていても評判が蓄積されるまでは警告が出ることがあります。マルウェアと断定されたという意味ではありませんが、Windows がまだ十分に信頼できると判断していない、という意味ではあります。

コード署名すればSmartScreen警告は消えますか？

必ず消えるわけではありません。コード署名が保証するのは、表示されている発行元によって署名されたことと、署名後にファイルが改ざんされていないことの 2 つで、警告ゼロを保証するものではありません。署名されていても、ファイルや発行元の評判が十分でない間は警告が出ることがあります。それでもコード署名は、配布・更新・監査・企業導入の土台として必須に近いものです。署名がないと、企業環境では App Control や EDR、Defender などで止められることもあります。

EV証明書を買えば初回からSmartScreen警告が出なくなりますか？

それは古い理解です。Microsoft の現在の説明では、EV 証明書が初回ダウンロード時の SmartScreen 警告を自動的に回避する挙動はなくなっており、EV で署名したファイルも OV 証明書と同様に評判が蓄積される前提で考える必要があります。企業調達上の要件や取引先のセキュリティ審査で EV が要求される場合に使う意味はありますが、SmartScreen 回避だけを目的に EV 証明書を買う判断はおすすめしません。その目的なら、まず配布経路、署名方式、Store 配布の可否を見直すべきです。

SmartScreen警告を減らすには、どう配布すればよいですか？

一般ユーザーに広く配るなら、まず Microsoft Store / MSIX を検討します。Store に提出された MSIX パッケージは Microsoft 側で再署名されるため、SmartScreen 面で最も安定しやすい経路です。Store に出せない場合は、OV 証明書または Azure Artifact Signing で署名し、初期の警告は出る可能性があると想定して、正式なダウンロード URL・発行元名・バージョン・ハッシュなどを利用者に案内します。社内配布では、署名に加えて Intune / GPO / App Control まで含めた配布経路の設計が必要です。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。