Windowsファイアウォールと業務アプリ ── 受信規則はインストーラーで登録する

「開発機では動くのに、客先のPCへ入れると別の端末から接続できない」。この相談で、Windowsファイアウォールを疑う場面はあります。ただし、通信できないことと、ファイアウォールが遮断していることは同じではありません。 アプリが待ち受けていない場合もあれば、接続先やポートが違う場合、許可規則がネットワークの条件に合っていない場合もあります。

開発機では、過去に作った許可規則が残っていることがあります。その状態で動作確認しても、新規導入先の挙動を再現したことにはなりません。初回起動の警告で誰かが許可することを前提にせず、どの通信を、誰が、どの段階で許可するのかを製品の導入手順に含めておく必要があります。Microsoftも、アプリの初回起動前に必要な規則を配置することを推奨しています。¹

この記事では、別端末からTCP接続を受け付ける業務アプリを主な例に、規則の設計とインストーラーへの組み込み、客先で通信できないときの確認順序を整理します。Windows 11やWindows Serverの運用を想定し、技術的な説明は2026年9月8日に確認したMicrosoftの公開資料に基づきます。コマンド中の製品名、パス、ポート、IP範囲は例です。実環境に合わせて置き換えてください。

1. まず結論

先に押さえたいのは、次の3点です。

• 受信規則の要否は、アプリ名ではなく通信の向きで決めます。 自分から接続するだけなのか、別端末からの新しい通信を待ち受けるのかを区別します。²
• 必要な規則は、初回起動より前に配置します。 ローカル管理が許される端末ではインストーラー、組織管理の端末ではGPOやIntuneなどによる配布が選択肢です。¹
• 障害時は、待ち受け、TCP接続、プロファイル、規則、ログの順で確認します。 規則の存在だけで許可を、ログがないことだけで未到達を断定しないことが重要です。³⁴⁵⁶

本記事の「インストーラーで登録する」という結論は、組織の管理ポリシーを上書きするという意味ではありません。通信に必要な設定を、利用者の初回操作ではなく、責任の明確な導入工程で整えるという意味です。

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全35件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2. 既定動作を正確に ── 受信は既定ブロック、送信は既定許可

Windowsファイアウォールは、端末自身の通信を制御するホスト型ファイアウォールです。既定では、要求への応答でも許可規則に一致する通信でもない受信をブロックし、送信はブロック規則などがなければ許可します。これはWindowsの既定値であり、客先の管理者が変更していないことまで保証するものではありません。²

たとえば、受注クライアントが受注サーバーのTCP 50051へ接続するなら、新しい接続を受け付けるのはサーバー側です。クライアントがその接続上の応答を受け取るために、同じ番号の受信ポートを開けるわけではありません。²

リモートの名前付きパイプはSMBを利用します。一般的な直接ホスト型SMBではTCP 445を使うため、独自アプリのexeに対する許可だけで解決するとは限りません。ローカルの名前付きパイプと、ネットワーク越しの利用を区別してください。SMBの認証やアクセス権も別途必要です。⁷⁸

次の図は、既定の受信ブロックを前提に、別端末からの接続を受ける部分を探すための整理です。「受信規則が必須」は受信を許可する設定が必要という意味で、既存の管理規則が足りていれば、アプリが重複した規則を追加する必要はありません。同じPC内だけの通信やUDP通信は、このTCP接続の図とは分けて扱います。

flowchart TB
    APP["自社アプリの通信を洗い出す"] --> Q{"ポートを開いて<br/>接続を待ち受けるか"}
    Q -- "待ち受けない<br/>(クライアントとして接続するだけ)" --> C1["受信規則は原則不要<br/>接続の戻りは「応答」として通る"]
    Q -- "待ち受ける<br/>(サーバー型・コールバック受信)" --> S1["受信規則が必須<br/>→ インストーラーで登録(5章)"]
    C1 -.-> EX["例外: 送信既定ブロックの<br/>高セキュリティ環境では送信規則を申請"]

