ICカードシステム開発の完全ガイド

ICカードシステムは、カード方式、現場機器とセンターの構成、運賃・精算の業務機能に分けて捉えると、必要なサービスと運用条件を整理できます。

構成や方式の違い、開発工程、費用、発注・運用の注意点を順に取り上げます。関連記事も合わせてご覧ください。

▼関連記事一覧
・ICカードシステム開発の進め方
・ICカードシステム開発でおすすめの開発会社6選と選び方
・ICカードシステム開発の見積相場・費用
・ICカードシステム開発の発注・外注・委託方法

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

ICカードシステムの概要

ICカードシステムは、カード認証から乗車受付、売上確定までをつなぐAFC（自動料金収受）基盤です。

利用者が改札や車載器にタッチすると、端末がカード情報を読み取ります。

端末は続けて、入出場の状態、残高、定期券の有効区間、運賃ルールを照合します。その結果は現場端末やセンターに記録され、売上集計や事業者間精算に使われます。

AFCとして備える主な機能

AFCには、乗車処理とカード管理に関する機能のほか、運行中の機器や売上を管理する機能も必要です。

• 乗車・運賃：入出場、運賃計算、乗継割引、運賃上限を扱います。
• カード管理：定期券の発行・更新、チャージ、払い戻し、紛失停止、履歴照会を行います。
• 機器・売上管理：改札機などの状態監視、運賃マスター配信、ブラックリスト更新、障害通知、監査ログ、日次・月次の売上集計を担います。

駅や車庫の通信が一時的に切れた場合でも、現場の端末は最低限の判定を続けられる必要があります。

復旧後にログを安全に同期する機能も欠かせません。

機器・ネットワーク・業務の三層構成

システム全体は、現場機器、通信・エッジ、センター・業務アプリの三層に分けて捉えられます。

• 現場機器：改札機、簡易改札機、券売機、精算機、窓口端末、バス車載器の設置。
• 通信・エッジ：駅や車両ごとの制御、オフライン継続、ログ蓄積、遠隔更新の担当部分。
• センター・業務アプリ：運賃、顧客、カード、決済、売上、精算、監視の統合。

現場機器には、リーダーライターやプリンターなどの組込み部品も含まれます。

ICカードシステムの種類と方式の比較

方式は、カード媒体だけでなく、運賃計算や認証をどこで行うか、通信断にどう備えるかでも分けられます。

必要なサービスを分解してから方式を選ぶと、比べやすくなります。

全国相互利用の交通系ICや地域独自カードは、利用者や運賃制度によって併用できます。さらに、クレジットタッチ、QR乗車券、モバイル定期券も、利用者や運賃制度によって併用できます。

交通系ICカードと地域独自カード

交通系ICと地域独自カードは、導入後に自社が担う運用の範囲が違います。

• 交通系IC：既存カードやモバイル端末を使え、日常利用、定期券、細かな割引、事業者間の相互利用に向く。
• 交通系ICの導入条件：カード仕様、暗号鍵、相互利用の接続条件、運賃データ交換、機器認定の確認が欠かせません。独自仕様を短期間で追加できる方式ではありません。
• 地域独自カード：地域ポイント、福祉乗車証、独自定期券、商店街連携を組み込みやすい方式。
• 地域独自カードの運用：発行・再発行、残高管理、紛失対応、他地域との乗り継ぎ、移行案内を自社で整える必要があります。

公開資料には、全国交通系ICの機器更新と別のタッチ決済方式を比べた事例があります。

判断では、導入費に加えて、利用者構成と継続運用費を見ます。

クレジットタッチ決済・QR・モバイルの併用

カード発行の有無や乗車券との連携に応じて、複数の決済・認証手段を組み合わせられます。

