AirWaveとCentralの主な技術的な違いは何ですか？

AirWaveはAOS-8コントローラに適したSNMPベースのオンプレミス監視ツールです。CentralはWebSocketテレメトリを使用するクラウドネイティブな管理プラットフォームであり、AOS-10およびWi-Fi 7ハードウェアにとって不可欠です。

AirWaveライセンスをAruba Centralで再利用できますか？

いいえ。Centralには独自のサブスクリプションライセンス（FoundationまたはAdvanced）が必要です。既存のAirWaveライセンスは引き継がれませんが、HPEはハードウェアのリフレッシュ時に移行クレジットや「Bridge」プログラムを提供することがよくあります。

AOS-10は移行にどのように影響しますか？

AOS-10はAruba AP/ゲートウェイ向けのクラウドネイティブなオペレーティングシステムです。Centralによって排他的に管理され、ローカルのVirtual Controllerの必要性を排除し、真のマイクロブランチ機能を可能にします。

VisualRFのフロアプランは自動的に移行されますか？

VisualRFマップは直接移行されません。AirWaveからフロアプランをエクスポートし、Centralの「Floorplans」セクションに再インポートする必要があります。通常、スケールとAP配置の再キャリブレーションが必要です。

大規模なスイッチスタックのコンフィグレーションの同等性はどのように処理しますか？

Centralは、望ましいクラウド設定とローカルデバイスの状態との差分を特定する「Config Audit」機能を提供します。「Push」ログを表示することで、どのCLIコマンドが実行に失敗したかを正確に確認できます。

CentralではUIグループとテンプレートグループのどちらを使用すべきですか？

UIグループを使用してください。テンプレートグループは構文エラーに起因する広範囲な障害を引き起こす可能性があります。UIグループは、検証済みのより安全な方法で設定をプッシュします。

レガシーAP-305/315 APはどうなりますか？

300および500シリーズなどの既存のAPはCentralに参加できますが、Centralがサポートするバージョン（AOS-8.10またはAOS-10）へのファームウェアフラッシュが必要です。新しいAP-600/700シリーズは直接AOS-10へ移行すべきです。

Aruba AirWaveからCentralへの移行：2026年エンジニアリングプレイブック

AirWaveは既に「死に体」のソフトウェアであり、2026年にオンプレミスのAMP（AirWave Management Platform）インスタンスにしがみついているエンジニアは、ネットワークを管理しているのではなく、負債を抱えています。Aruba AirWaveはその機能的ピークを数年前に迎えました。Aruba Centralへの移行は単なるUIのリフレッシュではなく、SNMPベースのレガシーポーリングからWebSocketベースのストリーミングテレメトリモデルへの根本的なアーキテクチャ転換です。まだ移行を開始していないのであれば、AOS-10への移行曲線から既に遅れをとっています。

AirWaveの終焉：なぜ2026年が最終期限なのか

HPE Arubaは何年もの間、AirWaveの終焉を示唆してきましたが、その厳しい現実は600シリーズおよび700シリーズのアクセスポイントとAOS-10アーキテクチャのリリースによって直面しています。AirWaveはAOS-6およびAOS-8の時代、つまり「Controller-Managed」または「Instant」のサイロの時代のために構築されました。AirWaveは、最新のWi-Fi 6EおよびWi-Fi 7無線によって生成される膨大な量のテレメトリに対応するのに苦労します。さらに重要なことに、AOS-10はローカルモビリティコントローラのコントロールプレーンを廃止し、クラウドネイティブなゲートウェイモデルを採用しており、AirWaveではこれをオーケストレーションできません。

AirWave（AMP 8.3.x）を使い続けると、AOS-8.4/8.10の世界に留まることになります。AI駆動型の無線リソース管理（RRM）を実行する機能、ClientMatchのきめ細かな可視性が失われ、2012年に設計されたツールで高密度環境を管理することを強いられます。XLサイズのAMPアプライアンス（おそらく老朽化したR740またはDL380で稼働）を維持する技術的負債は、電力、冷却、およびRFプロファイルを手動で調整する手間を考慮すると、Centralのサブスクリプション費用を上回ります。

アーキテクチャの差分：ポーリング vs. ストリーミングテレメトリ

AirWaveからCentralへ移行するエンジニアにとって最大の衝撃は「Health」ダッシュボードでしょう。AirWaveでは、データは最後のSNMPポーリング間隔（通常5～10分）と同じだけ古いです。もしAPがダウンした場合、AirWaveは、ポーリングが失敗して閾値に達するまで数分間、アラートを出さないかもしれません。Centralでは、APはAruba Cloudへの永続的なWebSocket接続（HTTPS/443）を維持します。

データプレーンにおける主な違いは以下の通りです。

ステートフルモニタリング： Centralは、クライアントが4-wayハンドシェイクに失敗した正確な瞬間を把握します。AirWaveは「クライアント数」しか知りません。
設定権限： AirWaveでは、Monitor-OnlyとConfig-Modeを選択できました。Centralでは、クラウドがSource of Truthです。スイッチやAPでのローカルなCLI変更は、Centralの同期タイマーによって上書きされます。
保持期間： AirWaveではディスク容量によって制限されていました。Centralは30日間の標準データを提供し、AI Insightsを介した長期レポートオプションも利用可能です。

AOS-10への転換：移行の真の理由

