列車運行管理システムの発注は、対象の範囲を整理し、RFPで条件をそろえ、試験・切替・保守までを含む契約を結ぶ、という順に進めます。この順で進めると、安全性と運行継続を両立させやすくなります。
▼全体ガイドの記事
・列車運行管理システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
発注・外注の出発点
まずは、列車運行管理システムの監視・制御機能と、改善したい業務を分けて整理します。信号保安設備や進路制御を含むか、周辺機能に限定するかで、必要な会社と契約の形が変わり、試験や費用にも影響します。
PTC・CTC・PRCと周辺システムの境界
PTC（Programmed Traffic Control）は、指令所から線区全体を集中制御し、列車位置の監視やダイヤに基づく進路制御を担います。
CTCは駅の信号機や分岐器を遠隔監視・制御し、PRCは計画ダイヤに応じて進路設定を自動化します。
発注時は、駅制御装置や連動装置、軌道回路、列車無線など、対象設備を線区単位で示します。
業務は系統ごとに分けて整理します。
- 運行系：輸送計画、車両・乗務員運用
- 旅客系：旅客案内、運行情報アプリ
- 制御系：信号機、連動装置、進路制御
旅客向けアプリなどの周辺システムと安全関連システムでは、許容遅延や可用性、試験方法が異なります。障害時の代替運用も異なるため、RFPには「列車運行管理システム一式」と一括りにせず、機能一覧と対象外一覧を併記します。
安全制御系と周辺業務系の分離
安全制御系は、冗長構成やフェールセーフを前提に設計します。
時刻同期や操作権限、監査ログの扱いも、この系統で定めます。通信断時の挙動や手動代替運転は、あらかじめ決めておきます。
周辺機能については、API連携を前提に別システムとして整理できる場合があります。
- 安全制御系：信号・進路制御と障害時の運用
- 周辺業務系：実績集計、ダイヤ改正支援、遅延分析
- 旅客案内系：案内データの配信
二つの領域を分けておくと、既設の信号保安設備を大きく変えずに周辺機能を先行導入できます。段階的に進めて、効果を確かめることもできます。
外部クラウドやAIを使う場合は、制御系へ直接つなぐか、参照専用の連携にとどめるかを分けて決めます。この区分によって、技術選定と障害時の責任の範囲が定まり、発注の設計にも反映されます。
発注形態の選び方
発注形態には、既存ベンダーへの一括更新、RFP方式、分離発注があるほか、JV・コンソーシアム方式もあります。発注形態は、会社の知名度よりも、設備情報の開示範囲や線区の規模、更新期限によって選ばれます。
発注者側の管理力や、運行を続けながら移行できる体制も判断材料になります。
既存ベンダーへの一括発注が向くケース
既設の信号、連動、駅装置、指令所設備が特定メーカーの独自仕様であれば、一括発注が現実的な選択になります。
- 一括化の利点：設備間の調整窓口を減らせる
- 一括化の利点：障害時の責任分界をまとめやすい
- 向く条件：メーカーが接続情報や試験環境を保有する
一社に更新範囲をまとめると、現地試験や夜間切替の計画を立てやすくなります。
既存ベンダーだけに要件整理を任せると、不要な更新や特定製品への固定化が起こる可能性があります。
RFIでは、現行構成とAPI、データ形式を確認し、部品供給期間や第三者連携の条件も押さえます。また、随意契約であっても、価格の妥当性と代替案は社内の記録に残します。
RFPで複数社を比較するケース
老朽化対策に加えて、運転整理の高度化やデータ活用、保守効率化を目指す場合は、RFPで複数社を比べます。
周辺業務との統合を目指す場合も、RFPで複数社の提案を比べます。比べるときは、調査の深さ、移行の安全、移行後の運用の順に、各社の提案を見ていきます。
- 調査・提案：既設調査の深さ、シミュレーターの有無
- 安全・移行：安全審査、現地試験、切替の体制
- 運用：移行後の24時間365日保守
評価では、初期価格に加えて、提案内容と移行後の保守まで見ます。
各社に同じ資料を同じ期限で渡すと、前提条件の違いによる見積のばらつきを抑えられます。
共通条件には、駅数と列車本数、設備、切替時間帯を含めます。稼働率や教育対象者数も、同じ条件として示します。
保守期間とデータ移行量も示しておき、未確定の事項は質問回答書で全候補に共有します。
JV・コンソーシアムや分離発注を使うケース
JV・コンソーシアムや分離発注では、専門領域ごとに会社を組み合わせます。
大規模線区での元請の役割や、分離発注で発注者に求められる統合管理、契約の取り決めを、あわせて確かめます。
- 専門領域：安全制御、運転整理・分析、旅客案内を分担
- 大規模線区：元請が全体統合し、各社がサブシステムを担当
- 分離発注：価格・技術を比べやすいが、発注者に統合管理力が必要
- 契約：構成管理、変更承認、試験判定、障害時窓口を明記
分離発注では、発注者がインターフェース管理や総合試験、障害時の切り分けを担える体制を整えます。
RFPと要件整理の内容
RFPは、課題と対象線区、既設設備を共通の前提として各社に伝える文書です。安全・性能の水準や移行条件も示し、納品物と評価方法まで含めて、提案を並べて比べられるようにします。
作成の前に、指令員や設備、情報システムの担当者を集めます。保安・安全、調達の担当者も加わります。
RFPの前に行う現地・既設調査
線区台帳を作り、駅数や信号機、転てつ機を洗い出します。連動装置や軌道回路、踏切も同じ台帳に加えます。列車無線や指令所、電源に加えて、通信回線、サーバー、表示装置も対象になります。
- 設備情報：型式、導入年、保守期限、予備品
- 接続情報：接続方式と単一障害点
- 運用情報：障害履歴と図面・実機の差異
設備名称だけでなく上記の情報まで台帳に記載し、現地では確認と担当者への聞き取りも行います。
異常時シナリオには、通信断や電源喪失、機器故障を含めます。在線情報の欠落や指令所切替も、シナリオに加えます。さらに、ダイヤ乱れや誤操作も整理します。
紙や電話による代替手順を見ると、必要な警報や承認フローが分かります。
RFPの成果物と試験条件
機能要件には、列車位置と在線の監視、列車番号の管理、ダイヤ変更を含めます。進路設定と運転整理も、機能要件の対象です。アラームや権限、ログのほか、旅客案内との連携と実績分析も機能要件に含まれます。
- 性能：稼働率、復旧時間、処理性能、時刻精度
- 運用：画面応答、冗長化、バックアップ、監査ログ
- 引き渡し：保守時間、教育、マニュアル、ソースコードや設定情報
納品物には、要件定義書と設計書、インターフェース一覧を含めます。構成図も、納品物に加えます。
試験仕様書と成績書、操作・障害時の手順書を明示します。教育資料や保守台帳、データ移行計画も、納品物として書き出します。
受入条件には、工場と現地の単体試験、連動試験、総合試験を含めるとともに、シミュレーター試験も加えます。並行稼働と、夜間切替後の安定化期間も定めます。
安全・セキュリティ・手動代替の別立て定義
安全と情報セキュリティは、運行継続を前提に、一般的な業務システム用の確認表とは別に定義します。
- 接続管理：ネットワーク分離、接続先認証、権限分離
- 保全：ログ監視、脆弱性対応、パッチ適用、バックアップ
- 運用継続：復旧訓練、サプライチェーン、委託先の遠隔保守方法
2026年4月改定の国土交通省「鉄道分野における情報セキュリティ確保に係る安全ガイドライン」は、対策の継続的な見直しを示しています。
国土交通省の第6版ガイドライン（2026年）は、鉄道の特性に応じた必要または望ましい対策水準を示しています。そのため、発注者の安全管理規程と照合して、適用範囲を決めます。
AIの扱いでは、進路制御や運転整理の承認を無条件に任せないことが原則です。
2025年に日立製作所とJR東日本が公表した共同検証では、ATOS障害時に仕様書や過去の知見をもとに、原因究明と復旧方法の特定を支援しています。
発注時には、AIを候補提示や検索、復旧支援に限るか、指令員の承認を必須にするかを決めておきます。また、誤回答が出た場合に備えて、手動に戻す方法も定義します。
契約形態の組み立て方
要件が固まらないうちに全工程を一括請負にすると、前提の変更が追加費用や納期の遅れにつながりやすくなります。
要件定義と現地調査は準委任または調査契約にします。
設計・構築・試験・切替は請負、運用保守はサービス契約とします。
要件定義は準委任、成果物が確定した工程は請負
準委任契約は、専門家による調査や設計支援のように、作業を進めながら前提を固めていく工程に向いています。
- 準委任の例：現地調査、業務ヒアリング、現行資料の整理
- 準委任の例：RFP作成支援、プロトタイプ検証
- 請負の例：設計、実装、試験、機器構築、切替作業
準委任では、作業時間に加えて、月次報告や課題一覧を提出物にできます。要件候補やインターフェース台帳も、提出物に含められます。
請負は、完成対象と受入条件が定まった工程に適しています。ただし、「完成」の定義が曖昧なままだと、工場試験に合格しても、実際のダイヤ乱れの場面で使えない恐れがあります。
試験シナリオや性能基準は、契約書と別紙仕様書に記載します。未解決事項や再試験費用の負担も、同じ書類に書いておきます。
契約の中心となる変更管理と責任分界
既設調査で制約が見つかったり、試験中に操作手順が変わったりすることがあります。そのため、契約では次の手続きを定めます。
- 変更手続き：起票者、影響分析の担当、費用・納期の承認者
- 緊急対応：緊急変更の手順
- 要件管理：基準要件と変更後要件の区別
責任分界には、設備故障や通信障害、データ不整合を含めます。誤操作やサイバーインシデントも対象に入れ、切替の失敗や第三者設備の仕様変更も含めます。
SLAや保守仕様書には、一次窓口と現地駆け付け時間を明記します。部品の保有やログの保存期間も、同じ書面に書いておきます。
遠隔保守の承認や、保守終了後の移行支援も定めます。
設定情報やデータの返却条件も、あわせて決めます。
費用相場と内訳の目安
周辺機能の追加は3,000万円から3億円程度、小規模線区の部分更新は2億円から10億円程度が目安です。
中規模線区のPTC刷新は10億円から50億円程度、大都市圏の複数線区更新は50億円を超える場合があります。
これらは概算で、ソフトウェアに加えて、指令所や駅側装置、ネットワークも含みます。試験や現地工事、切替まで見込んでいます。
線区や駅数、既設設備の状態、相互直通の有無で変わるため、予算の確定額として扱わないようにします。
公表計画と推定相場の区別
公表額は、個別案件の推定相場とは分けて見ます。
- 東京臨海高速鉄道：「中期経営計画2025（後半）」では、2025年度から2027年度に運行管理システムを更新。概算10億円
- 内訳の注意：ソフトウェア・機器・工事は分離されず、開発費単価ではない
- 阪神電気鉄道：2026年度にPTC更新とセンター建物の耐震化を計画
- 公表額：同年度の設備投資総額は172億円、PTC単体価格は非公表
- 予算取り：総額からPTC価格を逆算せず、現地調査前の目安にする
これらの公表額は、同程度の更新計画が実際にあることを確かめる材料です。
見積書で確認するソフトウェア以外の費用
見積もりは、費目ごとに分けて依頼します。
- 設計・開発：要件定義、現地調査、基本・安全設計、ソフトウェア
- 設備・接続：サーバー・ストレージ・ネットワーク、駅・指令所の機器工事
- 導入・運用：試験、切替、教育、マニュアル、保守、予備品
試験環境やシミュレーターも見積項目に含めます。工場・現地試験や夜間切替、試運転も同じように加えます。このように費目を分けて見ておくと、後から追加費用が発生する箇所を把握できます。
初期費用だけでなく、15年から20年程度のライフサイクルコストを比べます。その際は、24時間365日の監視や現地駆け付け、予備サーバーと部品の費用も含めます。
OS・ミドルウェア更新や脆弱性対応、教育に加えて、データ移行や将来の駅追加も比較に入れます。一般的なIT保守費の目安を機械的に当てはめるより、長期保守の体制と費用を個別に確認します。
委託先の選定と見積比較
委託先は、知名度よりも、同規模・同種線区の納入実績や異なるメーカー設備との接続実績で比べます。
責任分界や安全審査・試験体制、24時間保守は、同じ評価表で確認します。部品供給や要員の継続性、データと仕様書の引き渡し条件も比較対象です。
案件の近さで見る実績
列車位置監視だけの導入なのか、PTC・CTC・PRCや信号保安設備を含む更新なのかを区別して見ます。さらに、駅装置や旅客案内、輸送計画まで含むのかも確認します。
- 規模：駅数、列車本数、指令所の数
- 接続：相互直通、既設設備メーカー
- 移行：段階切替の有無
条件が近い案件ほど参考になります。実績件数だけでなく、その案件の現在の保守状況も聞きます。障害時の復旧体制が機能するかも、あわせて確かめます。
候補会社には、通信断時に運行を続けられる範囲や、連動装置との責任分界を具体的に質問します。現地試験に必要な夜数や、手動代替運転の教育担当、保守終了時の引き渡し内容も確かめます。
回答と根拠資料を評価表に残すと、営業説明だけで判断するリスクを減らせます。
見積の金額・前提・除外項目の比較
見積比較表には金額のほか、対象駅や設備、期間を記載します。試験回数や切替方式、保守期間も、同じ表に書き込みます。
ライセンスや機器、工事、教育の費用は、項目ごとにそろえます。旅費や予備品、税、価格変動、除外項目も含めて比べます。
- 共通化：見積前提一覧を同じ様式で提出してもらう
- 範囲確認：機器・工事込みか、ソフトウェアのみか
- 評価軸：価格以外に安全、移行、保守も比べる
たとえば、A社が機器・工事込みで、B社がソフトウェアのみの場合、単純な総額比較ではB社が安く見えます。
評価配点は価格に偏らせず、技術適合性や安全、セキュリティ、移行・試験計画を含めます。保守体制や管理、将来拡張性も評価し、発注者が重視する項目に配点します。
最安値の案でも、夜間切替や障害時の復旧が弱ければ、運行停止の損失や追加改修費が増える可能性があります。
契約と設計によるベンダーロックインの抑制
安全系では、既設メーカーの技術や保守網が必要になる場合があります。そのため、ロックインは完全には避けられない前提で、避けにくい範囲と将来交換可能にする範囲を分けて考えます。
- 契約で定める情報：データ形式、API、構成情報、ログ
- 引き渡し対象：試験結果、画面仕様、設定値、運用手順
- 権利・条件：教育資料の権利と引き渡し条件
周辺の計画・分析システムでは、標準APIやクラウドで複数社の選択肢を残せる場合があります。
東芝の公式情報では、輸送計画の基本機能をパッケージ化し、クラウド提供や機能選択に対応するサービスが案内されています。運行管理や信号保安には別の信頼性要件があるため、クラウド化は機能ごとに評価します。
よくある質問
発注前には、既存ベンダー以外への依頼やクラウド化、必要な予算について質問が寄せられます。判断を誤りやすい論点に、順に答えます。
小規模な鉄道会社でも列車運行管理システムを外注できますか？
小規模線区で外注を始める際は、導入範囲と概算費用を先に整理します。
- 外注：小規模な鉄道会社でも依頼できます
- 始め方：中核を一度に刷新せず、周辺機能から導入
- 対象例：運転整理支援、ダイヤ管理、旅客案内、実績分析
- 費用目安：機能追加は3,000万円から3億円程度。駅数や接続方式で変動
既設設備との連携範囲を絞ったうえで、現地調査を含む概算見積を取り寄せます。
列車運行管理システムをクラウドで構築できますか？
クラウド化できる範囲は、機能の役割と安全上の要件に分けて判断します。
- 検討できる機能：計画、分析、帳票、旅客案内（要件を満たす場合）
- 導入例：東芝の輸送計画ICTソリューション
- 安全関連機能：リアルタイム性、閉域性、冗長性、通信断時の動作を検証
- 判断方法：手動代替も確認し、機能単位で範囲を決定
既存の列車運行管理システムの会社にしか依頼できませんか？
依頼先を広げる場合は、既設設備の公開情報と各社の連携条件を確認します。
- 依頼先：既存ベンダーだけに限定されません
- 置換の制約：接続情報、独自プロトコル、保守権限、試験環境が非公開だと難しい
- 確認方法：既存会社を含む複数社へRFIし、公開資料と共同体制を確認
- 発注判断：責任分界と将来のデータ引き渡し条件を確認
AIで運転整理や障害対応を自動化できますか？
AIの適用範囲は、支援できる業務と安全確認の方法を分けて検討します。
- 導入候補：候補提示、事例・復旧手順の検索、警報要約、知識継承
- 安全判断：説明可能性や制約を検証し、指令員の承認を設ける
- 運用確認：誤回答時の手動復帰、試験、監査を整える
- 検証方法：本番制御と分離したシミュレーターで効果とリスクを確認
まとめ
発注・外注では、対象の線区と機能を分けてから、会社や製品を選びます。PTC・CTC・PRCや信号保安、駅設備、指令所の境界を整理します。輸送計画や旅客案内、分析の境界も、あわせて整理します。
発注側は、既設調査と異常時シナリオをもとにRFPを作成します。
発注前にそろえる資料
見積と移行の前提をそろえるため、発注前に各分野の資料を用意します。
- 設備資料：線区・駅・設備台帳、現行構成図、インターフェース一覧
- 運行資料：ダイヤ、列車本数、指令員の業務手順、障害・通信断・指令所切替シナリオ
- 契約・予算：保守契約、更新期限、想定予算、切替可能な時間帯
- 見積条件：ソフトウェア、機器、工事、試験、教育、切替、保守、予備品
除外項目と前提条件も、同じ様式で提出してもらいます。
運行継続と長期保守で見る委託先の選び方
委託先を比べるときは、初期費用の幅だけでなく、移行後まで含めた負担も確かめます。
- 費用目安：周辺機能は3,000万円から3億円程度、部分更新は2億円から10億円程度
- PTC刷新：中規模線区は10億円から50億円程度。公表計画と推定値を区別
- 大都市圏：複数線区の更新は50億円を超える場合があります
- 比較範囲：試験、切替、教育、24時間365日保守、15年から20年程度のライフサイクルコスト
- 委託先：運行を止めずに移行できる体制と責任分界を確認
▼全体ガイドの記事
・列車運行管理システム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。