MongoDBのシステム開発の完全ガイド

MongoDBのシステムは、データベースにMongoDBを使う業務システムです。データ構造の柔軟性、検索・AI連携、RDBとの使い分けを押さえると、業務への適性を判断しやすくなります。各テーマの詳細は関連記事もご覧ください。

▼関連記事一覧
・MongoDBのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・MongoDBのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・MongoDBのシステム開発の見積相場や費用/コスト/値段について
・MongoDBのシステム開発の発注/外注/依頼/委託方法について

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

MongoDBのシステムの概要

MongoDBのシステムは、業務画面とAPIを中心に、認証や外部サービス連携、管理機能、監視などを組み合わせて作ります。

ただし、MongoDBを導入しただけでは、業務で使えるシステムは完成しません。そのため、業務ルールとデータの流れを決め、安全に操作できるアプリケーションに仕立てる必要があります。

ドキュメント指向データベースを基盤とする設計

ドキュメント設計では、データを保存する単位と、構造が変わったときの扱いが要になります。

• データ形式：JSONに近いBSON形式のドキュメントを、コレクションに保存する形です。
• 設計単位：顧客の氏名や連絡先、契約状況、利用履歴の一部を一つにまとめられます。

一般的なRDBは行と列の表を中心に管理します。一方、MongoDBは、アプリケーションが一度に扱う単位のままデータを設計しやすい点が特徴です。

商品属性が異なるカタログや、項目が増減する顧客プロフィール、センサーイベントなどに適します。こうした構造が一定しにくい領域では、その柔軟さが生きます。

柔軟性を何でも許される自由と捉えると、同じ意味の項目が別名で保存されたり、必須項目が欠けたりします。

そこで、命名規則やデータ型、必須項目を決めておきます。バージョンや保持期間も定め、必要に応じてJSON Schemaによる検証を設定します。

検索・拡張・可用性を支える主要機能

検索から可用性、更新、検索連携まで、支える機能は4つの領域に分かれます。

• 検索・集計：インデックスを使ってデータを取り出し、集計パイプラインで処理します。
• 可用性・分散：複製と自動フェイルオーバーはレプリカセット、データの分散はシャーディングが担います。
• 更新・通知：トランザクション、変更ストリーム、時系列コレクションを利用できます。
• 検索連携：Atlasではキーワード検索とベクトル検索を組み合わせられます。

検索連携は、商品検索や社内文書検索、会話履歴を使うAIアプリケーションの基盤にもなります。

公開された小売AI事例では、文書保存、ベクトル検索、キーワード絞り込みを一つの基盤にまとめています。この事例は、2025年のピーク商戦を含む3回の大規模商戦を運用したものです（出典：MongoDB公式公開事例、2026年閲覧）。

公開事例の成果は、自社にそのまま当てはめられません。自社のデータ量と検索品質で検証する必要があります。

MongoDBのシステムに向く業務・向かない業務

MongoDBを採用するかは、業務データの性質と変更頻度で判断します。RDBとの優劣を比べるより、この2点を見るほうが実情に合います。

画面やAPIでデータをまとめて読み書きするなら、ドキュメントモデルが活きます。逆に、複数の表を厳密に突き合わせる処理が中心なら、別の設計が適する場合があります。

顧客・商品・イベントデータに向く業務

属性がレコードごとに異なる業務は、MongoDBと相性が良い領域です。たとえば、顧客プロフィールや商品カタログ、コンテンツ管理、問い合わせ履歴などがあります。

• イベント・ログ：IoTイベントや操作ログを蓄積できます。
• 予約・顧客情報：項目の増減があるデータも扱いやすいです。
• 検索・AI連携：検索を重視する場合の候補で、文書や会話履歴を検索基盤と一緒に管理できます。

新しい商品属性や顧客区分を追加するときも、表の変更や多数の結合を避けやすくなります。また、APIの返却単位と保存単位も近づけられます。

