ダイヤ管理システム開発の発注/外注/依頼/委託方法について

ダイヤ管理システムの発注・外注は、鉄道業務の制約と周辺システムとの連携を先に整理し、パッケージ・クラウド・スクラッチを比較して段階的に契約する進め方が適しています。

本記事では、ダイヤ管理システムを外部の開発会社へ依頼する際の発注形態、RFPと要件整理、契約形態、2026年時点の費用相場、委託先の選び方、見積書の比較ポイントを順番に解説します。ダイヤ作成だけでなく、車両・乗務員運用、運行管理、旅客案内、異常時対応まで含めて、自社に合う発注計画を作るための判断材料をまとめています。

▼全体ガイドの記事
・ダイヤ管理システム開発の完全ガイド

ダイヤ管理システムを発注する前に知っておきたい全体像

ダイヤ管理システムは、列車の時刻を入力するだけの表計算ソフトではありません。路線、駅、番線、信号、閉そく、列車種別、車両性能、停車時間、追越し、折返し、接続、車両基地、乗務員の資格や勤務条件などを考慮し、実施可能な輸送計画を作成する業務システムです。発注では、画面の見た目よりも、どの制約をシステムが検証し、どのデータを正本として周辺システムへ渡すかを決めることが重要です。

ダイヤ管理システムは、基本ダイヤや改正ダイヤ、臨時列車、工事・イベント時の実施ダイヤを計画する領域を担います。運行管理システムは、実際の列車位置や信号設備などを監視し、運行中の指令業務を支援する領域です。旅客案内や時刻表、チケット販売のシステムは、確定した列車情報を利用者向けに展開する領域となります。乗務員勤務や車両運用も密接に関係しますが、契約上は別システムとなる場合が多いため、発注前に責任分界とデータ連携を図にします。

たとえば、ダイヤの確定データをXMLやAPIで運行管理へ渡すのか、ファイル連携にするのかによって、設計・試験・障害対応の費用が変わります。東芝の輸送計画システムも、運転曲線、時隔、ダイヤ、車両・乗務員運用を支援し、運行管理やチケット販売などの周辺システムへの出力に対応すると説明しています（出典: 東芝「輸送計画システム」、2026年確認）。このような連携範囲を自社のRFPにも明記します。

パッケージは、運転曲線、時隔、ダイヤ図、車両運用、乗務員運用などの標準機能を活用しやすく、導入期間を短くしやすい方式です。クラウドやSaaSは、サーバーの保守やバージョンアップの負担を抑え、複数拠点で同じデータを扱いやすい方式です。東芝のTrueLineは、輸送計画の基本機能をクラウドサービスとして提供し、月額課金やトライアルを特徴として掲げているサービスです。出典は東芝「輸送計画ICTソリューション TrueLine」の2026年確認情報です。

スクラッチ開発は、独自の駅構造、相互直通運転、特殊な車両、固有の勤務規則、既存装置の特殊なインターフェースなどを細かく反映しやすい反面、要件定義と試験の負荷が大きくなります。実務では、標準パッケージを中核にして、固有マスタ、API、帳票、最適化ロジックだけを追加するハイブリッド方式も有力です。一路線・一基地のPoCから始める場合は、最初から全社共通の完成形を作らず、標準機能で変えられる業務と追加開発が必要な業務を見分けます。

ダイヤ管理システムの発注・外注の進め方

発注は、いきなり開発会社へ「ダイヤを自動作成できるシステムを作ってください」と依頼するのではなく、現状把握、要件整理、方式比較、RFP作成、提案・見積比較、契約、PoCまたは設計、開発、試験、切替の順に進めます。特に鉄道業務では、現場が暗黙に判断している制約を言語化しないと、完成後に「使えるが実務では使えない」システムになりやすいです。

最初に、基本ダイヤ、実施ダイヤ、臨時変更、工事ダイヤ、車両運用、乗務員運用、構内入換、運転整理、旅客案内の業務を一覧化します。現行のExcel、紙、CAD、既存データベース、手作業のチェック表を集め、入力者、承認者、出力先、保存期間、版管理の方法も記録します。過去のダイヤを数本選び、どのデータが欠けているか、駅名や列車種別の表記揺れがあるか、旧システムの世代差が残っているかを確認します。

この段階で「作成時間を何時間から何時間にするか」「違反チェックの見落としをどう減らすか」「ダイヤ改正前の残業をどれだけ減らすか」「異常時の代替案を何分以内に提示するか」といったKPIを置くと、委託先の提案を機能数ではなく成果で比較できます。担当者へのヒアリングでは、通常時だけでなく、相互直通、臨時列車、事故、災害、車両故障、乗務員不足の場面も聞き取ります。

