ネットワーク仮想化とは――汎用サーバー上でモバイルネットワーク機能を実装する、その仕組み

　従来、専用の装置として実現していた機能を汎用のサーバーなどの上で実現することを仮想化と言います。「楽天モバイルはネットワークを完全仮想化している」とか、「NTTドコモがコアネットワークの完全仮想化を完了した」とか、モバイルネットワークにおいて仮想化は大きな流れとなっています。

　仮想化には、開発や運用を含めた全体のコスト削減、新機能の開発や機能改修の短時間化、処理量の急激な増加などに対するスケールアップの迅速性、信頼性の向上、ハードウェアへの依存性の除去など、さまざまなメリットがあります。

　そこで今回はモバイルネットワーク、特にコアネットワークの仮想化の仕組みと進化、実際のネットワークでの仮想化の現状と今後の展開についてまとめます。

仮想化とは

　仮想化は元々ITの分野で、企業の人事・経理などの社内システム、銀行の勘定系システム、Webサーバーやデータベースなど、特定の基本ソフト（OS: Operating System）とアプリがセットになった物理サーバーを多数並列して運用していたのを、単一の汎用サーバー上で異なるユーザーがそれぞれ異なるソフト（OSとアプリ）を並行して実行できるようにする技術を起源とします。

　仮想化の背景には、半導体技術の進化に伴いPCや汎用サーバーが登場すると同時に、それらに搭載されるプロセッサの処理能力が飛躍的に向上したことがあります。高性能化した汎用サーバーは、特定の処理だけに専用化するのでは余力（リソースの空き）が生じるようになり、複数の処理で共用するのが現実的となりました。

　そこで、図1に示すように一つの物理サーバーの性能を細かく切り分け、あたかも複数台の独立したサーバーが存在するかのように「仮想マシン（VM: Virtual Machine）」を構成する手法が普及しました。仮想化により、1台の物理サーバー上に複数のVMを載せることができ、それぞれのVMを独立したOS上のアプリとして同時に実行できます。

　また、計算処理だけではなく、データを記憶するストレージや外部システムなどとのネットワーキングのためのハードウェアの進化により、これらも論理的に分割して柔軟に利用できるようになりました。物理的な制約に縛られずにプロセッサやストレージといったリソースを柔軟に分割・構成し運用できることが、仮想化の大きな特長です。

　仮想化により、従来はシステムごとに必要だった物理機器を集約できるため、機器の調達コスト（CAPEX）や設置スペース、消費電力などの運用コスト（OPEX）を大幅に削減できます。

　さらに、ソフトウェアの操作だけで素早く新しいVMを生成できる迅速性や、サービスを停止することなく別のサーバーへVMを移動させるライブマイグレーション、サーバーに異常が発生した際に、自動的にまた即座に待機している予備のサーバーへと処理を引き継ぐフェイルオーバー機能により高い可用性を実現できます。

　この仮想化技術をベースに、リソースの配分や管理を高度に自動化し、ネットワーク経由でオンデマンドに提供するサービス形態へと発展させたのが「クラウド化（クラウドコンピューティング）」です。

　仮想化が物理ハードウェアをソフトウェアによって論理的に切り出す基本的な技術を指すのに対し、クラウド化はその技術を活用して、ユーザーが必要な時に必要なだけリソースを利用できるようにした利用形態やサービスモデルを指します。

　つまり、仮想化はクラウド化を実現するために不可欠な基盤技術であり、現代のパブリッククラウドやプライベートクラウドという柔軟な社会インフラの誕生、近年大規模化するデータセンタービジネスの基盤ともなっています。

通信ネットワークの仮想化

　通信ネットワークにおける仮想化は、IT分野での仮想化の流れを受けNFV（Network Functions Virtualization）という枠組みで2010年代初頭から始まりました。そして、2010年代半ば以降モバイル通信ではコアネットワークを中心に、実際の商用システムにおいても仮想化が進んできました。

