ICカードシステム開発の発注/外注/依頼/委託方法について

ICカードシステムの発注では、カードを読み取る機器だけでなく、運賃計算・精算・改札や車載器の通信断対策まで含む交通基盤として要件を定めることが成功の近道です。

本記事では、交通系ICカードに対応したシステムの発注・外注・委託を検討する事業者に向けて、発注形態の選び方、RFPと要件整理、契約形態、費用相場、委託先の選定と見積比較のポイントを順番に解説します。地方バス事業者から複数駅を持つ鉄道事業者まで、自社に必要な範囲を切り分けて判断できるように、2026年時点で確認できる公開事例も交えて説明します。

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

ICカードシステムを発注する前に押さえる全体像

交通系ICカードのシステムは、改札機やバス車載器の読み取り処理、券売機や窓口端末、運賃マスター、センターサーバー、売上集計、事業者間精算、監視・保守を組み合わせたAFC（自動料金収受）システムです。発注時は機器とソフトウェアを別々に買うのではなく、利用者がタッチしてから精算データが確定するまでの業務全体を一つのサービスとして捉える必要があります。

最低限、カードの入出場判定、残高や定期券の判定、運賃計算、乗継割引、チャージ、払い戻し、利用履歴、売上集計を洗い出します。鉄道であれば駅数・改札通路数・券売機台数、バスであれば車両数・営業所数・車載器台数を整理します。さらに、通信断や停電が起きても現場を継続運転できる時間、復旧後のログ同期、二重計上の防止、ブラックリスト配信までRFPに含めることが重要です。

全国相互利用の交通系ICを維持するか、クレジットカードのタッチ決済（オープンループ）やQR乗車券を追加するかは、利用者層と運賃制度で決まります。交通系ICは定期券や複雑な割引、短い応答時間に向いています。一方、クレカタッチはカード発行なしで利用でき、訪日客や一見客の取り込みに向いていますが、決済認証や通信、チャージバック、精算の責任分界が別途必要です。全国ICを単純に置き換えるのではなく、通勤・通学利用は交通系IC、観光利用はタッチ決済という併用も発注時の有力な選択肢です。

ICカードシステムの発注形態はどれを選ぶべきですか？

発注形態は、パッケージや既存プラットフォームを利用する方式、クラウド・SaaSを組み合わせる方式、スクラッチ開発を中心にする方式の三つに整理できます。結論として、既存の交通基盤を使える部分は標準サービスに寄せ、独自運賃や既存基幹との接続だけを追加開発するハイブリッド型が、費用と将来の変更しやすさを両立しやすいです。

改札機、券売機、精算機、運賃管理、センターサーバーを実績のあるプラットフォームから選ぶ方式です。標準機能が自社の業務に合えば、設計・試験のリスクを抑えられ、導入後の保守体制も確保しやすくなります。日本信号は自動改札機、自動券売機、自動精算機からセンターサーバーまでを総合ネットワーク化した駅務システムを提供しており、AFCベンダーに相談する場合は、このようにどこまで一括で対応できるかを確認します（出典：日本信号「駅務自動化システム」）。

利用履歴、アカウント、運賃ロジック、分析、決済連携をセンター側に集約し、駅や車両側には短時間の判定とオフライン運転に必要な機能を持たせる方式です。初期の設備投資を抑えやすい一方、月額利用料、従量課金、通信費、データ保管費が継続します。RFPでは、クラウド障害時に改札を何時間継続できるか、データの所在、バックアップ、復旧目標、サービス終了時のデータ返却方法まで書きます。

地域独自カード、特殊な乗継割引、複数事業者の共同精算、鉄道・バス・MaaSの深い連携など、標準機能では対応できない要件が多い場合はスクラッチ開発が候補になります。ただし、カード仕様、暗号鍵、端末ファームウェア、運賃改定、障害対応、24時間監視を誰が長期保有するのかを決めなければなりません。初期見積が安く見えても、開発会社の担当者が交代した後の保守費や、別会社へ移行するためのAPI・データ形式が未整備だと、将来の発注自由度が失われます。