たとえば、説明文や仕様書、画像の特徴量、販売条件を商品情報に関連付けます。そのうえで、キーワード検索と意味検索を組み合わせる構成が考えられます。

検索結果の根拠となる文書や会話履歴も、同じ基盤で管理できます。その結果、別々のデータストア間で同期する処理を減らせる可能性があります。

厳密な整合性が必要な業務でのRDBとの併用

MongoDBとRDBは、整合性とデータの役割で分けて考えます。

• RDBが向く業務：仕訳、請求確定、在庫引当、複雑な帳票集計。
• 整合性の設計：業務全体の安全性は、MongoDBのトランザクション機能だけでは決まりません。
• 併用例：顧客プロフィールや行動ログはMongoDB、会計や契約金額はRDBで管理します。

複数データの整合性を保ちながら、多方向に集計する業務では、RDBのほうが設計しやすい場合があります。

併用するなら、データの正本、連携する時点、障害時の再送方法を決めておく必要があります。特に、適性と連携コストを比べておくことが、長期的な運用負荷を左右します。

MongoDBのシステム構成と選択肢

MongoDBのシステムでは、通常、利用者の画面からデータベースへ直接つながず、API層を介して構築します。

APIは、認証、入力検証、業務ルールを担い、権限確認もAPIの役目です。一方、MongoDBはデータの保存、検索、集計を担います。

クラウドやネットワークに加え、監視とバックアップも含めて、本番運用の構成になります。

画面・API・MongoDB・外部連携の役割分担

本番構成では、システムの各要素とデータの流れを対応づけて考えます。

• 構成要素：画面、APIサーバー、MongoDBを分け、ファイル保管、認証基盤、外部サービスも切り離します。
• 顧客情報：APIを通じてMongoDBへ書き込みます。
• 決済・検索：通知で決済を記録し、変更ストリームを使って検索インデックスを非同期で更新できます。

対象には、ブラウザやモバイルアプリ、業務端末も含めます。こうした役割分担を、構成図に落とし込みます。

境界を明確にすると、データベースを直接操作する処理が乱立するのを防げます。あわせて、API仕様のバージョン、再送時の重複防止、タイムアウトも設計します。

監査に必要な操作履歴は、データモデルと同時に検討します。

Atlasと自己管理型の運用体制の違い

既存のアプリ基盤やネットワーク方針との整合も踏まえ、運用の範囲と料金の2つの面から利用形態を比べます。

• Atlas：クラスタ作成やバックアップ、監視、スケールの負荷を下げやすく、主要クラウドやリージョンを選べます。
• 自己管理型：配置や設定を制御しやすく、運用作業は自社または委託先が担います。
• 自己管理の作業：パッチ、冗長化、障害対応、復旧訓練を行います。
• Flex：共有ハードウェアを使い、月額上限は30ドルです。一部の高度な機能に制約があります。
• 専用クラスタ：月額60ドルからです。追加項目は下記で確認できます。

専用クラスタでは、バックアップや追加ストレージ、データ転送などが別項目になります（出典：MongoDB公式請求ドキュメント、2026年8月閲覧）。

学習や小規模な検証で使う構成と、本番業務に必要な可用性は、分けて考えます。

MongoDBのシステム開発の進め方

MongoDBのシステム開発では、データベースを選ぶ前に業務目的と非機能要件を整理しておくと、失敗を減らせます。

データ量や読み書きの比率、同時接続数、障害時の復旧目標を定めておくと、クラスタやインデックスの判断が具体的になります。

詳しい進行方法はMongoDBのシステム開発の進め方/やり方/流れや方法/手法/工程/手順でも紹介しています。

要件定義での業務範囲と非機能要件の確定

要件定義では、業務側とシステム側の確認事項を分けて扱います。