　NFVの初期の検討をリードしたのが欧州の標準化団体であるETSI（European Telecommunication Standards Institute）の中のNFV ISG（Industry Specification Group）です。このNFV ISGが最初に発行したホワイトペーパーに掲載されたNFVの基本ビジョンを示したのが図2で、今でもよく参照されます。

　図2の左側には従来のネットワーク機器として、ルーターやファイアウォール、音声制御装置、モバイルコアネットワーク装置など、様々な専用の機器が並んでいます。従来、通信事業者は異なる通信サービスや機能ごとに、それに特化したこれらの専用ハードウェアを準備する必要がありました。

　この従来のやり方について、ホワイトペーパーでは3つの課題を挙げています。

　図2の右側は、ネットワーク仮想化アプローチでNFVが目指す姿です。左側にあった多種多様な専用の機器はすべて姿を消し、代わりにITの世界で大量生産されている標準的なサーバー、ストレージ（記憶装置）、スイッチ（ネットワーキングのための通信接続装置）という、シンプルで共通の機器（プラットフォーム）に集約されています。

　ルーターやファイアウォール、音声制御装置、モバイルコアネットワーク装置などはすべてソフトウェア（仮想アプリ）へと形を変え、サーバー上で実行されます。

　この新しいアプローチには、以下のようなメリットがあります。

　身近な例で例えると、以前私たちが「カメラ」「電卓」「時計」「辞書」といった個別の機器やモノを別々に買い揃えて持ち歩いていた状態が図の左側です。それを、1台のスマホ（共通のハードウェア）に統合し、必要な機能をすべてアプリ（ソフトウェア）としてダウンロードして使うように変えたのが、図の右側が示す仮想化のアプローチに相当します。

　実際の通信ネットワークの仮想化（NFV）とIT分野の仮想化は、共通ハードウェア上でサービスや機能をソフトウェアとして実現する「ハードとソフトの分離」という基本的な枠組みは共通していますが、処理対象の性質と要求される性能基準には大きな違いがあります。

　IT分野の仮想化は、主に企業システムやWebサーバーなどを対象としているため、データ処理の正確性や整合性（矛盾がないこと）を最優先します。処理の遅延はある程度のブレがあっても許容されることが多く、リソースの効率的な利用とコスト削減に主眼が置かれます。

　これに対し通信ネットワークの仮想化では、例えば1秒間に数億個も流れる通信データ（パケット）をリアルタイムに転送・制御する処理を扱います。そのため、ミリ秒未満の低遅延や非常に高いスループット（通信量）、そして社会インフラとして24時間365日絶対に止まらない文字通りキャリアグレードの高信頼性が要求されます。

　これらの厳しい要件をクリアするため、汎用サーバーの能力を限界まで引き出す独自の高速化技術、通信量の急増に対してサーバーの処理リソースを追加割当てする自動スケールアップ技術、サーバーの障害などの際に別のサーバーに瞬時に代替させる冗長化技術など、通信ネットワーク特有の仕組みを組み込んでいます。

NFVによる仮想化　VMベース

モバイルネットワークにおける仮想化は、まずは4Gのコアネットワーク（EPC: Evolved Packet Core）を対象として2010年代半ばから始まりました。

　当時のEPCは、加入者管理を行うHSS、制御信号を扱うMME、ユーザーデータを転送するS-GW/P-GWといった主要なコンポーネントが、通信ベンダー固有の専用ハードウェアと固有のソフトウェアから構成される機器として個別に開発・提供されていました。

　2010年代半ば、スマートフォンの普及、映像ストリーミングなど様々なアプリの利用拡大に伴いモバイルデータトラフィックは前例のないペースで増えていました。そうした中、通信事業者にとって専用機器による運用では、急増する通信量に合わせてタイムリーに設備を拡張することが難しく、また設備投資と共に局舎のスペース、電力などの運用コストも増大する懸念がありました。

