MENU

Windows 10でTCP受信バイト数を計測する方法｜perfmonログで時間別集計＆exe別はETWで対応

Windows10

Windows 10 クライアントで、AWS EC2（Windows Server 2016）との TCP 通信が「どれだけ受信したか（バイト数）」を把握したい——コスト見積もりでは定番の悩みです。本記事では、追加インストールなしで現実的に実現できる最短ルート（perfmon で NIC 受信量をログ化）を中心に、exe 別まで踏み込む場合の選択肢（ETW／サードパーティ）も整理します。

目次

やりたいことを整理すると「2種類の計測」がある

まず混乱しやすいのが、「受信バイト数」と一口に言っても、目的によって必要な粒度が変わる点です。今回の要望は、Windows 10 クライアント側でアプリ（exe）ごと／時間ごと（一定間隔ごと）に受信量を出して、AWS 側の転送量コスト見積もりの材料にしたい、というものです。

計測したい粒度例標準機能だけでの実現性おすすめ度
PC全体／NIC全体の受信量「このPCは1時間で何GB受信した？」可能（perfmon でログ化できる）高（最短・堅い）
exe（プロセス）別の受信量「この exe が1時間で何GB受信した？」難しい（perfmon単体では不可）要件が強い時のみ

結論として、「追加インストールなし・無料」に強くこだわるなら、まず NIC 全体（総量）を perfmon で記録するのが最短です。exe 別が必須なら、ETW で追跡する（設定・解析が高度）か、Wireshark などのツール導入が現実的になります。

結論：総量の受信バイト数なら perfmon のログ機能で解決できる

Windows 標準の「パフォーマンス モニター（perfmon）」は、ネットワークのカウンター（受信/送信）を一定間隔で記録（ログ化）できます。これにより、後から集計して「1時間あたりの受信量」「任意区間の受信量」を算出できます。

ただし重要な注意点があります。

  • perfmon が得意：NIC（ネットワークアダプター）全体のトラフィック
  • perfmon が苦手：exe（プロセス）別のトラフィックの長期ログ

「まずコスト見積もりに必要なのは総量で十分」というケースは多く、ここを押さえるだけで“見積もり作業が前に進む”ことがよくあります。

perfmon で何を取れば「受信バイト数」が出せるのか

ネットワーク受信量の基本は、perfmon のNetwork Interface（ネットワーク インターフェイス）系カウンターです。よく使うカウンターを整理すると次の通りです。

オブジェクトカウンター名意味見積もり用途での使い方
Network InterfaceBytes Received/sec受信スループット（B/s）一定間隔で記録し、後で積算して受信総量（B）を出す
Network InterfaceBytes Sent/sec送信スループット（B/s）サーバー側課金が「送信量」寄りの場合の突合にも便利
Network InterfaceBytes Total/sec送受信合計（B/s）「とにかく総量だけ」でよければ簡単（ただし受信だけではない）

ポイントは、Bytes Received/sec は「累計」ではなく「速度（B/s）」だという点です。ログを取ったあとに、サンプル間隔（例：60秒）を掛けて積算し、バイト総量に変換します。

追加インストールなし：perfmon で受信量を一定間隔でログに残す手順

手順の全体像

やることはシンプルで、perfmon の「データ コレクター セット」を作り、必要なカウンターを指定してログとして保存します。

  • perfmon を起動
  • ユーザー定義の「データ コレクター セット」を新規作成
  • Network Interface のカウンターを追加
  • サンプル間隔（例：10秒、60秒）を設定
  • ログ形式（BLG/CSV）と保存先を指定
  • 開始して放置（必要ならスケジュール設定）

具体手順（GUI）

  1. Windows の検索で perfmon（または「パフォーマンス モニター」）を起動します。
  2. 左ペインで データ コレクター セット → ユーザー定義 を開きます。
  3. 右クリックして 新規作成 → データ コレクター セット。
  4. 任意の名前（例：NetworkRxLog）を付け、手動で作成（詳細）を選びます。
  5. パフォーマンス カウンターを選択し、追加を押します。
  6. カウンター一覧から Network Interface を選び、Bytes Received/sec（必要なら Bytes Sent/sec も）を選択します。
  7. インスタンス（Ethernet、Wi-Fi など）を選び、追加して閉じます。
  8. サンプル間隔を設定します（例：60 秒）。
  9. ログの保存先・形式（BLG/CSV）を選んで完了します。
  10. 作成したデータ コレクター セットを右クリックして 開始。