• 業務範囲：利用者、画面、データを挙げ、登録・検索・更新の頻度も洗い出します。
• 業務要件：フロー、権限、承認のほか、外部連携、帳票、保持期間も整理します。
• 非機能要件：同時接続数や許容レイテンシ、稼働時間、RTO・RPOを数値化します。
• 管理要件：監査ログ、復元時間、個人情報の有無を確認します。

「通常時は2秒以内」と定める場合も、条件を分けて書く必要があります。たとえば、検索対象が100万件の場合、ピーク時に同時300人が操作する場合、集計処理が動く場合に分けて定めます。

要件定義書や画面一覧、データ項目一覧のほか、権限表と外部連携一覧も成果物として残します。これにより、見積とテストの基準がそろいます。

データモデル設計とPoCによる仮説検証

次に、業務上まとまって扱う単位を、ドキュメントの境界として考えます。顧客と注文、商品、イベントを一つのドキュメントに詰め込む設計は避けます。

データモデルとPoCでは、埋め込みと参照の使い分けと、検証で測る内容を押さえます。

• 埋め込み：更新や参照の頻度、データ量、履歴を見て、頻繁に一緒に読む小さなデータに使います。
• 参照：独立して増えるデータや多対多の関係では、別コレクションを検討します。
• PoCの計測：本番に近い代表データで、読み書き・検索・集計の性能、同時実行、索引の有無、復元、切り替えを測ります。

PoCでは、画面を一通り作るより、採用判断に必要なリスクを短期間で明らかにすることが目的です。たとえば、2〜6週間程度で、データモデルと主要APIの性能を確かめる計画が考えられます。

設計・開発・テスト・段階リリースの流れ

実装したシステムは、テストで機能や性能を確かめ、限定リリースで入力の負担や作業時間を見てから、段階展開に進みます。

1. 実装：APIや画面、認証を作り、データ移行、監視、バックアップも用意します。
2. 設計：代表クエリや並び順、絞り込み条件、更新頻度から、インデックスを決めます。
3. テスト：機能や性能、権限、障害復旧、バックアップの復元を確認します。
4. 限定リリース：小規模な対象部署や機能で、入力の負担、検索結果、作業時間を見ます。
5. 段階展開：並行稼働や段階移行を行い、切り戻しの条件と責任者を定めます。

全社の要望をすべて最初から盛り込むと、開発範囲や費用、期間が膨らみ、現場に定着させるのも難しくなります。そのため、要望の優先順位を管理します。

MongoDBのシステムの費用相場と3年TCO

MongoDBのシステム費用は、データベース料金に、要件定義や画面・API開発、データモデリング、既存データの移行を加えて見積もります。

クラウドや保守に加え、バックアップ、監視、追加改修も分けて考えます。以下の金額は、日本向けMongoDB専用の公表相場ではありません。

業務システム一般の目安に、MongoDB案件で増えやすい作業を加えた推定値です。実際の金額は、データ量や連携数、可用性、SLAによって変わります。

詳しい見積相場はMongoDBのシステム開発の見積相場や費用/コスト/値段についてでも紹介しています。

初期開発費の規模と移行範囲による違い

規模と開発範囲ごとの目安を、初期費用と期間の両方で比べます。

• 技術検証・小規模PoC：50万〜200万円が目安です。
• 小規模MVP：画面・認証・APIを含み、300万〜800万円です。
• 部門向け：複数権限、外部連携、帳票、初期移行を含み800万〜2,000万円です。
• 大規模構成：基幹連携や24時間運用などを含むと2,000万円〜1億円超の例もあります。

これらは推定レンジです。会社名や技術名だけでは料金を決められないため、要件の確認が欠かせません。

期間の目安は、PoCが2〜6週間、小規模MVPが2〜4か月、部門向けが4〜9か月です。なお、高可用性や基幹連携を含む場合は、9〜18か月以上です。

見積書では、要件定義やデータモデル、API、画面を別行に分けてもらいます。そのうえで、移行やテストに加え、クラウド設定、マニュアル、教育も項目に含めてもらいます。

