—·
全てのコンテンツはAIによって生成されており、誤りが含まれる可能性があります。ご自身でご確認ください。
OCUDUが掲げる共通のオープン基盤により、RANオートメーションはデモから“運用の仕組み”へと組み替えられる。SON、スペクトラムのワークフロー、ゼロタッチ、そして監査可能なRICループが焦点だ。
2026年3月、Linux Foundationは、OCUDU Ecosystem Foundationの設立を発表した。目的は「オープンソースのAI-RAN革新を加速すること」であり、OCUDUを、オープンなCU/DUソフトウェアのリファレンス・プラットフォームとして位置付けている。
（linuxfoundation.org
事業者にとって重要なのは、新しいデモではない。自動化が、複数ベンダーにまたがって“統制されたシステム”として実行できるかどうかだ。2026年のプロダクション品質のRANオートメーションは、オーケストレーションのインターフェース、ライフサイクルの流れ、そしてセキュリティのあり方が、十分に標準化されているかに左右される。つまり、大規模な変更のオーケストレーションだけでなく、ロールバックや監査が現実に回ることが条件になる。
OCUDUの「リファレンス・プラットフォーム」という枠組みは、分解されたコンポーネントにまたがって自動化を拡張する際に事業者が直面するボトルネックを狙い撃ちしている。CU/DUソフトウェア基盤が、自動化をどれだけ再現可能にし、テストでき、統制（ガバナンス）できるかが、その信頼性を決めるからだ。
同時に、O-RAN WG6は、SMO（Service Management and Orchestration）とO-Cloudの間でのライフサイクル・コレオグラフィ（段取りの舞台裏）を形式化してきた。共通性の柱は、O2 APIの整合だ。
（public.o-ran.org
実務者は何をすべきか： OCUDUやO-RAN WG6を「標準化の進捗」として消費するのではなく、明確な意思決定の材料として扱うべきだ。あなたのオートメーション・ツールチェーンは、今日から安定したオーケストレーションとライフサイクルのインターフェースを“話せる”のか。それとも、マルチベンダー展開のたびに、隠れた統合コストや変更統制（チェンジコントロール）のリスクが積み上がるのか。
OCUDUはLinux Foundationによって、ニュートラルなガバナンスの下で「ポータブルでオープンソースのCU/DUソフトウェア・スタック」を提供し、無線分野の革新を加速するオープンソース・イニシアチブとして説明されている。
（linuxfoundation.org
起点の違いが効いてくるのは、ゼロタッチのプロビジョニングやライフサイクル管理が、投入するソフトウェア成果物の決定性（どこでも同じ挙動に近づけられる性質）にしか依存しないからだ。もし自動化パイプラインが、拠点間でも、そしてベンダー間でも、CU/DUの挙動を一貫して保証できないなら、必要な瞬間に止まる。拡張（スケールアウト）、ソフトウェア更新、そしてロールバックの局面こそが、その“止まってはいけない”場面だ。
OCUDUのエコシステム型アプローチは、「アダプタによる統合」から「共通の基盤コンポーネント」へと移すことで、ばらつきを減らすことを狙っている。
また、2026年3月のOCUDUアップデートは、CU/DU層を越えた勢いとも結びついている。たとえば、OCUDUの初回リリースに関する報告では、Linux Foundation配下でのsrsRAN CU/DUに対する移行の取り組みや、ニュートラルなガバナンスへの移行が示されている。
（the-mobile-network.com
実務者は何をすべきか： RANオートメーションのロードマップを書くとき、OCUDUを「ガバナンスのプリミティブ（基礎要素）」として扱ってほしい。「自動化対応」の基準に、再現可能なCU/DUビルドの来歴（プロベナンス）と、ライフサイクル互換性を据えることだ。後回しにしないことが重要になる。
RANオートメーションが「可能かどうか」を延々議論するのをやめるには、事業者が目で見て理解できる4つのステップに翻訳するのが有効だ。変更統制委員会、セキュリティチーム、そしてSREグループが、すぐに認識できる形に落とし込む。
SON（Self-Organizing Networks）は、ネットワークの自己設定と自己最適化のための自動機能群として標準化されている。3GPPはSONを、自己設定と自己最適化を可能にし、さらにセルが失敗したときに隣接基地局が再構成する“回復に近い振る舞い”も含むものとして説明している。
（3gpp.org
「SONオートメーション」の展開で見落とされがちなのが、運用上のロールバックだ。SONの変更は、カバレッジ、干渉、ハンドオーバーの挙動に影響する無線パラメータを動かす。マルチベンダー環境では、少なくとも次が必要になる。（a）パラメータ範囲のガードレール、（b）設定のバージョン管理されたロールバック経路、（c）SONのアクションが、別の問題を持ち込む形で目標KPI（重要業績評価指標）を“改善した”のかを確認するための観測可能性（オブザーバビリティ）だ。
ロールバックの要件は、概念から手順へ翻訳しなければならない。最低限、すべてのSON変更イベントに次の4点を結び付けるべきだ。
決定論的（デターミニスティック）であることが重要なのは、「最後に動いていたものへ戻す」は、その最後に動いていたスナップショットの質にしか依存しないからだ。もしSONワークフローが特定の設定バージョン（保存されたパラメータ一式、あるいはベンダー定義の設定改訂など）を指し示せず、同じライフサイクル経路で再適用できないなら、ロールバックはベストエフォートの手作業介入になる。
KPIにも規律が必要だ。典型的なSONの失敗は、微妙なズレでは済まない。たとえば、過度に攻めた隣接リバランスは、カバレッジ指標を改善しながらも、ハンドオーバー失敗率を押し上げたり、ピンポン・ハンドオーバーを増やしたりする。実務者は、影響を受けるセルに対して、たとえば次のようなKPIファミリーを明示的に要求すべきだ。ハンドオーバー成功率、ハンドオーバー失敗率、RRCセットアップ成功率、PRB利用 / 干渉の代理指標。さらに、ロールバックのトリガーとなる時間窓（例：「X分/時間以内に、いずれかのKPIが閾値を超えて悪化するなら」）も設定する。ここで重要なのは、閾値そのものではない。KPI契約とトリガー論理が、オーケストレーション層で符号化され、監査可能であることが求められる。
3GPPはリリースをまたいでSONの能力も進化させている。たとえばEricssonは、3GPP Release 17における強化SON機能について、ユーザー機器や他のネットワークノードから必要データを収集し、それを用いるよう設計されたことを説明している。
（ericsson.com
実務者は何をすべきか： SONは、承認・展開・検証・ロールバックという明示的な状態を持つ統制されたワークフローとして実装する。ただし、証拠（エビデンス）を要求してほしい。（1）SONの各アクションに紐づく保存済みのパラメータ/設定改訂参照、（2）名称付きメトリクスと評価時間窓を含むKPI契約、（3）展開に使ったのと同じインターフェース経路を通じて自動的に巻き戻せるロールバック・トリガー（オペレーターの手順書頼みではないこと）。
自動化されたスペクトラム管理は、周波数を選ぶことだけではない。測定フィードバックに結び付いた、ポリシー駆動の意思決定である。SONが近隣やカバレッジの最適化に寄りやすい一方で、スペクトラムの自動化は、資源配分の調整を、ポリシーと測定フィードバックのループで行う傾向がある。
「閉ループのスペクトラム」における中核的な運用リスクは、測定がノイズを含みうること、規制上の制約が管轄ごとに異なること、そしてリプレイ可能な意思決定の痕跡がなければ、瞬間的な制御アクションが不可逆になり得ることだ。したがってプロダクションでは、スペクトラム・オートメーションのループを3層で定義すべきである。テレメトリ入力、ポリシー制約、アクチュエーション（制御）目標。それぞれにインターフェースレベルのトレーサビリティを持たせる。
テレメトリ入力には来歴（プロベナンス）を明示する必要がある。どの測定値を使うのか（また、その粒度はどれか）。どう正規化するのか（キャリアごと、セルごと、時間スライスごとなど）。そして、どれくらいの速さで制御層に伝わるのか。ポリシー制約には、**安全エンクロージャ（例：送信電力の変更率の上限、禁止されたバンド/チャネル一覧、干渉回避のルール）**と、**規制上の境界（現地のスペクトラム割当や、事業者固有の共存義務など）**の両方を含めるべきだ。事業者が制約をすでに理解していても、オートメーションは後から監査できる形で符号化されていなければならない。特に、制御判断が争点になる場合（例：「14:05にチャネルXが選ばれたのはなぜか」）では、その重要性が跳ね上がる。
アクチュエーション目標は、境界があり、かつ可逆であるべきだ。「その場しのぎの設定変更でしか“調整”できない」ループは、監査可能なロールバックに苦しむ。必要なのは、バージョン管理されたオーケストレーション操作（デプロイ/更新/ロールバック）に対応する、スペクトラム制御アクションである。同じコマンドをリプレイしたり、巻き戻したりできるようにする。実務的には、オーケストレーション/制御層が、意思決定ID、ポリシーバージョン、使用したテレメトリのスナップショット、アクチュエーションコマンドの結果を記録できる必要がある。
O-RANのアーキテクチャが関係するのは、閉ループ制御をRICベースの制御層として位置付け、そこでポリシーとテレメトリを組み合わせて最適化を導けるからだ。ETSIのO-RAN文書は、O2インターフェースがSMOとO-Cloudをリソースおよびデプロイ/ライフサイクル管理で接続し、さらにRICとオーケストレーションの周辺機能を説明している。
（etsi.org
つまり、スペクトラム・オートメーションのパイプラインには次の標準的な道筋が必要になる。
（1）測定と障害データをオーケストレーション/制御層に取り込む
（2）ポリシー制約（安全エンクロージャ、規制上の境界）を適用する
（3）バージョン管理と監査トレイル付きで設定変更を反映する
実務者は何をすべきか： スペクトラム自動化を「ポリシー＋測定＋オーケストレーション・インターフェース」の問題として扱い、ベンダーに次を明確化させてほしい。（1）各意思決定に投入されるテレメトリ・ストリーム、（2）適用されたポリシーバージョンと制約セット、（3）各アクチュエーションがライフサイクル/バージョン付きコマンドを通じてどのように巻き戻せるのか。
ゼロタッチ・プロビジョニングとは、拠点のオンボーディングや設定変更を、人手介入を最小限にして実行できるという運用上の約束だ。O-RANの文脈では、SMOとO-Cloudの間でのライフサイクル管理の相互作用が、O2 APIを介して実装される。
O-RAN WG6のミッションは、「ライフサイクルの流れと、SMOとO-Cloud間のO2 APIの共通性」を明確に狙っている。分解（ディスアグリゲート）されたマルチベンダーRANには、管理対象エレメントの発見、ライフサイクル管理、ネットワーク機能をまたいだオーケストレーションに向けて、共通でベンダー非依存のAPIが必要だと説明している。
（public.o-ran.org
具体的な実装ガイダンスとしては、O-RAN Software CommunityのSMO O2に関するドキュメントがある。O-RAN SC SMO O2プロジェクトのドキュメントサイトは、APIドキュメントへの参照先や、構造化されたO2インターフェースを提供している。
（docs.o-ran-sc.org
また、事業者はO-RANによる「ゼロタッチ」の成果についても公に議論している。Vodafoneは、顧客の接続を「たった1クリック」で提供するためのOpen RANオートメーションに取り組んでいると述べた。「E2E Distributed Zero Touch Deployment」というコンセプトを示し、新規拠点とサービスのオンボーディング時間を「75%」改善できることを期待していると説明している。
（vodafone.com
実務者は何をすべきか： オンボーディングとライフサイクルのステップを、O2で公開されるライフサイクルAPIに対応付けて設計することだ。もしあなたの「ゼロタッチ」プロセスが、特定のライフサイクル操作やインターフェース呼び出しまで追跡できないなら、監査にもマルチベンダーの拡張にも耐えられない。
O-RANのRIC（RAN Intelligent Controller）モデルは、時間スケールの違いによって一般に分かれて語られる。非リアルタイム（最適化やアシュアランスのような、より遅い閉ループ操作に使う）と、ニアリアルタイム（高速な無線リソース制御に使う）だ。ETSIの文書は、SMOとRICの機能、およびO2に関連するサービスが、デプロイとライフサイクル管理とどう関係するかを述べている。
（etsi.org
運用上の課題はガバナンスである。ニアリアルタイムの制御変更は、無線パラメータを素早く動かす。非リアルタイムの制御は、サービス挙動や最適化ポリシーをよりゆっくり変える。いずれにせよ、オートメーションは監査可能でなければならない。どのポリシーが意思決定したのか、どのテレメトリを使ったのか、どのコンポーネントに命令したのか、そしてどのロールバック経路が用意されているのか。これらが追跡できる必要がある。
重要な前提条件の一つが、層をまたいだインターフェースの整合だ。WG6は、オーケストレーションやライフサイクル管理が一貫して振る舞えるよう、O2 APIの共通性を強調している。
（public.o-ran.org
さらに、運用の設計図やプラットフォーム説明は、RICベースのオーケストレーションをSMOアーキテクチャへ組み込めることも示している。Ericssonのホワイトペーパー「SMO enabling intelligent RAN operations」では、「rApps」が非RT（非リアルタイム）RICの機能を活用することに触れ、O2が、インベントリ、モニタリング、ソフトウェア管理、ライフサイクル管理などのO-Cloudのリソース管理をオーケストレーションすることを支えると説明している。
（ericsson.com
実務者は何をすべきか： 制御ループは、ポリシーの識別（アイデンティティ）、バージョニング、そしてデプロイ/ロールバックの意味論（セマンティクス）を明示してガバナンスすること。そして監査トレイルを、後から辻褄合わせをする“コンプライアンスの儀式”ではなく、第一級のインターフェース要件として扱うべきだ。
Vodafoneは、Open RANオートメーションが「ワンクリック」で拠点とサービスのオンボーディングを可能にすることを説明し、新規拠点とサービスをデプロイする時間で「75%の改善」を目標としていると主張している。
（vodafone.com
これは見出し以上の意味を持つ。Vodafoneは、オートメーションが人手による“変更のボトルネック”を減らすと見込んでいる。マルチベンダーのネットワークコンポーネントを展開する際に必要になる時間と承認が、その源泉だ。さらに、孤立した無線設定スクリプトではなく、エンドツーエンドのオーケストレーション・インターフェースとの整合が示唆されている。
自社の展開で確認すべきこと： O2のライフサイクル呼び出しを標準化する前後で、「最初のオンエアまでの時間（time-to-first-on-air）」と「変更承認までの時間（time-to-change-approval）」のベースラインを比較してほしい。Vodafoneの言及は目標である。ゆえに社内で提示できる証拠は、監査可能な制御指標（コントロール・メトリクス）であるべきだ。
Rakuten Symphonyは、自社のRICプラットフォームを、Rakuten Mobileの日本における4G/5GのOpen RANネットワークへ導入したと発表した。AI駆動の最適化と意思決定を可能にし、消費電力を「約20%」削減できるとしている。
（symphony.rakuten.com
続くRakuten Symphony/Rakuten Mobileの別リリースでは、RICへのインターフェースを通じてアンテナ利用を構成することで、AI/MLモデルがエネルギー削減を「最大25%」可能にするデモが報告されている。
（symphony.rakuten.com
これらは合わせると、RICベースの自動化が、「エネルギーモデルの実験」から「実運用ネットワークの挙動に影響する制御プレーンの操作」へと移行し得ることを示している。
重要な制約： これらはベンダーが報告した成果である。事業者は独立した測定方法論を求めるべきだ。ベースラインがどう定義されたのか、そして削減には冷却や輸送、トラフィック構成といった関連する運用変更が含まれているかどうかまで含めて確認する必要がある。証拠は方向性を示すものであって、事業者間で自動的に比較可能になるわけではない。
Deutsche Telekomは、マルチベンダーの試験結果として、非リアルタイムRICとrAppのコンセプトを、分解されたRANを自動化・最適化するために提示した。O-RAN SCの非RT RICベースのソリューションを用いたこと、そして独自に開発したSMOフレームワークを使ったことも説明している。さらに、この発表では非RT RICが、閉ループ自動化のためのサードパーティアプリケーションを可能にするものとして位置付けられている。
（telekom.com
この試験は、ガバナンス層に関するものだ。非リアルタイムのループは、ポリシーや最適化設定を変える。マルチベンダーという枠組みが重要なのは、あなたのプロダクションの自動化チェーンが、あるコンポーネントのベンダーやバージョンが変わっても耐えられる必要があるからだ。
Capgeminiは、Deutsche Telekomと合意したことを発表した。目的は、インテリジェントRANオートメーションのための統一されたオープン・プラットフォームを設計すること。明確に、Deutsche Telekomの欧州セグメント向けに、O-RAN環境とレガシーRAN環境の双方で一貫して動作するSMOプラットフォームを設計すると述べている。
（capgemini.com
また、発表では、能力がRICのデプロイメントの上に構築されていること、そしてSMOが、Open RANとレガシーの無線アクセスネットワーク環境の両方にまたがってオートメーションを提供することも述べている。
（capgemini.com
RANオートメーションの論評に入る理由： これは“事業者の経済性”のサインである。複数世代のネットワークや複数ベンダーにまたがって協調できないなら、統合作業と変更統制のボトルネックにより、想定していた削減効果を失ってしまう。
事業者がコストを下げるのは、AIが存在するからではなく、人の介入が減るからだ。オートメーションの取り組みでは、経済性の帳簿（レジャー）に繰り返し現れる費用項目は通常3つに集約される。（1）手作業の設定とプロビジョニング、（2）設定変更に伴う変更統制のレビュー時間、（3）マルチベンダーのコンポーネントが入れ替わる際の統合回帰テスト。
O-RAN WG6がライフサイクルの流れと共通O2 APIに注力するのは、バケット#1と#3を直撃するためでもある。管理対象エレメントの発見、ライフサイクル管理、そしてオーケストレーションを、ベンダー非依存で実現することを狙っているからだ。
（public.o-ran.org
一方で、Vodafoneの「ワンクリック」目標やRakutenの報告は、実務者が運用コストと結び付けられるROI（投資対効果）の物語を提供する。Vodafoneが期待する「75%改善」のオンボーディング時間は、ワークフロー・オートメーションが人員計画とスケジューリングの課題をどう変えるかを示す指標になる。
（vodafone.com
Rakutenの「約20%」の消費電力削減は、RIC主導の自動化が、プロダクションで測定できるエネルギー効率のレバーになり得る一例だ。
（symphony.rakuten.com
プログラムの経済性を考えるための実務的な方法は、自動化を次の3つの運用KPIに翻訳し、ガバナンス会議で説明できるようにすることだ。（1）変更までの時間（変更統制のリードタイムを含む）、（2）ロールバックまでの時間とロールバック成功率、（3）自動化ワークフローによって節約できた運用時間を、拠点数で正規化した値。
実務者は何をすべきか： ライフサイクル・インターフェースの標準化に早期投資すること（SMO O2 API、オーケストレーションされたデプロイ経路）。この仕事が、2社目・3社目のベンダーが来ても効果を“持続可能”にする。後になってからでは遅い。
自動化のガバナンスは、しばしば防御的なセキュリティとして扱われる。認証と認可だ。しかし、マルチベンダーRANオートメーションでは、セキュリティの問いがより広がる。必要なのは、自動化を制約されたものにし、検証可能にし、そして復旧可能にすることだ。
O-RANリリース作業と関連レポートは、SMOおよびアプリケーションのライフサイクル管理に関するセキュリティの技術報告を重視してきた。たとえばO-RAN自身のブログであるRelease 3の実装紹介では、アプリケーションのライフサイクル管理、ログ管理、サービス管理、オーケストレーションを含めた脅威とリスク分析のアウトプットを含む「セキュリティ技術報告」が取り上げられている。
（o-ran.org
より直接的には、ETSIの文書がO2インターフェースの役割をクラウドのリソース管理やワークロード管理と結び付け、O2関連サービスをデプロイのライフサイクル管理へと連係させている。ここでは監査可能性が実現し得る。オーケストレーションのアクションが標準化されたライフサイクル・サービスに対応しているなら、一貫した記録が可能になる。
（etsi.org
最後に、O-RAN SC SMO O2のドキュメントやAPIドキュメントの存在は、ガバナンスが「プロセス主導」だけでなく「インターフェース主導」で成立し得るという考え方を補強する。
（docs.o-ran-sc.org
実務者は何をすべきか： すべての自動化機能に、（1）自動化ロジックの識別（アイデンティティ）とバージョン、（2）ライフサイクルAPIへ対応付けた監査可能なオーケストレーション・アクション、（3）ステージングでテストし、プロダクションの変更窓に合わせてリハーサル済みのロールバック、を含めるよう求めるべきだ。
証拠に基づけば、運用上の道筋ははっきりしている。OCUDUとO-RAN WG6の取り組みは、標準化されたライフサイクルとオーケストレーションの仕組みへ向かっている。とはいえ事業者側は、それを実装チェックリストと測定可能な成果へ翻訳しなければならない。
今後の調達とアーキテクチャのサイクルでは、あなたのオートメーション・ベンダーや統合ベンダーに対して、次の3つの成果物を、O-RANのオーケストレーションの仕組みに整合する形で提出することを求めるべきだ。
具体性を持たせるなら、あなたが影響できるアクターはSMOプラットフォームのオーナー、あるいはプライム統合者になる。受け入れ基準をO2インターフェースの挙動と、監査可能なロールバックの意味論に結び付け、あなたのプロダクションで想定するマルチベンダー構成に近いステージング試験のエビデンス提出を要求することだ。こうした要件の標準化方向性は、WG6がO2 APIの共通性とライフサイクルの流れを重視している点と整合している。
（public.o-ran.org
今後6〜12か月は、「自動化デモ」から「ガバナンスできる自動化」へと切り替わる流れが加速すると見込まれる。ただし、その進み方は一様ではない。理由は、インターフェースの標準化には協調した準備が必要だからだ。SMOのO2 APIとライフサイクルのツール群は、プラットフォーム事業者がデプロイするのと同じリリース周期で成熟していなければならない。
現実的な見通しとしては、2026年Q4までに、多くの事業者のプログラムが、制御された形で拠点オンボーディングのエンドツーエンド自動化を実現できるようになる。一方で、自己最適化する無線パラメータのループ（SONやスペクトラム調整）は、より厳格なガードレールと、入念にリハーサルしたロールバックが必要になる可能性が高い。これは、インターフェース層で構造化されているオーケストレーションとライフサイクルの共通化の取り組み方、そしてオンボーディング時間の削減やRICプラットフォームのデプロイを強調する事業者発表の方向性とも整合する。
（public.o-ran.org
意味のあるアクション： O2に整合したライフサイクル監査可能性とロールバックのテスト証拠を、2026年の自動化デプロイにおける契約上のゲートとして組み込むことだ。そうすれば、マルチベンダーのRAN自動化は「約束」から「運用可能なプロダクション・システム」へ変わる。