Limited Time Offer: Get 50% OFF your first month of Pro & Ultra plans 🎉

コマンドプロンプトでIPアドレスを確認し、ネットワーク診断とセキュリティ対策を学ぶ実践ガイド

Sep 21, 2026

ネットワーク障害の一次切り分けで、最も確実で速い手段はいまもコマンドラインです。画面遷移の多い管理ツールを開くより、ipconfigping を数回打つほうが、原因の当たりを付けられる場面は少なくありません。本記事では、WindowsのコマンドプロンプトとPowerShellを使い、ローカルIP・グローバルIPの確認から、経路診断、待ち受けポートの把握、そしてセキュリティ対策までを一連の流れとして整理します。読み取り専用の確認コマンドと、設定を変更するコマンドを明確に分けているので、現場で安全に使える手順書として参照してください。

対象読者は、社内ヘルプデスク、情シス担当、インフラ運用に片足を突っ込んだ開発者です。クラウド前提の環境であっても、端末側のIPとポートの状態を読めないと、クラウド側の設定ミスなのか端末側の問題なのかを切り分けられません。診断の順序を体に入れておくと、調査時間は大きく短縮できます。

IPアドレス確認がネットワーク診断の起点になる理由

「つながらない」という症状は、実際には複数の層に分解できます。名前解決が失敗しているのか、経路が存在しないのか、ポートが閉じているのか、アプリケーションが落ちているのか。これらを切り分けるには、まず自分の端末がどのアドレスを持ち、どのゲートウェイを通り、どのDNSを見ているかを知る必要があります。

IPアドレスはネットワーク上の住所です。住所が分からなければ、相手に届いているかどうかを確認できません。逆に住所さえ押さえれば、次の一手が決まります。同じセグメント内の通信なのか、ルーターを越える通信なのかで、疑うべきポイントは変わります。

コマンドラインが今も強い理由は三つあります。一つ目は軽さです。GUIの管理コンソールが応答しないほど負荷が高い状況でも、pingnetstat は動きます。二つ目は記録性です。出力をそのままテキストに残せるため、後から時系列で比較できます。三つ目は自動化との相性です。PowerShellと組み合わせれば、定期収集や差分検知に発展させられます。

診断の基本順序は、自分 → 相手 → 経路 → ポート です。いきなり遠くを疑うのではなく、足元から確認していくほうが結果的に速く到達します。

実行前の準備:権限・ターミナル・記録の取り方

管理者権限をいつ使うか

ipconfigpingtracert の基本実行は一般ユーザー権限で問題ありません。一方で、次の操作は管理者権限が必要です。

  • netstat -b のようにプロセス名を解決するオプション(環境により失敗しやすい)
  • arp -d によるARPキャッシュの削除
  • ipconfig /flushdns が権限不足で拒否される環境
  • netsh advfirewall によるファイアウォール設定の参照・変更
  • New-NetFirewallRule などのPowerShellコマンドレット

読み取り専用の調査は一般権限で行い、設定変更が必要になった時点で昇格する。この切り分けを習慣にすると、誤操作のリスクを下げられます。

コマンドプロンプトとPowerShellの使い分け

既存の手順書やベンダーのドキュメントは cmd 前提のものが多く、netstatroute print はコマンドプロンプトのほうが素直に動きます。一方で、結果を構造化して扱いたい場合や、複数端末の情報をまとめて取得したい場合はPowerShellが有利です。

目的 cmd PowerShell
IP構成の確認 ipconfig /all Get-NetIPConfiguration
接続一覧 netstat -ano Get-NetTCPConnection
経路表 route print Get-NetRoute
ポート疎通 telnet など Test-NetConnection -Port
名前解決 nslookup Resolve-DnsName

両方を併記しているのは、現場には両方の環境が混在しているからです。無理に統一するより、目的に応じて選ぶほうが実務的です。

出力を残す習慣

調査は一度で終わりません。「さっきはどうだったか」を比較できるかどうかで、原因特定の速度が変わります。