送信の既定がブロックに変更されている環境や、対象アプリの送信を明示的に禁止する規則がある環境では、接続する側の許可も必要です。「クライアントだからファイアウォールは無関係」とは言い切れません。¹ 通信方式そのものを整理したい場合は、プロセス間通信の選び方も参照してください。

2.1. プロファイルと「ネットワークの場所」

規則には、どのネットワークプロファイルで有効にするかという条件があります。代表的な適用の考え方は次のとおりです。²

接続中のネットワークは、次のコマンドで確認できます。複数のアダプターやVPNがある端末では、名前だけでなく、通信に使うインターフェイスも照合します。²

Get-NetConnectionProfile |
    Select-Object InterfaceAlias, InterfaceIndex, NetworkCategory

ドメイン／プライベート限定の規則は、対象の通信がパブリックのプロファイルに属していれば適用されません。ただし、通すためだけにネットワークをプライベートへ変更したり、規則を全プロファイルへ広げたりしないことが大切です。客先のネットワークをどう信頼するか、どのプロファイルで利用を認めるかを管理者と決めます。

2.2. 規則の優先順位

通常の許可・ブロック規則では、明示的な許可は既定の受信ブロックに優先しますが、同じ通信に一致する明示的なブロック規則は、競合する許可規則に優先します。後から追加した方が勝つ仕組みではありません。¹

そのため、「許可規則を追加したのに変わらない」ときは、許可の条件が合っているかに加え、同じアプリやポートに適用されるブロック規則を調べます。無関係な通信を止める規則が存在するだけで、その端末の全通信が止まるわけではありません。IPsec認証を使う特殊なバイパス規則などは、本記事の通常の許可規則とは別の設計です。

3. 「重要な警告」ダイアログの正体 ── 任せてはいけない理由

規則がないアプリが待ち受けを開始すると、設定や実行状況によって「このアプリの機能のいくつかがWindows Defenderファイアウォールでブロックされています」という通知が表示されます。通知を無効にした管理端末などでは表示されないため、警告が出なかったことは、通信が許可された証拠にはなりません。¹

Microsoftが説明する、通知が表示された場合の挙動は次のとおりです。¹

この仕組みで作られた規則が残ると、アプリを再起動しても同じ確認をやり直せません。特にブロック規則が作られていれば、許可規則の追加だけでは解決しない場合があります。規則の出所と必要性を確認したうえで、管理者が対象を限定して整理します。組織が意図的に配布したブロック規則を、アプリ側で削除してはいけません。

次の図は通知による規則作成の流れです。通知が実際に表示される条件や画面の表記は、OSと管理設定によって異なります。

flowchart TB
    L["アプリがポートの待ち受けを開始"] --> Q1{"そのアプリに一致する<br/>規則があるか"}
    Q1 -- "ある" --> R1["規則に従う<br/>(ダイアログは出ない)"]
    Q1 -- "ない" --> Q2{"受信通知は<br/>有効か"}
    Q2 -- "無効" --> R2["黙ってブロック<br/>(規則は作られない)"]
    Q2 -- "有効" --> DLG["「重要な警告」ダイアログ"]
    DLG -- "管理者が「アクセスを許可する」" --> OK["許可規則が作られる"]
    DLG -- "管理者が「キャンセル」" --> NG1["ブロック規則が作られる"]
    DLG -- "管理者権限のないユーザー<br/>(どの操作でも)" --> NG2["ブロック規則が作られる"]
    NG1 --> NEVER["規則を削除するまで<br/>ダイアログは二度と出ない"]
    NG2 --> NEVER

導入時に一度許可しても、別の機能で待ち受けを始める、ネットワークプロファイルが変わる、更新でexeのパスが変わる、といった条件は残ります。必要な通信を先に洗い出し、初回起動前に規則を用意する方が再現性のある導入になります。¹

