自動改札システムの発注は、業務範囲と責任分界を決めることから始まります。RFPと契約を整えてPoCで確認し、そのうえで本番へ進めると、追加費用や障害時の混乱を抑えられます。
発注形態、要件整理と費用、委託先の選定から稼働までを順に見ます。全体像は、自動改札システム開発の完全ガイドもご覧ください。
▼全体ガイドの記事
・自動改札システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
自動改札システムの発注・外注で最初に決める項目
自動改札システムは、利用者の媒体を読み取り、入出場を判定し、必要に応じて運賃を計算する仕組みです。決済結果や通過ログを駅・センターへ連携し、係員が異常に対応できる状態までを含みます。改札機を購入して設置すれば終わる設備ではないため、発注の対象は改札機の本体にとどまらず、周辺の仕組み全体になります。
発注の起点は、実現したい駅務業務と利用者体験に置きます。機器の型番は、そのあとで検討します。
改札機以外の発注範囲
見積もり漏れを防ぐため、機器本体以外の範囲は次の4項目に分けて整理します。
- 機能：制御ソフト、IC・QR・クレジットカードの読み取り、運賃・入場判定が対象です。
- システム・運用：駅サーバー、センターサーバーまたはクラウド、駅内ネットワーク、監視盤、係員画面、ログ管理、遠隔保守。
- 交換・追加工事：機器交換やリーダー追加では、電源・通信配線・筐体加工・夜間施工・立会い・旧機器撤去・予備機・教育・マニュアルを別項目で見積もります。
- 責任分界：決済会社、既存の券売機・精算機、交通系IC事業者、ネットワーク会社、駅設備工事会社、再委託先を、発注前に図で示してもらう。
境界が曖昧だと、決済接続費や運賃改定への対応が追加請求になりやすくなります。
最初に分類する3つの案件タイプ
案件の規模を分類すると、発注方式と予算を決める手がかりになります。RFPの冒頭に分類を書き、各社の見積もり前提をそろえておきます。
- 既存改札への機能追加：設備を生かして短期の検証を行える一方、旧式プロトコルや制御ソフトの制約があります。
- 複数駅の駅務刷新：運賃計算や駅サーバーなどの仕組みを、駅をまたいで共通化します。
- 全駅規模の新規構築・更新：機器の量産や夜間切替、旧新並行運用、障害時の切り戻し、長期保守を伴う社会インフラ案件。
自動改札システムの発注形態の選び方
主な発注形態は、機器メーカーへの一括発注、機器とSIを分ける分離発注、複数社の共同体制の3つです。どの形態にするかは、責任の集約、価格・技術の競争、既存設備の活用のうち何を重視するかで決まります。
機器メーカーへの一括発注が向くケース
一括発注を検討するときは、窓口を集約できる効果と、駅務特有の例外処理への対応力を見ておきます。
- 機器をまとめて導入：改札機や駅務機器、監視、保守を一括で頼むと、窓口を一本化でき、メーカーが組み合わせを保証しやすくなります。
- 例外処理が多い案件：磁気券搬送・複数枚処理・相互直通運転・定期券・精算・異常券などで、機器メーカーの知見を生かせます。
一方で、一括発注では特定ベンダーへの依存が強まり、クラウドや決済、データ分析の選択肢が狭まる場合があります。そのため、RFPにはAPI仕様やデータ所有権、他社機器との接続条件を明記します。契約終了時の移行支援や部品供給期間も、あわせて書いておきます。
分離発注と共同体制の使い分け
発注方式ごとの担当範囲と利点は、次のとおりです。比べると、自社に合う体制が見えてきます。
- 分離発注：機器はメーカー、基盤・アプリはSIer、決済は事業者、通信は通信会社に委託する形です。
- 分離発注の利点：既存改札の再利用とクラウド連携を組み合わせられ、技術選択の幅が広がります。
- 共同体制：メーカーとSIerが共同で提案し、一契約または連名契約で進める形。
- 共同体制の利点：大規模案件で、機器の信頼性と連携の柔軟性を両立できます。
分離発注では、「機器は正常だがAPIが停止」「復旧後も同期しない」といった境界の問題が起こり得ます。そのため、発注者側に全体アーキテクトと統合テスト責任者を置く必要があります。
共同体制では、代表者と各社の作業範囲を契約書に書き、瑕疵対応やSLA、再委託、契約終了後の資産移管も同じ契約書にまとめます。
RFPと要件整理の進め方
RFPは、同じ条件で提案と見積もりを比べるための発注基準です。現状の機器や運賃規則を説明しきれない場合でも、未確定の事項は明記します。提案で確認する論点と、発注者があとで決める論点を分けておくと、見積もりの精度が上がります。
業務要件で先に定義する項目
利用者と場所を先に定義します。鉄道駅、無人駅、空港、施設の入退場では、運賃計算、係員操作、本人確認、返金、営業時間外対応の扱いが異なります。
対象媒体は、交通系IC、磁気券、QR乗車券、クレジットカードのタッチ決済、顔認証などに分けて書きます。初期導入と将来の追加も、それぞれ明示します。
業務要件では、運賃・料金と処理性能の前提をそろえ、RFPに運賃処理、例外処理、性能要件を記載します。
- 運賃処理：入出場・定期券・企画券・乗継・相互直通・最安運賃・払い戻し・未収まで対象にします。
- 例外処理：二重タッチ・逆進入・不正通過・障害時の精算の扱いを対象にします。
- 性能要件：ピーク時の1分間通過人数や連続タッチ間隔、1台あたり同時処理数、タッチから開扉までの目標時間を数値で示します。
一般に紹介される0.2秒以内という目安は、絶対値ではありません。そのため、実際の利用環境に合わせて性能要件を合意しておきます。
非機能要件と障害時の動作
通信が切れても利用者を止めないためには、改札機または駅サーバーで入出場の判定を続け、復旧後にログと決済結果を同期するハイブリッド構成が現実的です。
RFPでは、通信断が5分、30分、数時間続く状況を想定し、それぞれの処理条件を決めます。あわせて、可用性や復旧時間、データ欠損の許容範囲も定義しておきます。
- 通信断時：入場の可否、出場、残額の更新、オフライン上限の扱い。
- 復旧時：再送と重複取引防止の手順を決めます。
- 運用継続：通知先、夜間の駆け付け、部品交換、バックアップ、ロールバックを要件に含めます。
国土交通省は2026年4月22日に、「鉄道分野における情報セキュリティ確保に係る安全ガイドライン」を第6版に改定しました。鉄道の情報システムでは、重要インフラとして継続性とセキュリティを前提にします（出典：国土交通省「鉄道分野における情報セキュリティ確保に係る安全ガイドライン」第6版、2026年）。
個人情報・決済・データの扱い
個人情報と決済の要件は分けて整理し、RFPや責任分界表に反映します。顔情報と決済データは、取り扱いを後から決めると手戻りが大きくなるため、次の5項目を先に確認します。
- 顔情報：取得目的、照合場所、保存期間、利用拒否や撤回の方法。
- 顔認証の運用：代替レーンの用意と、誤認識時に係員が動く手順。
- 顔認証の検証：照明やマスクによる精度の変化を、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月支払分）。
保守費と10年TCOの考え方
初期費用だけで比べると、安い提案が実際には高くつくこともあります。保守運用費は、初期開発・機器調達費の年15〜20％程度が目安です。ただし、含まれるサービスによって変わります。
保守の内容は、24時間365日の監視や現地の駆け付け、予備機、部品在庫の有無で確かめます。そのうえで、OS・証明書更新、決済ブランド対応、脆弱性対応、運賃改定の扱いも確認します。
見積書では、保守基本料、従量課金、夜間作業、障害対応、追加開発を分けて書いてもらいます。10年TCOには、導入から運用、更新までの費用を含めます。
- 導入費：機器購入、ソフト開発、現場作業、係員教育など。
- 運用費：クラウド、通信、決済手数料、監視、保守、部品交換、予備機の費用。
- 更新費：運賃改定、証明書・OS更新、EOLに伴う移行費が対象です。
クラウド化でサーバーの購入は減らせます。一方で、通信断対策や冗長化、ログ保管、監視、データ転送料は必要です。
初期費用と月額費用は、想定利用量と契約期間をそろえて比べます。
委託先の選び方と見積比較のポイント
委託先は、運賃計算や例外処理、既存機器との接続、低遅延の実測、オフライン継続を、同じ質問票で確認して選びます。知名度や改札機の納入実績は、その判断材料の一つにとどめます。
決済・顔認証のセキュリティや、24時間365日の保守、部品・OS・APIの長期サポート、データ移管条件も比べます。特に重視したいのは、障害時に誰が何分以内に何をするかです。
提案比較の評価軸
金額と技術の前提をそろえておくと、提案の差を判断できます。金額は、初期と月額、税抜と税込、必須とオプションに分けて並べます。
- 費目：機器、ソフト、連携、施工、試験、教育、保守、クラウド・通信ごとの区分。
- 見積前提：駅数や通路数、同時通過数、データ移行量、対応媒体、夜間作業の回数を各社でそろえる。
- 技術評価：通過性能、通信断からの復旧、運賃計算、二重請求の防止、監視、係員操作、ロールバック。
A社の見積もりに顔認証が含まれ、B社では別料金になっているなら、金額を直接比べられません。まず対応範囲をそろえることが必要です。
実績については、納入駅数だけでなく、媒体やピーク量、運賃の複雑さ、障害対応件数、保守年数、EOL移行の経験も尋ねます。なお、守秘義務がある場合でも、匿名化した規模と役割分担は確認できます。
見積もり前に委託先へ聞く質問
障害対応や将来の変更条件を聞くと、提案書には表れにくい運用力を比べられます。見積もりの前に、次の5つを委託先へ直接確認します。
- 通信断が30分続いた場合、どの機能を継続できますか。
- 復旧後の同期で取引を二重計上しない仕組みは何ですか。
- 通過性能はどの実機・データ・負荷で測定しますか。
- 運賃改定や決済ブランド追加の費用と納期は何ですか。
- 部品とOSは何年間供給されますか。障害時の一次受付、切り分け、現地駆け付けの担当は誰ですか。
契約では、ソースコード・設定の利用権や、API仕様書・テストデータ・運用ログ・設計書の納品範囲を確認します。
再委託の承認、個人情報、脆弱性報告の3点は、特に比べておきます。監査権、賠償上限、データ返却、別ベンダーへの移行支援も、あわせて確認します。たとえ安くても、出口費用が高ければ、実質TCOは下がりません。
発注からPoC・本番稼働までの進め方
発注後は、要件定義と方式設計、PoCを経て、詳細設計・開発に進みます。そのあと、総合試験、移行、本番稼働、運用改善と続きます。
リーダー追加とAPI連携は、要件定義から本番まで9〜18か月が目安です。新規の運賃計算・駅サーバー・改札機制御を含む場合は、18〜36か月が目安になります。
筐体や搬送機構の新規開発と大規模展開では、3〜5年以上かかることもあります。製造や認証、夜間施工、教育、運輸安全の確認も、納期に含めて考えます。
PoCの合格条件
PoCは、実駅または同等の設備を使い、媒体の混在や例外処理を検証する場です。合格条件は、次の4つの場面での挙動から決めます。
- 乗車媒体：IC、QR、タッチ決済を混在させた連続タッチや複数枚の試行。
- 券・残額：濡れた券や折れた券、残額不足、定期券の境界。
- 障害対応：通信断、停電、復旧同期、係員の手動処理での挙動。
- 顔認証：照明、マスク、逆光による誤認識、代替本人確認、利用停止・撤回の手続き。
合格条件は数値で決めておきます。主な対象は通過時間、誤判定率、処理件数です。このほか、障害検知と復旧時間、ログ欠損数、二重計上ゼロ、係員操作時間も数値で定めます。
未達だった場合に、機器交換、エッジ処理の追加、段階導入のどれを選ぶかも決めておきます。あわせて、その判断を下す意思決定者も明確にします。
移行と稼働後の保守
移行と稼働後の対応を段階的に組み立てると、未知の障害を小さくできます。
- 切替準備：旧新システムの並行稼働、駅ごとの切替、夜間作業、ロールバック、係員教育、利用者案内の計画。
- 段階導入：代表駅、利用量の多い駅、通信条件の厳しい駅の順に切り替えます。
- 復旧確認：切替前に、旧機器へ戻す手順と期限を実機で確かめます。
稼働後は、障害分析や運賃改定、決済の追加、証明書更新、脆弱性対応、部品の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設計を支援するパートナーへ、早めに相談できます。
▼全体ガイドの記事
・自動改札システム開発の完全ガイド
▼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を創業。