2026年時点で、ClassicとNextの設定パリティは1対1ですか？

F5はMigration Assistantを大幅に改善しましたが、複雑なiRulesやニッチなL7パーシステンスについては、まだ手動での介入が必要です。20%の手動リファクタリング率を見込んでください。

BIG-IP NextはTMOSのリブランドに過ぎませんか？

いいえ、NextはKubernetesネイティブのマイクロサービスアーキテクチャ上に構築されており、データプレーン（TMM）は管理プレーン（Central Manager）から切り離されています。

BIG-IP Nextのために新しいハードウェアを購入する必要がありますか？

NextはVE上でも動作しますが、Classic TMOSでは効率的に利用できないQATおよびFPGAオフロードを活用するため、rSeriesおよびVELOSハードウェア向けに最適化されています。

BIG-IP NextにおけるAS3の役割は何ですか？

AS3 (Application Services 3 Extension) は設定の主要な方法です。宣言型APIを使用していない場合、Nextを正しく使用していません。

Central ManagerはBIG-IQとどう異なりますか？

Central Managerは、すべてのNextインスタンスの信頼できる単一の情報源であり、ライフサイクルマネージャーです。BIG-IQの機能を置き換えるものですが、マイクロサービスベースのバックエンドを持っています。

Nextで削除される機能は何ですか？

多くのレガシーL7プロトコルやニッチなNTLM機能は、セキュリティ攻撃面の削減とカーネルの複雑性軽減のために非推奨になりました。

カットオーバーの最適な方法は何ですか？

DNSベースのトラフィックシフト（GSLB）は、MACレベルの競合を回避し、きめ細かなロールバックを可能にするため、ClassicからNextへトラフィックを徐々に移行させる最も安全な方法です。

F5 BIG-IP Next vs. Classic: 2026年版エンジニアリング移行ガイド

TMOSの時代は終わりを告げようとしています。2026年にもロードバランサーをモノリシックなアプライアンスとして扱っている場合、それは技術的負債の時限爆弾の上に座っているようなものです。Classic BIG-IPからBIG-IP Nextへの移行は、単なるバージョンアップグレードではありません。これは制御プレーンのアーキテクチャ全体を根本的に再構築するものであり、LinuxベースのモノリシックOSからKubernetesネイティブのマイクロサービス駆動型エンジンへと移行することで、我々が知る「bigip.conf」を完全に過去のものとします。

ポストTMOSの現実: Classicが終焉を迎える理由

20年間、F5エンジニアはbigpipe、そして後にtmshに依存して作業していました。Classic BIG-IPアーキテクチャでは、制御プレーン、管理プレーン、データプレーンが単一の密結合イメージにバンドルされていました。これにより、スケーリングが困難になり、アップグレードが危険なものとなっていました。2026年現在、業界は移行を完了しています。BIG-IP Nextは、これらの機能を完全に分離しています。データプレーン（TMM）は現在コンテナ化されたプロセスとして動作し、管理プレーンは集中管理コントローラー（BIG-IP Next Central Manager）にオフロードされています。

Classic時代では、管理GUIのCVEは、パッチ適用のためにはトラフィック処理エンジン全体を停止させることを意味しました。BIG-IP Nextでは、データプレーンは切り離されています。もはや「箱」を管理するのではなく、Central Managerを介してライフサイクル管理される高性能なトラフィックインスタンスを管理します。壁に書かれた文字に気づいていないのであれば、iSeriesのEOL日と、VELOSおよびrSeriesハードウェアへのシフトを見てください。これらは、Nextへの本格的な移行が始まる前のClassicの最終着地点です。

アーキテクチャ詳細: Kubernetesを基盤に

BIG-IP Nextの内部では、F5がついにKubernetesエコシステムを採用しました。これは単なる「コンテナ内のF5」ではありません。インスタンスライフサイクル全体のオーケストレーションは、K8sプリミティブを介して処理されます。VELOSパーティションまたはESXi上のVEとしてNextインスタンスをデプロイする場合、APIファーストのアプローチを使用し、ロードバランサーを一時的なリソースとして扱うシステムと対話することになります。

分離された管理への移行

Classic BIG-IPは、system-authおよびmcpdプロセスを使用して設定状態を処理していました。これは、あらゆる大規模デプロイメントのボトルネックでした。BIG-IP Nextは、「信頼できる情報源」をCentral Managerに移行します。インスタンスは本質的にステートレスなプロキシとなります。これにより、これまで不可能だった水平スケーリングが可能になります。2026年には、単一のCentral Managerが複数のクラウドおよびオンプレミス環境で500以上のNextインスタンスを制御するエンタープライズデプロイメントが見られますが、これは旧来では数十台のBIG-IQクラスタが必要であった偉業です。

設定: 「bigip.conf」の終焉とAS3の台頭

まだGUIをクリックして仮想サーバーを作成しているようでは、組織に貢献できていません。BIG-IP Nextは、実質的にApplication Services 3 Extension (AS3) またはその進化版を必須とします。もはや検索すべき/config/bigip.confはありません。設定はJSONとして保存され、REST APIを介してプッシュされます。

