基地局管理システム開発の発注/外注/依頼/委託方法について

基地局管理システムの発注は、管理対象と責任分界を先に決め、PoCで実機との連携を検証してから本開発へ進む流れで進めます。この順番を踏むと、導入後の手戻りを抑えられます。

▼全体ガイドの記事
・基地局管理システム開発の完全ガイド

基地局管理システムの発注・外注の始め方

基地局管理システムを中心に、基地局・5Gコア、伝送路、アンテナ、電源設備を示した図解。
設備の対象範囲をそろえると、発注時の役割分担を考えやすくなります。

基地局管理システムでは、基地局と5Gコアを扱います。RU(無線部)、DU(分散処理部)、CU(集中処理部)も、そこに含まれます。さらに、伝送路、アンテナ、電源設備も対象に入るため、一般的な業務システムの発注方法をそのまま当てはめられない場合があります。

発注前には、現場の運用課題と導入後のKPIを整理しておきます。「台帳を見たい」「障害の切り分けを速くしたい」「設定変更を自動化したい」のどれを目指すかで、必要な技術と責任が変わります。

管理対象と目的の切り分け

初期範囲を決めるときは、台帳に載せる設備と、システム導入の目的を分けて考えます。

  • 管理対象:基地局の位置、セル、アンテナ、RU・DU・CU、5Gコア、バックホール、SIM
  • 関連情報:機器型番、ソフトウェアバージョン、無線局免許、保守契約、工事履歴を含めます。
  • 導入目的:資産一元化、アラーム集約、性能分析、保守効率化、設定統制、委託先への作業指示のなかから選びます。

対象を広げすぎると、見積もりも膨らみます。そのため、初期リリースで必須となる範囲と、将来拡張する範囲を分けておきます。

制御系と業務管理系の境界

設備状態を表示する業務管理系と、装置設定や通信制御に関わる制御系は、区別して扱います。

  • 読み取り中心:台帳、地図、レポートを扱う場合は、閲覧権限を定めておきます。
  • 制御を含む場合:パラメータ変更やファームウェア更新には、認証、承認、ロールバック、監査ログが必要です。

制御系と業務管理系では、可用性の要件も異なります。業務画面が遅くても無線制御が止まらないように、両者を論理的に分け、操作権限を段階化する前提をRFPに明記します。

ポイント

発注前の判断は、管理対象と目的を分けられているか、制御系と業務管理系の境界を決められているかで見ます。どちらかが曖昧なままだと、必要な技術と責任の範囲が定まりません。

発注形態の選択肢:自社開発・パッケージ・クラウド

形態は、標準機能で早く始めるか、独自業務や既存設備との連携を優先するかで選びます。見出しの「自社開発」は後述のスクラッチ開発・ハイブリッド型、「パッケージ」と「クラウド」は後述のパッケージ・マネージド型に当たります。初期費用に加えて、運用条件も合わせて比較します。

  • 互換性:対応メーカーとAPIの公開範囲
  • 運用範囲:免許・工事の支援や24時間監視が含まれるかを見ます。
  • 拡張と終了:局数増加時の単価と、契約終了時のデータ返却

短期導入に向くパッケージ・マネージド型

設備台帳、監視、性能ダッシュボード、標準レポートを早く導入したい場合は、パッケージやマネージドサービスが候補になります。

設備、免許支援、構築、監視、保守をまとめて任せる一括委託の形をとれば、専門人材が少なくてもPoCを始められます。

NTTビジネスソリューションズは、要件定義から運用保守までの範囲を示しています。免許取得支援や施工も、その範囲に含まれます。一方で、独自画面や複雑な既存連携は追加費用になりやすいため、標準機能と個別開発の境界を見積書で確かめます。

独自要件に向くスクラッチ開発・ハイブリッド型

独自業務や深い連携、厳格なデータ所在要件がある場合は、スクラッチ開発かハイブリッド型が適しています。

  • 独自要件:複数メーカーのアラーム相関、独自の工事・保守業務への対応
  • 既存連携:GIS・ITSM・ERPとの深い連携を設計します。
  • 開発範囲:監視・認証・チケットは標準部品を使い、基地局固有の差分を開発します。

標準部品を組み合わせるこの方法なら、初期費用と将来の保守負担を抑えられます。RANの仮想化やオープン化も進んでおり、2025年にはNECがO-RAN仕様準拠のvRANソフトウェアを商用化しました。

ただし、標準に準拠していても、実機同士の相互接続が保証されるとは限りません。そのため、RFPには実機接続試験と、不具合時の切り分け責任を含めておきます。

局数と運用体制による発注範囲の分け方

