USBデバイスを接続した際、ウイルスバスターに「デバイスコントロール違反」や autorun.inf に関する警告が出ても、それだけでウイルス感染やUSB機器の故障が確定するわけではありません。まず、自動実行の制限、USBへのアクセス制限、不正プログラムの検出のどれが起きたのかをログで確認します。
この記事では、法人向けの旧ウイルスバスター コーポレートエディションの事例をもとに、保護を無効にせずに原因を切り分ける方法を説明します。個人向けウイルスバスターとは設定画面や管理方法が異なります。現在の環境では、使用中の製品名・バージョンに対応した公式資料を確認してください。
先に結論：警告を消すために自動実行ブロックを解除したり、autorun.inf を一律に許可リストへ追加したりする方法は勧めません。会社や学校の端末では管理者に相談し、必要な操作だけを安全に利用できる方法を検討します。
autorun.infとは：プログラム本体ではなく設定ファイル
autorun.inf は、WindowsのAutoRunに関する情報を記述するテキスト形式の設定ファイルです。起動対象のプログラム名や場所、ドライブのアイコンなどを指定できます。ファイル自身を「USBを挿すと自動で発動するプログラム」と説明するのは不正確です。設定を読み取る仕組みと、その設定が指し示す実行ファイルを区別してください。参考：Microsoft Learn：Creating an AutoRun-Enabled Application。
正規の製品にも使われますが、悪意のあるプログラムを起動させるために悪用されることもあります。ファイル名だけで「ウイルス」「安全」のどちらとも判断できません。必要なのは検出した機能、検出名、ファイルの内容や参照先、機器の入手元などの確認です。
AutoRunとAutoPlayは区別する
- AutoRun（自動実行）：メディアの設定に応じてプログラムなどを起動する仕組みです。
- AutoPlay（自動再生）：メディアの内容に応じて、使用するアプリや操作を案内・処理する仕組みです。AutoRunと同じ意味ではありません。
MicrosoftはWindows 7で、非光学式リムーバブルメディアからAutoRunの操作をAutoPlayに表示する動作を制限しました。一方、USB接続でもCD/DVDドライブとして認識される機器があります。「USB接続なら必ず自動実行される」「自動再生の画面が出ないからUSBが認識されていない」とは言えません。参考：Microsoft：AutoRun changes in Windows 7。
Windows側にもAutoRun／AutoPlayの管理ポリシーがあります。端末のOS、機器の種類、組織のポリシーを確認し、古い画面だけを根拠にレジストリや管理設定を変更しないでください。参考：Microsoft Learn：Autoplay Policy CSP。
最初に「何がブロックされたか」を確認する
「検出された脅威／違反」という通知の見出しだけでは原因を特定できません。詳細画面で機能名と処理内容を確認し、同じ時刻のデバイスコントロールログと不正プログラムの検出ログを分けて調べます。
| 確認できた内容 | 読み取れること | 次に確認すること |
|---|---|---|
| デバイスコントロールのログに autorun.inf が記録されている | 自動実行などのアクセスがポリシーで制限された可能性があります。これだけではマルウェア検出と断定できません。 | 対象パス、禁止された操作、アクセス元、適用された権限を確認します。 |
| 不正プログラムの検出名や隔離・駆除の記録がある | ファイル検索による検出として対応が必要です。デバイスコントロール違反と同時に起きる場合もあります。 | 保護や隔離を維持し、管理者のインシデント対応手順に従います。 |
| USBの読み取り・書き込み・実行が拒否される | ストレージへのアクセス権限で制限されている可能性があります。 | 必要なのがファイルの参照、保存、アプリの起動のどれかを明確にします。 |
| エクスプローラーにドライブが見当たらない | 表示だけでは自動実行制限、デバイス全体のブロック、機器やWindows側の問題を区別できません。 | 管理者がデバイスの認識状態と関連ログを確認します。初期化やフォーマットは行いません。 |
Trend Microの公式資料では、デバイスコントロールは外部機器などへのアクセスを制御する機能で、ファイル検索と組み合わせて利用するものとされています。USBの自動実行をブロックする設定と、読み取り・書き込み・実行の権限は別に説明されています。自動実行だけを制限することと、USB全体を利用禁止にすることは同じではありません。参考：Trend Micro：デバイスコントロール機能の概要・設定方法およびUSBメモリを検索する方法について。
保護を維持して切り分ける手順
1．実行せずに警告の情報を残す
不明なプログラムやショートカットを開かず、次の情報を記録します。警告を再現するためだけにUSBを何度も挿し直したり、別の業務用PCや私物PCへ接続したりしないでください。
- 警告が出た日時、端末名、製品名・バージョン、Windowsのバージョン
- 通知の全文、機能名、対象パス、検出名や実行された処理
- USB機器のメーカー・型番・入手元と、業務で使う目的
- ドライブが表示されるか、ファイルを読むだけでも拒否されるか、専用アプリだけが起動しないか
取得できない情報は無理に調べず、そのまま管理者へ伝えて構いません。画面を共有する際は、社内の承認済み窓口を使い、無関係な個人情報や機密ファイル名が写っていないか確認します。
2．ログで制限の対象を確認する
管理者は発生時刻と端末を合わせ、対象ファイル、アクセスを開始したプログラム、設定された権限を確認します。旧OfficeScanの公式資料でも、デバイスコントロールログの確認項目として日時、端末、デバイスの種類、対象、アクセス元、権限が挙げられています。参考：Trend Micro：Using Device Access Control to protect your computer against Autorun malware in OfficeScan。
ログに autorun.inf が載っていても、それが「アクセスを制限した対象」なのか、「不正プログラムとして検出したファイル」なのかを読み分けます。ログが不足しているときは、感染の有無や機器が使えない原因を決めつけないでください。
3．必要な作業に応じて対応を分ける
- ファイルを読むだけの場合：自動実行を許可する必要があるとは限りません。承認された媒体であることと検索状況を確認し、組織の許可された方法で必要なファイルを扱います。
- 専用アプリが必要な場合：メーカーの正規の利用方法と管理者の承認を確認します。内容を確かめずにUSB内のプログラムを手動起動することは、原因確認の代わりにはなりません。
- マルウェア検出がある場合：許可リストへの追加や隔離からの復元で通過させず、端末と媒体を管理者の手順で調査します。誤検出が疑われても、確認前に「安全」とは扱いません。
- 機器自体が使えない場合：管理者が適用ポリシーとWindowsの認識状態を確認します。機器の故障やドライバーなども候補になりますが、別のPCへの接続、ドライバーの入れ直し、初期化を先に試すのは避けます。
検索を行う場合も、保護を停止せず、組織で承認された検索・調査環境を使います。「検出なし」だけで安全を保証することはできません。暗号化やロックなどで検索できなかった領域がないかも確認してください。Trend Microは、パスワードで保護されたUSBのデータ領域が暗号化されている場合、その領域内の不正プログラムを接続時の検索で検出できないことがあると説明しています。参考：同社のUSB検索に関する注意事項。
元の記事に残っていた警告画面
元の記事には、USB接続時にWindowsの右下へ「検出された脅威／違反」が表示され、ステータスは「デバイスコントロール違反」だったという記録があります。当時は「USBデバイスを認識しなかった」と記述していました。
これは過去の観察記録です。今回、同じ機器・OS・製品構成での再現確認はしていません。残された文章と画面だけでは、USB全体の認識失敗だったのか、自動実行や一部のアクセスが制限されていたのか、マルウェア検出もあったのかまでは確定できません。
以下は元の記事の警告画面です。現行製品の表示や、特定ファイルの安全性を保証するものではありません。
次の画面は、元の記事で autorun.inf に関するログとして掲載していたものです。対象ファイル名と実際の検出・制御内容を分けて確認する必要があります。
旧記事の設定画面について：そのまま再現しない
以下の4枚は旧ウイルスバスター コーポレートエディションの画面を資料として残したものです。推奨設定や操作手順ではありません。旧記事で案内していた「ブロックを解除する」「autorun.inf を許可する」という方法を、一般的な解決策として採用しないでください。
自動実行ブロックの解除を勧めない理由
旧記事では、対象ホストのデバイスコントロール設定を開く画面を掲載していました。現在のメニューや適用範囲は、利用している製品・バージョンで確認が必要です。
次は旧記事で自動実行ブロックの変更箇所として掲載していた画面です。チェックを外す操作は勧めていません。自動実行の制限を解除しても、ストレージ権限、マルウェア検出、機器側の問題まで解消するわけではありません。使用後に戻す前提でも、その間に保護を弱めることになります。
autorun.infの一律許可を勧めない理由
旧記事では、別の対処方法として同じ設定画面をもう一度掲載していました。こちらも過去の画面記録であり、許可リストへの追加を促すものではありません。
次の画面は「ストレージデバイス上の実行を許可されたプログラム」に関する旧画面です。autorun.inf を追加すればUSBが使える、という一般則はありません。同名のファイルは別の媒体にも存在し得ますし、設定ファイルの名前だけでは、その参照先が信頼できるか判断できません。
Apex Oneの公式資料では、許可するプログラムはパスや署名元などを使って定義し、実行や読み書きの権限を扱います。また、許可するUSBデバイスを指定する機能は別項目です。これらはマルウェア検索の除外設定とも目的が異なります。例外の仕様や利用できる機能は製品構成によるため、必要な場合は管理者が対応資料を確認してください。参考：Trend Micro：Configuring Device Control settings of Apex One。
例外が必要なときに管理者へ伝えること
業務上の必要性が確認できた場合でも、全端末やすべてのUSBに同じ許可を配るのではなく、目的と対象を絞って検討します。内外のクライアント設定を無条件にそろえる必要もありません。次の項目を確認してから、組織の変更管理に従って判断してください。
- 目的：何の業務に必要で、参照・保存・アプリ起動のどこまで必要か。
- 対象：どの利用者、端末、機器、プログラムを対象とするか。
- 安全性の根拠：正規の提供元、必要なアプリ、検索・調査結果が確認できているか。
- 代替方法：自動実行に依存しないメーカーの手順や、承認済みのファイル受け渡し方法を使えないか。
- 適用と確認：承認者、必要な期間、最小限の権限、端末への反映確認、終了後の見直し方法を決める。
変更後に確認するのは「警告が消えたか」だけではありません。必要な作業ができること、不要な操作は制限されたままであること、不正プログラム対策が有効であることを管理者が確認します。
まとめ
autorun.inf に関する警告が出たら、設定ファイルの存在、デバイスコントロール違反、マルウェア検出を切り分けてください。自動実行の制限を外すことを最初の対処にせず、ログと業務上必要な操作を確認し、保護を維持したまま対応することが基本です。
資料確認日：2026年10月20日。この記事の画像は旧記事から引き継いだものです。今回の更新では実機での再現試験、セキュリティ設定の変更、USB内のファイル実行は行っていません。
コメント