Start-Transcript -Path "C:\temp\netcheck.txt" -Append
ipconfig /all
ping 8.8.8.8 -n 4
tracert -d 8.8.8.8
Stop-Transcript

コマンドプロンプトなら command > out.txt 2>&1 でも十分です。ファイル名に日付とホスト名を入れておくと、後から探しやすくなります。

ローカルIPの確認と読み解き方

ipconfigの基本と応用

最も基本的なコマンドは ipconfig ですが、実務では ipconfig /all を常用します。

ipconfig /all

出力のうち、必ず見るべき項目は次のとおりです。

  • IPv4アドレス:端末自身のアドレス
  • サブネットマスク:同一セグメントの範囲を決める値
  • デフォルトゲートウェイ:外部へ出るための出入口
  • DHCP有効/無効:アドレスが自動配布か固定か
  • DNSサーバー:名前解決を依頼する先
  • 物理アドレス(MACアドレス):機器固有の識別子
  • リース取得日時と有効期限:DHCPの状態把握に有効

よくある誤読が、169.254.x.x の見落としです。これはAPIPAと呼ばれる自動割り当てアドレスで、DHCPサーバーからアドレスを取得できなかったことを意味します。この状態では同一セグメント内の限られた通信しか期待できません。まずケーブル、Wi-Fi、DHCPサーバーの到達性を疑ってください。

127.0.0.1 はループバックアドレスで、自分自身を指します。これが表示されていても外部通信の可否は分かりません。

複数アダプタ・VPN・仮想スイッチの見分け方

近年の端末は、物理NIC、Wi-Fi、VPN、Hyper-Vの仮想スイッチ、WSL用の仮想アダプタ、コンテナ用のブリッジなど、複数のインターフェースを持つのが当たり前です。ipconfig /all の出力が長いのはそのためです。

見分けのコツは、アダプタ名と説明欄をセットで読むことです。「イーサネット アダプター」なのか「Hyper-V Virtual Ethernet Adapter」なのかで意味が変わります。VPN接続中は、VPN側のアダプタにアドレスが付き、物理側はそのまま残っていることが多いため、どちらが実際の通信に使われているかを意識してください。

MACアドレスを一覧で見たいときは次を使います。

getmac /v
hostname

hostname は端末名の確認です。資産管理台帳と突き合わせる際に必要になります。

アドレスを再取得するコマンド

DHCPの不調やDNSキャッシュの汚れが疑われるときは、次の順序で実行します。

ipconfig /release
ipconfig /renew
ipconfig /flushdns

/release/renew は一時的に通信が切れます。リモートデスクトップ経由で実行すると自分自身の接続を落とす可能性があるため、原則としてローカル操作か、復旧手段を確保したうえで行ってください。

DNSキャッシュの中身を確認したい場合は ipconfig /displaydns を使います。古いレコードが残っていないかを目視できます。

グローバルIPとDNSの確認

外部から見えるアドレスを調べる

ローカルIPが社内の住所なら、グローバルIPはインターネット上の住所です。ルーターやNATを越えた先で、相手にはどのアドレスが見えているのかを確認します。

Invoke-RestMethod -Uri "https://api.ipify.org"

ブラウザで確認できるサービスを使うのも実務的です。ただし外部サービスに問い合わせる行為そのものがログに残るため、統制の厳しい環境では事前に許可を取ってください。

ここで注意したいのが、ルーターの管理画面に表示されるWAN IPと、外部サービスが見せるIPが一致しないケースです。CGNAT(キャリアグレードNAT)配下では、100.64.0.0/10 のような共有アドレス帯が使われ、複数の契約者が一つのグローバルIPを共有します。この場合、外部からの着信ポート開放は基本的にできません。リモートアクセスを設計するなら、VPNやリバースプロキシなど別の手段を検討する必要があります。

グローバルIPが分かると、次の判断ができます。

  • 許可リスト(IP制限)に登録すべきアドレスは何か
  • アクセスログに記録された送信元は自分の組織か
  • 動的IPのために定期的な更新が必要か
  • 複数拠点で同じアドレスを共有していないか

nslookupで名前解決を検証する

名前解決の調査は nslookup が基本です。