RFPと要件整理では何を決めればよいですか？

RFPは「ICカードに対応したシステムが欲しい」という要望書ではなく、対象範囲、性能、移行、運用、責任分界、見積条件を候補会社が同じ前提で理解できる資料にします。要件が曖昧なまま相見積もりを取ると、A社は機器込み、B社はソフトウェアだけという比較不能な提案になり、最安値を選んだ後に追加費用が膨らみます。

最初に、駅・停留所・営業所・車両・改札通路・券売機・窓口端末・車載器の台数と設置場所を一覧にします。次に、Suica・PASMO・ICOCAなどの全国相互利用カード、地域独自カード、モバイル端末、定期券、障害者割引、回数券や上限運賃の有無を記載します。ピーク時間帯の1分当たり通過人数、同時接続数、日次取引件数、締め処理の時刻も数値化します。これらの基礎データがないと、必要なサーバー性能や通信帯域、端末台数を正しく見積もれません。

機能要件には、入出場処理、残高・定期券判定、運賃計算、乗継割引、チャージ、払い戻し、再発行、利用履歴照会、売上集計、事業者間精算、運賃マスター更新を含めます。既存の会計・顧客・販売管理との連携では、データ項目、連携頻度、エラー時の再送、締め後の訂正方法を定義します。データ移行では、残高・定期券・利用者ID・ブラックリストのどれを移すか、移行リハーサルを何回行うか、旧システムをいつまで参照可能にするかを明記します。

改札や車載器は、応答が遅いだけでも列や運行遅延につながります。RFPでは、通常時とピーク時の応答時間、許容するタイムアウト、通信断時に現場だけで継続できる時間、センター障害から復旧する目標時間、復旧後の同期順序、データ欠損の許容範囲を数値で定めます。加えて、冗長化、停電時の電源、監視アラート、遠隔アップデート、操作ログ、脆弱性診断、災害時の代替運用を含めます。候補会社には、数値を満たしたことを証明する負荷試験計画と試験結果の提出を求めます。

契約形態は請負と準委任をどう使い分けますか？

ICカードシステムは、企画・要件定義の段階では不確定な事項が多く、詳細設計・開発・試験に進むほど成果物を定義しやすくなります。そのため、上流を準委任、確定した開発や機器調達を請負とする段階契約が実務に合いやすいです。契約名称だけで判断せず、成果物、検収、変更手続き、責任分界を本文と別紙で明確にします。

現状調査、方式比較、業務フロー整理、RFP作成支援、実機を使ったPoC、要件定義は、作業を通じて発注者と受託者が仕様を固める工程です。作業時間や体制に対して報酬を支払う準委任であれば、途中で前提が変わった場合にも合意を更新しやすくなります。ただし、準委任だから成果物が不要になるわけではありません。会議体、課題管理表、要件定義書、PoC結果、残課題一覧を納品物として定めます。

詳細設計、ソフトウェア開発、端末設定、データ移行、総合試験など、成果物と完成条件を定義できる工程は請負契約に向いています。検収条件には、機能一覧の全項目、ピーク負荷、通信断・停電・復旧、運賃改定、締め処理、権限管理、監査ログを含めます。「納品したら検収」ではなく、試験証跡と未解決の重大障害がないことを確認して検収する仕組みにします。

運賃制度や法令、接続先の仕様が変わると、稼働後にも改修が発生します。追加改修の見積単価、緊急対応の料金、価格改定の条件、再委託の範囲、障害の一次受付と現地駆け付け、SLA、損害賠償の上限を事前に確認します。カード鍵や利用履歴などのデータ所有権、ソースコードの利用権、設計書の更新義務、契約終了時のデータ返却と移行支援も欠かせません。経済産業省のクレジットカード・セキュリティガイドラインは割賦販売法上の実務上の指針として位置付けられているため、決済を含む案件では、法令・ガイドライン・カードブランド基準のどれに対して誰が対応するかを記録します（出典：経済産業省、2025年3月改訂）。

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

