信用情報管理システム開発の完全ガイド

信用情報管理システムは、扱う情報を個人信用情報、法人の与信・債権、金融機関の信用リスクに分けて考えると、必要な業務基盤を選びやすくなります。

対象業務が違えば、機能も接続先も、開発方式や費用の見方も変わります。まず分類を決めることが、発注の進め方を左右します。

▼関連記事一覧

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

信用情報管理システムの概要

信用情報管理システムは、信用供与の判断に必要な情報を、正確かつ追跡できる状態で扱います。融資、カード、リース、割賦、保証、掛取引などでは、取引前の審査から、取引後の返済・支払状況の確認までを支えます。

業務の種類によって必要なシステムの範囲は大きく異なるため、本人確認、外部機関との連携、審査記録、権限管理、監査証跡まで含めて範囲を決めます。

信用情報を一元管理する業務基盤

管理対象には、氏名・生年月日などの本人特定情報、契約内容、保証人・担保、限度額が含まれます。返済・支払状況や延滞、完済などの取引事実も対象です。

個人向け：本人情報と契約・返済状況を扱います。
法人向け：会社・決算情報、取引実績、支払条件、債権残高、内部格付などを扱います。
履歴管理：取得者、取得目的、利用した判断を記録します。

業務基盤では、情報を画面に表示するだけでなく、いつ、誰が、何の目的で取得し、どの判断に使ったかを追えるようにしておく必要があります。

信用情報管理という言葉が持つ3つの意味

検索時に混乱しやすいのは、個人信用情報の照会管理、法人の与信・債権管理、金融機関の信用リスク管理が、同じ言葉で検索されるためです。

個人向けローンの審査と売掛先の限度額管理では、必要なデータも接続先も異なります。そのため、まず対象業務を決めることが、過剰な見積もりや要件不足を防ぎます。

個人信用情報：個人向けローンなどの照会と審査に使う情報です。
法人与信・債権：売掛先の限度額と債権を管理します。
信用リスク：金融機関の格付やポートフォリオを分析します。

導入を検討しやすい企業・部門

金融機関や、貸金・カード・信販・保証・リースの事業者が対象になりやすいです。法人取引の売掛与信を管理する企業も対象です。

審査根拠をExcelや担当者のメモで管理する企業は、導入の効果が出やすい状態です。

二重入力：同じ情報を複数のシステムに入力している。
転記ミス：照会結果を手作業で転記している。
履歴不足：監査時に判断の経緯を示せない。

信用情報管理システムの種類

対象業務を決めると、必要なデータや接続先を絞り込みやすくなります。

信用情報管理システムは、扱う信用情報と判断業務によって、大きく3種類に分かれます。似た名称のサービスでも、外部機関との接続、社内の債権管理、金融機関のリスク分析で強みが異なります。

分類を誤らないことが、選定の出発点になります。

個人信用情報の照会・登録を管理するシステム

申込の受付から、本人確認、照会依頼、結果の取り込み、審査担当者への連携、登録・更新、履歴の保存までを扱います。

接続先の条件：CIC、JICC、全国銀行個人信用情報センターで利用資格や契約が異なります。
接続の確認：接続方式、登録・照会ルール、自社と接続先のどちらが接続試験を担当するか確認します。

「APIにつなげられる」という説明があっても、自社が加盟条件を満たすかは、別に確かめる必要があります。

JICCは2026年5月末時点で加盟会員1,233社、登録情報5億2,020万件、登録残高327兆6,463億円を公表しています（出典：日本信用情報機構「信用情報に関する統計」、2026年）。

また、CICは2026年3月時点で保有情報約8億4,580万件、加盟会員809社、2025年度の照会件数約2億9,068万件を公表しています（出典：CIC「数字で見るCIC」、2026年）。個人信用情報は、小規模な顧客台帳とは異なるデータ基盤です。

法人の与信・債権を管理するシステム

