Windowsで「Windows Defender Firewallがこのアプリの一部の機能をブロックしました」を修正する方法

エラーの内容

ローカル開発サーバー、ゲーム、データベースツールなどのアプリを起動すると、Windowsに次のポップアップが表示されます：

Windows Defender Firewall has blocked some features of this app

「許可」をクリックしてもアプリが接続を受け付けられないことがあります。ダイアログが一切表示されず、アプリがバインドに静かに失敗することもあります。いずれにせよ、トラフィックが通過できていません。

根本原因

デフォルトでは、Windows Defender Firewallは明示的に許可されていないアプリへのすべての受信接続をブロックします。アプリが初めてポートでリッスンしようとすると、Windowsがプロンプトを表示します。「キャンセル」をクリックした場合、またはデスクトップセッションなしのサービス経由でアプリを実行した場合、ルールが作成されません。それ以降、アプリは静かにブロックされ続けます。

よくある問題が発生するシナリオ：

ポート3000や8080で動作するNode.js / Python / Goの開発サーバーに、ネットワーク上の他のデバイスからアクセスできない
受信接続を受け付けられないゲームやピアツーピアアプリ
同一LAN上の別のマシンから接続できないローカルデータベース（ポート5432のPostgreSQL、ポート6379のRedis）
アプリを新しいパスに再インストールした場合、古いファイアウォールルールが古い場所を指したままで一致しなくなる
スクリプトやスケジューラーがデスクトップセッションなしでアプリを起動したため、プロンプトが表示されなかった

修正方法1 — ファイアウォールGUIでアプリを許可する

PowerShellを使わずに特定のアプリのブロックを解除したい場合はこちらから始めてください：

Windowsセキュリティ → ファイアウォールとネットワーク保護 → アプリにファイアウォールの通過を許可する を開く
設定の変更をクリック（管理者権限が必要）
リストからアプリを見つけ、必要に応じてプライベートおよび/またはパブリックにチェックを入れる
リストにない場合は**別のアプリを許可…**をクリック → .exeファイルを参照 → 追加

Windowsはその実行ファイルのパスに紐付いたファイアウォールルールを作成します。

修正方法2 — 特定のポートへの受信ルールを追加する（PowerShell）

既知のポートでサーバーを動かしている場合、実行ファイル全体を許可するより、ポートベースのルールの方がより制限が厳しくなります。

# TCP ポート 3000 の受信を許可（例：開発サーバー）
New-NetFirewallRule `
  -DisplayName "Dev Server Port 3000" `
  -Direction Inbound `
  -Protocol TCP `
  -LocalPort 3000 `
  -Action Allow `
  -Profile Any

UDPやポート範囲を指定する場合：

# UDP、ポート範囲 7000-7100
New-NetFirewallRule `
  -DisplayName "Game Ports UDP" `
  -Direction Inbound `
  -Protocol UDP `
  -LocalPort 7000-7100 `
  -Action Allow `
  -Profile Private

両方のコマンドを管理者としてPowerShellで実行してください。

修正方法3 — 実行ファイルへの受信ルールを追加する（PowerShell）

動的ポートを使用している場合は、ポート番号を固定するのではなく、実行ファイル自体を許可します：

New-NetFirewallRule `
  -DisplayName "Allow MyApp" `
  -Direction Inbound `
  -Program "C:\Program Files\MyApp\myapp.exe" `
  -Action Allow `
  -Profile Any

従来のcmdを使いたい場合は、netshも使用でき、古いWindowsバージョンでも動作します：

netsh advfirewall firewall add rule ^
  name="Allow MyApp" ^
  dir=in ^
  action=allow ^
  program="C:\Program Files\MyApp\myapp.exe" ^
  enable=yes

修正方法4 — ルールが存在するが無効になっていないか確認する

新しいルールを作成する前に、ルールがすでに存在して単に無効になっていないか確認してください：

# すべての受信ルールを一覧表示
Get-NetFirewallRule -Direction Inbound | Select-Object DisplayName, Enabled, Action

# 名前のキーワードでフィルタリング
Get-NetFirewallRule -Direction Inbound | Where-Object { $_.DisplayName -like "*MyApp*" }

無効なルールが見つかりましたか？コマンド1つで再度有効にできます：

Set-NetFirewallRule -DisplayName "Allow MyApp" -Enabled True

修正方法5 — テスト用に一時的にファイアウォールを無効にする

ファイアウォールが本当に問題なのか確認できない場合は、一時的に無効にして確認してから、すぐに再度有効にしてください。

# 全プロファイルのファイアウォールを無効にする（テスト目的のみ）
Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False

# テスト後すぐに再度有効にする
Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled True

ファイアウォールを無効にしたらアプリが動作した場合、それが原因です。適切なルールを追加して再度有効にしてください — 無効のままにしないでください。

動作確認

ルールを追加した後、実際に機能しているか確認してください：

# アプリが期待するポートでリッスンしているか確認
netstat -ano | findstr :3000

# PowerShellで同じ確認
Get-NetTCPConnection -LocalPort 3000

同一ネットワーク上の別のマシンから：

# Windows（PowerShell）
Test-NetConnection -ComputerName 192.168.1.100 -Port 3000

# Linux / macOS
nc -zv 192.168.1.100 3000

TcpTestSucceeded : True と表示されれば、ポートが開いてアクセス可能です。完了です。

予防策

再発を防ぐためのいくつかの小さな習慣：

**ファイアウォールルールは実行ファイルのパスに紐付いています。**アプリを別のフォルダに再インストールしたり、ディレクトリ名を変更したりすると、古いルールが静かに一致しなくなります。追加したルールとその日時を記録しておくと、クリーンアップが簡単になります。
**可能な限りルールのスコープをプライベートネットワークのみに設定してください。**ポート3000の開発サーバーは、パブリックプロファイルでアクセスできる必要はありません。露出を最小限に抑えましょう。
具体的な表示名を使用してください。「Dev Server Port 3000」は、半年後に監査するとき「New Rule 4」よりずっとわかりやすいです。古いルールのクリーンアップ時に非常に役立ちます。
ルールのスコープを特定のサブネットに限定したい場合は、ToolCraftのサブネット計算機でCIDR範囲を素早く計算できます — 任意のソースではなく192.168.1.0/24のみを許可したい場合に便利です。ブラウザベースで、何もマシン外に送信されません。

古いルールのクリーンアップ

ファイアウォールルールはすぐに蓄積されます。不要になったルールを監査して削除してください：

# 表示名でルールを削除
Remove-NetFirewallRule -DisplayName "Old Dev Server"

# 特定のプログラムに紐付いたルールを検索
Get-NetFirewallRule -Direction Inbound | `
  Get-NetFirewallApplicationFilter | `
  Where-Object { $_.Program -like "*node*" }