列車運行管理システム開発の発注/外注/依頼/委託方法について

列車運行管理システムの発注・外注は、システム開発会社に機能を丸ごと依頼するのではなく、安全制御系と周辺業務系を分け、既設設備との責任分界、試験・切替、保守まで含めて調達範囲を定義することが成功の近道です。

列車運行管理システムは、列車位置の監視、ダイヤに基づく進路設定、信号機・転てつ機との連携、遅延時の運転整理、旅客案内への情報連携などを担います。本記事では、発注形態の選び方、RFPと要件整理、契約形態、費用相場、委託先の選定、見積比較のポイントを、鉄道事業者が実際に社内稟議やベンダー打ち合わせへ持ち込める順番で解説します。

▼全体ガイドの記事
・列車運行管理システム開発の完全ガイド

列車運行管理システムの発注・外注は何から始めればよいですか？

最初に行うことは、列車運行管理システムを「何を監視・制御するシステムか」と「どの業務を改善するシステムか」に分けることです。安全に直結する信号保安設備や進路制御を含むのか、ダイヤ作成、運転整理支援、旅客案内、実績分析などの周辺機能に限定するのかで、必要な会社、契約、試験、費用が大きく変わります。

列車運行管理システムでは、PTC（Programmed Traffic Control）が指令所から線区全体を集中制御し、列車位置の監視やダイヤに基づく進路制御を行います。CTCは指令所から駅の信号機や分岐器を遠隔監視・制御する仕組み、PRCは計画ダイヤに応じて進路設定を自動化する仕組みです。実際の発注では、これらの用語を並べるだけでは不十分で、駅制御装置、連動装置、軌道回路、列車無線、旅客案内、輸送計画、車両・乗務員運用のどこまでを対象にするかを線区単位で示す必要があります。

特に注意したいのは、旅客向けの運行情報アプリだけを列車運行管理システムと考えないことです。表示や通知を担う周辺システムと、列車の進路や信号を扱う安全関連システムでは、許容できる遅延、可用性、試験方法、障害時の代替運用が異なります。RFPでは「列車運行管理システム一式」と書くのではなく、機能一覧と対象外一覧を併記します。

安全制御の中核は、冗長構成、フェールセーフ、時刻同期、操作権限、監査ログ、通信断時の挙動、手動代替運転を前提に設計します。一方で、運転実績の集計、ダイヤ改正の支援、遅延原因の分析、旅客案内データの配信などは、API連携を前提にした別システムとして整理できる場合があります。二つの領域を分けると、既設の信号保安設備を大きく変更せずに周辺機能を先行導入し、段階的に効果を確認できます。

2026年4月改定の国土交通省「鉄道分野における情報セキュリティ確保に係る安全ガイドライン」では、鉄道事業者が重要システムのセキュリティ対策を継続的に見直すことが示されています。外部のクラウドやAIを採用する場合も、制御系へ直接つなぐのか、参照専用のデータ連携にとどめるのかを発注時点で分けることが重要です。これは技術選定だけでなく、障害時の責任を誰が負うかを明確にするための発注設計でもあります。

列車運行管理システムの発注形態はどのように選びますか？

発注形態は、既存ベンダーへの一括更新、複数社によるRFP方式、専門会社を組み合わせる分離発注、複数社のJV・コンソーシアム方式に大別できます。最適解は会社の知名度ではなく、既設設備の開示範囲、線区の規模、更新期限、発注者側のプロジェクト管理力、運行を継続したまま移行できる体制で決まります。

既設の信号、連動、駅装置、指令所設備が特定メーカーの独自仕様で構成され、インターフェース情報や試験環境をそのメーカーが保有している場合は、既存ベンダーへの一括発注が現実的です。更新範囲を一社で束ねることで、設備間の調整窓口や障害時の責任分界を減らし、現地試験と夜間切替の計画を作りやすくなります。