• クレジットタッチ：オープンループ方式の場合、訪日客や一見客はカードを新たに発行せずに利用できる。
• QR・モバイル：QR乗車券は予約・イベント・企画乗車券と連携しやすく、モバイル定期券は窓口の負担を軽くできる。
• タッチ決済の運用：決済認証、運賃確定、返金、事業者間精算の責任分界。定期券や複雑な割引を、そのまま置き換えられるとは限りません。
• 顔認証・タッチレス：2026年に既存改札への顔認証追加や既存機器を使う実証が公表されており、ICカードを残した段階的な追加も選べます。
• 生体情報の扱い：同意、本人確認、データ保管、誤認時の救済、代替手段までの設計。

リッチクライアント・センター方式・ハイブリッド

処理場所によって応答性や通信断への強さ、更新の負担が変わります。そのため、構成ごとの役割と費用を並べて比べます。

• リッチクライアント：改札・車載器側で運賃を判定し、応答を短く保ちつつ、通信断でも運行を続けられる構成。
• 端末側の運用負担：端末ごとの更新、鍵・マスター配布、機器差分の管理が重くなる点。
• センター方式・ABT：残高・アカウント・運賃計算をサーバーに集約し、機能追加や分析を一括で管理できる方式。
• ハイブリッド：端末で入出場、最低限の残高・有効性確認、通信断時のキューイングを担い、センターで複雑な運賃、履歴、精算、監視、レポートを扱う構成。

センター方式などを比べるときは、総保有コストで見ます。通信費や冗長化、監視のほか、障害復旧やデータ移行も含めます。

ICカードシステム開発の進め方を段階ごとに解説

利用者と路線、駅・車両の条件を、一つの業務フローとして整理します。

運賃、売上、保守の流れも、そこに加えます。

現場の制約とピーク性能を数値で押さえ、PoCで実機との相性や障害時の挙動を確かめてから本開発に進めると、後戻りを減らせます。

1. 現状調査と方式比較

現状調査では、設備と業務の範囲を洗い出します。方式比較では、利用者層や設備寿命も併せて見ます。

• 設備・連携：駅数、機器台数、営業所、回線、既存サーバー、会計・顧客・予約システムの把握。
• 運賃・利用：カード種別、モバイル、定期券、乗継、割引、運賃改定頻度、ピーク通過人数の整理。
• 方式の比較：全国相互利用、地域カード、タッチ決済、QRを、利用者層、設備寿命、更新費、拡張性の観点で比べる。

2. 要件定義と非機能要件の数値化

要件定義では、必要な機能と性能の条件を決めます。受け入れ条件として使うには、「高速」「止まらない」「安全」といった表現を、数値で決めた条件に置き換える必要があります。

• 機能：入出場、定期券、チャージ、払い戻し、割引、精算、返金、紛失停止、履歴、管理帳票の定義。
• 性能・復旧：応答時間、同時タッチ数、通信断の継続時間、復旧目標の数値化。
• 運用・安全：ログ保存期間、暗号鍵更新、端末更新時間帯、監視通知先の取り決め。

3. PoC・設計・開発

本開発の前には、実カード、モバイル端末、リーダーライター、回線、運賃データを使う小規模なPoCを行います。実環境でしか見えない想定外のケースを、このPoCで洗い出します。

• 通常・境界ケース：連続タッチ、カード種別の違い、残高不足、定期券区間外の確認。
• 障害ケース：電源断、通信断、復旧後の重複送信を試す試験。
• 成果物：採用方式、残課題、性能測定値、量産時の設計変更の記録。

4. 総合試験・移行・段階リリース

画面やAPIの単体確認に続けて、実機試験と移行確認まで進めます。

• 試験：実機で行う負荷、長時間運転、異常系、セキュリティ、運賃改定、日次締め、事業者間精算の各確認。
• 障害訓練：停電、回線断、センター障害を想定した対応の訓練。
• 移行・展開：旧カード、残高・定期券、履歴、ブラックリスト、運賃マスター、窓口の再発行手順の確認。

稼働は、まず限定路線や一部時間帯から始めて、問題を確かめてから全体へ広げます。

5. 保守・運賃改定・継続改善