nslookup example.com
nslookup example.com 8.8.8.8

二つ目は、参照するDNSサーバーを明示的に指定する書き方です。端末に設定されたDNSと、外部の公開リゾルバで結果が違う場合、キャッシュの問題か、内部DNS固有のレコード(社内専用の名前)が原因である可能性が高まります。

PowerShellなら Resolve-DnsName が読みやすく、レコード種別やTTLも確認できます。

Resolve-DnsName example.com -Type A
Resolve-DnsName example.com -Server 1.1.1.1

確認すべきポイントは、応答が返るか、期待したアドレスか、TTLが極端に短くないか、複数のレコードが意図せず混在していないか、の4点です。TTLが異常に短い設定は、切り替えを前提とした構成か、あるいは設定ミスの可能性があります。

DNS設定そのものを確認するには次を使います。

Get-DnsClientServerAddress -AddressFamily IPv4

意図しないDNSサーバーが設定されていた場合、それは過去の検証作業の残骸か、悪意ある改変の可能性があります。変更履歴と照合してください。

到達性と経路の診断:ping・tracert・pathping

pingの読み方

ping はICMPエコー要求を送り、応答と往復時間を測ります。

ping 8.8.8.8 -n 10
ping example.com
ping -4 example.com
ping -6 example.com

見るべき指標は、応答の有無、パケットロス率、RTT(往復時間)のばらつきです。平均が小さくても最大値が跳ねている場合、経路のどこかで輻輳や無線の再送が起きています。

重要な注意点として、ICMPがブロックされている環境では応答が返りません。応答なし=障害とは限らないのです。クラウドのセキュリティグループや境界ファイアウォールでICMPを拒否している構成は珍しくありません。この場合はTCPベースの確認に切り替えます。

Test-NetConnection example.com -Port 443

ポート443が開いているのに ping が通らない、という結果は矛盾ではありません。層が違うだけです。

tracertとpathpingの使い分け

tracertは、宛先までの経路をホップ単位で表示します。

tracert -d example.com
tracert -h 15 example.com

-d は逆引きを省略して高速化するオプションです。-h は最大ホップ数で、既定の30では足りない場合に増やします。

途中に * が並ぶのは、そのルーターがICMPのTTL超過応答を返さない設定だからです。必ずしも通信断を意味しません。宛先に到達していれば、途中の * は無視して構いません。

pathpingは、tracertと統計を組み合わせたコマンドで、どのホップでロスが発生しているかを推定できます。ただし実行に時間がかかるため、一次切り分けではなく二次調査に向いています。PowerShellでは Test-NetConnection -TraceRoute が同等の用途に使えます。

判断の目安は次のとおりです。

  • 最初のホップ(ゲートウェイ)で失敗 → ローカル側の問題
  • 途中まで到達して先で失敗 → 経路上の問題、上流の切り分けが必要
  • 宛先まで到達するが遅い → 帯域、無線品質、MTUを疑う
  • 特定の宛先だけ失敗 → 相手側のフィルタかDNSの問題

接続状態と待ち受けポートの可視化

netstatのフィルタリング

netstat は、現在の接続と待ち受けポートを一覧表示します。生の出力は行数が多いため、絞り込みが必須です。

netstat -ano | findstr LISTENING
netstat -ano | findstr ESTABLISHED
netstat -ano | findstr :3389

-a はすべての接続と待ち受け、-n は数値表示(逆引きなしで高速)、-o はプロセスIDの表示です。PIDが分かれば、次のコマンドでプロセスを特定できます。

Get-Process -Id 1234

状態の意味を押さえておきましょう。LISTENINGは接続待ち、ESTABLISHEDは確立済み、TIME_WAITは終了処理中、SYN_SENTは接続要求を出して応答待ちです。SYN_SENTが大量に残っている場合は、宛先からの応答がない、あるいはフィルタされている可能性があります。

バインドアドレスにも意味があります。0.0.0.0 はすべてのインターフェースで待ち受け、127.0.0.1 はローカルからのみ、特定のIPはそのインターフェース限定です。外部に公開したくないサービスが 0.0.0.0 で待っていないかは、定期的に確認したいポイントです。

