トラフィックとは｜意味・単位・見方を通信量と訪問数の実測で解説

「トラフィック（traffic）」は元々「交通量」という意味の言葉です。IT では道路を走る車の代わりに、回線を流れるデータや、サイトに来る人の流れを指します。意味が3つあるので、まず使い分けを押さえます。

flowchart TD
    T[トラフィック<br>= 流れの量] --> N[ネットワーク<br>流れるデータ量<br>単位: bps / バイト]
    T --> W[Web サイト<br>訪問数・セッション数<br>単位: 回・人]
    W --> A[広告のトラフィック<br>= 有料の流入だけ<br>単位: クリック・訪問]

よく調べられることの答えを先にまとめます。

確認環境：Ubuntu 24.04.5 LTS（カーネル 6.18）の上で、ip netns で2つの仮想ネットワーク（10.108.0.1 と 10.108.0.2）を veth でつなぎ、その中だけで通信量を発生させました。計測に使ったのは iproute2 6.1.0 の ip・ss・tc、Ubuntu のパッケージを展開した tcpdump 4.99.4（libpcap 1.10.4）・iperf3 3.16・nload 0.7.4・iftop 1.0pre4・iputils の ping、Web サーバーは同じく展開した nginx 1.24.0 と Python 3.13 の http.server、クライアントは curl 8.5.0 です。回線の上限は netns の中の tc（tbf）で 1〜100Mbps に絞りました。この環境のカーネルには netem（遅延や損失を模擬する機能）が無いため、遅延は「キューにたまった分」だけを計っています。GA4 の流入の分類は Google アナリティクスのヘルプ、転送量の料金は AWS の料金ページ、用語の定義は JPNIC の解説で確かめました（確認日 2026年10月29日）。

トラフィックとは（3つの意味の使い分け）

この節では、「トラフィック」が場面ごとに何を指すのかが分かります。

トラフィックは「流れの量」です。何が流れるかが場面で変わります。 JPNIC（日本ネットワークインフォメーションセンター）の用語解説は、ネットワークのトラフィックを「ネットワーク上を流れるデータそのもの、または一定時間に流れるデータ量」と説明しています。Web のアクセス解析では「サイトを訪れた人やセッションの数」を、広告では「広告からサイトへ送り込む訪問」を指します。

道路にたとえると、ネットワークのトラフィックは「道路を走る車の量」、Web のトラフィックは「店に来た客の数」、広告のトラフィックは「チラシを見て来た客の数」です。客が増えれば車も増えるように、Web のトラフィックが増えると、サーバーのネットワークのトラフィックも増えます。両方を同じ言葉で呼ぶので、会話では「通信量の話か、訪問数の話か」を先にそろえると行き違いが減ります。

3つとも、数えて比べて初めて意味を持ちます。この記事では、1 を Linux の仮想ネットワークで実際に流して計り、2 を Web サーバーのアクセスログから数えます。

ネットワークのトラフィックとは｜ページ1回の表示で流れた量

この節では、Web ページを1回開くと何パケット・何バイトが流れるのかが分かります。

32 バイトの HTML を1回取るのに、10 パケット・1,041 バイトが流れました。 手元の仮想ネットワークで、nginx が返す index.html（32バイト）と big.txt（135,091バイト）を curl で取り、その前後で ip -s link の値がどれだけ増えたかを数えました。

小さなページほど「中身以外」の割合が大きく、32 バイトの HTML では流れた量の 97% が接続の手続きです。135KB のファイルでは中身の 1,448 バイトずつが 98 個のパケットに分かれ、受け取った側から 39 個の確認応答（ACK）が戻っています。トラフィックとして数えるのは、中身だけでなくこの手続きの分を含めた「線を流れた全部」です。

単位の読み方｜bps と B/s、Mbps と MB/s の換算表

この節では、回線の「100Mbps」とダウンロードの「12MB/s」が同じ速さである理由と、換算の表が分かります。