発注範囲と運用条件は、検証する局数と継続運用の規模に合わせて設計します。

  • 1〜2局の検証:共有コアや短期レンタルで、管理画面、アラーム、性能データ、GIS、チケット連携を試します。
  • 数十局以上の運用:冗長化、データ保持、監視センター、現地対応、部品在庫、夜間作業、災害復旧を含めます。

発注単位を設計するときは、局数に加えてセル数や装置メーカー数、連携先数、監視時間帯も考慮します。

ポイント

形態は、初期費用だけでなく、局数や独自要件、契約終了時のデータ返却まで含めて比べると迷いにくくなります。

RFPと要件整理の決めごと

RFPに記載する設備・連携、既存システム、性能・利用者、成果物の4領域を並べた図解。
4領域の情報がそろうと、各社の提案範囲を同じ条件で比べられます。

RFPは、各社が同じ条件で比べられるように、業務の目的と現状の制約、期待する成果、提案範囲を示す資料です。設備構成と業務フローを示して読み取り系と制御系を区別しておくと、提案と見積の精度が上がります。

RFPに記載する設備・データ・利用者・成果物

提案の前提をそろえるには、設備や連携先、既存システム、性能と利用者、成果物の4つを、各社が同じ粒度で見積もれるように書いておく必要があります。

  • 設備・連携:局数と増設計画、装置名・型番・メーカー、接続プロトコル、監視基盤
  • 既存システム:GIS、ITSM、ERP、データレイクなどの連携先を示します。
  • 性能・利用者:収集間隔、リアルタイム性、保存期間、利用者数、権限ロール
  • 成果物:要件定義書、基本設計書、詳細設計書、接続仕様書、テスト計画・結果、運用・教育資料、ソースコード、API仕様、ログ出力、移行手順を指定します。

可用性やバックアップ、災害復旧目標、監査ログも要件に含めます。さらに、画面や帳票の例を添えると、提案範囲をそろえやすくなります。

現場のKPIと障害フローの要件化

導入効果は、画面数の多さではなく、現場の運用がどう変わったかで測ります。現状値を押さえておかないと、納品後に効率化を判断できません。

  • 時間・復旧:検知から一次切り分けまでの時間とMTTR(平均復旧時間)を測ります。
  • 障害対応:重複アラーム削減率と現地出動回数を追います。
  • 通信品質:セル稼働率、ハンドオーバー成功率、SLA違反件数
  • 作業:設定変更時間と各工程の承認状況を確認します。

障害対応の流れは、障害発生から検知・通知、原因候補の提示、現地作業までを一つの図にまとめます。さらに、復旧確認から顧客報告までも同じ図に入れます。そのうえで、誰がいつ承認するかもRFPに落とし込みます。

免許・通信の秘密・セキュリティの初期要件

ローカル5Gなどを扱う場合は、無線局免許と技術基準、電波利用料を確認します。設置場所、工事、保守の担当範囲も確かめます。

通信ログや位置情報、端末情報を扱う場合は、通信の秘密や個人情報、委託先の監督を踏まえる必要があります。そのうえで、収集目的と閲覧権限を決め、保存期間と削除方法も定めます。

セキュリティ要件は、アクセス制御、監査、運用対策に分けて整理します。

  • アクセス制御:多要素認証、管理ネットワーク分離、最小権限を定めます。
  • 監査・保護:操作ログの改ざん耐性、脆弱性・パッチ管理、秘密情報の保管を含めます。
  • 継続運用:バックアップとSIEM・SOC連携を要件に入れます。

経済産業省は2026年3月にサイバーインフラ事業者向けガイドラインを策定しています(出典:経済産業省「サイバーインフラ事業者に求められる役割等に関するガイドライン」、2026年)。このガイドラインは、発注者と受託者の役割を確かめる材料になります。

ポイント

RFPは、提案者が同じ前提で比べられる具体性があるかを基準にします。現場のKPIや障害フローまで要件に落とし込めていれば、納品後に効果を判断できます。

契約形態と責任分界の決め方

企画・PoC、本開発、継続的な監視・保守では、契約の性質が異なります。そこで、発注者と開発会社、通信設備メーカーに加えて、現地工事会社の担当も明確にします。

責任分界が曖昧だと、アプリから回線までのどこで問題が起きたかを切り分けられず、障害復旧が遅れます。

企画・要件定義は準委任、本開発は請負が基本

工程の性質に合わせて、準委任、請負、月額サービスを組み合わせます。

  • 企画・PoC:実機の制約や利用部門の要望に合わせ、作業時間や役割を定める準委任契約が適する場合があります。
  • 本開発:仕様、納期、検収、成果物が固まれば請負を検討します。
  • 運用保守:監視・保守を月額サービス契約に分ける構成もあります。