PowerShellでの確認

構造化された出力が必要ならこちらが便利です。

Get-NetTCPConnection -State Listen | Sort-Object LocalPort
Get-NetTCPConnection -State Established | Select-Object RemoteAddress,RemotePort,OwningProcess

CSVに落とせば、前回との差分を取れます。新しい待ち受けポートが増えていないかを確認する運用は、侵入の初期兆候を捉えるうえで有効です。

ARPとルーティングテーブルの読み方

arp -aでL2の対応を確認する

ARPテーブルは、同一セグメント内のIPアドレスとMACアドレスの対応表です。

arp -a

同じIPに対して異なるMACが短期間で入れ替わる場合、ARPスプーフィングやIPアドレスの競合を疑います。不審なエントリを削除するには次を使います。

arp -d *
netsh interface ip delete arpcache

削除は一時的な対処であり、根本原因の調査が別途必要です。スイッチ側のMACアドレステーブルやDHCPのリース履歴と突き合わせてください。

route printで経路を確認する

route print

注目すべきは、宛先 0.0.0.0 の既定ルートです。ここにゲートウェイが設定されていなければ、外部に出られません。複数の既定ルートがある場合は、メトリックの小さいものが優先されます。VPN接続時に意図しない経路が優先され、社内システムに届かなくなる現象はよくあります。

PowerShellでは次のように確認します。

Get-NetRoute -DestinationPrefix "0.0.0.0/0"
Find-NetRoute -RemoteIPAddress 8.8.8.8

Find-NetRoute は、指定した宛先に対してどのインターフェースとルートが使われるかを教えてくれます。「どのNICを使っているか分からない」という場面で非常に役立ちます。

ルートの追加や削除は、通信を止める可能性があります。検証環境で手順を確認し、変更前の出力を必ず保存してから実施してください。

診断結果をセキュリティ対策に結びつける

ファイアウォール設定の検証

まず状態を確認します。

Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction,DefaultOutboundAction

すべてのプロファイルが有効で、受信の既定がブロックになっているのが基本形です。次にルールを確認します。

Get-NetFirewallRule -Direction Inbound -Enabled True |
  Where-Object { $_.Action -eq "Allow" } |
  Select-Object DisplayName,Profile

見るべきは、Any/Anyで許可しているルール、出所不明のルール、無効化されたブロックルールです。過去の一時的な検証で追加されたまま残っているルールは、意外なほど多く見つかります。

ログを有効にすると、ブロックされた通信を後から追えます。

netsh advfirewall set allprofiles logging droppedconnections enable

ログはサイズが肥大化しやすいため、保存先とローテーションを決めてから有効化してください。

不審な外向き通信の見つけ方

境界の防御だけでなく、端末から外へ出ていく通信も監視対象です。netstatの結果と次の観点を組み合わせて判断します。

  • 見覚えのないプロセスが外部アドレスへ接続している
  • 高位ポートに対する定期的な短時間接続が繰り返されている
  • 業務時間外も継続して接続が維持されている
  • 通常は使わない地域のアドレス宛である
  • DNSクエリだけが大量に発生している

一つ一つは決定的な証拠になりません。複数の兆候が重なったときに、初めて調査優先度を上げます。重要なのは、正常時のベースラインを普段から記録しておくことです。異常は差分でしか見つけられません。

DNSの保護

DNSは名前解決の要であり、攻撃対象にもなります。対策の基本は次のとおりです。

  • リゾルバを信頼できるものに固定し、勝手な変更を防ぐ
  • 端末側でDNS over HTTPS(DoH)を検討する
  • 内部DNSと外部DNSの役割を分離する
  • 定期的にDNS設定の差分を確認する
  • キャッシュ汚染が疑われる場合はフラッシュと再取得を行う

Get-DnsClientServerAddress の出力を定期取得し、前回と比較するだけでも、改変の検知につながります。

自動化と定期監視の設計

手作業の確認は、調査のたびに再現性が揺れます。スクリプト化して同じ手順を繰り返せるようにすると、比較が容易になります。

