ダイヤ管理システムの発注は、業務と連携範囲を整理したうえで、方式と契約を比べながら進めます。PoCを経て段階的に導入すると、現場で使える安全な輸送計画につながります。
全体像は、ダイヤ管理システム開発の完全ガイドもご覧ください。
▼全体ガイドの記事
・ダイヤ管理システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
ダイヤ管理システムの発注前に知っておきたい全体像
ダイヤ管理システムは、時刻を入力するだけの表計算ソフトとは別物です。路線や駅の構造、信号や閉そくの条件、列車種別や車両性能まで考慮します。
さらに、停車時間や追越し、折返しや接続も扱います。車両基地や乗務員の資格、勤務条件も含みます。実施可能な輸送計画を作る業務システムです。
発注する側は、画面の見た目より先に、システムが検証する制約と、周辺へ渡す正本データを決めておきます。
ダイヤ管理と運行管理・旅客案内の違い
発注者は、システムごとの担当範囲とデータ連携を発注前に整理し、責任の境目を図にしておきます。
- ダイヤ管理：基本・改正・臨時列車や工事・イベント時の実施ダイヤの計画。
- 運行管理：列車位置や信号設備の監視と、運行中の指令業務の支援。
- 旅客案内：確定した列車情報を、時刻表やチケット販売など利用者向けに展開する役割。
- 周辺業務：乗務員勤務や車両運用と密接に関係するものの、契約上は別システムとなる場合が多い領域です。
連携方式がXML・APIかファイル連携かによって、設計・試験・障害対応の費用が変わります。
東芝の輸送計画システムは、運転曲線や時隔、ダイヤ、車両・乗務員運用を支援します。運行管理やチケット販売への出力にも対応すると説明されています（出典：東芝「輸送計画システム」、2026年確認）。自社のRFPにも、必要な連携範囲を明記します。
パッケージ・クラウド・スクラッチ・ハイブリッドの比較
方式ごとの向き不向きを比べると、自社で標準化する範囲と追加開発の範囲を決めやすくなります。
- パッケージ：運転曲線、時隔、ダイヤ図、車両・乗務員運用の標準機能を使えます。
- クラウド・SaaS：保守や更新の負担を抑えつつ、複数拠点で同じデータを扱えます。
- スクラッチ：独自の駅構造や車両、勤務規則、特殊な連携に合わせて作り込めます。
- ハイブリッド：標準機能を中核に、固有マスタやAPI、帳票、最適化ロジックを追加する方式。
パッケージは、導入期間を短くしやすい方式です。一方で、スクラッチ開発は、相互直通運転や既存装置とのインターフェースにも対応できます。ただし、要件定義と試験の負荷は大きくなります。
たとえば、東芝のTrueLineは、輸送計画の基本機能をクラウドで提供し、月額課金やトライアルを特徴に掲げています（出典：東芝「輸送計画ICTソリューション TrueLine」、2026年確認）。
一路線・一基地のPoCでは、標準機能に業務を合わせられる部分と、追加開発が必要な部分を見分けます。こうすれば、全社共通の完成形を最初から作らなくても検証できます。
ダイヤ管理システムの発注・外注の進め方
発注は、まず現状を把握して要件を整理し、方式を比べてRFPを作る流れで進みます。次に、提案と見積を比べて契約を結びます。その後は、PoCまたは設計を経て、開発、試験、切替へ進みます。
最初の現状把握を省けないのは、現場が暗黙に判断している制約を言語化しておかないと、完成しても実務で使えないシステムになりやすいからです。
現状業務とデータの洗い出し
現行業務と記録媒体を洗い出し、入力から承認、出力までの流れを追います。
- 業務：基本・実施・臨時・工事ダイヤ、車両・乗務員運用、入換、運転整理、旅客案内。
- 媒体：Excel、紙、CAD、既存データベース、手作業のチェック表。
- 管理方法：入力者、承認者、出力先、保存期間、版管理。
過去のダイヤを数本選んで、データの欠落、駅名や列車種別の表記揺れ、旧システムの世代差を調べます。
KPIには、作成時間の短縮や違反チェックの見落とし削減を置きます。改正前の残業削減や、異常時に代替案を示すまでの時間も含めます。これらで比べると、提案を機能数より成果で評価できます。
ヒアリングでは通常時のほかに、相互直通や臨時列車の扱いも確認します。また、事故や災害、車両故障、乗務員不足といった異常時の想定も聞いておきます。
RFPに書く業務条件と成果物
業務条件をそろえておくと、各社の提案と見積の前提を比べられます。そのため、RFPには対象規模や運行条件を具体的に示します。
- 輸送条件：路線・駅・番線数、列車本数、車両形式、時隔、最小停車時間・折返し・接続条件。
- 乗務員条件：資格、拘束、休憩、異常時の想定。
- システム条件：役割と承認、同時編集や版管理、監査ログ、検索・出力、処理・稼働時間。
- 運用条件：バックアップ、障害時の切戻し、移行・試験・教育・運用設計。
「自動作成」は、最適化の対象やハード制約違反の扱い、手修正後の再計算の可否まで指定しておきます。
成果物は画面一覧だけにせず、業務フローとデータ項目表まで含めます。さらに、制約・連携一覧、移行・試験計画、操作マニュアルも対象にします。そのほか、教育計画や運用設計、障害対応手順まで求めます。
提案依頼の前には秘密保持契約を結びます。実データを渡す場合は、列車番号や駅名を匿名化したうえで、権限や保管場所を決めます。また、削除方法も取り決めておきます。
RFPの粒度をそろえておくと、前提条件が抜けた安価な見積を見分けやすくなります。
PoCでの操作性と制約の再現性の検証
候補を絞り込めない場合は、一路線・一基地の過去数か月分のダイヤでPoCを行います。全機能のデモを見るより、自社業務に近い条件で検証できます。
- 制約：駅・番線、単線の行違い・追越し、車両・乗務員のつながり。
- 操作と説明：違反理由や最適化結果を説明でき、優先順位を変更できるか。
- 連携：Excel・XML出力と旧システムとの結果照合ができるか。
評価表には、操作時間や制約違反の検知率、出力精度を記録します。さらに、再計算時間や学びやすさ、障害時の代替操作も残します。
AIや数理最適化を使うなら、結果の説明、優先順位の変更、手修正の履歴も評価の対象にします。
日立の南海電鉄向け事例では、乗務員運用計画を従来の数か月から約1週間程度に短縮する効果検証が紹介されています。車両運用計画でも、従来の約20日から数日程度への短縮が示されています（出典：日立 Digital Highlights、2026年確認）。
ただし、自社で同じ効果が出るとは限りません。そのため、自社データで効果を測定します。
ダイヤ管理システムの契約形態と役割分担
要件が不確実なまま開発を始めると、要件変更と追加費用が生じやすくなります。そこで、調査や要件定義、PoCと、確定機能の開発や運用保守を分けると、責任が明確になります。
契約書だけでなく、要件定義書と仕様書も一体で管理します。さらに、検収基準と変更管理表も、同じ流れで扱います。
準委任と請負の工程ごとの使い分け
準委任と請負は、要件がどこまで確定しているかに応じて、工程ごとに選びます。制約が見つかる調査や要件整理には、準委任が適しています。
- 準委任：調査、要件整理、PoC、プロジェクト支援など、専門人材の稼働と業務支援。
- 請負：仕様、成果物、納期、検収基準が固まった開発や移行。
準委任では、作業範囲や稼働時間、会議体を明記します。さらに、報告や情報管理、途中終了時の引き継ぎも決めておきます。
請負でも、変更費用は発生します。列車本数や駅構造、連携先仕様の変更は、変更管理の対象です。冗長化や試験ケースの変更も対象に含まれます。
また、発注者の承認やデータ提供の遅れが納期に与える影響も、契約前に合意しておきます。
SLA・データ・知的財産・保守移管の取り決め
本番運用と契約終了後の継続利用に備えて、SLAやデータ、知的財産の条件を契約で決めておきます。
- SLA：重大度ごとの連絡時間、復旧目標、代替運用、復元、ロールバック、休日・改正期の問い合わせ体制。
- 復旧目標：RTOは復旧までの目標時間、RPOはどの時点までのデータを戻せるかの目標です。
- データ：発注者が継続利用できるダイヤ・各種マスタ・操作履歴の返却形式、バックアップ消去、API仕様書の引き渡し。
- 知的財産：ソースコード、第三者ライブラリのライセンス、別会社へ改修を依頼する条件。
- 運用移管：受託会社だけがスクラッチを変更する状態を避け、保守費やロックインを抑えるため、教育も契約に含めます。
「24時間監視」という表記で済ませず、監視対象や通知先、一次切り分けを分けて確認します。さらに、現地対応や再発防止報告の範囲も見ておきます。
ダイヤ管理システムの費用相場とコストの内訳
公開されている定価は少なく、費用は路線や列車、車両の規模によって変わります。相互直通や連携、冗長化も費用に影響します。さらに、セキュリティや移行、試験範囲の広さも関わります。
示す金額は、2026年の予算策定用の推定レンジで、公開価格ではありません。そのため、同じRFPで複数社から見積を取ります。
導入方式別の初期費用と期間の目安
方式ごとの費用と期間を並べると、予算と対象範囲を検討しやすくなります。
- 調査・要件定義・小規模PoC：500万〜1,500万円、2〜6か月。
- パッケージ・SaaS小規模導入：1,000万〜3,000万円、3〜9か月。
- 中規模導入・追加開発：3,000万〜1億円、9〜18か月。
- スクラッチ・大幅カスタマイズ：1億〜3億円、12〜24か月。
- 複数会社・相互直通・OT連携の統合：3億円から数十億円規模の可能性。
小規模PoCでは、一路線・一基地で過去ダイヤを再現し、制約モデルや操作性を調べます。出力連携も、あわせて確かめます。
小規模導入では、初期設定やマスタ移行、教育、軽微な連携までを費用に含みます。なお、月額利用料やクラウド費用は別途確認します。
中規模では、複数路線や車両・乗務員計画、周辺連携、並行稼働を含みます。大幅カスタマイズには、独自制約や最適化、複数連携に加えて、冗長化や総合試験も含みます。
一般的なシステム開発では、2026年の人月単価が60万〜200万円程度との相場があります（出典：SIA「システム開発の費用・相場 2026年版」、2026年）。
ダイヤ管理では、業務コンサルタントや鉄道業務に詳しい要件担当が必要です。加えて、UI設計や連携・試験・セキュリティの担当も欠かせません。工数は、画面数を基準に決めないようにします。
見積書で確認する開発費以外のコスト
見積は費用の種類ごとに分けてもらい、要件定義、基本・詳細設計、画面・帳票などの見積項目を別々に示してもらいます。項目が分かれていると、どの作業が含まれ、どの作業が対象外かを比べやすくなります。そのうえで、対象外の作業や責任分界も確認します。
- 開発：要件定義、設計、画面・帳票、制約チェック、最適化。
- 導入：外部連携、データ移行、テスト、セキュリティ、教育、切替。
- 基盤と管理：プロジェクト管理、ハードウェア、クラウド、バックアップ。
運行管理や旅客案内、チケット販売との連携は、インターフェースごとに費用と責任分界を示してもらいます。乗務員・車両管理との連携も、あわせて示してもらいます。
データクレンジングや旧データ変換、過去ダイヤの再現試験が、別料金になっていないかも確認します。
初期費用が安くても、運用費用が別に発生する場合があります。利用料やクラウド基盤、監視などが該当します。さらに、バックアップや問い合わせ、OSやミドルウェアの更新なども対象になります。
法令・ガイドライン対応や機能改善、繁忙期の休日対応も、別費用になる場合があります。
比べるときは、初期費用に加えて、5年間の総保有コストで見ます。たとえば、保守費を初期開発費の年10〜15％程度と仮置きする方法もあります。
ただし、保守費は、24時間監視や現地対応、SLA、追加改修を含むかどうかで変わります。率だけで判断しないようにします。
ランニングコストと将来の変更費用
SaaSやクラウドでは、利用量や監視水準によって月額が変わります。予算を仮置きする場合も、公開定価とは区別して扱います。
- 利用量：ユーザー数、路線数、機能モジュール、データ容量、API利用量。
- 運用水準：バックアップ世代、監視レベル、障害時の代替環境。
- オンプレミス：サーバー更新、バックアップ装置、ウイルス対策、保守。
仮置きの金額は、月30万〜200万円、年360万〜2,400万円程度になるケースもあります。これは公開定価ではなく、推定値です。
稼働後もダイヤ改正や駅・車両の変更が起こります。さらに、相互直通先や勤務規則の変更、セキュリティ強化も続きます。
設定変更とプログラム改修の境界や人月単価を確認します。さらに、リリース試験や緊急変更の割増、データ返却費の扱いも確かめます。変更要求は記録したうえで、優先順位と費用を両者で合意します。
委託先の選定と見積比較で確認すべきポイント
委託先は、会社の規模や知名度だけでなく、鉄道・軌道・バスなどの輸送計画への理解、既存設備との連携、現場への運用移管を基準に選びます。
大規模鉄道の経験が地域交通に合うとは限りません。また、一般業務システムに強くても、制約モデルや改正、異常時の切戻しを理解できなければ、要件定義に時間がかかります。
類似実績の見方：会社名より案件の中身
実績の案件条件を確かめると、自社業務との近さを判断できます。導入社名の一覧で評価を終えず、案件の中身まで見ます。
- 対象規模：路線、列車本数、駅・番線、車両・乗務員運用、相互直通。
- 構成：運行管理・旅客案内との連携、クラウドまたはオンプレミス。
- 運用：導入後の保守、利用者へのヒアリング、画面や試験仕様の確認。
日立システムズと広島電鉄の事例では、少人数での運用や操作性を意識した、クラウド型システムの共同開発が紹介されています（出典：日立システムズ「広島電鉄株式会社様 SmartDia・HyperDia事例」、2026年確認）。
担当者が少ない場合は、マスタ登録や権限変更、改正を誰が担うか確認します。さらに、帳票や問い合わせの一次対応も、担当者を決めておきます。
見積比較の並べ方：総額と前提条件
見積条件を同じ項目でそろえて、費用と発注者側の負担を比べます。
- 費用：初期、月額・年額、保守、追加開発単価、移行、連携、教育、試験、切替。
- 前提：対象外、発注者作業、再委託、納期、担当経験、検収条件。
- 運用：障害対応、ハードウェア、クラウド、バックアップ。
極端に安い提案では、移行や連携試験、教育が別料金になる場合があります。さらに、セキュリティや切戻し、保守の一部も、別料金のことがあります。
評価軸には、価格や業務適合性、鉄道知識、連携実績があります。さらに、操作性や拡張性、セキュリティも評価します。運用移管や管理、5年TCOも含めます。
配点の例は、価格30点、機能・業務適合25点、実績15点です。残りの配点は、品質・安全・セキュリティ15点、保守・移管10点、提案体制5点です。
評価者には、輸送計画や運行指令、情報システムの担当を入れます。現場や経営企画も加え、特定部署だけで決めないようにします。
安全・セキュリティ・切替リスクの質問項目
ダイヤデータの変更は輸送計画に影響するため、安全管理と切替の受入条件を委託先に確認します。
- データ保護：権限、承認前後の版、操作履歴、差分、復元、誤配信防止の要件。
- クラウド：保管場所、通信経路、認証、再委託、代替環境、回線断時の継続方法。
- 対策基準：アクセス制御や暗号化、脆弱性管理や監視、事故報告、バックアップ、BCP、委託先管理を照合します。
- 受入確認：自社の安全管理・情報セキュリティ部門が基準を確認します。
- 切替訓練：過去ダイヤ再生、旧新照合、並行稼働、承認・取消・ロールバックを試します。
国土交通省は、鉄道向け安全ガイドライン第6版を2026年4月22日に改定しました（出典：国土交通省「鉄道：情報セキュリティ対策」、2026年）。
旧システムは、切替の直後に止めません。改正日に切り替える場合は、旧環境へ戻す判断者と期限、紙や既存ファイルでの継続、誤配信の訂正手順を決めておきます。そのうえで、安全に使い続けられる状態を検収条件に含めます。
よくある質問
費用や期間は、事業者の規模と連携範囲で変わります。以下の回答は、要件整理やRFP作成の参考にしてください。
ダイヤ管理システムはパッケージとスクラッチのどちらが良いですか？
標準的な輸送計画機能を短期間で導入したい場合は、パッケージやクラウドが候補です。
独自の駅構造や相互直通、車両・乗務員の特殊制約、既存装置との固有連携が中心なら、スクラッチや追加開発を検討します。
一つに決めてしまう前に、PoCで標準機能の適合範囲を確かめ、固有部分だけを追加する方法が現実的です。
ダイヤ管理システムの発注費用はいくらですか？
予算策定用の推定レンジは、小規模PoCが500万〜1,500万円、パッケージ・SaaS小規模導入が1,000万〜3,000万円です。
中規模追加開発は3,000万〜1億円、独自制約を含むスクラッチは1億〜3億円程度です。費用は、路線や列車、連携の範囲で変わります。移行や試験、冗長化、セキュリティの扱いでも変わります。
比べるときは、初期費用に加えて、月額や保守、改修を含めます。さらに、教育や切替、5年間の運用費も比べます。
RFPには何を書けば開発会社から比較できる提案をもらえますか？
提案条件と運用条件をそろえるため、RFPには次の内容を記載します。
- 対象・業務条件：路線・駅・番線・列車と車両・乗務員条件、業務フローやデータ形式、連携先や性能、権限、監査ログ。
- 運用・受入条件：バックアップ、セキュリティ、移行、教育、保守、検収。
- 自動作成・AI：目的関数、制約、手修正、結果の説明、再計算、評価データ。
対象外と発注者側の作業も明記すると、見積の前提をそろえやすくなります。
クラウドでダイヤデータを管理しても安全ですか？
安全性は、クラウドかオンプレミスかよりも、どう運用するかで左右されます。
まず、認証や権限、暗号化の仕組みを決めます。そのうえで、履歴やバックアップ、脆弱性管理を定めます。さらに、監視やネットワーク断時の代替運用、復元、委託先管理も含めます。
評価は、自社基準と国土交通省の鉄道向けガイドラインに照らして行います。あわせて、ダイヤ作成系と運行中の制御系の分離と、データの連携経路も設計時に決めます。
小規模な鉄道事業者でもダイヤ管理システムを外注できますか？
外注できます。全路線を一度に対象とせず、一路線・一基地・一帳票・限定連携から始めます。
PoCで操作性と制約の再現性を確かめてから広げます。少人数運用では、自社でのマスタ変更と、紙や既存ファイルへの復帰を重視します。加えて、教育や問い合わせ窓口も大切です。
大規模事業者向けの機能をそのまま導入せず、目的と運用体制に合う範囲で発注します。
まとめ
発注時は、ダイヤ作成や車両・乗務員運用、運行管理、旅客案内の境界と、データ連携を整理します。そのうえで、現状業務や制約、データを洗い出します。さらに、利用者や承認、異常時対応も確認します。
成果物と検収基準を含むRFPを作り、方式は業務適合性と5年TCOで比べます。要件が未確定の工程は準委任やPoCで進め、確定した開発は請負で委託します。稼働後は、SLA付きの保守として切り分けます。
見積では、開発費のほか、移行や連携、試験をそろえて比較します。さらに、教育や切替、セキュリティも含めて比べます。保守や将来改修も、同じ表で扱います。
委託先の鉄道実績や制約の理解、操作性を確認します。さらに、連携や切戻し、運用移管も見ます。加えて、セキュリティと、2026年時点のガイドライン対応も確かめます。
一路線・一基地のPoCから始めて、安全に使えることを検証しながら段階的に広げることが、発注を成功させる基本です。
▼全体ガイドの記事
・ダイヤ管理システム開発の完全ガイド
▼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を創業。