【実務・中級編】イーサネットフレームのFCS(Frame Check Sequence)によるエラー検出 – ネットワーク基礎とWebセキュリティ実践ガイド

パケットはなぜ信じられるのか？――FCS（フレームチェックシーケンス）とCRCが物理層のノイズからWebを守る仕組み

インフラの構築やWeb APIの設計において、私たちは日々、JSONのペイロードやHTTPヘッダー、そしてTLSの暗号化のレイヤーに気を奪われがちだ。しかし、どれほど洗練されたREST APIを設計しようとも、その土台を支える物理的なネットワークケーブルや無線空間で「ビット化け」が起きれば、すべては水泡に帰す。

「いやいや、上位レイヤーにはTCPのチェックサムがあるし、TLSだってメッセージ認証コード（MAC）があるから大丈夫だろう」

そう思ったそこのあなた。甘い。現場で数々の不可解なパケットロスや通信断に立ち向かってきたエンジニアなら知っているはずだ。OSI参照モデルの最下層、すなわち物理層とデータリンク層の境界で起きている泥臭い現実を無視して、堅牢なシステムは作れない。

今回は、イーサネットフレームの末尾にひっそりとしがみついている、だが絶対に欠かすことのできない4バイトの守護神、FCS（Frame Check Sequence）と、その裏でうごめくCRC（巡回冗長検査）の数学的・実務的な挙動について、現場の視点から徹底的に解き明かしていこう。

—

1. イーサネットフレームの構造とFCSの立ち位置

まずは、私たちが普段何気なく流しているパケットが、ワイヤ上でどのような姿をしているかを確認する。OSI参照モデルの第2層（データリンク層）において、データは「イーサネットフレーム」というカプセルに包まれて送り出される。

一般的なIEEE 802.3イーサネットフレームの構造は、おおむね以下のようになっている。

+-------------------+-------------------+-------------------+-------------------+--------------------+
| プリアンブル/SFD  | 宛先MACアドレス   | 送信元MACアドレス | タイプ (EtherType)| ペイロード (データ)  |
| (8 バイト)         | (6 バイト)         | (6 バイト)         | (2 バイト)         | (46 ～ 1500 バイト) |
+-------------------+-------------------+-------------------+-------------------+--------------------+
                                                                                | FCS (4 バイト)     |
                                                                                +--------------------+

このフレームの一番最後（末尾）に陣取っている4バイト（32ビット）こそが、今回の主役である FCS だ。
送信側のネットワークインターフェースカード（NIC）は、フレーム内の特定の領域（宛先MACアドレスからペイロードの末尾まで）を対象に数学的な演算を行い、その結果得られた32ビットの値を「チェック値」としてフレームの末尾にねじ込む。受信側のNICは、受け取ったフレームに対して全く同じ演算を行い、末尾のFCSの値と突き合わせる。

もし、この2つの値が一致しなければ……？その瞬間、そのフレームは「汚染されたゴミ」とみなされ、容赦なくパージ（破棄）される運命にある。

—

2. CRC（巡回冗長検査）の裏側：なぜ「単なる足し算」ではダメなのか？

「チェックサム」という言葉を聞くと、単にデータのバイトをすべて足し合わせる（チェックサム方式）を想像するかもしれない。しかし、ネットワークの世界はそんなに甘くない。

通信経由で起きるエラーは、1ビットだけが反転する「単一ビットエラー」だけとは限らない。ノイズの影響で、連続した複数のビットが同時に化ける「バーストエラー」が日常茶飯事として発生する。単純な加算方式では、例えば「あるバイトが1増え、別のバイトが1減った」というような相殺エラーを見逃してしまう。

そこで登場するのが、多項式除算をベースにした CRC（Cyclic Redundancy Check：巡回冗長検査） だ。

数学的背景（ざっくりとしたイメージ）