　日本でも比較的早くEPC仮想化の検討が進みましたが、それには2000年代中期頃から、通信分野で用いられていた国際標準のハードウェアであるいわゆるブレードサーバーについて、性能面及びコスト面で限界が感じられていたという背景もあります。

　それらの背景もあり、各事業者やベンダーで仮想化の検討や実証試験、実装が進みました。ここでの仮想化は、当時IT分野で成熟していたハイパーバイザ（Hypervisor）技術を通信インフラに適用する形で行われました。

　ハイパーバイザとは、従来専用ハードウェア上で個別の基本ソフト（OS: Operating System）上で動作していたソフトウェアを、汎用サーバー上でそのままVMとして動作させるための制御プログラムです。通信ネットワークの仮想化においてはKVM（Kernel-based Virtual Machine）が多く採用されています。

　KVMに代表されるハイパーバイザは、物理ハードウェアの違いをうまく吸収するように制御するため、ゲストOS（汎用サーバー上のOSに対して、その上で動くアプリのOSという意味）を含む既存のソフトウェアを改変することなく非常に効率良く動作させることが可能です。

　この仮想化により専用ハードウェアとソフトウェアの切り離しが行われ、図3に示すようにMMEやHSS、S-GW/P-GWといった各コアネットワーク機能がVNF（Virtual Network Function）と呼ばれるVMとして、汎用サーバー上で動作するようになりました。

　仮想化では、VMを設定する単位としてハードウェアの制約はなくなり、一つのサーバー上で同じ種類のVNFが複数同居できます。

　例えば、特定の地域や加入者数に応じた適切なサイズのVNFを複数並列で運用することで、処理効率を高めたりリスクを分散したりすることが可能です。また、加入者の増加に伴いサーバーを追加したり、サーバーにVNFを追加して処理量の増加に対応することも可能です。

　一方、仮想化において、通信事業者ネットワークでは多数のサーバー群によりコアネットワーク機能を運用することになりますが、それらのサーバーにVNFを割当てたり、VNFの追加、削除など、運用管理の役割を担う「統合管理プラットフォーム」が必要となります。これは一般に、クラウドOS（Operating System）とかデータセンターOSと呼ばれます。

　クラウドOSというのはパソコンの基本ソフトであるWindowsやmacOSと同様に、複雑なハードウェアを意識させずシステム全体を扱いやすくコントロールする役割を担いますが、その対象が大量の物理サーバー、ストレージ、それらをつなぐスイッチなどのネットワーキング機能であり、これらをプール化し、あたかも1台の巨大なコンピューターとして一元管理・制御します。

　VMベースの仮想化においてクラウドOSの主な機能は、多くのサーバー群やストレージなどのリソースを利用して、処理負荷に応じてVNFを動的に生成、消去したり、各VNFがうまく共存できるように制御して、全体として最大限の処理能力を引き出すことです。

　通信ネットワークにおけるVMベースの仮想化においては、IT分野で実績のあるOpenStackが主に利用されてきました。OpenStackはオープンソースですが、このオープンソースのコミュニティは通信分野での仮想化には非常に協力的で、通信分野向けの機能最適化が迅速に行われました。

　さて、ハイパーバイザがVMを効率良く動作させると言っても、S-GW/P-GWのように膨大なパケットを転送する処理では処理負荷（オーバーヘッド）が大きくなってしまい、処理が追いつかなくなります。

　つまり、汎用サーバーはパケット転送以外の様々な処理も同時にこなしているため、届いたデータパケットを一旦待ち行列（順番待ちの列）に入れます。そして、自分の順番が来てから転送処理を行うため、どうしても少し遅れが生じ、通信に必要なリアルタイム性が損なわれてしまいます。

　そこで、OpenStackはクラウドOSとしての内部処理をバイパスしたり、物理ネットワーク処理機能とVNFの間を直結するパスを設定したりすることで、VNFからハードウェアに直接アクセスして無駄のない超高速な処理が行える仕組みを提供します。このように、OpenStackはVMの制御だけではなく、通信処理の効率化にも関与します。

