券売機システムの発注は、現状調査、要件整理、PoC、先行駅導入、全駅展開の順に進めると、営業を止めずに運用へつなげやすくなります。その前提として、誰がどの範囲を受け持つかを先に決めておくことが成否を左右します。
▼全体ガイドの記事
・券売機システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
券売機システムの発注・外注の範囲
発注・外注では、端末の調達と駅務連携、運賃・券種の設定を委託します。さらに、決済や施工、試験、保守も任せます。誰がどの範囲を構築・運用するかで成否が決まるため、任せる範囲は最初に明確にしておきます。
発注対象は端末だけでなく駅務全体
交通向け券売機では、発券や乗車券以外の業務も発注対象になります。具体的には、発券・運賃、決済・媒体、駅務処理の3つにまたがります。
- 発券・運賃：普通券、定期券、特急券、企画券、割引券まで扱う
- 決済・媒体：交通系IC、QR券、クレジットとタッチによる支払いに対応
- 駅務処理：払い戻しや売上照合まで対象に含める
ICカードでは、Suica、PASMO、ICOCAなどへのチャージや履歴確認も扱います。また、QR券の発行と受け取りも対象です。
範囲には、駅サーバー、運賃・券種管理、改札が含まれる場合があります。このほか、精算機、係員端末、予約Webが入ることもあります。
決済ゲートウェイや遠隔監視、会計も対象になる場合があります。さらに、回線や設置工事まで含むこともあります。
RFPでは、範囲を端末、アプリ、連携に分けます。加えて、施工、移行、保守も区分して書きます。
発注前に決める責任分界
券売機が止まったときに早く戻せるよう、発注の前に、障害の起こり方から復旧の担当までを決めておきます。
- 停止要因：紙詰まりや釣銭切れ、回線に加え、運賃マスタやIC認証の障害も想定します。決済会社や改札機、売上集計の障害も含めます。
- 復旧責任：一次切り分けの担当、復旧の指揮を執る会社、現地対応の期限を契約前に定める
- 無人駅の運用：遠隔監視、音声案内、インターホン、代替決済、通信断時の限定運転を要件に含める
台数や初期価格だけで選ぶと、障害対応や運賃改定の追加費用が膨らむ場合があります。そのため、業務を止めない運用の設計まで委託範囲に含めます。
券売機システムの発注形態の選び方
発注形態は、パッケージやクラウド、既存機器改修、スクラッチ開発を比べて選びます。実績ある運賃計算や決済を使いながら、自社固有の券種や駅業務はAPIで拡張する方法も有力です。
品質と保守を重視する場合のパッケージ導入
鉄道向け駅務機器や運賃・IC連携のパッケージは、券種や改札の組み合わせに加えて、精算や売上締めまで検証済みです。そのため、短納期と安定稼働を目指せるほか、24時間365日の保守も契約に含めやすい形です。
独自企画券や他社サービスとの連携には、制約が出る場合があります。採用時は、機能一覧だけでなく運賃改定とマスタ承認を確認します。さらに、データ出力、API公開範囲、OS・部品の供給期限も見ておきます。
契約が終わったときに、取引データと設定情報を取り出せる条件もRFPに入れます。そうすると、将来の更新で選択肢を残せます。
クラウドと既存機器改修の段階導入
段階的な媒体追加や設備更新の候補は、クラウド型と既存機器改修の2つです。両者は、広げられる媒体と、既存の機器に手を入れる範囲が異なります。
- クラウド：QR券、Web予約、複数事業者の企画券に対応しやすい
- 既存機器改修：QRリーダーやタッチ決済端末を段階的に追加できる
たとえば、東芝のQR乗車券システムはABTサーバー、発行・払い戻し用Web API、駅員・本社向けWebサイトで構成されます（出典: 株式会社東芝「QR乗車券システム」、2026年確認）。ただし、クラウドでも現金処理、発券機構、通信断対策は別途必要です。
既存機器にQRリーダー、タッチ決済端末、遠隔案内を加える方法は、一斉更新よりも切替のリスクを小さくできます。機器寿命や電源・配線、処理性能を確認します。加えて、メーカー間の保守責任も見ておきます。
まず、1駅または1〜3台のPoCで、通信断後の再送や二重発券を実測します。払い戻しと操作時間も測ったうえで、展開に進みます。
独自業務に限定したスクラッチ開発
パッケージで対応できない独自業務が多い場合に限り、スクラッチ開発を検討します。
- 独自要件：独自運賃、地域乗継、観光施設との共通券、特殊割引
- 標準部品：運賃計算、決済、認証、QR検証は実績あるものを使う
独自要件が多いと、運賃計算の全パターンや端末OS・組込み制御を、発注者と開発会社が長期にわたって担うことになります。さらに、決済認証や24時間保守も、両者が長く担う範囲に入ります。
独自画面や業務フローを外注するなら、その独自性が利用者の価値や運用コストの差になるかを確かめます。また、標準機能で代替できる要件は増やしすぎないようにします。
RFPと要件整理の進め方
RFPは、提案と見積を同じ前提で比べるための文書です。そのため、価格だけでなく、目的や対象駅、業務範囲を書き、非機能、移行、保守の条件もそろえます。
要件が未確定なら、まずRFIで方式や制約を聞きます。その回答をRFPに反映して更新します。複数社の回答を取り入れると、過大なスクラッチ提案や見積の抜け漏れを減らせます。
現状調査での駅・端末・券種の洗い出し
駅ごとの特性がつかめるよう、次の項目を整理します。
- 設備：端末台数、型式、導入年、回線、故障履歴
- 利用状況：1日利用者数、ピーク、現金比率、券種、払い戻し件数
- 駅業務：駅員の手順と、有人・無人・観光・ターミナルごとの違い
接続先には、運賃・券種マスタ、IC事業者、予約Webがあります。さらに、決済ゲートウェイや改札、精算機も含まれます。
売上会計と遠隔監視も、接続先の一覧に入ります。そのうえで、データの正、連携方式、更新頻度を図に記録します。障害時の代替処理も同じ図に書きます。
発注者が駅ごとの一覧を用意しておくと、開発会社が再び調べる工数を抑えられ、提案の精度も高まります。なお、駅ごとに必要な画面や保守体制は異なるため、全駅を平均値でひとまとめにせず、駅ごとに書きます。
利用者と駅員の両方からの機能要件
利用者と駅員の業務を分けて、券売機に必要な機能を整理します。
- 利用者操作：乗降駅・経路検索、運賃表示、紙・QR券、ICチャージ、予約受取
- 案内・決済：払い戻し、多言語、音声、使いやすい画面、支払い方法への対応
- 駅員業務：運賃改定、現金回収、締め、障害対応、保守手配
利用者向けには、車椅子利用者や高齢者が使いやすい画面を定義します。支払い手段には、現金、クレジット、デビットがあります。タッチとQR決済も含め、券種との組み合わせを整理します。
駅員機能には、券種追加、開閉局、払い戻し承認があります。監査ログや遠隔再起動も含めます。
無人駅で通信断や釣銭切れが起きたときに残す機能と、呼出し経路を決めます。そのうえで、業務シナリオを受入試験に使います。
数字で示す非機能要件と受入条件
非機能要件は、稼働と処理性能、復旧を分けて数値で定めます。設置・保守環境も、数値で示します。
- 性能：応答時間、1時間の処理件数、同時利用数
- 継続性：稼働率、バックアップ、復旧時間、通信断時の動作
- 設備：ログ保持、耐久性、設置環境、セキュリティ更新、部品供給期限
「高速」「安定」「安全」といった語は、人によって解釈が分かれます。そのため、購入完了時間や障害通知時間、復旧目標など、測定できる表現にします。
国土交通省は2026年4月、鉄道分野の情報セキュリティ安全ガイドラインを第6版に改定しました。
RFPには、資産管理、アクセス制御、ネットワーク分離を盛り込みます。また、脆弱性対応、バックアップ、事故対応も含めます。委託先を含む供給網管理も加え、実装方法と証跡を求めます（出典: 国土交通省「鉄道分野における情報セキュリティ確保に係る安全ガイドライン 第6版」、2026年）。
券売機システムの契約形態の決め方
要件の確定度、試験後の変更可能性、駅展開の分割可否を見て、契約形態を選びます。まず、要件定義、PoC、開発・調達の順に段階を分けます。
そのあとに、先行駅、全駅展開、保守を続けます。各段階で納めるものと、決定の時期を設計します。
範囲と完成条件を固めたあとの請負契約
範囲と完成条件を確定できる作業は、請負契約で納めるものを明確にします。
- 対象範囲：機能、画面、連携、端末、駅ごとの施工、納期
- 受入試験：運賃全パターン、発券、通信断、停電、釣銭切れ
- 異常系：券紙切れ、二重発券、払い戻し、日跨ぎ、会社間乗継
試験結果と不具合への対応は、契約書や仕様書に結び付けて書きます。仕様変更や既存設備の想定外の制約は、無償対応になるとは限りません。
追加費用、変更承認者、見積単位を明記します。納期への影響や、複数社にまたがる障害の責任も書き込みます。さらに、端末とアプリを別会社に頼む場合は、接続試験の主導者も決めます。
要件定義や伴走支援に向く準委任契約
要件が未確定の初期や、共同で業務を整理する段階は、準委任で専門人材を確保できます。
- 支援内容：駅員への聞き取り、既存機器調査、RFP作成
- 調整業務：PoC評価、ベンダー間調整など進め方が成果となる仕事
- 月次管理：納めるもの、課題、決定事項、試験計画、次月の終了条件
準委任は稼働時間への支払いで進むため、機能の完成や品質は保証されません。そこで、要件定義とPoCのあとに仕様を確定させ、開発や量産は請負に切り替える段階契約も有効です。
保守契約のSLAと更新費用
保守は、対応時間、障害時の動き、継続費用を条件ごとに比べます。
- 対応体制：24時間365日、監視範囲、重要度、一次回答、現地到着
- 保守継続：代替機、部品供給、更新、IC・決済変更、運賃改定費
- 契約更新：更新年の費用、撤去、データ移行、後継機への切替も確認
駅の営業時間だけを対象にするか、始発前から終電後までを対象にするかで体制は異なります。そのため、運行時間に合わせてSLAを決めます。
企画初期は、保守費を初期導入費の年10〜20％程度と仮置きする場合があります。ただし、保守費は端末・駅数や部品、現地対応で変わります。さらに、クラウドや回線、決済手数料の条件でも変わります。
券売機システムの費用相場の目安
交通・改札向けは公開定価が少なく、個別見積になります。価格は台数や駅数、券種によって決まります。また、IC、決済、既存設備の条件も価格に影響します。
施工や保守SLAも見積の条件になります。以下は2026年時点の企画初期の推定レンジで、入札や正式発注の確定価格ではありません。
飲食店向けの券売機の価格を、鉄道向けの相場にそのまま当てはめないようにします。
企画初期の費用レンジ
駅数や機能、連携範囲で変わる推定値は次のとおりです。企画初期の比較には、この費用幅を使います。
- 無人型端末：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億円超になることもある
無人型端末の目安には、筐体、現金処理、ICリーダーが含まれます。基本発券と遠隔監視も入ります。
高機能型は、定期券、予約受取、払い戻しを想定します。また、多言語、クレジット、有人遠隔支援も含めます。
端末価格とは別に、工事や回線、機器改修の費用がかかる場合があります。さらに、消費税と保守もかかることがあります。
PoCや地域導入には、要件定義、運賃・券種連携、決済・改札接続を含みます。施工、試験、教育も入ります。
西日本鉄道の2025年資料は、バリアフリー計画の一部に駅務機器改修費15百万円、収受システム改修費4百万円、駅頭表示改修費9百万円を記載しています。ただし、これは券売機単体の新規導入価格ではなく、改修の例として扱います。相場とは断定せず、駅数と対象機器をそろえて見積を取ります（出典: 西日本鉄道「2025年3月24日付バリアフリー整備・徴収計画」、2025年）。
費用の内訳（端末価格と開発・運用費）
費用の仮置き比率を分けて見ると、見積の抜けや、PoCの固定費に気づけます。
- 要件・開発：定義・管理は10〜15％。アプリ、運賃、券種、APIは20〜35％
- 端末・基盤：機器本体や組込み、決済機器は25〜40％。ネットワーク・クラウド・監視は10〜20％
- 導入・検証：施工、移行、教育は10〜20％。試験・第三者評価・予備費は10〜15％
端末数が少ないPoCは、要件定義や試験の固定費が大きく、端末単価だけでは比べられません。
5年TCOでは、初期開発、端末・サーバー、通信を合算します。さらに、クラウド、決済手数料、紙・現金回収も入れます。保守、部品交換、運賃改定も、同じ枠で見ておきます。
そして、OS更新、教育、障害対応を加えます。撤去・移行も含めます。「別途」「実費」は、数量と単価を確認します。
現地作業、試験環境、夜間切替が除外されると、契約後に総額が逆転する場合があります。予備機や移行の扱いも、見積の段階で確かめます。
発注形態ごとの開発期間
開発期間は、方式と展開範囲によって6か月から48か月まで幅があります。
- パッケージ：設定と連携を中心に6〜12か月
- クラウドPoC：QR発券・決済連携で9〜18か月
- スクラッチ：独自運賃・端末制御を含み18〜36か月
- 複数路線展開：磁気券からQRへ移行し、旧券併存で24〜48か月
試験や展開の工程も合わせて見積もります。テストを後回しにすると、営業開始後の障害につながります。
そのため、運賃の全組み合わせや通信断、停電を実機で検証します。さらに、釣銭・券紙切れ、券詰まり、二重発券も実機で確かめます。
払い戻し、日跨ぎ、会社間乗継も対象に含めます。繁忙日や始発・終電の時間帯も確認します。
RFPでは、試験、先行駅、教育の期間を分けて出してもらいます。また、ロールバックや全駅展開も、別の期間として示してもらいます。
委託先選定と見積比較のポイント
端末価格だけでなく、駅務機器、IC・運賃、QRを一体で担えるかを比べます。決済や中央システムも、同じ会社が受け持てるかを見ます。施工と24時間保守まで任せられるかも確かめます。
候補企業には、同じ駅数、端末数、券種を示します。さらに、決済、保守時間、移行条件も共通で示します。
そのうえで、似た規模や利用者数、無人駅比率の実績を確認します。導入後の障害対応についても見ます。
実績と責任範囲による候補の絞り込み
候補企業の確認では、実績、障害対応、長期運用の条件を比べます。
- 適合・責任：IC・運賃実績と機器連携の担当範囲
- 障害対応：オフライン動作、現地到着時間、代替機、改定費用
- 継続性：データ権利、API、ログ、下請け、5〜10年後の保守
2026年4月、東芝は東京メトロなどとQR乗車証の実証を行い、交通とスポーツ観戦の連携を検証しました（出典: 株式会社東芝「交通チケットオープン化プラットフォーム『どこチケ』を活用した実証実験」、2026年）。外部連携を想定する場合は、券売機の会社に加えて、APIやデータ分析、認証も評価します。沿線事業者との間では、どこまでを誰が受け持つかも確かめます。
同じ条件と5年TCOによる見積比較
見積の内訳と評価条件をそろえ、価格以外の運用面も比べます。
- 費用内訳：端末、ソフト、連携、施工、保守、移行、撤去を共通分類にする
- 追加費用：駅別、夜間、現地調査、変更、運賃改定の単価を確認
- 評価配点：価格30％、機能・連携25％、保守・SLA、試験・移行、セキュリティ・拡張性を各15％で設定
費用分類には、初期費、試験、教育を含めます。さらに、決済手数料、紙・釣銭、予備機も入れます。価格を公表していないパッケージでは、機能や接続先を追加するときの料金ルールを確認します。
評価軸は、機能適合、交通実績、非機能です。提案体制も評価軸に入ります。
自社で評価表を作れば、最低価格や営業資料の印象に引きずられずに比べられます。
価格と同じ重みで見るセキュリティとアクセシビリティ
安全性と使いやすさは、評価配点とは別に、価格と並べて必ず満たすべき条件として確かめます。規格名だけでなく、実際の運用条件を評価します。
- カード決済：PCI DSS、非保持化、暗号化、鍵管理、監査ログ
- 顔認証：利用目的、同意、保存・削除、委託先、代替手段
- 操作性：文字、色、音声、操作位置、姿勢、言語選択を実機で試す
決済事業者とPCI DSSの適用範囲を確認し、カード情報を券売機や自社サーバーに保存・通過させない設計にします。ネットワーク分離や脆弱性対応も組み込みます。あわせて、証跡の保管者と、顔認証で本人を誤認した場合の対応を決めます。
国土交通省の基準・指針に沿った設計かどうかは、利用者が購入を完了できるかに関わります。そのため、係員だけでなく初めて使う人も実機で試験します。
よくある質問
発注では、価格や既存機器との接続、期間がよく問われます。保守や通信断への対応も、よく挙がる点です。交通・改札向けの代表的な問いに答えます。
券売機システムの発注費用は1台いくらですか？
ICチャージや近距離券が中心の無人型端末は1台500万〜1,500万円、高機能端末は1台1,000万〜3,000万円程度が、企画初期の推定です。
これは端末価格の目安です。運賃・券種、改札連携、施工を含めた総額は、駅数と連携範囲で変わります。試験や通信、保守も、その総額に含めて考えます。
無人駅でも券売機システムを外注できますか？
外注できます。遠隔監視、インターホン・音声案内、通信断時の限定運転は要件に入れます。釣銭・券紙残量の通知や代替手段、保守員の駆け付けも要件に含めます。
駅ごとの回線品質と利用者数を測り、完全停止を避けられるか、障害時に何を案内するかをPoCで確かめます。
交通系IC、QR、タッチ決済は同じシステムで扱えますか？
併用できる構成はありますが、券種や改札で、すべて同じように使えるとは限りません。認証、残高・期限、オフライン判定の条件は、媒体ごとに異なります。払い戻しや売上照合、再送の条件も、媒体によって違います。
RFPには、対応券種と駅務機器の組み合わせを記載します。磁気券やICが併存する期間、スマホQRやタッチ決済が併存する期間では、媒体間の状態管理と問い合わせ窓口も設計します。
発注前にRFPがなくても見積を依頼できますか？
概算依頼は可能です。ただし、駅数、台数、券種がないと、各社で前提が異なります。既存機器や決済の条件、保守時間、導入時期も、前提として示す必要があります。
まずRFIで方式と資料を確かめ、現状調査と要件整理のあとにRFPを出します。そうすると、各社の提案を比べやすくなります。急ぐ場合も、前提や除外、追加費用の条件は書面に残します。
まとめ
発注では、端末価格だけでなく、運賃・券種、IC・QR・決済、改札を一体で考えます。売上や施工、試験も含めます。遠隔監視と保守までを視野に入れます。
パッケージやクラウド、既存機器改修、スクラッチを比べ、固有業務だけをスクラッチ開発にすると、開発リスクと変更費を抑えやすくなります。
発注前に確認する項目
まず、駅、端末、券種を一覧にします。利用者と故障履歴も洗い出します。そのうえで、RFIで方式を確かめてから、機能、非機能、セキュリティをRFPにまとめます。
バリアフリーと移行も、RFPに書きます。SLAと、どこまでを誰が受け持つかも書き込みます。
見積は、5年TCOで比べます。保守や決済、通信に加えて、改定、教育、撤去も含めて見ます。営業を止めない体制と、データや契約の継続性も評価します。
段階的な委託と運用への接続
2026年は、QR乗車券やタッチレスの実証と連携が進んでいます。将来の媒体追加に備え、APIやオフライン処理を確かめます。共通管理、ログ、受け持ちの範囲も確認します。
業務シナリオと受入条件を共有すれば、迷わない購入と駅員による迅速な復旧を成果にできます。
▼全体ガイドの記事
・券売機システム開発の完全ガイド
▼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を創業。