Amazon DocumentDBのシステム開発は、可変データの特性、負荷に合う構成、互換性の検証を踏まえて設計すると、業務に合うデータ基盤になります。
2026年時点の情報をもとに、企画から開発会社・サービスの選定までを扱います。各テーマの詳しい内容は、下の関連記事もあわせてご覧ください。
▼関連記事一覧
・Amazon DocumentDBのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・Amazon DocumentDBのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・Amazon DocumentDBのシステム開発の見積相場や費用/コスト/値段について
・Amazon DocumentDBのシステム開発の発注/外注/依頼/委託方法について
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Amazon DocumentDBのシステムの概要
Amazon DocumentDBのシステムは、画面、業務API、認証・連携処理、データベースで構成します。
監視やバックアップなどの運用サービスも組み合わせて、一つのシステムとして動かします。
DocumentDBは、顧客・案件・活動・イベントを保存し、業務アプリケーションを支えるデータベースです。
CRMやMAとしての機能は、画面やAPIを含むアプリケーション側で実現します。
JSONドキュメントを扱うフルマネージド型データベース
DocumentDBはMongoDB互換のドキュメントデータベースで、項目が増えやすい顧客情報も扱えます。
- 開発環境：MongoDB用のドライバー、API、開発ツールをそのまま使える
- 可変データ：顧客プロフィール、問い合わせ、商談進捗、フォーム送信、メール開封、Web閲覧は、後から項目が増えやすい
- 機能差：「MongoDB互換」と聞いても、演算子、集計、インデックス、トランザクション、シャーディング、管理用DBなどに違いがある
- 採用前の確認：既存のクエリを一覧にし、代表的なデータと負荷でPoCを行うと、後からの手戻りを抑えられる
表を細かく分けると、画面表示のたびに結合が増えます。そのため、顧客・案件ごとに関連情報をまとめて読む設計では、ドキュメント形式が候補になります。
営業・CRM・MAの可変データとの相性
項目や量が変化するシステムでは、DocumentDBが候補になります。代表的なのは次のようなデータです。
- 属性が異なる顧客情報：企業ごとに、持つ項目そのものが変わる
- 接点イベント：活動や行動の記録が、時系列に沿って増えていく
- 追加項目の多い業務：将来、項目を追加する場面が見込まれる
企業ドキュメントには、担当者、契約状態、利用機能、最新接点の要約を持たせる構成が考えられます。
活動イベントは別ドキュメントに蓄積でき、変更通知には変更ストリームとLambdaなどを組み合わせられます。
複雑な全社集計や会計処理、表形式データとの結合が中心の業務なら、RDBが適する場合があります。
RDBを主データベースにして、DocumentDBをイベントストアやプロフィール領域に限る方法もあります。
データの形だけでなく、検索・更新・集計のパターンも見て判断します。DocumentDBの用途や仕組みを把握したうえで、業務要件に合うかを検討します。
Amazon DocumentDBのシステムの構成・種類
構成は、データを保持するクラスターボリュームと、処理能力を担うインスタンスに分けて考えます。
稼働方式はProvisionedまたはServerless、料金構成はStandardまたはI/O-Optimizedから選びます。
二つは、ワークロードと運用方針に合わせて組み合わせます。
クラスターボリュームとインスタンスの役割分担
ストレージと処理能力の役割を分けて見ると、読み取りの設計も組み立てられます。
- 共有ストレージ：複数のアベイラビリティーゾーンにまたがり、3ゾーンに6つのデータコピーを保持
- 容量：1つのクラスターボリュームに、最大128TiBまで保存できる
- インスタンス：プライマリが読み書きを担い、レプリカが読み取りを分担する
- 読み取り拡張：レプリカを最大15台まで追加できる
AWS公式資料では、検索やダッシュボードの読み取りをレプリカへ分散できると説明されています（出典：AWS公式ドキュメント「Amazon DocumentDB の仕組み」、2026年確認）。
この構成では、ストレージ容量とコンピュート性能を別々に考えられます。
レプリカの読み取りは、結果整合性になる場合があります。そのため、書き込み直後に最新値が必要な画面では、プライマリを読むか、整合性の要件を定めておく必要があります。
発注側は、仕様書に画面ごとの読み取り先、許容遅延、ピーク時の同時接続数を書いておきます。
ProvisionedとServerlessの選び分け
稼働方式は、アクセスの安定性や変動幅を基準に比べます。
- Provisioned：インスタンスクラスを常時確保しておく方式
- Serverless：DCUを単位に、容量が増減する方式
Provisionedは、安定した本番業務や一定性能が必要な検索基盤、予測可能なバッチ処理に向きます。一方、Serverlessは検証環境やキャンペーンなど、負荷が変動するシステムで候補になります。
DocumentDB Capacity Unit（DCU）は、Serverlessの容量単位です。AWS公式料金ページでは、0.5 DCUから開始し、需要に応じて自動調整すると説明されています（出典：AWS公式料金ページ、2026年確認）。
ピーク容量を常時確保する場合と比べると、最大90%のコスト削減が訴求されています。ただし、この削減率は保証されないため、最低・最大容量、稼働時間、急な負荷上昇を実測して確かめます。
I/Oと読み取りレプリカ数も含めて、予算と性能の上限を設定します。
営業日の日中に負荷が増える場合は、時間帯別のメトリクスで評価します。
StandardとI/O-OptimizedのI/O比率による比較
料金構成と利用状況を照らし合わせ、両方式の見積もりを比べます。
- Standard：インスタンス、ストレージ、I/O、バックアップの4要素を支払う方式
- I/O-Optimized：I/O料金は個別に請求されず、I/Oが多い構成や請求予測を重視する構成に向く
- 比較の目安：I/O費が総額の25%を超えると予想されるなら候補（出典：AWS公式料金ページ、2026年確認）
25%は目安で、切り替えを自動的に決める基準ではありません。
アクセス、転送、保管期間、配置ゾーンも総額に影響するため、併せて見ます。
AWS Pricing Calculatorで、同じデータ量、稼働時間、I/O量を設定して両方式を試算します。また、開発環境と本番環境は分けて見積もります。
Amazon DocumentDBのシステム開発の進め方
開発は業務目的を起点に、データモデルと互換性を固めてから、非機能要件と移行計画を具体化します。
CRMやMAでは、使われない入力項目が増えるほどデータ品質が下がります。そのため、分析や自動化を後から加えても、成果につながらない場合があります。
開発では、現場の最小入力と、管理者が必要とする情報を分けて設計します。
要件定義とPoCでのDocumentDBの必然性の確認
要件定義では、データの種類と件数、検索や保存の条件を洗い出します。
- データ：扱う対象は、顧客、企業、担当者、商談、活動、イベントです
- 規模：1日あたりの登録件数と、ピーク時の同時接続数
- 運用条件：業務の流れから見た検索条件、保存期間、削除条件
RDB、既存MongoDB、DocumentDB、DynamoDBは、読み書きの頻度や結合の数で比べます。項目の変化や運用体制も見ておき、「AWSにあるから」という理由だけで採用を急がないようにします。
PoCでは、CRUDに加えて検索や集計の処理を試します。特に、一覧検索、複合条件、並び替え、ページングは、画面の動きを左右するので丁寧に確かめます。さらに、同時実行、バックアップ復元、障害時の切り替えも確認します。
MongoDBから移行する場合は、APIと集計パイプラインを一覧にして洗い出します。インデックス、トランザクション、変更ストリームも同じように確かめます。互換性は、そのまま使えるもの、修正が必要なもの、代替設計が必要なものに分け、見積もりの前提にします。
データモデル・API・AWS基盤の設計
画面、API、AWS基盤を設計する際は、読み書きの単位と接続方法をそろえておきます。
- データ配置：一緒に表示するプロフィールは埋め込み、更新頻度や件数が違うイベントは別コレクションで参照する
- 分割・索引：巨大なドキュメントは画面の読み出しと更新の単位で分け、インデックスは実際のクエリを根拠に決める
- アプリ構成：Reactなどの画面、Node.js・Java・PythonなどのAPIに、認証や非同期処理、ログ、監視を組み合わせた構成
- 接続管理：DocumentDBはVPC内に置いて実行基盤からだけ通し、認証情報はSecrets Managerなどで保管します
- IaC：ネットワーク、セキュリティグループ、パラメータ、監視設定をコードで再現し、環境差や引き継ぎ時のリスクを減らす
巨大なドキュメントは、更新の競合や読み取り量を増やします。また、インデックスを増やしすぎると、書き込みコストや更新時間に影響します。
テスト・段階移行・リリースの一連の流れ
リリース前に、機能と非機能の両面からテストします。
- 性能・可用性：負荷、遅延、障害復旧、レプリカラグを確かめる
- セキュリティ：権限の設定、暗号化、監査ログの取得状況
- 復旧：バックアップからの復元、RTOとRPO、切り戻しの条件
読み取りレプリカを使う場合は、書き込み直後の表示や集計遅延を実データで確認します。また、許容停止時間と切り戻しの条件はテスト計画書に記し、担当者の経験だけに頼らないようにします。
移行は、全件コピーと差分同期の後に照合を行い、リハーサルを重ねてから段階的に切り替えます。切り戻しも同じ流れで検証します。
AWS DMSを使う場合でも、コレクションやインデックスに加えて、ユーザー権限と非対応機能を個別に確認します。
AWSの導入事例では、120TBの文書データを3週間でダウンタイムなく移行しました。同事例では、文書データベース費用が20%減り、クエリ性能が95%改善しました。ただし、これは大規模サービスの事例で、一般案件の成果を保証する数字ではありません（出典：AWS公式導入事例、2026年確認）。
Amazon DocumentDBの費用相場
費用は、DocumentDBのAWS利用料と、開発・移行・保守の費用に分けて考えます。
AWS利用料だけで予算を組むと、API開発やデータ整備、負荷試験の費用が加わり、予算を超えやすくなります。そのため、監視、教育、既存連携も含めて、金額は初期検討用の概算として見ます。
金額は、リージョンや為替、データ量によって変わります。さらに、ピーク負荷や機能数でも変わります。
▶ 詳細はこちら：Amazon DocumentDBのシステム開発の見積相場や費用/コスト/値段について
AWS利用料の内訳：インスタンス、I/O、ストレージ、バックアップ
AWS利用料は、インスタンスやI/O、保存、バックアップの条件によって変わります。
- 基本料金：インスタンス、データベースI/O、ストレージ、バックアップが対象（出典：AWS公式料金ページ、2026年確認）
- 検証環境：単一インスタンス、少量データ、限定稼働なら、DocumentDB単体で月3万〜10万円程度から
- 小規模CRM・MA：冗長化した2〜3インスタンスを想定した場合、AWS全体で月15万〜50万円程度
- 大規模利用：大きなアクセス、グローバル構成、長期バックアップがあると、月50万円を超える場合があります
両方式を比べる際は、I/O課金の扱いを含めて見ます。一方、ゾーン間転送、CloudWatch、実行基盤、サポート契約は料金ページの外です。
AWS利用料の金額は、AWS料金例と小規模構成をもとにした概算で、確定した見積もりではありません。
PoCから大規模移行までの開発費の幅（500万円未満から数億円まで）
開発費は、インスタンス費よりも工数に左右されます。作業の範囲は、画面や連携、移行などで大きく変わります。下の金額は、初期検討用の推定レンジです。
- PoC：互換性と性能の確認に100万〜300万円
- 小規模：顧客、案件、活動の管理に500万〜1,500万円
- 中規模：CRM/MA連携を伴う場合の1,500万〜5,000万円
- 大規模：5,000万円から数億円になる場合があります
大規模案件では、複数拠点や基幹連携に加えて、複雑な権限、数千万件以上の移行、DRを含みます。
期間の目安は、PoCが1〜2か月、小規模が3〜6か月、中規模が6〜12か月です。大規模な移行や定着化は、12〜24か月以上かかる場合があります。
見積もりは工程ごとに分けて比べます。要件定義、設計、開発・単体テストに加えて、次の2つも金額の内訳に入れます。
- 結合・総合テスト
- 移行・教育
保守・改修費は、開発費の年10〜20%程度を初期の目安として置きます。エンジンのアップグレードと互換性検証も、保守計画に含めておきます。
エンジンバージョンと運用費のTCOへの織り込み
2026年時点では、エンジン版のサポート期限も費用に関わります。そのため、性能評価やログ保管を含めて運用費を見積もります。
- 3.6のサポート：標準サポートは2026年3月30日に終了しています
- 旧版の継続：追加料金やセキュリティ更新の条件を確かめ、更新時には互換性テスト、改修、リハーサルの費用を計上する
- 8.0の性能情報：クエリレイテンシー最大7倍、圧縮率最大5倍、ベクトルインデックス構築最大30倍の改善が案内されています
- 8.0の評価：Serverlessが使えるかどうかも、検討材料に含めます
- 長期運用：増加時の保管先、監視担当、障害対応時間、定期改善を含めた3年程度のTCO
AWSは最大3年間のExtended Supportを案内しています（出典：AWS公式「DocumentDB 3.6のExtended Support発表」、2025年）。Serverlessも8.0で利用可能です（出典：AWS公式「Amazon DocumentDB ServerlessがDocumentDB 8.0で利用可能になった発表」、2026年）。
新規開発では、利用可能なリージョンとドライバーを確かめておきます。性能改善の公表値は見積もりにそのまま使わず、代表的な負荷で検証します。
行動ログを無期限に保存すると、ストレージとバックアップが膨らみます。そこで、TTLやアーカイブを設定し、分析用データをS3などへ移す方法を検討します。
Amazon DocumentDBのセキュリティと運用の確認事項
マネージドデータベースを使うことと、企業のセキュリティ要件を満たすことは、別に確かめる必要があります。
セキュリティは、ネットワークや認証、権限、暗号化の設計に加えて、監査、バックアップ、復旧訓練まで含めて考えます。さらに、アプリと運用手順も含めて、個人情報保護法などへの適合を別途確認します。
VPC・TLS・IAMによる接続経路と権限の分離
接続経路と利用者の権限、認証情報、暗号化の設定は、それぞれ別に確かめます。
- ネットワーク：VPC内に配置し、インターネット接続は避けたうえで、通信元をサブネットとセキュリティグループで限る
- 権限：画面利用者、API実行者、管理者を分け、営業担当者が全顧客情報を見られる状態を避ける
- 認証情報：ソースコードや環境変数に平文で置かず、Secrets Managerなどで管理する
- 保護の仕組み：通信はTLS、保存時はKMSを使い、保存データ、インデックス、ログ、バックアップ、スナップショットをAES-256で暗号化できる
DocumentDB 8.0ではTLS 1.2以上が必要です（出典：AWS公式ドキュメント「Security in Amazon DocumentDB」「Encrypting data at rest」、2026年確認）。
ドライバーや証明書を更新する手順を決めておき、開発、検証、本番の各環境で接続テストを行います。
バックアップ・監視・復旧の実地確認
バックアップがあるかどうかだけでなく、復旧手順と監視の担当範囲も、実地で確かめておきます。
- 復旧手順：保持期間、ポイントインタイムリカバリ、スナップショット、別リージョン退避、接続先変更を決めたうえで、復元テストを行う
- 復旧目標：RTOが30分か4時間かによって、レプリカ、切り替え、運用当番の設計が変わります
- データベース監視：CPUやメモリ、接続数、遅延、レプリカラグ、ストレージ、I/O、エラー率、バックアップの成否
- アラート対応：CloudWatchのメトリクスとログを結び、一次切り分けを担当する人と時間帯を決めておく
- イベント処理：変更ストリームの取りこぼしや重複実行、再試行、保留キューの状況
復元テストは、リリース前と定期運用で実施します。
データ品質とガバナンスの業務運用への組み込み
入力ルールが自由すぎると、企業名の揺れや重複顧客、古い担当者、商談ステータスの欠損が増えていきます。そのため、柔軟性を業務の価値につなげるには管理が欠かせません。
AIのリードスコアリングや自動配信を加える前に、次のルールを整えておきます。
- 入力管理：必須項目、マスタ、重複判定の基準
- 追跡：誰が更新したかと、変更履歴
- データ処理：削除や匿名化のルール
委託する場合は、設計書やIaCなどを契約で定めておきます。対象には、テスト仕様書、移行手順、運用Runbookも含めます。
ソースコードの納品範囲も、あらかじめ明確にしておきます。曖昧なままだと、担当が交代した後の障害や改修で調査費が重なります。
システムの所有権と運用責任は、発注の前に確認しておきます。
Amazon DocumentDBの開発会社・サービスの選び方
発注先は、AWSの経験だけでなく、互換性検証、業務アプリ開発、移行、セキュリティ、運用を見て比べます。
データベースの構築だけを任せるのか、画面やAPI、既存CRMとの連携まで任せるのかで、体制と見積もりが変わります。そのため、同じ要件書を候補先に渡して、作業範囲と前提をそろえて比べます。
互換性検証と移行実績の確認
互換性検証と移行実績は、調査の内容や成果物、業務への理解から確かめます。
- 互換性調査：API、演算子、集計、インデックス、トランザクションを調べ、非対応機能の代替案と改修工数、性能への影響を示せる
- PoC成果：互換性マトリクスの提示を受け、成功条件と失敗時の追加費用について尋ねる
- 移行実績：データ量、停止時間、照合方法、切り戻し、インデックス移行、移行後の性能測定の実績
- 業務理解：既存MongoDBの移行か新規開発かに応じた知見があり、CRMやMAの入力負担、権限、連携も理解している
「MongoDB互換なので移行できます」という説明は、検証結果や移行実績と合わせて受け止めます。
見積もりの範囲と成果物のそろえ方
見積書では、工程と成果物を分けて書き、費用の前提をそろえておきます。
- 作業範囲：要件定義、設計、API・画面、AWS基盤
- 品質・移行：テスト、移行、教育、運用の引き継ぎ
- 運用条件：AWS利用料、監視、障害対応の時間帯
AWS利用料が別に請求されるか、Serverlessやレプリカがどの前提で入っているかを確かめます。見積もりが安いほど、含まれていない作業を明示してもらうと、比較がずれにくくなります。
成果物には、要件定義書、設計書、データモデル、クエリ・インデックス設計があります。加えて、IaC、テスト結果、移行リハーサルの記録、復元手順、運用Runbook、ソースコードも確認します。
保守契約では、問い合わせ窓口や初動時間、復旧目標、更新対応、追加改修の単価を定めておきます。どこまでを誰が受け持つかも、契約後ではなく提案の段階で比べられるようにします。
開発後の運用体制と定着支援
委託先が開発後に担う運用と、現場への定着支援の中身を確かめます。
- 技術運用：蓄積されたデータに応じて、クエリ、インデックス、ストレージ、バックアップを見直す
- 保守担当：月次コスト、性能、脆弱性、証明書、エンジン更新、障害訓練の担当者
- 時間外対応：夜間や休日の監視、一次対応、復旧判断をどこまで任せるか
- 定着支援：業務に沿った画面、適切な入力項目、データ品質の確認、必要な期間の技術・業務支援
研修の後も、利用率や必須項目の充足率、重複率、商談更新の遅れを定期的に確認します。
▶ 詳細はこちら：Amazon DocumentDBのシステム開発でおすすめの開発会社/ベンダー6選と選び方
▶ 詳細はこちら：Amazon DocumentDBのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
▶ 詳細はこちら：Amazon DocumentDBのシステム開発の発注/外注/依頼/委託方法について
よくある質問（FAQ）
採用判断、MongoDBからの移行、開発費と運用費に関する疑問に、順に答えます。
Amazon DocumentDBとRDBはどちらを選ぶべきですか？
項目が増減するJSONを顧客や案件の単位で読むなら、DocumentDBが候補になります。一方、複雑な結合や会計処理、横断集計が中心なら、RDBが候補になりやすいです。
主要なクエリとトランザクションの要件で比べると、業務の正本とイベントデータを分けて併用する方法もあります。
MongoDBからAmazon DocumentDBへ移行できますか？
移行はできますが、無変更で移せるとは限りません。AWS DMSや移行ユーティリティを使える一方で、API、演算子、インデックス、トランザクションには機能差があります。互換性を調べ、負荷試験やデータ照合、切り替えのリハーサルを行ったうえで、修正箇所と停止時間を見積もります。
小規模なAmazon DocumentDBシステムはいくらから作れますか？
技術検証は100万〜300万円、業務画面とAPIを含む小規模な新規開発は500万〜1,500万円程度が初期の目安です。金額は、画面数や連携数に加えて、移行、権限、性能要件、テスト範囲によって変わります。
AWS利用料や保守、監視、教育は開発費とは分けて、複数社で前提をそろえて比べます。
Serverlessを選べば必ず安くなりますか？
Serverlessを選んでも、必ず費用が下がるわけではありません。
- 費用低減の可能性：負荷が変動する場合、Provisionedより費用を抑えられることがある
- 比較条件：最低・最大DCU、稼働時間、I/O、レプリカ、データ転送を含める
- 上限確認：実際のアクセスで負荷試験を行い、AWS Pricing Calculatorでも月額上限を確認する
まとめ
Amazon DocumentDBは、変化しやすい顧客情報や商談、活動履歴、行動イベントをJSONで扱えるデータベースです。AWSのマネージドなストレージやバックアップ、監視、可用性も利用できます。
クラスターボリュームとインスタンスの役割を押さえたうえで、ProvisionedとServerless、StandardとI/O-Optimizedを負荷に合わせて選びます。
PoCで互換性・性能・費用を確かめてからの採用判断
採用の前に、主要なクエリや必要な性能、データ移行、3年程度のTCOをPoCで確かめておきます。個人情報を扱う場合は、VPCやIAM、TLS、KMSなどの仕組みに加えて、監査、復元、権限の分離を要件に含めます。
現場が入力を続けられる業務フローまで設計してはじめて、データ基盤が成果につながります。
要件書に記載する項目
相談や見積もりの前に、要件と費用の比較条件をそろえておきます。
- データ・負荷：件数の見込みと増加率、ピーク時の同時接続数、主要なクエリ
- 接続・復旧：MongoDBの版、連携先、RTO・RPO、許容停止時間
- 管理条件：個人情報の区分と、必要な保持期間
- 費用範囲：開発、AWS利用料、移行、テスト、教育、保守を別々に比べる
条件をそろえておくと、価格だけでは見えないリスクも検討の対象に入ります。
DocumentDBの開発では、データと業務の将来像を実装できる設計に落とし込みます。
費用の前提をそろえて比べると、価格に含まれていない作業範囲が見えてきます。DocumentDBの開発範囲は、要件定義から移行・保守まで含めて検討します。
▼関連記事一覧
・Amazon DocumentDBのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・Amazon DocumentDBのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・Amazon DocumentDBのシステム開発の見積相場や費用/コスト/値段について
・Amazon DocumentDBのシステム開発の発注/外注/依頼/委託方法について
▼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を創業。