オーソリシステム開発の完全ガイド

オーソリシステムは、加盟店側のゲートウェイ、アクワイアラ側の処理、イシュア側の与信・利用枠管理に分けて捉えると、必要な範囲を判断しやすくなります。

発注前に決めたいことを、役割の分け方から費用、発注先、RFP、セキュリティまで順に見ていきます。各テーマの詳細は関連記事もご覧ください。

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

オーソリシステムの定義と役割

承認後の処理までを分けると、開発範囲を整理しやすくなります。

オーソリシステムは、カードなどのキャッシュレス決済の要求を受けたときに、カード・口座・加盟店・取引の状態を確認する基盤です。

リアルタイムに承認・拒否を返す仕組みで、信用照会・与信照会・利用承認とも呼ばれます。

承認・拒否を返すリアルタイム基盤

承認判定は、要求が経路をたどって基盤に届き、カードや利用枠などの項目を確認したうえで行われます。

応答の条件は、通常時、ピーク時、障害時で分けて考えます。

要求経路：POS・ECサイトから加盟店サーバーまたは決済代行サービスへ送られ、国内決済ネットワークや国際ブランド網を経由します。
判定：アクワイアラ側またはイシュア側の基盤で処理します。
確認項目：カードの有効性、利用停止、加盟店・端末、利用可能枠、残高、取引種別、不正利用の兆候です。

通常時の応答時間は案件ごとに設計しますが、約2秒級を意識するケースもあります（出典: NotebookLMリサーチノート、2026年）。

実際のSLAは、通常時、ピーク時、障害時に分けて定義する必要があります。

信用照会の一部分という位置づけ

オーソリは決済の流れのうち信用照会を担う一部分です。そのため、後続処理とは境界を分けて考えます。

オーソリ：信用照会を行い、承認・拒否を返します。
後続処理：承認後に売上を確定し、清算や請求を行います。
関連機能：EMV 3-Dセキュアは本人認証、不正検知はリスク評価を担います。

境界があいまいだと、API連携で足りる案件に大規模開発を計上する場合があります。反対に、必要な与信・残高・監査機能を見落とすおそれもあります。

オーソリシステムの種類と役割の分け方

判定を支える保護と継続運用も、基盤の設計範囲に含まれます。

構成は、支える業務、接続先、自社で保有する範囲によって変わります。そのため、加盟店側のゲートウェイ、アクワイアラ側の処理、イシュア側の与信・利用枠管理を分けて考えます。

アクワイアラ側とイシュア側の要件の違い

アクワイアラ側は、加盟店・端末・決済チャネルからの要求をカード会社やネットワークへ振り分け、その応答を返します。

一方で、イシュア側はカード会員の利用可能枠や残高を参照します。また、利用停止や取引履歴、不正リスクなども加えて判定します。

この違いを踏まえ、発注前に、加盟店の決済導入、決済事業者の接続基盤、カード発行会社のオーソリ刷新のうち、どれが目的かを明確にします。

電文変換と接続管理の基盤

接続と取引状態の設計では、次の機能を一体で扱います。

電文・接続：要求の受信・送信、ルーティング、ISO 8583などの変換と、国内網・国際ブランド網との仕様差異の吸収
取引状態：承認、拒否、取消、リバーサル、再送、部分承認、重複取引、タイムアウト後の遅延応答
識別・記録：取引ID、冪等性キー、相関ID、監査ログ

HTTP APIを1本つなぐだけでは、再送時に二重承認や残枠の不整合が起きる可能性があります。上の取引状態と識別・記録の仕組みは、この問題を防ぐためのものです。

判定・保護・継続運用の3層の機能

オーソリ基盤の機能は、判定、保護、継続運用の3層に分けられます。

判定：カード有効性、利用枠、残高、加盟店・端末、取引頻度、地域・デバイスのリスクルール
保護：トークン化、PANのマスキング、暗号鍵とHSM、アクセス権、脆弱性対策
継続運用：24時間365日の監視、障害通知、再処理、スタンドイン、東西2センターなどのBCP

