運転整理システム開発の発注/外注/依頼/委託方法について

運転整理システムの発注・外注は、既存の運行管理システムと現場業務を調査したうえで、参照専用のPoC、指令員が承認する支援機能、本番の連携範囲を段階的に決めて進める方法が適切です。

運転整理システムは、列車の遅延を表示するだけの仕組みではありません。事故や設備故障、大雨などでダイヤが乱れたときに、列車の順序変更、運休、折返し、待避、乗務員・車両の運用変更を検討し、指令員の判断と旅客案内を支える重要なシステムです。本記事では、発注形態の選び方、RFPと要件整理、契約形態、2026年時点の計画用費用相場、委託先の選定方法、見積比較のポイントまでを一連の流れで解説します。

▼全体ガイドの記事
・運転整理システム開発の完全ガイド

運転整理システムとは何ですか？発注前に知る全体像

運転整理システムとは、列車の位置や遅延、設備状態、ダイヤ、車両、乗務員、旅客流動などを組み合わせ、ダイヤ乱れからの復旧案を作成・比較・承認する指令支援システムです。導入時は「自動で運転を決めるシステム」と捉えるのではなく、人が安全に判断するための意思決定基盤として業務範囲を定めることが重要です。

遅延表示システムは、列車が何分遅れているか、どの列車が運休しているかを利用者や社内へ伝える役割が中心です。一方、運転整理システムは、現在のダイヤと設備の制約をもとに「先行列車をどこで待避させるか」「途中駅で折り返すか」「接続を維持するか」「乗務員と車両をどう組み替えるか」といった復旧案を作成します。案ごとに遅延時間の総和、運休本数、駅の滞留、乗換えへの影響、平常ダイヤへ戻るまでの時間を比較し、指令員が理由を確認して最終判断できる設計が必要です。

基本的な連携対象は、運行管理システムやTTC・PTC・PRC・CTCから取得する列車位置、時刻、進路、設備状態、ダイヤデータです。案件によっては、車両の編成・留置、乗務員の勤務と交代、回送、駅の線路容量、気象・災害情報、旅客の混雑状況、Webやアプリの案内情報まで扱います。既存システムのメーカー、通信方式、更新頻度、データの正確性、欠損時の扱いを確認せずに開発を始めると、画面だけ完成しても実際の運転整理には使えません。

最初から全線区・全障害パターンを自動化するより、参照専用のPoCから始める方が発注の失敗を抑えやすいです。まず過去の事故、信号トラブル、大雨、混雑などのデータで複数の整理案を表示し、熟練者の判断と比べます。次に、指令員が案を修正・承認する支援機能へ広げ、通信断やデータ欠損時も手動運用へ戻れることを確認してから、本番系との連携範囲を広げます。AIを組み込む場合も、AIの提案をそのまま制御指示にせず、ルールや数理最適化による制約検証を通す構成が基本です。

運転整理システムの発注・外注はどのように進めますか？

発注・外注は、目的と責任範囲を決める企画、RFI・RFPによる情報収集、提案と見積の比較、契約、要件定義、開発・試験、受入れ、保守契約の順に進めます。特に重要なのは、運転整理の業務ルールや最終承認を発注者側で保持し、ベンダーへ任せる設計・実装・試験・運用支援との境界を最初に明文化することです。

既存の運行管理システムを大きく変更する場合は、現行ベンダーへの追加開発や随意契約が候補になります。既存仕様と接続方式を把握しているため短期化しやすい一方、比較対象が少なく、価格や将来の切替条件が見えにくくなることがあります。信号・制御設備と一体で更新するなら鉄道信号メーカー、輸送計画・車両・乗務員・旅客案内を横断して再設計するなら鉄道系SIerや大手総合SIerが候補です。新規開発会社を加える場合は、設備メーカーとの責任分界と障害時の一元窓口をRFPへ記載します。

RFPには、対象線区、対象列車、既存システムの構成、連携データ、想定する障害シナリオ、指令員の承認フロー、旅客案内の配信先、稼働時間、可用性、障害時の縮退運転、監査ログ、権限管理、セキュリティ、教育、保守期間を記載します。機能一覧だけでなく、事故・大雨・設備故障・相互直通のようなケースを文章で示し、入力データ、制約、出力案、承認者、検収条件まで求めると、提案会社ごとの解釈差が小さくなります。

企画調査やPoCは、作業範囲と成果物を定めた準委任契約が適することがあります。要件が固まり、仕様どおりの機能を納品する段階は請負契約が候補になりますが、安全に関わる連携や既存設備との調整まで一律の完成責任を負わせられるかは、範囲を分けて検討する必要があります。準委任か請負かという名称だけで判断せず、成果物、作業時間、変更管理、瑕疵対応、知的財産権、再委託、秘密保持、データ返却、契約終了時の引継ぎを確認します。