CRCでは、データ列を係数が0か1しかない巨大な多項式とみなす。そして、送信側であらかじめ決められた「生成多項式（IEEE 802.3のイーサネットでは Ethernet FCS や CRC-32 と呼ばれる標準的なものが使われる）」でその多項式を割り算し、その余りをFCSとして付与する。

受信側は、受信したデータ全体（FCSを含む）を同じ生成多項式で割る。もし割り切れる（余りが特定のビットパターンになる）ならば、エラーなしと判定する。

このCRC-32のアルゴリズムは、以下のような特性を持っているため、ハードウェア（NICのASICやFPGA）での高速処理に非常に適している。

1ビットおよび2ビットの独立したエラーを100%検出できる。
奇数個のビットエラーを100%検出できる。
長さが生成多項式の次数以下のバーストエラーを100%検出できる。
それ以上の長いバーストエラーであっても、ほぼ 1 – (1 / $2^{32}$) （約99.9999999%）という驚異的な確率で検知できる。

—

3. エラー発生時の挙動：パケットはどこで消えるのか？

では、実際に伝送路（UTPケーブルや光ファイバー）の途中でノイズが乗り、ビット化けが発生した瞬間のパケットの運命を追ってみよう。

[送信端末] ---> ( 物理ノイズ発生！ビット化け ) ---> [スイッチ/ルーターの受信ポート]
                                                           |
                                                   [NIC内部のASICがCRC計算]
                                                           |
                                                   ( 計算結果が一致しない！ )
                                                           |
                                                   [ジャイアント/Runt/FCSエラーカウンタ加算]
                                                           |
                                                   [フレーム即座に破棄 (Drop)]

ここで非常に重要な事実がある。FCSエラーで破棄されたフレームは、上位レイヤー（IPやTCP/UDP）には一切到達しない。

インフラ運用の現場で、よく勘違いしているジュニアエンジニアに出会う。
「TCPのチェックサムがあるんだから、物理層のエラーもTCPが再送制御してくれるんでしょ？」と。

確かに、TCPは信頼性の高いプロトコルであり、データが届かなければ再送を行う。しかし、FCSエラーで弾かれたフレームは、OSのネットワークスタックから見れば「最初から存在しなかったもの」と同じだ。OSのパケットキャプチャツール（tcpdump や Wiresharkなど）をOS側で起動していても、NICのハードウェアレベルでドロップされたFCSエラーフレームは、多くの場合、通常のパケットキャプチャには映らない。

これが、ハードウェア障害やケーブルの劣化を切り分ける際の罠となる。OSのログには「通信が遅い」「タイムアウトする」としか出ないのに、スイッチのポート統計（CiscoのIOSであれば show interfaces など）を見ると、CRC Errors や Input Errors のカウンターが刻々と増加している……という現場の光景は、ネットワークエンジニアにとってはおなじみの悪夢だ。

—

4. 実務でのトラブルシューティング：CRC/FCSエラーを見つけたらどう動くか？

もし、あなたが運用の現場で「特定のセグメントで通信が不安定だ」「Web APIへのリクエストが時々ロストする」というインシデントに直面したとき、どのようにFCS/CRCの観点からアプローチすべきか。実務的なステップを共有しよう。

ステップ1: ネットワーク機器のインターフェース統計を確認する

OS上のログだけに頼らず、L2スイッチやルーター、ロードバランサーの物理ポートのカウンタを叩け。

# Cisco IOS系スイッチの例：インターフェースのエラー統計を確認する
# 注目すべきは CRC, Input Error, Frame の各カウンタだ。
Switch# show interfaces GigabitEthernet 0/1
GigabitEthernet0/1 is up, line protocol is up (connected)
  Hardware is BCM5600, address is 0011.2233.4455
  ...
  5 minute input rate 124500 bits/sec, 142 packets/sec
  5 minute output rate 89200 bits/sec, 98 packets/sec
     12845097 packets input, 1823904800 bytes, 0 no buffer
     Received 0 broadcasts, 0 multicasts, 0 runts, 0 giants
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

