自社開発のWindowsアプリがウイルス扱いされたら ── Microsoft Defenderの誤検知対応と、性能影響との付き合い方

「お客様の端末で、うちのアプリがウイルス扱いされて消されました」── 自社開発・受託開発のWindowsアプリを配布していると、いつかこの連絡を受ける日が来ます。昨日まで普通に動いていた業務アプリが、Defenderの定義更新をきっかけに突然隔離される。開発機では何も起きないのに、顧客環境でだけ検知される。マルウェアなど書いた覚えはないのに、です。

これは珍しい事故ではありません。現代のウイルス対策ソフトは「既知のマルウェアと一致するか」だけでなく、機械学習・ふるまい・クラウド上の評判(レピュテーション)で「怪しさ」を推定するため、実績のない正規のバイナリが疑われることは仕組み上避けられないからです。そして誤検知への対処には、やってよいこと(Microsoftへの誤検知報告、限定的な除外)と、やってはいけないこと(ウイルス対策の無効化、広範囲の除外)がはっきり分かれています。

この記事では、誤検知が起きる仕組み、配布前にできる予防、検知されたときの正規の対処ルート、顧客環境での応急対応としての除外設定とそのリスク、そしてもう一つの定番相談である「Defender(MsMpEng.exe)が重い」への向き合い方を、開発者の目線で整理します。

1. まず結論

• 正規のアプリでも誤検知は起こり得ます。Defenderは2015年以降、静的シグネチャ中心のエンジンから機械学習・クラウド保護を使う予測型のモデルへ移行しており、未知のファイルは既知の悪性と一致しなくても「怪しさ」で判定されます。¹²
• 恒久対応の正規ルートはMicrosoftへのファイル申請(誤検知報告)です。Microsoft Security Intelligenceのサンプル申請ポータルから開発者として提出し、判定を追跡します。判定に不服があれば開発者向け連絡フォームで再調査を依頼できます。³⁴
• 隔離されたファイルは復元できます。Windowsセキュリティの「保護の履歴」から、またはコマンドラインの MpCmdRun.exe -Restore で戻します。⁵
• 除外設定は「報告結果が出るまでの一時対応」です。除外は保護の穴(protection gap)であり、Microsoftは「控えめに・特定の問題にだけ・定期的に見直して」使うよう明記しています。入れるならフルパス指定の最小範囲で、記録を残します。⁶
• 予防の柱は一貫したコード署名です。Microsoftに誤検知防止の事前登録プログラムはなく、信頼されたルート認証局の証明書で一貫して署名し続けることが、出所の特定と既知リスト入りを早める公式に案内された方法です。⁴
• リリース前の自前スキャンと事前申請で「実績ゼロ」を減らせます。MpCmdRun.exe のカスタムスキャンで配布物を検査でき、未知のファイルをサンプル申請しておくことは評判(レピュテーション)の確立を始める手段だとMicrosoft自身が案内しています。⁷⁸
• 「Defenderが重い」はまず計測です。Performance analyzer(New-MpPerformanceRecording / Get-MpPerformanceReport)でどのファイル・プロセスがスキャン負荷の中心かを特定してから対策を考えます。除外はここでも最後の手段です。⁹¹⁰

2. なぜ正規のアプリがウイルス扱いされるのか

「ウイルス対策ソフト=既知のウイルスのパターン(シグネチャ)と照合するもの」という理解のままだと、誤検知は不可解に見えます。しかし現代のDefenderは違います。Microsoftは2015年に、静的シグネチャベースのエンジンから、機械学習・応用科学・AIといった予測技術を使うモデルへ移行したと明言しています。¹

検知は多層で行われます。端末上では軽量な機械学習モデル・ふるまい分析・ヒューリスティックが動き、端末だけで白黒つけられないファイルはメタデータがクラウド保護サービスへ送られ、多くの場合ミリ秒単位で判定が返ります。それでも判定できない場合は、ファイルのサンプル送信を求め、クラウド側でスキャン・デトネーション(隔離環境での実行)・ビッグデータ分析にかけます。「block at first sight(初回検出時ブロック)」が有効な環境では、クラウドの判定が出るまでファイルのオープンが一時的に保留されることさえあります。²¹¹