　このように、S-GWやP-GWのように超高速にデータを転送する厳しいリアルタイム性が必要となる装置の仮想化についても、上記のようにクラウドOSをバイパスするなどにより、VMベースであっても専用ハードに匹敵する「キャリアグレード」の高速パケット転送が可能となり、パケット転送処理も含めた仮想化が本格化しました。

　一方、主に制御信号を扱うMMEやHSSは計算処理が中心であるため、比較的シンプルにVMベースの仮想化が進展しました。これによりEPC全体の仮想化が実現し、加入者数の増加などに対してVNFの複製を増やすだけで迅速に処理能力を拡張できる環境が整いました。

　初期のVMベースの仮想化では、既存の専用ハード上のソフトウェアをゲストOSも含めてそのままVNFとして利用していましたが、やがて仮想化環境に、より適した新たなVNFが開発されるようになりました。

　専用ハード上のソフトウェアが巨大で、例えばスケールアップのためにVNFを追加生成するときに多くの時間が掛かるといった問題があったので、新たなVNFは機能的に少し小さな単位に分割して機動力を高めるなど、効率を上げるようにしました。

　この仮想化環境に適合したVMへの進化が、後述のクラウドネイティブ仮想化への架け橋になっています。

VMベース仮想化の課題

　4GでのVMベースの仮想化は、ハードとソフトの分離を実現しましたが、通信ネットワークの運用という意味ではいくつかの問題点があることが徐々に明確となりました。

　最大の課題は、VMの重厚長大さでした。

　たとえばトラフィック急増に対応するためにMMEに相当するVNFを増設しようとしても、OSを含む巨大なVNF全体のデータコピーと、PC上でのWindows起動と同様なOSの起動処理を伴うため、完了までに数分程度の時間を要しました。このため、突発的なアクセス急増に対して、即座に通信リソースを増強することが難しかったのです。

　また、VMベース仮想化の後期に登場した、仮想化環境へ最適化したVNFであっても、システム全体が1つの巨大なブロックとして作られていることに変わりはありませんでした。そのため、一部の機能を修正・追加するだけでも、VNF全体に手を加える大きな手間が掛かりました。

　さらに、その一部分の不具合がVNF全体、ひいてはネットワーク全体の通信障害につながるリスクも抱えていました。

クラウドネイティブ技術

　さて、2010年代前半から後半にかけてIT業界ではクラウドネイティブ技術が誕生し、パブリッククラウドを中心に急速に広まりました。クラウドネイティブ技術というのは、従来のコンピューターの動かし方を根本から変える3つの新たな構成要素であるコンテナ、マイクロサービス、コンテナオーケストレーターからなります。図4にクラウドネイティブ技術の基本的仕組みを示します。

コンテナ（container）

　コンピューターの中で動くすべてのアプリ（Word、Excel、ブラウザなど）は、「プロセス」と呼ばれるひと塊のプログラムの処理の単位として動いています。通常、同じコンピューターの中で動くプロセス同士は、お互いの存在が見えています。

　これに対し、「コンテナ」技術とは、コンピューターの基本ソフト（OS）の機能を使って、特定のアプリの周りに透明で見えない壁を立てるような技術です。壁の内側に閉じ込められたアプリは、同じコンピューターの中で、他にどんなアプリが動いているのか見えず、まるで自分だけでコンピューターを独占しているように動作します。

　同時に、そのアプリが使える計算処理パワーやメモリー容量が、壁によって厳しく制限されます。これにより、万が一そのアプリがバグなどで暴走してメモリーを食いつぶそうとしても、壁に阻まれるため、隣にある他のアプリやコンピューター全体が巻き添えを食うのを防ぐことができます。

　コンテナ技術はそれ以前からありましたが、使いこなすのは非常に困難でした。しかし、米Docker社が2010年代半ばに誰でも使いこなすことができるコンテナを作りだし、動かすためのコンテナエンジンとして「Docker」を公開し、一気に注目を集めました。それ以降、コンテナ技術が急速に広まりました。

