2026年。
クラウドがあります。
SD-WANがあります。
SASEがあります。
Pythonがあります。
Ansibleがあります。
APIがあります。
AIにログを読ませて、障害原因を整理してもらえる時代になりました。
ネットワークエンジニアを取り巻く技術は、この20年でかなり変わったと思います。
ところが、ネットワークの切替作業になると、今でも見かけるものがあります。
ExPingです。
作業前にExPingを起動する。
対象となるIPアドレスを並べる。
192.168.10.1 OK
192.168.10.2 OK
192.168.10.3 OK
10.10.1.254 OK全部緑。
「作業前疎通OKです」
そして設定変更。
少しPingが落ちる。
しばらくすると、また全部緑になる。
「復旧しました」
私はこういう光景を見ていて、たまに思います。
我々はいつまでExPingを使い続けるんだろう。
今回はExPingについて少し考えてみたいと思います。
タイトルはネタっぽいですが、私は別にExPingを否定したいわけではありません。
むしろこの記事を書きながら考えてみると、
ExPingって相当優秀なのでは?
と思っています。
そもそもExPingとは?
まず、ExPingを知らない人向けに簡単に説明します。
ExPingは、複数のIPアドレスに対してPingを実行し、その結果を一覧で確認できるWindows向けのツールです。
Windowsなら普通に、
ping 192.168.1.1
と実行すればPingできます。
1台ならこれで十分です。
でもネットワークの切替作業では、
192.168.1.1
192.168.1.2
192.168.1.3
192.168.1.4
192.168.2.1
192.168.2.2
192.168.2.3
のように、複数の機器やサーバーを同時に見たいことがあります。
そんなときにExPingを使うと、
Router-A OK
Router-B OK
Server-A OK
Server-B OK
というように一覧で確認できます。
個人的には、この「一覧で見られる」という一点だけでもかなり便利だと思っています。
しかしExPingの最終更新は2005年
ExPingについて改めて調べてみて、個人的に一番面白かったのがここです。
公式サイトに掲載されている最新版は、
Version 1.33。
最終更新日は、
2005年8月23日。
20年以上前です。
しかも公式サイトに記載されている動作環境を見ると、
Windows 95
Windows 98
Windows Me
Windows NT4
Windows 2000
Windows XP
となっています。
XPです。
これだけ見ると、
「さすがにもう使うのをやめた方がいいのでは?」
と思います。
普通のソフトならそう考えると思います。
でもネットワークの現場では、今でもExPingという名前が普通に出てきます。
ここが面白い。
この20年間、ネットワーク業界ではいろいろなものが変わりました。
オンプレミス
↓
仮想化
↓
クラウド
↓
SDN
↓
SD-WAN
↓
SASE
↓
Zero Trust
↓
自動化
↓
AI
その横でExPingは、
ExPing
↓
ExPing
↓
ExPing
↓
ExPing
と生き残っている。
私はこれを見て、
古いというより、用途が完成しているのではないか
と思いました。
私がExPingはまだ消えないと思う理由
私は、ExPingはまだしばらく現場から消えないと思っています。
理由はいくつかあります。
理由1:ネットワーク作業で確認したいことが変わっていない
ネットワーク技術そのものは大きく変わっています。
でも、作業中に確認したいことの一つは昔から変わりません。
このIPアドレスまで通信できるか?
これです。
例えばルーティング変更なら、
作業前
Router-A OK
Router-B OK
Server-A OK
Server-B OK
↓
ルーティング変更
↓
作業後
Router-A OK
Router-B OK
Server-A OK
Server-B OK
と確認したい。
この用途なら、
複数IPへPingを実行して結果を一覧表示する
というExPingの機能で十分です。
クラウド時代になったからといって、Pingそのものが突然不要になったわけではありません。
理由2:切替作業中は「一覧で見える」が強い
もちろん、PowerShellでもできます。
Pythonでもできます。
スクリプトを書けばもっと高度なこともできます。
でも、私はネットワーク作業では必ずしも高機能である必要はないと思っています。
例えば冗長化試験中。
Router-A OK
Router-B OK
Server-A OK
Server-B NG
Server-C OK
こうなったとき、
「あ、Server-Bだけ落ちている」
とすぐ分かる。
これが便利です。
特に、
- ルーティング変更
- VLAN変更
- STP切替
- 冗長化試験
- 回線切替
- 機器再起動
のような作業では、複数のPingを画面上で流しっぱなしにしておきたいことがあります。
その用途では、ExPingは今でも分かりやすいです。
理由3:誰でも使える
私はここがExPing最大の強みではないかと思っています。
ExPingの操作をものすごく簡単に説明すると、
- IPアドレスを登録する
- Pingする
- OK/NGを見る
これだけです。
例えば夜間作業で、
「この20台の疎通を見ていてください」
と新人エンジニアにお願いするとします。
ExPingなら比較的すぐ説明できます。
一方で、
「このPowerShellを実行してください。対象IPはCSVから読み込んでいて……」
となると、少し話が変わります。
もちろん、仕組みを作り込むならPowerShellやPythonの方が便利です。
でも、
今この瞬間に20台のPingを見たい。
という用途では、ExPingくらい単純な方が使いやすい。
私はそう思います。
ただし、私は「ExPing全部緑=正常」とは考えない
ここからが、この記事で一番伝えたいところです。
私はExPing自体は便利だと思っています。
今後も使う場面はあると思います。
ただし、
ExPingが全部緑になったからネットワークは正常
とは考えません。
ここはかなり重要です。
Pingで何を確認しているのか
Pingでは、主にICMP Echo RequestとEcho Replyを使って到達性を確認します。
イメージとしては、
PC
│
│ Echo Request
│ 「届きますか?」
▼
Server
│
│ Echo Reply
│ 「届いています」
▼
PC
です。
つまりPingが成功した場合、
そのIPアドレスまで到達して、ICMPの応答が返ってきた
ということが分かります。
これは非常に有用です。
障害切り分けの最初の確認として、私もPingをよく使います。
ただし、それ以上のことまでPingが保証してくれるわけではありません。
Pingが通ってもWebサイトは使えない
例えばWebサーバーがあります。
PC
│
│ ICMP
▼
Web Server
Ping:OK
これだけを見ると正常に見えます。
しかし、
PC
│
│ TCP/443
▼
Web Server
HTTPS:NG
ということは普通にあります。
サーバーOSは起動している。
IPアドレスにも到達できる。
Pingにも応答する。
でもWebサービスが止まっている。
この場合、
ExPing:OK
でも、
利用者:Webサイトが見られない
となります。
だから私は、
Pingは正常性確認ではなく、正常性確認の一部
だと考えています。
PingがNGでも通信できる場合もある
逆もあります。
例えばファイアウォールなどでICMPを許可していない場合です。
Ping NG
TCP/443 OK
HTTPS OK
という状態はあり得ます。
この場合に、
「Pingが通らないからネットワーク障害です」
と判断するのも違います。
私は障害対応や試験をするとき、
このシステムは、何の通信が成功すれば正常なのか?
を考えることが大切だと思っています。
「Pingする人」と「試験を設計する人」は少し違う
若手のころは、
「このIPへPingしてください」
と指示されることが多いと思います。
私もPingそのものは重要な作業だと思っています。
ただ、設計や構築側へ進むと、少し視点が変わります。
今度は、
何を確認すれば、このシステムを正常と判断できるのか
を考える必要があります。
例えばリモートアクセスVPNなら、
VPN装置へPing
だけでは十分ではないでしょう。
私なら例えば、
VPN接続できる
↓
認証できる
↓
IPアドレスが払い出される
↓
DNS名前解決できる
↓
社内サーバーへ通信できる
↓
業務システムを利用できる
というように考えます。
ExPingは、この中の一部分を確認するツールです。
それでいいのです。
一部分を確認するツールなのに、全部を確認したと思わない。
これが大切だと思っています。
PowerShellがあればExPingはいらないのか
ここで、
「じゃあPowerShellを使えばいいのでは?」
という話になります。
確かにその通りな部分もあります。
WindowsならTest-Connectionを使えます。
Test-Connection 192.168.1.1
対象をファイルにして、
$targets = Get-Content .\targets.txt
foreach ($target in $targets) {
Test-Connection -TargetName $target -Count 2
}
とすれば、複数IPを処理できます。
さらに、
- CSVへ保存
- NGだけ抽出
- 実行時刻を記録
- 作業前後を比較
- 自動判定
などもできます。
このレベルまでやるなら、私はPowerShellやPythonを使うメリットが大きいと思います。
TCPポートまで見るならTest-NetConnectionも便利
私はPingだけでは足りない場合、TCPポートまで確認する考え方も重要だと思っています。
例えばHTTPSなら、
Test-NetConnection 192.168.10.100 -Port 443
と実行できます。
これなら、
Ping
↓
IPとして到達できるか
だけでなく、
TCP/443
↓
HTTPSに必要なポートまで接続できるか
を確認できます。
そこからさらに、
ICMP
↓
TCP
↓
HTTP / HTTPS
↓
アプリケーション
↓
実際のユーザー操作
と確認レベルを上げていく。
私は、この考え方を持っていることの方が、
ExPingを使うか使わないか
より重要だと思っています。
ExPingとPowerShellはどちらが優れているのか
私は「どちらが上か」という話ではないと思っています。
使う場面が違います。
私ならExPingを使う場面
- 数台〜数十台を手軽に確認したい
- 切替作業中に一覧を眺めたい
- 冗長化試験の瞬断を確認したい
- 一時的な確認だけしたい
- スクリプトを作るほどでもない
私ならPowerShellやPythonを検討する場面
- 数十〜数百台以上を処理したい
- 結果を自動保存したい
- 作業前後を比較したい
- OK/NGを機械的に判定したい
- 毎回同じ試験を繰り返したい
私なら監視システムを使う場面
- 常時監視したい
- 障害通知したい
- 応答時間を記録したい
- パケットロスを長期的に見たい
- グラフや履歴を残したい
つまり私は、
その場の確認
↓
ExPing
繰り返す試験
↓
PowerShell / Python
継続的な監視
↓
監視システム
という使い分けでいいと思っています。
ExPing最大の問題は「古いこと」ではないと思う
もちろん、20年以上更新されていないソフトウェアです。
公式サイト上の対応OSもWindows XPまでです。
企業で使用する場合には、現行OSでの動作確認や、会社のセキュリティポリシー、ソフトウェア利用ルールなどを確認する必要があります。
そこは別問題として考えるべきです。
ただ、技術的な観点で見ると、私はExPing最大の問題はそこではないと思っています。
私が怖いと思うのは、
全部緑
↓
ネットワーク正常
↓
試験OK
と考えてしまうことです。
ExPingはPingツールです。
Pingを確認するなら便利です。
しかし、
- DNS
- TCP
- UDP
- TLS
- HTTPS
- 認証
- API
- アプリケーション
- 実際の利用者操作
まで正常であることを証明してくれるわけではありません。
私が卒業したいのはExPingではない
この記事を書く前は、
「我々はいつまでExPingを使い続けるのか」
というタイトルなので、もう少しExPingをいじる記事になると思っていました。
でも書いているうちに、少し考えが変わりました。
私は別に、ExPingを卒業する必要はないと思っています。
むしろ卒業したいのは、
Ping OK = 正常
という考え方です。
通信をかなり大ざっぱに分けると、
物理接続
↓
IP到達性
↓
TCP / UDP
↓
アプリケーション
↓
実際のサービス
となります。
ExPingが確認しているのは、この中の一部分です。
一部分だから価値がないわけではありません。
むしろ、
一部分を素早く確認する
という仕事については優秀です。
重要なのは、
今、自分は何を確認しているのか。
を理解して使うことだと思っています。
私はたぶん、これからもExPingを使う
結局のところ、私はExPingを否定できませんでした。
例えば夜間のネットワーク切替。
対象は20台。
作業開始前は全部Ping OK。
ルーティングを変更。
数秒間Pingが落ちる。
経路が切り替わる。
全部Pingが戻る。
Router-A OK
Router-B OK
Server-A OK
Server-B OK
Server-C OK
これを見たいだけなら、
ExPingでいいじゃないか。
と思います。
最新の技術を使うこと自体が目的ではありません。
ネットワークエンジニアの目的は、
必要な確認を、正確かつ効率よく行うこと
だと思っています。
そのための道具としてExPingが便利なら、使えばいい。
私はそう考えています。
Pingの「その先」が気になった人へ【PR】
ただ、ExPingを使って、
OK
NG
だけを見るところから一歩進むと、ネットワークはかなり面白くなります。
例えばPing一つでも、
宛先IPは同一ネットワークなのか
↓
ARPは発生するのか
↓
デフォルトゲートウェイを使うのか
↓
どのルートが選択されるのか
↓
ICMP Echo Requestはどう届くのか
↓
Echo Replyはどう戻ってくるのか
と考えることができます。
私はネットワークエンジニアとして仕事をするなら、
Pingを打てることより、「なぜPingが通るのか」を説明できることの方が重要
だと思っています。
そうしたTCP/IPの仕組みを体系的に学びたい人には、
『マスタリングTCP/IP 入門編 第6版』
をおすすめします。
IPアドレス、TCP、UDP、ルーティング、各種プロトコルなどをまとめて学べる定番のネットワーク入門書です。
特に、
- pingコマンドは使える
- IPアドレスもなんとなく分かる
- でもパケットがどう流れるか説明するのは難しい
- ARP、ICMP、TCPの関係が曖昧
- 障害対応でもう一段深く考えたい
という人とは相性がいいと思います。
ExPingを使いながら、
「そもそも、このPingの裏側で何が起きているんだ?」
と思ったら、次に読む本としておすすめです。
※リンク先の商品価格・在庫・最新版についてはAmazonの商品ページをご確認ください。
本を読んだら、実際のパケットを見てみる
個人的には、本を読んだらWiresharkで実際の通信を見ることもおすすめします。
Wiresharkを起動して、
ping 192.168.1.1
を実行する。
すると、
ICMP Echo Request
ICMP Echo Reply
を実際に確認できます。
さらに、
- ARP
- DNS
- TCP 3-way handshake
- HTTPS
などを見ていく。
資格学習では単語だったものが、
本当に流れているパケット
として見えるようになります。
この瞬間にネットワークの理解が一気につながる人は多いと思います。
ITジャンプでも、このあたりはネットワーク学習シリーズで順番に解説しています。
あわせて読みたい