この仕組みの含意は明確です。判定材料は「悪性との一致」だけでなく「無害である実績」も含むということです。Microsoftの分類基準には「Unknown(認識されないソフトウェア)」というカテゴリが明示されており、未知・ダウンロード実績の少ないプログラムへの警告は「まだ検出されていないマルウェアの早期警戒システム」と位置付けられています。珍しいプログラムがすべて悪性なわけではないが、未知カテゴリのリスクは一般ユーザーにとって高い、というのが公式の整理です。⁸

つまり、リリースしたての自社アプリは、Windowsのセキュリティ機構から見れば「世界で誰も実行したことのない、実績ゼロのバイナリ」です。そのうえで次のような特徴が重なると、疑いは強まります。

• コードの実体を隠す構造。Microsoftのマルウェア分類には、コードと目的を隠して検出を困難にする「Obfuscator(難読化)」という型があり、セキュリティ製品の検出を積極的に回避しようとするソフトウェアは望ましくないアプリケーション(PUA)の一分類にもなっています。難読化ツールや自己解凍形式、ランタイムを1つのexeに同梱するタイプのパッケージングは、マルウェアが多用する構造と外形上区別がつきにくく、正規アプリでも警戒されやすい領域です。⁸
• 署名がなく、出所をたどる手掛かりがない。次章で述べるとおり、一貫した署名は調査側が出所を特定する主要な手掛かりです。⁴
• インストーラーが別のソフトウェアを同梱している。同一開発元でないソフトウェアや動作に不要なソフトウェアのインストールを提案するものは「Bundling software」としてPUA分類の対象です。⁸

なお、ダウンロード直後に出る「Windows によって PC が保護されました」という青い警告は、Defenderウイルス対策の検知とは別の仕組み(Microsoft Defender SmartScreen)です。Microsoftの開発者向けFAQでも、SmartScreenはDefenderウイルス対策とは無関係だと明記されています。⁴ SmartScreenと評判の話は「Windowsで「Windows によって PC が保護されました」が出る理由」で詳しく整理しているので、警告の種類がどちらなのかをまず切り分けてください。

3. 配布前にできる予防

3.1. 一貫したコード署名 ── 事前登録プログラムは存在しない

「誤検知されないよう、事前にMicrosoftのホワイトリストに登録できないか」という発想は自然ですが、答えはNoです。Microsoftは開発者からの既知リスト登録・誤検知防止プログラムの申し込みを受け付けていません。代わりに公式FAQが案内しているのが、信頼されたルート認証局が発行した証明書で、プログラムのファイル群に一貫して署名し続けることです。一貫した署名があると、調査チームがプログラムの出所を素早く特定して過去の知見を適用でき、結果としてプログラムが既知リストへ早く追加されることがあり、頻度は低いものの証明書自体が信頼された発行元リストに載ることもある、とされています。⁴

裏を返すと、署名の効果は「ファイル単位の実績」を「発行元単位の実績」に束ねることにあります。ビルドするたびにハッシュが変わる実行ファイルは、ファイル単位で見れば毎回「初めて見るファイル」ですが、同じ証明書で署名されていれば出所は連続します。署名の実務(証明書の種類、Azure Artifact Signing、タイムスタンプ)は上記のSmartScreen記事と「Windowsアプリ開発のセキュリティ最低限チェックリスト」を参照してください。

3.2. リリース前に自分でスキャンする

配布してから顧客環境で検知されるより、リリース判定の一部として自分のビルド成果物をスキャンしておくほうがずっと安上がりです。Defenderにはコマンドラインツール MpCmdRun.exe があり、スクリプトやスケジュールタスクからの自動化に使えます。既定でPATHには入っていないため、%ProgramData%\Microsoft\Windows Defender\Platform\<バージョン>(なければ %ProgramFiles%\Windows Defender)へ移動してから実行します。⁷