bps はビット毎秒、B/s はバイト毎秒です。1 バイト＝8 ビットなので、Mbps を 8 で割ると MB/s になります。 回線や機器のカタログは bps（小文字の b）、ブラウザのダウンロード表示や iftop -B はバイト（大文字の B）で出すため、同じ速さが別の数に見えます。

同じ計算を Python で出した表です。転送にかかる理論上の時間は「大きさ（ビット）÷ 速さ（bps）」で、ヘッダーなどの上乗せ分は含みません。

     1 Mbps =    0.125 MB/s =        125 KB/s
    10 Mbps =    1.250 MB/s =       1250 KB/s
   100 Mbps =   12.500 MB/s =      12500 KB/s
  1000 Mbps =  125.000 MB/s =     125000 KB/s
 10000 Mbps = 1250.000 MB/s =    1250000 KB/s

理論上の転送時間（オーバーヘッド無視）    1Mbps     10Mbps   100Mbps   1Gbps
135KB(今回のbig.txt)                    1.1秒     0.1秒    0.0秒    0.0秒
5MB(写真1枚)                            40.0秒    4.0秒    0.4秒    0.0秒
100MB                                   13.3分    80.0秒   8.0秒    0.8秒
1GB(動画)                               133.3分   13.3分   80.0秒   8.0秒
50GB(ゲーム)                            6,666.7分 666.7分  66.7分   6.7分

手元で 135,091 バイトのファイルを取った時間は、1Mbps で 1.10 秒、10Mbps で 0.110 秒、100Mbps で 0.011 秒でした。理論値の 1.08 秒・0.108 秒・0.0108 秒とほぼ一致します。「大きさ ÷ 速さ」の見積もりは、混んでいない回線ではそのまま当たります。

帯域・速度・遅延（レイテンシ）とトラフィックの違い

この節では、似た言葉である帯域・通信速度・遅延と、トラフィックの関係が分かります。

帯域は「道路の幅（上限）」、トラフィックは「実際に走った車の量」、遅延は「1台が端から端まで着くまでの時間」です。 JPNIC の解説も、通信速度は「利用可能な上限や目安」、トラフィックは「実際に流れている量」と区別しています。

もう1つ区別したいのが「瞬間」と「合計」です。回線が詰まるかどうかは瞬間の最大（ピーク）で決まり、料金は月の合計で決まります。月に 300GB 流れても、平らにならせば平均 0.9Mbps にしかなりませんが、夜の 1 時間に集中すれば、その間は 100Mbps の回線でも足りなくなります。トラフィックの話をするときは、bps（瞬間の速さ）なのか、バイト（合計）なのかを先に決めます。

遅延の意味・目安・測り方は、関連記事「レイテンシとは｜意味・目安・測り方を遅延0〜300msの実測で解説」で扱っています。この記事では「トラフィックが増えると遅延がどう変わるか」だけを後の節で計ります。

ip -s link と ss で通信量を見る（Linux）

この節では、Linux で「このマシンがどれだけ通信したか」を、追加のソフトなしで確かめる方法が分かります。

ip -s link はインターフェイスごとの累計、ss -i は接続（ソケット）ごとの通信量を出します。 まず ping を4回打った直後の ip -s link です。

$ ip netns exec t108-a ping -c 4 10.108.0.2
64 bytes from 10.108.0.2: icmp_seq=1 ttl=64 time=0.051 ms
...
4 packets transmitted, 4 received, 0% packet loss, time 3076ms

$ ip -n t108-a -s link show t108-va
6: t108-va@if5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether ee:72:71:11:2d:1b brd ff:ff:ff:ff:ff:ff link-netns t108-b
    RX:  bytes packets errors dropped  missed   mcast
           434       5      0       0       0       0
    TX:  bytes packets errors dropped carrier collsns
           434       5      0       0       0       0

ping を4回打つと 5 パケット・434 バイトになりました。ping 1回は 98 バイト（ICMP 64＋IP 20＋Ethernet 14）で 4 回分が 392 バイト、残りの 42 バイトは最初に相手の MAC アドレスを探した ARP の 1 パケットです。「何もしていないのに流れる分」は、こうした手続きの通信です。

