自動改札システム開発の発注/外注/依頼/委託方法について

自動改札システムの発注・外注では、改札機本体だけでなく、運賃計算、交通系IC・QR・タッチ決済、駅サーバー、監視、保守までを一つのサービスとして定義することが重要です。発注先を決める前に、対象駅・通路数・ピーク時の通過量・通信断時の動作・10年程度の運用まで整理できれば、過不足のない見積もりと契約条件を作れます。

この記事では、自動改札システムを発注・外注する方法を、発注形態の選択、RFPと要件整理、契約形態、費用相場、委託先の選び方、見積比較、PoCから本番稼働までの進め方に分けて解説します。鉄道会社だけでなく、空港アクセス、BRT、テーマパーク、スタジアム、大学、工場など、入退場と決済を自動化したい事業者にも活用できる内容です。

▼全体ガイドの記事
・自動改札システム開発の完全ガイド

自動改札システムの発注・外注で最初に決めること

自動改札システムは、改札機を購入して設置すれば終わる設備ではありません。利用者の媒体を読み取り、入出場を判定し、必要に応じて運賃を計算し、決済結果や通過ログを駅・センターへ連携し、係員が異常に対応できる状態までを含む業務システムです。発注の起点は機器の型番ではなく、実現したい駅務業務と利用者体験です。

最低限、改札機の制御ソフトウェア、IC・QR・クレジットカードなどの読み取り機能、運賃・入場判定、駅サーバー、センターサーバーまたはクラウド、駅内ネットワーク、監視盤、係員向け画面、ログ管理、遠隔保守を対象に含めます。改札機の交換やリーダー追加を伴う場合は、電源、通信配線、筐体加工、夜間施工、現場立会い、旧機器の撤去、予備機、教育、マニュアルも別項目で見積もる必要があります。

また、システム境界を曖昧にすると、決済会社との接続費や運賃改定対応が追加請求になりやすくなります。決済事業者、既存の券売機・精算機、交通系ICの事業者、ネットワーク会社、駅設備工事会社など、再委託先を含む責任分界を発注前に図で示してもらうことが大切です。

案件は、既存改札への機能追加、複数駅の駅務システム刷新、全駅規模の新規構築に分けて考えると、発注方式と予算を決めやすくなります。既存改札へのリーダーやカメラの追加は、設備資産を活用しながら短期間で検証しやすい一方、旧式プロトコルや制御ソフトウェアの制約を受けます。

駅務システム刷新は、運賃計算、駅サーバー、監視、精算、係員業務までを共通化する案件です。全駅更新は、機器の量産、駅ごとの夜間切替、旧新並行運用、障害時の切り戻し、長期保守を含む社会インフラ案件になります。どの規模に該当するかをRFPの冒頭に書くことで、各社が異なる前提で金額を出す問題を抑えられます。

自動改札システムの発注形態はどれを選びますか？

発注形態は、機器メーカーへの一括発注、機器とSIを分ける分離発注、複数社による共同体制の3つが基本です。どれが正解ということではなく、責任を一社へ集約したいのか、価格や技術を競わせたいのか、既存設備を活かしたいのかで選択が変わります。

一括発注は、改札機、駅務機器、監視、保守をまとめて導入したい場合に向いています。窓口が一本化され、機器とソフトウェアの組み合わせをメーカー側が保証しやすい点が利点です。特に、磁気券の搬送、複数枚処理、相互直通運転、定期券、精算、異常券など、駅務固有の例外処理が多い案件では、実績ある機器メーカーの知見を活用しやすくなります。

一方で、一括発注は特定ベンダーへの依存が強くなり、クラウド、決済、データ分析などの選択肢が狭くなる場合があります。RFPには、API仕様の開示、データの所有権、他社製機器との接続可否、契約終了時の移行支援、部品供給期間を明記し、一括発注の利便性と将来の変更可能性を両立させます。

分離発注では、改札機をメーカー、共通基盤や業務アプリをSIer、決済を決済事業者、ネットワークを通信会社へ委託するなど、得意領域ごとに選定できます。既存改札の再利用やクラウド連携を重視する案件では、分離発注によって技術選択の自由度を高められます。ただし、障害時に「機器は正常だがAPIが止まった」「ネットワークは復旧したが同期できない」といった境界問題が起こるため、発注者側に全体アーキテクトと統合テスト責任者が必要です。

共同体制は、機器メーカーとSIerが共同提案し、発注者が一つの契約または連名契約で進める方式です。大規模案件では、改札機の信頼性とクラウド・決済・データ連携の柔軟性を両立しやすくなります。共同体の代表者、各社の作業範囲、瑕疵対応、SLA、再委託、契約終了後の資産移管を契約書で一つにまとめることが重要です。

RFPと要件整理で自動改札システムの品質を決める