rem 管理者権限のコマンドプロンプトで実行
cd /d "C:\ProgramData\Microsoft\Windows Defender\Platform\<最新バージョンのフォルダ>"

rem リリースフォルダをカスタムスキャン(-ScanType 3)
rem -DisableRemediation: 検出しても隔離などの処置を行わず、結果をコマンド出力に表示する
MpCmdRun.exe -Scan -ScanType 3 -File "C:\Release\MyApp" -DisableRemediation

戻り値は0と2が定義されていますが、ゲートとして使うときに見落としやすいのは、0が「検出なし」だけでなく「検出したが修復に成功した」も含むことです。素の -Scan のままだと、Defenderがリリース成果物を検出して隔離まで済ませたのに、戻り値は0で「クリーン」としてパイプラインを通過する、という最悪の組み合わせが起こり得ます。カスタムスキャンでは -DisableRemediation を付けて検出時の処置を行わせない構成にし(検出結果はコマンド出力に表示されます)、「2が返ったら出荷を止めて調査する」判定に加えて、コマンド出力の検出有無と成果物ファイルが欠けていないことの確認までをゲートに含めてください。⁷

3.3. 未知のファイルを事前に申請しておく

Microsoftは、未知・疑わしいソフトウェアのサンプル申請について「システムによるスキャンを受けさせ、評判の確立を始めることに役立つ」と明言しています。⁸ つまりサンプル申請ポータルは検知されてから使う駆け込み寺であると同時に、実績ゼロの新バイナリに最初の実績を作る予防手段でもあります。大きなリリース(メジャーバージョン、パッケージング方式の変更、難読化ツールの導入など、外形が大きく変わるタイミング)では、配布開始前に申請しておく価値があります。

4. 誤検知されたときの正規の対処ルート

4.1. まず事実確認 ── 保護の履歴とイベントログ

「消えた」「起動しなくなった」という報告が、本当にDefenderの検知によるものかをまず確認します。GUIでは、Windowsセキュリティの「ウイルスと脅威の防止」→「保護の履歴」に検知と隔離の記録が残り、隔離された項目のフィルタ表示もできます。⁵

ログとして残したい場合・リモートで確認したい場合はイベントログです。Defenderのイベントは「アプリケーションとサービス ログ → Microsoft → Windows → Windows Defender → Operational」に記録され、PowerShellの Get-WinEvent でも取得できます。¹² 検知そのものはイベントID 1116(マルウェアまたは望ましくないソフトウェアを検出)、それに対する隔離などの処置はID 1117として記録されます。¹³

# Defenderの検知(1116)と処置(1117)のイベントを新しい順に確認
Get-WinEvent -LogName 'Microsoft-Windows-Windows Defender/Operational' |
    Where-Object { $_.Id -in 1116, 1117 } |
    Select-Object TimeCreated, Id, Message -First 10

ここで脅威名(例: Trojan:Win32/Wacatac.B!ml のような検知名)と、検知されたファイルのパス・バージョンを記録してください。Microsoftへの申請でも顧客への説明でも、この2つが出発点になります。検知名の構造(型/プラットフォーム/ファミリ名)はCAROというマルウェア命名規則に従っており、末尾の !ml のような接尾辞から検知の由来を推測できることもあります。¹⁴

4.2. Microsoftへ誤検知を報告する

恒久対応はこれです。Microsoft Security Intelligenceのサンプル申請ポータル(microsoft.com/wdsi/filesubmission)から、誤って検知されたファイルを提出します。申請にはサインインが必要で、サインインすると申請の判定状況を追跡できます。メールでのサンプル受付は行われていません。³

開発者の場合は、申請時にsoftware developer(ソフトウェア開発者)として提出します。判定が確定するまで待ち、判定に不服がある場合は、申請結果に付属する開発者向け連絡フォームからMicrosoftに連絡して再調査を依頼できます。⁴ 提出されたファイルはまず自動システムで即時スキャンされ、すでに処理済みのファイルなら早期に判定が出ます。未処理の申請は、影響範囲の大きいファイルや、Software Assurance IDを持つエンタープライズ顧客からの申請が優先される形で分析されます。¹⁵