法人向けの与信管理型では、取引先マスタ、与信限度額、決算書や外部評価、契約条件を扱います。さらに、売掛残高、入金消込、延滞、回収状況も管理対象です。

審査と承認：営業部門が登録した取引先情報を審査部門が確認する流れが一般的です。
取引への反映：承認した限度額を、受注や出荷の判断に反映します。

ただし、個人信用情報機関への照会が不要な場合もあります。法人情報の正確性、権限、更新日、承認履歴は管理します。

金融機関の信用リスクを分析するシステム

このシステムは、内部格付や自己査定、債務者区分、格付遷移、PD推計を分析します。与信限度額、ポートフォリオ、リスクアセットや採算も分析対象です。

案件単位：個別案件の審査に必要な情報を扱います。
全体分析：エクスポージャーや集中リスクを把握するデータ基盤が必要です。

個人信用情報の照会システムとは、必要なデータモデルも計算ロジックも大きく異なります。

ポイント

3種類は、扱う情報と判断業務で分けて考えます。対象業務を先に決めておくと、接続先と必要なデータを絞り込みやすく、見積もりの前提もそろえやすくなります。

信用情報管理システムの主要機能

登録から監査までを支える役割が、機能ごとに見渡せます。

機能は、画面の多さより、情報の取得から判断、更新、監査までの流れに沿って考えます。AIスコアや高度な分析より先に、データの正本、権限、例外処理を固めておく必要があります。

業務が止まった場合の手動運用も、先に決めておく方が失敗の少ない進め方になります。

顧客・取引先マスタと名寄せ

同一人物や法人の重複登録を防ぐため、マスタでは、氏名、住所、電話番号、法人番号、本人確認情報、契約番号を管理します。

表記の変化：旧姓、住所・法人名・代表者の変更を扱います。
名寄せ：候補表示と担当者確認を組み合わせます。
履歴：統合と分離の経緯を記録します。

名寄せルールがないと、同じ顧客の残高や延滞情報が分かれてしまいます。こうした事態を避けるには、完全自動にせず、担当者の確認を残す設計が現実的です。

照会・登録・更新とエラー処理

照会依頼ごとに、受付番号、結果、目的、担当者、処理日時を紐づけて保存します。

結果取込：タイムアウト、通信断、項目不一致、重複依頼、再送、部分成功を扱います。
登録・更新：延滞、異動、完済の状態遷移と登録期限を管理します。
未処理検知：登録漏れを一覧で確認できるようにします。

処理の結果は、成功か失敗かだけでなく、次に誰が何をすべきかまで画面に示します。

審査ワークフローと例外承認の記録

受付から一次確認、審査、承認、差戻し、再審査、否決、契約後の見直しまで、業務の状態を定義します。

承認者：申請額やリスク区分に応じて設定します。
例外承認：理由、根拠資料、承認者、期限を必須にします。
スコア利用：担当者の判断や異議申立ての結果も追跡します。

スコアだけで審査を完結させないためには、入力データとモデルのバージョンも記録しておく必要があります。

外部連携と監査証跡の管理

連携先には、信用情報機関や勘定系・融資管理があります。CRMや会計、eKYCとつながる場合もあります。反社・AMLチェックやDWHも、連携先に含まれることがあります。

データ連携：正本となるシステム、更新の優先順位、障害時の再送を定めます。
分析利用：データを匿名化する方法を決めます。
証跡：操作、照会、データ変更、権限変更の履歴を検索できるようにします。

履歴をまとめて検索できると、監査や本人からの開示・訂正依頼に対応しやすくなります。

信用情報管理システム開発の進め方

企画時の確認が、要件定義から運用まで引き継がれる構成です。

画面を作り始める前の業務・法務・接続条件の整理が、成否を分けます。この順序で進めると、外部接続や監査要件が後から判明するリスクを抑えられます。

▶ 詳細はこちら：信用情報管理システム開発の進め方/やり方/流れや方法/手法/工程/手順