Microsoftは、非管理者が使う端末について、規則の事前配置と受信通知の無効化を推奨しています。通知は Set-NetFirewallProfile -NotifyOnListen False やグループポリシーで制御できますが、これは端末全体の通知方針を管理する側の判断です。業務アプリのインストーラーが、他のアプリにも影響する通知設定を無断で変える理由にはなりません。通知を切っても、必要な通信が許可されるわけではありません。¹⁹

4. 受信規則の設計 ── プログラム指定・ポート指定・サービス指定

まず、通信仕様を「受信／送信」「TCP／UDP」「待ち受けポート」「実行主体」「接続元」「利用するネットワーク」に分けて書き出します。そのうえで、規則の条件を組み合わせます。¹⁰

-Program に指定するのは、ショートカットやランチャーではなく、実際に通信を担当するexeです。別のサービスやホストプロセスが待ち受ける構成なら、その実行主体に合った設計が必要です。動的ポートを使う場合も、直ちに全ポートを無条件で開けるのではなく、プログラム、サービス、接続元などで絞れる範囲を検討します。¹⁰³

さらに、-Profile で利用するネットワークを、-RemoteAddress で接続元を限定します。たとえば、受注クライアントの配置先が 172.16.10.0/24 と決まっているなら、その範囲を指定します。LocalSubnet は小規模ネットワークなどで使える指定ですが、「社内の全拠点」「VPNの向こう側」まで自動で含むという意味ではありません。実際の経路と、受信側から見える接続元アドレスを確認してください。¹¹⁰

TCPしか使わない機能に、念のためUDPも許可する必要はありません。また、社内限定の機能をパブリックでも有効にするなら、必要性と接続元の制限を別途説明できるようにします。必要な相手から、必要なプログラムの、必要な通信だけを通すのが規則設計の出発点です。

5. インストーラーでの登録実務 ── netshとNew-NetFirewallRule

5.1. 前提: 管理者権限が必要

端末全体のファイアウォール規則を登録・変更・削除する処理は、昇格した管理者権限で実行します。管理者グループのユーザーであっても、UACによる昇格なしでよいとは限りません。¹¹

登録処理をインストーラーの昇格した工程に置けば、アプリ本体を常時管理者として動かす必要はありません。逆に、標準ユーザーだけで完結するユーザー単位のインストーラーには、端末全体の規則を変更する権限がありません。その場合は、管理者による別途のセットアップか、組織からの規則配布を導入要件にします。管理者特権が必要になる場面と、日常のアプリ実行に必要な権限を分けてください。

以下は、自社のexeが固定ポートで待ち受け、インストーラーによるローカル規則の管理が許可されている端末の例です。管理ポリシーによる制限を解除する処理は含めません。

5.2. netsh advfirewall での登録

netsh では、次のようにプログラム、TCPポート、プロファイル、接続元をまとめて指定できます。これは同じ規則をまだ作っていない端末での初回登録例です。管理者として起動したコマンドプロンプトから、バッチファイルとして実行する想定です。¹¹

@echo off
netsh advfirewall firewall add rule ^
  name="MyCompany OrderServer TCP 50051 In" ^
  dir=in action=allow enable=yes ^
  program="C:\Program Files\MyCompany\OrderServer\OrderServer.exe" ^
  protocol=TCP localport=50051 ^
  profile=domain,private remoteip=172.16.10.0/24
if errorlevel 1 exit /b 1

同じ add rule を繰り返しても更新にはならず、同名の規則が増える可能性があります。削除してから作り直す方式にも、削除後に登録が失敗すると規則がなくなるという問題があります。修復や更新を繰り返す製品では、次節のように識別子を固定して既存規則を更新する設計を勧めます。

撤去時のコマンドは別です。次の削除処理はアンインストール時だけ実行し、上の登録バッチの末尾には追加しません。 名前に一致する規則が対象になるため、他製品と衝突しない名前を使います。¹¹