契約の名称より中身を見ます。成果物と検収、瑕疵対応の条件に加え、変更手続きや再委託の条件も確かめます。

SLA・障害対応・変更管理の数値合意

保守契約では、監視から変更手続きまでの流れを具体化します。

  • 対応時間:監視時間帯、受付方法、一次応答、切り分け開始の時間を定めます。
  • 復旧と保守:暫定復旧、恒久対策、現地駆け付け、月次報告、計画停止、バックアップ、災害復旧の目標を定めます。
  • 変更手続き:理由、影響、追加費用、納期、承認者を記録します。

「24時間監視」という表記では、アラーム受付だけなのか、原因分析や現地手配も含むのかが読み取れません。そのため、重大度別の応答時間と、発注者・受託者・設備メーカーの連絡経路を一覧にします。

API・ログ・データ返却と解約時の移行

委託先を変える場合に備えて、契約と選定の段階で確認しておく項目を整理します。

  • 契約条件:データの所有権・利用権、API利用条件、ログ取得、設定情報の形式、ソースコードの扱いを定めます。
  • データ返却:クラウド型では、設備台帳、アラーム・性能・作業履歴、ユーザー・権限情報の返却形式と期限を確認します。
  • 選定時の確認:再委託先、海外拠点でのデータ処理、脆弱性の通知期限、サポート終了時の代替案を見ます。

データを独自形式でしか取り出せないと、将来の移行費用が高くなります。

ポイント

判断の目安は、障害時にどこを誰が受け持つかを、契約書と見積書で同じ言葉で示せているかです。曖昧な箇所が残るほど、障害復旧の遅れにつながります。

基地局管理システムの費用相場の目安

管理ソフト単体の費用目安を、基本管理、分析・連携、高度運用の機能範囲別に示した図解。
機能の範囲が広がるにつれ、推定費用の帯も上がります。

基地局管理システムの費用は、管理ソフト単体か、基地局から運用までを含むかで大きく異なります。管理ソフト単体の公開価格は少ないため、見積もりでは範囲を分けて考えます。

次の金額は、公開価格と類似するネットワーク監視・資産管理・業務SIから推定した目安です。局数や装置構成によって変わります。

規模別の初期費用とランニング費用の目安

局数や構成ごとの推定費用と期間を並べると、規模による違いが見えてきます。

  • 1局のPoC:共有コアと標準監視なら初期200万〜1,500万円、月額30万〜40万円前後、1〜3か月が目安です。
  • 1〜2局:管理画面、API、ネットワーク構築込みで初期2,000万〜5,000万円、年間300万〜1,000万円、3〜6か月程度です。
  • 数局・オンプレミス:コアや既存SI連携込みで初期5,000万〜1億円、年間1,000万円前後、6〜12か月程度です。
  • 10局以上:基幹連携、冗長化、24時間監視、現地保守込みで初期1億〜数億円以上、年間数千万円以上、12〜24か月以上になる可能性があります。

いずれも一般的な見積もりから推定した値です。比べる際は、RFPの前提条件をそろえてください。

公開価格の読み方(ネットワーク込みの参考値)

公開価格の例は、管理ソフト単体の価格と混同せず、ネットワーク構成込みの金額として読みます。

  • NTTビジネスソリューションズ:ローカル5G最小構成はサブスクリプション型が月額約35万円からです。一括型は初期約1,270万円から、月額約13万円からです。
  • NTTBP:屋内・RU1台の標準例は、5Gコア・CU・DUなどが月額306,900円です。
  • 機器・工事:RU・アンテナは月額26,400円、付属品・設置工事は初期約220万円から、5年総額は約2,200万円です。

これらは、コアや無線機器に加えて、アンテナ、工事、運用に関わる価格です(出典:NTTビジネスソリューションズおよびNTTBPの公開料金、2026年確認)。

費用を左右する見積変数

管理ソフト単体の機能範囲によっても、費用の推定幅は大きく変わります。

  • 基本管理:台帳、権限、ダッシュボード、API連携なら500万〜1,500万円程度です。
  • 分析・連携:アラーム相関、性能分析、ITSM・GIS連携まで含めると1,500万〜5,000万円程度です。
  • 高度運用:マルチベンダー制御、24時間運用、冗長化、AI分析では5,000万〜2億円以上となることがあります。

上記は類似システムからの推定で、基地局とアンテナは別費用です。さらに、コアや伝送、設置工事も別費用になります。