Centralへの移行は通常、AOS-10へのアップグレードと同時に行われます。ここでほとんどの移行が「困難」に直面します。AOS-10は、Instant APに存在した従来の「Virtual Controller」（VC）選出プロセスを廃止します。AOS-10環境内のすべてのAPは同等の参加者であり、コントロールプレーンの指示のためにCentralクラウドと直接通信します。これにより、大規模なAirWave管理IAPクラスタで発生していた「VC再起動」による遅延が解消されます。

! Legacy AOS-8 IAP Config (AirWave managed)
iap-master-election
virtual-controller-ip 10.1.10.5
!
! New AOS-10 Central Logic
! No VC IP. APs use 'aruba-central' point-of-presence.
! Management via:
(AP)# show ap-env
(AP)# show ap debug cloud-server

移行フェーズ1：テンプレートの同等性と戦略

AirWaveの.cfgを単純にCentralに「インポート」することはできません。UIグループまたはテンプレートグループの2つの選択肢があります。AirWaveで「グループとフォルダ」を使用してデバイスを一括編集していた経験が豊富な場合、Centralのテンプレートグループは馴染みがあるかもしれませんが、フラストレーションを感じるでしょう。Centralでは、テンプレートグループは「全てか無か」のCLIブロックです。%variable%マッピングに構文エラーが1つでもあれば、サイト全体の接続が停止します。

ほとんどの企業にはUIグループへの移行をお勧めします。これにより、CentralのGUIを使用して設定を行うことができ、APに送信されるXMLが常に有効であることが保証されます。500以上の同一のブランチサイトがある場合にのみ、.csv変数アップロードを使用したテンプレートグループを検討してください。このフェーズでのヘッドエンド移行の処理方法については、AOS-10ゲートウェイクラスタリングのベストプラクティスに関するガイドを参照してください。

移行フェーズ2：オンボーディングプロセス（グリーンフィールド vs. ブラウンフィールド）

ブラウンフィールド移行の場合、AP/スイッチからAirWaveの設定を削除する必要があります。デバイスがDHCPオプション43またはDNS（airwave.yourdomain.com）を介してAirWaveを指している場合、これらのレコードを削除する必要があります。デバイスがポート443経由でactivate.arubanetworks.comに到達できるようになると、そのMAC/シリアルがCentralアカウントと照合され、新しい設定がプルされます。

デバイス切り替えのステップバイステップ：

ライセンスの割り当て：MAC/シリアルがCentralの「Greenhouse」に登録され、FoundationまたはAdvancedライセンスが適用されていることを確認します。
グループへの移動：デバイスを事前に設定されたUI/テンプレートグループに割り当てます。
AirWave情報の削除：ローカルデバイスCLIで：no communication-monitor ap と no amp-server を実行します。
再起動：これにより、デバイスはActivateハンドシェイクを再開します。

「何が壊れるか」リスト：移行後のサポートに備える

移行はシームレスではありません。移行初日に壊れる可能性のあるものを以下に示します。

レポート形式： AirWaveのPDFレポートはカスタマイズ可能です。Centralのレポートはより厳格です。もしC-suiteが特定の「週次ワイヤレスヘルス」PDFを期待している場合、Central APIとPowerBIを使用してカスタムダッシュボードを構築する必要があるかもしれません。
VisualRFの遅延： AirWaveのVisualRFはローカルで迅速でした。Centralのフロアプランは一貫したアップリンク帯域幅を必要とします。10MbpsのMPLSリンク経由で大きなCADファイルをフロアプランに使用すると、動作が遅くなります。
スイッチ管理： AOS-S（2930F/M, 5400R）スイッチを使用している場合、Centralの「Configuration Audit」は手動の「write memory」コマンドに非常に敏感です。NOCのメンバーにCLIの使用を中止するよう訓練する必要があります。
内部リンク： APが新しい管理プレーンに移動したときにRADIUS CoA（Change of Authorization）が壊れないように、ClearPassとCentralの統合における落とし穴に関する分析を確認してください。

コスト分析：サブスクリプションの苦い薬

AirWaveは、VMライセンスと1回限りのAPライセンス、そしてわずかな年間サポート料金を購入すれば実質「無料」でした。Centralは継続的なOpexの負担です。AP/スイッチノードあたりの標準的な1年間Foundationライセンスは、通常、MSRPで100～150米ドルです。500台のAP環境では、年間5万ドル以上の予算項目になります。

ただし、TCO（Total Cost of Ownership）を計算する必要があります。AirWaveサーバーの管理には以下が必要です。

ハイパーバイザのコンピューティング/ストレージ（AirWaveはリソースを大量に消費します—小規模インストールでも8vCPUと32GB RAMが最低必要）。
RHEL/CentOSのパッチ適用とセキュリティ強化。
手動によるバックアップ検証。

Centralはサーバーメンテナンスを不要にし、ワイヤレスチームの「管理オーバーヘッド」時間を20〜30%削減すると見積もられています。

結論：後戻りできない

AirWaveからCentralへの移行は避けられません。2026年までに、AirWaveはWi-Fi 7エンタープライズの高性能・低遅延要件をサポートできないレガシーな監視ツールとなるでしょう。この移行には、「ボックスマネージャー」のアプローチから「ポリシーオーケストレーター」のアプローチへの考え方の転換が必要です。サイトごとの移行支援やAOS-10設計のハイレベルなアーキテクチャ検証が必要な場合は、techleague.ioのプロフェッショナルサービスおよびエンジニアリングチームをご覧ください。