netsh advfirewall firewall delete rule name="MyCompany OrderServer TCP 50051 In"

終了コードとエラー出力をインストーラーのログに残し、「登録に失敗した」「すでに削除済み」「権限がない」を区別します。登録が失敗しているのに、通信準備まで完了したと利用者へ表示しないことも重要です。

5.3. PowerShell (New-NetFirewallRule) での登録

PowerShellのNetSecurityモジュールでは、規則を特定する -Name と、画面に表示する -DisplayName を分けられます。スクリプトの識別子には、表示言語や文言変更の影響を受けない固定の -Name を使います。¹⁰

次は、同じ処理を再実行しても規則を増やさない、インストール・修復・更新用の例です。既存規則があれば Set-NetFirewallRule、なければ New-NetFirewallRule を使います。表示名を更新するときの引数は -NewDisplayName です。¹²

# インストール・修復・更新用。管理者として実行する。
$ErrorActionPreference = "Stop"
$ruleName = "MyCompany-OrderServer-In"
$displayName = "MyCompany OrderServer (TCP 50051 受信)"
$program = "C:\Program Files\MyCompany\OrderServer\OrderServer.exe"

if (-not (Test-Path -LiteralPath $program -PathType Leaf)) {
    throw "実行ファイルがありません: $program"
}

# この製品が所有するローカル規則の設定。
# 接続元とプロファイルは、導入先の管理者と合意した値に置き換える。
$settings = @{
    PolicyStore   = "PersistentStore"
    Direction     = "Inbound"
    Action        = "Allow"
    Enabled       = "True"
    Program       = $program
    Protocol      = "TCP"
    LocalPort     = 50051
    Profile       = @("Domain", "Private")
    RemoteAddress = "172.16.10.0/24"
}

# 「規則がない」と、取得自体の失敗を区別する。
$existing = @(Get-NetFirewallRule -PolicyStore PersistentStore -ErrorAction Stop |
    Where-Object { $_.Name -eq $ruleName })

if ($existing.Count -eq 0) {
    New-NetFirewallRule -Name $ruleName -DisplayName $displayName @settings |
        Out-Null
} else {
    Set-NetFirewallRule -Name $ruleName -NewDisplayName $displayName @settings
}

この例が変更するのは、PersistentStore にある、自社で管理する名前の規則だけです。同じ識別子を別用途に使わないでください。また、送信元ポート、サービスなどの条件を後から追加した製品では、その条件の移行も明示的に設計します。Set-NetFirewallRule は、指定していない条件をすべて初期状態へ戻す処理ではありません。¹²

削除は、次のアンインストール専用の処理に分けます。対象規則がなければ何も削除しませんが、規則の取得や削除そのものの失敗は隠しません。⁵⁹

# アンインストール用。登録処理と続けて実行しない。
$ErrorActionPreference = "Stop"
Get-NetFirewallRule -PolicyStore PersistentStore -ErrorAction Stop |
    Where-Object { $_.Name -eq "MyCompany-OrderServer-In" } |
    Remove-NetFirewallRule -ErrorAction Stop

これらは登録処理の例であり、インストーラー全体のトランザクションを実装したものではありません。製品へ組み込む際は、設定変更の失敗をインストーラーへ伝えること、更新失敗時に旧版と旧設定へ戻せること、アンインストール時に自社の規則だけを削除することを確認します。

5.4. アップデートでexeパスが変わる場合

プログラム指定の規則は、登録したパスを条件にします。たとえば v1.0 フォルダーのexeに対する規則があっても、更新後に v1.1 フォルダーのexeが待ち受けるなら、その旧規則は新しいexeには一致しません。¹¹⁰

次の図は、その旧パスの規則だけに依存していた場合です。別の有効な許可規則がある場合や、通知が表示されない実行状況まで一律に表すものではありません。

