ICカードシステムの発注は、利用者と運賃の整理、RFPの作成、契約と見積もりの比較の順に進めると、必要な交通基盤を導入しやすくなります。発注形態の選び方から委託先の選定まで、段階ごとに決めることを順に説明します。
▼全体ガイドの記事
・ICカードシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
ICカードシステムを発注する前に押さえる全体像
交通系ICカードのシステムは、改札機やバス車載器、券売機や窓口端末、運賃マスター、センターサーバーを組み合わせたAFC（自動料金収受）システムです。
読み取りから精算・保守までの発注範囲
発注では、機器とソフトを別々に考えず、タッチから精算データの確定までを一つのサービスとして捉えます。
- 運賃業務：入出場判定、残高・定期券判定、運賃計算、乗継割引が対象です。
- 利用者対応：チャージ、払い戻し、利用履歴、再発行の範囲。
- 運用と精算：売上集計、事業者間精算、監視・保守。
最低限、鉄道は駅数・改札通路数・券売機台数、バスは車両数・営業所数・車載器台数を整理しておきます。通信断や停電への備えも欠かせず、継続運転時間や復旧後のログ同期、二重計上の防止、ブラックリスト配信をRFPに盛り込みます。
交通系IC・クレカタッチ・QRの使い分け
方式は、利用者層と運賃制度を見て選びます。
- 交通系IC：定期券、複雑な割引、短い応答時間に適しています。
- タッチ決済：カード発行なしで利用でき、訪日客や一見客に向きます。
- 併用：全国ICを一律に置き換えず、通勤・通学は交通系IC、観光はタッチ決済に分けます。
決済認証、通信、チャージバック、精算それぞれについて、どこまでを誰が受け持つかを別途決めておきます。
ICカードシステムの発注形態の選び方
発注形態は、既存プラットフォーム、クラウド・SaaS、スクラッチ開発の三つに分けて考えられます。
既存基盤の標準サービスを使い、独自の運賃や既存基幹との接続だけを追加で開発する形は、費用と将来の変更しやすさを両立させやすい方式です。
パッケージ・既存プラットフォームの利用
改札機や券売機を中心に、精算機や運賃管理、センターサーバーまでを、実績のある基盤から選びます。標準機能が業務に合っていれば、設計や試験のリスクを抑えやすく、保守体制も確保しやすくなります。
たとえば日本信号は、自動改札機、自動券売機、自動精算機からセンターサーバーまでを総合ネットワーク化した駅務システムを提供しています。
AFCベンダーに相談する場合は、どこまでを一括で対応できるかを確認します（出典：日本信号「駅務自動化システム」）。
クラウド・SaaSの組み合わせ
利用履歴や運賃ロジック、決済連携などをセンター側に集約する構成です。そのうえで、駅や車両側には短時間の判定とオフライン運転の機能を持たせます。
初期投資を抑えやすい反面、稼働後も月額利用料、従量課金、通信費、データ保管費が続きます。
RFPには、障害時の継続時間やデータの所在を書きます。加えて、バックアップと復旧目標、終了時の返却方法も記載します。
スクラッチ開発の独自性と長期保守
標準機能で足りない要件が多い場合は、スクラッチ開発が候補になります。地域独自カードや特殊な乗継割引、共同精算などが該当します。
カード仕様や暗号鍵、端末ファームウェアを、誰が長期にわたって保有するかを決めます。運賃改定や障害対応、24時間監視についても、長期の担い手を決めておきます。
保守費が不明確なまま、または別会社へ移すためのAPI・データ形式が未整備のままだと、将来の発注の自由度が失われます。
RFPと要件整理で決める項目
RFPは、候補会社が同じ前提で読める資料にします。「ICカード対応」の一行では要件の範囲が読み取れないため、対象範囲や性能、移行の条件を具体的に書きます。運用や責任分界、見積条件も、同じ水準で書き込みます。
要件が曖昧なままだと、機器込みの提案とソフトだけの提案を比べられず、最安値で選んだあとに追加費用が膨らむ恐れがあります。
現状の設備・業務・利用者の洗い出し
設備の台数と設置場所は、一覧にまとめます。拠点は駅や停留所、営業所、車両で、機器は改札通路や券売機、窓口端末、車載器です。
- カードと運賃：カードの種別（Suica・PASMO・ICOCA、地域独自カード、モバイル端末）、定期券、障害者割引、回数券、上限運賃。
- 処理量：ピーク時の毎分通過人数や同時接続数、日次取引件数、締め時刻を数字で示します。
基礎データがないと、必要なサーバー性能や通信帯域、端末台数を正しく見積もれません。
運賃・精算・移行に関する機能要件
必要な機能、既存システムとの連携、移行条件は、それぞれ具体的に書いておきます。
- 運賃処理：入出場、残高・定期券判定、運賃計算、乗継割引。
- 利用者対応：チャージ、払い戻し、再発行、履歴照会。
- 集計・更新：売上集計、事業者間精算、運賃マスター更新。
- 既存システム連携：会計・顧客・販売管理のデータ項目、頻度、エラー時の再送、締め後の訂正。
- データ移行：残高、定期券、利用者ID、ブラックリストの対象、リハーサル回数、旧システムの参照期限。
非機能要件の応答・継続運転・復旧の数値
改札や車載器の遅れは、列や運行の遅延につながります。そのため、応答や継続運転、復旧の条件を数値で示します。
- 応答性能：通常時・ピーク時の応答時間と許容タイムアウト。
- 継続運転・復旧：通信断時の継続時間、復旧目標、同期順序、データ欠損の許容範囲。
- 運用対策：設備面（冗長化、停電時電源）、監視アラートと遠隔更新、操作ログ、脆弱性診断、災害時の代替運用。
候補会社には、要件を満たすことを示す負荷試験の計画と結果を提出してもらいます。
請負と準委任の使い分け
企画や要件定義では不確定な事項が多く、詳細設計・開発・試験では、成果物を定めることができます。そのため、上流は準委任、確定した開発や機器調達は請負とする段階契約が実務に合います。
契約名称だけで決めず、契約を結ぶ際には、成果物や検収、変更の手続きを、契約本文と別紙で明確にします。どこまでを誰が受け持つかも、同じ書類で決めておきます。
要件定義とPoCに準委任を使う場面
現状調査や方式比較、業務フロー整理は、作業を通じて仕様を固める工程です。RFP作成支援や実機PoC、要件定義もこれに当たります。準委任は作業時間や体制に対する報酬のため、前提が変わったときに合意を更新しやすくなります。
準委任でも成果物は必要で、会議体や課題管理表を納品物として定めます。要件定義書やPoC結果、残課題一覧も、納品物に含めます。
確定した機能・機器の請負と検収条件
成果物と完成条件を定義できる工程は、請負に向いています。詳細設計やソフト開発、端末設定が該当し、データ移行や総合試験も含まれます。
検収条件には、機能一覧の全項目やピーク負荷、通信断・停電・復旧を含めます。運賃改定や締め処理、権限管理、監査ログも対象に入れます。
検収では、納品の事実だけでなく、試験証跡と重大な未解決障害がないことを確かめます。
変更・障害・データの責任範囲の取り決め
契約の段階で、各項目の対応者を文書にしておきます。
- 変更：追加改修の単価、緊急料金、価格改定、再委託の範囲。
- 障害対応：一次受付、現地駆け付け、SLA、損害賠償上限。
- データと権利：カード鍵・履歴の所有権、ソース利用権、設計書の更新、終了時の返却・移行支援。
- 決済の責任：法令・ガイドライン・カードブランド基準ごとの対応者。
経済産業省の「クレジットカード・セキュリティガイドライン」は、割賦販売法上の実務上の指針です。
そのため、決済を含む案件では、法令、ガイドライン、カードブランド基準のそれぞれに、誰が対応するかを記録しておきます（出典：経済産業省、2025年3月改訂）。
ICカードシステムの費用相場と見積内訳
費用は、駅・車両・端末数やカード方式、運賃の複雑さによって変わります。さらに、機器の再利用や連携、移行・保守の範囲も影響します。そのため、公開事例と類似案件の推定は分けて読み、同じ条件で比べます。
規模別の初期費用の幅
車載器中心の小規模な導入から、複数事業者の決済や利用者移行まで含む構成へと進むほど、費用も導入期間も大きくなります。
- 小規模：既存決済基盤と数十台から数百台の車載器を使う案件。
- 中規模：複数拠点、定期券、運賃計算、営業所・会計連携を含む案件。
- 複数事業者：全国交通系IC・クレカタッチ・QRを併用し、端末更新と利用者移行を行う案件。
小規模な地域交通の場合、初期費用は5,000万円から3億円程度、期間は6か月から15か月が検討の目安です。中規模の案件では、2億円から8億円程度、12か月から24か月が目安になります。
複数事業者で決済の併用から端末更新、利用者移行まで行う場合は、6億円から20億円超、18か月から36か月程度を想定します。いずれも、公開事例と類似案件からの推定であり、価格表ではありません。
公開事例の金額の読み方
公開価格は、案件の対象範囲を確かめたうえで、同じ条件で見積もるための比較材料として使います。
- 福岡市地下鉄：交通系IC基盤を使うモバイル定期券サービス構築の提案限度額は2億3,000万円（税込）です。
- 熊本地域：くまモンICと全国交通系ICの更新は12億1,000万円、くまモンICとクレジットカードなどのタッチ決済導入は6億7,400万円です。
福岡市地下鉄は2026年6月に公表しました（出典：福岡市地下鉄「モバイル定期券サービス事業」提案競技、2026年）。これは既存基盤へのサービス追加で、全改札を刷新する案件ではありません。
熊本地域の金額は、複数のバス・電鉄事業者を対象とした比較です。全国ICの更新費用が常に12億円になるわけではありません。
方式によって範囲が変わるため、機器から精算までを、RFPの比較軸として使います（出典：熊本市「熊本地域乗合バス事業共同経営に関する状況報告」）。
端末・開発・移行・保守の分け方
費用は、初期導入に必要な項目と、稼働後の保守項目に分けて整理します。
- 端末・開発：改札機、券売機、車載器と、アプリ・運賃・精算・サーバー。
- 関連費：既存基幹連携やデータ移行・試験、ネットワーク・セキュリティ、教育、切替、予備費。
- 初期費用の比率：端末類30〜50％、ソフト20〜35％、連携・移行・試験15〜30％、ネットワーク等10〜25％。
- 年間保守：初期開発・調達費の15〜20％程度を仮置きします。
- 別行の費用：端末保守、クラウド、通信、決済手数料、追加改修。
比率は一般的な仮置きにすぎず、ハード中心かクラウド中心かといった案件の構成によって変わります。
委託先の選定と見積比較で確認するポイント
委託先は、知名度や初期価格だけでなく、機器やクラウド、決済、現地保守のうち、どこまでを自社で持つかで比べます。同規模・同方式の実績や、障害時に誰が指揮を執るかも見ておきます。
複数の領域にまたがる場合は、主契約者と再委託先の間で、どこまでを誰が受け持つかを確かめます。機器メーカーや決済事業者との契約関係も確認します。
同規模・同方式の実績と保守体制
交通分野の実績に加えて、駅・車両数やIC種、定期券・割引が近い事例を求めます。さらに、ピーク処理や複数社精算、通信断対応、稼働年数も比べます。
事例名を開示できなくても、規模や役割、稼働開始年を確認できます。保守範囲と障害対応も確かめられます。
24時間365日の監視と駆け付け地域を評価します。予備機や部品供給年数、担当者不在時の代替体制も見ます。
見積比較の前提条件と除外項目
同じRFPと台数表、導入時期、試験範囲を、候補会社すべてに渡します。そのうえで、見積項目を同じ基準で比べます。
- 費用：初期費用、月額・年額、購入・リース、通信、決済。
- 導入：カード発行、移行、教育。
- 稼働後：切替、保守、追加改修。
各項目は「含む」「別途」「対象外」「前提未確定」に分けます。未確定項目には、上限額か算定方法を示してもらいます。
極端に安い提案では、費目の抜けを特に確かめます。
- 除外項目：ライセンス、移行、性能試験が除外されていないか。
- 作業の条件：休日作業や旧システムとの並行稼働が見積もりから漏れていないか。
セキュリティ・データ移行・ベンダーロックインの見方
クレジットカードのタッチ決済を含む場合は、決済情報の保護、データの移行性、将来の接続性を確認します。
- 決済情報：カード番号を自社で保存・処理・通過させない非保持化、トークン化、ネットワーク分離、脆弱性診断、アクセス権限、ログ監視。
- 責任分担：決済代行、受託会社、自社の対応責任を、RFPと契約に反映します。
- 移行性：履歴、残高、定期券、運賃マスター、精算データの標準形式での書き出し。
- 契約終了時：API仕様書、データ辞書、ソースコード利用権、エスクローの要否。
PCI DSSはカード会員データを保護するための業界基準です。PCI SSCの文書ライブラリに掲載されているPCI DSS v4.0.1は、2024年6月版です（出典：PCI Security Standards Council「Document Library」）。
将来の接続性については、既存機器と新しい仕組みをつなぐ例も出ています。2026年7月には、既存改札機にカメラを追加し、複数メーカーの改札機と顔認証基盤を連携する仕組みが発表されました。既存機器を活用する選択肢が広がったため、将来の機能追加を見据えて接続仕様を確認しておきます（出典：日立製作所ほか「SAKULaLaを活用した顔認証改札の仕組み」、2026年7月）。
よくある質問（FAQ）
発注前の準備から契約後の運用まで含めて、よくある質問に答えます。
ICカードシステムの発注費用はいくらですか？
目安は、小規模な地域交通で5,000万円から3億円程度、中規模で2億円から8億円程度です。複数事業者や複数決済、端末更新まで含む案件では、6億円から20億円超が一つの目安になります。
公開事例と類似案件からの推定で、駅・車両数や端末、運賃制度によって変わります。移行や保守の範囲でも変わります。初期費用だけでなく、月額や通信、決済手数料、機器更新、追加改修まで含めたTCO（総保有コスト）で比べます。
RFPには何を書けばよいですか？
対象となる駅・車両・端末、カード種別、定期券・割引を記載します。運賃制度やピーク処理量、応答時間も書き込み、通信断時の継続運転も加えます。
既存システム連携や移行、試験、切替は、RFPに明記します。保守やSLA、セキュリティ、再委託、データ所有権も、同じ資料に記します。
購入・リースやライセンス、クラウドを含めて費目を指定します。通信や教育、休日作業も費目に入れます。含む範囲と除外項目は、分けて提示してもらいます。
請負契約と準委任契約はどちらがよいですか？
要件定義やPoCのように前提を整理しながら進める工程は準委任が使いやすく、成果物と完成条件を定められる設計・開発・試験は、基本的に請負が向いています。
実際には、上流を準委任、開発と機器調達を請負に分ける段階契約が適しています。
成果物と検収、変更管理、障害対応を明文化します。データとソースコードの権利も、書面にします。
交通系ICをクレカタッチ決済に置き換えるべきですか？
置き換えるかどうかは、利用者と運賃制度で判断します。定期券や複雑な割引、短い応答時間を重視する通勤・通学には、交通系ICが向きます。
カード発行なしで利用したい訪日客や一見客には、クレカタッチを追加する併用が現実的です。
熊本地域の公開比較でも、全国IC更新とタッチ決済では費用と範囲が異なります。利用者影響や移行費、手数料、保守を含めて比べます。
まとめ
発注では、利用者にどの運賃を適用するか、どの機器とデータで、どの水準の運用を行うかを決めます。そのうえで方式を比べ、既存機器を活かす範囲と新しく作る範囲を切り分けます。
発注前のRFPと評価表の作成
RFPには、設備と業務の洗い出し、機能・非機能要件を書きます。移行や試験、保守、セキュリティもまとめます。
同じ条件で提案を求めたうえで、価格に加えて実績や現地保守を評価します。さらに、責任分界やデータ移行、追加改修の透明性も見ます。
稼働後までを含めた契約と費用の比較
工程に応じて準委任と請負を組み合わせ、検収や変更管理、SLAを明記します。データの権利や再委託、終了時の移行支援も、契約に入れます。
保守や通信のほか、決済手数料や機器更新、追加改修まで含めた総保有コストで比べると、長期の運用を見据えた委託先を選びやすくなります。
▼全体ガイドの記事
・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を創業。