同じ数字は /proc/net/dev と /sys/class/net/<名前>/statistics/ にもあり、監視ツールの多くはここを読んでいます。

$ ip netns exec t108-a cat /proc/net/dev
Inter-|   Receive                                                |  Transmit
 face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
    lo:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0
t108-va: 6435092   94919    0    0    0     0          0         0 8425238820  158977    0    0    0     0       0          0

この時点の TX は 8,425,238,820 バイト（約 8.4GB）です。直前に上限なしで iperf3 を 5 秒流したためで、仮想の線はメモリのコピー速度で流れるので 13.4Gbps が出ました。本物の回線ではこの値は出ません。

接続ごとの量は ss -ti で見ます。50Mbps で送っている最中の1行です。

$ ip netns exec t108-a ss -tin 'dport = :5201'
State Recv-Q Send-Q Local Address:Port  Peer Address:Port
ESTAB 0      0         10.108.0.1:47750   10.108.0.2:5201
	 bbr wscale:10,10 rto:204 rtt:0.135/0.01 mss:1448 pmtu:1500 ... cwnd:193 bytes_sent:15728677 bytes_acked:15728678 segs_out:10923 segs_in:449 data_segs_out:10921 ... pacing_rate 31711441128bps delivery_rate 11096252624bps delivered:10922 app_limited busy:104ms ... minrtt:0.004

ip・ss・nc を使った切り分けの手順は、関連記事「Linuxネットワークコマンド一覧｜ip/ss/ncで障害切り分け」で扱っています。

tcpdump でトラフィックの中身を見る（10 パケットの原文）

この節では、「トラフィック」と呼んでいるものが、1 個ずつ見るとどんなパケットなのかが分かります。

nginx から 32 バイトの HTML を1回取ると、次の 10 パケットが流れました。 -t で時刻を省き、-nn で名前解決を止めています。

$ ip netns exec t108-a tcpdump -t -i t108-va -nn -c 10 'tcp port 8081'
IP 10.108.0.1.47074 > 10.108.0.2.8081: Flags [S], seq 1144050523, win 64240, options [mss 1460,sackOK,TS val 2264064920 ecr 0,nop,wscale 10], length 0
IP 10.108.0.2.8081 > 10.108.0.1.47074: Flags [S.], seq 1317705956, ack 1144050524, win 65160, options [mss 1460,sackOK,TS val 812993202 ecr 2264064920,nop,wscale 10], length 0
IP 10.108.0.1.47074 > 10.108.0.2.8081: Flags [.], ack 1, win 63, options [nop,nop,TS val 2264064920 ecr 812993202], length 0
IP 10.108.0.1.47074 > 10.108.0.2.8081: Flags [P.], seq 1:89, ack 1, win 63, options [nop,nop,TS val 2264064920 ecr 812993202], length 88
IP 10.108.0.2.8081 > 10.108.0.1.47074: Flags [.], ack 89, win 64, options [nop,nop,TS val 812993202 ecr 2264064920], length 0
IP 10.108.0.2.8081 > 10.108.0.1.47074: Flags [P.], seq 1:278, ack 89, win 64, options [nop,nop,TS val 812993203 ecr 2264064920], length 277
IP 10.108.0.1.47074 > 10.108.0.2.8081: Flags [.], ack 278, win 63, options [nop,nop,TS val 2264064921 ecr 812993203], length 0
IP 10.108.0.1.47074 > 10.108.0.2.8081: Flags [F.], seq 89, ack 278, win 63, options [nop,nop,TS val 2264064921 ecr 812993203], length 0
IP 10.108.0.2.8081 > 10.108.0.1.47074: Flags [F.], seq 278, ack 90, win 64, options [nop,nop,TS val 812993203 ecr 2264064921], length 0
IP 10.108.0.1.47074 > 10.108.0.2.8081: Flags [.], ack 279, win 63, options [nop,nop,TS val 2264064921 ecr 812993203], length 0
10 packets captured