flowchart TB
    V1["v1.0を導入<br/>規則はv1.0フォルダーのexeを指す"] --> UP["アップデートでv1.1フォルダーに配置<br/>実行されるexeのパスが変わる"]
    UP --> MISS["旧パスの規則は対象を見失う<br/>(規則は残っているのに効かない)"]
    MISS --> Q{"受信通知は<br/>有効か"}
    Q -- "有効" --> DLG["ダイアログが再表示<br/>一般ユーザーが触ればブロック規則"]
    Q -- "無効" --> SILENT["ダイアログも出ずに<br/>黙ってブロック"]
    MISS -.->|"対策"| FIX["パスを更新をまたいで固定する<br/>または更新処理で旧規則を削除して再登録"]

対策は、更新をまたいでexeのフルパスを固定するか、更新工程で規則を新しいパスへ変更することです。5.3節の方式なら、同じ -Name の規則を新パスで更新できます。旧規則の削除と再登録を選ぶ場合は、失敗時の復元まで含めて実装し、古い広い許可だけを残さないようにします。

MSIでは、WiXのファイアウォール拡張のように規則を宣言的に扱える仕組みもあります。独自のカスタムアクションでコマンドを起動する前に、利用するツールが対応する条件や更新・撤去の扱いを確認してください。¹³ 配布方式ごとの考え方はWindowsアプリの配布方式の選び方で、ウイルス対策の検知はMicrosoft Defenderの誤検知対応で扱っています。

6. トラブルシューティング ── 「通信できない」の切り分けフロー

問い合わせを受けたら、最初に「接続元と接続先」「使用した名前またはIPアドレス」「TCP／UDPとポート」「失敗時刻」「アプリのエラー」をそろえます。以下はTCPを使う受注サーバーの例です。サーバー側で調べる項目と、実際の接続元で試す項目を混ぜないようにします。

図の TcpTestSucceeded=True は、試験した宛先へのTCP接続が成功したという意味です。アプリの認証・TLS・データ交換まで成功したことや、別の実行ファイルである業務アプリの送信まで許可されることは保証しません。⁴

flowchart TB
    S["「クライアントから通信できない」"] --> N["サーバー側: netstat -ano"]
    N -- "待ち受けていない" --> APP["ファイアウォール以前の問題<br/>アプリ・サービス側を調査"]
    N -- "LISTENINGしている" --> T["クライアント側: Test-NetConnection"]
    T -- "TcpTestSucceeded=True" --> OTHER["到達性は正常<br/>アプリ層(認証・プロトコル)を調査"]
    T -- "False" --> P["サーバー側: Get-NetConnectionProfile<br/>適用中プロファイルを確認"]
    P -- "規則の対象と不一致" --> FIXP["規則のプロファイル指定を見直す"]
    P -- "一致している" --> R["Get-NetFirewallRule -PolicyStore ActiveStore<br/>許可規則の有無・ブロック規則の混入を確認"]
    R --> LOGCHK["pfirewall.logで破棄(DROP)を実測"]

1. 待ち受けでは、ポートだけでなくアドレスとプロセスも見ます。 LISTENING でも、127.0.0.1 や ::1 だけにバインドしているなら、別端末からそのまま接続できる待ち受けではありません。対象のLANアドレスで待ち受けているか、別プロセスが同じポートを使っていないかを確認します。netstat -ano のPIDをタスクマネージャーなどと照合し、必要な権限があれば netstat -abno で実行ファイルも調べられます。IPv4とIPv6は分けて確認してください。³

2. TCP接続の試験は、実際の接続元で行います。 次の例では RemoteAddress、SourceAddress、InterfaceAlias、TcpTestSucceeded を確認します。⁴

# クライアント側で実行する。名前とポートは実環境に置き換える。
Test-NetConnection -ComputerName sv01 -Port 50051 -InformationLevel Detailed