{
    "class": "ADC",
    "schemaVersion": "3.0.0",
    "id": "NextMigration",
    "tenant1": {
        "class": "Tenant",
        "app1": {
            "class": "Application",
            "template": "http",
            "serviceMain": {
                "class": "Service_HTTP",
                "virtualAddresses": ["10.10.10.100"],
                "pool": "web_pool"
            },
            "web_pool": {
                "class": "Pool",
                "monitors": ["http"],
                "members": [{
                    "servicePort": 80,
                    "serverAddresses": ["192.168.1.10", "192.168.1.11"]
                }]
            }
        }
    }
}

この変更により、真のGitOpsが可能になります。2026年における標準的なワークフローは次のとおりです。開発者がGitHubリポジトリにPRを送信 -> CI/CDパイプラインがAS3 JSONを検証 -> Central Managerが変更をBIG-IP Nextインスタンスにプッシュ。これにより、Classic時代における障害の主要原因であった手動設定のずれが解消されます。

パリティギャップ: 移行で失うもの

率直に言いますと、BIG-IP NextはClassicと100%の機能パリティを持っていませんし、おそらく今後もそうでしょう。F5はこの移行を利用して技術的負債を取り除きます。TMOSカーネルを妨げていた古いプロトコルやニッチな機能は削除されました。2012年以降の曖昧なiRulesコマンドセットや特定のレガシーNTLMプロファイルに依存している場合、大きな問題に直面するでしょう。

iRules移行: F5は「BIG-IP Next Migration Assistant」を提供していますが、これは魔法の杖ではありません。複雑なiRulesの約20%は手動での書き直しが必要です。Next上のiRulesはよりパフォーマンスが高いですが、構文にはより厳格です。
AFM/ASM: セキュリティモジュールは「BIG-IP Next WAF」および「BIG-IP Next Access」と再ブランド化されました。ポリシーエンジンはよりクリーンですが、高度にカスタマイズされたv15/v16 ASMポリシーから移行する場合、数週間にわたる監査プロセスが必要です。
L7パーシステンス: 多くのレガシーパーシステンスメソッドは、Modern TLS標準を介したクッキーベースまたはユニバーサルインスペクションに代わって非推奨になりました。

2026年の移行ロードマップ

無計画な移行は失敗します。我々は3段階のアプローチを推奨しており、これはF5から現代のSDNへの移行ガイドで詳しく説明しています。

フェーズ1: Central Managerのデプロイ

Central Manager (CM)が堅牢化され、IPAM/DNS統合が確実になるまで、単一のNextインスタンスもデプロイしないでください。CMは頭脳です。BIG-IQを扱った以上の敬意を払ってください。高可用性のため、CMには3ノードクラスタを確保してください。

フェーズ2: シャドウ設定とAS3変換

既存のClassic BIG-IP設定をMigration Assistantに通します。すべての仮想サーバーについて、対応するAS3宣言を生成します。これらの宣言をラボのNextインスタンスにデプロイし、データプレーンの動作がレガシーTMM出力と一致することを確認する「読み取り専用」テストを実施します。

フェーズ3: トラフィックフリップ

DNSベースの移行（GSLB/BIG-IP DNS）を使用して、Classic iSeriesからNextインスタンスへトラフィックを徐々に移行させます。MACアドレスレベルでのフォークリフトスワップを試みないでください。Nextの基礎となるネットワークスタックは、特にマルチテナント環境において、ARPとルーティングを異なって処理します。

ハードウェアパフォーマンス: Next時代のVELOSとrSeries

レガシーハードウェアでBIG-IP Nextを実行することは、フラストレーションの元です。Kubernetesベースのアーキテクチャから最大限の性能を引き出すためには、rSeries（例：r5900またはr10900）またはVELOSシャーシによって提供されるFPGAアシストオフロードが必要です。rSeriesはSSL/TLSオフロード専用のFPGAを提供し、NextデータプレーンはQuickAssist Technology (QAT)ドライバーを介してこれらを直接利用します。

私のテストでは、r10900上のBIG-IP Nextインスタンスは、同じハードウェア上のClassic v15ソフトウェアと比較して、40%多く同時TLSハンドシェイクを処理します。なぜでしょうか？それは、Nextのデータプレーンが、Classic TMOSを悩ませていた大規模な管理プロセスのオーバーヘッドなしに、マルチコアスケーリングに最適化されているからです。

実世界のコストとライセンス

F5は完全にサブスクリプションベースのモデルに移行しました。まだ永久ライセンスを使用している場合、2026年にはF5 FlexPoolまたはBIG-IP Nextサブスクリプションへの移行をF5が奨励するため、メンテナンスコストが急増するでしょう。高性能なNextインスタンス（10Gbpsスループットティア相当）の場合、WAF/Advanced Firewallの要件にもよりますが、年間約15,000ドル〜25,000ドルの費用を見込む必要があります。

結論: 今すぐ移行すべきか？

新しいインフラストラクチャを構築する場合、Classicをデプロイしてはいけません。それは、24か月後に移行しなければならないレガシーシステムを構築しているだけです。iSeriesハードウェアで安定したワークロードを実行している場合、2026年末までに戦略を確定する時間があります。TLS 1.3におけるパフォーマンス向上と、AS3/GitOpsの運用効率は、初期の設定変換の苦痛に見合うだけの価値があります。ただし、APIファースト管理にチームが対応できていない場合は、デプロイ中心のNextの現実に合わせて人材を雇用または育成するまでClassicにとどまるべきです。

ADCスタックのモダナイゼーション、または現在のF5環境の専門監査が必要ですか？techleague.ioで当社のエンジニアリングサービスおよびアーキテクチャレビューをご覧ください。