誤検知としてMicrosoftが定義を更新すれば、そのファイルは以後検知されなくなります。逆に言えば、報告しない限り、除外設定でしのいでも他の顧客環境では検知され続けます。なお、ファイルとして残らないふるまい検知の場合でも、MpCmdRun.exe -GetFiles で生成できる診断ファイル(MpSupportFiles.cab)を提出して分析を依頼するルートが用意されています。¹⁵⁷

顧客がMicrosoft Defender for Endpoint(EDR)を導入している組織なら、顧客側のセキュリティ管理者がMicrosoft Defenderポータルの申請(Submissions)ページから提出し、あわせて「許可」インジケーターで組織内の誤検知を抑止する、という管理者ルートもあります。¹⁵ この場合は自社だけで完結させず、顧客のIT部門と連携してください。

4.3. 隔離されたファイルを復元する

誤検知だと確信できるファイルは、隔離から復元できます。GUIでは保護の履歴から対象を選んで「復元」します。コマンドラインでは MpCmdRun.exe を使います。⁵

rem 隔離されている項目の一覧
MpCmdRun.exe -Restore -ListAll

rem 隔離時のファイルパスを指定して元の場所へ復元
MpCmdRun.exe -Restore -FilePath "C:\Program Files\Contoso\ContosoApp\ContosoApp.exe"

-Path オプションで復元先を別フォルダに指定することもできます(この場合、項目は隔離にも残ります)。⁷ ただし、定義が更新される前に復元すれば当然また検知され得るので、実務では「誤検知報告 → 必要なら一時的な除外 → 復元」の順で進めるのが安全です。

4.4. 他社のウイルス対策ソフトで検知された場合

DefenderではなくEDRや他社ウイルス対策製品での検知は、Microsoftに報告しても解決しません。検知した製品のベンダーごとに誤検知報告(false positive submission)の窓口へ個別に申請する必要があります。多くのベンダーが専用フォームを用意しているので、「ベンダー名 + false positive submission」で窓口を探し、Defenderの場合と同じく検知名・ファイル・署名情報を添えて申請してください。複数製品で同時に検知された場合は、ビルド側の要因(難読化・パッカー・同梱物)を疑う材料にもなります。

5. 顧客環境での応急対応 ── 除外設定と、そのリスク

5.1. 除外の位置付け ── 恒久対応ではない

誤検知報告の判定が出るまで顧客の業務が止まる、という状況では、Defenderの除外(exclusion)が応急処置になります。ただし位置付けを間違えてはいけません。Microsoft自身が繰り返し警告しているとおり、除外は技術的には保護の穴(protection gap)であり、(1)控えめに使う、(2)性能問題やアプリ互換性など特定の問題にだけ使う、(3)なぜその除外が必要だったかの経緯を残して定期的に見直す、が公式の原則です。⁶ なお、ここで説明する除外はDefenderウイルス対策のスキャン(スケジュール/オンデマンド/リアルタイム保護)に対する除外です。Microsoft Defender for Endpointを導入している環境では、除外したファイルでもEDRのアラートやその他の検知は引き続き発生し得ます。¹⁶ 「除外を入れたのにアラートが出る」はこの仕様によるもので、故障ではありません。

そして除外を入れるとしても、リアルタイム保護そのものやDefender全体を無効化する提案は論外です。その端末の防御はアプリ以外の脅威に対しても丸ごと下がります。誤検知対応の名目でセキュリティ機能の無効化を顧客に依頼した実績は、後々のセキュリティ監査で必ず問題になります。

5.2. 正しい入れ方 ── フルパスで最小範囲

除外はWindowsセキュリティのGUI(ウイルスと脅威の防止の設定 → 除外)でも追加できますが、手順書に落とすならPowerShellが確実です。除外リストの管理には Add-MpPreference(追加)、Remove-MpPreference(削除)、Set-MpPreference(リストごと置き換え)を使います。Set-MpPreference は既存の除外リストを上書きするため、顧客環境で既存の除外を消してしまわないよう、追加には必ず Add-MpPreference を使ってください。¹⁶