False でも、Windowsファイアウォールが原因と確定するわけではありません。名前解決、接続先、経路、VPN、ネットワーク機器、別製品の通信制御なども候補です。逆に True なら、まず接続先が意図したサーバーかを確認し、そのうえで業務アプリの接続先設定や認証、プロトコルを調べます。IPアドレスでの試験はTCP到達性の比較には使えますが、名前を使う認証や証明書検証の動作まで同じになるとは限りません。このコマンドの -Port はTCP試験であり、UDPの成否判定には使いません。⁴

3. プロファイルと4. 規則は、実際に適用される設定で確認します。 Get-NetFirewallRule の既定の参照先はローカルの永続ストアです。GPOなどを含む現在のポリシーを見るには、-PolicyStore ActiveStore を指定します。規則の存在だけでなく、プロファイル側の設定も確認します。⁵¹⁴

# サーバー側で、管理者として実行する。
Get-NetConnectionProfile |
    Select-Object InterfaceAlias, InterfaceIndex, NetworkCategory

Get-NetFirewallProfile -PolicyStore ActiveStore |
    Select-Object Name, Enabled, DefaultInboundAction, DefaultOutboundAction,
        AllowInboundRules, AllowLocalFirewallRules

$rules = @(Get-NetFirewallRule -PolicyStore ActiveStore -TracePolicyStore |
    Where-Object { $_.Enabled -eq "True" -and $_.Direction -eq "Inbound" })

$rules | Select-Object Name, DisplayName, Action, Profile,
    PolicyStoreSourceType, PolicyStoreSource

AllowInboundRules が無効な構成では、許可規則を追加するだけでは受信を許可できません。また、ローカル規則の適用可否は7章の管理ポリシーと合わせて判断します。NotConfigured などの未構成値は、その文字列だけで許可・不許可を断定せず、管理者に実効設定を確認します。¹⁵

プログラム、ポート、アドレスは、規則に関連するフィルターオブジェクトにあります。次の例では、自社規則の条件をそれぞれ表示します。$rules は上のコマンドで取得したものを使います。^5161718

$targetRules = @($rules | Where-Object { $_.Name -eq "MyCompany-OrderServer-In" })
$targetRules | Get-NetFirewallApplicationFilter | Select-Object Program
$targetRules | Get-NetFirewallPortFilter | Select-Object Protocol, LocalPort, RemotePort
$targetRules | Get-NetFirewallAddressFilter | Select-Object LocalAddress, RemoteAddress

# 自社規則とは別名のブロック規則も調査対象にする。
$rules | Where-Object { $_.Action -eq "Block" } |
    Select-Object Name, DisplayName, Profile, PolicyStoreSourceType, PolicyStoreSource

ブロック規則についても、候補の規則から同様にフィルターを確認します。サービス指定があるなら Get-NetFirewallServiceFilter など、その条件も調べます。LocalPort -eq 50051 のような完全一致検索だけでは、Any やポート範囲を指定した規則を取りこぼします。 「検索に出なかったので、競合規則はない」としないでください。¹⁷⁵

5. ログは、記録を有効にしたうえで再現させます。 ファイアウォールログは既定では許可・破棄のどちらも記録しません。既定の保存先は %windir%\system32\logfiles\firewall\pfirewall.log、最大サイズの既定値は4,096KBです。まず対象プロファイルの設定と実際の保存先を確認します。⁶

# サーバー側。まず読むだけで、設定は変更しない。
Get-NetFirewallProfile -PolicyStore ActiveStore |
    Select-Object Name, LogBlocked, LogAllowed, LogFileName, LogMaxSizeKilobytes

破棄の記録が無効なら、管理者の承認を得て、対象のプロファイルだけ Set-NetFirewallProfile -Profile Private -LogBlocked True などで有効にします。ここで Private は例です。変更前の設定を記録し、調査後は元の値へ戻します。組織管理の設定なら管理側で変更し、許可通信の大量の記録や全プロファイルの変更を最初から行う必要はありません。⁹⁶

