プラットフォーム構築は、利用者、業務、連携、運用の要件を整理したうえで、認証やデータ、API、通知などの共通機能を複数の業務で使えるようにする開発です。
最初はMVPで重要な業務を検証し、そのあと共通基盤を広げていくと、必要な機能を段階的に加えられます。
▼関連記事一覧
・プラットフォーム構築開発の進め方/やり方/流れや方法/手法/工程/手順
・プラットフォーム構築開発でおすすめの開発会社/ベンダー6選と選び方
・プラットフォーム構築開発の見積相場や費用/コスト/値段について
・プラットフォーム構築開発の発注/外注/依頼/委託方法について
Webサービス開発の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」で詳しく解説しています。
プラットフォーム構築の全体像
プラットフォーム構築は、共通機能を先に整え、その上に利用者や業務を増やしていく開発です。画面の設計にとどまらず、データの閲覧権限、外部連携の形式、障害時の復旧まで含めて設計します。
単独システムとプラットフォームの違い
単独システムは、特定の部門や業務の効率化を主な目的にします。一方、プラットフォームは、複数の利用者や業務で認証、データ、API、通知、管理機能を共用します。
たとえば、顧客ポータルに契約確認や申請を加え、問い合わせ、請求、分析まで広げるときは、共通の顧客IDと権限モデルを初期の画面と合わせて設計します。
プラットフォーム構築の主な5類型
目的によって、プラットフォームは次の5種類に分けられます。
- 顧客・会員ポータル型：利用者向けの窓口を一つにまとめた型。
- 企業間連携型：企業間取引を、APIやEDIでつなぐ仕組み。
- データ基盤型：データの収集や統合、分析を担う仕組み。
- マルチテナント型：複数の企業が同じサービスを使う形。
- IoT・現場サービス型：設備や作業員の情報を、業務につなぐ仕組み。
共通して必要になる機能
基本機能には、登録とログイン、多要素認証のほか、組織・テナント・ロール別の権限管理があります。そのうえで、顧客や商品などのマスタや検索、申請・承認、通知の機能も含みます。さらに、ファイルや帳票、問い合わせ、管理者画面も含みます。
外部と接続するときは、APIキーやOAuth認証、レート制限、Webhookを検討します。加えて、データ変換や再送、エラー監視も検討します。
複数の企業で使う場合は、テナント分離と契約・料金管理を初期から設計します。さらに、利用停止や契約終了時のデータ返却も、設計の対象に含めます。
構築するプラットフォームの種類の決め方
種類を整理すると、必要な機能と非機能要件が見えてきます。複数の類型を組み合わせる案件も多いため、類型の名称で決めるより、誰が使い、どの業務やデータを扱い、何の価値を誰と交換するかを基に考えます。
顧客・会員ポータル型
顧客や会員が、契約状況や申請、予約を一つの窓口で確認し、請求や問い合わせも同じ窓口で扱う型です。そのため、会員属性や契約、組織、担当者の関係を、データモデルに定義しておきます。
現場で使われ続けるには、機能の数より入力項目を減らすことが大切です。そこで、スマートフォンからでも迷わず完了できるよう、導線を設計します。
企業間取引・API・EDI連携型
企業や部署のシステムをつなぎ、注文や在庫、配送、請求などを連携させる型です。接続先が増えるほど、個別の接続を変えるコストが高くなります。
APIゲートウェイや共通データ形式、認証を共通化します。利用量制限や監視、再送も同様に共通化し、相手側の仕様変更を吸収できる境界も設けます。
データ連携・分析型
販売や顧客、設備、物流、会計などに分かれたデータを集め、可視化や予測に使う型です。データの意味や更新頻度、品質をそろえるとともに、誰が保有し何に使うかも決めておきます。
設備IDや顧客IDがシステムごとに違うと、分析結果が正しい判断につながりません。そのため、データを集める前に、マスタとデータ辞書を整備しておきます。
マルチテナント型SaaS
複数の企業が同じサービスを契約し、設定やデータを企業ごとに分けて使う型です。テナント分離は、画面だけでなく全層で確認します。DBやAPIに加え、ファイル、ログ、バックアップまで対象になります。
料金プランや利用上限、契約更新は、設計の段階で決めておきます。後から業務ルールを作り直す負担を抑えるため、請求やサポート、解約後のデータ出力も設計に含めます。
IoT・現場サービス型
温度や湿度、電力のデータを集め、稼働状態や位置情報なども加えて、異常通知や作業指示につなぐ型です。また、通信できない場所や、手袋をしたままの操作も想定します。
通信できない場所でも扱えるよう、オフライン入力と再送を決めておきます。時系列データや設備IDの標準化、アラートの優先度も決めます。データは収集、蓄積、可視化の順に進み、異常通知や作業指示、結果記録へとつながって循環します。
プラットフォーム構築の6段階の進め方
すべての機能を最初から作ろうとすると、要件が膨らみ、予算を超えやすくなります。そのため、事業仮説と重要業務を小さく検証し、共通基盤を段階的に広げます。
▶ 詳細はこちら：プラットフォーム構築開発の進め方/やり方/流れや方法/手法/工程/手順
1. 事業仮説と利用者の定義
提供者や利用企業、現場担当に加えて、管理者や運用担当の役割も分けます。そのうえで、誰と誰の間で、どのデータや価値を循環させるかを一枚の図にまとめます。
機能を決めるには、「利用者を増やしたい」という目標を、成果を測れる形に直す必要があります。たとえば、申請時間を半分にする、入力漏れを減らす、設備異常への初動を短縮する、といった具合です。
2. 業務・データ・非機能要件の整理
画面一覧に加えて、業務フローやデータ項目、ID関係を整理します。さらに、権限や例外処理、連携先も洗い出します。そのうえで、利用者数や同時接続数、保存期間、SLAも決めます。
顧客や組織、契約、設備などの主キーを先に決めておかないと、後でデータを統合するのが難しくなります。また、通信断や返品、承認の差し戻し、担当者の交代といった例外も聞き取ります。
3. 4〜8週間のMVP・PoCによる価値の検証
MVP（Minimum Viable Product）やPoCでは、最重要の業務を1つと連携を1つに絞り、利用者が実際に使うかを確かめます。たとえば、現場が写真付きの作業報告を送り、管理者が異常を確認して指示を返す流れを、先に動かします。
画面の完成度に加えて、入力時間やエラー率を測ります。さらに、通知への反応やデータ品質、継続利用の意向も確かめます。そのうえで、本番に残す機能を判断します。
4. アーキテクチャとデータ連携の設計
構成は、Web・モバイル画面と認証・権限、業務APIとAPIゲートウェイに分けて考えます。業務DBや時系列・ログDB、ファイル保存も、役割を分けて組みます。
メッセージキューやバッチ・ETL、分析基盤を、役割ごとに設けます。監視・CI/CDやバックアップも、役割ごとに分けて置きます。
初期の段階で細かくマイクロサービス化すると、通信やテスト、監視、責任分界が複雑になりがちです。そのため、まずは境界の明確なモジュール型モノリスで始めます。負荷や組織分離が必要になった部分から分割するのが現実的です。
5. パイロット導入から本番への展開
検証のあとは、限られた部署や顧客で試験導入し、操作教育や問い合わせ、障害対応、データ移行の手順を確かめます。
利用者や連携先を増やし、負荷試験と権限テストを済ませてから、本番へ移ります。リリースは、開発の完了を示す日というより、利用状況を測って改善を始める日です。そのため、現場の変化にも合わせて改修していけます。
6. 運用データによる改善
稼働率や応答時間、エラー率、API利用量のほか、アクティブ利用者や業務完了率、問い合わせ件数も、継続して追います。そのうえで、要望は事業効果や利用者の困りごとを踏まえて優先します。
セキュリティや保守性、費用も、優先度を判断する材料になります。加えて、復旧訓練やログ確認、脆弱性対応、契約終了時のデータ返却も、定期的に見直します。
パッケージ・クラウド・スクラッチの選び方
方式は、差別化する業務と既製機能で足りる業務を分けてから選びます。価格や期間、拡張性を見るとともに、データ移行や運用人材、ロックインも確かめます。そのうえで、5年後も維持できる構成を選びます。
既存SaaS・パッケージを核にする方法
顧客管理や申請、ワークフロー、問い合わせの大半が既存サービスに合うなら、導入したうえで、独自の部分をAPI連携で広げます。初期費用や期間を抑えやすいうえ、標準機能の更新も使えます。
契約の前に、ライセンス単価や利用者増加時の費用を確認します。さらに、データ持ち出しやAPI制限、サービス終了時の移行方法も確かめます。
クラウドネイティブで構築する方法
マネージドDBやコンテナ、サーバーレスに加えて、API管理、監視、バックアップを組み合わせます。そうすると、利用量に応じた拡張や運用の自動化がしやすくなります。
一方で、従量課金や権限設計、リージョン、障害時の切り替え、ログ保管に関わる費用が見えにくい場合があります。そのため、リクエスト数やデータ量、保存期間、ピーク時の接続数を前提に、月額上限とアラートを設けます。
スクラッチ開発が向いているケース
独自の料金計算やマッチング、審査が競争力の中心になるなら、スクラッチ開発を検討します。設備制御や複雑な権限、業界固有のデータモデルが中心の場合も、検討の対象になります。
自由度は高まる一方で、要件定義やテスト、脆弱性対応、採用・引き継ぎの責任も広がります。また、独自部分だけを開発し、認証や通知、監視、決済には既存サービスを使う方法もあります。
ローコード・生成AIを使う際の注意点
ローコードや生成AIは、画面の試作や定型的な登録処理、テストコード、ドキュメント作成を速めます。
どこまで任せるかは、業務ごとに適用範囲を決めて判断します。そのうえで、生成物の品質確認やライセンスを決めます。さらに、個人情報を入力しないルールと障害時の責任も決めておきます。
実際に、2026年公開の大規模会員基盤の事例でも、ローコードと生成AIは、品質やガバナンス、運用設計と組み合わせて評価されています。
プラットフォーム構築の費用相場とコスト内訳
初期費用の目安は、MVPで300万〜1,000万円、中規模で1,000万〜3,000万円、大規模なマルチテナント型や高可用性基盤で4,000万〜1億円超です。ただし、これは確定した見積もりではありません。
費用は、機能数や利用者数、連携先によって変わります。さらに、データ移行やデザイン、セキュリティ、SLAによっても差が出ます。
▶ 詳細はこちら：プラットフォーム構築開発の見積相場や費用/コスト/値段について
規模別の初期費用と期間
含める機能の範囲が広がるほど、費用も期間も大きくなります。下の3区分は、規模ごとに含まれる機能と費用・期間の幅を示しています。規模別の目安を比べるときは、各社の見積もりが、どの区分の機能や条件を含んでいるかを確認します。
- 検証用MVP：会員登録、管理画面、主要業務1本、少数のAPI、最低限の分析を含む構成で、費用は300万〜1,000万円、期間は1〜4か月程度。
- 中規模：複数ロール、基幹連携、通知、監査ログ、移行、運用設計まで含み、費用は1,000万〜3,000万円、期間は4〜9か月程度。
- 大規模・マルチテナント型：課金、テナント分離、大量データ、高可用性、24時間運用を含む場合で、費用は4,000万〜1億円超、期間は9〜18か月以上。
API連携基盤では、技術支援やAPI管理製品、クラウド環境を含む公開パッケージで、税抜890万円からの例があります（出典: API連携プラットフォーム構築支援パックの公式公開ページ、2026年確認）。
掲載価格に含まれる支援時間、製品の利用期間、実作業範囲、クラウド従量料金は、案件ごとに確認が必要です。
費用の内訳と見積もりで確認する項目
予算の配分は、次の計画用の比率を参考にすると、抜けを確かめられます。
- 企画・要件定義：10〜20%。
- UI・UXと試作：10〜15%。
- アプリ・API開発：30〜45%。
- クラウド・DevOps・セキュリティ：10〜20%。
- テスト・移行・教育：10〜20%程度。
この比率は、案件条件から算出した計画値で、公開された統計ではありません。見積もりでは、画面数に加えて、連携数や権限パターン、データ量を反映します。さらに、テスト環境や移行難易度も見積もりに入れます。
人件費は、担当者のスキルや契約形態、管理工数によって変わります。そのため、準委任か請負か、再委託の扱い、追加開発の単価を明記します。さらに、障害対応の時間帯や保守範囲、クラウド契約の名義、データ返却費も書いておきます。
移行や監視、教育、脆弱性対応が別料金だと、初期見積もりが安くても総額は大きく変わります。
ランニングコストと5年総額
環境の規模や可用性で月額の運用費は違うため、条件別の目安を比べます。
- 小規模MVP：月数万円〜30万円。
- 中規模の本番環境：月30万〜150万円。
- 大規模・高可用性環境：月150万円以上になる場合もあります。
運用費には、クラウドの従量料金や監視、バックアップ、WAFやCDNが含まれます。ログ保管、外部サービスのライセンス、保守人員も、運用費の一部です。
料金は、アクセス数や保存量、通信量、バックアップ世代数、契約割引によって変わります。そのため、利用量の前提を置いて試算します。
たとえば、公式の料金試算例では、データ転送量やリクエスト数、保存容量に応じて月額が変わる従量課金の構成が示されています（出典: 目的別クラウド構成と料金試算例、2020年公開・2026年確認）。
開発費、移行費、5年間のクラウド費を合算し、さらに保守費や追加開発費、教育費、契約終了時の移行費も加えて判断します。
セキュリティ・運用・法務で失敗しない設計
利用者や連携先が増えるほど、事故の影響範囲も広がります。そのため、認証や権限、ログ、暗号化は、要件定義の段階から含めます。バックアップや障害復旧、データ削除も、同じ段階で扱います。
認証・権限・テナント分離の設計
個人データを扱う場合は、アクセスできる担当者と範囲を限定し、権限を識別・認証して不正アクセスを防ぐ仕組みを運用します（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年確認）。
権限管理とテナント分離では、次の対策を実装し、確かめます。
- 管理者権限：最小限に絞り、二要素認証を併用します。
- 権限変更：承認を設けたうえで、操作ログと定期棚卸しを行う体制にします。
- テナントID：API検索、ファイルURL、キャッシュ、バックアップ、分析データの全経路で、テナントIDを確かめます。
分離は、画面上の表示だけでなく、異なる企業のテストデータで横断参照を試して確かめます。さらに、契約終了後の削除とデータ出力も確認します。
可用性・監視・障害復旧の決め方
安定して稼働させるため、可用性の目標と、異常を検知する監視項目を数値で決めます。
- 可用性の目標：通常時とピーク時の同時接続数、許容応答時間、復旧目標の時間と時点、バックアップ世代、保守時間。
- 監視対象：サーバーやAPI失敗率、キュー滞留、連携遅延、未完了バッチ、認証エラー、異常な権限利用。
障害時の一次受付や判断者、利用者への通知時期、切り戻しの手順を決めておきます。また、バックアップからの復元訓練を定期的に行う必要があります。復旧後は、データの整合性と外部連携の再送結果まで確認します。
データ移行とAPI変更の管理
移行後も業務の整合性と連携の継続性を保つため、データ移行とAPI変更を順に管理します。
- 既存データの意味、欠損、重複、表記ゆれ、更新日時、個人情報の有無を洗い出します。
- 移行対象と除外、変換、検証件数、切り戻し、旧システムの停止期間を決めておきます。
- リハーサルを複数回行い、移行後は件数の一致だけでなく、代表業務を最初から最後まで動かして整合性を確かめます。
- APIの仕様書やバージョン、互換性、認証、制限、エラーコード、廃止予告、利用状況の把握方法を取り決めます。
- 変換層やバージョン管理を設け、連携先の仕様変更で全体を同時に直すリスクを下げます。
利用規約・個人情報・取引ルールの整理
取り扱う情報やサービスの形態に応じて、規約と取引ルールを整理します。
- 顧客・位置・決済・取引データ：目的、利用範囲、保存期間、第三者提供、委託先、国外取扱い、削除請求の確認。
- 取引の場を提供する場合：事業規模や業態を確かめたうえで、条件開示、変更通知、苦情・紛争処理を設計します。
デジタルプラットフォーム取引透明化法は、対象となる提供者に対して、情報開示や自主的な手続・体制の整備、年度ごとの報告と自己評価を求めています（出典: 経済産業省「法律のポイント」、2026年確認）。
ただし、すべてのサービスが一律に対象になるわけではありません。取引条件や問い合わせ対応は、要件定義の段階から検討します。利用規約の作成は、その後の工程になります。
プラットフォーム構築における開発会社/ベンダーの選び方
知名度や安さだけでなく、同規模・同利用形態の案件をどう進めたかで比べます。そのうえで、要件定義からAPI・データ・ID設計、クラウドまでを、一つの責任範囲で説明できるかを見ます。セキュリティや移行、運用も、同じ範囲で説明できるかを確かめます。
条件をそろえた実績の確認
判断の材料になるのは、業界が同じかどうかだけでなく、条件が近い案件かどうかです。たとえば、利用者数や同時接続数、テナント数、連携先が近い案件を見ます。さらに、データ種類や稼働時間、障害対応、移行量、保守期間も比べます。
公開できない案件でも、匿名化した構成図や課題、テスト方法、運用体制を説明できるかを質問します。要件が変わったときの見積もり更新方法や、試作の進め方も確かめます。
利用部門との合意形成の進め方や、設計書・ソースコードの納品範囲も聞きます。技術用語や機能一覧ばかりで、業務成果やリスクの説明がない提案は、プロジェクト管理の進め方を慎重に見ます。
見積もりの前提・除外・追加費用の比較
総額だけでなく、作業の分解や前提、除外事項、成果物、検収条件、変更管理を比べます。特に、要件定義が含まれるか、クラウド費が何か月分か、移行件数の上限はいくつかを確かめます。
テストデータを準備する担当者や、監視・障害対応の時間帯も確認します。保守では、窓口や受付時間、初動時間、復旧目標を比べます。さらに、脆弱性対応や更新、追加開発単価も見ます。
担当が替わる際の引き継ぎや、ベンダーを変える際のデータ、ソースコード、環境情報の返却も、契約に記載しておきます。
開発後の運用体制と内製化の確認
プラットフォームはリリース後に価値が増えていくため、役割分担と運用知識の引き継ぎが大切です。
- 自社の役割：運用・業務・開発・セキュリティの担当を決め、データの意味や権限承認、優先順位、障害時の判断を担います。
- 外部パートナーの支援：手順書や教育、コードレビュー、運用の引き継ぎを、提案の範囲に含めます。
▶ 詳細はこちら：プラットフォーム構築開発でおすすめの開発会社/ベンダー6選と選び方
▶ 詳細はこちら：プラットフォーム構築開発の発注/外注/依頼/委託方法について
比較可能なRFPの作成と失敗パターンの回避
複数社に相談するなら、同じ条件で比べられるRFPを用意します。全仕様が決まっていなくても、同じ書式で条件を渡せば、価格差の理由が見えてきます。
RFPに入れる項目
RFPには、事業背景や達成指標、利用者の種類と人数、同時接続数、端末を記します。さらに、業務フローや権限、データ項目、既存システム、連携先も書きます。
APIやデータ量、保存期間、個人情報の扱いに加えて、監査ログやバックアップ、SLAも含めます。また、移行や教育、予算、希望時期、体制、契約条件も書き加えます。未確定の事項は「検討中」と記し、提案側に、確認したい質問と仮定を分けて書いてもらいます。
よくある失敗と対策
機能を先に増やして、利用者と成果を後から決める失敗には、MVPで重要業務を検証し、利用率や完了時間を指標にして対処します。IDやデータの持ち主を後回しにする失敗には、データ辞書や権限表、連携仕様を要件定義に含めて備えます。
クラウド費や保守費を初期見積もりから外す失敗には、複数の利用量で試算し、上限アラートを設けます。運用知識が自社に残らない失敗には、担当者や手順書、教育、障害訓練、データ返却条件を確かめます。
プラットフォーム構築でよくある質問
プラットフォーム構築を検討するときによくある疑問に、順に答えます。費用や期間は要件によって変わるため、判断の基準があると、相談先の提案を比べる際の目安になります。
プラットフォーム構築は最低いくらからできますか？
検証用MVPは、300万〜1,000万円程度が予算取りの目安です。会員登録や管理画面、主要業務1本、少数の連携に絞った場合の金額です。
決済や複雑な権限、大量データ移行、高可用性、24時間運用を含めると、費用は増えます。そこで、必要な成果と利用者数を整理し、MVPと本番拡張を分けて見積もります。
パッケージとスクラッチ開発はどちらがよいですか？
標準的な業務が多く、短期の導入を優先する場合は、パッケージや既存SaaSを核にして、独自の部分だけを連携させる方法が適しています。
独自のデータモデルや料金計算、業務ルールが競争力になる場合は、スクラッチを検討します。認証や通知、監視は既存サービスに任せ、差別化する部分を独自開発にすると、費用と自由度のバランスを取りやすくなります。
完成までどれくらいの期間がかかりますか？
MVPは1〜4か月、中規模の本番開発は4〜9か月、大規模・マルチテナント型は9〜18か月以上が目安です。
期間が長くなる要因は、要件定義やデータ移行、外部連携先との調整です。セキュリティ審査や利用者教育も、長期化の要因になります。また、先に4〜8週間の試作をしておくと、本番開発の不確実性を下げられます。
自社に専門人材がいなくても構築できますか？
構築は可能ですが、業務責任者やデータ管理者、権限承認者、運用責任者は、自社で決めておく必要があります。要件の優先順位や受け入れの判断、障害時の業務継続も、自社で判断できる体制が必要です。
試作や設計書、操作手順、教育、コードレビューを通じて、外部の会社から段階的に知識を移します。
まとめ：プラットフォーム構築の段階導入と5年総額による判断
共通の認証や権限、API、運用基盤によって、複数の利用者や業務、データ、外部サービスをつなぐのがプラットフォーム構築です。
構築する対象を、顧客ポータルや企業間連携、データ基盤、マルチテナントSaaS、IoT・現場型などに分けると、機能とリスクを整理しやすくなります。
構築で押さえるべき要点
成功のポイントは、事業仮説と重要業務をMVPで検証し、最初から大きく作り込まないことです。そのうえで、ID、データ、権限、非機能要件を固め、段階的に広げていきます。
費用の目安は、MVPで300万〜1,000万円、中規模で1,000万〜3,000万円、大規模で4,000万〜1億円超です。さらに、比べる際は、クラウドや保守、追加開発、移行を含む5年総額を基準にします。
相談前に準備すること
まず、利用者数や同時接続数、主要業務、データ項目、連携先をまとめます。そのうえで、権限やSLA、移行、監査、予算、納期も加え、全体を一枚に収めます。
その内容をもとに複数社へ相談し、実績や要件定義、見積もりの前提、運用体制、データ返却条件を比べます。そうすると、価格だけに左右されない発注判断につながります。
▼関連記事一覧
・プラットフォーム構築開発の進め方/やり方/流れや方法/手法/工程/手順
・プラットフォーム構築開発でおすすめの開発会社/ベンダー6選と選び方
・プラットフォーム構築開発の見積相場や費用/コスト/値段について
・プラットフォーム構築開発の発注/外注/依頼/委託方法について
▼開発を相談する前に読みたい無料ホワイトペーパー
・Webサービス開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。