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

基地局管理システムの発注・外注は、管理対象と責任分界を先に定め、PoCで実機連携を検証してから本開発へ進む方法が失敗しにくいです。

基地局、RU(無線部)、DU(分散処理部)、CU(集中処理部)、5Gコア、伝送路、アンテナ、電源設備まで扱うシステムでは、一般的な業務システムの発注方法をそのまま適用できない場合があります。自社開発・パッケージ・クラウド型サービス・通信事業者やSIerへの一括委託には、それぞれ向き不向きがあります。この記事では、発注形態の選択、RFPと要件整理、契約形態、費用相場、委託先の選び方、見積比較、導入後の運用までを順番に解説します。

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

基地局管理システムの発注・外注は何から始めますか?

基地局管理システムの発注計画を整理するイメージ

基地局管理システムの発注では、いきなり開発会社へ機能一覧を渡すのではなく、現場の運用課題と導入後のKPIを整理することが最初の手順です。特に「基地局の台帳を見たい」のか、「障害の切り分けを速くしたい」のか、「設定変更まで自動化したい」のかで、必要な技術と契約上の責任が大きく変わります。

最初に管理対象と目的を分けて整理します

まず、管理する設備を台帳へ並べます。基地局の位置、セル、アンテナ、RU・DU・CU、5Gコア、バックホール、SIM、機器型番、ソフトウェアバージョン、無線局免許、保守契約、工事履歴などが候補です。そのうえで、目的を「資産情報の一元化」「アラームの集約」「性能分析」「現地保守の効率化」「設定変更の統制」「委託先への作業指示」に分けます。管理対象を広げすぎると見積もりが膨らみますので、初期リリースで必須の範囲と、将来拡張する範囲を分けることが重要です。

制御系と業務管理系の境界を決めます

基地局管理システムには、設備の状態を表示する業務管理系と、装置の設定や通信制御に関わる制御系があります。読み取り専用の台帳・地図・レポートから始める場合と、パラメータ変更やファームウェア更新まで許可する場合では、認証、承認、ロールバック、監査ログ、可用性の要件が異なります。障害時に業務画面が遅くなっても無線制御が止まらないよう、両者を論理的に分離し、操作権限も段階化する前提をRFPに明記します。

発注形態は自社開発・パッケージ・クラウドのどれを選びますか?

基地局管理システムの発注形態を比較するイメージ

発注形態は、標準機能で早く始めたいか、独自業務や既存設備との連携を優先するかで選びます。判断の軸は初期費用だけではなく、対応メーカー、APIの公開範囲、免許や工事を含むか、24時間監視を任せられるか、局数を増やしたときの単価、契約終了時のデータ返却まで含めて比較することが大切です。

パッケージ・マネージド型は短期導入に向いています

設備台帳、監視、基本的な性能ダッシュボード、標準レポートを早く導入したい場合は、パッケージやマネージドサービスが候補です。通信設備、無線局免許の支援、構築、監視、保守まで一括で任せられるサービスなら、自社に専門人材が少なくてもPoCを始めやすくなります。NTTビジネスソリューションズは、要件定義・エリア設計・システム設計から免許取得支援、構築、施工、監視、運用保守までの流れを示しています。標準範囲を超える独自画面や複雑な既存連携は追加費用になりやすいため、標準機能と個別開発の境界を見積書で確認します。

スクラッチ開発・ハイブリッド型は独自要件に向いています

複数メーカーの装置をまたぐアラーム相関、独自の工事・保守業務、既存GIS・ITSM・ERPとの深い連携、厳格なデータ所在要件がある場合は、スクラッチ開発またはハイブリッド型が適しています。すべてを一から作るのではなく、監視・認証・チケットなどの標準コンポーネントを活用し、基地局固有の差分だけを開発すると、初期費用と将来の保守負担を抑えやすいです。2025年にNECがO-RAN仕様に準拠したvRANソフトウェアを商用化したように、RANの仮想化やオープン化が進んでいますが、標準準拠だけで実機の相互接続が保証されるとは限りません。RFPには実機接続試験と不具合時の切り分け責任を含めます。

局数と運用体制を基準に発注範囲を分けます

1〜2局の検証であれば、共有コアや短期レンタルを使い、管理画面・アラーム収集・性能データ・GIS表示・チケット連携だけを検証する方法が現実的です。一方、数十局以上を継続運用する場合は、冗長化、データ保持期間、監視センター、現地駆け付け、部品在庫、夜間作業、災害時の復旧までを含めた発注が必要です。局数を単純に増やすだけでなく、局数、セル数、装置メーカー数、連携先数、監視時間帯を発注単位として設計します。

RFPと要件整理では何を決めますか?

基地局管理システムのRFPと要件を整理するイメージ

RFPは「機能を作ってください」と依頼する書類ではなく、業務の目的、現状の制約、期待する成果、提案してほしい範囲を同じ条件で比較するための資料です。基地局管理システムでは、設備構成と業務フローの両方を示し、読み取り系と制御系を区別して書くことが、提案品質と見積精度を高めます。