RFPには、対象路線数、駅数、番線数、列車本数、車両形式、運転時隔、最小停車時間、折返し条件、接続条件、乗務員の資格・拘束・休憩条件、異常時の想定を記載します。さらに、利用者の役割、承認経路、同時編集の有無、版管理、監査ログ、検索・出力形式、処理時間、稼働時間、バックアップ、障害時の切戻し条件まで定義します。「自動作成」と書く場合は、何を最適化するのか、ハード制約に違反した案を出さないのか、担当者の手修正後に再計算できるのかも指定します。

成果物も、画面一覧だけでなく、業務フロー、データ項目表、制約一覧、連携一覧、移行計画、試験計画、操作マニュアル、教育計画、運用設計、障害対応手順まで示します。提案依頼の前に秘密保持契約を結び、実データを渡す場合は列車番号や駅名の匿名化、アクセス権限、保管場所、削除方法を決めます。RFPの粒度が揃うほど、各社の見積条件が揃い、安いが前提条件を省いた見積を見抜きやすくなります。

候補が絞れない場合は、全機能のデモを求めるより、一路線・一基地・数か月分の過去ダイヤを使ったPoCを実施します。検証するのは、スジを描けるかだけではありません。駅や番線の制約を登録できるか、単線の行違いや追越しを検知できるか、車両・乗務員のつながりを確認できるか、違反理由を現場担当者が理解できるか、ExcelやXMLでデータを出せるか、旧システムと結果を照合できるかを確認します。

PoCの評価表には、利用者の操作時間、制約違反の検知率、出力データの正確性、再計算時間、学習のしやすさ、障害時の代替操作を入れます。AIや数理最適化を使う場合も、結果を人が説明できること、優先順位を変えられること、手修正の履歴を残せることを評価します。日立の南海電鉄向け事例では、従来数か月かかっていた乗務員運用計画を約1週間程度、車両運用計画を従来の約20日から数日程度へ短縮する効果検証が紹介されています（出典: 日立 Digital Highlights、2026年確認）。ただし、自社で同じ効果が出るとは限らないため、自社データを使って測定します。

ダイヤ管理システムの契約形態と役割分担

ダイヤ管理システムは、業務の不確実性が高いまま開発を始めると、要件変更と追加費用が発生しやすい分野です。すべてを一つの請負契約にまとめるのではなく、調査・要件定義・PoC、確定した機能の開発、運用保守を分けると、発注者と受託者の責任が明確になります。契約書だけでなく、要件定義書、仕様書、検収基準、変更管理表を一体で管理します。

準委任は、発注者と受託者が協力して調査、要件整理、PoC、プロジェクト支援を進める契約に向いています。成果物の完成を約束するより、専門人材の稼働と業務支援を委託する性質が強いため、現場ヒアリングで新たな制約が見つかる段階に適しています。作業範囲、稼働時間、会議体、報告内容、情報管理、途中終了時の引き継ぎを明記します。

請負は、仕様、成果物、納期、検収基準が固まった機能の開発や移行に向いています。ただし、請負だから変更費用が発生しないわけではありません。列車本数の増加、駅構造の変更、連携先の仕様変更、追加の冗長化、試験ケースの増加は、変更管理の対象となります。発注者側の承認遅延やデータ提供遅延が納期へ与える影響も、契約前に合意します。

本番運用では、障害の重大度ごとの連絡時間、復旧目標、代替運用、バックアップからの復元、ダイヤデータのロールバック、休日やダイヤ改正期の問い合わせ体制をSLAに定めます。RTOは復旧までの目標時間、RPOはどの時点までデータを戻せるかの目標です。単に「24時間監視」と書くのではなく、監視対象、通知先、一次切り分け、現地対応、再発防止報告まで分けて確認します。

列車ダイヤ、駅・番線・車両・乗務員のマスタ、利用者の操作履歴は、発注者が継続的に利用できるデータです。契約終了時のデータ返却形式、バックアップの消去、API仕様書の引き渡し、ソースコードの扱い、第三者ライブラリのライセンス、追加改修を別会社へ依頼できる条件を確認します。特にスクラッチ部分を受託会社だけが変更できる状態にすると、将来の保守費用とベンダーロックインが大きくなるため、運用移管と教育を契約に含めます。

ダイヤ管理システムの費用相場とコストの内訳

ダイヤ管理システムの公開定価は少なく、費用は路線数、列車本数、駅・番線数、車両形式、相互直通の有無、既存システムとの連携、冗長化、セキュリティ、データ移行、試験範囲で大きく変わります。以下は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億円から数十億円規模になる可能性があります。

一般的なシステム開発では、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点というように、社内で重み付けを先に決めます。評価者には輸送計画、運行指令、情報システム、現場、経営企画を含め、特定部署だけで決めないようにします。

ダイヤデータは、変更内容によって実際の輸送計画へ影響する重要な情報です。権限のない利用者が変更できないこと、承認前の案と確定版を区別できること、操作履歴と差分を追跡できること、バックアップから復元できること、連携先へ誤った版を配信しないことを要件にします。クラウドを採用する場合は、データの保管場所、通信経路、認証方式、委託先の再委託、障害時の代替環境、ネットワーク断時の業務継続を確認します。