$out = "C:\logs\netcheck_$(Get-Date -Format 'yyyyMMdd_HHmm').csv"
$result = foreach ($c in Get-NetTCPConnection) {
  [PSCustomObject]@{
    LocalAddress  = $c.LocalAddress
    LocalPort     = $c.LocalPort
    RemoteAddress = $c.RemoteAddress
    RemotePort    = $c.RemotePort
    State         = $c.State
    PID           = $c.OwningProcess
  }
}
$result | Export-Csv -Path $out -NoTypeInformation -Encoding UTF8

これをタスクスケジューラに登録し、1時間おきに実行します。前回ファイルとの差分を取り、新規の待ち受けポートや新規の外部接続だけを抽出すれば、確認すべき行数は数十行に収まります。

設計時の注意点は次のとおりです。

  • 個人情報や認証情報を含む出力は保存先とアクセス権を限定する
  • ログの保存期間とローテーションを決める
  • 収集スクリプト自体の改変を検知できるようにする
  • 収集結果を人が確認する運用とセットにする

AIによる一次分析は、大量のログから候補を絞る用途で役立ちます。ただし、AIの要約は必ず生データと突き合わせてください。判断の根拠は常に一次情報に置きます。

よくあるつまずきとFAQ

Q. pingが通らないのにWebサイトは見られます。故障でしょうか。

故障とは限りません。ICMPが経路上でブロックされているだけの可能性が高いです。Test-NetConnection -Port 443 でTCPの到達性を確認してください。

Q. netstatの出力が多すぎて読めません。

findstr で状態やポートを絞り込むか、PowerShellで State を指定して取得してください。CSVに落として表計算ソフトで並べ替えるのも有効です。

Q. グローバルIPが時々変わります。

動的割り当ての一般的な挙動です。IP制限を使う運用なら、変更検知の仕組みか、固定IP契約、VPNや中継サーバーの利用を検討してください。

Q. 169.254から始まるアドレスが表示されます。

DHCPからアドレスを取得できていません。ケーブル、Wi-Fi接続、DHCPサーバーの稼働状況を確認し、ipconfig /release/renew を試してください。

Q. IPv6は無効化したほうが安全ですか。

単純な無効化は推奨しません。OSやアプリが前提としている場合があり、別の問題を生みます。まず Get-NetIPAddress で状態を把握し、必要ならポリシーで制御するほうが安全です。

Q. 管理者権限がないと何ができませんか。

ipconfig /allpingtracertnetstat -ano などの読み取り系は一般権限で実行できます。できないのは、ファイアウォール設定の変更、ARPキャッシュの削除、ルート変更など、環境に影響を与える操作です。

Q. tracertで * が続きますが、通信はできています。

応答しないルーターが途中にあるだけで、通信自体は成立しているケースが大半です。最終行に宛先が表示されているかを確認してください。

Q. 待ち受けポートの数を減らすには。

不要なサービスを停止し、起動設定を見直します。Get-NetTCPConnection -State Listen でポートとPIDを確認し、Get-Process でプロセスを特定してから、サービス単位で判断してください。

まとめ:確認の順序を固定すると診断は速くなる

コマンドプロンプトとPowerShellによるIP確認は、特別な道具を必要としないぶん、どんな現場でも使えます。大切なのは個々のコマンドの暗記ではなく、確認する順序を固定することです。自分自身のアドレスと設定を押さえ、名前解決を確認し、到達性と経路を見て、待ち受けポートと接続状態を把握する。ここまでを一つの流れとして身につければ、症状の切り分けは格段に速くなります。

そして、診断結果はセキュリティ対策と地続きです。意図しない待ち受けポート、見覚えのない外向き通信、書き換えられたDNS設定。これらはすべて、日常的な確認の延長線上で見つかります。特別な監視製品を導入する前に、まず基本のコマンドで自分の環境を可視化し、その出力を継続的に記録する運用を作ってください。記録があれば、変化に気づけます。変化に気づければ、被害が広がる前に対処できます。

Alexander

Alexander