RFPには設備・データ・利用者・成果物を記載します

RFPには、対象局数と増設計画、管理対象の装置名・型番・メーカー、接続プロトコル、既存監視基盤、GIS、ITSM、ERP、データレイクなどの連携先を記載します。さらに、収集間隔、リアルタイム性、保存期間、利用者数、権限ロール、監査ログ、可用性、バックアップ、災害復旧目標、画面や帳票の例も示します。成果物は、要件定義書、基本設計書、詳細設計書、接続仕様書、テスト計画・結果、運用手順書、教育資料、ソースコード、API仕様、ログの出力方法、データ移行手順まで具体化します。

現場のKPIと障害フローを要件に変換します

導入効果は、画面の数ではなく運用の変化で測ります。代表的なKPIは、障害の検知から一次切り分けまでの時間、MTTR(平均復旧時間)、重複アラームの削減率、現地出動回数、設定変更にかかる時間、セル稼働率、ハンドオーバー成功率、SLA違反件数です。現状値を測らずに「効率化する」と書くと、納品後に効果を判断できません。障害発生、検知、担当者への通知、原因候補の提示、現地作業、復旧確認、顧客報告の各工程を図にし、誰がいつ何を承認するかをRFPへ落とし込みます。

免許・通信の秘密・セキュリティを初期要件に含めます

ローカル5Gなどを扱う場合は、無線局免許、技術基準、電波利用料、設置場所、工事、保守の担当範囲を確認します。通信ログ、位置情報、端末情報などを扱う場合は、通信の秘密や個人情報、委託先監督の観点から、収集目的、閲覧権限、保存期間、削除方法を決めます。多要素認証、管理ネットワークの分離、最小権限、操作ログの改ざん耐性、脆弱性・パッチ管理、秘密情報の保管、バックアップ、SIEMやSOCとの連携も要件です。経済産業省は2026年3月にサイバーインフラ事業者向けガイドラインを策定しています(出典: 経済産業省「サイバーインフラ事業者に求められる役割等に関するガイドライン」、2026年)。発注者と受託者が担うセキュリティ上の役割を確認する材料にできます。

契約形態と責任分界はどのように決めますか?

基地局管理システムの契約と責任分界を確認するイメージ

基地局管理システムは、要件が固まる前の企画・PoCと、仕様が確定した本開発、継続的な監視・保守で契約の性質が異なります。契約書では、開発会社に任せる作業だけでなく、発注者が決める事項、通信設備メーカーが担う事項、現地工事会社が担う事項を明確にします。責任分界が曖昧なまま障害が起きると、アプリ、ネットワーク、無線、電源、回線のどこで問題が起きたかを巡って復旧が遅れます。

企画・要件定義は準委任、本開発は請負を基本に検討します

現状調査、要件定義、PoCのように、実機の制約や利用部門の要望を確認しながら成果を調整する工程は、作業時間や役割を定める準委任契約が適することがあります。一方、仕様、納期、検収条件、成果物が固まった本開発は、合意した成果を納品する請負契約を検討します。実際には、要件定義を準委任、本開発を請負、監視・保守を月額のサービス契約に分ける構成もあります。契約名称だけで判断せず、成果物、検収、瑕疵対応、変更手続き、再委託の条件を確認します。

SLA・障害対応・変更管理を数値で合意します

保守契約では、監視時間帯、受付方法、一次応答時間、切り分け開始時間、暫定復旧と恒久対策の目標、現地駆け付けの条件、月次報告、計画停止、バックアップ、災害時の復旧目標を定めます。たとえば「24時間監視」と書くだけでは、アラームを受け取るだけなのか、原因分析や現地手配まで含むのかが分かりません。重大度ごとの応答時間と、発注者・受託者・通信設備メーカーのエスカレーション経路を一覧化します。仕様変更は、変更理由、影響範囲、追加費用、納期、承認者を記録する手続きを契約に含めます。

API・ログ・データ返却と解約時の移行を確保します

外注先を変更できる状態を保つには、データの所有権や利用権、APIの利用条件、ログの取得方法、設定情報のエクスポート形式、ソースコードの扱いを契約で定めます。クラウド型サービスでは、解約時に設備台帳、アラーム履歴、性能データ、作業履歴、ユーザー・権限情報をどの形式で、いつまでに返却するかを確認します。独自形式のデータしか取り出せない場合、将来の移行費用が高くなります。再委託先、海外拠点でのデータ処理、脆弱性の通知期限、サポート終了時の代替案も、選定段階で確認することが大切です。

基地局管理システムの費用相場はいくらですか?

基地局管理システムの費用と見積を確認するイメージ

基地局管理システムの費用は、管理ソフトだけか、基地局・5Gコア・伝送・工事・運用を含むネットワーク全体かで大きく異なります。管理ソフト単体の公開価格は少ないため、見積では範囲を分けて提示してもらうことが必要です。以下の金額は、公開価格と類似するネットワーク監視・資産管理・業務SIからの推定を組み合わせた目安であり、局数や装置構成によって変わります。

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