再現時刻、送信元IP、宛先IP、プロトコル、ポートに一致する DROP があれば、その通信が破棄されたことを確認できます。ただし、該当行がないだけでは「パケットが届いていない」と断定できません。 ログ設定が適用されているか、別の保存先を見ていないか、ファイルが更新されているか、書き込み権限に問題がないかを先に確かめます。必要なら通信キャプチャなどを組み合わせます。ログファイルが作られない場合のフォルダーや mpssvc の権限確認も、Microsoftの手順に沿って行います。⁶

さらに調べる場合は、Windows Filtering Platformの監査イベント5152や5157も候補です。パケット単位の監査は大量のイベントを生成するため、Microsoftはブロックされた接続の監視に接続単位の5157を案内しています。監査方針と記録量を管理者と確認し、必要な範囲・期間に絞ります。¹⁹

ファイアウォールの無効化を、最初の確認手段や恒久対策にはしません。 とくに MpsSvc サービスの停止はMicrosoftのサポート対象外です。隔離した検証環境で管理者が比較試験を行う場合でも、サービスは動かしたまま対象プロファイルを限定し、元の設定への復元を必須にします。本番で必要なのは、全面的に防御を外すことではなく、原因に合った設定の修正です。²

7. 組織管理下での注意 ── ローカル規則が効かない環境と申請の作法

GPOやIntuneでファイアウォールを集中管理している環境では、プロファイルごとに「ローカル規則のマージ」を無効にできます。この場合、インストーラーがローカルの永続ストアに規則を作成できても、通信を許可する設定としては適用されません。登録処理の成功と、実効ポリシーへの反映は別です。¹

図の「ローカルで作成した規則」は、5章の PersistentStore に作るような通常のローカル規則を指します。ローカルグループポリシーで構成された規則とは扱いが異なります。これは制限回避のために別のストアへ書き込めばよいという話ではなく、客先の管理者と配布元を統一するための区別です。¹

flowchart TB
    GPOR["GPO/Intuneで配布された規則"] --> EFF["実際に効く規則の集合<br/>(ActiveStore)"]
    LOCAL["ローカルで作成した規則<br/>(インストーラーの登録を含む)"] --> Q{"ローカル規則のマージ<br/>(AllowLocalPolicyMerge)"}
    Q -- "有効(既定)" --> EFF
    Q -- "無効" --> DROP["規則は存在するが適用されない<br/>→ GPO/CSPでの集中配布に切り替える"]

この環境では、ローカル規則を何度も作り直すのではなく、情シス部門へ規則の配布を依頼します。インストーラーは自分が規則を管理するのか、管理側の配布を前提にするのかを区別し、管理方針を勝手に変えない設計にします。

申請には、最低限次の情報をそろえます。TCP 50051を開けてください だけでは、どの端末の、誰の通信を、どこまで許可するかが決まりません。

導入試験は、開発機やサーバー自身からの接続だけで終えず、実際の利用場所と権限で行います。VPN経由など経路が複数あるなら、その経路ごとに確認します。TCP接続が通った後に認証で失敗する場合は、ファイアウォールとは別の調査へ進めます。関連する認証・通信保護の話は、SMB署名とLDAPチャネルバインディングも参照してください。

8. まとめ

Windowsファイアウォールへの対応は、「警告で許可する」「ポートをひとつ開ける」だけでは完結しません。アプリの通信方向を洗い出し、プログラム、ポート、接続元、プロファイルを合わせて設計し、初回起動前に必要な設定を配置することが出発点です。¹¹⁰

ローカル管理が許されるなら、その登録・更新・削除をインストーラーの責任範囲に含めます。GPOやIntuneで管理されるなら、同じ通信仕様を管理者へ渡して配布してもらいます。規則を作れたことではなく、意図した相手と実際のアプリで通信でき、不要な範囲を許可していないことを導入完了の条件にしてください。

通信できないときは、待ち受けアドレスと実行主体、TCP接続、プロファイル、実効ポリシー、破棄ログを順に確認します。「つながらないからファイアウォール」「ログがないから未到達」と飛躍せず、それぞれの結果で分かったことと、まだ分からないことを分けると、次に調べる場所が明確になります。