比較の前提は、構成条件と連携条件をそろえることです。構成では局数やセル数、装置メーカー数を、連携ではプロトコルや連携先を合わせます。保存期間や監視時間、現地作業も、そろえる対象です。さらに、テスト環境や教育、移行、保守まで含めて比べます。

ポイント

金額を比べるときは、ネットワーク込みか管理ソフト単体かを先に分け、局数や装置構成をそろえてから見ます。前提がそろわない金額同士では、価格差の理由が分かりません。

委託先選定と見積比較の確認事項

委託先は会社名や価格だけでなく、基地局管理のどこを担えるかで評価します。通信設備会社やネットワークSIer、業務システム会社などを組み合わせる方法もあり、クラウド事業者や監視・保守会社と組むケースもあります。

複数社から同じ条件で提案を受け、技術と体制、費用、契約条件に分けて採点します。

無線・クラウド・業務SI・運用の経験の評価軸

提案の評価軸を分けると、各社が対応できる技術と運用範囲を把握できます。

  • 無線接続:RU・DU・CU・5Gコア・伝送機器のメーカーと接続実績を確認します。
  • 標準技術:O-RAN、NETCONF/YANG、REST API、TM Forum Open APIへの対応を見ます。
  • 業務連携:GIS、ITSM、契約・資産管理、データ基盤との連携や、工事・点検・部品交換の業務設計力を確かめます。
  • 運用体制:24時間監視、現地保守、障害連絡、教育、引き継ぎの範囲を比べます。

見積書の作業範囲・前提・除外項目の比較

見積書を作業別に分けて読むと、価格差の理由や追加請求の範囲が見えてきます。

  • 作業項目:要件定義、設計、開発、ライセンス、クラウド、機器、回線、工事を分けます。
  • 導入作業:データ移行、テスト、教育、保守も別項目にします。
  • 数量・条件:局数、画面数、API数、装置数、作業時間、納期、検収条件を記します。

「一式」と書かれた項目は、含まれる作業と追加請求の有無を確かめます。税や出張費、夜間作業は、見積に入っているかを見ます。現地調査と免許申請、予備機、保守時間も、同じ観点で押さえておきます。

データ移行、性能試験、セキュリティ診断は、見積から抜けやすい費用です。

PoCの検証方法と合格条件

提案書では、完成後の画面だけでなく、PoCで確かめる項目と合格条件を見ます。

  • アラームと性能:異なるメーカーのアラームを一つのチケットに集約し、指定間隔でデータを取れるか試します。
  • GISと制御:地図で影響範囲を示し、承認付き設定変更とロールバックを確認します。
  • 合格条件:復旧報告までの時間、データ欠損、誤アラーム、操作ログ、障害時手順を数値または判定条件で定めます。

合格条件では、「動いた」ことに加えて、数値や判定条件まで決めておきます。さらに、デモ環境も実際の接続機器と同じ条件で動くかを確かめます。

発注後の開発・導入の進め方

発注後は、要件定義とPoCから始め、設計・開発、テスト、段階リリースを経て、運用改善へ進みます。

まずは代表局や障害パターンで、現場作業者と監視担当者の利用を確かめ、そのあとで対象を増やします。なお、試験や教育を削ると、稼働後の障害対応や追加開発で費用が膨らむおそれがあります。

要件定義とPoCでの現状確認

要件定義では現状を洗い出し、PoCで実機との連携と異常時の動作を確かめます。

  • 現状調査:設備台帳、監視、メーカー、プロトコル、既存API、免許・工事・保守データ
  • 運用要件:利用者権限と障害フローの整理
  • 実機検証:1〜2局でアラーム、性能、地図、チケット、設定変更の安全性を試します。

装置停止や通信断、電源断のような異常系に加え、データ遅延や重複アラーム、誤設定も試験します。そのうえで、差分を本開発の要件に反映すると、稼働後の手戻りを抑えられます。

本番前の性能・障害・セキュリティ・移行の試験

本番前には、機能に加えて性能や復旧、権限を試します。セキュリティとデータ移行も、本番前に確かめておく項目です。

  • システム試験:負荷、フェイルオーバー、バックアップ復元、権限、操作ログを試します。
  • 障害・安全性:脆弱性診断、通信断、装置停止を想定した試験を行います。
  • 移行:項目対応、欠損データ、重複統合、移行後の照合方法を決めます。

Excelや紙、複数の監視ツールから台帳や履歴を移す場合は、移行方法もあらかじめ定めます。運用担当者には、画面の説明に加えて、障害シナリオを使った訓練を行います。

段階リリースとKPI・運用契約の見直し