RFPは、ベンダーに希望を伝える文書ではなく、同じ条件で提案と見積もりを比較するための発注者側の基準です。現状の機器や運賃規則をすべて説明し切れない場合でも、未確定事項を明記し、提案で確認してほしい論点と、発注者が後日決める論点を分けておくと見積もりの精度が上がります。

まず、利用者と利用場所を定義します。鉄道駅なのか、無人駅なのか、空港や施設の入退場なのかで、必要な運賃計算、係員操作、本人確認、返金処理、営業時間外の対応が変わります。次に、対象媒体を交通系IC、磁気券、QR乗車券、クレジットカードのタッチ決済、顔認証などに分け、初期導入と将来追加を明示します。

運賃や料金については、入場・出場、定期券、企画券、乗継、相互直通、最安運賃、払い戻し、未収、二重タッチ、逆進入、不正通過、障害時の精算まで列挙します。処理性能は「速いこと」ではなく、ピーク時の1分間通過人数、連続タッチの間隔、改札機1台あたりの同時処理、ICタッチから扉が開くまでの目標時間として数値化します。ノートで紹介される0.2秒以内という目安も、絶対値ではなく、実際の利用環境で合意する性能要件として扱う必要があります。

自動改札は、通信が一時的に切れても利用者を止めない設計が必要です。ICの入出場判定を改札機または駅サーバー側で継続し、通信復旧後にログと決済結果を同期するハイブリッド構成が現実的です。RFPには、通信断が5分、30分、数時間続いた場合の入場可否、出場処理、残額更新、オフライン上限、復旧時の再送、重複取引の防止をシナリオで書きます。

可用性だけでなく、復旧時間、データ欠損の許容範囲、監視の通知先、夜間の駆け付け、部品交換、バックアップ、ロールバックも要件化します。国土交通省は2026年4月22日に「鉄道分野における情報セキュリティ確保に係る安全ガイドライン」第6版を改定しており、鉄道の情報システムでは重要インフラとしての継続性とセキュリティを前提にする必要があります。出典は国土交通省「鉄道分野における情報セキュリティ確保に係る安全ガイドライン」第6版（2026年）です。

顔認証を採用する場合は、顔の特徴情報を何の目的で取得し、どこで照合し、どの期間保存し、本人が利用しない選択や撤回をどう行うかをRFPに含めます。顔認証を使えない利用者の代替レーン、誤認識時の係員対応、照明やマスクによる認証率の変化もPoCで確認します。サービス事業者が生体情報を復元できない形式で管理する場合でも、委託先管理とログの保管場所を確認します。

タッチ決済では、カード情報を改札機や駅サーバーに保持しないトークン化、ネットワーク分離、アクセス制御、脆弱性対応、監査ログを検討します。PCI DSS v4.xでは、2025年3月31日以降に一部の旧要件が新要件へ置き換わり、該当要件は適合報告でN/Aとして扱う整理が示されています。出典はPCI Security Standards Council FAQ 1593（2025年）です。発注者は「PCI DSS対応済み」という一言で済ませず、自社と決済事業者のどこが対象範囲になるかを責任分界表で確認します。

自動改札システムの契約形態と責任分界

契約形態は、要件の確定度と成果物の測定しやすさで選びます。すべてを一つの契約に押し込むのではなく、構想・現状調査、要件定義、PoC、開発・機器調達、導入、保守を段階に分けると、発注者が判断しやすくなります。

請負契約は、成果物、納期、検収基準が明確な範囲に向いています。改札機の設置台数、画面仕様、API連携、試験項目、導入駅、操作マニュアルなどを成果物として定義し、完成したかを判定できるようにします。検収基準には、正常系だけでなく、通信断、二重タッチ、異常券、停電、復旧同期、ピーク負荷、係員の手動介入まで含めます。

請負で注意したいのは、要件変更がすべて追加費用になりやすいことです。運賃改定、決済ブランド追加、駅の営業時間変更、既存設備の不具合など、起こり得る変更をあらかじめ変更管理の対象として定義し、見積もり単価、承認者、納期への影響、緊急変更の扱いを契約に入れます。

現状調査、業務整理、要件定義、アーキテクチャ検討、PoC支援のように、作業を通じて発注者と一緒に答えを作る工程では、準委任契約が適する場合があります。成果を「完成したシステム」ではなく、調査報告書、要件一覧、検証結果、次工程の判断材料として定義すると、未知の多い案件でも無理のない進め方になります。

おすすめは、最初に短期間の構想・要件定義を行い、PoCの合格条件を満たした後に本開発へ移る段階契約です。PoCでは、1駅または数通路を対象に、IC・QR・タッチ決済を混在させ、通過速度、認証、通信断、停電、復旧、ログ整合性を検証します。本契約へ進むゲート条件、失敗した場合の撤退または方式変更、PoC成果物の本開発への引継ぎを事前に合意します。