データ（length が 0 でない）を運んだのは 10 個のうち 2 個だけです。-e を付けると Ethernet のフレーム長が出て、中身 0 バイトの SYN でも length 74、ACK で length 66 あることが分かります。これがヘッダーの分です。

$ tcpdump -t -e -i t108-va -nn -c 3 'tcp port 8081'
ee:72:71:11:2d:1b > 42:fe:13:b4:91:31, ethertype IPv4 (0x0800), length 74: 10.108.0.1.47080 > 10.108.0.2.8081: Flags [S], ...
42:fe:13:b4:91:31 > ee:72:71:11:2d:1b, ethertype IPv4 (0x0800), length 74: 10.108.0.2.8081 > 10.108.0.1.47080: Flags [S.], ...
ee:72:71:11:2d:1b > 42:fe:13:b4:91:31, ethertype IPv4 (0x0800), length 66: 10.108.0.1.47080 > 10.108.0.2.8081: Flags [.], ...

本物の環境では流れるパケットが多すぎて目で追えないので、host 10.108.0.2・port 8081 のように相手やポートで絞り、-c で個数を区切ります。-w ファイル名 で保存しておけば、あとから Wireshark で開けます。tcpdump は「量」を数える道具ではなく、「どの通信が流れているか」を確かめる道具として使います。

135KB のファイルを取ったときは、tcp 1448 のパケットが 98 個続きました。パケットを画面で追いたいときは、関連記事「Wiresharkの使い方｜画面の見方・フィルター早見表を実例で解説」で扱っています。

nload・iftop で「今の」トラフィックを見る

この節では、累計ではなく「今この瞬間に何 Mbps 流れているか」を見る道具と、表示の読み方が分かります。

nload はインターフェイス全体の今の速さを、iftop は「誰と誰の間で」いくら流れているかを出します。 どちらも Ubuntu のパッケージを作業場所に展開して使い、iperf3 で 50Mbps を流しながら見ました。

nload の画面（送信側の部分。文字だけ抜き出しています）です。Curr が今の速さ、Ttl が合計です。

$ nload -t 1000 t108-va
Outgoing:
##
##
##  Curr: 49.07 MBit/s
##  Avg: 49.58 MBit/s
##  Min: 49.07 MBit/s
##  Max: 50.09 MBit/s
##  Ttl: 7.94 GByte

iftop は -t で文字だけの出力にできます。既定はビット表示で、-B を付けるとバイト表示になります。同じ 50Mbps の転送が、片方は 37.2Mb、もう片方は 6.22MB と見えます。

$ iftop -t -s 2 -i t108-va -n          # ビット表示（既定）
   1 10.108.0.1        =>     37.2Mb     37.2Mb     37.2Mb     9.31MB
Total send rate:                37.2Mb     37.2Mb     37.2Mb

$ iftop -t -s 4 -i t108-va -n -B       # バイト表示
   # Host name (port/service if enabled)   last 2s   last 10s   last 40s cumulative
   1 10.108.0.1                     =>     6.22MB     5.70MB     5.70MB     22.8MB
     10.108.0.2                     <=     4.14KB     4.02KB     4.02KB     16.1KB
Total send rate:                           6.22MB     5.70MB     5.70MB
Total receive rate:                        4.14KB     4.02KB     4.02KB

iftop は -f 'port 80' のように BPF のフィルターで通信を絞れるので、「Web の通信だけ」「特定の相手だけ」の量も見られます。nload は -u m で MBit/s、-u M で MByte/s に単位を固定でき、小文字と大文字の違いがそのまま bit と Byte の違いです。どの道具も、表示の単位を確かめてから数字を読みます。

送信 6.22MB/s に対して受信は 4.14KB/s です。一方向にデータを流しているとき、反対方向にも確認応答（ACK）が流れ、その量はおよそ 1/1500 でした。「ダウンロードしかしていないのにアップロードも増える」のはこのためです。