「システム開発一式」とだけ書かれた見積では、後から追加費用が発生する境界を判断しにくくなります。そのため、作業範囲を明示してもらいます。

クラウド・保守・追加改修の月額と年額

継続費用は、クラウド料金と保守、追加作業に分けて把握します。

• Atlas料金：無料枠、共有月9ドルから、専用月60ドルからです。
• 本番基盤：月2万〜20万円程度、大規模構成は月数十万〜数百万円の可能性があります。
• 保守費：初期開発費の年15〜20%程度を仮置きする方法があります。
• 3年TCO：初期費用とクラウドの36か月分、保守の3年分に、追加改修や教育なども含めます。

1ドル150円で換算すると、共有は約1,350円、専用は約9,000円になります。

為替やリージョン、稼働時間も別に確認します。さらに、ストレージやバックアップ、転送などクラウド側の料金も、別に見ておきます（出典：MongoDB Atlas公式料金ページ、2026年8月閲覧）。

本番レンジは、料金表からの編集上の推定です。保守費には、障害対応や監視、パッチが含まれます。バックアップ確認や軽微改修、問い合わせ対応も含みます。

たとえば、初期費用が1,000万円なら、保守費は年150万〜200万円、月額12万5,000円〜約16万7,000円です。運用引き継ぎ費も、TCOに含めます。

RDBからの移行とデータモデリングの注意点

既存のRDBからMongoDBへ移行するときは、表をそのままドキュメントに変換せず、業務に合わせて組み直す必要があります。

まず、現在の画面や帳票、APIを確認します。検索条件や更新頻度、履歴要件も確かめたうえで、業務上まとまって扱う単位へ再設計します。

移行の難しさは、製品の違いよりも、現行データの重複や欠損、表記揺れ、古いマスタにあります。

柔軟なスキーマにおける業務上の契約

データ構造を長く保守するため、次の契約事項をあらかじめ決めておきます。

• データ契約：必須項目や、数値・日時・文字列の型、配列の上限を決めます。
• 互換性：旧バージョンを読める期間を定め、構造変更をバージョン管理します。
• 保持・削除：TTLログの保存期間と例外を定め、監査履歴は別保管も検討します。

実際のクエリは一覧にし、頻度や許容時間、対象データ量をもとに優先順位を付けます。ただし、インデックスを増やすほど、書き込みやメモリ、ストレージの負担も増えます。

集計が通常業務の読み書きを圧迫する場合は、処理時間を分ける設計や、集計用データの作り方を見直します。

移行の棚卸し・変換・並行稼働・切り戻し

移行作業は、準備から切り替え後の対応まで順に進めます。

1. 棚卸し：現行データと移行対象を整理します。
2. 準備：変換ルールを作り、テスト移行を行います。
3. 同期・検証：差分同期と受け入れ検証を行います。
4. 切り替え：本番を切り替え、必要なら切り戻します。

顧客IDや注文番号などの業務キーは、維持するか新しいIDへ変換するかを、先に決めておきます。

金額や日時、タイムゾーンは、移行後に不具合が見つかりやすい項目です。削除状態や添付ファイルの参照先も、移行後に不具合が出やすい項目です。

停止時間を短くするなら、過去データを先に移しておきます。そのうえで、移行期間中の差分を記録してから切り替える方式を検討します。

切り替え前には件数だけでなく、重要項目の合計やランダムなサンプルを照合します。さらに、主要画面の検索結果や権限による表示差も確かめます。

作業者や判断者、停止の上限、切り戻しの条件を決めておくと、障害時に現場が迷いにくくなります。

セキュリティ・個人情報・運用保守の設計

個人情報や機密情報を保存する場合は、データベースだけでなく、アプリケーションや端末、クラウド、委託先まで含めて安全管理を考えます。

個人情報保護委員会のガイドラインは、漏えい・滅失・毀損を防ぐ措置を、データの性質や量などのリスクに応じて講じるよう示しています（出典：個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年閲覧）。