サンプル間隔はどう決める？（おすすめの考え方）

見積もり用途では「細かすぎるとログが増え、粗すぎると変動が見えない」というトレードオフがあります。迷ったら次を目安にすると運用しやすいです。

サンプル間隔向いている用途メリットデメリット
1秒短時間の性能検証／スパイク解析瞬間的なピークが見えるログが増えやすい
10秒アプリの動作検証／負荷試験粒度とログ量のバランスが良い長期（数週間）だと増える
60秒コスト見積もり／日次・週次集計長期運用に強い細かな揺れは平均化される

「1時間あたりの受信量」を見たいなら、60秒でも十分に意思決定できます。まずは 60 秒で始め、必要が出たら 10 秒にする、の順が失敗しにくいです。

どの Network Interface を選べばいい？（ここで詰まりがち）

PCによっては Network Interface のインスタンスが大量に出ます（仮想スイッチ、VPN、Bluetooth、Loopback など）。EC2 との通信に使っている NIC を選ばないと、値がズレます。

  • まずは タスク マネージャー → パフォーマンス → Ethernet/Wi-Fi を見て、通信が動くアダプター名を確認
  • VPN を使っているなら、VPN 側の仮想アダプターが対象になることがある
  • 同名が複数ある場合は、通信中にグラフが動くものを優先

「どれかわからない」場合は、短時間だけ複数インスタンスでログを取り、あとで値が動いたインスタンスだけに絞る方法が確実です。

ログから「受信バイト総量」を計算するロジック（時間ごとの集計も同じ）

perfmon で取れる Bytes Received/sec は B/s（バイト毎秒）です。したがって、ある区間の受信総量（バイト）は次で求められます。

受信総量（B）＝ Σ（Bytes Received/sec の値 × サンプル間隔（秒））

たとえば、60秒間隔でログを取っていて、その1行が「その60秒間の平均B/s」だとすると、1行あたりの受信量は「値 × 60」です。これを1時間分（60行）足せば「1時間の受信量」になります。

時刻Bytes Received/sec（B/s）間隔（秒）この区間の受信量（B）
10:00:00120,000607,200,000
10:01:0080,000604,800,000
10:02:000600

実務では、これを「1時間ごと」「アプリ動作中だけ」「テストケースごと」など、欲しい単位で集計します。

集計を楽にする：Excel と PowerShell の現実的な使い分け

Excel で集計する（手元でサクッと見積もり）

perfmon のログを CSV で保存すれば、Excel に読み込んでピボット集計しやすくなります。

  • CSV を Excel で開く
  • Bytes Received/sec 列に「サンプル間隔を掛けた列」を作る（例：=B2*60）
  • 時刻を「時間」で丸める列を作る（例：=TEXT(A2,”yyyy/mm/dd hh:00″)）
  • ピボットで「時間ごとに受信量（B）を合計」

「試験を1回やって、見積もりの目安を出す」用途なら、Excel が最短です。

PowerShell で集計する（定期運用・繰り返し試験に強い）

繰り返し試験や、毎日・毎週のレポート化を考えるなら PowerShell で自動集計するとブレません。ここではCSVログを前提に、時間ごとの受信量を集計する例を示します（列名は環境のCSVに合わせて調整してください）。

$csvPath = "C:\PerfLogs\NetworkRx\NetworkRx.csv"
$sampleIntervalSec = 60  # perfmon のサンプル間隔に合わせる

# CSVを読み込み（タイムスタンプ列名やカウンター列名は実ファイルに合わせてください）
$rows = Import-Csv $csvPath

# 例：列名が "Time" と "\Network Interface(Ethernet)\Bytes Received/sec" の場合
$counterColumn = "\Network Interface(Ethernet)\Bytes Received/sec"

$data = $rows | ForEach-Object {
    $t = [datetime]$_.Time
    $v = [double]($_.$counterColumn)

    [pscustomobject]@{
        Timestamp = $t
        HourKey   = $t.ToString("yyyy-MM-dd HH:00")
        Bytes     = $v * $sampleIntervalSec
    }
}