売上確定や返金、会員残高との照合・消込まで含めるかで、開発範囲が変わります。そのため、システムの境界として明示しておきます。

PSP・パッケージ・クラウド・スクラッチの選び方

方式は、カード情報を自社環境で扱うか、独自の与信・利用枠を持つかで変わります。接続先の数、取扱量、必要な可用性も、選ぶときの条件になります。

すべてを内製せず、標準化できる部分と競争力に直結する部分を分けると、費用と期間を抑えやすくなります。

PSP・決済代行APIによる導入範囲の絞り込み

ECサイトやアプリに決済手段を追加する場合は、既存のPSPや決済代行APIが候補になります。

導入しやすい範囲：カード情報をトークン化し、承認・取消・返金・Webhookを短期間で用意
対象外の要件：独自利用枠、複雑なカード発行、独自リスク判定、複数事業の残高統合

将来の要件が今の範囲に収まるかを確かめてから、採用します。

パッケージとクラウドの標準機能の活用

パッケージ・プロセッサとクラウドでは、標準機能と拡張の方法をそれぞれ確かめます。

パッケージ：電文、ブランド接続、会員・利用枠、標準判定、監視機能を活用しやすい
設定・保守：設定可能範囲、追加開発、保守期限、仕様変更費用、データ移行方法の確認
クラウド：APIゲートウェイ、ロードバランサー、コンテナ、分散DB、メッセージング、キャッシュ、HSM、監視を組み合わせる
拡張性：ピーク時の拡張や段階的な開発が可能

2025年公開の決済処理参照構成では、暗号化、トークン化、リスク確認を扱います。さらに、ISO形式の電文も扱います。また、アクワイアラ側とイシュア側を分け、毎秒数千件へ拡張できる構成例もあります（出典: 公開された決済処理プラットフォームの参照構成、2025年）。

この例は特定案件の性能を保証するものではないため、実際のピークTPSと応答時間は自社データで試験します。

独自性の高い領域に絞ったスクラッチ開発

独自要件と標準機能の境界を見極めたうえで、開発範囲と移行方法を選びます。

独自開発の候補：独自カード商品、与信モデル、利用枠、不正判定、複数事業の残高管理が競争力になる場合
内製の負担：電文ゲートウェイ、トークン化、暗号鍵管理、標準接続まで担うと監査・運用負担が増加
段階移行：既存メインフレームのAPI化、リスク判定の分離、低リスクチャネルからの並行稼働を比較

ポイント

導入方式は、独自性が高く競争力に直結する部分だけを自社で開発し、残りは標準機能や既存の仕組みに任せて選ぶのが基本です。カード情報の扱いや接続先の数も、方式の条件になります。

オーソリシステム開発の進め方

前工程で定めた数値や責任範囲を、後工程の確認へつなぎます。

要件は、処理範囲と接続先を出発点に、性能、判定ルール、安全などの順に固めていきます。BCPや運用も同じ流れで決めます。例外対応を追加すると設計変更が大きくなるため、正常系と異常系を同時に定義しておきます。

要件定義での対象範囲と数値の決定

要件定義では、対象範囲と接続先を図にして、必要な数値を決めます。

対象範囲：イシュア側、アクワイアラ側、加盟店向けゲートウェイのどこを作るか
性能・稼働：月間件数、ピークTPS、平均・最大応答時間、同時接続数、目標承認率、稼働率
継続・監査：RTO、RPO、監査ログの保存期間
接続・責任：国内決済ネットワーク、国際ブランド網、PSP、本人認証、不正検知、会員・与信・請求基幹と、各データ項目の担当範囲

関係者の間で、数値と責任の前提を共有しておきます。

設計・開発での状態遷移と責任分界の確定

基本設計では、状態遷移と情報の管理、担当範囲を明確にします。