# 管理者権限のPowerShellで実行

# ファイル単位の除外(最小範囲。フォルダではなく実行ファイルをフルパスで)
Add-MpPreference -ExclusionPath "C:\Program Files\Contoso\ContosoApp\ContosoApp.exe"

# 現在の除外設定を確認
Get-MpPreference | Select-Object ExclusionPath, ExclusionProcess, ExclusionExtension

# 誤検知が解消されたら撤去する
Remove-MpPreference -ExclusionPath "C:\Program Files\Contoso\ContosoApp\ContosoApp.exe"

-ExclusionPath はファイル単位でもフォルダ単位でも指定できますが、フォルダを指定するとサブフォルダまで丸ごと対象になるため、まずはファイル単位を検討します。¹⁶ もう一つの -ExclusionProcess は名前から誤解されやすいオプションで、指定したプロセス自身を除外するのではなく、そのプロセスが開くファイルをスキャン対象から外すものです。プロセスの実行ファイル自体を除外したいなら -ExclusionPath を使う、というのが公式の整理です。¹⁷ アプリが大量のデータファイルを開くせいで検知や性能問題が起きるケースでは -ExclusionProcess、実行ファイル自体が誤検知されるケースでは -ExclusionPath、と使い分けます。

意図どおり除外できたかは、MpCmdRun.exe -CheckExclusion -Path <パス> で検証できます。⁷ また、管理された環境ではエンドポイントごとに手で入れるのではなく、Intuneやグループポリシー(コンピューターの構成 → 管理用テンプレート → Windowsコンポーネント → Microsoft Defenderウイルス対策 → 除外)で集中管理するのが前提です。Microsoftは除外の定義・編集にIntuneの利用を推奨しています。¹⁶¹⁵

5.3. やってはいけない除外

除外フォルダは「Defenderが見ない場所」として攻撃者にも利用されます。Microsoftは「たとえ悪意がないと信頼していても除外すべきでない」項目を具体的に列挙しています。¹⁸

• C:\、C:\Temp、C:\Users\、%Windir%\Temp のような汎用フォルダの除外。自社アプリのためにテンポラリフォルダを丸ごと除外するのは、すべてのマルウェアに安全地帯を提供する行為です。
• .exe、.dll、.tmp、.zip のような拡張子単位の除外。
• cmd.exe、powershell.exe、msbuild.exe、java.exe のような汎用プロセスの除外。
• パスなしのファイル名だけの除外(例: ContosoApp.exe)。同名のマルウェアがどこに置かれても除外されてしまうため、必ずフルパスで指定します。

まとめると、除外は「フルパスで・最小範囲で・記録を残して・期限を決めて」です。除外を入れた事実と理由は、顧客側のIT管理者と共有し、誤検知報告の判定が出て検知されなくなったことを確認したら撤去します。

6. 性能影響との付き合い方 ── 「MsMpEng.exeが重い」

誤検知と並ぶもう一つの定番相談が性能です。タスクマネージャーで MsMpEng.exe(Antimalware Service Executable)がCPUを食っている、アプリのファイル出力やビルドが遅い、という症状です。MsMpEng.exe はDefenderウイルス対策のサービス本体で、リアルタイム保護の既定動作は「ファイルを開いた時点で同期的にスキャンする(open now, scan now)」です。¹⁹ 大量の小さいファイルを開閉するワークロード ── ビルド、ログの細かい書き込み、テンポラリファイルの多用 ── ほどスキャン回数が増え、影響を受けやすい構造だということです。

6.1. まず計測 ── Performance analyzer

「重いから除外」と直行する前に、何がスキャン負荷の中心なのかを計測します。Defenderには専用のPerformance analyzerがあり、PowerShellの New-MpPerformanceRecording でスキャンのパフォーマンス記録(ETL)を採取し、Get-MpPerformanceReport で集計できます。⁹

# 管理者権限のPowerShellで実行

