ICカードシステム開発は、現状調査、方式比較、要件定義、実機検証、段階導入の順に進めるのが基本です。この順で進めると、現場停止や追加費用のリスクを抑えやすくなります。
全体像、開発工程、費用相場、見積もりの確認点の順に説明します。
▼全体ガイドの記事
・ICカードシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
ICカードシステムの全体像
交通向けのICカードシステムは、改札機やバス車載器だけを指す言葉ではありません。FeliCaなどのカードを受け付ける端末や、運賃マスター、定期券と割引の判定を含みます。さらに、センターサーバーや決済、事業者間精算を一体で動かし、監視と保守も担います。
対象範囲は最初に広く定義しておくと、端末だけ先に決めて、後から基幹連携や精算が膨らむ失敗を防ぎやすくなります。
ICカードシステムを構成する機器とソフトウェア
現場端末とセンター側の機能を分けて整理すると、構成範囲と通信要件を決める材料がそろいます。
- 現場端末：自動改札機、券売機、チャージ機、精算機、窓口端末、バス車載器
- センター機能：利用履歴、カード・端末管理、運賃計算、売上集計、事業者間精算
- 運用機能：監視と監査ログを設け、通信断や停電への対応を受け持つ
現場端末は、残高や定期券の有効区間、入場記録を短時間で読み書きし、取引データをセンターへ送ります。
一方で、駅や車両では通信断や停電が起こり得ます。このため、全判定をクラウドに依存させず、端末に最低限の判定と暗号化ログを持たせます。
通信復旧後に重複なく同期する、エッジとクラウドのハイブリッド構成が現実的です。
要件定義の段階で、通信断が何分続いても運用を継続するか、復旧後にどの順番で同期するかまで決めておきます。
交通系IC、タッチ決済、QR、顔認証の役割
交通系IC、タッチ決済、QR、顔認証は、得意な場面がそれぞれ異なるため、利用者や運賃制度に合わせて組み合わせます。
- 交通系IC：定期券、細かな乗継割引、オフライン時の素早い処理
- タッチ決済：カード発行やチャージが不要で、一見客や訪日客にも使ってもらいやすい
- QR乗車券：スマートフォンや予約サービスと連携しやすい
- 顔認証：手ぶらでの通過や周辺サービスとの連携を検討しやすい
選定では、処理速度や通信への依存度、決済手数料を並べて比べます。既存設備の更新時期も判断材料に加えると、方式ごとの向き不向きが見えてきます。
2026年7月、各社が共同で、既存改札機にカメラを追加する顔認証連携を発表しました。参加したのは、日立、東武鉄道、オムロン、日本信号、東芝、パナソニック コネクトです（出典：各社共同ニュースリリース、2026年）。
改札機をすべて交換せずに機能を加える事例で、既存設備を活かす段階導入の選択肢が広がっていることを示しています。
ICカードシステム開発の進め方と工程
要件の抜けは、現場の停止や精算差異にすぐつながります。
工程は、前半の検討と後半の開発・展開に分けて順に進めます。前半は、現状調査、方式比較、要件定義、PoCの順に進めます。
後半は、設計・実装、総合試験、限定導入、全体展開の順です。
実機を使うPoCと、通信断・電源断・混雑を再現する試験は、前倒しで進めておきます。
各段階で確かめる内容が違うため、検討から展開までを段階ごとに区切って進めます。
- 現状調査を行い、方式を比較する
- 要件を定義し、実機を使ったPoCを行う
- 設計・実装後、総合試験と運用リハーサルを行う
- 限定導入で基準を確認してから、全体へ展開する
企画・現状調査で洗い出す項目
設備、利用状況、既存連携を調べておくと、見積もりの前提がそろいます。
- 設備数：駅、改札機、券売機、車両、営業所、窓口
- 利用と環境：1日の利用者数、朝夕のピーク通過人数、同時タッチ数
- 現場条件：端末ごとの通信状態、電源設備、設置スペース、現地保守体制
- 既存連携：運賃計算、会計、顧客管理、定期券発行、ダイヤ・路線マスター
カードは、全国相互利用の交通系ICと地域独自カードに分けて整理します。
モバイル端末やクレジットカード、QRを使う場合も、対象の範囲を一覧にします。
定期券、乗継割引、障害者割引の流れは、文章にして残します。高齢者向け制度や上限運賃、払い戻しも含めます。紛失再発行まで含めて、利用の流れを一通り書き出します。
要件定義と方式比較
機能と非機能の要件を数値にしたうえで、方式を絞り、実機PoCで技術上の不確実性を確かめます。
- 機能要件：入出場、残高確認、チャージ、定期券発行、運賃計算、精算
- 記録と管理：利用履歴、ブラックリスト更新、払い戻し、監査ログ
- 非機能要件：応答時間、ピーク処理能力、通信断の継続時間、復旧目標
- 安全と継続：二重計上防止、暗号鍵更新、遠隔更新、災害時バックアップ
「高速」「安全」「止まらない」といった要件は、測れる数値に置き換えて決めます。数値があれば、各社の見積もりを同じ条件で比べられます。
方式は、パッケージや交通向けプラットフォーム、クラウドやSaaSなどから、スクラッチやオープンループ併用までを比べます。
全国交通系ICを維持するか、オープンループを加えるか、独自カードを残すかを比べると、見積もりの条件がそろいます。
標準機能が多い場合はパッケージが有利です。一方で、独自割引や複数事業者の精算が多いと、追加開発が膨らみます。
クラウドを使う場合は、改札側に残すオフライン判定と、障害時の業務継続策を決めておきます。
方式を絞ったら実機を借りて、カードとリーダーの相性、スマートフォンの読み取り、連続タッチを検証します。
異常な取り外しや通信断からの同期、運賃改定、端末交換も試します。
PoCは完成品をつくる工程ではなく、実機で確かめる工程として扱います。見積もり前に、技術的な不確実性と責任分界を見つけておくことが目的です。
設計・開発・試験・段階リリース
要件定義までで決めた内容を設計・実装に移し、試験を重ねて、限定導入で合格基準を満たしてから全体へ広げます。
詳細設計では、境界や責任、運用の決め方を項目ごとに定めます。
- 境界：端末、駅や営業所のネットワーク、センターの境界を決める
- 責任分界：運賃マスターや精算、会計連携について、どこまでを誰が受け持つかを定める
- 変更手順：運賃改定や定期券の年度切替を含む変更手順を、文書に残しておく
- 運用と管理：監視や権限、ログの扱いを決め、カード鍵や証明書、端末ファームウェアの管理者もあらかじめ決めておく
- 障害対応：障害の一次受付と現地対応者を、あらかじめ明確にする。所有者があいまいだと、ベンダー間の対応が遅れる原因になる
試験は、単体、結合、総合の順に段階を分けます。負荷試験、セキュリティ診断、運用リハーサルも行います。
- 通信と負荷：ラッシュ時の連続タッチや通信断を再現する
- 障害と復旧：電源断後の再起動、誤った運賃マスターも試す
- 切替と配信：重複送信や端末交換、ブラックリスト配信を試験シナリオに含める
- 操作手順：駅員や乗務員の操作手順も確認しておく
- 本番切替：利用者を交えた本番切替のリハーサルも行う
最初から全駅・全車両に広げず、条件の異なる駅や路線で試します。限定導入では、障害率や改札通過時間、精算差異を測ります。問い合わせ件数や復旧時間も記録します。
合格基準を満たしたら、展開範囲を広げます。
ICカードシステムの費用相場とコストの内訳
費用は、駅や車両の数、端末の更新台数によって変わります。加えて、全国相互利用や運賃制度も影響します。既存基幹との連携や決済方式も、金額を左右する要素です。
ここに挙げる数字は、一律の価格表ではなく、公開事例と類似案件から作った検討レンジです。
購入かリースか、補助金の有無によっても金額は変わります。
保守を何年分含めるかによっても、総額は変わります。
同じシステムでも、条件をそろえて比べてください。
規模別の初期費用と開発期間の目安
初期費用と開発期間の幅は、導入規模が大きくなるほど広がります。
- 小規模：初期費用5,000万円から3億円、期間6か月から15か月
- 中規模：2億円から8億円、期間12か月から24か月
- 複数事業者：6億円から20億円超、期間18か月から36か月
- 大都市圏の全面刷新：数十億円から数百億円の規模もあり得る
小規模なバス事業者や地域交通が、既存の決済プラットフォームを利用して数十台から数百台の車載器を導入する場合の目安です。
中規模の目安は、営業所を含む複数拠点のバス・鉄道事業者が、定期券や運賃計算、会計連携まで構築する場合です。
複数事業者の目安は、全国交通系ICとクレジットカードのタッチ決済、QRを併用し、端末更新、精算、利用者移行まで行う場合です。
大都市圏の全面刷新では、改札機、券売機、精算機が更新の対象に入ります。センターや基幹連携も含まれ、金額を左右するのは駅数と機器台数です。
福岡市地下鉄は2026年6月、モバイル定期券の構築業務委託について、提案限度額を税込2億3,000万円と公表しました（出典：福岡市交通局「モバイル定期券サービス事業」、2026年）。
既存の交通系IC基盤にモバイル定期券を加えた案件です。改札機を全面的に更新する相場とは、分けて考えます。
機器・開発・連携・保守の費用内訳
初期投資と運用費を分けて把握しておくと、方式の違いを比べやすくなります。
- 端末：改札機、券売機、車載器など。全体の30%から50%程度
- アプリ・運賃・精算・サーバー開発：20%から35%程度
- 基幹連携・移行・試験：15%から30%程度
- 関連費：ネットワーク、セキュリティ、教育、切替、予備費。10%から25%程度
各項目の割合は、記事作成時点の案件比較から置いた推定レンジです。
端末が多いほど、機器の比率は上がります。また、クラウドやSaaSを使うと、初期費用の一部が月額や従量課金に移ります。
熊本地域の資料では、全国相互利用カードの機器更新を12億1,000万円としています。
タッチ決済中心の新サービスは6億7,400万円でした（出典：熊本市「熊本地域乗合バス事業共同経営に関する状況報告」、2024年公表資料）。
複数のバス・電鉄事業者を対象にした比較で、全事業者に当てはまる金額ではありません。ただし、方式によって初期投資が変わる例として参考になります。
ランニングコストには、端末・サーバー保守、通信、クラウド利用料が含まれます。監視や決済手数料も、ここに入ります。さらに、カード発行やデータセンター、脆弱性診断も含みます。追加改修も、ランニングコストに数えます。
年間保守を、初期の開発・調達費の15%から20%程度と置く場合もあります。その際は、端末・ソフト保守、通信費、決済手数料を分けて見ます。初期費用だけで比べると、5年後のTCOで評価が逆転することがあります。
ICカードシステムの見積もりを取る際のポイント
見積もりは、総額の安さより、内訳が同じ条件で積み上がっているかを確認します。対象は、機器、ソフトウェア、移行のほか、試験、教育、保守です。
RFPには、対象路線と駅・車両・端末数を書きます。加えて、カード種別や運賃制度、ピーク性能も記載します。さらに、通信断や切替時期、既存システムとの連携も盛り込みます。
条件が曖昧なまま相見積もりを取ると、会社ごとに範囲がずれ、安いように見える見積もりが出てしまいます。
仕様書と非機能要件の具体化
仕様と試験条件を具体的に書くと、追加費用が生じる箇所が見えてきます。
- 機能一覧：読み取り、入出場、残高、チャージ、定期券、割引、払い戻し
- 管理機能：紛失対応、履歴、売上集計、事業者間精算、管理画面
- 端末一覧：機種、台数、場所、交換時期、再利用の可否
- 運賃マスター：登録者、承認者、適用日時、誤登録時のロールバック
運賃マスターの運用まで書いておくと、運賃改定にかかる開発費を各社で比べられます。
非機能要件には、応答時間、ピーク同時処理数、通信断の継続時間を書きます。復旧目標も含めます。データ保持期間や監査ログ、バックアップも対象です。暗号鍵や脆弱性対応、遠隔更新のほか、SLAも明記します。
改札の応答は、平均値だけでなく、ピーク時の最大値と異常時の挙動も求めます。
試験で使うカードや端末、通信条件を決めます。合格基準まで合意しておくと、追加費用を抑えやすくなります。
複数社の比較と発注先の選び方
必要な役割と運用体制を照らし合わせて、発注先の実績や責任範囲を確認します。
- AFC機器会社：改札機や券売機などの機器を得意とする
- SIer：クラウドや基幹連携を得意とする
- 決済会社：クレジット決済基盤を得意とする
一社で全範囲を担えない場合は、主契約者が障害窓口と責任分界を引き受けるかを確認します。
同規模・同方式の稼働実績や現地保守網を評価します。24時間対応や再委託先も、評価の対象です。
端末ファームウェアの保守期間も確認します。提案書では、初期費用に加えて、5年または10年のTCOを比べます。
追加改修単価や端末更新費、クラウド増設費は、比較の対象です。通信費や決済手数料も含めて比べます。
カード鍵や利用履歴、運賃マスターの所有権と利用権を確認します。APIやソースコード、設計書についても、確かめておきます。
契約終了時に高額な移行費が発生しないよう、他社へ移せるデータ形式やAPIがあるかも確認します。
セキュリティと契約の責任分界
決済情報の扱いと契約上の責任は、早めに定めておきます。運用時に認識が食い違うのを防げます。
- 決済情報：カード情報の非保持化やトークン化、決済事業者との責任分界
- セキュリティ基準：法令上の指針と業界基準を区別して要件を確認
- 契約条件：契約形態、検収、SLA、変更費用、データ返却と移行支援
- 変更対応：運賃改定や制度変更の承認と緊急時の暫定対応
タッチ決済では、カード番号を自社環境で保存・処理・通過させない方法を検討します。
経済産業省は2025年3月にクレジットカード・セキュリティガイドライン6.0版を公表しました。
これは割賦販売法上のセキュリティ対策に関する実務上の指針です。一方で、PCI DSS v4.0.1は業界基準です。
PCI DSSは法令そのものではありませんが、決済事業者や委託先との要件確認で重要です（出典：経済産業省、PCI Security Standards Council、2025年資料）。
契約では、請負か準委任かの範囲、要件変更時の単価、検収条件を定めます。
重大度別のSLAや復旧時間、賠償上限を定めます。再委託や脆弱性の報告も、契約に盛り込みます。
運賃改定や制度変更は、すべてを事前に予測できません。そのため、変更管理委員会、承認フロー、緊急時の暫定対応を契約に含めておくと、稼働後の対立を減らせます。
ICカードシステム開発でよくある質問（FAQ）
費用や期間は、対象範囲によって変わります。ここに挙げる数字は検討レンジとして読み、同じRFPをもとに複数社から見積もります。
ICカードシステムの開発費用はいくらですか？
小規模な地域交通なら5,000万円から3億円、中規模なら2億円から8億円が検討レンジです。
複数事業者や複数決済を含む大規模案件では、6億円から20億円超が検討レンジです。
改札機を全面更新するか、既存基盤に機能を加えるかで、金額は変わります。機器や開発、連携は、それぞれ分けて見積もります。移行、試験、保守も、別に把握しておきます。
開発期間はどのくらいかかりますか？
導入規模や更新範囲によって、開発期間は異なります。
- 小規模：既存プラットフォームを利用する場合は6か月から15か月
- 中規模：12か月から24か月
- 複数事業者：端末更新や利用者移行まで行う場合は18か月から36か月程度
- 駅ネットワークの全面刷新：3年から5年以上かかることもあります
期間を左右するのは、カード接続や機器調達です。現場試験や運賃改定の時期も関わります。さらに、切替に使える深夜の時間帯も、スケジュールに影響します。
クラウドだけでICカードシステムを構築できますか？
クラウドは、センターサーバーや、運賃・履歴・分析の基盤として使えます。ただし、改札や車載器の全処理を通信に依存させる設計は避けるべきです。
現場には、最低限の判定や暗号化ログ、通信断時の継続機能を持たせます。復旧後は、重複なく同期する構成を検討します。
通信断の継続時間と、復旧できない場合の駅員・乗務員の代替手順も、要件に含めてください。
交通系ICをクレジットカードのタッチ決済へ置き換えるべきですか？
交通系ICは定期券や細かな割引、日常利用に残し、タッチ決済と併用するのが現実的です。
タッチ決済は、一見客や訪日客向けに追加できます。熊本地域の資料では、全国交通系ICの更新とタッチ決済の投資額を比較しています。
費用だけでなく、利用者への影響や決済手数料も含むTCOで判断します。通信やカード発行、運賃制度も、その中に含めます。
まとめ
ICカードシステムは、読み取りだけでなく、運賃や定期券、精算まで設計します。さらに、基幹連携やネットワークの設計、監視、保守も含まれます。
まず、現状調査、方式比較、要件定義と進めます。そのうえで、PoCと実機負荷試験、段階導入、全体展開の順に進めます。この順なら、現場停止や追加費用のリスクを抑えやすくなります。
対象範囲ごとの費用と期間
費用の目安は、導入規模や決済方式によって異なります。
- 小規模・中規模：小規模な地域交通で5,000万円から3億円、中規模で2億円から8億円
- 複数事業者・複数決済：6億円から20億円超が検討レンジ
公開実績は、対象範囲を示す参考値です。駅数や車両数、端末に加え、運賃制度や移行、保守も同じ条件で積み上げます。
保守や通信、クラウドの費用に加えて、決済手数料や更新費も含むTCOで判断してください。
RFPと実機検証の計画
発注前に決める条件と、方式を選ぶときの確認事項を整理します。
- RFP：機能・非機能要件、障害時の責任分界、データと鍵の権利、SLA、変更管理、契約終了後の移行条件をまとめる
- 決済方式：交通系IC、タッチ決済、QR、顔認証を目的と制約に応じて組み合わせる
- 実機検証：PoCと限定導入を計画し、測定できる合格基準を定める
▼全体ガイドの記事
・ICカードシステム開発の完全ガイド
▼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を創業。