「Pingは通る」で終わらせない。業務アプリに近い通信を試すNWTestToolをAIと作りました
こんにちは。メディルです。
これまでは、病院の情報システム課をAIで支援するアイデアや、院内向けWebシステムの開発について紹介してきました。
今回は少し視点を変えて、ネットワークエンジニアやシステム課の方に向けた、Windows用のネットワーク試験ツール「NWTestTool」を紹介します。
作ろうと思った理由は、自分自身がネットワーク試験で感じてきた、ある物足りなさでした。
Pingは通る。でも、業務で使えるかまでは分からない
私がこれまで行ってきた試験では、手元で使えるツールがPingレベルの確認に偏っていました。疎通できたことは分かっても、業務アプリケーションに近い通信を、十分に確かめられているとは言いにくい。そこに試験品質の課題を感じていました。
Pingは、到達性や応答時間を見るための大切な手段です。ただ、Webのログインやデータの送受信、DBへの接続と応答などは、それとは別に確認したいことです。
例えば、次のような通信です。
Web画面を取得し、ログイン後もセッションを維持する
DBへの接続後に要求を送り、まとまった量の応答を受け取る
接続をしばらく維持してから、もう一度通信する
ファイルを送り、受け取った内容が一致するか確認する
こうした確認をしたくても、試験用のWebサーバーやDB、認証環境まで用意するとなると、準備の負担が大きくなります。
「試験区間の両端にPCを置いて、業務アプリに近い通信を手軽に流せたらいいのに」
この経験が、今回の開発の出発点です。
両端に同じツールを置いて試す
NWTestToolは、試験区間の両端に同じツールを置き、一方をサーバー役、もう一方をクライアント役として通信させる構成です。
外部のWebサイトや製品DBを準備する必要はありません。試験用のアカウント、パスワード、転送データもツール側で用意します。
基本的な操作は、次の流れです。
両端のWindows PCにZIPを展開し、ツールを起動する
対向側で待受IPを指定し、「サーバー役を開始」する
クライアント側で対向IPを入力する
試験カードから内容を選び、実行する
同じPCの中で両方の役割を動かすこともできます。まず操作や試験内容を理解してから、別PC間の確認へ進める作りです。
ホームでは、まとめて実行する試験と、個別に選ぶ試験をカードに分けています。「何を確かめたいか」から選べる画面を目指しました。
WEB・DB・ファイル転送・認証を26パターンで確認
現在のv0.7.1では、Pingを含めて26パターンを用意しています。
WEBでは、HTTPSでのページ・CSS・画像の取得、ログインとCookieによるセッション維持、アップロード・ダウンロード、WSS、プロキシ経由のHTTPS通信を試します。
DBでは、SQL ServerのTDS形式やPostgreSQL形式の通信を使い、少量・大量の応答、接続維持後の再通信、ログイン拒否などを確認します。
ファイル転送では、FTPのパッシブ／アクティブ転送や、アップロード後の読み戻しを行います。転送した1 MiBのデータはSHA256で照合します。
認証などのカテゴリには、RADIUS、LDAP、SAML SSO、NTPの応答確認を用意しました。認証拒否の試験は、期待どおりの拒否応答を受け取れれば成功になります。
ここで大切なのは、「実際の業務システムそのものを動かすツール」ではないという点です。
例えばDB試験は、実際のTCP接続でDBのプロトコルに沿った要求と準備済みの応答を往復させます。SQLを解析・実行するDBエンジンは内蔵していません。現在のTDS試験も、暗号化なし・SQLログイン方式の範囲です。
電子カルテや各社の業務アプリの動作保証をするものではなく、その前段で、代表的な通信のやり取りを試しやすくするための道具です。
成功・失敗だけでなく、どこまで進んだかを残す
試験の品質を上げるには、通信を流すだけでなく、結果を説明できることも必要だと考えました。
そのため、処理の段階をクライアント役とサーバー役の図で表示し、失敗した場合は停止した段階を残すようにしています。応答内容の照合や処理時間も確認できます。
さらに、Wiresharkのdumpcap／TSharkとNpcapを導入した環境では、試験対象の通信を選別したパケット取得と解析にも対応しています。結果はJSON、CSV、ログ、取得できた場合はPCAPNGとして保存します。
パケット取得を無効にした状態でも、アプリケーション通信の試験は実行できます。
通信の合否と、パケットから読み取れる所見は分けて扱っています。例えば、通信が成功していても再送の疑いがあれば、その所見を残します。逆に、応答がないという理由だけで、ファイアウォールによる遮断と断定する表示にはしていません。
一括実行で、確認項目の抜けを減らす
個別試験に加えて、代表的な9件を実行する「簡易版」、全26件を実行する「フル版」、カテゴリごとの全試験を用意しました。
実行前に試験内容を確認でき、途中で1件失敗しても後続を続けます。中断した場合は、残りを未実行として残します。
画像は、開発環境の同一PC内でフル版26件を実行した結果です。実際の院内ネットワークでの試験結果ではありません。
「何を実行して、何が成功し、どこが未確認なのか」を残せることが、作業後の説明や再試験につながると考えています。
AIに実装を支援してもらい、試験の意味を詰める
今回も、AIの支援を受けながら開発を進めました。
出発点にあったのは、「業務アプリに近い試験をしたい」という自分の経験です。それを、サーバー役の内蔵、通信パターン、結果保存、操作画面という具体的な機能に落とし込んでいきました。
特に意識したのは、見栄えのよい成功表示を作ることよりも、「何を確認できたら成功と言えるか」を明確にすることです。接続できたこと、応答内容が一致したこと、期待した拒否が返ったことは、それぞれ意味が違います。
現場で感じていた不便を言葉にし、AIと実装を進め、確認できる範囲を整理していく。これまで紹介してきた病院システム課向けの取り組みとも、同じ流れだと感じています。
現在の検証範囲と、これから
開発記録では、v0.7の自動検証137件が合格しています。v0.7.1では画面から簡易版9件、フル版26件、WEBカテゴリ7件の成功を確認しました。通信処理はv0.7から変更していません。
ただし、これらは同一Windows PC内のループバックを中心とした検証です。別PC間や、実機のファイアウォール・VPNを通した検証は、これから確認する範囲です。実機のアプリケーション識別や、業務システムとの相互運用性を保証するものではありません。
通常のWEB試験はTCP/443を使いますが、DBや認証などの多くは試験用の高位ポートです。実業務と同じポート制御を確認したい場合には、試験の条件が合っているかを確かめる必要があります。
使用する際は、許可された試験区間で待受ポートとファイアウォールの設定を確認してください。ツールはOSのファイアウォール設定を自動変更しません。また、配布物は未署名のため、組織のアプリ承認手続きに沿った確認が必要です。
私が欲しかったのは、「Pingは通った」という確認から、もう一歩踏み込むための道具でした。
ネットワークエンジニアや病院システム課の方にも、試験項目や証跡の残し方を考えるきっかけになればうれしいです。今後は実際のネットワーク環境でも確認を進め、その結果や改善点も紹介していきたいと思います。
