minto.tech スマホ（Android/iPhone）・PC（Mac/Windows）の便利情報をお届け！ 月間アクセス160万PV！スマートフォン、タブレット、パソコン、地デジに関する素朴な疑問や、困ったこと、ノウハウ、コツなどが満載のお助け記事サイトはこちら！
※本ページにはプロモーション(広告)が含まれています
Windows 11の「Smart App Control(SAC)」は、悪意あるアプリケーションを機械学習ベースで遮断する防御層として有用ですが、開発者モードでVisual StudioやWinDbgから自プロセスにデバッガーをアタッチしようとしたタイミングで「このアプリは保護されています」というメッセージが表示され、アタッチが失敗する事象が報告されています。本記事は、SACの評価(Evaluation)/有効(On)/無効(Off)3つの状態とWDAC(Windows Defender Application Control)の関係、署名付きデバッガーでもブロックされる根本原因、PDBシンボル解決失敗時の対処、Windows Sandbox/Hyper-V分離での検証、reset-sac.ps1によるクリーンリセット手順までを体系的に解説します。対象読者はVisual Studio 2022でnative/managed混在デバッグを行う開発者、WinDbg Previewでカーネルデバッグ準備中の方、および自社製アプリをWindows 11で開発・配布しているエンジニアです。
この記事でわかること
- Smart App ControlとWDACの関係および「一方通行」設計の意味
- SACがデバッガーアタッチをブロックする技術的根拠
- Evaluation/On/Off状態の確認方法と遷移ルール
- Windows Sandboxを活用したSAC影響下検証のテクニック
- reset-sac.ps1でSACを初期状態に戻す安全な手順
基礎解説
Smart App ControlはWindows 11 22H2以降で導入された新しい防御機能で、クリーンインストール時のみ「Evaluation(評価)」モードで起動し、数日〜数週間の学習期間を経てユーザーの環境に応じて自動的に「On」か「Off」に決定します。重要な特性は、一度「Off」に遷移するとクリーンインストールしない限り「On」に戻せないという一方通行設計です。これにより誤ってOFFに下げると永続的に防御が効かなくなるため、開発環境での無効化には慎重な判断が必要です。
SACは内部的にWDAC(Windows Defender Application Control)のポリシーとして実装されており、評判ベースのクラウド判定と組み合わせて「署名が信頼でき」「同じハッシュのバイナリが十分広く出回っており」「過去に脅威報告がない」三条件を全て満たすバイナリのみ実行を許可します。Visual StudioやWinDbgは当然署名付きで広く出回っていますが、問題はデバッガーがターゲットプロセスに「デバッグ権限(SeDebugPrivilege)」でアタッチする行為そのものがSACのポリシー評価対象になり、「アタッチ先プロセスのメモリへの書き込みやスレッド制御」がブロックされる点です。
さらに複雑なのは、PDBシンボルファイルの解決です。Microsoft Symbol Serverから取得したPDBは通常署名付きですが、社内で生成したローカルPDBは未署名です。SACが有効な状態では未署名PDBの読み込みが拒否され、シンボル解決失敗によりデバッガーは有用な情報を表示できません。これは「デバッガーがブロックされた」というより「部分的に機能制限された」症状として現れ、診断を難しくします。
Windows Sandbox環境やHyper-V分離セッションではSACが独立したインスタンスとして動作するため、ホスト側で無効化していてもサンドボックス内で有効になっている場合があります。これがサンドボックス内デバッグ不能の原因となることがあり、サンドボックスの構成ファイル(.wsb)でSACを明示制御する必要があります。
原因の切り分け
SACによるデバッガーアタッチ失敗は、表層症状だけでは他の要因(UAC、Windows Defender、AV製品)と見分けにくいため、切り分けが重要です。
| 原因要因 | 症状メッセージ | 確認コマンド |
|---|---|---|
| Smart App Control On | 「このアプリは保護されています」 | Get-MpComputerStatus SmartAppControl |
| WDACカスタムポリシー | Event ID 3077が多発 | CiTool -lp |
| UAC昇格不足 | アクセスが拒否されました | whoami /priv |
| Windows Defender ブロック | Tamper Protection関連 | Get-MpPreference |
| PDBシンボル未署名 | Symbol loaded skipped | .sympath確認 |
| Hyper-V分離セッション | サンドボックス内限定 | .wsb構成確認 |
最も重要なのは最初の2行の確認です。PowerShell (管理者)で`Get-MpComputerStatus | Select-Object SmartAppControl*`を実行し、`SmartAppControlState`が`On`か`Evaluation`か`Off`を確認してください。`On`なら原因はSACでほぼ確定です。
解決手順（段階別）
ステップ1: SAC状態の確認
管理者PowerShellで次を実行します。
Get-MpComputerStatus | Format-List SmartAppControl*出力に`SmartAppControlState : On`または`Evaluation`とあればSACが稼働中です。`Off`であれば別の原因(UAC、Defenderなど)を疑います。
ステップ2: イベントログでの確認
イベントビューアーで「アプリケーションとサービスログ > Microsoft > Windows > CodeIntegrity > Operational」を開き、デバッガー起動時刻周辺の「Event ID 3077」を探します。Event ID 3077はSAC/WDACによるバイナリブロックを示します。メッセージに該当デバッガーのパスが含まれていれば確証となります。
ステップ3: 評価モードの挙動変更
SACが「Evaluation」の場合、Evaluationは監視のみで実ブロックはしない設計ですが、一部の敏感な操作(他プロセスへのデバッグアタッチ等)は評価中でも制限されます。この場合は「設定 > プライバシーとセキュリティ > Windows セキュリティ > アプリとブラウザー制御 > Smart App Control」を開き、明示的に「Off」にする選択肢を検討します。ただし一方通行設計のため慎重に判断してください。
ステップ4: 信頼された開発者証明書で署名
自社製アプリを開発している場合、Extended Validation(EV)コード署名証明書または信頼できる認証局発行のコード署名証明書でバイナリを署名することで、SACのポリシー判定を通過できます。PowerShellの`Set-AuthenticodeSignature`または`signtool.exe`を使用します。
ステップ5: SACを安全にOFFにする
設定アプリから「Smart App Control」を「Off」に切り替えます。警告ダイアログが表示され、一方通行であることが通知されます。確認後、Windowsを再起動します。再起動後にデバッガーアタッチが正常動作することを確認します。
ステップ6: WDACカスタムポリシーの追加(代替手段)
SACをOFFにせずに個別アプリを許可したい場合、WDACのSupplemental Policyとしてデバッガーのハッシュまたは発行者を許可するルールを追加できます。これには`ConvertFrom-CIPolicy`と`CiTool`を使用します。高度な作業のため、ITProサポート向けの手段です。
ステップ7: Windows Sandboxでの検証環境構築
SACの影響を避けてデバッグ検証したい場合、Windows Sandboxの構成ファイル(.wsb)に`
ステップ8: reset-sac.ps1でクリーンリセット
Microsoftが提供する`reset-sac.ps1`スクリプトを使うと、SACの評価学習結果を初期化してEvaluationモードに戻せます。環境を一度リセットしてから開発環境を整備することで、デバッガー関連のポリシーキャッシュをクリアできます。スクリプトはMicrosoft LearnのSmart App Control公式ドキュメントから取得します。
設定値・パラメータ比較表
| 項目 | 開発者推奨 | 一般利用推奨 |
|---|---|---|
| SAC状態 | Off(署名付き検証環境を別途用意) | On |
| Tamper Protection | On | On |
| WDAC Supplemental Policy | 必要に応じて作成 | 未使用 |
| Windows Sandbox | 検証用に有効化 | 通常未使用 |
| コード署名証明書 | EVまたは標準 | 不要 |
| PDBシンボルソース | Microsoft Symbol Server + ローカル | 不要 |
| UAC レベル | デフォルト(通知) | デフォルト |
よくある失敗と再発防止
開発者が最も陥りやすい失敗は「SACをOFFにすれば戻せる」と誤解して安易に無効化することです。SACは一方通行設計のため、OFFにすると以降はクリーンインストールしない限り永続的にOFFのままとなり、もしその開発用PCを通常用途に転用する際の防御レベルが下がったままになります。対策として、開発用PCは「最初からSACをOFFで運用することを前提にクリーンインストール」し、通常用途PCとは物理的に分離する方針を推奨します。
もう一つの失敗は、サンドボックス環境でSACの影響を忘れることです。Windows SandboxはホストのポリシーをコピーしないためSAC挙動がホストと異なります。.wsb構成ファイルで明示的にSAC関連の設定を記述し、再現性のあるテスト環境を作るべきです。また、サンドボックスは再起動の都度リセットされるため、毎回初期状態から構築できる利点を活かして「問題が再現する環境」のスナップショット化も検討する価値があります。
再発防止には、開発環境とSAC状態のマトリクス管理を推奨します。プロジェクトのWikiに「このリポジトリはSAC Offで開発している」「このリポジトリはSAC Onでも動作確認済み」と明示しておくと、チーム内での混乱を防げます。また、CIパイプラインでSAC Onの検証用ビルドエージェントを別途用意しておくと、リリース前の最終確認として有効です。
FAQ
Q1. SACをOFFにしたらPCは危険になりますか
Windows Defenderの基本防御は継続して動作するため、即座にPCが危険になるわけではありません。ただし、ゼロデイ脅威に対する追加防御層が消失するため、怪しいバイナリの実行には従来以上に注意が必要です。
Q2. Evaluationモードでもデバッガーアタッチがブロックされるのはなぜですか
EvaluationはSAC本来のバイナリブロックは行いませんが、評価モードでも「メモリ書き込みを伴うプロセス間操作」の一部は制限される仕様です。Microsoftの公開資料でも明言されており、開発者は一時的にOFFにするか、別PCを用意することが推奨されます。
Q3. 一度OFFにしたSACをOnに戻す方法はありませんか
公式にはクリーンインストールが唯一の方法です。`reset-sac.ps1`はEvaluationに戻せますが、Evaluationから手動でOnに昇格する手段は提供されていません。Microsoftの設計意図として「ユーザー学習の後退」を防ぐためです。
Q4. WinDbgだけOffにしてVisual StudioはOnのままにできますか
個別アプリ単位でのSAC許可は標準の設定画面からは不可能ですが、WDAC Supplemental Policyでバイナリ固有のハッシュ許可を追加すればWinDbg.exeだけ通過させることは技術的に可能です。ただし設定が複雑で、環境更新時にポリシーメンテナンスが必要になります。
Q5. PDBシンボルファイルの署名を追加できますか
PDBファイルはAuthenticode署名に対応していないため、バイナリ本体のような署名は付与できません。代替手段としては、Microsoft Symbol Server経由で配信する方法、または社内symbol storeを構築して署名付きマニフェストで管理する方法があります。
Q6. Windows Sandboxを使えばSACの影響を完全回避できますか
Windows Sandboxは独立したインスタンスのため、ホストのSAC設定とは別に動作しますが、サンドボックス内でもSACが有効になる場合があります。.wsbファイルで明示的に設定することで回避できます。開発検証環境としては有用な選択肢です。
Q7. 会社支給PCでSACがOnですが、自分の権限では変更できません
企業管理下のPCはIntuneやGroup Policyで設定が固定されている場合があります。IT部門に開発目的の例外申請を行うか、別途開発専用PCの貸与を要望するのが筋です。無断で無効化しようとするとコンプライアンス違反になる可能性があります。
Q8. 開発者モードを有効にしただけでSACは緩和されませんか
Windowsの「開発者モード」とSmart App Controlは独立した機能で、開発者モードを有効にしてもSACの判定ポリシーには影響しません。両者の関係を誤解するとトラブルの原因になるので注意してください。
まとめ
Smart App Controlは強力な防御機能ですが、開発者モードでのデバッガーアタッチと相性が悪く、未署名バイナリやメモリ書き込みを伴う操作がブロックされる仕様です。最初にSAC状態をPowerShellで確認し、Event ID 3077で原因を特定、評価モードの場合は一時的にOffに切り替え、信頼証明書で署名、WDAC Supplemental Policy、Windows Sandbox、reset-sac.ps1リセットと段階的に対応すれば、開発とセキュリティの両立が可能です。一方通行設計の制約を理解したうえで、開発用と通常用のPCを分離運用することが、長期的な安定性確保の最適解です。
