Windows 11 Pro 24H2でPowerShellからNICチーミングを作ろうとして「LBFO feature is not currently enabled, or LBFO is not supported on this SKU」と出る場合、故障ではなく“OSのサポート範囲”に当たっている可能性が高いです。原因の切り分けと、LTSC 2024を含む現実的な代替策をまとめます。
症状：Windows 11 Pro 24H2 で NIC チーミングを作れずエラーになる
典型的には、4ポートの有線LAN（クアッドポートNIC）を搭載したPCで、管理者権限のPowerShellから次のようにチーム作成を試みると失敗します。
New-NetLbfoTeam -Name "Team1" -TeamMembers "Ethernet1","Ethernet2" -TeamingMode SwitchIndependent -LoadBalancingAlgorithm Dynamicそして、以下のような趣旨のエラーが表示されます。
LBFO feature is not currently enabled, or LBFO is not supported on this SKUこのエラーは「手順が間違っている」というより、LBFO（Microsoft純正のソフトウェアNICチーミング）がそのOSのSKUで提供されていない時に出やすいメッセージです。つまり、設定で有効化できる類ではなく“設計として外れている”ケースがほとんどです。
まず押さえる：NICチーミング／LBFO／LACPは別モノが混ざりやすい
「NICを束ねる」という話は似た単語が多く、原因の切り分けが難しくなります。ここで一度、整理しておくと判断が速くなります。
| 用語 | ざっくり説明 | 主な目的 | どこで設定するか |
|---|---|---|---|
| NICチーミング（LBFO） | 複数の物理NICをOS側で1つの論理NICとして扱う仕組み | 冗長化／負荷分散／（条件次第で）帯域向上 | Windows Server（NetLbfo） |
| LACP（802.3ad） | スイッチとホストが協調してリンクアグリゲーションを組む規格 | 帯域向上／冗長化 | スイッチ側＋ホスト側（LBFOやベンダーツール等が必要） |
| スイッチ・インディペンデント | スイッチ側の特別設定なしでチーミング（ただし挙動に制約） | 冗長化／一部の負荷分散 | チーミング機能側（LBFOなど） |
| ネットワークブリッジ | 2つのNICを“橋渡し”してL2でつなぐ（チーミングではない） | ネットワーク分岐・接続の都合 | Windows（ncpa.cpl） |
| SMB Multichannel | SMB通信が複数のNIC/経路を自動活用（チーミング不要の場合がある） | ファイル転送の高速化／耐障害性 | SMBクライアント／サーバー側（基本は自動） |
ポイントは、スイッチにLACPを入れただけではWindows側に“束ねる機能”が無いと成立しないこと、そしてネットワークブリッジはLBFOの代わりにならないことです。
結論：Windows 11（Pro / Enterprise / LTSC 2024 などクライアントSKU）ではLBFOはサポートされない
Microsoftの公式ドキュメント（NetLbfoモジュールの説明）では、NIC Teaming（LBFO）はWindows Server 2012以降のサーバーOSのみで利用可能で、Windows 10やその他のクライアントOSでは利用できない旨が明記されています。
つまり、Windows 11 Pro 24H2はクライアントOSのため、OS標準のソフトウェアNICチーミング（LBFO / NetLbfo）をローカルで作成することはできません。その結果、PowerShellで作ろうとすると「このSKUではLBFOがサポートされない」といったエラーになります。
ここで混乱しやすいのが、NetLbfoのPowerShellコマンド自体はクライアントOSにも存在し得る点です。ドキュメントには、クライアントOS上のNIC Teamingコマンドは「Windows Server上のNICチームをリモート管理するため」に利用できる、といった趣旨も記載されています。つまり“ローカルで作成できる”とは別の話です。
| 項目 | Windows 11（クライアント） | Windows Server（サーバー） |
|---|---|---|
| LBFO（NetLbfo）でチームを作る | 不可（SKU非対応） | 可 |
| LBFOの管理GUI（NIC Teaming） | 基本的に無し | あり（Server Manager等） |
| PowerShellコマンドの存在 | 環境により見えることはある（リモート管理用途など） | 当然あり |
| 「LBFO is not supported on this SKU」 | 出やすい | 通常は出ない（別要因が無ければ） |
Windows 11 LTSC 2024 でも同じ扱い
「LTSCならサーバー寄りで使えるのでは？」と期待されがちですが、Windows 11 Enterprise LTSC 2024 / Windows 11 IoT Enterprise LTSC 2024 はあくまでWindows 11のクライアント系SKUです。LTSCは“サポート期間や更新方針”の話であり、サーバーOSに変わるわけではありません。
実際、Windows 11 Pro 24H2でLBFOが通らない件に対して、Microsoft Q&Aでも「NIC TeamingはWindows Serverのみ」「Windows 11 LTSC 2024はサーバーSKUではない」という趣旨で案内されています。
結論として、Windows 11 LTSC 2024でもLBFO（NetLbfo）によるソフトウェアNICチーミングは原則使えません。LTSCを選んでも、この点は解決しない可能性が高いです。
「仕様で不可」を最短で確認する：3つのチェック
「サポート外なのは分かった。でも自分の環境で確かめたい」という方向けに、現場で使える確認パターンをまとめます。
OSのエディションとSKUを確認する
まずは“クライアントOSかサーバーOSか”を確定させます。
(Get-CimInstance Win32_OperatingSystem).Caption
(Get-ComputerInfo).WindowsProductName表示に「Windows 11 Pro」「Windows 11 Enterprise」「Windows 11 IoT Enterprise LTSC」などが出るなら、クライアントSKUです。LBFOは原則対象外になります。
NetLbfoモジュール／コマンドが“ローカル用途”として成立しているかを確認する
Get-Module -ListAvailable NetLbfo
Get-Command -Name New-NetLbfoTeam -ErrorAction SilentlyContinueコマンドが見えても、実行時にSKU判定で止まることがあります。「見える＝使える」ではありません。NetLbfoの公式説明にも、クライアントOS側のコマンドは“サーバーをリモート管理する目的”がある旨が示されています。
GUIにNIC Teamingが存在するかを確認する
Windows ServerではServer Managerのローカルサーバー画面にNIC Teamingが出るのが一般的です。一方、Windows 11の標準UIでは“OS純正のLBFOチーミング”を作る導線は基本的に存在しません。これはSKUの違いによるものです。
代替策：やりたいこと別に「現実的な落とし所」を選ぶ
NICチーミング（LBFO）は便利ですが、目的を分解すると“別の機能で満たせる”場面も多いです。ここでは、Windows 11環境で採りやすい選択肢を、目的別に整理します。
| 目的 | おすすめ | 理由 | 注意点 |
|---|---|---|---|
| OSとして1本に見せたい（IPを1つにしたい） | Windows Serverへ移行 | LBFOを公式にサポート | ライセンス／運用設計が必要 |
| ファイル転送を速くしたい | SMB Multichannel | チーミング無しで複数NICを活用できる | SMB用途限定／NAS側の対応要確認 |
| 冗長化したい（ケーブル断を避けたい） | スイッチ冗長化や機器構成の見直し | OSチーミングに依存しない設計にできる | ネットワーク全体の設計が必要 |
| 帯域を上げたい（1GbE×複数の代わりに） | 2.5GbE/10GbEへアップグレード | 構成がシンプルでトラブルが少ない | スイッチ・配線の更新が必要 |
| どうしても同一PCで束ねたい | NICベンダーの機能（対応時のみ） | OS機能がなくても束ねられる場合がある | Windows 11で使えないベンダーもある |
Windows Serverを使う：最も確実で“正攻法”
OSレベルのNICチーミング（LBFO）を前提にするなら、結局はWindows Serverを使うのが最短です。MicrosoftのNetLbfo（NIC Teaming）機能はWindows Server向けとして提供されているため、仕様とサポートを両立できます。
また、Windows Server 2016以降ではLBFOに加えてSET（Switch Embedded Teaming）という別系統のチーミング手段も整理されています。どちらにせよ、これらはサーバー領域の機能としてドキュメントが体系化されています。
「Windows 11で使いたいアプリがある」などの事情がある場合は、次のような折衷案も現実的です。
- 物理ホストはWindows Server（または別のハイパーバイザー）にして、Windows 11は仮想マシンとして運用する
- NICチーミングが必要な用途（NAS/ルーティング/監視など）だけサーバー側に寄せ、Windows 11はクライアントに徹する
NICベンダー側のチーミング：できる場合もあるが“Windows 11対応”が最大の壁
「OSのソフトウェアチーミングは無理でも、NICのドライバー／管理ツール側で束ねられないか？」という発想は自然です。実際、ベンダーが独自にチーミング機能を提供していることがあります。
ただし、Windows 11ではベンダー側のチーミングが成立しないケースが増えています。代表例がIntelで、IntelはWindows 11（クライアント）でIntel PROSetおよびIntel Advanced Network Services（ANS）をサポートしないと明記しています。ANSにはチーミングやVLAN作成機能が含まれるため、Intel系の「PROSetでチーミングしていた」環境は、Windows 11への移行で行き止まりになりやすいです。
ベンダー方式を検討するなら、次の観点をチェックすると“買ってから詰む”事故を減らせます。
| チェック項目 | 見るべきポイント | 落とし穴 |
|---|---|---|
| Windows 11対応の管理ツールがあるか | 対応OSにWindows 11が明記されているか | ドライバーは対応でも“チーミング機能”だけ非対応がある |
| チーミング方式（LACP/Static/独自） | スイッチ側設定が必要か／不要か | スイッチと方式が合わないとリンクが上がっても通信が不安定 |
| 同一NIC/同一速度の要件 | 混在可否、速度違いの扱い | 速度違いは片方が遊ぶ、または不安定になることがある |
| サポート対象が“サーバーOS限定”になっていないか | Windows Serverのみ対応のケースも多い | クライアントOSでは動作してもサポート外になりがち |
結局のところ、Windows 11で「ベンダーのチーミング」を当てにするより、サーバーOSへ寄せるか、用途別に別の仕組みに置き換えるほうが運用は安定しやすいです。
SMB Multichannel：ファイル転送目的なら“チーミング無し”で複数NICを活かせる
NASやファイルサーバーへのアクセスを速くしたい（バックアップ、動画編集、ISO配置など）という用途なら、NICチーミングよりもSMB Multichannelのほうが相性が良いことがあります。
SMB MultichannelはSMB 3.0の機能で、SMBクライアントとSMBサーバーの間に複数の経路がある場合に、複数のネットワーク接続を同時に使って帯域を増やしたり、経路断に強くしたりする仕組みです。さらに、SMB Multichannelは既定で有効であり、条件が整えば自動で複数経路を使います。
特に重要なのは、SMB Multichannelは「チーミングされたNIC」に限らず「複数のNIC」でも成立し得る点です。つまり、Windows 11側でLBFOが組めなくても、SMB用途だけは性能向上の余地があるということです。
確認に使えるコマンド例です（環境によって表示内容は変わります）。
# SMB Multichannelが有効か
Get-SmbClientConfiguration | Select-Object EnableMultiChannel
# 実際に複数経路が張れているか（SMB接続中に実行）
Get-SmbMultichannelConnectionSMB Multichannelには要件があり、例えば複数NIC、RSS対応、同速度のNICが有利などの条件が挙げられています。用途が「NASを速くしたい」なら、まずはSMB Multichannelを軸に設計し、足りないところだけ機器更新（2.5GbE/10GbE）で補うのが現実的です。
帯域が欲しいなら“チーミング”より回線・機器更新がトラブルが少ない
1GbE×2本や1GbE×4本を束ねて速度を上げたい、という動機は多いのですが、チーミングは「いつでも単純に合算できる」わけではありません。通信の種類（1本の大きな転送か、複数の同時接続か）や負荷分散アルゴリズムによって、体感が変わります。
そのため、Windows 11クライアントで苦労して束ねるより、次のような更新のほうが“結果として速くて安定”しやすいです。
- PC側を2.5GbE/10GbEにする（PCIe NICやUSB-Cアダプタ）
- スイッチも2.5GbE/10GbE対応にする
- ケーブルを規格に合わせて見直す（2.5GbEなら多くは既存のCat5eでも可だが、環境次第）
複数ポートNICがある環境ほど「束ねる」より「役割分離」（後述）のほうが運用がラクになるケースもあります。
冗長化が目的なら“OSで束ねる”以外にも道がある
冗長化の目的が「ケーブルが抜けても止めたくない」「スイッチが1台死んでも耐えたい」なら、OS側のチーミングが無いと詰む…とは限りません。むしろ冗長化は、ネットワーク全体の設計で決まります。
- スイッチをスタック／MLAG／冗長構成にして、単一スイッチ障害を避ける
- ルータ／FW側で回線冗長（デュアルWAN等）を組む
- “止まると困る”役割（NAS、監視、ルーティング）だけ別筐体に移し、Windows 11はクライアント用途に限定する
Windows 11クライアントにサーバー級の冗長化要件を持ち込むほど、運用コストが跳ね上がる傾向があります。目的を分解して、冗長化が本当に必要な部分だけに投資すると失敗しにくいです。
4ポートNICを“無駄にしない”Windows 11での活かし方（役割分離の例）
LBFOで束ねられないなら、4ポートを別用途に割り当てて“得意なことだけ任せる”ほうが現実的です。例えば次のような分け方があります。
| ポート | 用途例 | 設定の考え方 | メリット |
|---|---|---|---|
| Port 1 | 通常の社内LAN（インターネット） | デフォルトゲートウェイは基本ここだけに置く | ルーティングが安定 |
| Port 2 | NAS専用（SMB Multichannel狙い） | NAS用セグメントを分離、または専用スイッチ | 転送の安定・高速化が狙える |
| Port 3 | 検証環境（ラボ） | 別サブネットで固定IP、必要なら静的ルート | 本番と干渉しにくい |
| Port 4 | 機器管理用（IPMI/ILO相当の管理NW、監視、収録など） | DNS登録を抑制するなど、名前解決の混乱を避ける | “管理だけ止めない”が作りやすい |
この“役割分離”は、LBFOの「1本にまとめたい」という思想とは逆ですが、Windows 11クライアントで安定運用しやすいのはこちらです。
複数NIC運用でハマりやすいポイントと対策
チーミング無しで複数NICを同時に挿す場合、よくあるトラブルを先回りして潰しておくと運用が楽になります。
| ありがちな症状 | 原因の例 | 対策の方向性 |
|---|---|---|
| 通信が不安定／行き先によって遅い | 複数NICにデフォルトゲートウェイが設定され、経路が揺れる | デフォルトゲートウェイは基本1つにする。必要なら静的ルートで分ける |
| PC名の名前解決が変になる | 複数NICがDNSにAレコード登録してしまう | 用途によってDNS登録を抑制（管理NWなど） |
| 同一サブネットに2枚挿したら挙動が読めない | 送受信が別NICに分散され、セッションが崩れる／期待通りに分散しない | 基本はサブネット分離。SMB Multichannel狙いなど、狙いが明確な場合のみ例外を検討 |
| 「LACPを組んだのに速くならない」 | 1つの大きい転送は注意しないと1本に偏ることがある | 用途（同時接続数）を見直す。単純に10GbE化した方が早いケースも多い |
よくある質問
Windows 11の「ネットワークブリッジ」でNICチーミングの代用になりますか？
代用にはなりません。ネットワークブリッジはL2の“橋渡し”であり、LBFOのような負荷分散やフェイルオーバーを提供する仕組みではありません。構成によっては余計にトラブルが増えるため、目的が「冗長化・帯域向上」なら別手段を選ぶ方が安全です。
スイッチ側だけLACPを設定すれば、Windows 11でも束ねられますか？
一般に、ホスト側が“束ねたNIC”として振る舞うための機能（OSのLBFOやベンダーツール）が必要です。Windows 11標準ではLBFOがサポート対象外なので、スイッチ側だけ設定しても成立しません。
IntelのNICならIntel PROSetでチーミングできますか？
Windows 11クライアントでは、Intel PROSetおよびIntel Advanced Network Services（ANS）がサポートされない旨がIntelから案内されています。ANSにはチーミングやVLAN関連機能が含まれるため、Windows 11でIntel PROSet方式のチーミングを前提にするのは避けたほうが無難です。
Windows 11 LTSC 2024ならLBFOが使える可能性は？
LTSC 2024はクライアント系SKUであり、LBFOがWindows Server向け機能である点は変わりません。Microsoftのドキュメント上も、NIC Teaming（LBFO）はサーバーOSで提供される旨が示されています。
どうして「Windows 11でNICチーミングができた」という情報があるの？
非公式な手順や、サポート外の構成で“たまたま動いた”例が混ざっていることがあります。OS更新で突然壊れたり、ドライバー更新で戻らなくなったりしやすく、業務用途・常用用途ではおすすめできません。確実さを求めるなら、サポートされるOS（Windows Server）へ寄せるのが安全です。
まとめ：Windows 11でNICチーミングに悩んだら、まず“LBFOはサーバー機能”と割り切る
- Windows 11 Pro 24H2でLBFO（NetLbfo）によるソフトウェアNICチーミングを作ろうとしてエラーになるのは、手順よりもSKUのサポート範囲に当たっている可能性が高いです。
- Windows 11 LTSC 2024もクライアントSKUであり、LBFOが例外的に許可されるわけではありません。
- 代替策は「Windows Serverへ寄せる」「ベンダー機能（ただしWindows 11対応を要確認）」「用途別にSMB Multichannelや機器更新で解決する」が現実的です。
コメント