トラフィックが多いときに起きること｜キューとドロップの実測

この節では、回線の上限を超えてデータを流すと、遅延が増え、最後には捨てられる様子が数字で分かります。

10Mbps の線に 20Mbps を流すと、半分（4,349 / 8,631 個）が捨てられました。TCP では捨てられた分を送り直すので、代わりに遅延が 0.03ms から 10ms に増えました。 送信側の netns で tc の tbf（トークンバケット）を使い、線の上限を 10Mbit、ためておける量を 100ms 分に設定しました。

$ ip netns exec t108-a tc qdisc add dev t108-va root tbf rate 10mbit burst 32kbit latency 100ms

まず TCP（iperf3 の既定）で 6 秒流した結果です。送信側は 10.7Mbits/sec を送ろうとし、受信側に届いたのは 9.42Mbits/sec、再送（Retr）が 632 回ありました。

$ ip netns exec t108-a iperf3 -c 10.108.0.2 -t 6
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  1.50 MBytes  12.6 Mbits/sec  577   14.1 KBytes
[  5]   1.00-2.00   sec  1.62 MBytes  13.6 Mbits/sec   55   14.1 KBytes
[  5]   2.00-3.00   sec  1.00 MBytes  8.38 Mbits/sec    0   14.1 KBytes
[  5]   3.00-4.00   sec  1.12 MBytes  9.44 Mbits/sec    0   14.1 KBytes
[  5]   4.00-5.00   sec  1.25 MBytes  10.5 Mbits/sec    0   14.1 KBytes
[  5]   5.00-6.00   sec  1.12 MBytes  9.43 Mbits/sec    0   14.1 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[  5]   0.00-6.00   sec  7.62 MBytes  10.7 Mbits/sec  632             sender
[  5]   0.00-6.01   sec  6.75 MBytes  9.42 Mbits/sec                  receiver

最初の 2 秒は上限を超えて送り、577 回・55 回と再送が出ています。3 秒目以降は TCP が速さを 10Mbps 付近に合わせ、再送が 0 になりました。これが TCP の「混雑制御」で、トラフィックが多いときに自動で速さを落とす仕組みです。

その間、同じ線で ping を打つと、往復時間が増えました。空いているときの 0.029ms が、混んでいる間は平均 10.34ms です。

空いているとき: rtt min/avg/max/mdev = 0.021/0.029/0.035/0.005 ms
混んでいるとき: rtt min/avg/max/mdev = 7.589/10.340/13.550/1.562 ms

遅れた理由は、ping のパケットが「キュー（待ち行列）」で順番を待ったからです。転送の途中で tc -s qdisc を見ると、キューに 10 パケット・15,140 バイトがたまっていました。10Mbps では 15,140 バイトを出すのに約 12ms かかるので、後ろに並んだ ping もそれだけ待ちます。

$ ip netns exec t108-a tc -s qdisc show dev t108-va      # 転送の途中
qdisc tbf 8007: root refcnt 3 rate 10Mbit burst 4Kb lat 100ms
 Sent 2502137 bytes 1664 pkt (dropped 1135, overlimits 4357 requeues 0)
 backlog 15140b 10p requeues 0

$ ip netns exec t108-a tc -s qdisc show dev t108-va      # 6 秒の TCP 転送のあと
qdisc tbf 8003: root refcnt 3 rate 10Mbit burst 4Kb lat 100ms
 Sent 7522304 bytes 4995 pkt (dropped 1010, overlimits 11557 requeues 0)
 backlog 0b 0p requeues 0

UDP（送り直しをしない）で、上限の 2 倍の 20Mbps を 5 秒流すと、捨てられた分がそのまま損失として見えます。

$ ip netns exec t108-a iperf3 -c 10.108.0.2 -u -b 20M -t 5
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-5.00   sec  11.9 MBytes  20.0 Mbits/sec  0.000 ms  0/8631 (0%)  sender
[  5]   0.00-5.10   sec  5.91 MBytes  9.72 Mbits/sec  0.336 ms  4349/8631 (50%)  receiver

