ICカードシステム開発の進め方/やり方/流れや方法/手法/工程/手順

ICカードシステム開発は、カードを読み取る機械を導入するだけではなく、入出場、運賃計算、定期券、精算、障害対応までを止めずに動かす交通インフラを設計することです。

本記事では、交通系ICカードを利用するICカードシステムの全体像から、企画、要件定義、PoC、開発、試験、段階導入までの進め方を解説します。初期費用の相場、保守費用、見積書で確認したい項目、クレジットカードのタッチ決済やQR、顔認証との組み合わせ方も、2026年時点の公開事例を交えて紹介します。

▼全体ガイドの記事
・ICカードシステム開発の完全ガイド

ICカードシステムとは何ですか？全体像を理解する

交通向けのICカードシステムは、改札機やバス車載器だけを指す言葉ではありません。FeliCaなどのカードを受け付ける端末、運賃マスター、定期券と割引の判定、センターサーバー、決済、事業者間精算、監視、保守を一体で動かす仕組みです。最初に対象範囲を広く定義しておくと、端末だけ先に決めて後から基幹連携や精算が膨らむ失敗を防ぎやすくなります。

現場側には、駅の自動改札機、券売機、チャージ機、精算機、窓口端末、バスの車載器があります。これらはカード残高、定期券の有効区間、入場記録などを短時間で読み書きし、必要な取引データをセンターへ送信します。センター側には、利用履歴、カード・端末管理、運賃計算、売上集計、事業者間精算、監視、監査ログの機能を配置します。

駅や車両では通信断や停電が起こり得るため、すべての判定をクラウドに依存させる設計は危険です。改札や車載器に最低限の判定と暗号化された取引ログを持たせ、通信が復旧した後に重複なく同期するエッジとクラウドのハイブリッド構成が現実的です。要件定義では、通信断が何分続いても継続するか、復旧後にどの順番で同期するかまで決めておきます。

交通系ICは、定期券、細かな乗継割引、オフライン時の素早い処理に向いています。一方、クレジットカードのタッチ決済によるオープンループ方式は、カード発行やチャージを必要としないため、一見客や訪日客への対応に向いています。QR乗車券はスマートフォンや予約サービスとの連携がしやすく、顔認証は手ぶらでの通過や周辺サービスとの連携を検討しやすい方式です。

これらは単純な優劣ではなく、利用者、運賃制度、処理速度、通信依存度、決済手数料、既存設備の更新時期で選びます。2026年7月には、日立、東武鉄道、オムロン、日本信号、東芝、パナソニック コネクトが、既存の改札機にカメラを追加して顔認証と連携する仕組みを発表しました。改札機をすべて交換せずに機能を追加する事例は、既存資産を活かす段階導入の選択肢が広がっていることを示しています（出典: 各社共同ニュースリリース、2026年）。

ICカードシステム開発の進め方と工程

ICカードシステムは、要件の抜けが現場停止や精算差異に直結します。そのため、企画から本番稼働までを一気に開発するのではなく、現状調査、方式比較、要件定義、PoC、設計・実装、総合試験、限定導入、全体展開の順でリスクを小さくします。特に実機を使うPoCと、通信断・電源断・混雑を再現する試験を前倒しすることが重要です。

まず、駅数、改札機数、券売機数、車両数、営業所数、窓口数を一覧にします。次に、1日の利用者数だけでなく、朝夕のピーク通過人数、同時タッチ数、端末ごとの通信状態、電源設備、設置スペース、現地保守の体制を確認します。既存の運賃計算、会計、顧客管理、定期券発行、ダイヤや路線マスターとの連携方式も対象です。

カードについては、全国相互利用の交通系IC、地域独自カード、モバイル端末、クレジットカード、QRを分けて整理します。定期券、乗継割引、障害者割引、高齢者向け制度、上限運賃、払い戻し、紛失再発行の業務フローも文章化します。この段階で「全国交通系ICを維持するのか」「オープンループを追加するのか」「独自カードを残すのか」を比較すると、後の見積条件が揃いやすくなります。