稼働後は、保守や変更対応、更新計画を定めておくと、運用が特定の担当者に頼りきりになるのを防げます。

• 継続運用：障害監視、端末の予防交換、鍵・証明書の更新、運賃改定、定期券ルールの変更、カード・決済の追加を、稼働後も続けること。
• 保守契約：受付時間、一次切り分け、現地到着・復旧目標、予備機、ソフト修正、機器寿命、ログ提供、原因報告を契約に明記。
• 更新・引き継ぎ：開発後も5年から10年程度を見据えた更新計画と、担当者の引き継ぎの設計。

▶ 詳細はこちら：ICカードシステム開発の進め方

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

費用は、駅・車両・端末の台数や全国相互利用によって変わります。運賃制度、決済方式、既存設備の再利用、基幹連携、移行範囲も、費用に関わります。

ここに挙げる金額は、公開案件と類似案件から整理した検討用の目安で、標準価格表ではありません。

機器を購入するかリースにするか、補助金、消費税、保守期間によっても総額は変わります。そのため、初期費用だけで判断せず、総額で比べることが大切です。

規模別の初期費用と開発期間

初期費用と期間の目安は、規模や導入範囲によって異なります。そのため、条件と合わせて比べる必要があります。

• 小規模：既存決済基盤を使い、車載器数十台から数百台の規模で、5,000万円から3億円、6か月から15か月が目安。
• 中規模：複数拠点、定期券、運賃計算、営業所・会計連携を行う場合で、2億円から8億円、12か月から24か月程度。
• 複数事業者：全国交通系IC、タッチ決済、QRを併用し、端末更新と利用者移行を行う場合で、6億円から20億円超、18か月から36か月程度になることがあります。

大都市圏で改札、券売機、精算機、センター、基幹連携を全面刷新する場合は、数十億円から数百億円規模になり得ます。

福岡市地下鉄では、既存交通系IC基盤にモバイル定期券を追加する構築業務の提案上限を2億3,000万円（税込）としています（出典：福岡市地下鉄「モバイル定期券サービス事業」公表資料、2026年）。

熊本地域の公開資料は、全国交通系ICの機器更新を12億1,000万円、タッチ決済中心の新サービスを6億7,400万円として比較しています（出典：自治体の「熊本地域乗合バス事業共同経営に関する状況報告」、2024年）。

この金額は、複数事業者・設備を対象にした比較です。そのため、すべての交通事業者にそのまま当てはまる相場ではありません。

費用の主な内訳とランニングコスト

初期費用は、機器、ソフト、基盤、移行・試験などに分かれます。検討の初期は、配分の目安を仮置きとして使います。

• 機器：改札機、券売機、精算機、車載器、窓口端末、リーダーライター、組込みソフト。配分の目安は30〜50%程度。
• アプリ・基盤：運賃、定期券、精算、監視の開発やサーバー。配分の目安は20〜35%程度。
• 連携・移行・試験：既存基幹連携、データ移行、試験、教育、切り替え。配分の目安は15〜30%程度。
• その他：ネットワーク、セキュリティ、教育、予備費。配分の目安は10〜25%程度。

稼働後も、機器保守、クラウド・サーバー利用料、回線料、決済手数料がかかります。さらに、カードの発行・再発行、監視、診断、追加改修、運賃改定対応も発生します。

年間保守は、初期開発・調達費の15〜20%程度で仮置きする場合もあります。そのうえで、現地機器保守、ソフト保守、通信、決済の従量料金は、それぞれ分けて見積もります。

初期見積もりが安くても、月額や機器更新費が高ければ、5年の総額では逆転する可能性があります。

▶ 詳細はこちら：ICカードシステム開発の見積相場・費用

ICカードシステムの開発会社・サービスの選び方

候補を比べるときは、知名度や提案金額に加えて、担当できる層で見ます。駅務機器、組込み・現場ネットワーク、クラウド・データ連携、決済認証・精算基盤では、得意な領域が異なります。