送った 8,631 個のうち 4,349 個（50%）が届きませんでした。動画や音声の通話が「途切れる」のは、この捨てられた分です。TCP のダウンロードは送り直しで中身は欠けませんが、その分だけ遅くなります。TIME_WAIT や 40ms の遅延など TCP 側の挙動は、関連記事「TCPの落とし穴8選｜TIME_WAIT・40ms遅延の正体」で扱っています。

Web サイトのトラフィック＝訪問数｜アクセスログから数える

この節では、「サイトのトラフィック」を解析ツールなしで、サーバーのアクセスログから数える手順が分かります。

アクセスログは 1 リクエスト 1 行です。行数がページビュー（PV）、IP アドレスの種類が訪問者数の目安になります。 手元の nginx に、10 個の IP アドレスから 53 回のアクセス（1 つはクローラーを名乗る User-Agent）を送り、残ったログを集計しました。1 行は次の形（combined 形式）です。

10.108.0.17 - - [30/Oct/2026:19:51:18 +0900] "GET /big.txt HTTP/1.1" 200 135091 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36"
10.108.0.20 - - [30/Oct/2026:19:51:18 +0900] "GET /index.html HTTP/1.1" 200 32 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

$ awk '{print $7}' access.log | sort | uniq -c | sort -rn
     10 /index.html
     10 /about.html
      8 /notfound
      7 /missing.png
      7 /blog/post-1.html
      6 /blog/post-2.html
      6 /big.txt
$ awk '{print $9}' access.log | sort | uniq -c
     39 200
     15 404
$ awk -F'"' '{print $4}' access.log | sort | uniq -c | sort -rn
     51 -
      2 https://www.google.com/
      1 https://t.co/abc
$ grep -c Googlebot access.log; grep -c iPhone access.log; grep -c "Windows NT" access.log
12
7
34

IP アドレスで訪問者を数える方法には限界があります。会社や学校では多くの人が 1 つの IP に見え、スマホの回線では同じ人の IP が途中で変わります。同じ人が PC とスマホで見れば 2 人に数えます。目安として使い、正確な人数が要るときは GA4 のような計測タグの仕組みを使います。逆に、ログは計測タグが動かない相手（クローラー・画像の直接取得・API）も残すので、「サーバーに実際に来た全部」を知りたいときはログの方が向いています。

参照元（4 つ目の " " の中）を数えると、検索から 2 回、X（t.co）から 1 回、残りは参照元なし（ブックマークや直接入力）でした。これが GA4 の「チャネル」の元になる情報です。awk の集計の書き方は、関連記事「awkコマンドの使い方｜実例50と集計・ログ解析、gawkとmawkの違い」で扱っています。

GA4 のトラフィックと「トラフィックを増やす」の意味

この節では、Google アナリティクス（GA4）で「トラフィック」がどう分類されているかと、「増やす」が何を指すのかが分かります。

GA4 の「トラフィック獲得」は、セッション（訪問）をどこから来たかで分類したレポートです。 分類の名前は「デフォルト チャネル グループ」と呼ばれ、Google アナリティクスのヘルプは参照元とメディアの組み合わせで判定する、と説明しています。主なチャネルは次のとおりです（判定の細かな条件はヘルプの表が元になります）。

ヘルプには、このほか Organic Video・Paid Social・SMS・AI Assistant など全部で 19 のチャネルが載っています。アクセスログとの違いは、GA4 はブラウザで動く計測タグが送った情報を「セッション」や「ユーザー」の単位にまとめる点で、クローラーや計測タグが動かない環境の訪問は数に入りません。ログの PV と GA4 のセッション数が合わないのはこのためです。

