【実務・中級編】 PoE（Power over Ethernet / IEEE 802.3af）の給電制御と最大供給電力 – インフラ・物理＆L2/L3ネットワーク基礎実践ガイド

現場のエンジニアが知っておくべき「PoE」の深淵：802.3afの給電ロジックとトラブル回避術

こんにちは。ネットワークの深淵を覗き込み、時にはパケットの叫び声に耳を傾けてきたインフラエンジニアです。

皆さんは普段、Web APIのレスポンスタイムやスケーラビリティに頭を悩ませているかもしれません。しかし、そのAPIを叩くための「物理的な土台」が揺らいでいたらどうでしょう？監視カメラ、無線AP、あるいはIP電話。これらを動かすIEEE 802.3af（PoE）の挙動を知っておくことは、現場での「原因不明の再起動」という悪夢を回避するための必須スキルです。

今回は、PoEの原点である802.3afを紐解き、単なる「ケーブルから電気が流れる」という理解を超えた、その繊細な制御の世界へご案内します。

—

PoE（802.3af）の給電ロジック：物理層のハンドシェイク

多くの人が誤解していますが、PoEはスイッチのポートにLANケーブルを挿した瞬間、無差別に48Vを流しているわけではありません。もしそんなことをすれば、PoE非対応のPCを繋いだ瞬間にNICが昇天してしまいます。

PoEの制御は、大きく分けて「検出(Detection)」と「分類(Classification)」の2段階で行われます。

1. 検出 (Detection)：相手は「食べる準備」ができているか？

PSE（Power Sourcing Equipment：スイッチ側）は、まずポートに微小な電圧（2.7V〜10.1V）をかけ、抵抗値を測定します。PoE対応デバイス（PD：Powered Device）は、規定のシグネチャ抵抗（25kΩ）を内部に持っています。この抵抗値を検知して初めて、スイッチは「あ、こいつは電気を欲しがっているやつだ」と認識します。

2. 分類 (Classification)：どれだけ腹が減っているか？

次にスイッチは、より高い電圧をかけてPDから「クラス情報」を引き出します。802.3afではクラス0〜3が定義されており、最大供給電力が決まります。

| クラス | PDの消費電力(W) | PSEの供給電力(W) |
| :— | :— | :— |
| 0 | 0.44 – 12.95 | 15.4 |
| 1 | 0.44 – 3.84 | 4.0 |
| 2 | 3.84 – 6.49 | 7.0 |
| 3 | 6.49 – 12.95 | 15.4 |

ここで重要なのは、「スイッチ側が予約する電力は、実際の消費電力よりも多い」という点です。15.4Wという数字は、ケーブルの抵抗による損失（熱）を見越したPSE側の最大値です。

—

実践：スイッチのCLIからPoEの状態を読み解く

現場で「APが頻繁に落ちる」という相談を受けた際、私が最初に見るのがこのステータスです。Cisco等のスイッチでの確認コマンドを例に挙げます。

# 現在のPoE供給状況を確認するコマンド
show power inline

# 出力例（解釈のポイント）
# Interface  Admin  Oper       Power   Device              Class
# Gi0/1      auto   on         12.95W  IP-Phone-8841       3

この出力で注目すべきは Oper が on になっているか、そして Power が上限ギリギリになっていないかです。もし Power が15.4W付近でフラついていたら、ケーブル長が長すぎることによる電圧降下や、あるいはスイッチ全体の電力バジェット（PoE供給能力の合計）が枯渇しているサインかもしれません。

—

運用エンジニアのためのトラブルシューティング Tips

もし皆さんがPythonでPoE対応機器の状態を管理するツールを作るとしたら、SNMPを活用するのが定石です。以下は、pysnmp を使ってPoEの状態を取得するイメージです。

from pysnmp.hlapi import *

# PoEのMIB (ENTITY-POE-MIB) から供給電力を取得する簡易ロジック
def get_poe_power(target_ip, interface_index):
    # OIDはメーカーのMIBリファレンスを参照すること
    oid = f'1.3.6.1.2.1.105.1.1.1.3.{interface_index}' 
    
    # SNMP GETの実行
    iterator = getCmd(SnmpEngine(),
                      CommunityData('public'),
                      UdpTransportTarget((target_ip, 161)),
                      ContextData(),
                      ObjectType(ObjectIdentity(oid)))
    
    # 実際にはここで値を取り出し、mW単位をWに変換して処理する
    # ...
    print(f"Interface {interface_index} is consuming power.")

# 実務では、この数値をPrometheus等に送り、グラフ化して可視化するのがベストプラクティスです。

現場の泥臭い教訓：

「最大電力の罠」: PDが仕様書で「12W」と言っていても、起動時の突入電流（Inrush Current）で一瞬だけ15.4Wを超え、スイッチ側が過電流保護でポートを遮断することがあります。特に冬場の起動時など、電気特性が変化する環境では顕著です。
「ケーブル品質」: 安価なLANケーブル（特に芯線が細いCCAケーブル）は抵抗が高く、電圧降下によりPDが正常動作しません。PoEを使うなら、必ずしっかりとした銅線（Solid Copper）のCat5e/Cat6ケーブルを選びましょう。

—

最後に：ネットワークは「電気」の積み重ねである

APIを叩くコードがどれほど洗練されていても、その下の物理層が電気的に不安定であれば、すべては砂上の楼閣です。PoEはまさに、物理的な「電気」と論理的な「データ」が交差する、インフラエンジニアの醍醐味が詰まった領域です。

もし現場で不可解なリンクダウンに遭遇したら、設定ファイルだけでなく、まずは show power inline を叩いてみてください。パケットの向こう側で、電気が足りずに震えているデバイスがいるかもしれませんよ。

それでは、また次回の深淵でお会いしましょう。ハッピー・ネットワーキング！