企画フェーズの対象業務と成功指標

個人信用情報の照会・登録、法人の取引先与信、信用リスク分析のうち、どの業務を対象にするかを決めます。

改善指標：照会から判断までの時間、転記件数、審査滞留、誤登録、監査資料の作成時間を数値化します。
優先順位：法令・契約・業務継続に必要なMUSTと、将来のAI分析・経営ダッシュボードなどのWANTに分けます。

要件定義でのデータ・権限・連携条件

要件定義では、データ項目や名寄せキー、保存期間、利用目的、訂正フロー、承認権限、ログの保持範囲を決めます。

接続条件：CICやJICCなどの利用資格、契約、通信方式、受付時間、エラーコード、テスト環境を確認します。
例外対応：通信断、情報不一致、照会不能、重複申請、差戻し、外部停止時の手動対応を設計します。

開発・テスト・リリースの段階的な進め方

まず、顧客・取引先マスタと権限を整え、そのうえで照会・登録、審査、帳票、分析へと開発範囲を広げます。この順序なら、業務の骨格を確認しやすくなります。

テスト：件数照合、権限外アクセスの拒否、ログ改ざん防止、ピーク時の照会、障害復旧とバックアップ復元、接続再送を検証します。
リリース準備：旧システムとの並行稼働、現場研修、問い合わせ窓口、手動運用手順を整えます。

移行後の運用とデータ品質の改善

稼働後は、登録漏れや名寄せ候補、照会エラーを定期的に確認します。承認の滞留や権限変更、訂正依頼も対象です。

月次：データ品質をレビューします。
四半期：権限、ログ、復旧手順を点検します。

移行時の件数が一致しても、顧客IDの重複や古いステータスが残ると、審査結果に影響します。

ポイント

進め方は、対象業務の決定から要件定義、開発、移行後の運用まで一続きで考えます。前の段階で決めた接続条件や監査要件が、後の工程の確認事項になります。

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

技術方式は、初期費用だけでなく、業務への適合度、接続の自由度、運用体制、将来の変更しやすさを合わせて比べます。また、標準化できる範囲は既存サービスで短期間に立ち上げ、独自性の高い部分だけ追加開発する組み合わせも考えられます。

標準業務を短期間で整えるパッケージ

顧客・契約・限度額・審査・帳票などの標準機能を使い、設定変更や追加連携で自社業務に合わせます。

利点：実績のある業務フローや権限設計を利用できます。
確認点：独自審査ルールとの適合、追加開発の境界、更新時の影響を確認します。
契約：データ持ち出しの条件を確認します。

独自ルールを無理に合わせようとすると、現場が別管理へ戻ることがあります。

可用性と運用効率を高めやすいクラウド

冗長化、監視、バックアップ、災害対策、環境追加を設計しやすいため、運用人材が限られる企業にも適しています。

統制：データ保存場所、委託先管理、暗号化、接続元制限を確認します。
運用：ログ保管、障害時の責任分界を定めます。

金融機関向けクラウドサービスの2025年6月公表資料では、標準最小構成が月額50万円からでした。初期構築費とクラウド利用料は別途でした（出典：金融機関向けクラウドサービス提供事業者の2025年6月公表資料）。

一般的な業務SaaSより高い運用要件を見込む必要があります。

独自業務と深い連携に向くスクラッチ

独自の審査ロジック、複雑な基幹連携、特殊な権限・帳票、業界固有の共同利用に合わせやすい方式です。

費用と期間：要件が広がるほど増えます。
引き継ぎ：担当者の異動後に仕様が分からなくなるリスクがあります。
成果物：ソースコード、設計書、テスト仕様、データモデル、運用手順を明記します。

障害時の連絡体制も、成果物と契約で確認しておきます。そうしておけば、将来ベンダーを変える場面にも備えられます。

ポイント