取引状態：承認、拒否、保留、取消、リバーサル、再送、タイムアウト、遅延応答、障害時代行
二重処理対策：再送後に相手側は承認済み、自社側は未完了となる場合があるため、取引IDと冪等性を使う
役割分担：カード情報・トークン・鍵の扱いを分け、監視・復旧・監査対応の担当をRACIや責任分界表に記す

状態の定義と担当の分け方は、開発と運用の関係者で共有しておきます。

テスト・移行での障害と切り戻しの実演

テストでは異常系と性能を確かめ、移行の手順は本番前に実演しておきます。

障害・例外試験：ピーク負荷、ネットワーク分断、接続先停止、HSM障害、重複送信、遅延応答、リバーサル、利用枠の戻し、誤検知、ログ欠落
性能試験：平均値だけでなくp95・p99応答時間、ピークTPS、エラー率、キュー滞留を測定
移行・訓練：低リスクチャネルから並行稼働し、シャドートラフィック、カナリアリリース、日次照合、ロールバック、切替・障害訓練を実施

試験結果を確かめたうえで、本番への切替と切り戻しができる状態にします。

▶ 詳細はこちら：オーソリシステム開発の進め方

オーソリシステムの費用相場とコストの内訳

オーソリシステムには、公開された一律の定価がありません。そこで以下の金額は、2026年時点の企画初期推定です。取扱量や接続先、既存基幹に加えて、二重化や監査範囲、24時間運用の有無を踏まえています。

この金額は、オーソリ本体の公的な相場ではなく、決済API連携やゲートウェイ、カード基幹刷新など近接する領域の公開情報を基にした目安です。

対象範囲別の初期費用と期間の目安

対象範囲が広がるほど、初期費用と期間は大きくなります。企画初期の目安では、PSP・API接続の数百万円から、カード基幹刷新の数億円以上まで、範囲によって幅があります。

PSP・API接続：1つの決済手段で承認・取消・返金・Webhookまでを実装する範囲なら、300万円〜1,000万円、期間は2〜4か月程度
国内網ゲートウェイ：国内決済ネットワークとの接続、電文変換、接続試験、障害時再送まで含めると、1,000万円〜3,000万円、4〜8か月程度
パッケージ・クラウド：会員・利用枠、不正判定、複数ブランド、既存基幹との連携を設定・追加開発する場合は、2,000万円〜8,000万円、6〜12か月程度
自社オーソリ基盤：複数ブランド、トークン、監視、BCPまで含める場合は5,000万円〜3億円、12〜24か月以上となる可能性
カード基幹刷新：レガシー移行、複数センター、API公開、請求・清算まで含めると、数億円〜数十億円以上となり、要件によっては100億円規模の計画もあり得る

経済産業省の検討資料も参考になります。2026年のカード分野API連携の検討では、API未対応の事業者の初期投資や、すでに対応している事業者が接続先を追加する場合の費用分類が検討されています（出典: 経済産業省「クレジットカード分野に係るAPI連携の推進に係る検討会」、2026年）。

ただし、これはオーソリ全体の価格表ではありません。既存基盤の活用、接続先の追加、新しい共通基盤の構築のどれかで、投資規模は変わります。詳細は経済産業省のAPI連携検討資料で確かめられます。

ランニング費用と初期費用の分け方

運用費と継続的な改修費は分けて、変動する条件とともに見積もります。

インフラ費：クラウド、ネットワーク、データベース、メッセージング、HSMにかかる費用
運用費：監視・障害対応、脆弱性診断やペネトレーションテスト、PCI DSS対応、接続料、証明書、鍵管理、不正検知の費用
月額・年間試算：インフラは月額数十万円〜数百万円以上、24時間365日の監視・運用は年間500万円〜5,000万円程度
保守・改修：ブランド仕様変更、本人認証仕様、APIバージョン、OSやミドルウェア更新、障害訓練、監査支援、データ移行など
中期試算：初期費用の10〜20％を年間改修枠と仮置きし、3〜5年TCOでは契約・見積の実額に置換