一社に任せる場合でも複数社を組み合わせる場合でも、どこまでを各社が受け持つかを明確にします。

役割別の候補の比較

候補は、自社の課題に必要な責任範囲で選びます。役割の違う会社を、同じ基準で順位付けしないよう注意します。

• 駅務機器：改札・券売機・精算機・車載器を導入する場合の候補は、AFCベンダー。
• 業務統合：運賃、予約・MaaS、会計、顧客データ、分析を扱う場合、クラウドや業務システムに強い総合SIerを検討する。
• 決済：タッチ決済で認証、カードブランド、PSP、加盟店契約、返金、チャージバック、事業者間精算を扱える基盤の比較。

駅務機器の公開仕様には、改札・券売機・精算機からセンターまでをネットワーク化し、ICカード対応を一体で提供する構成があります（出典：駅務自動化システムの公開製品資料）。

AFCベンダーを選ぶ際は、既存設備との互換性、機器の供給期間、ファームウェア更新、現地の交換体制を確かめます。

実績・体制・契約条件の確認

実績、提案体制、契約・料金の条件を確かめたうえで、導入後の運用や移行のしやすさまで評価します。

• 稼働実績：「交通分野」の実績に加えて、自社と同じ規模、カード方式、運賃制度、機器構成、ピーク負荷の例。
• 担当体制：現場、障害対応、運賃精算の各担当の顔ぶれと役割分担。
• 契約条件：鍵・顧客データの所有権、ソースコード・設定値、API・データ形式、再委託の取り決め。
• 責任・移行：SLA、損害賠償、障害報告、機器更新価格、追加改修単価、契約終了時のデータ返還の内容。
• サービス料金：月額・従量課金、決済手数料、最低利用料、料金改定、停止時の代替手段の内容。

提案には、現場を見た担当者、障害対応を経験した責任者、運賃・精算を理解する業務担当者が加わっているかを確かめます。

開発中のデモに加えて、通信断、重複送信、運賃マスターの誤配信、カード紛失、停電復旧時の挙動も評価します。

条件を確かめないまま安い初期提案を選ぶと、ベンダーロックインに陥り、後から移行しにくくなることがあります。

▶ 詳細はこちら：ICカードシステム開発でおすすめの開発会社6選と選び方

ICカードシステムの発注・外注・委託での注意点

発注時には、機能一覧に加えて、機器台数、路線、駅、車両をRFPに記載します。カード種別と運賃制度、ピーク性能、通信断も、RFPに書き込みます。移行、試験、保守、SLAも、RFPに含めます。

発注者と受託者の担当範囲を明確にし、各社が同じ前提で見積もれるようにします。

RFPに必ず記載する項目

RFPと見積書は、数量や前提を共通にしておくと、相見積もりの差を説明しやすくなります。

• 設備・運賃：拠点・機器台数、既存機器の型式・残存年数、カード、定期券、割引、運賃上限。
• 決済・性能：決済方式、モバイル・QR、ピーク処理量、応答時間、通信断条件、復旧目標。
• 移行・保護：ログ、監査、データ移行、教育、現地切り替え。

カード鍵や証明書、個人情報、決済情報、生体情報を扱うなら、保管場所や暗号化、アクセス権、委託先、削除期限も明記しておきます。

見積書は、機器、ライセンス、開発の費用を分けて書きます。連携、試験、移行、教育も、別の項目にします。旅費、予備機、クラウド、回線、保守、決済手数料も、それぞれ分けて示します。

未確定の項目は一式にせず、台数・拠点・工数・単価・前提に分けて示します。そうすると、相見積もりの差を比べられます。

請負・準委任と検収条件の使い分け

契約形態は、名称よりも作業内容や変更・障害時の取り決めに合わせて選びます。

