マルチテナントのシステム開発は、分離要件を定め、RFPと契約に反映し、PoCで確かめる順に進めると、複数の顧客を安全に運用しやすくなります。
発注形態の選び方や契約、費用、委託先の比べ方も、この流れの中で判断していきます。
▼全体ガイドの記事
・マルチテナントのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
マルチテナントのシステムを発注する前に押さえる全体像
マルチテナントは、1つのアプリケーションやコードベースを複数の企業・組織が使う方式で、各社には自社専用の環境に見えるように提供します。販売管理、CRM、勤怠、人事、予約、ECなどのSaaSでよく使われています。
マルチテナントは、ユーザーを追加するだけの仕組みとは違い、契約単位で利用開始・変更・停止・削除まで管理します。特に大切なのは、テナント間でデータや権限が混ざらないことです。
共有型と専用型の違い
共有型と専用型は、運用効率と顧客ごとの分離要件を比べて選びます。構成によって、顧客追加や保守の負担も変わります。
- 共有型：同じアプリケーションやデータベースを、複数のテナントで共用します。
- 専用型：テナントごとに、DBやアプリケーション、クラウド環境を分けた構成。
共有型は環境を複製しなくてよく、アップデートを一括で適用しやすい方式です。標準化した業務を低コストで提供したい場合に向いています。
共有型では、クエリ条件の漏れやキャッシュキーの衝突が起きると、別テナントの情報が見えてしまう危険があります。
専用型は、機密性や性能、データ所在地といった顧客ごとの要件に対応しやすい方式です。その一方で、構築・監視・バックアップ・更新の対象が増えます。
AWS Well-Architected SaaS Lensは、効率だけでなく、コンプライアンスやノイジーネイバーも考慮するよう示しています。さらに、階層別サービスを理由にサイロ型を選ぶ考え方も紹介されています（出典: AWS Well-Architected SaaS Lens、2026年参照）。
分離すべき対象の範囲
テナント間の漏えいを防ぐには、データの保存先から運用画面まで、対象ごとに境界がそろっているかを発注側と開発会社で確認します。
- データと保存先：DB、ファイルストレージ、検索インデックス、バックアップ。
- 処理と配信：キャッシュ、メッセージキュー、メール、ログ。
- 利用者と管理：認証・認可、管理者画面、データアクセス。
共有キャッシュにテナント識別子がない場合や、CSV出力だけ検索条件が異なる場合も事故につながります。また、バックアップ復元時に別の顧客へ誤ってデータを戻す危険もあります。
テナントIDの扱いについては、OWASPのMulti-Tenant Application Security Cheat Sheetが推奨を示しています。クライアントが送った値をそのまま信頼せず、認証済みのセッションやトークンからテナントを確定して、データアクセス層で所有権を検証します。
キャッシュキーや保存パスにも境界を反映します（出典: OWASP Multi-Tenant Application Security Cheat Sheet、2026年参照）。
発注側がこの範囲をRFPの非機能要件に含めることが、発注の出発点です。
発注形態の選び方とパッケージ・クラウド・スクラッチの違い
発注形態は、機能数だけでなく、業務をどこまで標準化できるかで決めます。自社がSaaS事業者として継続運用するかも、判断材料になります。
既存サービスに合わせられるのにフルスクラッチを選ぶと、初期費用と保守負担が膨らみます。また、差別化が必要なのに設定変更だけで済ませると、後の大規模な作り直しにつながる恐れがあります。
標準化された業務に向くパッケージやSaaS
既存業務に合わせられる範囲を見極めれば、導入形態を絞り込めます。標準化できる業務であれば、既存サービスを活用できます。
- 既存サービス：マルチテナント型SaaSやパッケージの導入
- 不足機能：必要な部分をAPI連携やアドオンで補う
販売管理や勤怠、請求などの大部分を既存運用に合わせられる場合は、この方式が現実的です。初期の開発量を抑えられ、更新やセキュリティ対応も提供会社に寄せられます。
SaaSが備える「複数ユーザー対応」と、自社が複数企業へ提供するテナント管理は、別々に確認する必要があります。そのうえで、標準機能で不足する範囲を確かめます。
テナント管理の機能が標準で備わっているかは、管理者や料金プラン、データ出力などの面から確かめます。解約時の削除や監査ログも、同じ目で見ます。外部連携やSSOについても、同じように確認します。
個別カスタマイズを重ねる場合は、将来の更新や契約終了時の移行条件まで確かめておく必要があります。
差別化や拡張性が必要な場合のクラウド上の新規開発
顧客拡大や個別設定、既存基幹・外部APIとの連携が必要なら、マネージドサービスを使うクラウド開発が候補です。
- クラウド：AWS、Azure、Google Cloudなどの利用
- 標準サービス：監視やバックアップ、WAF、DB運用を組み立てやすくするサービス
将来の顧客増加に合わせた拡張も、設計に組み込めます。AWSは2025年8月、アイデミー事例を公開しました。ECSとApplication Load Balancerを採用しています。
さらに、Aurora PostgreSQLのRow Level SecurityとAWS WAFも組み合わせました。なお、2名の開発チームが3週間でインフラ環境を構築したと紹介されています（出典: AWS Japan公式ブログ「アイデミー様のSaaS on AWS事例」、2025年）。
この3週間はインフラ構築の期間です。そのため、業務アプリ全体の要件定義・開発・移行期間とは分けて見積もります。
競争力と専用要件が明確な場合のフルスクラッチ
独自要件が競争力につながるかを見て、スクラッチ開発の必要性を判断します。共通機能と顧客固有の設定を分けることが基本になります。
- 独自要件：特殊な業務、厳格なデータ所在地、複雑なリアルタイム連携。
- 顧客別要件：異なる料金モデルや権限モデルへの対応。
これらが競争力になる場合は、クラウド上でスクラッチ開発を行うのが適しています。顧客ごとに環境を複製せず、共通のコードを保ったうえで、設定によって差分を吸収します。
機密性の高い顧客だけを、専用DBや専用環境に移せるハイブリッド型も有効です。全顧客に同じ分離方式を当てはめる必要は、必ずしもありません。
分離方式には、共有型、テナント別スキーマ・DBのブリッジ型、顧客ごとに環境を分けるサイロ型があります。料金プランや契約と分離レベルを連動させる前提を発注時に合意しておけば、将来の大口顧客にも対応しやすくなります。
RFPと要件整理で発注先に伝えるべき項目
RFPは、同じ条件で提案と見積もりを比べるための基準です。そのため、「マルチテナント対応」の一言で済ませず、利用者や業務、企業数、必要な性能と分離の水準を書き込みます。
要件は数値と業務シナリオで示し、未確定の項目は未定と明記します。そのうえで、提案側に確認事項と代替案を求めます。
事業要件とテナント運用の具体化
事業の規模と契約後の運用を具体化すると、必要な管理機能や連携を見積もれます。利用開始から解約までの業務の流れも、整理しておきます。
- 事業規模：対象業界、初年度・3年後のテナント数、1テナントあたりのユーザー数、同時接続数。
- 契約運用：料金プラン、無料トライアル、利用開始、変更、休止、解約。
- 権限と課金：利用者権限、計測単位、上限超過時の動作。
テナントの登録を営業担当が手作業で行うか、契約・決済と連動して自動で作成するかによって、管理画面と連携方式が変わります。また、データ出力や削除証跡も、業務フローに含めて書いておきます。
機能要件には、テナント管理者、部門管理者、一般利用者を記します。運用者などについても、役割ごとに書き分けます。
顧客管理者による利用者の追加や、運用者が顧客データを見る際の承認と記録も、明確にしておきます。
売上や利用量をテナント単位で集計する場合は、課金対象メトリクス、計測単位、上限超過時の動作を記載します。これを明確にしておくと、請求機能の追加費用を抑えやすくなります。
非機能要件とセキュリティの合格条件
非機能要件は、形容詞ではなく数値や時間で定めます。ピーク時の件数や許容時間を示せば、見積もりの前提をそろえられます。
- 性能と稼働：稼働率、目標応答時間、同時実行数、ピーク時件数。
- 復旧と監視：バックアップ頻度、復旧時間・時点、保持期間、監視時間。
- 障害連絡：連絡方法と、他社への影響を抑えるクォータや制限。
「高速」「安全」といった表現だけでは、会社ごとに見積もりの前提が変わります。そこで、1社の大量処理が他社の性能を下げるノイジーネイバーへの対策として、テナント別のクォータやレート制限、優先度を定め、アラートも求めます。
セキュリティ要件は、ログインだけでなく、テナントID改ざんやIDOR、権限昇格を対象にします。加えて、CSV・ファイル出力、キャッシュ、検索の経路も含めます。バッチやメール、復元も、要件の対象です。
異なるテナントの利用者で同じ操作を行い、データが混ざらないことを、テストで指定します。
個人データを扱う場合は、クラウド事業者や保守会社が実際にデータを扱うかも確認します。国外の再委託先の有無や、保存・アクセス場所、削除方法も併せて確かめます。
外国の事業者へ個人データの取扱いを委託する場合は、法第28条の整理が必要な場合があると、個人情報保護委員会は示しています（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドラインに関するQ&A」、2025年確認）。
PoCと受け入れ条件の事前設定
新規性が高い案件や既存のシングルテナント製品からの移行では、いきなり本開発を契約せず、短いPoCで不確実性を減らす方法があります。そのうえで、確認する範囲を先に決めておきます。
- 異なるテナント間でのログイン、権限、データ取得を検証する
- ファイル保存、通知、CSV出力、バックアップ復元を試す
- 同時アクセスやtenant_id改ざんへの応答を確かめる
- 解約済みテナントのアクセスや、大量処理の影響を確認する
PoCの成果物は、画面のほかに報告書も求めます。報告書には、分離方式と想定テナント数、負荷試験の条件を含めてもらいます。さらに、未解決のリスクや本開発の追加工数も書いてもらいます。
本番の受け入れ条件には、機能試験に加えて、テナント間でアクセスできないことと、監査ログが残ることを含めます。また、復元手順を実行できることや、障害時に連絡と切り戻しができることも確認します。
マルチテナント開発の契約形態と責任分界
分離方式や移行データの状態によっては設計変更が起きやすいので、契約形態は要件の確定度と変更の多さに合わせて選びます。全工程を完成責任だけで最初から固定すると、無理な前提が見積もりや品質に表れます。
発注側と開発会社は、要件定義から運用までを工程ごとに分け、納めるものと責任範囲を確かめます。
請負契約の成果物と変更ルール
請負契約は、完成させるシステムや成果物、検収条件を定める形態です。要件が固まった機能や、合意済みの移行ツールに向いています。
- 仕様：対応ブラウザ、性能条件、セキュリティ・テナント分離試験。
- 納品と検収：納品物、検収期限、瑕疵や契約不適合への対応。
料金プランの追加や専用環境への変更が起きた場合に備え、扱いを事前に決めておきます。既存データの不備や外部API変更も、決めておく対象になります。そのうえで、追加費用や納期を合意する手順が必要です。
「軽微な変更」の定義が曖昧だと、発注側と開発会社の双方に想定外の負担が生じます。そのため、変更要求票と影響範囲、承認者を決め、見積もりの更新まで契約前に合意しておきます。
要件定義や継続改善に向く準委任契約
準委任契約は、専門人材が一定の業務を遂行する形態です。進めながら決める工程と相性がよいのが特徴です。
- 検討工程：要件定義、アーキテクチャ検討、PoC。
- 継続工程：アジャイル開発、既存システムの段階移行。
準委任では、発注者にも優先順位を決める責任があります。そのため、プロダクトオーナーや業務担当、セキュリティ担当の参加時間を確保しておきます。
契約では作業時間だけでなく、週次報告や設計レビュー、試験結果の扱いも定めます。リスク管理表、コードレビュー、意思決定記録も、契約で決める対象です。
準委任でも品質保証は必要で、テナント分離など重大な要件は、試験内容と合格条件を明文化します。
契約に残す権利・再委託・運用責任
納品後に自社で改善できるよう、成果物と運用資産の扱いを確認します。著作権の帰属だけでなく、改修や二次利用に必要な権利も定めておきます。
- 成果物：ソース、設計書、API仕様、DB定義、IaC、テストコード。
- 運用資産：手順書、監査ログ、クラウドアカウント。
- 終了時：データ返却・削除証明、第三者ライセンス。
- アカウント：クラウドアカウントの所有者。
再委託先がいる場合は、会社名と所在国、担当範囲を確認します。加えて、アクセス可能なデータや事故連絡、監査の可否も求めます。
アプリの認可やテナント分離は、クラウド会社の責任とは別です。そのため、どこまでを誰が受け持つかを整理しておきます。障害や漏えい、データ削除が起きたときに、誰が何をするかも合意しておきます。
マルチテナントのシステム開発費用相場と見積もりの内訳
開発費は、PoC・MVPで300万〜800万円、標準的なBtoB SaaSで800万〜2,000万円が推定レンジです。複数業務を含む本格サービスは2,000万〜5,000万円、厳格な監査や専用環境を含む場合は5,000万〜1億円以上です。
期間の目安は順に、2〜4か月、4〜8か月、8〜15か月、12〜24か月以上です。ただし、公的な一律価格ではありません（出典: NotebookLMリサーチノート「マルチテナントのシステム」、2026年8月）。
分離レベルで変わる規模別の費用相場
想定する規模と機能をそろえてから、費用を比べます。各レンジには、分離や運用の要件が異なる形で含まれています。
- PoC・MVP：300万〜800万円。
- 標準的なBtoB SaaS：800万〜2,000万円。
- 複数業務を含む本格サービス：2,000万〜5,000万円。
- 監査や専用環境が厳格な場合：5,000万〜1億円以上。
PoC・MVPは、主要業務1つと数テナントに、共有DBを使う構成を想定します。基本的なロール管理と最低限の管理画面も想定します。
標準的なBtoB SaaSには、テナント登録、プラン・課金、外部APIを含みます。加えて、監査ログやバックアップ、負荷試験も含めます。
複数業務や帳票を含めたり、SSOやデータ移行を加えたりすると、2,000万〜5,000万円以上へ上がりやすくなります。顧客別の専用分離を加える場合も、同じ方向に費用が動きます。
一般的な業務システムでは、小規模を50万〜300万円または300万〜1,000万円とする整理があります。中規模は300万〜1,000万円または1,000万〜5,000万円、大規模は1,000万円以上または5,000万〜1億円以上とする例もあります。
分類の方法によって幅が変わるため、これをマルチテナント固有の費用とは断定できません（出典: NotebookLMリサーチノート、2026年8月）。
機能数だけでなく、分離や移行の作業も含む見積もりかを確認します。監査や負荷試験、運用自動化も含まれているかを確かめます。
初期開発費とランニングコストの分け方
ひとまとめの見積もりは比較しにくいので、初期費用と運用費を分け、工程や分離方式の前提も明記してもらいます。
- 開発工程：要件定義、UI・UX、アーキテクチャ設計、アプリ実装、DB設計、認証・認可。
- 追加機能：テナント管理、課金、外部連携、データ移行。
- 試験・運用準備：テスト、インフラ、監視、ドキュメント。
共有DB、テナント別スキーマ、専用DBのどれを前提にするかは、見積書にも記載してもらいます。
運用費には、クラウドやDB、ストレージの費用が含まれます。バックアップや監視、WAFも対象になります。外部認証やメール配信、サポートも、運用費に入ります。
障害対応や脆弱性診断、追加開発も見込みます。保守運用費は、初期開発費の年15〜25％程度とする一般的な目安があります。
保守運用費は、24時間監視やSLAの有無で変動します。専用環境やデータ量、窓口の有無も、変動の要因です（出典: NotebookLMリサーチノート、2026年8月）。
テナント追加の費用と、専用型へ移行する費用も、別に確認します。
費用を押し上げる要因
見積もりの範囲と前提をそろえると、金額差の理由を判断できます。分離や既存データの移行も、費用に影響します。
- 利用規模：テナント数、ユーザー数、データ量、ピーク時の同時処理。
- システム要件：分離方式、外部連携、SSO、監査、専用環境。
- 移行条件：既存データの品質、モデル変更、移行リハーサル。
既存のシングルテナント製品では、たとえば、全クエリにテナント条件を加えたり、データモデルを変えたりする必要があります。
顧客別設定の切り出しや移行リハーサルにも手間がかかります。そのため、初期費用だけでなく、検証期間も見積もります。
ある会社は負荷試験や監査ログを含み、別の会社はオプション扱いにしている場合、金額差は範囲の違いかもしれません。
前提や対象外の作業、追加単価を並べ、同じ条件の総額で比べます。クラウド費用や契約終了時の移行費用も、総額に含めて確かめます。
委託先の選定と見積比較で失敗しないポイント
委託先は、単なるWeb開発の実績ではなく、複数の企業を同じ基盤で安全に運用した経験で選びます。
提案書の見栄えや会社規模だけでなく、分離方式の理由や、顧客の追加・解約の自動化を確かめます。障害時の影響範囲やクロステナント試験、データ移行を、具体的に説明できるかを確認します。SLAや運用体制も、同じ観点で見ます。
実績は「何を作ったか」より「どう分離して運用したか」
守秘義務に配慮しながら、同じコードベースで何テナント程度を運用したかを質問します。分離方式や、顧客ごとの設定・料金プランの管理方法も確認します。
- 分離と運用：共有DB、スキーマ分離、専用DBの採用経験。
- 障害とリリース：影響範囲、一括反映、顧客別の延期可否。
- 体制：要件定義、設計、試験、リリース後の窓口。
差し支えない範囲で、障害時に影響を受けたテナントや、顧客別にリリースを延期できたかも聞きます。
設計レビューの責任者やセキュリティ試験の担当、問い合わせ窓口を明らかにしてもらいます。業務理解と運用体制も、選定の材料になります。
再委託がある場合は、アクセスする会社と国を示せるかを確認します。権限やログ保管、契約終了時の削除も、提示できるかを見ます。
工程・成果物・前提条件をそろえた見積もりの比較
各社に同じRFPと質問票を渡し、工程と成果物をそろえて比べます。相見積もりは、3社程度以上に依頼します。
- 開発と試験：要件定義、設計、アプリ、インフラ、テナント管理、分離・負荷試験。
- 移行と運用：脆弱性診断、移行、教育、保守、追加開発。
各項目を「含む」「別途」「発注者が用意」に分けておくと、契約後の認識違いを減らせます。
価格に加えて、納期や体制、提案の具体性を比べます。リスクの説明や発注者側の作業についても、同じ条件で見ておきます。
極端に安い提案では、非機能要件や試験が抜けている可能性があります。移行や運用設計も、抜けがないかを確かめます。一方で、高額な提案が専用環境や過剰な機能を一律に含んでいる場合もあります。
自社の優先順位を、必須、できれば欲しい、将来対応の三段階に分けて評価します。
提案の場で聞く設計の理由と失敗時の対応
分離方式を選んだ理由や、テナントIDを確定・再検証する箇所を聞きます。各データ経路の分離方法も、説明してもらいます。
- 境界：キャッシュ、ファイル、検索、バッチ、バックアップ。
- 障害対応：高負荷、解約後のアクセス、移行失敗の検知。
- 復旧体制：切り戻し方法と責任分担。
2025年11月、AWSは同じLambda関数を使いながら、テナントごとに実行環境を分けるテナント分離モードを発表しました。さらに2026年6月には、イベントソースマッピングとの連携方法も公開しました（出典: AWS Compute Blog、2025年11月・2026年6月）。
AWS Lambdaのテナント分離モードや、イベントソースマッピング連携を使っても、DBからログまで自動で分離されるわけではありません。新技術を使う提案では、サービスに任せる境界と、アプリ側で検証する境界を説明してもらいます。
よくある質問
発注前によく寄せられる疑問に、判断の基準とあわせて答えます。選び方は、機密性や成長規模に加えて、予算と運用体制によって変わります。
マルチテナントのデータベースは顧客ごとに分けるべきですか？
必ずしも顧客ごとに分ける必要はありません。共有テーブルやテナント別のスキーマ・DB、専用環境から、要件に応じて選びます。
機密性や性能、顧客契約を比べ、運用コストも見ます。採用の理由を明確にしたうえで、アクセス層から移行まで、監査やバックアップも含めて一貫して分離します。
マルチテナントのシステム開発費用はどれくらいですか？
PoC・MVPは300万〜800万円、標準的なBtoB SaaSは800万〜2,000万円、本格サービスは2,000万〜5,000万円が推定レンジです。
厳格な専用要件を含む場合は、5,000万〜1億円以上になります。公的統計ではなく、一般的な業務システム相場に分離・課金・監査・移行などを加味した目安です。
RFPで前提条件をそろえ、工程別の相見積もりを取ってください。
マルチテナント開発の外注先は何を基準に選べばよいですか？
同じ基盤での複数顧客の運用実績と、分離方式の判断理由を確認します。クロステナント試験や、追加・解約の自動化も見ます。
障害時の責任分界や移行、保守体制も基準になります。要件定義から運用まで工程別に説明があると、比較しやすくなります。
契約書にはマルチテナント特有の何を書けばよいですか？
分離方式やセキュリティ試験、性能条件を記載します。障害連絡と切り戻し、データの保存・返却・削除も書いておきます。
クラウドや再委託先との責任分界、ソースコードと設計書の権利も定めます。専用環境へ移せる場合は、移行条件と追加費用も明記します。
個人データや国外の委託先が関係する場合は、法務・個人情報保護の担当者にも確認してもらいます。
まとめ
発注時には、何社がどの業務を、どの分離レベルで使うかを決めておきます。共有型やブリッジ型、専用型には、それぞれ利点と負担があります。
全顧客に同じ方式を適用する必要はありません。成長のシナリオに応じて、機密性や性能が必要な顧客だけを専用環境へ移せる形も検討します。
RFP・契約・見積もりの判断基準のそろえ方
RFPと契約では、要件と責任範囲を明確にしておきます。比較の際には、試験や移行、保守が見積もりに含まれるかを確かめます。
- RFP：規模、性能、権限、監査、バックアップ、解約・削除。
- 見積もり：工程、分離・負荷試験、移行、保守の範囲。
- 契約：成果物、変更管理、責任分界、権利、データ処理。
再委託やデータの所在地も記載します。3社程度以上の提案を同じ条件で比べると、価格だけでは見えない違いを判断しやすくなります。
分離要件とPoCの合格条件から始める手順
「マルチテナント対応で」と依頼する前に、漏えいを防ぐPoCの範囲を決めておきます。そのうえで、異なるテナントでの操作を確かめます。
- ログイン、データ取得、ファイル、CSV、通知を検証する
- バックアップ復元を試す
- 識別・認可の層と、漏えいを防ぐ試験を確認する
委託先には、どの層でテナントを識別・認可し、どの試験で漏えいを防ぐかを説明してもらいます。
発注者の業務知識と、委託先の設計・実装・運用の力を組み合わせます。そうすることで、顧客追加後も安全に成長できるシステムを目指せます。
▼全体ガイドの記事
・マルチテナントのシステム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。