これらは公開された標準値ではなく、性能・拠点数・運用体制によって変わる試算です。そのため、契約や見積の実額を入れて、TCOを更新していきます。

見積書の5項目への分解と比較

見積書には、次の費目を分けて書いてもらいます。

要件定義・基本設計：要件定義と基本設計
機能・接続：電文と接続、判定ロジック
周辺基幹連携：周辺基幹との連携
試験・監査：テスト環境と性能試験、セキュリティと監査
移行・運用：移行、監視、運用訓練

特に「オーソリ機能一式」とだけ書かれている場合は、HSM、3-Dセキュア、不正検知が別費用になりやすい項目です。障害時の代行、切り戻し、ブランド仕様変更も、別費用として扱われやすい点です。したがって、どこまでが含まれるかを、見積の段階で確かめておきます。

費用を抑えるには、独自開発を減らすことに加えて、対象の範囲を明確にします。手段としては、カード情報の非保持化、接続先の優先順位付け、標準機能の採用が挙げられます。段階移行で範囲を区切る方法もあります。

評価は、最安値ではなく投資対効果で行います。承認率や停止時間、障害時の損失も含めて考えます。さらに、将来の仕様変更費用も見ておきます。

▶ 詳細はこちら：オーソリシステム開発の見積相場・費用

ポイント

費用は対象範囲と接続先、二重化や24時間運用の有無で大きく変わります。金額だけでなく、テスト・運用・保守まで含むかを揃えて比べます。

開発会社・サービスの選び方

開発会社は、知名度や提案書の見栄えだけでなく、担える役割と実績で比べます。判定基盤や国内網・国際ブランド接続を担えるかで、比較する相手は変わります。さらに、不正検知や可用性基盤まで担えるかも確かめます。

接続実績の対象範囲と数値の確認

「決済実績があります」という説明だけでは、経験の範囲を判断できません。そのため、まず、CAFISやCARDNETなどの国内網、国際ブランド網、PSPの経験を確かめます。

次に、3-Dセキュアと不正検知の経験を確かめます。HSM、トークン、既存メインフレームの経験も見ておきます。

可能な範囲で、実案件のピークTPSと平均・最大応答時間を提示してもらいます。加えて、障害時の切替時間、年間停止時間、承認率への影響も、数値や試験結果で示してもらいます。

セキュリティと運用体制の契約前の確認

契約の前に、保管や鍵の扱い、日々の運用、担当分担、認証の最新要件を確かめておきます。

情報管理：PCI DSS対象、カード情報の保存場所、トークンの発行・返却、暗号鍵とHSMの責任
運用対応：脆弱性対応、ログ監査、アクセス権、インシデント時の連絡時間
責任の分け方：認証取得の有無だけでなく、自社と委託先の要件分担

2024年に公表されたPCI DSS v4.0.1は、要件の誤記修正や明確化を含む改訂です。なお、最新の版はPCI Security Standards Councilの公式文書一覧で確かめられます。

移行と保守を含めた選び方

提案の段階で、移行と保守の実施条件を確かめておきます。契約が終わるときのトークンやログの返却形式も、あわせて確かめます。

本番移行：データ移行、並行稼働、照合、切り戻し、利用者・加盟店への影響、障害時の連絡体制
準備・保守：切替リハーサル、テストデータ、日次照合、障害訓練、監視引き継ぎ、ブランド仕様変更への対応
契約終了：トークンやログの返却形式を定め、ロックインを避ける

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

ポイント

開発会社は、担える役割と実績に加え、契約前に確かめる安全と運用の体制、移行や保守への対応まで含めて比べるのが基本です。先に任せたい範囲を決めておくと、比較の基準がそろいます。

発注・外注で失敗しないRFPのポイント

RFPでは、機能に加えて、取引量や性能、障害時の状態を具体的に書きます。あわせて、セキュリティ責任、移行条件、運用時間も具体化しておきます。要件があいまいだと、想定範囲がずれて、納品物や運用負担を比べられなくなります。