認証・権限・暗号化・ネットワークの多層対策

安全管理は、アクセス制御、情報保護、委託先との取り決めに分けて考えます。

• 認証・権限：人とアプリのアカウントを分け、必要最小限の権限にします。
• 保護策：TLSや保存・項目単位の暗号化、監査ログ、ネットワーク制限を組み合わせます。
• 委託契約：利用目的とアクセス範囲、保存場所、再委託、事故連絡、返却・削除、監査を定めます。

秘密情報も安全に保管する必要があります。MongoDB公式チェックリストは、認証、ロール制御、TLS、保存データを挙げています。さらに、信頼できるネットワーク、監査、定期パッチにも触れています（出典：MongoDB Manual 8.3「Security Checklist」、2026年8月閲覧）。

個人情報保護委員会のガイドラインは、委託元に必要かつ適切な監督を求めています。

技術設定だけでなく、契約と運用手順まで確かめます。

バックアップとRTO・RPOの実測

バックアップは、取得したうえで復元できるかまで確かめる必要があります。そこで、復元テストや目標、日常の監視項目も確認します。

• 復元テスト：戻せる時点や復元時間、復元後のアプリ動作を検証します。
• 目標との照合：RTO4時間・RPO15分なら、頻度や切り替え手順が目標を満たすか確認します。
• 監視：CPUやメモリ、遅延、インデックスを追います。容量や接続数、エラー、バックアップも対象です。

RTOは障害から復旧するまでの目標時間、RPOは復元するデータ時点の目標です。

MongoDB公式ドキュメントは、長いクエリや未使用クラスタを、請求と性能の確認対象として説明しています。さらに、バックアップとデータ転送も、請求・性能の確認対象として挙げられています（出典：MongoDB公式請求最適化ドキュメント、2026年8月閲覧）。

月次で利用量と料金を確認し、不要な環境を停止する運用も必要です。

MongoDBのシステム開発会社・ベンダーの選び方

開発会社・ベンダーは、MongoDBの経験だけでなく、要件定義やデータモデリング、RDB移行への対応力で選びます。クラウドやセキュリティ、運用保守への対応力も、あわせて見ます。

公式パートナーや認定の有無は参考になります。ただし、それだけで品質や価格を断定することはできません。そのため、自社に似たデータ量や業務の複雑さ、移行条件を扱った担当者が提案に参加するかを確認します。

技術力に加えた業務理解と移行力の評価

候補会社の提案では、技術説明に加えて、作業体制と検証内容も見ます。

• 設計力：ドキュメントの境界、RDBの再設計、クエリに基づく索引設計について質問します。
• 性能・移行：件数や同時接続、測定条件を確認します。変換、差分同期、照合、停止時間、切り戻しの手順も見ます。
• 運用体制：Atlas・自己管理型の責任分界、リージョン、バックアップ保持期間、監視時間帯、障害時の一次対応、パッチ担当を把握します。
• 担当者：要件定義や教育の役割と稼働期間、設計・移行・運用責任者の参加を確かめます。

性能については、「速い」という説明よりも、許容時間まで示せるかを見ます。また、日本語での要件定義や現場教育が必要な場合は、提案書の担当情報を確認します。

RFPと契約による成果物・費用・責任範囲の固定

見積の条件をそろえたうえで、契約後の成果物と、どこまでを誰が受け持つかを定めます。

• 見積条件：目的、業務、利用者数、データ件数をそろえます。ピーク負荷、既存環境、連携先も合わせます。
• 費用比較：初期費用、月額クラウド費、保守費、追加改修単価を比べます。
• 提案比較：納期、体制、成果物、コード引き渡し、契約終了時のデータ返却も比べます。
• 契約条件：変更や受け入れ、性能試験、障害対応、連絡時間、復旧目標を確認します。
• 責任範囲：バックアップ、再委託、秘密保持、個人情報の扱いを定めます。移行、テスト、教育、運用設計も、受け持つ範囲を決めます。