「トラフィックを増やす」は、これらのチャネルから来る訪問を増やすことです。 検索（記事を書く・ページを直す）、SNS（投稿する）、広告（買う）、参照（紹介される）のどれを伸ばすかで打ち手が変わります。広告の話で「トラフィック」と言うときは、このうち有料のチャネル（Paid Search・Paid Social・Display）から送り込む訪問を指しています。

トラフィックと料金｜転送量課金の考え方

この節では、クラウドやレンタルサーバーで「トラフィック」が料金にどう関わるのかが分かります。

クラウドの多くは「外へ送ったバイト数（データ転送アウト）」で課金します。 AWS の EC2 の料金ページは、2026年10月29日時点で「1 か月あたり 100GB のインターネットへのデータ転送（OUT）を無料」とし、それを超える分は転送量の階層ごとの単価で課金する、と説明しています（単価はリージョンごとに料金表で確かめます）。受信（IN）は多くの場合に課金されません。

レンタルサーバーや VPS では「月の転送量の目安」や「上限」が決まっていることが多く、超えると速度を制限される・追加の料金がかかる、といった扱いになります（条件は各サービスの約款で確かめます）。CDN も配信した量で課金するものが多く、どの場合も見るべき数字は「外へ送ったバイト数」です。

手元のアクセスログの 10 列目を足した 818,856 バイトが、この「外へ送った量」の元になる数字です。1 日 1 万 PV のサイトで 1 ページあたり 2MB（画像込み）を送ると、1 か月で約 600GB になります。

• 11 ページの転送量を知るブラウザの開発者ツールの Network タブの合計か、ログの 10 列目の平均
• 2PV × 1 ページの量 × 30 日で月の転送量を見積もる1 万 PV/日 × 2MB × 30 ＝ 約 600GB
• 3画像の圧縮・キャッシュ・CDN で「送る量」を減らす同じ PV でもネットワークのトラフィックは減らせる
• 4急な増え方は監視するクローラーや大きなファイルへの集中は、ログのステータスと UA で見つかる

よくあるつまずき（文言と原因）

この節では、トラフィックを調べるときに出る文言や勘違いと、その原因が分かります。

判断表｜何を見ればよいか

この節では、「トラフィックを調べたい」と思ったときに、どの数字をどの道具で見るかが決まります。

1. 1「サイトに何人来たか」 → アクセスログか GA4PV は行数、訪問者は IP かセッション。クローラーは除く
2. 2「どこから来たか」 → 参照元の列か GA4 のチャネル検索・SNS・広告・直接の割合
3. 3「今どれだけ流れているか」 → nload・iftop単位が b か B かを確かめる
4. 4「合計でどれだけ流れたか」 → ip -s link・ログの 10 列目料金の見積もりはこの数字から
5. 5「遅い・途切れる」 → ping と tc -s qdisc の dropped遅延が増えていれば混雑、dropped が増えていれば上限超え
6. 6「何の通信か分からない」 → tcpdump・Wireshark相手の IP・ポート・量を 1 パケットずつ

よくある質問

Q. トラフィックとは何ですか？ A. ネットワークを流れるデータ（とその量）のことです。Web サイトの話では「サイトへの訪問数」、広告の話では「広告から送り込む訪問」の意味で使います。元は「交通量」という意味の英語です。

Q. トラフィックの単位は何ですか？ A. ネットワークでは bps（1 秒あたりのビット数）とバイト（合計）です。Web では セッション数・ユーザー数・ページビュー（PV）で数えます。

Q. Mbps と MB/s の違いは？ A. Mbps は 1 秒あたりのメガビット、MB/s は 1 秒あたりのメガバイトです。1 バイト＝8 ビットなので、100Mbps ＝ 12.5MB/s です。回線の表示は小文字の b、ダウンロードの表示は大文字の B が多いです。

Q. トラフィックと帯域の違いは？ A. 帯域は流せる上限（道路の幅）、トラフィックは実際に流れた量（走った車の量）です。手元では帯域を 10Mbps に絞り、20Mbps のトラフィックを流すと半分が捨てられました。