機能要件では、入出場、残高確認、チャージ、定期券発行、運賃計算、精算、利用履歴、ブラックリスト更新、払い戻し、監査ログを整理します。非機能要件では、改札の応答時間、ピーク時の処理能力、通信断時の継続時間、復旧目標、データの二重計上防止、暗号鍵の更新、端末の遠隔更新、災害時のバックアップを数値で決めます。「高速」「安全」「止まらない」といった形容詞だけでは見積もれないためです。

方式は、パッケージ、交通向けプラットフォーム、クラウドやSaaS、スクラッチ、オープンループ併用を比較します。既存の標準機能が多ければパッケージが有利ですが、独自割引や複数事業者精算が多い場合は追加開発が膨らみます。クラウドを使う場合も、改札側にオフライン判定を残す範囲と、クラウド障害時の業務継続策を明確にします。

方式を絞ったら、実機を借りたPoCを行います。カードとリーダーの相性、スマートフォンの読み取り、連続タッチ、異常な取り外し、通信断からの復旧同期、運賃改定、端末交換を検証します。PoCの目的は完成品を作ることではなく、見積前に技術的な不確実性と責任分界を発見することです。

詳細設計では、端末、駅や営業所のネットワーク、センターサーバー、運賃マスター、精算、会計連携、監視、権限、ログの境界を決めます。並行して、カード鍵や証明書の管理者、端末ファームウェアの更新者、障害時の一次受付と現地対応者を決めます。機能の所有者が不明なまま進めると、障害発生時に複数ベンダーが互いの範囲外として対応が遅れるためです。

試験は、単体試験、結合試験、総合試験、負荷試験、セキュリティ診断、運用リハーサルに分けます。ラッシュ時の連続タッチ、途中で通信が切れるケース、電源断後の再起動、誤った運賃マスター、重複送信、端末交換、ブラックリスト配信をシナリオ化します。現場の駅員や乗務員が使う操作手順まで確認し、利用者を含む本番切替リハーサルを実施します。

最初から全駅・全車両へ広げるのではなく、利用量と設備条件が異なる駅や路線を選び、限定導入します。限定導入で障害率、改札通過時間、精算差異、問い合わせ件数、復旧時間を測定し、合格基準を満たしたら展開範囲を広げます。運賃改定や定期券の年度切替も想定し、稼働後の変更手順を残しておくことが長期運用の安心につながります。

ICカードシステムの費用相場とコストの内訳

ICカードシステムの費用は、駅数や車両数、端末の更新台数、全国相互利用の有無、運賃制度、既存基幹との連携、決済方式で大きく変わります。以下の金額は一律の価格表ではなく、公開事例と類似案件から作った検討用のレンジです。機器を購入するのかリースするのか、補助金を使うのか、保守を何年含めるのかで、同じシステムでも見積総額は変わります。

小規模なバス事業者や地域交通が、既存の決済プラットフォームを利用し、数十台から数百台の車載器を導入する場合は、初期費用5,000万円から3億円、期間6か月から15か月が一つの目安です。中規模のバス・鉄道事業者が、複数拠点、定期券、運賃計算、営業所、会計連携まで構築する場合は、2億円から8億円、期間12か月から24か月程度を想定します。

複数事業者で全国交通系IC、クレジットカードのタッチ決済、QRを併用し、端末更新、精算、利用者移行まで行う場合は、6億円から20億円超、期間18か月から36か月程度になることがあります。大都市圏の駅ネットワークを全面刷新し、改札、券売機、精算機、センター、基幹連携を含めると、数十億円から数百億円の規模もあり得ます。この場合は駅数と機器台数が金額を大きく左右します。

公開実績では、福岡市地下鉄が2026年6月に公表したモバイル定期券サービスのシステム構築業務委託で、消費税を含む提案限度額を2億3,000万円としています。これは既存の交通系ICカードシステムを活用してモバイル定期券を追加する案件であり、改札機を全面更新する相場ではありません（出典: 福岡市交通局「モバイル定期券サービス事業」、2026年）。