# 1時間ごとの受信量（B）を集計
$hourly = $data |
    Group-Object HourKey |
    ForEach-Object {
        $sumBytes = ($_.Group | Measure-Object Bytes -Sum).Sum
        [pscustomobject]@{
            Hour  = $_.Name
            Bytes = [math]::Round($sumBytes, 0)
            MiB   = [math]::Round($sumBytes / 1MB, 2)
            GiB   = [math]::Round($sumBytes / 1GB, 2)
        }
    } |
    Sort-Object Hour

$hourly | Format-Table -AutoSize

この形にしておくと、ログが増えても「集計ルール」が固定され、見積もりの再現性が上がります。特に AWS のコスト見積もりは、試験条件を変えながら何度も計測し直すことが多いので、集計の自動化は効きます。

コスト見積もり目的なら知っておきたい「計測のズレ」

NIC全体の受信量は「早く・確実に」取れますが、見積もりの観点ではズレが入りやすいポイントがあります。先に対策を知っておくと、後から慌てません。

ズレの原因起きること対策
バックグラウンド通信（Windows Update等）アプリ以外の受信が混ざる計測用PCを分ける／テスト中は不要アプリを閉じる／ベースラインを測って差し引く
VPN/プロキシ経由監視すべきNICが変わる通信経路を固定し、どのアダプターが動くかを事前確認する
再送・ヘッダー等のオーバーヘッド「アプリのデータ量」と一致しない見積もりは“回線上のバイト”として扱う／必要ならパケット解析で補正する
RDP/ファイル共有など別用途の通信テスト通信と混在計測中は別用途のリモート操作を避ける／別時間帯に実施する

AWS の転送量課金は経路や条件で考え方が変わりますが、見積もり作業ではまず「実際にクライアントが受け取った総量」を掴むだけでも、意思決定が一段進むことが多いです。

perfmon だけでは「exe別」は追えない理由

perfmon の Network Interface カウンターは、その名の通りインターフェイス全体の通信量です。ここから「どの exe が何バイト使ったか」を復元する情報は含まれていません。

Windows には「リソース モニター（resmon）」や「タスク マネージャー」でプロセス別の送受信速度を確認できる場面もありますが、次の壁に当たります。

  • 長期ログ（1時間ごと、日ごと）として残しづらい
  • 後から集計しやすい形式で出しづらい
  • exe別の“総バイト”を正確に積算する運用が難しい

そのため「exe別・一定間隔で記録して集計する」という要件を満たすには、別の仕組みが必要になります。

exe別で見たい場合の現実的な選択肢

ここから先は「追加インストールなし」の難易度が上がります。現場での選択肢を、要件と工数で整理します。

方法追加インストール無料exe別時間ごとの集計難易度コメント
perfmon（NIC全体）不要◯×◯低最短で“見積もりに使える総量”が出る
サードパーティ（例：Wireshark等）必要（多くはドライバ含む）◯（フリーが多い）条件次第◯中フィルタや解析に慣れが必要。導入条件に注意
ETW（イベント トレーシング）不要（収集自体は標準で可能）◯◯（突合が必要）◯高“Windowsだけでやり切る”ならこれ。ただし設計・解析が高度
アプリ側で計測（ログ出力）不要◯◯◯中〜高ソース改修できるなら最も正確。運用も安定

「導入条件（インストール不可）」が強い場合、現実解はperfmonで総量かETWで頑張るの二択になりがちです。

ETW で exe 別の通信量に近づける考え方（高度だが標準寄り）

ETW（Event Tracing for Windows）は、Windows 内部で発生するイベントを高性能に収集する仕組みです。ネットワークスタックのイベントも ETW で取れるため、うまく設計すると「接続（フロー）ごとの送受信量」や「送受信イベント」を集めて、プロセス情報と突合できます。

実務上の考え方は次の通りです。

  • ネットワーク関連の ETW プロバイダー（例：TCP/IP 系）から、送受信量に関係するイベントを収集する
  • 同じタイムライン上で、プロセス（PID）と実行ファイル（exe）を辿れる情報も収集する
  • 「接続（5-tuple：ローカルIP/ポート、リモートIP/ポート、プロトコル）」や「PID」をキーに突合し、exe 別に積算する