ただし、既存ベンダーだからという理由だけで要件整理を任せると、不要な機器更新や特定製品への固定化が起こる可能性があります。RFIで現行構成、利用可能なAPI、データ形式、保守部品の供給期間、将来の第三者連携条件を確認し、随意契約とする場合にも価格妥当性と代替案を社内記録に残します。

刷新の目的が老朽化対策だけでなく、運転整理の高度化、データ活用、保守効率化、周辺業務との統合に及ぶ場合は、RFPで複数社の提案を比較します。比較対象は初期価格だけではなく、既設調査の深さ、シミュレーターの有無、安全審査の進め方、現地試験の体制、移行後の24時間365日保守まで含めます。

RFP方式では、同じ資料を同じ期限で渡さなければ、見積の差が会社の能力差なのか、前提条件の違いなのか判断できません。駅数、列車本数、対象設備、切替可能な時間帯、必要な稼働率、教育対象者数、保守期間、データ移行量を共通条件として提示し、未確定事項は質問回答書で全候補へ共有します。

安全制御系は鉄道信号に強い会社、運転整理や分析は業務システムに強い会社、旅客案内やデータ基盤はIT会社というように、専門領域を組み合わせる方法もあります。大規模線区では、元請会社が全体インテグレーションを担い、機器メーカーやソフトウェア会社がサブシステムを担当する体制が一般的です。

分離発注は価格と技術の比較がしやすい反面、発注者側にインターフェース管理、総合試験、障害時の切り分けを担う能力が必要です。契約書には、構成管理責任者、変更承認者、試験の合否判定者、運行障害時の一次窓口を明記し、会社間の「相手側の範囲です」という抜けを防ぎます。

RFPと要件整理では何を決めるべきですか？

RFPは、ベンダーに価格を聞くためだけの文書ではありません。発注者が抱える運行上の課題、対象線区、既設設備、求める安全・性能水準、移行条件、納品物、評価方法を同じ前提で伝え、提案内容を比較可能にするための文書です。作成前に現場の指令員、設備担当、情報システム担当、保安・安全担当、調達担当を集めます。

最初に線区台帳を作り、駅数、信号機、転てつ機、連動装置、軌道回路、踏切、列車無線、指令所、電源、通信回線、サーバー、表示装置を棚卸しします。設備名称だけでなく、型式、導入年、保守期限、予備品、接続方式、現在の障害履歴、単一障害点まで記載します。図面と実機の差異が見つかることもあるため、現地確認と担当者ヒアリングをRFPの前提にします。

さらに、通常時だけでなく、通信断、電源喪失、機器故障、列車の在線情報欠落、指令所の切替、ダイヤ乱れ、誤操作を異常時シナリオとして整理します。指令員が紙や電話で行う代替手順を確認すると、システムに必要なアラーム、操作履歴、承認フロー、復旧支援画面が明確になります。

RFPの機能要件には、列車位置・在線監視、列車番号管理、ダイヤ変更、進路設定、運転整理、アラーム、操作権限、ログ、旅客案内連携、実績分析を記載します。非機能要件には、稼働率、復旧時間、処理性能、時刻精度、画面応答、冗長化、バックアップ、監査ログ、保守時間帯、教育、マニュアル、ソースコードや設定情報の引き渡しを含めます。

納品物は、要件定義書、基本設計書、詳細設計書、インターフェース一覧、構成図、試験仕様書、試験成績書、操作手順書、障害時手順書、教育資料、保守台帳、データ移行計画まで明示します。工場試験、現地単体試験、連動試験、総合試験、運行を模したシミュレーター試験、並行稼働、夜間切替後の安定化期間を受入条件に含めることが大切です。

安全要件と情報セキュリティ要件は、一般的な業務システムのチェックリストを流用せず、鉄道の運行継続を前提に定義します。ネットワーク分離、接続先の認証、権限分離、ログ監視、脆弱性対応、パッチ適用手順、バックアップ、復旧訓練、サプライチェーン、委託先の遠隔保守方法をRFPに含めます。国土交通省の第6版ガイドライン（2026年）は、鉄道分野の特性に応じた必要または望ましい対策水準を示しているため、発注者の安全管理規程と照合して適用範囲を決めます。