関連記事

• Windowsのプロセス間通信をどう選ぶか ── 名前付きパイプ / TCP / gRPC / 共有メモリ / COM 判断表
• Windowsアプリ配布方式の選び方 - MSI/MSIX/ClickOnce/xcopy/独自更新
• Windows の管理者特権が必要になるのはいつなのか - UAC、保護領域、設計上の見分け方
• 自社開発のWindowsアプリがウイルス扱いされたら ── Microsoft Defenderの誤検知対応と、性能影響との付き合い方
• SMB署名とLDAPチャネルバインディング ── NTLM対策の「残り半分」を実務で締める
• Windowsサービスの作り方と運用 ── タスクスケジューラとの使い分けからBackgroundServiceのサービス化まで

関連する相談領域

合同会社小村ソフトでは、Windows業務アプリの開発に加え、ファイアウォール規則を含むインストーラー設計、客先で通信できない問題の原因調査、組織管理下での展開に向けた技術相談を扱っています。相談時には、接続元と接続先、通信方式、再現手順、エラーやログがあると、調査範囲を具体化できます。

• Windowsアプリ開発
• 不具合調査・原因解析
• 技術相談・設計レビュー
• お問い合わせ

参考リンク

関連する記事

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

関連トピック

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

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

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

よくある質問

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

クライアントとしてサーバーに接続するだけのアプリにもファイアウォール規則は必要ですか？

既定の送信許可の環境で、自分から接続し、その応答を受けるだけなら、通常はアプリ専用の受信規則を追加する必要はありません。ただし、送信を制限する組織ポリシーや明示的なブロック規則があれば別です。また、クライアントという名前のアプリでも、別端末からのコールバックや通知を待ち受ける部分には受信を許可する設定が必要です。アプリの呼び名ではなく、実際の通信方向で判断します。

「Windowsセキュリティの重要な警告」ダイアログで「アクセスを許可する」を押せば済むのではないですか？

本番の導入手順を、その操作だけに依存させない方が安全です。Microsoftの説明では、通知が表示された管理者がキャンセルした場合や、管理者ではないユーザーが操作した場合には、ブロック規則が作られます。後から許可規則を追加しても、競合するブロック規則があれば通りません。初回起動前に、インストーラーまたは組織の管理者が必要な規則を配置します。

受信規則はポート指定とプログラム指定のどちらで作るべきですか？

固定ポートで待ち受ける自社アプリなら、プログラムのフルパスとプロトコル、ローカルポートを組み合わせ、接続元IPとプロファイルも必要な範囲に絞るのが基本です。動的ポートやサービスとしての実行など、構成に応じた調整は必要です。プログラム指定の規則では実行ファイルのパス変更を更新処理に反映し、ポートだけの広い許可を安易に作らないようにします。

インストーラーが登録した規則が、客先のPCでは効いていないようです。なぜですか？

規則の登録成功だけでは、通信が許可されたとは判断できません。待ち受けアドレス、実行ファイルのパス、プロファイル、接続元IP、競合するブロック規則を確認します。さらにGPOやIntuneでローカル規則のマージが無効になっていると、インストーラーが作った規則は適用されません。その場合は管理ポリシーを回避せず、情シス部門による規則の配布に切り替えます。

通信の切り分けのためにファイアウォールを一時的に無効化してもよいですか？

まず待ち受け、実効ポリシー、破棄ログで調べます。ファイアウォール全体の無効化は通常の対処にせず、特にMpsSvcサービスの停止はMicrosoftのサポート対象外なので避けます。管理者が隔離した検証環境で一時的に無効化する必要がある場合も、サービスは動かしたまま対象プロファイルを限定し、変更前の設定を記録して直ちに復元します。

著者プロフィール

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

小村 豪

合同会社小村ソフト 代表

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