このアプローチは「Windows 標準機能だけでやり切る」方向に寄せられますが、次のようなハードルがあります。

  • どのプロバイダー／どのイベントを取るかの設計が必要
  • 収集した ETL をどう集計するか（CSV化、パース、突合）の実装が必要
  • 運用で回すならログサイズ管理、個人情報・機密情報の取り扱いも必要

ETW 収集の入口としてよく使われる手段

「ETW を取る」こと自体は Windows 標準のコマンドで始められます。代表的には次のような方法があります。

  • netsh trace：ネットワーク関連のトレース収集に使われることが多い
  • pktmon：パケット寄りの収集が必要なときに使う（解析は別途工夫が必要）

ただし、ここで重要なのは「取る」よりも“欲しい形（exe別×時間別）に集計する”ところが本番、という点です。ETW は万能ですが、運用設計まで含めると一気に難易度が上がります。

「DataBytesIn/Out」を使う発想

ETW のネットワーク関連イベントには、接続単位・イベント単位で送受信バイトに相当する情報が含まれるケースがあります。これを積算し、別途収集したプロセス情報（PID→実行ファイル名）と突き合わせれば、exe 別の送受信量を構築できます。

ただし実装は環境差が出やすいため、まずは小さな範囲（短時間・単一アプリ）でトレースを取り、期待する情報が取れるかを確認してから運用設計に進むのが安全です。

運用のおすすめ：段階的に深掘りすると失敗しにくい

「最初から exe 別を完璧に取ろう」とすると、ETW の設計・解析・運用で詰まって、見積もり自体が止まることがあります。現場で進めやすい順番は次です。

  1. perfmon で NIC 全体の受信量（時間別）をログ化し、ざっくり見積もりが出せる状態にする
  2. 必要なら、テスト中のバックグラウンド通信を減らし、総量のノイズを落とす
  3. 「どうしても exe 別が必要」になった段階で、ETW（またはツール導入、またはアプリ改修）を検討する

この順番にすると、見積もり作業の“止まり”を避けつつ、必要に応じて精度を上げられます。

よくある質問

受信量は「Bytes Received/sec」だけで十分？

受信量だけを見積もりに使うなら十分です。ただし、検証中に「送信も増えていないか」「双方向で想定外の通信が走っていないか」を確認したいなら、Bytes Sent/sec も一緒に取ると原因切り分けが楽になります。

EC2 側で計測した方が正確では？

サーバー側（Windows Server 2016）で送信量を取れば、クライアントの受信量と近い値になることが多いです。ただし、今回の目的が「クライアントが実際に受け取った量」を基準にしたい、またはクライアント側でのみ観測したい事情があるなら、クライアント側 perfmon の価値は高いです。どちらが正しいというより、見積もりで採用する“基準点”を先に決めるのが大事です。

特定のサーバー（EC2）との通信だけを perfmon で取れる？

perfmon の Network Interface カウンターは原則として NIC 全体なので、特定のリモート IP だけに絞るのは不得意です。通信相手で絞りたい場合は、ETW／パケット解析／アプリ側ログなどの選択肢を検討してください。現実的な代替としては「テスト用PCを用意して他通信を極力止める」「ベースラインを測って差し引く」が効きます。

まとめ：最短で見積もりに使うなら perfmon、exe 別は ETW かツールが必要

Windows 10 クライアントが TCP 通信で「どれだけ受信したか（バイト数）」を、時間ごと（一定間隔ごと）に把握したいなら、まずは Windows 標準の perfmon でNetwork Interface の Bytes Received/sec をログ化するのが最短です。ログを積算すれば、1時間あたり／任意区間あたりの受信量を算出できます。

一方で、perfmon 単体では exe 別の通信量を長期ログとして扱うのは難しく、実現するなら ETW での収集・突合（高度）か、Wireshark などのツール導入、またはアプリ側での計測ログ出力が必要になります。まず総量で見積もりを前に進め、必要になった段階で深掘りするのが、実務では最も失敗しにくい進め方です。

Windows10
windows10 TCP perfmon AWS ETW

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次