まとめ:ネットワークエンジニアはいつまでExPingを使い続けるのか
最初の問いに戻ります。
ネットワークエンジニアはいつまでExPingを使い続けるのか。
私は、
まだしばらく使い続けるんじゃないか
と思っています。
2005年に最終更新されたソフトが、20年以上経っても、
「複数のIPにPingを打って、結果を一覧で見たい」
という要求を満たしてしまっている。
それなら無理に捨てる必要もありません。
クラウドになっても。
SD-WANになっても。
SASEになっても。
自動化が進んでも。
AIがログを解析するようになっても。
夜間作業では誰かが言うのです。
「一応、ExPing流しておきますね」
そして全部緑になった画面を見る。
「よし」
となる。
私もたぶん、これから何度もこの光景を見ると思います。
そして私自身も、必要なら普通にExPingを使うと思います。
ただし、一つだけ忘れないようにしたい。
ExPingの「OK」は、Pingに応答したという意味でしかない。
TCPは正常なのか。
DNSは正常なのか。
アプリケーションは正常なのか。
最終的にユーザーはサービスを利用できるのか。
そこまで考えたうえで、
「今回はPingまで確認すれば十分」
と判断してExPingを使う。
私は、そういう使い方ができればいいと思っています。
古いツールを使っていることが問題なのではなく、何を確認しているか分からないまま使っていることの方が問題です。
そして、そこを理解したうえで使うExPingは、
2026年になっても、
まだ十分便利なツールだと思います。

コメント