AIやクラウドを使う場合も、最終的な進路制御や運転整理の承認をAIへ無条件に委ねないことが原則です。2025年に日立製作所とJR東日本が公表した共同検証では、ATOSの障害時に仕様書や過去の知見をもとに原因究明と復旧方法の特定を支援する方向が示されました。発注時は、AIを「候補提示・検索・復旧支援」に限定するのか、指令員の承認を必須にするのか、誤回答時にどう手動へ戻すのかまで定義します。

契約形態はどのように組み立てればよいですか？

列車運行管理システムでは、要件が固まっていない段階から全工程を一括請負にすると、前提変更が追加費用や納期遅延に直結しやすくなります。要件定義・現地調査は準委任または調査契約、設計・構築・試験・切替は請負、運用保守はサービス契約というように、工程ごとに契約を分ける方法が実務的です。

準委任契約は、専門家の作業や調査、設計支援を依頼しやすい契約です。現地調査、業務ヒアリング、現行資料の整理、RFP作成支援、プロトタイプ検証など、作業内容を進めながら前提を確定する工程に向きます。作業時間だけでなく、月次報告、課題一覧、要件候補、インターフェース台帳などの提出物を定義しておくと、活動の評価がしやすくなります。

請負契約は、完成させる対象と受入条件が定まっている設計、実装、試験、機器構築、切替作業に適しています。ただし、鉄道設備を含む案件で「完成」の定義が曖昧だと、工場試験は合格したものの実際のダイヤ乱れで使えないという問題が起こります。試験シナリオ、性能基準、未解決事項の扱い、再試験の費用負担を契約書と別紙仕様書に書きます。

運行管理システムでは、既設設備の調査で新しい制約が見つかったり、試験中に操作手順の変更が発生したりします。変更要求の起票者、影響分析の担当、費用と納期の承認者、緊急変更の手順を決め、ベースラインとなる要件と変更後の要件を分けて管理します。

契約に入れるべき責任分界は、設備の故障、通信障害、データ不整合、誤操作、サイバーインシデント、切替失敗、第三者設備の仕様変更などです。加えて、障害受付の一次窓口、現地駆け付け時間、部品の保有、ログの保存期間、遠隔保守の承認、保守終了後の移行支援、設定情報とデータの返却条件をSLAや保守仕様書に明記します。

列車運行管理システムの費用相場と内訳はどのくらいですか？

費用は、周辺機能の追加なら3,000万円から3億円程度、小規模線区の部分更新なら2億円から10億円程度、中規模線区のPTC刷新なら10億円から50億円程度、大都市圏の複数線区更新なら50億円を超える場合があります。これはソフトウェアだけでなく、指令所、駅側装置、ネットワーク、試験、現地工事、切替を含む案件規模別の概算です。線区、駅数、既設設備の状態、相互直通の有無で大きく変わるため、相場をそのまま予算確定額として扱わないことが重要です。

公表資料の実例として、東京臨海高速鉄道の「中期経営計画2025（後半）」では、2025年度から2027年度の設備投資として運行管理システムの更新が概算10億円で示されています。ただし、資料上ではソフトウェア、関連機器、工事の内訳が分離されていないため、10億円をシステム開発費だけの市場価格と解釈できません。公開された設備投資額は「同程度の更新計画が実在する」ことを確認する材料として扱います。

阪神電気鉄道も2026年度の鉄道事業設備投資計画で、老朽化したPTCシステムの更新とPTCセンター建物の耐震化を計画しています。2026年度の鉄道事業設備投資総額は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億円程度が概算の目安ですが、公表計画と推定レンジは分けて考えます。最終的には、試験・切替・教育・24時間保守・15年から20年程度のライフサイクルコストまで含めて比較し、運行を止めずに移行できる体制と責任分界を確認することが、発注成功につながります。

▼全体ガイドの記事
・列車運行管理システム開発の完全ガイド

会社紹介

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

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

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