券売機システムの導入は、駅ごとの現状調査から始めて、要件定義、PoC、先行駅での検証を経て、段階展開へ進む流れで行います。この順で進めると、駅務の継続性と利用者の利便性につながります。全体像は券売機システム開発の完全ガイドもご覧ください。
▼全体ガイドの記事
・券売機システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
券売機システムの全体像
券売機システムは、乗車券の販売端末と、運賃・券種・決済・発券状態・売上を管理する仕組みを組み合わせた駅務システムです。
JR東日本は2025年7月から新型指定席券売機を順次導入しており、案内では購入、変更、払い戻し、Web予約券の受け取りなどを一つの端末に集約しています（出典：JR東日本「指定席券売機ご利用案内」、2025年）。
端末だけでなく駅務全体をつなぐ仕組み
利用者が出発駅と到着駅を選ぶと、システムが経路と運賃を計算します。そのうえで、券種に応じて紙券、QR乗車券、ICカードへのチャージを処理します。
取引ごとに、決済の完了や発券、払い戻し対象を記録します。あわせて、駅別・端末別の売上集計と会計連携も行います。
券売機の販売から駅務管理までを支える設備は、次のように役割ごとに分けられます。
- 端末側：券売機端末とエッジ制御
- 駅と中央の設備：駅サーバー、駅LAN、運賃・券種・取引管理
- 乗車・決済連携：自動改札機、精算機、IC・QR認証基盤、決済ゲートウェイ
- 運用管理：遠隔監視・保守、売上・会計システム
端末そのものが正常でも、中央の券種データが古いままだと誤販売につながります。そのため、券種データの更新には承認手順と、反映結果を確認する機能が必要です。
利用者向け機能と運用者向け機能の分け方
利用者向け機能は、券種の販売・受け取りに関するものと、決済・案内に関するものに分けて整理します。
- 販売・受け取り：乗車券、定期券、特急券、企画券、割引券の購入、予約済みきっぷの受け取り、払い戻し
- IC・案内：交通系ICカードのチャージ・履歴確認、多言語表示、音声案内
- 決済：現金、クレジット・デビットカード、タッチ決済、QR決済と、方式別の取消・返金・売上照合
運用者向け機能は、機器の監視に関するものと、駅での処理・監査に関するものに分けて検討します。
- 監視・遠隔対応：券紙・紙幣・硬貨・釣銭の残量、券詰まり・通信断の検知、遠隔操作
- 駅での運用：駅員端末からの手動処理、売上締め、現金回収
- 記録・更新：監査ログ、障害ログ、運賃改定
無人駅では、障害が起きても全機能を止めず、現金販売だけを止めて、ICチャージや限定発券を続ける縮退運転を検討します。この方法なら、駅員の派遣回数を抑えやすくなります。
券売機システムの進め方・開発工程
端末をすぐに発注せず、まず駅ごとの業務と既存設備を把握してから段階的に進めます。企画初期の期間の目安は、方式によって次のように異なります。
- パッケージ中心：設定と連携に6〜12か月
- クラウド型QR：発券・決済・改札連携のPoCに9〜18か月
- スクラッチ：独自の運賃計算や端末制御を含め18〜36か月
1. 現状調査と企画による駅ごとの差の把握
現状調査では、駅や端末、利用状況、設備、保守に関する条件を一覧にします。
- 駅・利用状況：駅数、1日あたりの利用者数、時間帯別ピーク、現金比率、IC利用状況
- 端末・業務：端末の種類と台数、券種・運賃規則、既存の改札・精算機、故障履歴
- 設置・保守：通信回線、電源、設置スペース、保守体制
ターミナル駅、有人駅、無人駅、観光駅では、必要な機能がそれぞれ異なります。そのため、全駅に同じ仕様を当てはめると、必要な機能と合わなくなる駅が出てきます。
企画の目的は、「端末を更新する」ことだけにとどめず、測定できる業務指標で定義します。候補として、購入完了時間、係員呼出率、券詰まり、釣銭補給回数が挙げられます。
通信断からの復旧時間、窓口業務の削減、キャッシュレス利用率も指標になります。目的が明確であれば、端末価格が少し高くても、遠隔監視や縮退運転を優先できます。
2. サービス設計と要件定義による例外処理までの決定
要件定義では、利用者サービス、媒体の状態管理、非機能要件、運賃試験の範囲を決めます。
- 利用者サービス：購入可能な券種、決済、対応言語、払い戻し条件、予約受取、遠隔案内、駅員の介入方法
- 併存媒体：交通系IC、磁気券、スマホQR、クレジットカードのタッチ決済を一定期間併用する場合の発行・利用・取消・払い戻し管理
- 非機能要件：処理時間、稼働率、障害検知・復旧時間、オフライン動作、ログ、データ保持、バックアップ、権限、脆弱性対応、筐体の高さ、音声案内
媒体ごとに「発行済み」「利用済み」「取消済み」「払い戻し済み」を管理し、同じ取引を二重に処理しない仕組みを備える必要があります。
運賃計算では、正常系に加えて会社間乗り継ぎや日跨ぎを試験します。割引、定期券、払い戻しも対象で、さらに運賃改定の前後も含めます。
3. PoC、開発、試験、先行駅、段階展開の順序
方式は、鉄道向けパッケージやクラウド・SaaSのほか、既存機器改修、スクラッチ開発から比較します。
- パッケージ：駅務・運賃・IC連携の実績と保守体制を利用しやすい
- クラウド：QR乗車券やWeb予約、複数事業者との連携を拡張しやすい
- 既存機器改修：施工範囲を抑えやすいが、機器寿命・処理性能・保守責任の境界を確認する
- スクラッチ・組み合わせ：全面開発を避け、運賃・決済・認証には実績部品を採用して、独自機能をAPIで拡張する方法もある
PoCでは、実際の筐体、ICカード、QR、決済端末、駅ネットワークを使います。購入から改札通過、売上照合までを一通り通して検証します。
通信断や電源断、釣銭切れなどの場面を想定して試します。券紙切れや二重発券、決済後の発券失敗も対象です。遠隔操作や復旧後の再送も試し、駅員と利用者の両方で確認します。
次に、1〜数駅で先行導入し、昼夜や繁忙日を含む実運用でエラー率と問い合わせを測ります。その後、駅単位で展開します。
2026年時点では、磁気乗車券からQR乗車券への移行も中長期の設計条件になります。鉄道事業者8社は2026年度末以降、磁気券をQR乗車券へ順次置き換える方針を公表しています（出典：JR東日本ほか「鉄道事業者8社による磁気乗車券からQRコードを使用した乗車券への置き換えについて」、2024年）。
移行は一斉に切り替えず、まず旧券と新方式の併存を設計します。そのうえで、ロールバック、共通QR管理、会社間利用の照合方法も決めておきます。
券売機システムの費用相場とコストの内訳
鉄道向け券売機システムには公開定価がほとんどありません。価格は、駅数や端末数、券種によって変わります。さらに、IC事業者や決済方式、既設機器、施工条件、保守SLAなどによっても変わります。
次に示すのは、2025〜2026年の公開情報と駅務機器の機能範囲をもとにした企画初期の推定です。入札やRFPで確定する正式見積ではありません。
企画初期の導入単位ごとの推定レンジによる予算化
推定レンジは、端末の機能と導入規模によって異なります。
- 無人型端末：ICチャージと近距離券を中心に、筐体、現金処理、ICリーダー、基本発券、遠隔監視を含め1台500万〜1,500万円程度
- 高機能端末：指定席、定期券、予約受取、払い戻し、多言語、クレジット決済、遠隔有人支援を備え、1台1,000万〜3,000万円程度
- 1駅PoC：端末1〜3台と連携を含め3,000万〜1億円
- 地域導入：5〜15駅で2億〜8億円
- 広域移行：多数駅・複数社をまたぐQR・IC移行で10億〜50億円超
施工や通信、予備部品、決済手数料、保守などは別途になる場合があります。そのため、端末価格だけで比べないことが大切です。
端末が少ないPoCでは、要件定義や中央連携、試験、施工、教育などの固定費が大きくなります。その結果、1台あたりの金額が高く見えます。
開発費だけでなく5年TCOによる比較
費用内訳は案件ごとに異なるので、企画初期は次の比率を仮置きとして使います。
- 要件定義・PM：10〜15%
- アプリ・運賃・券種・API開発：20〜35%
- 端末・組込み・決済機器：25〜40%
- 駅ネットワーク・クラウド・監視：10〜20%
- 施工・データ移行・教育・試験・第三者評価・予備費：施工などが10〜20%、試験などが10〜15%
前提が変われば比率も変わるため、この比率を相場として固定しないでください。各項目の数量と単価は、開示を求めます。
西日本鉄道が2025年に公開したバリアフリー整備・徴収計画では、駅務機器改修費が1,500万円、収受システム改修費が400万円です。その他の駅務機器・駅頭表示改修費は2,400万円です（出典：西日本鉄道「2025年3月24日付バリアフリー整備・徴収計画」、2025年）。
これは券売機単体の新規導入価格ではなく、計画の一部にあたる費用です。公開費用は下限のイメージとして扱い、相場とは断定しないのが安全です。
保守費は、初期導入費の年10〜20%程度を仮置きします。ただし、対応の範囲によって変わります。たとえば、24時間365日対応や現地駆け付け時間、代替機、部品供給期限が含まれるかどうかで差が出ます。OS・決済仕様の更新や運賃改定対応も、同じ見方で確認します。
5年TCO（総所有コスト）は、初期開発費に、通信や決済手数料、紙、現金回収、保守を加えて比較します。さらに、改札・サーバー更新や障害対応、撤去費も含めます。
券売機システムの見積もりを取る際のポイント
見積もりの精度は、発注者が渡す情報の粒度で決まります。「券売機を更新したい」とだけ伝えた場合、比べられるのは端末の機械費に限られます。
まず、駅数や端末台数、券種、1日利用者数、現金比率をそろえます。さらに、既設機器や決済、稼働率、復旧時間も前提として示します。システム、施工、試験、保守の各項目も、同じ前提で比べます。
RFI・RFPへの駅別条件と非機能要件の記載
RFIで複数社に実現方式と概算を尋ね、その回答を踏まえてRFPを作成します。RFPには、駅別条件と機能・運用要件を記載します。
- 方式とサービス：パッケージ、クラウド、既存機器改修、スクラッチ、利用者機能、運賃・券種
- 連携：IC・QR・タッチ決済、予約Web、改札・精算・会計
- 駅・端末条件：設置条件、処理時間、通信断時の動作
- 運用・品質：監査ログ、バックアップ、セキュリティ、アクセシビリティ、移行、教育、SLA
見積書では、要件定義や設計、開発、端末、決済機器などの費目を分けてもらいます。通信、施工、移行は、それぞれ別の行に分けてもらいます。試験、教育、保守、撤去、予備費についても、別の行に分けます。
各項目について、数量や単価、期間を指定します。前提や除外事項、追加変更時の単価も書いてもらいます。これにより、A社では端末機能に含まれ、B社ではオプション扱いになるといった比較のずれを抑えられます。
価格より責任範囲と実績の確認
開発会社やベンダーは、担当範囲と類似する駅務システムの実績で比べます。
- 担当範囲：端末、組込みソフト、中央サーバー、運賃計算、IC・QR・決済、改札、施工、監視、保守
- 連携実績：他社の改札や予約システムとの接続経験
- 運用体制：自社のIC・運賃制度に近い実績、障害時の現地到着時間、代替機、部品供給期間
接続の経験がない場合、別途の調整費や責任分界が発生する可能性があります。そのため、契約前に担当の境界を確認しておきます。
ベンダーロックインを抑えるには、取引データの所有者とAPIの公開範囲を確認します。さらに、データの出力形式や、運賃改定・決済仕様変更の費用も見ておきます。
契約が終わるときの移行支援についても確認します。契約は一括請負のほか、要件定義、PoC、開発、先行駅、全駅展開、保守を段階ごとに分けて比べます。
PoCで重大な障害条件が見つかった場合に全駅展開を止められる契約であれば、予算と運用のリスクを管理しやすくなります。
セキュリティ・継続運用・アクセシビリティの価格との同時評価
見積もりの段階では、決済情報の保護、システム停止時の運用、利用者の使いやすさを確認します。
- 決済情報：PCI DSS v4.0.1の範囲とカード情報の非保持化
- セキュリティ：端末・ネットワーク対策と運用管理
- 継続運用：中央システム停止時の発券・照合・復旧
- アクセシビリティ：多様な利用者を想定した実機確認
- 導入効果：完了率と係員呼出率による評価
カード決済では、PCI DSS v4.0.1の適用範囲を決済事業者と確認します。あわせて、カード情報を券売機や自社サーバーに保存させず、通過もさせない非保持化を見積もりの条件に含めます。
見積もりの範囲には、端末の暗号化や鍵管理、ネットワーク分離、監査ログ、脆弱性対応を含めます。加えて、資産・権限管理、バックアップ、インシデント対応、委託先管理も評価します。
国土交通省は2026年4月、「鉄道分野における情報セキュリティ確保に係る安全ガイドライン」を第6版に改定しました（出典：国土交通省「鉄道：情報セキュリティ対策」、2026年）。このガイドラインは、前段のようなセキュリティ対策を評価するときのよりどころになります。
中央が停止した場合の対応として、端末キャッシュや署名済み券情報、再送・照合、手動復旧、監視通知までの提案を受けます。
高齢者や車椅子利用者、訪日客が迷わず使えるかを実機で確かめるため、画面のコントラストや高さ、ボタン、音声案内を評価します。
現金投入口や券の受取口、オペレーター接続、多言語切替も確認します。機能を追加して費用が増える場合は、完了率と係員呼出率で効果を判断します。
よくある質問（FAQ）
端末価格や開発方式、通信断、ICとQRの併用、保守範囲については、よく質問が寄せられます。企画、駅務、情報システムの担当者向けに、回答を挙げておきます。
券売機システムは1台いくらかかりますか？
企画初期の推定では、無人型端末が500万〜1,500万円、高機能端末が1,000万〜3,000万円程度です。あくまで端末本体を中心とした目安で、プロジェクト全体の総額ではありません。
中央システムや改札連携、施工、試験、教育、保守は別に見込んでおく必要があります。正式な金額は、駅数や端末数、券種、決済、既設機器、保守条件をRFPに記載して確認します。
通信断や停電が起きたときも券売機は使えますか？
方式によりますが、通信断時にも全機能を止めない設計は可能です。そのためには、端末キャッシュや署名済み券情報、再送キュー、取引番号、復旧後の照合、手動処理を要件に含めます。
あわせて、現金処理や発券の安全性も確認します。ただし、運賃データや決済認証を常に中央で行う機能は、オフライン時に制限される場合があります。
交通系IC、QR乗車券、タッチ決済は併用できますか？
複数の乗車媒体を併用する場合は、管理状態と移行時の運用を整理しておきます。
- 媒体の状態管理：発行、利用、取消、払い戻し、売上照合の各段階を、媒体ごとに追える形にする
- 移行期間：磁気券からQRへの移行やICとタッチ決済の並行運用で、旧方式の利用者を急に締め出さないための猶予の設定
- 障害時の対応：代替手段の用意
- 接続試験：新しい媒体について、端末、改札、中央管理、サービス事業者との接続まで含めた試験
東芝は2026年、東京メトロなどと「どこチケ」を活用し、公共交通とスポーツ観戦を組み合わせるQR乗車証の実証を行っています（出典：株式会社東芝「どこチケを活用した実証実験」、2026年）。
開発期間はどれくらい見ておけばよいですか？
パッケージ設定と既存連携は6〜12か月、クラウド型QRのPoCは9〜18か月、独自運賃計算や端末制御を含むスクラッチは18〜36か月が目安です。
複数路線を段階展開して旧券と新券を併存させる場合は、24〜48か月になることもあります。いずれの場合も、運賃計算や払い戻し、通信断、釣銭切れ、日跨ぎの試験期間は削らず、先行駅の実運用も計画に入れます。
まとめ
券売機システム開発は、運賃や券種、IC、QRをつなぐ駅務基盤の更新です。決済、改札、売上、保守も、この基盤の中で扱います。まず、駅ごとの利用状況と既設設備を一覧にします。
業務要件や処理時間、通信断、セキュリティ、アクセシビリティ、運賃改定の手順を定義します。そのうえで、PoCと先行駅の実運用を経て段階展開へ進みます。
端末単価より導入後の総額による判断
企画初期の段階では、無人型端末が500万〜1,500万円、高機能端末が1,000万〜3,000万円、1駅PoCが3,000万〜1億円という推定を使えます。
正式な判断では、5年TCOを比べます。その範囲には、端末や連携、施工、試験が含まれます。教育や通信、決済、保守、撤去も、同じ比較に入れます。また、障害時の継続運用と、5〜10年後の保守継続性も評価します。
最初の一歩となる駅別の要件整理とRFI
発注の準備では、駅ごとの情報をそろえておくと、見積もりの前提を比べやすくなります。
- 発注前に駅一覧、端末台数、券種、運賃規則、利用者数、現金比率、既設機器、決済、復旧時間、保守窓口を一枚にまとめます。
- この資料をもとに複数社へRFIを行い、方式や責任分界、概算、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を創業。