自動改札システムの費用相場と見積もりの内訳

自動改札システムに一律の定価はありません。駅数だけでなく、通路数、ピーク処理量、対応媒体、運賃計算の複雑さ、既存機器の再利用、施工時間帯、監視センター、保守SLAで大きく変わります。以下の金額は2026年時点の初期検討用の目安であり、公開契約額と類似する駅務・決済・制御システムからの推定を含むため、入札価格や個別見積もりを保証するものではありません。

改札機本体は、IC中心の簡易型で1台あたり約650万〜700万円、高機能な磁気券搬送・複数枚分離・印字などを備えるタイプで約1,000万〜1,500万円以上という目安があります。既存筐体へリーダーやカメラを追加できれば、本体交換より費用と工期を抑えられる可能性がありますが、接続改修、認証基盤、現場工事、試験は別途必要です。

数駅から十数駅、数通路から数十通路の機能追加であれば、機器・リーダーに0.5億〜2億円、運賃・決済・認証連携に0.3億〜1.5億円、サーバー・ネットワーク・施工・試験に0.2億〜1.5億円を加え、総額1億〜5億円程度を初期仮置きする考え方があります。十数〜数十駅の駅務刷新は5億〜30億円程度、大規模な全駅更新は数十億〜数百億円に達することがあります。いずれも対象範囲を明記したうえで使うレンジです。

公開契約の例として、東京都交通局では、地下鉄各駅の駅務機器を監視・制御する自動改集札装置監視盤の買入れその1が2億5,542万円、その2が1億8,018万円として公表されています。これは監視盤更新の契約額であり、改札機1台や1駅の単価へ単純に割り戻せませんが、監視・制御だけでも大きな投資になることを示す参考事例です。出典は東京都交通局「令和7年度 公金支出情報」（2026年3月支払分）です。

初期費用だけで比較すると、安い提案が実際には高くなることがあります。保守運用費は、初期開発・機器調達費の年15〜20％程度という目安がありますが、24時間365日の監視、現地駆け付け、予備機、部品在庫、OS更新、証明書更新、決済ブランド対応、脆弱性対応、運賃改定を含むかで変わります。見積書では、保守基本料、従量課金、夜間作業、障害対応、追加開発を分けて記載してもらいます。

10年TCOでは、機器の購入費、ソフトウェア開発費、クラウド利用料、通信費、決済手数料、監視、保守、部品交換、予備機、現場作業、係員教育、運賃改定、証明書やOSの更新、EOLに伴う移行費まで含めます。クラウド化はサーバー購入を減らせても、通信断対策、冗長化、ログ保管、監視、データ転送料が必要です。初期費用と月額費用を別々に見るのではなく、想定利用量と契約期間をそろえて比較します。

委託先の選び方と見積比較のポイント

委託先は知名度や改札機の納入実績だけで決めません。運賃計算と例外処理、既存機器との接続、低遅延の実測、オフライン継続、決済・顔認証のセキュリティ、24時間365日保守、部品・OS・APIの長期サポート、データ移管の条件を同じ質問票で確認します。提案書の見栄えより、障害時に誰が何分以内に何をするかが明確かを重視します。

提案比較では、機器費、ソフトウェア費、連携費、施工費、試験費、教育費、保守費、クラウド・通信費を分け、税抜・税込、初期・月額、オプション・必須をそろえます。見積もりの前提駅数、通路数、同時通過数、データ移行量、対応媒体、夜間作業回数も横並びにします。A社は顔認証を含み、B社は別見積もりという状態では、金額だけを比較できません。

技術評価は、実機での通過性能、通信断からの復旧、運賃計算の正確性、二重請求防止、監視アラート、係員操作、ロールバックを確認します。実績を聞くときは「何駅に納入したか」だけでなく、同じ媒体、同じピーク量、同じ運賃の複雑さ、障害時の対応件数、保守継続年数、EOL移行の実績まで尋ねます。守秘義務で詳細を出せない場合でも、匿名化された規模と役割分担は確認できます。

「通信断が30分続いた場合に、どの機能を継続できますか」「復旧後の同期で同じ取引を二重計上しない仕組みは何ですか」「通過性能はどの実機・データ・負荷で測定しますか」と質問します。さらに、「運賃改定や決済ブランド追加の費用と納期は何ですか」「部品とOSは何年間供給されますか」「障害時の一次受付、切り分け、現地駆け付けの担当は誰ですか」と聞けば、提案書だけでは見えない運用力を比較できます。

契約条件では、ソースコードや設定情報の利用権、API仕様書、テストデータ、運用ログ、設計書の納品範囲を確認します。再委託先の承認、個人情報の取扱い、脆弱性報告、監査権、損害賠償の上限、サービス終了時のデータ返却、別ベンダーへの移行支援も比較対象です。安い見積もりでも、将来の移行に高額な出口費用があるなら、実質的なTCOは下がりません。