• 請負：要件と成果物が固まった機器連携や標準機能の実装に向く。
• 準委任：PoC、現場調査、方式比較、運用設計、段階的な要件整理など、作業時間と成果を管理する場合に適することがある。
• 納品・検収：納品物、期限、検収の対象となる試験結果の定義。
• 変更管理：変更受付、影響調査、見積承認、優先度、納期変更、追加単価の取り決め。
• 障害対応：機器・通信・クラウド・決済・運賃マスターの一次窓口、連絡網、エスカレーション時間、暫定復旧方法の契約への記載。

▶ 詳細はこちら：ICカードシステム開発の発注・外注・委託方法

セキュリティ・可用性・運用設計で押さえるポイント

交通向けICカードシステムには、移動を止めない可用性と、決済・個人情報・運賃データを守る安全性が求められます。

オンラインだけに頼ると、通信障害の影響が大きくなります。そのため、現場データを最小限にして、オフライン継続と復旧同期を設計します。また、時計ずれ、二重計上、ログ欠損、鍵の期限切れは、平時から監視しておく必要があります。

決済・個人情報の責任分界

タッチ決済を扱う場合は、カード番号を自社で保存・処理・通過させない非保持化やトークン化を含めて、決済事業者との責任分界を確かめます。

PCI DSS v4.0.1は、カード会員データを安全に扱うための業界基準です。経済産業省のガイドラインは、割賦販売法上の実務指針として位置付けられています（出典：PCI Security Standards Councilの文書ライブラリ、経済産業省の2025年改訂資料）。

いずれも、法令そのものと同じ意味ではありません。適用範囲と契約上の義務を、それぞれ整理します。

止めないための冗長化と障害対応

冗長化、オフライン時の制限、復旧同期、監視・訓練を組み合わせることで、運行の継続と精算の正確さを確保します。

• 冗長化：センターは複数系統、データベースは冗長構成とし、可能な範囲で回線経路を分けておく。端末には安全なオフラインモードを持たせる。
• オフライン制限：長期の許容は不正利用や精算差異を増やすため、カード別の有効期限、利用回数、残高上限、ブラックリスト更新期限を決めておく。
• 復旧同期：一意な取引IDで端末ログを突き合わせ、再送時の二重計上を防ぐ仕組み。
• 監視項目：端末死活、通信遅延、エラー率、残高同期、運賃マスター世代、ディスク容量、証明書期限、売上欠損の表示。
• 障害訓練：センター停止、回線断、停電、端末故障、誤配信、鍵更新失敗を想定し、紙の手順書だけで暫定運用できるかの確認。

自社に適した方式を判断する視点

利用者の利便性に加えて、現場の制約、収益管理、更新計画を合わせて判断します。優先順位を付けておくと、方式を選んだ理由を説明しやすくなります。

既存改札・車載器の活用

既存の機器については、残存年数、改造可能な接続部、メーカーの保守期限、設置スペース、電源・通信工事の可否を確かめます。

既存機器を活かせば、工期と初期費用を抑えられる可能性があります。一方で、古い制御方式や部品供給の終了が障害になることもあります。そのうえで、アドオンと全面更新を、機器寿命と5年総額で比べます。

利用者ごとの利便性の優先度

利用者の属性によって、必要な手段は異なります。一つの方式に置き換えるよりも、併用が必要になる場合もあります。

• 通勤・通学者：交通系ICの継続性、定期券、割引、紛失再発行を重視する層。
• 訪日客・一見客：カード発行が不要なタッチ決済やQRの検討。
• 地域サービス利用者：地域ポイントや福祉制度が重要な場合の、独自カードやアカウント連携の検討。

費用・リスク・将来拡張の比較

評価表では、費用、期間、運用負担、障害リスク、拡張性をあわせて比べます。全機能を一度に導入すると、費用と試験範囲が膨らみます。

• 費用・期間：初期費用、月額・従量費、5年の機器更新費、保守人員、決済手数料、開発期間の一覧。
• 運用リスク：通信依存性、障害時の影響、事業者追加のしやすさの評価。
• 導入範囲：全国相互利用、タッチ決済、QR、顔認証の必須機能と将来追加機能の切り分け。