検収は「画面が動くこと」だけにせず、代表的な障害シナリオで制約違反が出ないこと、案の根拠と影響範囲を表示できること、指令員が手動修正できること、通信断・データ欠損・サーバー障害から復旧できること、操作ログを追跡できることまで含めます。AIや最適化モデルを含む場合は、正解を一つに固定しにくいため、評価指標、再現可能なテストデータ、モデル更新の承認方法を契約書や仕様書へ落とし込みます。

運転整理システムの費用相場とコストの内訳

運転整理システム単体の公開見積はほとんどないため、以下の金額は2026年時点で発注計画を立てるための推定レンジです。一般的な業務システムの公開相場では、パッケージ導入10万〜100万円、カスタマイズ50万〜300万円、スクラッチ100万〜1,500万円以上という整理があります（出典: Harmonic Society「2025年版 業務システム開発費の相場と料金まとめ」、2025年）。しかし運転整理では、リアルタイム連携、二重化、24時間運用、安全性の検証、設備との接続、長期保守が加わるため、この数字をそのまま当てはめてはいけません。

過去ダイヤや障害データを読み込み、参照専用で整理案を表示するPoCは、1線区・6〜12か月で2,000万〜8,000万円程度を計画上の目安にします。ここでは、リアルタイム制御や旅客向けの確定配信ではなく、データの取込、制約モデル、シミュレーション、指令員による評価を主な範囲とします。金額の大小だけでなく、「熟練者の案と比べられるか」「提案理由を説明できるか」「データ欠損時に危険な案を出さないか」を成果条件に含めることが大切です。

既存の運行管理システムと連携し、指令員が案を比較・修正・承認し、ログや社内・旅客案内まで接続する支援システムは、1〜数線区で8,000万〜3億円程度、期間は12〜24か月程度を計画上の目安にします。複数線区で運行管理、輸送計画、車両・乗務員運用、旅客案内、インフラ更新まで統合する場合は、3億〜10億円超、24〜48か月程度を見込むことがあります。AI・数理最適化の追加モジュールは、データ整備や評価環境を含めて3,000万〜1.5億円程度の別枠になる場合があります。

実際の価格は、線区数、駅数、相互直通の有無、既存設備のメーカー、データの品質、冗長化方式、試験の範囲、現地立会い、教育、保守体制で変わります。公開された運転整理システム固有の価格統計ではないため、上記は予算取りとRFPの比較軸に使う数値と位置づけ、提案会社へは前提条件と含まれない項目を分けて提示してもらいます。

初期費用の内訳は、要件定義・業務分析、既存システムとの連携とデータ整備、画面・業務機能、最適化やAIエンジン、インフラ・冗長化・セキュリティ、試験・教育・移行に分けて確認します。計画段階では、要件定義10〜15%、連携とデータ整備20〜35%、画面・業務機能15〜25%、最適化・AI15〜30%、インフラ等10〜20%、試験等10〜20%を仮置きできますが、これは配分の目安であり、各工程の重なりや重複計上を提案会社へ確認します。

運用後は、監視、障害対応、脆弱性対応、OSやミドルウェアの更新、設備側の仕様変更、モデルの再評価、線区追加、訓練環境、データ保管が発生します。初期費用だけでなく、5〜10年の保守費、ライセンス費、クラウドや専用設備の費用、現場の教育工数、障害時の代替運用費を合わせた総保有コストで比較すると、安い初期見積が長期的には高くなるリスクを見抜けます。

委託先選定と見積比較で確認すべきポイント

委託先は、会社の知名度や提示価格だけで決めず、鉄道固有の業務理解、既存設備との接続力、安全・セキュリティの体制、現場へ定着させる力、長期保守の継続性を同じ条件で比較します。大手メーカー、信号・運行管理の専門会社、鉄道系SIer、業務システムに強い開発会社を候補へ入れる場合は、RFPの要件とシナリオをそろえることが公平な比較につながります。

提案会社には、同規模の線区、同様の相互直通、運行管理や信号設備との接続、車両・乗務員運用、旅客案内まで扱った実績を確認します。実績数だけでなく、どの範囲を自社が担当し、既存ベンダーと誰が調整し、障害発生時に何分以内にどの部署が対応したかを聞くことが重要です。日立は2025年にJR東日本と、鉄道運行管理・保守業務でAIエージェントの効果測定を目的とした共同検証に合意しており、AI活用が研究段階から現場検証へ進んでいる事例として確認できます（出典: 日立製作所「鉄道運行管理システムにてAIエージェントを活用する共同検証」、2025年）。