費用内訳の仮置きとして、改札機、券売機、車載器などの端末が全体の30%から50%、アプリ、運賃、精算、サーバー開発が20%から35%、既存基幹連携、データ移行、試験が15%から30%、ネットワーク、セキュリティ、教育、切替、予備費が10%から25%程度になります。これは記事作成時点の案件比較から置く推定レンジで、端末が多いほど機器比率が上がり、クラウドやSaaSを使うほど初期費用の一部が月額や従量課金へ移ります。

熊本地域の資料では、全国相互利用カードの機器更新と、クレジットカードなどのタッチ決済を中心とする新決済サービスを比較し、前者を12億1,000万円、後者を6億7,400万円としていました。複数のバス・電鉄事業者を対象にした比較であり、すべての交通事業者にそのまま当てはまる金額ではありませんが、方式選択によって初期投資が大きく変わることを示す具体例です（出典: 熊本市「熊本地域乗合バス事業共同経営に関する状況報告」、2024年公表資料）。

ランニングコストには、端末やサーバーの保守、通信、クラウド利用料、監視、決済手数料、カード発行、データセンター、脆弱性診断、追加改修が含まれます。年間保守を初期開発・調達費の15%から20%程度と仮置きする場合もありますが、端末保守とソフト保守、通信費、決済手数料を分けて提示してもらうことが大切です。初期費用だけを比較すると、5年後のTCOで方式の評価が逆転することがあります。

ICカードシステムの見積もりを取る際のポイント

見積を比較するときは、総額の安さよりも、同じ条件で機器、ソフトウェア、移行、試験、教育、保守が積み上がっているかを確認します。RFPや見積依頼書には、対象路線、駅・車両・端末台数、カード種別、運賃制度、ピーク性能、通信断、切替時期、既存システムとの連携を記載します。条件が曖昧なまま相見積もりを取ると、会社ごとに含める範囲が違い、安いように見える見積ができてしまいます。

機能一覧には、カードの読み取り、入出場、残高、チャージ、定期券、乗継割引、払い戻し、紛失対応、利用履歴、売上集計、事業者間精算、管理画面を含めます。端末一覧には機種、台数、設置場所、交換時期、既存機器の再利用可否を含めます。さらに、運賃マスターの登録者、承認者、適用日時、誤登録時のロールバック方法も書いておくと、運賃改定の開発費を比較しやすくなります。

非機能要件は、1台あたりの応答時間、ピーク時の同時処理数、通信断時の継続時間、復旧目標、データ保持期間、監査ログ、バックアップ、暗号鍵管理、脆弱性対応、遠隔更新、SLAを明記します。改札の応答速度は、平均値だけでなく、ピーク時の最大値と異常系の挙動も求めます。性能試験で使用するカード、端末、通信条件、合格基準まで合意できれば、追加費用の発生を抑えやすくなります。

発注先は、改札機や券売機などのAFC機器に強い会社、クラウドや基幹連携に強いSIer、クレジット決済基盤に強い会社を、役割で見比べます。自社だけで全範囲を持てない場合は、主契約者が全体の障害窓口と責任分界を担えるかを確認します。交通事業の同規模・同方式の稼働実績、現地保守網、24時間対応、再委託先、端末ファームウェアの保守期間も評価対象です。

提案書では、初期費用だけでなく、5年または10年のTCO、追加改修単価、端末の更新費、クラウドの増設費、通信費、決済手数料を比較します。カード鍵、利用履歴、運賃マスター、API、ソースコード、設計書の所有権と利用権も確認します。他社へ移行できるデータ形式やAPIがないと、契約終了時に高額な移行費が発生するためです。