RFPの対象・性能・接続先の記載

RFPは、項目を一つの文書にまとめて書きます。

対象業務：イシュア、アクワイアラ、加盟店ゲートウェイと、承認・拒否・取消・売上確定・返金・照合の範囲
性能・継続性：月間件数、ピークTPS、p95・p99応答時間、同時接続数、承認率、稼働率、RTO・RPO、2センター、障害時代行の条件
接続・環境：接続先、電文形式、本人認証、不正検知、会員・与信・請求基幹、テスト環境

各社の提案は、この項目を共通の土台にして比べます。

契約方式と追加費用の条件

契約方式ごとに、責任と追加費用の条件を分けて比べます。

契約方式：準委任、請負、ライセンス、マネージドサービスで成果物・責任・変更管理・障害対応が異なる
追加費用：請負でも接続先仕様、性能要件、カード情報の保持範囲、法令・ブランド仕様の変更で発生する場合がある
契約条件：納品判定、受入試験、瑕疵対応、SLA、再委託、秘密保持、監査協力、終了時のデータ・トークン返却

提案比較での異常系の試験計画

提案では、異常系をどう扱うかと、運用へ何を引き継げるかを確かめます。

異常系：タイムアウト後の再送、二重送信、リバーサル、カード会社停止、ネットワーク分断、誤判定、データ不整合
設計・試験資料：サンプル電文、状態遷移図、障害時シーケンス、性能試験条件、切替・切り戻し手順
運用成果物：監視項目、アラート基準、エスカレーション、鍵更新、脆弱性対応、監査証跡

▶ 詳細はこちら：オーソリシステム開発の発注・外注・委託方法

ポイント

RFPには取引量や性能、障害時の状態を具体的に書き、契約方式ごとの責任と追加費用も同じ前提で比べます。条件があいまいだと、見積の前提がずれてしまいます。

セキュリティと可用性の設計

オーソリでは、カード情報の安全性と決済の可用性を両立させる必要があります。特に、安全対策が遅れると、情報の流れやログを変えにくくなり、PCI DSS対象範囲や監査費用が膨らみます。

カード情報の保持範囲と責任の分担

カード情報を保持するかどうかで必要な対策は変わるため、情報の流れと責任の範囲を決めておきます。

保持する場合：暗号化、鍵管理、HSM、マスキング、アクセス制御、脆弱性管理、監査ログ、バックアップ、委託先管理が対象
保持しない場合：決済ページ、API、管理画面、ログ、ブラウザ・端末の脆弱性対策は必要
全体の確認：ガイドラインはカード会社、加盟店、PSPなどに漏えい・不正利用防止の指針を示し、EMV 3-Dセキュアや不正ログイン対策も含む

経済産業省は2025年3月に「クレジットカード・セキュリティガイドライン」を改訂しました（出典: 経済産業省「クレジットカード・セキュリティガイドライン」、2025年）。詳しくは、経済産業省のセキュリティガイドライン改訂案内で確かめられます。

二重化と障害時の業務継続の設計

障害時の継続方法と取引の整合性は、あわせて設計します。

冗長化：東西2センター・複数AZ、経路分離、DB複製、監視、フェイルオーバー、バックアップ、切替訓練
整合性：二重化だけでは防げない二重送信・重複承認への対策
スタンドイン：承認上限、対象取引、リスクルール、後続照合、復旧後のリバーサルを定義

運用指標と監査証跡

稼働状況を継続的に監視し、取引を追跡できる記録と対応基準を整えます。

稼働指標：承認率、拒否率、タイムアウト率、p95・p99応答時間、ピークTPS、キュー滞留、再送・リバーサル件数、復旧時間、照合差異
監査記録：取引ID、相関ID、ルール判定、外部応答、再処理履歴を残し、カード情報はマスキング
対応基準：通知先、一次・二次対応、経営報告の基準を運用設計書に記載