# 記録を開始し、重い操作(ビルド、バッチ処理など)を再現してからEnterで停止
New-MpPerformanceRecording -RecordTo .\Defender-scans.etl

# スキャン時間の上位ファイルと、そのファイルへのスキャン内訳を表示
Get-MpPerformanceReport -Path .\Defender-scans.etl -TopFiles 3 -TopScansPerFile 10

-TopFiles / -TopScansPerFile のほか、プロセス別・拡張子別の集計も取れるので、「自社アプリのどのファイルアクセスがスキャンを誘発しているか」を具体的に特定できます。注意点として、このツールは問題ファイルの洞察を得るためのもので、除外を提案するためのものではないと公式ドキュメント自身が釘を刺しています。¹⁰

6.2. 除外の前にアプリ側でできること

計測で「自社アプリが書き出す大量のテンポラリファイルがスキャンの中心」と分かったなら、除外の前にアプリの書き込みパターンを見直す余地があります。リアルタイム保護がファイルのオープンを契機に動く以上¹⁹、次のような設計変更はスキャン回数そのものを減らします。

• 数千個の小さい中間ファイルを開閉する処理を、少数のファイルへの追記やメモリ内処理に集約する
• 「一時ファイルを書いてはリネーム・削除」を繰り返すパターンを減らす
• ログを1行ごとに開いて閉じる実装をやめ、ストリームを開いたまま書く

どのプロセスがどのファイルをどんな頻度で触っているかの実測には、Process Monitorがそのまま使えます。手順は「Process Monitor(ProcMon)実践ガイド」を参照してください。

6.3. 開発機ならDev Driveのパフォーマンスモード

開発機のビルドが遅い、という文脈ではWindows 11のDev Drive + パフォーマンスモードが第一候補です。Dev Drive(ReFSベースの開発用ボリューム)上では、Defenderのリアルタイム保護が非同期の「パフォーマンスモード」で動作します。ファイルオープン時に同期スキャンする代わりに、オープン完了後に遅延してスキャンする「open now, scan later」方式で、フォルダ除外のようにスキャンを完全に止める手法よりも大幅に高い保護を保ったまま性能を改善できる、と公式が位置付けています。¹⁹ ソースツリー、パッケージキャッシュ、ビルド出力をDev Driveに移すのが定石です。²⁰

ただしパフォーマンスモードはDev Drive上でのみ動作し、リアルタイム保護が有効であることが前提です。また「MsMpEng.exeのCPU/メモリ使用率が高い」という症状への対処はパフォーマンスモードの守備範囲ではなく、その場合は前述のPerformance analyzerでホットなプロセス・パスを絞り込むのが公式の案内です。¹⁹

このほか、オンデマンドスキャン(定期のフルスキャン等)が業務時間帯に重い、という場合には、MpCmdRun.exe -Scan に -CpuThrottling スイッチがあることも覚えておくと役立ちます。付けるとスキャンのCPU使用率に上限(既定では50%)が適用されます。⁷ ただし、スイッチに数値を渡して任意の割合を指定する形式ではありません。上限値そのものはポリシー側の設定(ScanAvgCPULoadFactor)で構成するもので、この値はハードリミットではなく「平均としてこの割合を超えないようにする」というスキャンエンジンへの目安です。²¹

7. 判断表 ── 症状別・取るべき行動

どのケースでも共通するのは、「まず事実(検知名・対象・検知した製品)を確定させる」「報告という恒久対応を必ず走らせる」「除外・復元は一時対応として最小範囲で」という3点です。

8. まとめ