ICカードシステムの費用は、駅・車両・端末の台数、カード方式、運賃の複雑さ、既存機器の再利用、決済や会計との連携、移行・保守の範囲で大きく変わります。公開事例と類似案件からの推定を分けて考えることが大切です。公開価格をそのまま自社の相場とみなさず、同じ前提条件で見積を比較します。

小規模な地域交通で、既存の決済プラットフォームを使い、数十台から数百台の車載器を導入する場合は、初期費用5,000万円から3億円程度、期間6か月から15か月が一つの検討レンジです。複数拠点や定期券、運賃計算、営業所・会計連携まで含む中規模案件は、2億円から8億円程度、12か月から24か月が目安になります。複数事業者で全国交通系IC、クレカタッチ、QRを併用し、端末更新と利用者移行まで行う場合は、6億円から20億円超、18か月から36か月程度を想定します。これらは公開事例と類似案件からの推定であり、価格表ではありません。

福岡市地下鉄は2026年6月、既存の交通系ICカードシステムを活用したモバイル定期券サービスのシステム構築業務について、提案限度額を2億3,000万円（税込）と公表しました。これは改札機を全面刷新する費用ではなく、既存基盤へモバイル定期券を追加する案件です（出典：福岡市地下鉄「モバイル定期券サービス事業」提案競技、2026年）。

熊本地域の共同経営に関する資料では、くまモンICと全国交通系ICを更新する費用を12億1,000万円、くまモンICとクレジットカードなどのタッチ決済を導入する費用を6億7,400万円として比較しています。複数のバス・電鉄事業者を対象とした比較なので、全国ICの更新が常に12億円になるという意味ではありません。方式によって機器、契約、利用者移行、精算の範囲が変わることを示す材料として、RFPの比較軸に使います（出典：熊本市「熊本地域乗合バス事業共同経営に関する状況報告」）。

見積書は、端末・改札機・券売機・車載器、アプリ・運賃・精算・サーバー開発、既存基幹連携、データ移行・試験、ネットワーク・セキュリティ・教育・切替・予備費に分けます。一般的な仮置きとして、端末類30〜50％、ソフトウェア20〜35％、連携・移行・試験15〜30％、ネットワークなど10〜25％程度の比率を置けますが、ハード中心の案件とクラウド中心の案件では構成が変わります。年間保守は初期開発・調達費の15〜20％程度を仮置きしつつ、端末保守、クラウド、通信、決済手数料、追加改修を別行にすることが重要です。

委託先の選定と見積比較で確認するポイント

委託先は、会社名の知名度や初期価格だけで選びません。改札機・車載器・クラウド・決済・現地保守をどこまで自社で持つか、同規模・同方式の稼働実績があるか、障害時に誰が指揮を執るかを確認します。候補会社が複数領域にまたがる場合は、主契約者と再委託先の責任分界、機器メーカーや決済事業者との契約関係も聞き取ります。

実績は「交通分野の実績あり」だけでは不十分です。駅数・車両数、交通系ICの種類、定期券や割引、ピーク処理、複数事業者精算、通信断対応、稼働年数が自社と近い案件を示してもらいます。導入事例の名称を開示できない場合でも、規模、役割、稼働開始年、保守範囲、障害対応の体制は確認できます。24時間365日の監視、現地駆け付けの地域、予備機の保有、部品の供給年数、担当者不在時の代替体制も評価項目にします。

相見積もりでは、候補会社に同じRFP、同じ台数表、同じ導入時期、同じ試験範囲を渡します。比較表には、初期費用、月額・年額、機器の購入またはリース、通信、決済手数料、カード発行、移行、教育、現地切替、保守、追加改修の単価を並べます。「含む」「別途」「対象外」「前提未確定」を区別し、未確定項目には上限額か算定方法を書いてもらいます。極端に安い提案は、ライセンス、データ移行、性能試験、休日作業、旧システムとの並行稼働が除外されていないかを確認します。