パッケージ、クラウド、スクラッチは、初期費用だけでなく業務への適合度や運用体制で比べます。独自ルールがどこまで必要かが、方式を選ぶ判断材料になります。

信用情報管理システムの費用相場と内訳

費用は、接続先や照会件数、データ移行量、審査ロジックで大きく変わります。既存基幹、可用性、監査要件によっても差が出るため、相場は幅で捉える必要があります。

次の金額は、一般的な人月単価と基幹刷新の工程比率に、連携・セキュリティ・テストを加えた企画段階の推定です。正式な見積もりでは、各社の前提条件をそろえて比べてください。

▶ 詳細はこちら：信用情報管理システム開発の見積相場や費用/コスト/値段について

初期費用の幅（300万円〜2億円超）

費用と期間は、導入規模や含める工程によって、次のように変わります。

小規模：既存パッケージ連携中心で300万〜1,000万円程度、2〜4か月が目安です。
中規模：照会連携、審査フロー、名寄せ、基幹・CRM連携、監査帳票を個別開発し、1,000万〜3,000万円程度、4〜9か月が目安です。
複数業務・金融機関の基幹連携：冗長化・移行・並行稼働を含め3,000万〜8,000万円程度です。
大規模統合：24時間運用や災害対策を含めると8,000万円〜2億円超の場合があります。

上の金額は、いずれも企画段階の推定レンジです。

要件定義・連携・移行・テストごとの費用

見積もりは工程ごとに分けてもらいます。前半は要件定義や設計、開発で、後半は連携、移行、テスト、教育、リリース支援です。

接続とデータ：外部接続試験や名寄せが追加費用になりやすい項目です。
安全性：権限設計、監査ログ、脆弱性診断が費用に影響します。
品質確認：性能試験や障害訓練も見積もりに含めます。

エンジニア月額を80万〜120万円と見込むと、5人が6か月稼働した場合、人件費だけで2,400万〜3,600万円です。そのため、費用は機能数よりも、必要な工数と体制で見ることになります。

月額利用料と保守費用を含めた比較

クラウド型では、初期設定、移行、連携開発に加えて、月額利用料が発生します。そのほか、外部機関利用料、専用線、監視、バックアップ、本人確認、ログ保管も発生します。

スクラッチ保守：初期開発費の年5〜15％程度を仮置きします。
保守範囲：OS・ミドルウェア更新、脆弱性・障害・制度変更への対応を確認します。

料金が上がる条件には、照会件数の増加、利用者の追加、データ容量、休日対応、追加帳票があります。

ポイント

初期費用は規模と含める工程で大きく変わるため、金額は幅で捉えます。比べるときは、月額利用料や保守費用まで含めた総額を、前提をそろえて見ます。

セキュリティ・法規制・2026年の最新動向

情報の漏えいや誤登録は、本人や取引先に大きな影響を与えます。そのため、保護要件を機能要件と同じように定義します。

個人情報保護法や信用・金融分野のガイドライン、業界団体のルール、契約上の利用目的を照らし合わせます。そのうえで、法務、コンプライアンス、現場、ITが共同で判断します。

利用目的・保存期間・訂正手続きの明確化

信用分野の個人情報保護ガイドラインでは、与信事業者が目的に応じて保存期間を定め、期間後に消去することなどが示されています。

同ガイドラインでは、規程や手順書、責任者、アクセス制御についても示されています（出典：個人情報保護委員会「信用分野における個人情報保護に関するガイドライン」、2026年確認）。

保存管理：取得目的、同意・通知の状態、保存期限、消去結果を記録します。
本人対応：開示・訂正・削除の受付と対応履歴を持たせます。
分析利用：複製した情報が目的外利用にならないか確認します。

権限・暗号化・ログ・業務継続の設計

営業、審査、登録、監査、システム管理など職務ごとに権限を分け、必要最小限の閲覧・更新範囲にします。