指標の変化を監査記録と照らし合わせられるよう、運用の責任者を決めておきます。

ポイント

保持するカード情報の範囲で、必要な対策と監査の負担が変わります。安全対策は設計の段階で決め、担当の範囲も先に定めておくと判断しやすくなります。

オーソリシステムに関するよくある質問

企画や発注の時期によくある疑問を取り上げます。決済APIの追加か基盤刷新かを整理すると、必要な機能と費用が見えてきます。

オーソリシステムと決済システムは同じものですか？

オーソリは、決済の要求に承認・拒否を返す信用照会の基盤です。売上確定から返金までの後続処理や、本人認証、不正検知とは、主体や目的が異なります。そのため、発注時には範囲を明記します。

オーソリシステムの開発費は最低いくらですか？

費用は、接続範囲と追加要件によって変わります。

基本接続：既存APIへの接続だけなら、標準的な承認・取消・返金に絞って300万〜1,000万円程度
費用増の要件：独自利用枠、複数ブランド、国内網接続、2センター、24時間運用、PCI DSS対応

金額だけでなく、接続やテストのほか、運用、保守、仕様変更がどこまで含まれるかも確かめます。

クラウドで構築すればPCI DSSに準拠できますか？

準拠の判断では、クラウドの認証範囲と自社の管理範囲を合わせて評価します。

クラウド・自社の範囲：認証範囲、自社管理のアプリ、設定、アクセス権、カード情報の流れ、ログ、脆弱性対策、委託先管理を評価
トークン化：対象範囲を小さくできるが、決済画面やAPIの安全対策は引き続き必要

ピークTPSや応答時間はどのように決めますか？

ピークTPSは、過去12か月の件数や時間帯別の実績に、繁忙期の増加率と将来計画を加えて設定します。応答時間は平均に加えて、p95・p99まで確かめます。タイムアウト率や同時接続数、外部接続先の制約も、あわせて見ておきます。

試験環境では、通常時、ピーク時、障害時を再現し、性能目標をSLAと受入条件に結び付けます。

開発を始める前に何を準備すればよいですか？

相談の前に、業務・性能、情報管理、例外時の流れを、わかっている範囲で整理しておきます。

業務・性能：決済上の立場、対象チャネル、接続先、月間件数、ピークTPS、必要応答時間
環境・継続性：カード情報の保持範囲、既存基幹、稼働時間、障害時の目標
業務フロー：承認・拒否、取消、リバーサル、再送、返金、照合、切り戻し

この資料があれば、同じ条件で開発会社やサービスに相談でき、見積の比較と方式の選定が進みます。

まとめ

オーソリは、カード決済の要求に承認・拒否を返すリアルタイム基盤です。決済API接続や加盟店ゲートウェイと、アクワイアラ処理やイシュアの与信・利用枠管理とでは、必要な機能が異なります。そのため、対象範囲を分けて考えます。

成功の要点は範囲・数値・異常系の3点

成功の要点は、対象範囲、数値、異常系の3点です。方式は、自由度だけでなく、PCI DSS対象範囲や接続実績で比べます。加えて、性能と可用性、移行の難しさ、3〜5年のTCOも見ます。

費用幅：API接続は300万円〜1,000万円程度、カード基幹刷新は数億円以上
見積比較：要件定義・基本設計、機能・接続、周辺基幹連携、試験・監査、移行・運用の5項目に分けて評価する

最初の相談に向けた要件整理表

最初の相談に向けて、要件整理表には次の内容を記載します。

業務・性能：対象業務、接続先、取扱件数、ピークTPS、応答SLA、カード情報の扱い
運用・移行：RTO・RPO、障害時の代行、移行・切り戻し、保守時間
例外・終了時：タイムアウト、二重送信、リバーサル、ネットワーク分断、監査ログ、契約終了時のデータ返却

同じ条件で相談できれば、見積を並べて比べる作業が進みます。

▼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を創業。