自動改札システム開発は、現状調査、要件定義と方式選定、設計・試験・移行の順に進みます。この順で進めると、開業直前の手戻りを抑えやすくなります。
全体像や費用の目安、見積もりの取り方も、順に見ていきます。全体像は自動改札システム開発の完全ガイドもご覧ください。
▼全体ガイドの記事
・自動改札システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
自動改札システム開発の全体像
自動改札システムは、乗車資格を判定し、通行可否と運賃の収受を処理する社会インフラです。その設計は、駅とセンターを結ぶ業務システムとして行います。さらに、交通系ICカードや磁気券、QR乗車券、クレジットカードのタッチ決済を扱う場合は、それぞれの認証・精算ルールを統合します。
自動改札システムの定義と構成要素
自動改札システムは、乗車券や決済手段を読み取り、入出場、運賃、扉の開閉を自動で処理します。
利用者が目にする改札機は、そのシステムの入口にあたります。
構成要素は、駅に置く機器、サーバー、それらを支える基盤の3つに分かれます。
- 駅の機器：改札機、券売機、精算機、監視盤
- サーバー：駅サーバー、センターサーバー
- 基盤：決済・認証基盤、ネットワーク、遠隔保守機能
裏側では、入出場履歴や売上、障害ログ、係員操作履歴が連携します。
交通系ICカードでは、カード情報の読み取り、残額や定期券区間の判定、入出場データの更新が必要です。通信障害時には、後同期も行います。さらに、相互直通運転や改札外乗換えがある路線では、最安運賃や連絡運輸などの例外処理も必要です。
改札機・駅・センター・決済の4層構成
システムの責任範囲は、次の4層に分けて整理します。
- 改札機：低遅延処理、不正通過や券詰まりの検知
- 駅内：ネットワーク、駅サーバー、端末管理と一時集約
- センター：運賃マスタ、利用実績、精算、遠隔監視
- 決済・認証：外部サービスとの認証・精算連携
クラウドを使う場合も、判定をすべて通信先に任せる設計は避けます。通信断やセンター障害が起きたときも、最低限の入出場判定は改札側で続けます。
復旧後は、データを重複なく同期できるハイブリッド方式が現実的です。
改札の応答時間は、ラッシュ時の通過人数や異常券も含めた実測値で合意します。
応答時間は「0.2秒以内」と決め打ちせず、連続タッチなども試します。こうした性能条件は、使いやすさと安全性を左右します。
自動改札システム開発の進め方
開発は、構想・現状調査から始まり、要件定義と方式選定、PoCを経て、設計・開発、試験、移行へ進みます。運用改善は、その後に続きます。機器の納期だけで計画すると、運賃や異常系の検証が遅れます。
既存駅を止めずに更新する場合は、早い段階から夜間切替とロールバックを計画します。早めに計画しておくと、開業直前の大きな手戻りを防げます。
1. 構想・現状調査と対象範囲の決定
調査では、駅数や改札通路数、設置場所を確認します。ピーク時の1分間通過人数も、あわせて把握します。既存機器については、メーカー、型式、通信プロトコルを一覧にします。
初期リリースで対応する券種も決めます。普通券や定期券、企画券に加えて、交通系IC、QR、タッチ決済をどこまで含めるかを整理します。
地方鉄道、BRT、テーマパークでは、鉄道と同じ機器を導入するとは限りません。たとえば、入場券と会員認証だけに絞る選択肢もあります。
現場では、次の異常時に誰がどう対応するかを、発注側と開発会社で確認します。
- 乗車券：残額不足、定期券の区間外、連続タッチ
- 通行・機器：逆方向への進入、停電、券詰まり
- 通信・係員：通信断、係員呼出し、復旧対応
「止められない業務」と「復旧後に処理できる業務」に分けると、エッジとセンターのどちらが何を受け持つかがはっきりします。
開発規模は、小規模な機能追加、十数駅規模の刷新、全線更新のいずれかに分類します。この区分も、調査段階で決めます。
2. 要件定義・方式選定・PoCの実施
要件定義では、機能要件と非機能要件を分けて数値化します。機能要件には、券種や運賃規則、決済ブランドを含めます。係員操作や返金も機能要件に入れ、売上集計と遠隔再起動も、同じ区分で扱います。さらに、例外時の精算担当者と操作画面も決めます。
非機能要件には、ピーク処理量や平均・最大応答時間、稼働率を定めます。
通信が途切れた場合に、改札側で続ける時間と復旧の目標も決めます。さらに、ログ保存期間や予備機の台数、保守受付時間も決めておきます。「高速」や「安定」だけで終わらせず、測定できる条件にします。
事業規模と既存設備に応じて、要件を満たす方式を次の観点で比較します。
- 機器一体型：鉄道向けパッケージと専用機器
- 既存機器活用：改札を生かしたクラウド連携
- 独自開発：主要機能のスクラッチ開発
- 共同体制：機器メーカーとSIerの連携
小規模事業者は既存端末や決済サービスを活用できます。そのうえで、独自の運賃・会員・MaaSの部分だけを追加すると、期間と保守負担を抑えられます。
大規模事業者は、低遅延のエッジ処理を使い、改札機を横断して更新できるセンター基盤と組み合わせるのが適しています。
PoCでは、1駅または数通路で、IC、QR、タッチ決済を混在させて試します。
正常な一人通過だけでなく、次のような異常系も検証します。
- 読み取り：連続タッチ、複数枚、読み取り失敗
- 利用者・券：電池切れ、濡れた券、手動精算
- 障害・決済：通信断、停電、再送、二重請求防止
顔認証を検討する場合は、照明やマスクがある状態での認識と、誤認識の扱いを試します。さらに、登録解除、代替通路、同意撤回も試験項目に含めます。
3. 詳細設計・開発・試験・切替の流れ
設計から本番切替までの主な作業を、次の順に進めます。
- 改札機制御、運賃計算、決済を含む機能群を疎結合に設計し、監視、ログ、遠隔保守も同じ方針で扱います。
- 外部APIのタイムアウトとリトライ、冪等性を決め、障害通知やデータの正本、再処理の方法も決めておきます。
- 決済サービス停止時に改札を閉じるか、一定条件で通過させて後精算するかを合意します。
- 実際の運賃パターンと過去の障害記録で試験し、新旧システムを並行稼働させます。
- 入出場履歴と売上を突合し、誤差がないことを確かめます。
- 駅ごとの夜間切替とロールバック、係員教育を準備し、利用者への案内と問い合わせ窓口も、あわせて用意します。
決済停止時の扱いは、事業者の運用とリスク許容度によって異なります。
ロールバックでは旧機器に戻せるようにしておき、切替の準備が整ったあとに本番環境へ移行します。
既存改札へのリーダー追加は、要件定義から本番まで9〜18か月が目安です。一方、新規の運賃計算や駅サーバーを含む場合は、18〜36か月かかります。
自動改札システムの費用相場とコストの内訳
自動改札システムには、一律の定価はありません。費用を左右するのは、駅数よりも改札通路数やピーク処理量です。
対応する乗車券や既存設備の再利用の可否によっても、金額は変わります。さらに、施工時間帯と保守SLAも、金額に影響します。
公開されている価格が少ない領域のため、ここに示す金額は、機器単価や過去の更新例などから推定した目安です。NotebookLMでリサーチした内容の整理と、類似システムからの推定を含みます。入札価格や個別案件の見積もりを保証するものではありません。
機器費・ソフトウェア費・施工費の目安
費用を比べるときは、機器、ソフトウェア、設置・試験の範囲を分けて見ます。
- 改札機：本体のほか、読み取り端末やカメラの追加も検討します。
- ソフトウェア：機能ごとに開発範囲を分けます。
- 設置・試験：設備、工事、教育を見積もります。
ソフトウェア費には、改札機制御と運賃計算、決済連携が含まれます。券種・マスタ管理も、ここに入ります。
駅・センターサーバーと監視の開発に加えて、ログ分析と係員画面の開発も含まれます。
駅内ネットワーク、サーバー、無停電電源は見積もりに入れます。
設置工事と夜間切替の費用も見込みます。
試験機と予備機、教育費も発生します。
IC中心の簡易型改札機は、1台あたり約650万〜700万円が目安です。
一方、高機能型は約1,000万〜1,500万円以上で、磁気券の搬送や複数枚の分離、印字を備えます。
既存筐体を再利用できれば、全交換より初期費用を抑えられる可能性があります。ただし、再利用する場合は、配線や電源、通信に加えて、保守責任に伴う追加費用も確認します。
2026年7月、東芝と日立は、主要3社の既存改札機に顔認証を追加する仕組みを発表しました（出典：東芝ニュースリリース、2026年）。同じ月には、次の4社も既存改札機に顔認証を追加する仕組みを発表しています。
- 東武鉄道
- オムロン
- 日本信号
- パナソニック コネクト
東京都交通局の2025年契約では、自動改集札装置監視盤の更新が2億5,542万円でした（出典：東京都議会公営企業委員会速記録、2025年）。ただし、対象範囲が異なるため、1駅単価には割り戻せません。この契約額からは、監視や制御だけでも大きな予算になることが分かります。
案件規模ごとの総額の目安
規模ごとの初期概算は、次の幅を仮置きとして使えます。
- 数駅〜十数駅の機能追加：総額1億〜5億円程度
- 十数〜数十駅の駅務刷新：総額5億〜30億円程度
機能追加の内訳例は、改札機とリーダーが0.5億〜2億円です。運賃・決済・認証連携は0.3億〜1.5億円、ネットワークなどは0.2億〜1.5億円です。ネットワークなどには、サーバーや施工、試験も含まれます。
顔認証や複数ブランドの決済を加えると、上限を超えやすくなります。券売機との連携や24時間保守も、費用を押し上げる要因になります。
採用する機能ごとにオプションとして分けて見積もると、追加費用の内訳が見えてきます。
刷新では、共通基盤や全駅への展開、夜間切替も総額に影響します。機器台数に加えて、教育や予備機、監視センターも含めて検討します。
大規模更新の参考値として、JR東日本の424駅で約460億円、JR西日本の253駅で約110億円という事例があります。いずれもリサーチノートにある過去の事例で、現在の個別見積ではありません。対象範囲も異なるため、両事例は単純に比べられません。
保守運用の費用は、初期開発・調達費の年15〜20%程度が目安です。保守費は、現地駆け付けや部品在庫の有無で変わります。さらに、証明書更新と脆弱性対応も、保守費を左右します。
自動改札システムの見積もりを取る際のポイント
同じ前提で比べられるRFPを作ると、見積もりの精度が上がります。発注側は、機器やソフト、施工を分けて提示するよう求めます。試験と移行、教育と保守は、それぞれ別の項目として挙げてもらいます。
初期費用が安い提案でも、保守や部品供給が別契約の場合があります。そのため、初期費用と10年程度のTCO（総所有コスト）を並べて比べます。
RFPに記載する数量・性能・例外処理
数量や運用の条件は、次の情報をRFPに記載します。
- 設備：駅数、通路数、方向、既存機器の型式
- 利用：ピーク時通過人数、券種、運賃規則
- 工事：施工可能な時間帯
- 性能：処理件数、応答時間、障害・復旧条件
性能条件には、1分あたりの処理件数、平均・最大応答時間、同時障害数を指定します。
通信断が続くあいだの継続時間と復旧目標も、RFPに記載します。
運賃改定や決済ブランドの追加も見込みます。マスタ更新を止めずに行えるか、改定前後の履歴を保持できるかも確認します。
例外処理には、残額不足や期限切れの定期券、重複タッチを含めます。入場記録のない出場や精算差額も確認します。
読み取り不能と扉の閉塞も確かめておきます。駅サーバーやセンターの停止も、対象になります。
各ケースについて、表示と音声、係員への通知を決めます。売上への反映と再処理の方法も、あわせて決めます。
検収基準は、「問題なく動くこと」より具体的に決めておく必要があります。テストデータや測定方法を定め、合格値と証跡の形式まで定義します。
機器・ソフト・保守の責任分界による発注先の選び方
発注体制には、次の選択肢があります。
- 一括発注：駅務機器メーカーへまとめて依頼
- 共同体制：機器メーカーとSIerが連携
- 分離発注：既存改札を使い、ソフトを別会社へ依頼
一括発注は責任の所在が分かりやすい一方、特定ベンダーに依存しないか、データやAPIが閉じていないかを確認します。
分離発注は柔軟ですが、障害の切り分けと全体の性能保証を誰が担うのかを、契約で明確にします。
改札機の納入実績に加えて、運賃計算の例外処理を確認します。エッジとクラウドの責任の分け方や、通信断時の継続についても確かめます。監視や長期サポートの体制も比べます。
部品、OS、APIの長期サポートと、24時間365日の監視も確認します。
データ所有権、仕様開示、再委託先も質問します。
契約が終わるときのデータ移管や、追加開発の単価も確かめます。
顔認証やタッチ決済を使うなら、提案の範囲がどこまで含まれるかも見ます。
個人情報保護やPCI DSSへの対応、監査ログ、委託先管理まで提案に含められる会社を選びます。
初期見積に含めるセキュリティ・保守・TCO
初期見積もりでは、セキュリティ、個人情報・決済、長期運用の対策を分けて確認します。
- セキュリティ：資産管理、通信保護、脆弱性対応、事故時の備え
- 情報の取扱い：顔認証や決済データの保護と本人の選択肢
- 長期運用：保守、更新、教育を含む5年・10年のTCO
情報システムの停止は、利用者の移動や収入に直結します。
国土交通省の「鉄道分野における情報セキュリティ確保に係る安全ガイドライン」を参照します（出典：国土交通省、2026年版）。
資産と通信の状況を見えるようにし、ネットワークを分けて、保守用アカウントには多要素認証を使うことを要件にします。
このほか、バックアップや訓練も要件に含めます。
パッチを当てにくい改札機には、代替策を用意します。
長期利用を見据えて、EOL時の更新計画も定めます。
顔認証では、利用目的の通知・公表、照合の必要性、保存期間を設計します。
第三者提供や委託の扱い、本人の選択肢と代替手段も確認します。
2026年7月の発表では、既存改札にカメラを追加する仕組みが示されました。鉄道各社が、個人情報や生体情報を直接取得しない方式です。
採用する場合は、自社の個人情報の取扱いと委託関係を別途確認します。
タッチ決済では、カード番号を改札や駅サーバーに保持しない方法を検討します。
トークン化とネットワーク分離を検討し、PCI DSS v4.xの対象範囲を決済事業者と確定します。
PCI SSCは2025年3月31日以降、置き換えられた要件をROCやSAQでN/Aとして扱うことを示しています（出典：PCI Security Standards Council、2025年）。
ランニング費用には、クラウドや通信回線、監視が含まれます。
ヘルプデスクと現地駆け付け、予備機・部品、証明書更新も見積もります。
運賃改定や脆弱性診断、OS更新の費用、そして教育費も加えます。初期費用に加えて、5年・10年のTCOを試算します。
機器の交換時期や保証の終了、追加駅の単価を、一覧にまとめます。夜間工事費も、この一覧に含めます。
自動改札システム開発でよくある質問
導入では、機器の選び方に加えて、開発期間やクラウド化を検討します。決済方式や保守範囲も、あわせて検討が必要です。発注前によく尋ねられる点を、質問ごとに答えます。
自動改札システムの開発費用はいくらですか？
初期概算は、案件規模と改札機1台あたりの目安から見ていけます。
- 機能追加：数駅・数通路で1億〜5億円程度
- 駅務刷新：十数〜数十駅で5億〜30億円程度
- 改札機：1台あたり約650万〜1,500万円以上
総額は、運賃計算や決済、駅サーバーによって変わります。施工、試験、保守の範囲も、総額に影響します。
金額は公開契約額や類似案件からの推定です。
駅数に加えて、通路数とピーク処理量を示し、個別の見積もりを取ります。
自動改札システムはクラウド化できますか？
クラウド化の適否は、処理場所と通信断時の確認条件に分けて判断します。
- 改札・駅側：読み取り、通過判定、扉制御を処理します。
- センター・クラウド：運賃マスタ、利用実績、精算、監視、分析を管理します。
- 通信断への備え：継続時間、後同期、重複防止、復旧手順をPoCで確認します。
この分担を満たすには、エッジとクラウドを組み合わせるハイブリッド方式が適しています。
IC・QR・タッチ決済・顔認証を最初から全部入れるべきですか？
最初から全方式を入れる必要はありません。利用者や運用に合わせて、次のように段階的に導入できます。
- 交通系IC：主軸となる決済手段
- タッチ決済：訪日客や短期利用者向け
- QR：イベント利用者向け
- 顔認証：事前登録できる会員や特定サービス向け
方式を選ぶ際は、処理速度、登録の手間、個人情報の扱いを比べます。
2025年10月、関東の鉄道11社局は、クレジットカードなどのタッチ決済による後払い乗車の相互利用を発表しました。2026年春以降の開始を目指す協定です（出典：東京メトロほか共同発表、2025年）。さらに、各社は複雑な運賃計算システムの開発にも着手しました。
この動向を踏まえ、決済方式の追加を見込んだAPIを設計します。
まとめ
自動改札システム開発では、機器を買い揃えるだけでなく、業務全体を設計することが大切です。運賃計算や決済、監視、通信断時の継続を扱い、移行と長期保守まで含めて考えます。
対象の駅と通路、ピーク処理量を把握し、エッジとセンターの役割を決めます。PoCで実機と異常系を試せば、費用とリスクを具体的に把握できます。
開発を成功させる要点
見積もりでは、機器やソフト、ネットワーク、施工を分けて見ます。試験、教育、保守も別の項目にして、初期費用と10年TCOを比べます。
発注先は、例外処理やAPIの開示、障害時の責任の分け方を確認して選びます。部品供給やセキュリティ監査、EOL対応も、選定時の確認事項です。
IC、QR、タッチ決済、顔認証の4方式は、利用者と運用負荷に応じて段階的に導入します。
まず作成する資料
最初に、次の項目を1枚の資料にまとめます。
- 対象・設備：対象駅・通路一覧と既存機器一覧
- 利用規模：ピーク時通過人数、対応する券種・決済方式
- 障害対応：障害時の現場手順
資料をもとに、必要な機能と性能をRFPに記載します。移行条件や保守SLAも記載し、同じ条件で複数の候補に相談します。
自社だけで整理しにくい場合は、構想、RFP作成、ベンダー比較を支援する開発会社へ早めに相談します。そうしておくと、追加費用や手戻りを減らす助けになります。
▼全体ガイドの記事
・自動改札システム開発の完全ガイド
▼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を創業。