同じ資料には、個人情報や希望RTO・RPO、リリース時期も記載します。費用を安く見せるために移行やテストなどが除かれていないか、注意が必要です。

詳しい会社選びは、MongoDBのシステム開発でおすすめの開発会社/ベンダー6選と選び方をご覧ください。

発注・外注の方法は、MongoDBのシステム開発の発注/外注/依頼/委託方法についてで紹介しています。

よくある質問

MongoDBのシステムを検討するときによくある質問を、適性、費用、個人情報、既存RDBからの移行の4つに分けて回答します。

MongoDBはRDBより優れていますか？

MongoDBとRDBの優劣は、業務によって変わります。項目の増減が多く、アプリケーション単位で読み書きするデータには、MongoDBが向きます。

一方、厳密な参照整合性や複雑な帳票集計には、RDBが向く傾向があります。業務ごとに使い分ける構成も有力です。

MongoDBのシステムは月額いくらかかりますか？

Atlasの公式料金は、無料枠のほか、共有インスタンスが月9ドルから、専用インスタンスが月60ドルからです。本番の総額は、クラウドやストレージ、バックアップ、転送などで変わります。監視や保守も含めて考えます。

開発費を含む初期費用は、小規模MVPで300万〜800万円、部門向けで800万〜2,000万円が一つの推定目安です。利用量と運用条件を示したうえで、見積もってもらいます。

個人情報をMongoDBへ保存しても問題ありませんか？

保存すること自体が直ちに禁止されるわけではありません。そのうえで、利用目的とアクセス権限、暗号化を、リスクに応じて設計します。ネットワーク制限や監査ログも、あわせて考えます。

バックアップや保存場所、委託先の監督も確かめます。個人情報保護法上の義務も確認したうえで、法務・情報セキュリティ部門と、クラウドおよび開発会社の責任範囲を整理します。

既存のRDBからMongoDBへ移行できますか？

移行はできますが、表を機械的に変換せず、業務単位でデータモデルを再設計します。そのうえで、重複や欠損を洗い出し、変換、照合、差分同期、切り戻しを含む計画を作ります。

PoCで停止時間と性能を検証します。また、既存のRDBを残しつつMongoDBと併用する段階移行も選択肢です。

まとめ

MongoDBのシステムは、構造や量が変わりやすい業務で力を発揮します。顧客プロフィールや商品情報、ログ、IoTイベント、検索・AIデータが、その代表例です。

柔軟なドキュメントモデル、検索・集計、レプリカセット、シャーディング、変更ストリームを活用できます。ただし、柔軟性を理由に業務設計を省かないことが、活用の前提になります。

業務要件・費用・運用体制による採用判断

採用前には、MongoDBとRDBの使い分けや、Atlasと自己管理型の責任分界を整理します。初期開発費と月額費用、3年TCOも、あわせて見ます。

RTO・RPOや移行の停止時間、セキュリティ要件も確認します。PoCでは、代表データとピーク負荷を使い、性能に加えて復元と運用のしやすさを確かめます。

次の一歩となる業務範囲と検証条件の決定

相談に進む前には、共有する情報と比較条件、採用判断の考え方を整えます。

• 相談準備：業務フローやデータ項目、利用者数、連携先を共有します。個人情報や納期、性能目標も伝えます。
• 会社比較：要件定義から移行・保守まで同じ条件で比べます。
• 採用判断：業務要件や整合性、運用体制を設計したうえで、柔軟なデータを素早く業務へ届けたい場合の候補とします。

設計を先に固めれば、MongoDBの柔軟性が長期的な価値につながります。

▼関連記事一覧
・MongoDBのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・MongoDBのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・MongoDBのシステム開発の見積相場や費用/コスト/値段について
・MongoDBのシステム開発の発注/外注/依頼/委託方法について

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