PoCで1局を扱い、共有コアと標準監視を利用する場合は、初期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局を使ってアラーム収集、性能データ、地図表示、チケット連携、設定変更の安全性を検証します。PoCでは、通常時だけでなく、装置停止、通信断、電源断、データ遅延、重複アラーム、誤った設定変更などの異常系を試験します。ここで得た差分を本開発の要件へ反映すると、後工程の手戻りを抑えやすくなります。

本番前に性能・障害・セキュリティ・移行を試験します

本開発では、機能試験だけでなく、負荷試験、フェイルオーバー試験、バックアップからの復元、権限試験、操作ログの確認、脆弱性診断、通信断や装置停止を想定した障害試験を行います。既存のExcelや紙、複数の監視ツールから台帳・履歴を移行する場合は、項目の対応表、欠損データの扱い、重複の統合、移行後の照合方法を決めます。運用担当者が新しいアラームの意味を理解できるよう、画面説明だけでなく、障害シナリオを使った訓練を実施します。

段階リリース後にKPIと運用契約を見直します

本番稼働は、代表局、少数局、全局というように段階的に広げます。各段階で、アラームの誤検知率、MTTR、現地出動回数、設定変更の承認時間、データ欠損、利用者の問い合わせ件数を確認します。目標値に届かない場合は、画面の改修だけでなく、監視ルール、責任分界、教育、保守時間帯、装置側の設定を見直します。2026年1月にソフトバンクとエリクソンが発表したAIによるMassive MIMO基地局のカバレッジ最適化では、大阪・関西万博の実証で下りスループットが76.9Mbpsから95.5Mbpsへ約24%改善したとされています(出典: ソフトバンク・エリクソン、2026年)。このような高度な自動化を検討する場合も、まずベースラインと評価条件を定義してから導入効果を測定します。

よくある質問

基地局管理システムの発注に関するよくある質問

基地局管理システムの発注では、費用、期間、運用責任、既存設備との互換性について多くの疑問が生じます。ここでは、初めて外注する企業が判断しやすいよう、代表的な質問へ直接回答します。

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

最初から全局・全機能を作らず、1〜2局のPoCで、台帳、アラーム、性能、GIS、チケット連携などの効果を確認する方法が有効です。ネットワーク込みの費用と管理ソフト単体の費用を分け、標準機能を優先し、独自開発はKPIに直結する部分へ絞ります。ただし、将来の局数拡張、API、データ返却、セキュリティ、運用教育を初期要件から外すと、後から高い移行費用が発生するため、削る範囲と残す範囲を明確にします。

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

外注できますが、提案前に装置メーカー、型番、ソフトウェアバージョン、監視プロトコル、APIの有無、ライセンス条件、ログの取得方法を開示する必要があります。すべての装置を一つの画面で同じ粒度に表示できるとは限らないため、第一段階は読み取りとアラーム集約、第二段階で性能分析や設定変更というように優先順位を分けます。接続できない装置が見つかった場合の代替監視、追加費用、納期、責任分界を契約前に合意します。

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

無線局免許、基地局、5Gコア、伝送、現地工事、24時間保守まで一括で任せたい場合は、通信設備会社やネットワークSIerが向いています。既存の業務システム、工事・保守フロー、GIS、ITSM、データ分析を柔軟に組み替えたい場合は、業務システム開発会社を組み合わせる方法が適しています。重要なのは会社の種類ではなく、両者を含む体制の責任者、障害時の一次窓口、APIとデータの管理者、検収責任を提案書と契約書で明確にすることです。

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

必要があります。ローカル5Gなどでは無線局免許や技術基準、設備構成に応じた申請・運用を確認し、通信ログや端末情報を扱う場合は通信の秘密、個人情報、委託先監督を確認します。5Gシステムの安全性・信頼性を高める制度やガイドラインも更新されますので、発注者の業態、設備、データ、委託範囲に応じて、法務・セキュリティ担当と受託先へ確認します。記事の一般論だけで適用関係を断定せず、案件ごとに所管官庁や専門家へ相談することが安全です。

まとめ

基地局管理システムの発注を成功させるまとめ

基地局管理システムの発注・外注では、最初に管理対象、導入目的、KPI、制御系と業務管理系の境界を定めます。そのうえで、パッケージ・マネージド型、スクラッチ型、ハイブリッド型を、局数、装置メーカー、既存連携、自社の運用体制に合わせて選びます。

RFP・契約・見積を一つの条件で揃えます

RFPには設備、データ、利用者、連携、性能、セキュリティ、成果物、保守条件を記載し、見積書では開発、機器、工事、クラウド、移行、教育、運用を分けて比較します。契約では、準委任・請負・保守サービスの使い分け、SLA、障害時の責任分界、再委託、API・ログ・データ返却、解約時の移行支援まで確認します。価格の安さだけでなく、将来の局数拡張と委託先変更ができるかを評価することが、長期的なコストとリスクを抑えるポイントです。

小さく検証してから本番と高度化へ進みます

1〜2局のPoCでアラーム、性能、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を創業。