国土交通省は、鉄道分野の特性に応じた情報セキュリティ対策の目標を示す安全ガイドライン第6版を2026年4月22日に改定しています（出典: 国土交通省「鉄道：情報セキュリティ対策」、2026年）。発注時は、アクセス制御、暗号化、脆弱性管理、監視、インシデント報告、バックアップ、BCP、委託先管理をガイドラインに照らして確認します。安全に関わる業務では、開発会社の説明だけでなく、自社の安全管理部門と情報セキュリティ部門が受入基準を確認します。

切替では、旧システムをすぐ停止せず、過去ダイヤのリプレイ、旧新結果の照合、並行稼働、承認・取消・ロールバック訓練を行います。切替日をダイヤ改正日に合わせる場合は、失敗時に旧システムへ戻す判断者、戻す期限、紙や既存ファイルで業務を継続する方法、周辺システムへ誤配信した場合の訂正手順を決めます。完成したシステムを納品して終わりではなく、現場が安全に使い続けられる状態を検収の条件にします。

よくある質問

ここでは、発注担当者が委託先へ相談する前に疑問になりやすい点を回答します。費用や期間は事業者の規模と連携範囲で変わるため、質問への回答を自社の要件整理やRFPへ反映します。

標準的な輸送計画機能を短期間で導入したい場合はパッケージやクラウドが適しています。独自の駅構造、相互直通、車両・乗務員の特殊な制約、既存装置との固有連携が中心の場合はスクラッチや追加開発を検討します。最初から一つに決めず、PoCで標準機能の適合範囲を確認し、固有部分だけを追加する方式が現実的です。

小規模PoCで500万〜1,500万円、パッケージやSaaSの小規模導入で1,000万〜3,000万円、中規模の追加開発で3,000万〜1億円、独自制約を含むスクラッチで1億〜3億円程度が予算策定用の推定レンジです。路線数、列車本数、外部連携、データ移行、試験、冗長化、セキュリティで変動します。初期費用だけでなく、月額、保守、改修、教育、切替、5年間の運用費を含めて比較します。

対象路線、駅・番線、列車本数、車両・乗務員の条件、作成・承認・出力の業務フロー、現在のデータ形式、連携先、性能、権限、監査ログ、バックアップ、セキュリティ、移行、教育、保守、検収基準を書きます。自動作成やAIを求める場合は、目的関数、ハード制約、手修正、結果の説明、再計算、評価データまで指定します。対象外と発注者の作業も明記すると、見積の前提を揃えやすくなります。

クラウドかオンプレミスかだけで安全性は決まりません。認証、権限、暗号化、操作履歴、バックアップ、脆弱性管理、監視、ネットワーク断時の代替運用、障害時の復元、委託先管理を要件とし、自社の安全管理基準と国土交通省の鉄道分野向けガイドラインに照らして評価します。クラウドを採用する場合は、ダイヤ作成系と運行中の制御系をどのように分離し、どのデータをどの経路で連携するかを設計段階で決めます。

外注できます。一度に全路線を対象にせず、一路線・一基地・一つの帳票・限定した連携から始め、PoCで操作性と制約の再現性を確認してから段階的に広げます。少人数運用では、担当者が自分でマスタを変更できること、紙や既存ファイルへ戻れること、教育と問い合わせ窓口が用意されることを重視します。大規模事業者向けの機能をそのまま導入するのではなく、導入目的と運用体制に合う範囲で発注します。

まとめ

ダイヤ管理システムを発注・外注するときは、最初にダイヤ作成、車両・乗務員運用、運行管理、旅客案内のシステム境界とデータ連携を整理します。そのうえで、現状業務、制約、データ、利用者、承認、異常時対応を棚卸しし、成果物と検収基準まで含むRFPを作成します。

方式は、パッケージ、クラウド、スクラッチ、ハイブリッドを自社の業務適合性と5年TCOで比較します。要件が固まらない工程は準委任やPoC、確定した開発は請負、稼働後はSLA付きの保守契約に分けると、変更リスクを管理しやすくなります。見積書では、開発費だけでなく、移行、連携、試験、教育、切替、セキュリティ、保守、将来改修を同じ条件で比較します。

委託先を選ぶときは、鉄道の類似実績、制約モデルの理解、現場の操作性、周辺システムとの連携、障害時の切戻し、運用移管、セキュリティ、2026年時点のガイドライン対応を確認します。一路線・一基地のPoCから始め、現場が安全に使い続けられることを検証しながら段階的に拡張することが、ダイヤ管理システムの発注を成功させる基本です。

▼全体ガイドの記事
・ダイヤ管理システム開発の完全ガイド

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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