代表局、少数局、全局の順に対象を広げながら、各段階で運用実績を確かめます。

  • 監視指標:アラーム誤検知率、データ欠損、利用者の問い合わせを確認します。
  • 運用指標:MTTR、現地出動回数、設定変更の承認時間を測ります。
  • 未達時の見直し:監視ルール、責任分界、教育、保守時間帯、装置設定を見直します。

2026年1月、ソフトバンクとエリクソンはAIによるMassive MIMO基地局のカバレッジ最適化を発表しました。大阪・関西万博の実証で下りスループットが76.9Mbpsから95.5Mbpsへ約24%改善したとされています(出典:ソフトバンク・エリクソン、2026年)。高度な自動化を検討する場合は、先にベースラインと評価条件を定めてから、効果を測ります。

よくある質問

発注時に生じやすい疑問として、費用や期間、運用責任、既存設備との互換性などに答えます。

基地局管理システムの発注費用を抑える方法はありますか?

まず1〜2局のPoCで効果を確かめ、全局・全機能の開発は段階を踏んで進めます。検証対象には、台帳やアラーム、性能といった基本機能に加えて、GISやチケット連携も含められます。

ネットワーク込みと管理ソフト単体の費用は分けて考え、標準機能を優先します。独自開発は、KPIに直結する部分に絞ります。

局数拡張やAPI、データ返却を初期要件から外すと、高い移行費用が生じることがあります。そこで、局数拡張やAPIに加え、セキュリティや運用教育も含めて、削る範囲と残す範囲を明確にします。

既存の監視システムやメーカーが複数あっても外注できますか?

外注できます。提案の前に、メーカーと型番、ソフトウェアバージョンを開示します。監視プロトコルとAPI、ライセンス、ログ取得方法も、あわせて示します。

すべての装置を同じ粒度で表示できるとは限りません。そこで、第一段階は読み取りとアラーム集約、第二段階は性能分析や設定変更と、優先度を分けて進めます。

接続できない装置が見つかった場合の代替監視や追加費用、納期、責任分界は、契約前に合意します。

通信設備会社とシステム開発会社のどちらに頼むべきですか?

免許や基地局、5Gコアまで任せるなら、通信設備会社やネットワークSIerが向いています。伝送や現地工事、24時間保守まで含める場合も、この考え方が当てはまります。

業務システムや工事・保守フローを柔軟に組み替えるなら、業務システム開発会社との連携が適します。GISやITSM、データ分析も対象に含めるなら、この形を検討します。

会社の種類で決めるよりも、体制責任者や障害時の窓口、API・データ管理者、検収責任を、提案書と契約書で明確にしておきます。

基地局管理システムの外注で法規制に注意する必要はありますか?

必要です。ローカル5Gでは、無線局免許や技術基準、設備構成に応じた申請や運用を確かめます。

通信ログや端末情報を扱う場合は、通信の秘密や個人情報、委託先の監督を確かめます。あわせて、安全性や信頼性に関する制度やガイドラインも更新されるため、最新の内容を見ておく必要があります。

業態や設備、データ、委託範囲に応じて、法務・セキュリティ担当と受託先に確かめます。一般論だけで適用の関係を断定せず、案件ごとに所管官庁や専門家へ相談します。

まとめ

基地局管理システムの発注では、まず管理対象と目的、KPI、制御系と業務管理系の境界を決めます。発注形態は、局数や装置メーカー、既存連携、自社の運用体制に合わせて選びます。

RFP・契約・見積の条件そろえ

RFPには、設備やデータ、連携先に関する要件を記載します。性能や利用者に関する要件に加えて、セキュリティや成果物、保守条件も含めます。

見積もりは、開発や機器、工事に分けて示します。クラウドや移行、教育、運用の費用は、別の項目として立てます。価格とあわせて、将来の局数拡張や委託先の変更に対応できるかを評価すると、長期的なコストとリスクを抑えられます。

契約では、準委任や請負、保守サービスの区分と、SLA、障害時の責任を確かめます。再委託やAPI・ログ・データ返却、解約時の移行支援も、その範囲に含めます。

小規模検証から本番・高度化まで

PoCから段階導入、運用改善へと進みながら、現場の効果を継続して確かめます。

  • 小規模検証:1〜2局でアラーム、性能、GIS、ITSM、設定変更、異常系を試し、合格した範囲から局数を増やします。
  • 効果測定:導入後はMTTR、アラーム削減率、現地出動回数、セル稼働率、設定変更時間、SLA違反件数を測ります。
  • 運用改善:画面の納品後も、通信品質と保守業務が改善するまで、発注者と委託先で運用を見直します。

▼全体ガイドの記事
・基地局管理システム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。