見積比較では、総額を横並びにするだけでなく、要件定義、データ連携、画面、制約エンジン、試験、教育、移行、保守を同じ項目へ割り当てます。「一式」と記載された項目には、人数、期間、単価、成果物、前提条件、除外条件を追加で求めます。特に、現地調査、既存設備側の改修、夜間試験、並行稼働、旅客案内との接続、セキュリティ診断、障害時のオンサイト対応が別料金になっていないか確認します。

価格以外では、提案の実現性を評価します。RFPの想定シナリオを実際のデータで再現できるか、案の比較指標を発注者と合意できるか、指令員が説明を受けて修正できるか、納期遅延時の段階リリースがあるか、データ・モデル・ソースコードの利用権が確保されるかを見ます。提案段階で質問へ具体的に答えられない会社は、開発後の追加費用や責任分界の曖昧さにつながる可能性があります。

運転整理システムは、列車運行と旅客サービスへ影響するため、情報システムだけでなく重要インフラとしてリスクを評価します。国土交通省は2026年4月に「鉄道分野における情報セキュリティ確保に係る安全ガイドライン」第6版を改定し、鉄道事業者の重要システムに対する対策を示しています（出典: 国土交通省「鉄道分野における情報セキュリティ確保に係る安全ガイドライン」、2026年）。RFPには、ネットワーク分離、認証、遠隔保守、脆弱性・パッチ管理、ログ監視、バックアップ、インシデント連絡、復旧訓練を含めます。

また、システム障害時に「既存ベンダーが対応するのか」「新規開発会社が一次窓口になるのか」「設備側の改修費を誰が負担するのか」を決めておきます。AIやクラウドを利用する場合は、学習データの持ち出し、モデル更新、外部サービス停止、通信遅延、出力の説明、手動運用への切替を契約に含めます。安全に関わる処理系へ接続する場合は、IEC 62425:2025など適用可能な規格や安全評価の要否を、対象範囲と責任分担を含めて専門家へ確認します。

発注後の要件定義・開発・テストを成功させる進め方

契約後は、発注者の業務知識とベンダーの技術知識を一つのプロジェクト体制へまとめます。企画時の仮説をそのまま仕様にせず、平常時、障害発生直後、復旧局面の業務を分け、誰がどの情報を見て何を承認するかを具体化します。開発期間を短く見せるために要件定義や試験を削ると、現場で使えない機能や本番切替の延期につながるため、段階ごとの完了条件を置きます。

最初に、解決したい課題をKPIへ変換します。たとえば、整理案作成にかかる時間、復旧までの時間、運休本数、駅の滞留、乗換え失敗、指令員の操作数、案内更新の遅れを計測対象とします。国土交通省の公表資料では、令和6年度の輸送障害は7,405件で、前年度より311件増加しています（出典: 国土交通省「鉄軌道輸送の安全に関わる情報（令和6年度）概要版」、2025年公表）。自社の障害件数や復旧時間を基準値として記録し、導入効果を「AIを使ったか」ではなく、輸送への影響がどう変わったかで評価します。

次に、データ辞書と業務ルールを作ります。列車、駅、番線、進路、編成、乗務員、勤務、接続、運休、折返し、留置などの用語を定義し、ルールの優先順位、例外、承認権限、手動修正の条件を整理します。熟練者へヒアリングするときは、通常の判断だけでなく「案を採用しなかった理由」「情報が欠けているときの見切り」「安全確認のために必ず見る項目」も記録すると、暗黙知を要件へ変換しやすくなります。

設計では、システムをデータ連携層、業務データ層、制約充足・数理最適化・シミュレーションの計算層、指令員向けHMI、社内・旅客向け配信層に分けて考えると責任範囲が明確になります。AIを使う場合も、AIが提案する部分、ルールエンジンが検証する部分、人が承認する部分を画面と設計書に示します。案の理由、違反している制約、影響を受ける列車や駅、代替案を表示できると、指令員が提案を信頼して使いやすくなります。

現場確認は、完成間際のデモだけで済ませません。ワイヤーフレーム、プロトタイプ、過去障害の再現、操作訓練を通じて、指令員が普段使う用語や画面遷移と合っているかを確かめます。南海電鉄と日立の2025年度効果検証では、約20日間かかっていた1か月分の車両運用計画が、システム活用により数日程度へ短縮されたと公表されています（出典: 日立製作所「南海電鉄にて乗務員運用計画と車両運用計画の自動作成システムを構築開始」、2026年）。運転整理でも、導入効果を具体的な作業時間と判断品質へ結び付けて検証します。