マイクロサービス（microservices）

　それまでの一般的なアプリは、すべての機能（例えば、買い物サイトであれば「商品の検索」「カートに入れる」「決済する」など）が、1つの大きなプログラムの塊として作られていました。「マイクロサービス」とは、この大きな塊を作るのをやめ、「単一の仕事しかしない小さなアプリ」にばらばらに分解し、アプリ間を通信機能でつなぐ設計手法です。

　分解された小さなアプリは、それぞれコンテナの中で個別に動きます。アプリの作り方が全く違っていても、それぞれの空間で独立して動いているため、お互いのコード（プログラムの記述）が混ざり合うことはありません。一方で、何かやりとりが必要なときには、お互いに通信機能を使ってメッセージを送り合って連携します。

　それぞれの小さなアプリは、自分の手元にユーザーの情報などを記憶し続けない、つまり状態を持たない（ステートレス）作りになっています。データはすべて、外側にある「共通の大きな記憶装置（データベース）」へその都度保存しに行きます。

　これにより、例えば「決済する」アプリだけを最新版に書き換えたいとき、他のアプリ（検索など）を止めることなく、動かしたままでその部分だけを入れ替えることができるようになります。

コンテナオーケストレーター（container orchestrator）

　アプリをマイクロサービスとして細かく分解し、それぞれをコンテナの空間で動かすようになると、データセンターの中には例えば数千～数万個という膨大な数の小さなアプリが同時に共存することになります。これを人間の手で、どのコンピューターでどれを動かすかと管理するのは不可能です。

　そこで登場するのが、コンピューター群全体の動作を統括する「コンテナオーケストレーター」です。利用者が例えば、「このアプリは常に3インスタンス（コピーを3つ）稼働させる」という定義ファイル（マニフェスト）を用意すると、コンテナオーケストレーターはこれを基にバックグラウンドで自動的にそのアプリの3つのコピーが同時に実行できるように処理リソースを割当てます。

　具体的には、データセンター（クラウド）にある何百台ものコンピューターの空き状況をリアルタイムでモニターし、「今は1番目のコンピューターが空いているから、ここに配置しよう」と判断して特定のアプリを起動します。

　また、アプリが正常に動いているかを常に監視し続けます。もしどこかのコンピューターが故障したり、アプリがエラーで突然消滅した場合は、それを瞬時に検知します。そして、別の正常に動作しているコンピューターの上で、即座に同一のアプリに対応するコンテナを再起動してサービスを復旧させます。

　このように、コンテナオーケストレーターは人間が一切指示をし直さなくても、常に定義ファイル通りの数と状態でプログラムを維持し続ける、データセンター全体の自動制御システムとしての役割を果たします。

　大量のコンテナを管理するコンテナオーケストレーターの領域では幾つかの提案がありましたが、激しい覇権争いの後、Googleが公開しオープンソースとして管理されているKubernetes（クバネティス）がパブリッククラウドからオンプレのサーバーに至るまで広く利用されるようになり、事実上の標準となりました。

クラウドネイティブ仮想化

　2010年代後半、5Gのコアネットワークである5GC（5G Core）の標準化が行われました。

　モバイル通信において、4Gまでの標準化は各機能をハードウェアとしての装置と対応づけ、実質的に物理的な装置の仕様と、装置間での制御信号やデータのやりとりを規定することが前提となっていました。

　しかし、既に4Gでの仮想化が進んでいたので、5GCについては物理的な装置の仕様ではなく仮想化を前提に標準化を行うこととなりました。一方で、同時に導入が始まっていたVMベースの仮想化には、前述のように処理の重さや機動力の欠如が明らかとなってきていました。