クレジットカードのタッチ決済を含む場合は、カード番号を自社で保存・処理・通過させない非保持化、トークン化、ネットワーク分離、脆弱性診断、アクセス権限、ログ監視の範囲を確認します。PCI DSSはカード会員データを保護するための業界基準であり、PCI SSCの文書ライブラリでは2024年6月版のPCI DSS v4.0.1が掲載されています。採用しただけで責任がなくなるわけではないため、決済代行会社、受託会社、自社の各責任をRFPと契約に反映します（出典：PCI Security Standards Council「Document Library」）。

また、専用形式のデータや非公開APIに依存しすぎると、契約終了時に別会社へ移行できません。利用履歴、残高、定期券、運賃マスター、精算データを標準的な形式で取り出せるか、API仕様書やデータ辞書を受け取れるか、ソースコードの利用権やエスクローが必要かを確認します。2026年7月には、既存改札機にカメラを追加し、複数メーカーの改札機と顔認証基盤を連携する仕組みが発表されました。既存機器を活用する選択肢が広がる一方、将来の機能追加を見据えた接続仕様の確認が一層重要になっています（出典：日立製作所ほか「SAKULaLaを活用した顔認証改札の仕組み」、2026年7月）。

よくある質問（FAQ）

ここでは、ICカードシステムの発注・外注を検討する際によく寄せられる質問に回答します。費用だけでなく、発注前の準備と契約後の運用まで含めて判断することが大切です。

小規模な地域交通で5,000万円から3億円程度、中規模で2億円から8億円程度、複数事業者・複数決済・端末更新まで含む案件で6億円から20億円超が一つの目安です。ただし、公開事例と類似案件からの推定であり、駅・車両数、端末、運賃制度、移行、保守によって変わります。初期費用だけでなく、月額、通信、決済手数料、機器更新、追加改修を含むTCOで比較します。

対象となる駅・車両・端末、カード種別、定期券・割引・運賃制度、ピーク処理量、応答時間、通信断時の継続運転、既存システム連携、データ移行、試験、切替、保守、SLA、セキュリティ、再委託、データ所有権を記載します。見積の比較ができるように、購入・リース、ライセンス、クラウド、通信、教育、休日作業などの費目を指定し、含む範囲と除外項目を分けて提示してもらいます。

要件定義やPoCのように前提を整理しながら進める工程は準委任、詳細設計・開発・試験のように成果物と完成条件を定められる工程は請負が基本的に使いやすいです。実際には、上流を準委任、開発と機器調達を請負に分ける段階契約が適しています。契約形態よりも、成果物、検収、変更管理、障害対応、データとソースコードの権利を明文化することが重要です。

一律に置き換えるのではなく、利用者と運賃制度で判断します。定期券、複雑な割引、短い応答時間を重視する通勤・通学利用では交通系ICを維持し、カード発行を避けたい観光客や一見客にはクレカタッチを追加する併用が現実的です。熊本地域の公開比較でも、全国交通系IC更新とクレジットなどのタッチ決済では費用とサービス範囲が異なっているため、利用者影響、移行費、決済手数料、保守を含めて比較します。

まとめ

ICカードシステムの発注・外注・委託では、最初に「何を読み取るか」ではなく、「どの利用者に、どの運賃を適用し、どの機器とデータを通じて、どの水準で運用するか」を決めます。交通系IC、クレカタッチ、QRなどの方式を比較し、既存機器を活かす範囲と新しく作る範囲を切り分けます。

次に、設備・業務の棚卸し、機能要件、性能・通信断・復旧などの非機能要件、移行、試験、保守、セキュリティをRFPにまとめます。候補会社には同じ条件で提案を求め、価格だけでなく、同規模の稼働実績、現地保守、責任分界、データの持ち出しやすさ、追加改修の透明性を評価します。

契約は、要件定義・PoCを準委任、成果物が確定した開発・試験を請負とするなど、工程に合わせて組み立てます。検収条件、変更管理、障害時のSLA、データ所有権、ソースコード、再委託、終了時の移行支援を明記します。初期費用の安さだけでなく、保守、通信、決済手数料、機器更新、追加改修まで含む総保有コストを比べることで、長く安定して使える委託先を選びやすくなります。

▼全体ガイドの記事
・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を創業。