試験は、単体テスト、連携テスト、過去障害の再現、複数障害の組合せ、性能、冗長化、サイバーセキュリティ、操作性、旅客案内、手動運用への切替を分けて実施します。入力の遅延、同じ列車の重複、欠損データ、通信断、時刻変更、設備状態の不一致が起きたときに、危険な案を表示・配信しないことを確認します。検証用データには個人情報や機微な運行情報を含める場合があるため、マスキング、アクセス権、保管期限も決めます。

本番切替は、一度に全線区へ展開せず、1線区・限定機能・限定時間帯から始め、既存手順との並行稼働を経て広げます。切替判定には、重大な制約違反がないこと、想定時間内に案を作れること、指令員の訓練が完了していること、障害時に旧手順へ戻れること、24時間の連絡体制が整っていることを含めます。運用開始後も、採用された案と却下された案、手動修正、障害、旅客影響をログとして蓄積し、次の線区や次のモデル更新へ活用します。

よくある質問

運転整理システムの発注では、費用だけでなく、既存設備との接続、安全性、現場の承認手順、導入後の保守が同時に問われます。ここでは、発注前によくある質問へ直接回答します。

参照専用のPoCであれば、1線区・6〜12か月で2,000万〜8,000万円程度を計画上の目安にできます。本番連携、冗長化、安全試験、旅客案内、24時間保守まで含めると、8,000万〜3億円以上へ広がる可能性があります。公開された固有システムの価格ではないため、対象線区と連携範囲を決めてから複数社へ見積を依頼します。

指令員を不要にする前提ではなく、AIや数理最適化が作った案を安全制約で検証し、指令員が理由と影響を確認して承認する構成が現実的です。想定外の事象、設備情報の欠損、相互直通先との調整、旅客への説明などは、人が判断する範囲として残ります。提案の採用率、手動修正の内容、誤案の発生、判断時間を記録し、段階的に自動化の範囲を評価します。

現行システム構成図、線区と駅の一覧、ダイヤ・列車・設備・車両・乗務員データのサンプル、過去の障害記録、運転整理の業務手順、画面や帳票、承認権限、障害時の手動手順、旅客案内の配信先を準備します。すべてがそろわなくても、未確定項目と調査方法を明記すると提案の前提がそろいます。特に「既存システムを変えない」「将来は連携する」「本番制御へは接続しない」といった境界を最初に示すことが重要です。

同規模の線区や運行管理・信号設備との接続実績、現場の運転整理業務への理解、安全・セキュリティの体制、PoCから本番へ移す方法、障害時の24時間対応、データやモデルの帰属を確認します。大手メーカー、信号専門会社、鉄道系SIer、業務システム開発会社を候補に入れ、同じRFPと障害シナリオで提案してもらうと、会社ごとの向き不向きと見積の前提が比較しやすくなります。

まとめ

運転整理システムの発注・外注では、最初に「何を自動化するか」ではなく、「どの障害で、誰の判断を、どのデータで支援し、どの指標を改善するか」を決めます。既存の運行管理や信号設備を調査し、業務ルールとデータ辞書を整えたうえで、参照専用PoC、指令員承認型の支援、本番連携へ段階的に進めると、現場の信頼と安全性を確かめながら投資できます。

発注前は、対象線区と障害シナリオ、既存システムとの接続範囲、指令員の承認権限、手動運用への切替条件を決めます。RFPには初期費用だけでなく、試験・教育・保守・セキュリティ・障害対応を含め、5〜10年の総保有コストを比較できる形で記載します。

まず過去のダイヤ乱れを3〜5件選び、入力データ、現場の判断、実施した整理、旅客への影響、復旧までの時間を整理してください。その資料をもとに複数社へ相談し、自社線区の制約を理解した提案、説明可能な整理案、手動運用へ戻れる設計、導入後も改善できる契約を比較することが、運転整理システムを長く使うための第一歩です。

費用は、PoCで2,000万〜8,000万円程度、既存システム連携を含む支援で8,000万〜3億円程度、複数線区の大規模更新で3億〜10億円超という計画用レンジを起点にします。ただし、これは公開された固有システムの価格ではないため、RFPで連携範囲、試験、教育、保守、障害時の責任分界を明示し、5〜10年の総保有コストで比較することが大切です。国土交通省の安全・セキュリティ方針や、AI・最適化の検証事例も踏まえ、発注者が最終承認と業務知識を保持できる体制を整えます。

▼全体ガイドの記事
・運転整理システム開発の完全ガイド

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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