　ちょうどその時期に、上記のようにコンテナやKubernetesによるクラウドネイティブ技術がパブリッククラウドなどに大規模に導入され、ITの世界での事実上の標準となっていました。そこで、5GCの標準化においてはVMベース仮想化の問題を解決することも期待して、クラウドネイティブの概念を取り入れた仕様を策定する方向となりました。

　具体的には、5GCをNF（Network Function：ネットワーク機能）という、装置単位ではなく仮想化を前提とした機能単位で規定し、標準仕様を満たすNFであればどこでも動作可能という、ハードウェアを意識しないアーキテクチャとしました。

　また、図5に示すようにNF間が共通のバス（通り道）を介してWebアプリで広く使われているHTTP/2という標準手順でやりとりするサービスベースインタフェース（SBI: Service-based Interface）を用いるサービスベースアーキテクチャ（SBA: Service-based Architecture）を採用しました。

　ここでNFはサービス機能であり、個々のNFが自身のサービスを他のNFに対して提供するという形で、システム全体としてコアネットワーク機能を実現するという構成になっています。

　図5に5GCの主要なNFを示しますが、例えばAMF（Access and Mobility Management Function）はスマホのネットワークへの登録、移動の管理やセキュリティ関連の仲介をする機能、SMF（Session Management Function）はスマホの通信経路を含む接続の制御、AUSF（Authentication Server Function）は認証（ユーザーの適格性チェック）を行う機能です。

　また、サービス機能としてのNFを1つ又は複数のマイクロサービスに対応づけ、各マイクロサービスをコンテナに納めることを想定しています。そして、クラウドネイティブの強みであるコンテナを瞬時に起動し、瞬時に消去できる特性を活かすため、5GCを実装する上ではNFの内部に加入者の接続状態や通信状態の情報を持たせない「ステートレス」な設計になっています。

　具体的にはAMFやSMFなどのNFからスマホ毎の状態情報を切り離し、スマホの接続状況などの一時的な状態データを保持する個別のデータベースとNF本体の機能のソフトウェアとを組み合わせたデータ分離型の実装になっています。

　また、NFは通常複数のNFソフトウェアのコピー（インスタンス）として実装されるので、どのNFインスタンスがどこで動いているかを探索できるようにするために、5GCでは各NFインスタンスが自分の存在を登録し、他のNFがそれを探して自動的にやりとりする仕組み（サービスディスカバリ）を担う機能を仕様として設けました。

　これはITの世界でKubernetesが内部で行っているマイクロサービス（コンテナ）単位の管理の考え方を、5GCのアーキテクチャに導入したことに相当します。マイクロサービス、コンテナ、Kubernetesの仕組み自体は、5GCの各NFをNFインスタンスとしてクラウドネイティブ仮想化の技術で実装する段階でフルに活用されています。

　5GCでは、クラウドネイティブ設計の特長を活かし、ネットワークを運用しながらNFの部分的な機能の改変や追加を随時行うCI/CD（Continuous Integration/Continuous Delivery）が可能になることが期待されるということも、クラウドネイティブ仮想化の導入の大きな利点と考えられます。

　従来、通信ネットワークでは、たとえば数カ月に一度、夜間などに計画停止を伴う大規模なシステムメンテナンスを行うことが通例でした。しかし、CI/CDの導入によりサービスを継続したまま、裏側で特定のNFのソフトウェア（あるいはそれを構成するマイクロサービス）だけを安全に最新版へアップグレード（インサービス・ソフトウェアアップグレード）する運用方式を採用することができます。

仮想化した5GCの実装

　5GCは5Gスタンドアローン（SA）で利用されるコアネットワークです。5G SAは日本を含めて世界的に提供エリアが拡大しています。こうした展開が進む中、通信事業者による5GCの実装については、ほぼ例外なくクラウドネイティブなアーキテクチャでの実装が行われています。