アクセス保護：通信・保存時の暗号化、多要素認証、端末制御を確認します。
運用監視：特権ID、改ざん防止ログ、暗号化バックアップを扱います。
委託先リスク：障害や侵害を想定した管理を行います。

金融機関では、2025年公表の金融分野サイバーセキュリティガイドラインや、2026年公表の第三者リスク管理調査も踏まえます。

クラウドや委託先を含むサプライチェーン全体で、障害や侵害を想定しておく必要があります（出典：金融庁、2025〜2026年）。

AI審査における説明可能性と人の統制

AIのスコアリングや審査書類の要約は担当者を支援します。ただし、最終判断は人が行う前提で設計します。

判定記録：モデルの版、特徴量、判定結果を保存します。
人の確認：担当者の上書き理由や本人の異議申立てに対応します。
導入準備：データ品質と現行の審査ルールを整えます。

学習データの偏りや誤判定、モデル更新、入力データの欠損、判断理由の説明にも備えておきます。

導入で起きやすい失敗例と対策

機能が足りないことだけでなく、対象業務、データ責任者、例外運用、導入後の改善が決まっていないことも、失敗につながります。代表的な3つの失敗を、事前に確認しておきます。

Excelを画面に置き換えるだけの失敗

既存のExcel台帳をそのまま画面にしても、二重入力や属人化は残ったままです。

正本：どの情報を正とするか定めます。
担当と期限：更新者と更新期限を決めます。
連携先：承認後に情報を渡すシステムを決めます。

業務フローは、画面数を増やすより、入力を一度にし、必要な部門へ確実に流す形で設計します。

外部連携の条件が後から判明する失敗

外部の信用情報機関との連携を一般のAPIと同じように考えると、加盟資格や契約、専用回線、接続試験、利用時間の制約で計画が止まります。

事前確認：提案依頼前に利用資格、接続先、照会目的、想定件数、登録機能を確認します。
接続先への照会：技術条件を問い合わせます。
代替手順：接続できない場合の業務手順も要件に含めます。

導入後のデータ品質と運用責任の曖昧さ

訂正や重複統合、期限切れデータの消去、権限変更、照会エラーの再処理の担当が曖昧だと、システムはすぐに信頼を失います。

責任者：業務データ、IT運用、個人情報保護の担当を置きます。
月次確認：件数、エラー、滞留、権限をレビューします。
品質測定：機能追加の前に既存データを測ります。

信用情報管理システムの開発会社/ベンダーの選び方

知名度や価格よりも、自社と同じ種類の信用情報業務の経験で比べることが大切です。個人信用情報の照会に強い会社と、法人与信・債権管理や金融機関の信用リスク分析に強い会社は、必ずしも同じではありません。

候補は2〜3社に絞り、同じ要件書で提案と見積もりを受けると、価格差の理由を見極めやすくなります。

自社と同じ業務領域の実績

「金融系の導入経験」の有無より、個人信用情報の照会・登録、法人与信、信用リスク分析のどの実績があるかを確かめます。

効果指標：処理時間、転記削減、審査滞留、監査資料作成の改善を見ます。
再現条件：照会件数、利用者数、既存基幹、運用時間、移行方法を質問します。

公開されている導入事例では、照会処理が1件あたり約7分から約3分になった例もあります（出典：信用情報照会システムの公開導入事例、2026年確認）。

要件整理とPoCの進め方

良い提案は、要望を機能の一覧で終わらせず、業務とデータフロー、権限、連携を計画にまとめています。移行、テスト、運用も同じ計画に含まれているかを見ます。

PoC範囲：照会結果取込、重複判定、例外承認、ログ検索まで確認します。
難しい連携：代表的なデータで短期のPoCを行います。
本開発に進まない場合：成果物と費用を事前合意します。

移行・保守・契約条件の比較

データ件数の照合や旧システムとの並行稼働を確認します。障害時の手動運用、24時間対応、復旧目標、制度変更への対応も確かめます。