もしここで CRC カウンタや Input errors が秒単位でモリモリ増えているなら、それは上位のWebアプリケーションのバグでもAPIの設計ミスでもない。100%ハードウェア・物理層のトラブルだ。

ステップ2: 物理レイヤーの総点検

FCSエラーの主な原因は、ソフトウェアの不具合ではなく、以下のような物理的な要因に起因する。
1. UTPケーブルの劣化・規格違反: カテゴリ5eのケーブルに無理な曲げ荷重がかかっていたり、長距離（100m超）を引き回していたりする場合。
2. 電磁干渉（EMI）: 強い磁界を発生させるモーターや高圧電力線の近くにLANケーブルが平行して敷設されている場合。
3. コネクタの接触不良: RJ45コネクタの爪が折れていたり、端子に酸化皮膜やホコリがたまっている場合。
4. SFP/SFP+モジュールの不良・光ファイバーの汚れ: 光通信の場合、トランシーバーのレーザー出力低下や、光ファイバーのコア（端面）の汚れが原因で受光レベルが落ち、ビット化け（CRCエラー）を引き起こす。

—

5. コードや設定レベルでの意識：上位レイヤーは物理層を信用していない

さて、FCSとCRCが物理層でいかにパケットの完全性を担保しているかを見てきたが、最後にアプリケーションやWeb APIを設計するエンジニアへのメッセージとして、「防衛的プログラミング」の視点を添えておこう。

信頼性の低いネットワーク環境や、IoTデバイスなどが混在するエッジ環境において、Web APIを設計する際、私たちはトランスポート層（TCP）だけに依存せず、アプリケーション層でも整合性を検証する仕組みを取り入れることがある。

例えば、クライアントからサーバーへ巨大なバイナリデータや重要なペイロードをPOSTする際、HTTPヘッダーに独自のチェックサム（例えば Content-MD5 や X-Checksum-SHA256 など）を付与し、サーバー側でハッシュを再計算して検証する実装がこれに該当する。

以下に、Python（FastAPIやrequests）を用いた簡単な検証アプローチのイメージを示す。

import hashlib
from fastapi import FastAPI, Header, HTTPException, Request

app = FastAPI()


@app.post("/api/v1/upload")
async def upload_data(request: Request, x_sha256_checksum: str = Header(...)):
    """クライアントから送信されたデータの整合性を、

    TCP/IPの下位レイヤー（およびFCS）を越えてアプリケーション層で二重に担保する例。
    """
    body_bytes = await request.body()

    # サーバー側で受信したペイロードからSHA-256ハッシュを算出
    calculated_hash = hashlib.sha256(body_bytes).hexdigest()

    # クライアントが送ってきた期待値と比較
    if calculated_hash != x_sha256_checksum:
        # ネットワークのどこかで（あるいはメモリ上で）データが破損している可能性がある
        raise HTTPException(
            status_code=400,
            detail="Integrity check failed: Checksum mismatch.",
        )

    return {
        "status": "success",
        "message": "Data received and verified successfully.",
    }

このように、イーサネットフレームの末尾にあるたった4バイトのFCSが物理的なビット化けを防ぎ、その上をTCPが流れ、さらに必要に応じてアプリケーション層がハッシュで整合性を担保する――。
この多層防御（レイヤード・セキュリティ）の思想こそが、現代の巨大なインターネットインフラを支えている根幹なのだ。

—

まとめ

パケットの旅は、いつだって物理層の泥臭い電気信号や光の点滅から始まる。
次に「Web APIのレスポンスがおかしい」「パケットが時々消える」という不可解なトラブルに遭遇したときは、慌ててソースコードを開く前に、まず思い出してほしい。

フレームの末尾で静かに身を削りながらエラーを検知し続けている、あの小さな4バイトのFCSの存在を。ネットワークの基本原則を理解しているエンジニアこそが、真に信頼性の高いシステムを構築できるのだ。