　自前の専用データセンター（オンプレ）の汎用サーバー上にKubernetesを搭載し、その上でクラウドネイティブ・ネットワーク機能（CNF: Cloud-native Network Function）として設計されたNFを起動して動作させます。このとき、Kubernetesが定義ファイルに従ってNFを構成する複数のマイクロサービス（コンテナ）を生成しNFインスタンスとして動作させるという仕組みです。

　オンプレだけでなく、安全性や信頼性などの技術基準を満たした上でAWSやGoogle Cloudといったパブリッククラウドのインフラを5GCの一部として組み込む「ハイブリッド・クラウド」や「マルチクラウド」での商用運用も現実のものとなり、通信インフラの柔軟性は従来になく大きくなっています。

　クラウドネイティブ化の大きなメリットとして期待されていたCI/CDも徐々に実用フェーズを迎えつつあります。これにより、かつてのように数カ月に一度のネットワークの計画停止は過去の光景になります。現在は、サービスを継続したまま、裏側で特定のネットワーク機能（NF）のコンテナだけを安全に最新版へ差し替えるインサービス・ソフトウェアアップデートが定着してきています。

　5G SAにおける主要機能であるネットワークスライシングについても、用途や要求品質（超高速、超低遅延、多数同時接続）に応じて、共通の物理プラットフォームの上に、論理的に完全に独立したNF群をオンデマンドで瞬時に切り出す運用が、クラウドネイティブの仕組みによって非常に柔軟かつ迅速に実現できるようになります。

AIネイティブ時代の仮想化

　2030年頃の商用化を目指す6Gは、AIのためのネットワーク（Network for AI）になると言われています。また、既にネットワーク運用の自動化などで利用され始めているAIが6Gにおいてより一層重要な役割を果たす（AI for Network）とも言われています。

　仮想化においても、例えばクラウドネイティブ仮想化で人が定義ファイル（マニフェスト）をあらかじめ書き、Kubernetesがその通りにコンテナを操作するという段階から、AIネイティブ時代の仮想化では、この定義ファイルの人手での作成すら不要になる可能性があります。

　人間が「通信遅延を1ミリ秒以下に保ち、消費電力を最小化せよ」といった抽象的な意図（インテント）を伝えるだけで、インフラに組み込まれたAIが、トラフィックや気象状況、イベントの動きなどをリアルタイムに予測して、分散されたNFインスタンスの配置を先回りして最適化し、自律的に制御するようになるかも知れません。

　また、AIネイティブ時代の仮想化では、個々のNF自体に、特定の通信処理だけでなく意思決定能力を持った小型のAIエージェントが組み込まれる可能性があります。

　そうすると、基地局の近くで動くNF、エッジデータセンターで動くNF、中央のクラウドで動くNFのそれぞれがもつAIが、お互いに自律的に交渉・連携（協調学習）し合いながら、ネットワーク全体の最適化や、高度なAIサービスの提供を分散処理で行うようになるかも知れません。

おわりに

　今回は触れませんでしたが、モバイルネットワークの仮想化という観点ではコアネットワークだけではなく、基地局周りの無線アクセスネットワーク（RAN: Radio Access Network）の仮想化も着実に進展しています。特に、計算処理が中心の無線信号処理部分は仮想化と親和性が高く、汎用のプロセッサやクラウド上での実装が進んでいます。

　仮想化によって、モバイル通信ネットワークの構成や運用の仕方が大幅に変わってきており、IT、クラウド技術によりネットワークの柔軟性が高まっています。

　CI/CDによる開発と運用のサイクル、即ちソフトウェアのライフサイクル管理の自動化により、ネットワーク機能を適宜修正、高度化することが可能となり、ユーザーへ提供するサービス面も柔軟に対応できるようになることが期待されます。

　本記事執筆に当たってアドバイスを頂いた日本仮想化技術株式会社執行役員の玉置伸行氏によれば、CI/CDのメリットを享受するには通信事業者の組織も見直して、開発部門と運用部門を一体化するようなアプローチが必要ではないかということであり、通信業界は今後そのような組織体制を含めた競争になっていくのかも知れません。