• 現代のDefenderはシグネチャ照合ではなく、機械学習・クラウド保護・実績(レピュテーション)で判定します。実績ゼロの新しいバイナリが疑われるのは仕組み上の必然で、難読化や自己解凍のような「実体を隠す」構造はさらに疑われやすくなります。
• 予防の柱は、信頼された認証局の証明書による一貫したコード署名です。事前登録による誤検知防止プログラムは存在しません。リリース前の MpCmdRun.exe による自前スキャンと、外形が大きく変わるリリースでの事前サンプル申請も有効です。
• 検知されたら、保護の履歴とイベントログ(ID 1116/1117)で検知名と対象を確定し、Microsoft Security Intelligenceのサンプル申請ポータルへ開発者として提出します。隔離されたファイルは保護の履歴または MpCmdRun.exe -Restore で復元できます。
• 除外設定は報告の判定が出るまでの一時対応です。フルパスで最小範囲、記録を残し、解消したら撤去。テンポラリフォルダや拡張子、汎用プロセスの除外はマルウェアの隠れ場所を作るため厳禁です。
• 性能問題はまずPerformance analyzerで計測し、アプリ側の書き込みパターン改善とDev Driveのパフォーマンスモードを検討してから、それでも必要な場合にだけ限定的な除外を考えます。リアルタイム保護の無効化を顧客に依頼するのは論外です。

関連記事

• Windowsで「Windows によって PC が保護されました」が出る理由
• 自動アップデートのセキュリティ設計 - HTTPSだけでは足りない理由
• Windowsアプリ開発のセキュリティ最低限チェックリスト
• Windowsアプリ配布方式の選び方 - MSI/MSIX/ClickOnce/xcopy/独自更新
• Process Monitor(ProcMon)実践ガイド ── 「設定が読まれない」「ACCESS DENIED」を10分で特定する

関連する相談領域

合同会社小村ソフトでは、配布したアプリの誤検知・SmartScreen警告への対応方針の整理、コード署名を含む配布・更新体制の設計、ウイルス対策ソフト起因の性能問題の計測と切り分けといった相談を扱っています。

• Windowsアプリ開発
• 技術相談・設計レビュー
• お問い合わせ

参考リンク

関連する記事

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

関連トピック

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

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

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

よくある質問

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

自作のアプリがMicrosoft Defenderにウイルスと判定されました。どうすればよいですか？

まず慌てて除外設定やDefenderの無効化に走らないでください。恒久対応の正規ルートは、Microsoft Security Intelligenceのファイル申請ポータル(サンプル申請)から、開発者(software developer)としてファイルを提出することです。サインインすれば申請の判定状況を追跡でき、誤検知と判定されれば定義更新によって以後は検知されなくなります。隔離されてしまったファイルは、Windowsセキュリティの「保護の履歴」またはMpCmdRun.exeの-Restoreで復元できます。

誤検知をMicrosoftに報告するにはどうすればよいですか？

Microsoft Security Intelligenceのサンプル申請ポータル(microsoft.com/wdsi/filesubmission)からファイルを提出します。申請にはサインインが必要で、提出後は判定状況をポータル上で追跡できます。提出されたファイルはまず自動システムで即時スキャンされ、必要に応じてアナリストが分析します。開発者として提出し、判定に不服がある場合は、申請結果に付属する開発者向けの連絡フォームから再調査を依頼できます。

顧客環境で除外設定を入れてもらうのは適切ですか？

誤検知報告の結果が反映されるまでの一時対応としてなら選択肢になりますが、恒久対応にしてはいけません。除外はDefenderの保護に穴を開ける設定で、Microsoft自身が「控えめに使うこと」「特定の問題にだけ使うこと」「定期的に見直すこと」を明記しています。入れる場合は実行ファイルのフルパスなど最小範囲に限定し、誰が・なぜ・いつまでという記録を残し、誤検知が解消されたら撤去します。フォルダ丸ごとやC:\Temp、拡張子.exeのような広い除外は、マルウェアの隠れ場所を作るのと同じです。

コード署名すれば誤検知はなくなりますか？

保証はされませんが、大きく効きます。Microsoftは既知リストへの事前登録のような誤検知防止プログラムを提供しておらず、代わりに「信頼されたルート認証局の証明書で一貫して署名し続けること」を推奨しています。一貫した署名があると調査チームがプログラムの出所を素早く特定でき、既知リストへの追加が早まる場合があります。逆に署名なし・ビルドごとに出所の手掛かりがないバイナリは、実績のない未知のファイルとして毎回ゼロから疑われます。

著者プロフィール

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

小村 豪

合同会社小村ソフト 代表

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