第1段階で入出場・運賃・精算・監視を安定させ、モバイル、決済、QR、分析、認証は第2段階以降に分ける方法があります。

後から機能を追加できるよう、API、データモデル、認証、端末更新、精算の拡張点を初期設計で確保します。

よくある質問（FAQ）

導入前には、費用、カード方式、通信断、既存設備、決済、保守について疑問が生じやすいものです。検討時に確認したい内容に、ここで答えます。

ICカードシステムの開発費用はいくらですか？

小規模な地域交通は5,000万円から3億円、中規模は2億円から8億円、複数事業者や複数決済を含む案件は6億円から20億円超が、検討の目安となる範囲です。

金額は、機器台数、既存設備、運賃制度、移行、保守の範囲によって変わります。そのため、公開事例の金額をそのまま予算にはせず、同じ前提で相見積もりを取って比べます。

ICカードシステムはクラウド化できますか？

クラウド化はできますが、改札や車載器の判定をすべて通信先に任せる設計は避けます。端末側では、最低限の入出場判定とオフライン継続を担います。

センター側では、運賃、履歴、精算、分析、監視を処理する構成が現実的です。

通信費、冗長化、障害復旧、データ保管、端末更新まで含めて、採算を確かめます。

交通系ICカードとクレジットタッチはどちらを選ぶべきですか？

定期券、通勤・通学、細かな割引、地域間の乗り継ぎを重視するなら、交通系ICを中心に考えます。一方、訪日客や一見客の利用しやすさ、カード発行の不要さを重視するなら、クレジットタッチが候補になります。

用途が異なるため、利用者構成と運賃制度を見て併用する方法もあります。

変更するときは、返金、チャージバック、障害時の扱い、手数料、利用者への告知も比べます。

開発会社には何を確認すればよいですか？

確認するのは、自社と同規模・方式の稼働実績です。改札・車載器とセンターの対応範囲も、見ておきます。現地保守網と障害時のSLAも、確認します。

データと鍵の所有権、API・ソースコード、追加改修単価、契約終了時の移行方法も、あわせて確かめます。さらに、実装や運用の責任者が、通信断や運賃改定を説明できるかも見極めます。

まとめ：ICカードシステムは方式・現場・TCOで見る選び方

ICカードシステムは、改札、車載器、券売機、センターを結ぶ社会インフラです。運賃、決済、精算、保守も、その中に含まれます。全体を一つの仕組みとして捉えることが、選定の出発点になります。

交通系IC、地域独自カード、クレジットタッチ、QR、モバイル、顔認証には、それぞれ異なる利用者と運用条件があります。そのため、単純な優劣では比べられません。

導入前に決める事項

まず、対象拠点と機器台数、ピーク処理量を押さえます。そのうえで、運賃・定期券・割引、通信断時の継続、移行対象、保守体制を整理します。

既存設備を活かすか、全国相互利用を維持するか、タッチ決済を追加するか、独自運賃や地域サービスを続けるかを選びます。費用は初期で5,000万円から数百億円まで幅があるため、公開実績と自社の推定を分けて、5年総額で比べます。

小さな検証と段階導入

現場で検証しながら、次の順で段階的に導入します。

1. 現状調査と方式比較
2. 数値化した要件定義
3. 実機PoC
4. 負荷・障害試験
5. 限定導入
6. 全体展開

発注時には、機器・ソフト・通信・移行・保守の責任分界を契約に記しておきます。あわせて、稼働後の運賃改定、セキュリティ、端末更新、障害訓練まで、運用計画に含めます。

利用者の利便性と現場の継続性を両立する方式を選ぶことが、長く使われるシステムにつながります。

▼関連記事一覧
・ICカードシステム開発の進め方
・ICカードシステム開発でおすすめの開発会社6選と選び方
・ICカードシステム開発の見積相場・費用
・ICカードシステム開発の発注・外注・委託方法

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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