Q. トラフィックが多いとなぜ遅くなるのですか？ A. 上限を超えた分がキュー（待ち行列）に並ぶからです。手元では往復 0.03ms が 10ms に増えました。キューがいっぱいになると捨てられ、TCP は送り直すので、さらに遅く見えます。

Q. Linux で通信量を確認する方法は？ A. ip -s link で累計、ss -ti で接続ごと、nload で今の速さ、iftop で相手ごとの速さ、tcpdump で 1 パケットずつの中身が見られます。

Q. Web サイトのトラフィックはどう数えますか？ A. アクセスログの行数が PV、IP アドレスの種類が訪問者の目安です。クローラー（User-Agent に bot を含む行）は除いて数えます。GA4 ではセッション数と、チャネル別の内訳が見られます。

Q. 「トラフィックを増やす」とはどういう意味ですか？ A. 検索・SNS・広告・他サイトからの紹介など、サイトへの訪問を増やすことです。GA4 のチャネルごとに打ち手が変わります。

Q. 広告で言う「トラフィック」は何ですか？ A. 広告をクリックしてサイトに来た訪問のことです。Web のトラフィックのうち、有料のチャネルから来た分を指します。

Q. トラフィックに料金はかかりますか？ A. クラウドでは「外へ送ったバイト数」で課金されることが多いです。AWS は 2026年10月29日時点で月 100GB まで無料、超えた分は階層ごとの単価です。受信は多くの場合に課金されません。

Q. ダウンロードしかしていないのにアップロードが増えるのはなぜ？ A. 受け取った側が「届いた」という確認応答（ACK）を返しているからです。手元では受信の約 1/1500 の量が反対方向に流れました。

Q. ネットワークのトラフィックを減らす方法は？ A. 画像の圧縮、ブラウザのキャッシュ、CDN で近い場所から配る、不要なクローラーのアクセスを断る、などです。同じ訪問数でも「送る量」は減らせます。

まとめ

• トラフィックは「流れの量」。ネットワークでは流れるデータ量（bps・バイト）、Web では訪問数（セッション・PV）、広告では広告から送る訪問を指す。
• bps を 8 で割ると B/s。100Mbps ＝ 12.5MB/s。手元の 135KB の取得は 1Mbps で 1.10 秒、100Mbps で 0.011 秒と、理論値どおりだった。
• 32 バイトの HTML を 1 回取るのに 10 パケット・1,041 バイトが流れた。接続の手続きと確認応答もトラフィックに含まれる。
• 10Mbps の線に上限を超えて流すと、キューにたまって往復 0.03ms が 10ms になり、あふれた 1,010 パケットが捨てられた。UDP で 20Mbps を流すと 50% が届かなかった。
• Web のトラフィックはアクセスログの行数（PV）と IP の種類で数えられる。クローラーを除き、参照元の列を見ると GA4 のチャネルに近い内訳が出る。送ったバイト数の合計が転送量課金の元になる。

参考・出典

確認日はいずれも 2026年10月29日です。

• JPNIC「インターネット用語1分解説～トラフィックとは～」：https://www.nic.ad.jp/ja/basics/terms/traffic.html
• Google アナリティクス ヘルプ「[GA4] デフォルト チャネル グループ」：https://support.google.com/analytics/answer/9756891?hl=ja
• AWS「Amazon EC2 オンデマンド料金」（データ転送）：https://aws.amazon.com/jp/ec2/pricing/on-demand/
• man7.org「ip-link(8)」：https://man7.org/linux/man-pages/man8/ip-link.8.html
• man7.org「ss(8)」：https://man7.org/linux/man-pages/man8/ss.8.html
• man7.org「tc-tbf(8)」：https://man7.org/linux/man-pages/man8/tc-tbf.8.html
• tcpdump「Manpage of TCPDUMP」：https://www.tcpdump.org/manpages/tcpdump.1.html
• ESnet「iperf3」：https://software.es.net/iperf/
• nginx「Module ngx_http_log_module」：https://nginx.org/en/docs/http/ngx_http_log_module.html

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。