発注からPoC・本番稼働までの進め方

発注後は、要件定義、方式設計、PoC、詳細設計・開発、総合試験、移行、本番稼働、運用改善の順で進めます。既存改札へのリーダー追加とAPI連携なら、要件定義から本番まで9〜18か月、新規の運賃計算・駅サーバー・改札機制御まで含むと18〜36か月、筐体や搬送機構の新規開発と大規模展開では3〜5年以上を見込むことがあります。納期は開発だけでなく、機器の製造、認証、夜間施工、教育、運輸安全上の確認を含めて計画します。

PoCは、動くデモを見て満足する場ではありません。実際の駅または同等の設備で、IC、QR、タッチ決済を混在させ、連続タッチ、複数枚、濡れ・折れた券、残額不足、定期券境界、通信断、停電、復旧同期、係員による手動処理を検証します。顔認証を含む場合は、照明、マスク、逆光、誤認識、本人確認の代替手段、利用停止・撤回まで確認します。

合格条件は、通過時間、誤判定率、処理件数、障害検知時間、復旧時間、ログの欠損数、二重計上ゼロ、係員操作の完了時間などの数値にします。条件を満たさなかった場合に、改札機を交換するのか、エッジ処理を増やすのか、機能を段階導入するのかを決める意思決定者も明確にします。

本番移行では、旧システムと新システムの並行稼働、駅ごとの切替、夜間作業、ロールバック、係員教育、利用者への案内を計画します。全駅を一度に切り替えるのではなく、代表駅、利用量の多い駅、通信条件の厳しい駅を段階的に選ぶと、未知の障害を小さくできます。切替前には、旧機器へ戻す手順と戻せる期限を実機で確認します。

稼働後は、障害分析、運賃改定、決済ブランド追加、端末証明書更新、OSやミドルウェアの脆弱性対応、部品のEOL管理をロードマップ化します。2025年10月には、関東の鉄道事業者11社局がクレジットカード等のタッチ決済による後払い乗車サービスの相互利用を発表しており（出典: 東京メトロほか11社局「タッチ決済による後払い乗車サービスの相互利用」、2025年）、決済方式は導入後も拡張されます。初回契約に「将来の追加は別途」とだけ書くのではなく、追加接続の設計条件と単価の考え方を定めておくことが重要です。

よくある質問（FAQ）

自動改札システムの発注では、費用だけでなく、発注範囲、契約、保守、将来拡張について同じ疑問が繰り返されます。ここでは、初回相談の前に確認しておきたい質問へ直接回答します。

既存改札への機能追加や数駅規模では1億〜5億円程度、十数〜数十駅の駅務刷新では5億〜30億円程度を初期検討の目安にできます。ただし、これは機器台数だけでなく、運賃計算、決済、サーバー、施工、試験、保守の範囲で変わる推定値です。正確な金額を得るには、駅数より先に通路数、ピーク通過量、対応媒体、既存設備、保守条件をRFPへ記載します。

クラウド化だけで必ず安くなるわけではありません。低遅延が必要な改札判定はエッジまたは駅側に置き、運賃マスタ、集計、分析、認証、料金施策をセンターやクラウドへ置くハイブリッド構成が現実的です。通信断時の継続処理、復旧同期、冗長化、監視、通信費、データ保管費まで含めて10年TCOで比較します。

改札機、駅務機器、運賃計算、24時間保守を一括で任せたい場合は、駅務機器メーカーを中心に比較します。既存設備を活用したクラウド、決済、データ連携を重視する場合は、SIerやクラウドに強い会社を組み合わせる方法もあります。会社名から決めるのではなく、実績、責任分界、PoCの実測、長期サポート、データ移管条件を同じ評価表で確認して選定します。

まとめ

自動改札システムの発注・外注を成功させるポイントは、改札機だけでなく、運賃計算、決済、駅サーバー、センター、監視、保守までを一つの業務サービスとして整理することです。案件を既存改札への追加、駅務刷新、全駅更新に分類し、機器一括、分離発注、共同体制から自社に合う形を選びます。

RFPでは、通路数やピーク処理量、対応媒体、通信断時の動作、セキュリティ、ログ、SLA、EOL、検収条件、データとAPIの移管条件を具体化します。見積もりは初期費用だけでなく、保守、クラウド、通信、決済、部品、教育、将来拡張を含む10年TCOで比較し、PoCの合格条件を満たしてから本契約へ進めることが安全です。

発注前に要件と責任分界を整えれば、ベンダーの提案力を引き出し、導入後の追加費用や障害時の押し付け合いを減らせます。自社だけで業務要件やRFPをまとめることが難しい場合は、構想・要件定義から開発会社の選定、見積比較、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を創業。