権利とデータ：ソースコード・設計書の帰属、データ返却・消去を明記します。
委託管理：再委託先、脆弱性対応、追加費用の条件を確認します。
終了時：サービス終了時の移行支援を定めます。

初期価格に加えて、5年程度の保守・移行・変更費用を含めた総保有コストで比べます。

▶ 詳細はこちら：信用情報管理システム開発でおすすめの開発会社/ベンダー6選と選び方

▶ 詳細はこちら：信用情報管理システム開発の発注/外注/依頼/委託方法について

ポイント

開発会社は、知名度や価格より、自社と同じ信用情報業務の実績で比べます。同じ要件書で提案と見積もりを受けると、価格差の理由が見えやすくなります。

よくある質問（FAQ）

回答は対象業務や接続条件で変わります。そのため、次の内容は仕様として固めず、業務・法務・接続先の確認に使います。

CICとJICCを1つのシステムにつなげられますか？

技術方式のほか、自社の加盟資格や契約、利用目的、照会権限、接続条件を満たす必要があります。両方に対応することは可能ですが、機関ごとに項目やエラー、受付条件が違うため、接続先別に処理とログを分ける設計が安全です。

信用情報を自社データベースに保存できますか？

可否は、情報の種類、利用目的、契約条件、保存期間、法令やガイドラインによって決まります。そのうえで、必要な項目だけを目的に沿って保存し、権限、暗号化、期限、消去、訂正、開示の履歴を管理します。

分析用に複製する場合は、匿名化や利用範囲の制限を含めて、法務・コンプライアンス部門と確認してください。

金融機関でもクラウド型を利用できますか？

利用できる可能性はあります。ただし、金融機関向けの要件を満たす構成が前提になります。

安全要件：安全管理、可用性、委託先管理の要件を満たします。
データ・監査：データ所在、監査、復旧、接続制御を確認します。
運用評価：方式の名称だけでなく、責任分界、24時間監視、障害時の代替運用、ログの取得範囲で評価します。
段階移行：既存基幹を残し、信用情報管理の一部から移す方法もあります。

補助金はスクラッチ開発にも使えますか？

補助制度ごとに対象経費が異なり、スクラッチ開発費が自動的に対象になるとは限りません。

2026年のデジタル化・AI導入補助金通常枠では、対象ITツールの業務プロセス数によって、補助額が5万円以上150万円未満、または150万円以上450万円以下です。補助率は原則2分の1以内などとされています（出典：中小企業基盤整備機構「デジタル化・AI導入補助金2026 通常枠」、2026年）。

申請前には、公式情報で次の4つの対象条件を確かめてください。

登録ITツール：対象として登録されているかどうか。
支援事業者：申請時に関わる事業者の条件。
申請時期：いつ申請できるか。
対象経費：補助の対象になる経費の範囲。

費用を抑えるには何を後回しにすべきですか？

法令や契約、照会、権限、ログ、訂正に関わる機能は、後回しにしません。バックアップや業務継続に関わる機能も、費用を抑える場合でも残しておきます。

段階導入できる機能：高度な経営分析、AIスコア自動化、特殊帳票、全社展開は第2段階に回せる場合があります。
費用調整：安全性を下げず、対象業務と利用者を限定します。

まとめ

検討では、個人信用情報の照会・登録、法人の与信・債権管理、金融機関の信用リスク管理のどれを扱うかを、まず切り分けます。

顧客・取引先マスタや名寄せ、照会、審査、更新を、一つの業務フローとしてつなげます。権限やログ、訂正、保存期間、外部連携も、同じ流れの中で設計します。

安全性・データ品質・運用を含めた設計

費用は、既存パッケージ連携なら300万〜1,000万円程度から、個別開発や複数業務の統合では数千万円、大規模な基幹連携では2億円超まで広がります。

接続試験、移行、監査、復旧、制度変更、保守を含めた総費用で比べます。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を創業。