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つの観点を分けて考えることです。

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

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 の現在の説明では、EV証明書が初回ダウンロード時のSmartScreen警告を自動的に回避する挙動はなくなっています。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 と呼ばれていました。

物理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 <timestamp-server-url> /td SHA256 /a .\MyApp.exe
signtool verify /pa /v .\MyApp.exe

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

署名後に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の影響を受けやすい方式でもあります。

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配布を優先するか、ダウンロードページに発行元確認の説明を置きます。

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