クレジットカードのタッチ決済を採用する場合は、カード番号を自社環境に保存・処理・通過させない非保持化やトークン化を含め、決済事業者との責任分界を早期に確認します。経済産業省は2025年3月にクレジットカード・セキュリティガイドライン6.0版を公表しており、これは割賦販売法上のセキュリティ対策に関する実務上の指針と位置付けられています。PCI DSS v4.0.1はPCI Security Standards Councilが公開する業界基準で、法令そのものではありませんが、決済事業者や委託先との要件確認で重要になります（出典: 経済産業省、PCI Security Standards Council、2025年資料）。

契約では、請負と準委任の範囲、要件変更時の単価、検収条件、障害の重大度別SLA、復旧時間、損害賠償の上限、再委託、脆弱性発見時の報告、データ返却、契約終了後の移行支援を定めます。運賃改定や制度変更は完全に予測できないため、変更管理委員会と承認フロー、緊急時の暫定対応を契約に含めると、稼働後の対立を減らせます。

ICカードシステム開発でよくある質問（FAQ）

ここでは、ICカードシステムを企画する担当者が特に確認しやすい質問に回答します。費用や期間は対象範囲で変わるため、回答の数字は一般的な検討レンジとして読み、最終的には同じRFPで複数社から見積を取得してください。

小規模な地域交通で5,000万円から3億円、中規模で2億円から8億円、複数事業者や複数決済を含む大規模案件で6億円から20億円超が検討レンジです。改札機を全面更新するか、既存基盤へモバイル定期券やタッチ決済を追加するかで金額は大きく変わります。機器、開発、連携、移行、試験、保守を分けて見積もることが重要です。

既存プラットフォームを利用した小規模導入なら6か月から15か月、中規模なら12か月から24か月、複数事業者で端末更新や利用者移行まで行う場合は18か月から36か月程度が目安です。駅ネットワークの全面刷新では3年から5年以上かかることもあります。カード接続条件、機器調達、現場試験、運賃改定の時期、切替可能な深夜時間帯がスケジュールを左右します。

クラウドをセンターサーバーや運賃・履歴・分析の基盤として使うことはできますが、改札や車載器の全処理を通信に依存させる設計は避けるべきです。現場側に最低限の判定、暗号化ログ、通信断時の継続機能を持たせ、復旧後に重複なく同期するハイブリッド構成を検討します。通信断時の継続時間と、復旧できない場合の駅員・乗務員の代替手順を要件に含めてください。

一律に置き換えるのではなく、交通系ICを定期券や細かな割引、日常利用に残し、タッチ決済を一見客や訪日客向けに追加する併用が現実的です。熊本地域の公開資料でも、全国交通系ICの更新とクレジットカードなどのタッチ決済で異なる投資額を比較しており、費用だけでなく利用者影響、決済手数料、通信、カード発行、運賃制度まで含めたTCOで判断する必要があります。

まとめ

ICカードシステム開発では、カードの読み取り機能だけでなく、運賃、定期券、精算、既存基幹、ネットワーク、監視、保守までを一つのサービスとして設計します。進め方は、現状調査、方式比較、要件定義、PoC、実機負荷試験、段階導入、全体展開の順に進めると、現場停止や追加費用のリスクを抑えやすくなります。

費用は、小規模な地域交通で5,000万円から3億円、中規模で2億円から8億円、複数事業者・複数決済で6億円から20億円超が検討レンジです。公開実績の金額は対象範囲を示す参考値であり、自社の駅数、車両数、端末、運賃制度、移行、保守を同じ条件で積み上げて比較する必要があります。初期費用だけでなく、保守、通信、クラウド、決済手数料、更新費を含めたTCOで判断してください。

発注前には、機能要件と非機能要件、障害時の責任分界、データや鍵の権利、SLA、変更管理、契約終了後の移行条件をRFPにまとめます。全国交通系IC、タッチ決済、QR、顔認証は目的と制約が異なるため、利用者と業務ごとに組み合わせます。まずは実機を使ったPoCと限定導入の計画を作り、測定可能な合格基準を定めることが、長く使えるICカードシステムへの第一歩です。

▼全体ガイドの記事
・ICカードシステム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。