Amazon ElastiCacheのシステム開発の発注/外注/依頼/委託方法について

Amazon ElastiCacheの発注は、現状分析、PoC、設計・実装・試験、本番化の順に進めると、性能とデータ鮮度を確かめながら導入できます。目標や対象データを決めないまま発注すると、要件が足りないまま進みやすく、追加費用や納期延長も起きやすくなります。

▼全体ガイドの記事
・Amazon ElastiCacheのシステム開発の完全ガイド

Amazon ElastiCacheのシステムを発注・外注する前に知っておきたい全体像

アプリケーションとAmazon RDS・Amazon Auroraの間に置かれたElastiCacheを示す図解
キャッシュ層を原本データベースの手前に置く構成です。

Amazon ElastiCacheは、マネージドなインメモリデータストアで、アプリケーションとAmazon RDSやAmazon Auroraなどの間に置きます。よく参照するデータを一時保存し、DBへの読み取り回数や応答時間を抑えます。

発注範囲は、AWSコンソールでキャッシュを作ることだけでなく、保存・削除の条件や障害時の戻し方をアプリへ組み込む作業まで含みます。

キャッシュと原本データベースの役割分担

業務データの性質によって、キャッシュするものと原本DBで確定するものを分けて考えます。

  • キャッシュ候補:顧客一覧、ログインセッション、集計、リードスコア、API制限。
  • 原本で確定:契約状態、請求金額、在庫、権限など正確性が必要な情報です。表示にはキャッシュを使えても、更新・確定時は原本DBで確認します。
  • 有効期限と削除:TTLだけで済むか、更新時に明示的な削除が必要かを業務担当者と決めます。

AWS公式のJuspay事例では、Auroraの前段にElastiCacheを置き、通常時の最大10倍のトラフィックや最大5万TPSを扱ったと紹介されています。

また、複数リージョン・複数AZで99.99%のインフラ稼働率を維持した個別事例です(出典: AWS公式Juspay事例、2026年確認)。ただし、これは他社の事例で自社の数値を保証するものではないため、ピーク時の吸収層や可用性をRFPへ落とす際の参考として使います。

導入を急ぐ企業と急がない企業の区別

アクセスピークが明確で、同じデータを繰り返し読むためRDSやAuroraの負荷が高い企業は、検証効果を見込みやすいです。

一方で、遅さの原因が未整理のSQL、ネットワーク、外部API、画面処理にある場合は、先に計測して原因を切り分けます。計測しないまま進めると、問題を隠したり、古いデータを速く表示したりするおそれがあります。

発注先には、導入前後のP95・P99レイテンシー、DB負荷、ヒット率、データ鮮度を測る計画も求めます。

Amazon ElastiCacheの発注形態の選び方

発注形態は、目的と社内の技術体制で決めます。要件がまだ固まらない場合は、現状分析とPoCを先に進め、効果と構成を確かめてから本番開発へ移ると、失敗を抑えやすくなります。

新規開発、既存CRMの改善、24時間運用では、必要な支援範囲が変わります。そのため、目的に合う委託形態を選びます。

  • 小規模PoC:効果や対象データが不明な段階で、小さく検証する形式。
  • 一括外注:アプリ、DB、AWSを一体で改修する形式。
  • 運用保守委託:監視や障害対応の社内体制を補う形式。

まず小規模なPoCだけを外注する方法

キャッシュ対象や効果が不明な場合は、代表的な画面やAPIから対象を選び、2〜6週間程度のPoCを委託します。

成果物には環境だけでなく、キー設計、TTL、無効化ルールを含めます。また、負荷試験、導入前後のP95・P99、DBのCPU・接続数、障害時のフォールバック確認も対象に入れます。

AWSは2025年1月から、EC2とElastiCacheの接続設定をコンソールで簡素化する機能を案内しています。ただし、接続できることと、安全に業務で運用できることは別です(出典: AWS公式、2025年)。

アプリ・データベース・AWSを一体で外注する方法

AWS設定だけを別の会社へ頼むと、どこまでを誰が受け持つかという責任分界が複雑になります。既存アプリへ組み込む場合は、同じチームへ一括で委託するほうが進めやすいです。

対象範囲には、アプリ改修、RDS・Auroraのクエリ分析、VPC・Security Groupを含めます。さらに、IaCやCI/CDに加えて、監視と負荷試験も対象範囲に入ります。

キャッシュミス時のDBアクセスについては、タイムアウト、リトライ、サーキットブレーカーとあわせて、実装の責任も記します。

構築後の監視・保守まで委託する方法

本番環境を社内だけで監視できない場合は、構築と運用保守を分けずに依頼します。通知を受けてから一次切り分けを始める時間も定めます。

  • 監視項目:メモリ、CPU、接続数、ヒット率、Evictions、レイテンシー、レプリケーション遅延。
  • 24時間対応:時間外の担当者と連絡先、復旧手順、AWS問い合わせ、月次報告を決めておく。

運用を委託しても、業務上どのデータを止めてよいかを判断する責任は発注者側に残ります。

ポイント

効果や対象データがまだ不明な段階では小規模PoCから始め、アプリとAWSの改修をまとめて頼みたいなら一括外注を選びます。本番の監視を社内で回せない場合は、運用保守を別に委託して体制を補います。

Amazon ElastiCacheの発注・外注を進める手順

現状分析、キャッシュ要件の整理、PoCから本番化へ進む流れを示す図解
目標とデータの扱いを決めてから検証へ進む順序です。

相談の前に現状と目標を整理し、各候補へ同じ情報を渡すと、比較の条件がそろいます。一方で、要件が足りないと、追加費用や納期延長が起きやすくなります。

技術要件と業務判断は、次の順で固めます。

  1. 現状分析:課題と測定目標の整理。
  2. キャッシュ要件:対象データと鮮度・更新ルールの決定。
  3. PoCから本番化:検証、実装、試験を経て、段階的に移行する。

現状分析と導入目的の整理

遅い画面やAPI、対象データ、利用者数、通常時・ピーク時のリクエスト数を確認します。加えて、DBのCPU、接続数、遅いクエリも調べます。

顧客一覧、ログイン集中、集計処理など、対象によって設計は変わります。目標は「高速化」のような言葉で止めず、検索APIのP95やピーク時DB CPUの上限で測れる形にします。

キャッシュ停止時にも注文処理を継続するといった業務上の目標を、発注側で定めます。

キャッシュ対象と業務ルールの決定

キーと値の形式、TTL、最大容量を決めるほか、古い値をどこまで許容するかも決めます。キャッシュする範囲は、顧客情報全体よりも、短期セッションや検索結果の識別子に絞れるかを検討します。

更新時には、キャッシュを先に削除するか、原本の更新後に再生成するかを決めます。TTLに加えて明示的な無効化が必要なデータも、区別しておきます。

表記揺れや重複した顧客マスタを放置すると誤データを速く返すため、データ品質もRFPの前提に含めます。

PoC、設計、実装、試験、本番化の順序

PoCのあとは、方式選定から移行までを次の段階に分けて進めます。

  • 方式選定:キャッシュの候補と可用性構成の比較。
  • 実装:アプリのキャッシュ処理と障害対策の組み込み。
  • 試験:通常負荷、障害、データ復旧の確認。
  • 本番移行:運用準備が整ったあと、トラフィックを段階的に移す。

代表的なAPIで小さく試したあと、Valkey・Redis OSS・Memcachedのどれを使うか、Serverlessとノードベースのどちらにするかを選びます。そのうえで、Multi-AZやレプリカの構成も決めます。

アプリ側には、読み書き、タイムアウト、リトライの処理を実装します。加えて、DBフォールバックとキャッシュスタンピード対策も組み込みます。

試験では、ピーク負荷と全キー消失を確かめます。ノード・AZ障害、更新直後の読み取り、バックアップ復旧も確認します。最後に、Runbookと監視アラームを整えます。

ポイント

要件がまだ固まらないなら、現状分析とPoCを先に進め、効果と構成を確かめてから本番開発へ移ります。要件が足りないまま発注すると、追加費用や納期延長の原因になります。

RFP・要件整理に書く内容

RFPは、各社の提案を同じ条件で比べるための資料です。背景と範囲、性能と鮮度を共通化し、そのほかの項目も同じ形式でそろえます。完全な設計書は不要ですが、譲れない業務条件と提案会社に検討してほしい条件は分けて書きます。

背景・対象業務・利用量の具体化

困っている画面や業務と、導入しない場合の影響を書きます。対象業務には、顧客検索、セッション、案件一覧を挙げます。スコアリング、ランキング、レート制限も対象業務として書き、対象外の処理も明示します。

利用量は、データ容量、平均・最大リクエスト数、読み書き比率を、可能な範囲で記載します。ピーク時間、データ増加量、同時接続数も同じように書きます。実測値がなければ推定と明記し、PoCで測る項目を示します。

非機能要件とセキュリティ条件の明記

性能に加えて、可用性、RTO・RPO、許容できるデータの古さを指定します。障害時の継続と対応時間、ログ保存期間も決めておきます。さらに、バックアップ、リージョン、個人情報の扱いも書き込みます。

プライベートサブネット、Security Group、TLSを必須にするかを判断します。保管時暗号化、IAMまたはAUTH、RBACも検討の対象です。Secrets管理とIaCの扱いも、あわせて決めます。

条件を満たす構成図と、満たせない場合の代替案も提案してもらいます。

納品物・評価基準・見積の分け方の指定

成果物、受入条件、費用内訳は、それぞれ分けてRFPに記載します。

  • 納品物:設計、コード、試験、運用資料の範囲。
  • 受入基準:性能と復旧を測定できる条件。
  • 見積内訳:工程別費用とAWS利用料を分けて、出してもらう。

納品物には要件定義書と構成図、パラメータを含めます。TerraformやAWS CDKなどのIaCも対象です。

アプリのソースやテストの仕様・結果も対象です。監視設計とRunbookのほか、障害訓練記録と引き継ぎ資料も対象に入ります。

受入基準は、構築が完了したかだけでなく、目標APIのP95やDB負荷で判断できるように定めます。データ鮮度、復旧時間、バックアップ復元も、同じ基準で測ります。

見積もりは、要件定義、PoC、改修、AWS構築の工程ごとに分けます。性能試験、移行、保守、AWS利用料も、それぞれ別に見積もります。

請負・準委任・ラボ型の契約形態の選び方

要件が決まった部分と検証しながら決める部分が混在しやすいため、工程別に契約を分けるのが実務的です。要件定義とPoCは準委任、本番構築は請負、運用保守は準委任またはサービス契約とします。

契約名だけでなく、成果物と作業範囲、責任の範囲を契約前に確認します。変更手続きや検収条件も、同じ時点で確かめます。

  • 請負:成果物と受入基準が固まった開発の場合の契約。
  • 準委任:調査、PoC、設計、継続改善を進める場合の契約。
  • ラボ型:一定期間チームを確保し、優先順位を見直しながら開発する場合の契約。

成果物と受入基準が固まった開発での請負契約

既存API連携と指定AWS環境、負荷試験報告、IaC、運用手順書などを納品します。そのうえで、P95や復旧試験を検収条件に入れられます。

発注後に対象を増やしたり、ノードベースからServerlessへ変えたりすると、追加費用が生じる場合があります。変更の承認者と、金額・納期の算定方法を決めておきます。

調査・設計・改善を進めながら決める開発での準委任契約

準委任は、専門家の作業や技術支援を受ける契約です。要件が変わりやすい現状分析やPoC、構成検討、継続的な性能改善で使われます。

作業時間や体制を基準にするため、成果物の完成責任や性能保証は、請負と同じようには期待できません。そのため、月次の作業や稼働時間、定例会を決めておきます。報告書、設計記録、未消化タスクの扱いも合意します。

継続的な開発体制を作る場合のラボ型・アジャイル型

ラボ型は、一定期間チームを確保し、優先順位を毎月見直す方式です。CRM機能の追加と性能改善を並行する企業や、利用状況を見て対象を広げる企業に適します。

発注者側には、優先順位を決めるプロダクト責任者が必要です。月額だけでなく、チーム構成と稼働時間を確認します。成果物の権利、品質管理、交代時の引き継ぎも、同じ場で見ておきます。

ポイント

請負は成果物と受入基準が固まった開発、準委任は調査や設計を進めながら決める部分に使います。契約名だけでなく、成果物や作業範囲、変更手続きを見て選びます。

Amazon ElastiCacheのシステム発注費用・料金相場

初期設定、標準導入、大規模対応の発注費推定レンジを比べる横棒図
導入範囲が広がるにつれて費用帯も上がります。

費用は、AWS利用料と開発会社への人件費・保守費を分けて考えます。一律の月額相場はなく、保存量、ECPU、ノードの数で変わります。さらに、リージョンやレプリカ、バックアップ、通信、利用時間によっても変わります。

ここで示す数字は、東京リージョンの確定見積もりではありません。AWS料金例と一般的なクラウド開発案件から作った、初期検討用の推定レンジです。

ServerlessとノードベースのAWS利用料の計算方法

利用料の見積もりでは、使用量に応じる方式とノード時間方式を区別します。

  • Serverless:保存量はGB時間、リクエストはECPUで計算。
  • ノードベース:オンデマンドノードの利用時間を基本にした計算。
  • Valkey:最低保存量100MB。ほかの対応エンジンより保存量の価格が33%低いと案内されています。

Valkeyは新規案件の候補ですが、Redis OSSとの互換性、ライブラリ、運用担当の経験を確認します(出典: AWS公式Amazon ElastiCache料金表、2026年8月確認)。

米国東部(バージニア北部)の例では、10GBを平均5万リクエスト/秒で使うServerless for Valkeyが1時間1.254米ドルです。730時間換算では、約916米ドル/月になります。

ピーク時に100GB、1秒あたり100万リクエストを想定した12ノード構成は、転送込みで1時間5.6552米ドルです。730時間の単純換算では、約4,128米ドル/月です。

いずれも特定条件での例です(出典: AWS公式料金表、2026年8月確認)。円換算や東京リージョンの請求額は確定できないため、AWS Pricing Calculatorに自社の条件を入力して試算します。

開発会社への発注費の範囲別見積もり

開発会社への発注費は、作業範囲ごとに初期検討用の推定レンジで把握します。

  • 初期設定:ElastiCache単体の設定と簡単な接続確認で、100万〜300万円程度。
  • 標準導入:本番運用まで含めて、300万〜800万円程度。
  • 大規模対応:複数リージョンなどを含む場合は、800万〜2,000万円以上のこともあります。

標準導入には、Web・CRM連携、IaC、CI/CDが入ります。さらに、監視、負荷試験、障害時のフォールバックも含めます。大規模対応には、自前Redisからの移行、厳格な監査、24時間運用などが加わります。

金額は公定価格ではなく、要件と工数による推定です。

期間は、現状分析とPoCで2〜6週間、標準導入で2〜4か月が目安です。大規模移行や高可用性設計では、4〜9か月程度になります。

営業・CRM・MA全体の一般的な案件相場では、小規模10万〜500万円、中規模500万〜5,000万円という整理もあります。

保守は初期開発費の年10〜20%という目安もあります。ただし、キャッシュ基盤だけの公定相場ではありません。

見積もりでは、要件定義と実装、試験を分けたうえで、AWS利用料と保守費も別に見積もります。

見落としやすい追加費用

追加費用は、構成や運用条件に応じて発生します。見落としやすい項目を、分けて確認します。

  • 構成・通信:レプリカ、Multi-AZ、AZ間・リージョン間の転送。
  • 監視・試験:バックアップ、CloudWatch、負荷試験環境、AWS Support。
  • 運用・更新:夜間休日対応と、古いRedis OSSの更新費用。

AWS公式料金表では、バックアップ保存は1GiB月あたり0.085米ドルです。同一リージョンの別AZ転送では、EC2側に標準のリージョン内転送料金がかかります。

古いRedis OSSのExtended Supportは、通常料金に対して1〜2年目が80%、3年目が160%のプレミアムです。バージョンアップ費も見込んでおきます(出典: AWS公式Amazon ElastiCache料金表、2026年8月確認)。

ポイント

AWS利用料と開発費を分け、見落としやすい追加費用も含めて見積もります。金額は個別見積もりで確定させ、本文の数字は初期検討の目安として扱います。

Amazon ElastiCacheの委託先選定と見積比較のポイント

委託先は、AWSの初期設定だけでなく、アプリやDBを含めて一体で説明できるかで選びます。セキュリティや性能試験、運用まで説明できるかも確かめます。

「AWS対応」という表現から、更新漏れや障害時の雪崩を防げるかを読み取るのは難しいです。

同じRFPを複数社へ渡し、提案の前提と成果物をそろえて比べます。体制や費用、リスクも同じ条件で見ます。

ElastiCache・Valkey・Redisの実績の確認

AWS案件数だけでなく、何をキャッシュし、どの程度のリクエストを処理し、P95やDB負荷をどう改善したかを聞きます。

RDSやAuroraとの連携、ECSやEKSの経験を聞きます。Multi-AZやレプリカ、バックアップの経験も聞きます。IaCや負荷試験、DBフォールバックの実績も確かめます。

匿名化した構成や指標を説明できるか確認します。数値を出せない場合も、質問への回答の仕方を見ます。

見積もりの前提と作業範囲の粒度の統一

見積もりは、要件定義、設計、改修、AWS構築の工程ごとに分けてもらいます。テストや移行、監視、文書、教育、保守も同じ粒度で示してもらい、工数や期間、担当、前提を確認します。

AWS利用料を開発会社が立て替えるか、発注者アカウントへ直接請求するかも決めます。安い見積もりは負荷試験や運用設計を含まない場合があるため、除外項目を質問します。

運用体制・成果物・権利関係の契約前確認

本番後に自社で変更できるよう、AWSアカウントやソース、IaCの所有者とアクセス権を決めます。設定値、ログ、監視画面、手順書も同じ扱いにします。委託先だけが本番を操作していると、契約終了時の引き継ぎが難しくなります。

24時間監視では、対応時間、一次回答、復旧目標をSLAや運用契約に記します。障害報告や再発防止、第三者サービス費も、同じ契約に入れます。納品と協力義務を明確にしておくと、移管や追加開発を進めやすくなります。

ポイント

委託先は、AWS設定だけでなくアプリ、DB、セキュリティ、運用まで一体で説明できるかで選びます。見積もりは工程ごとに同じ粒度でそろえ、運用と成果物の所有者を契約前に決めます。

個人情報を扱うElastiCacheの外注で確認するセキュリティ

顧客情報や営業履歴を置く場合は、データの最小化と委託先の管理を、性能要件と並べて検討します。一時データであっても、バックアップやログ、スナップショットに残る可能性があります。

保存項目、期限切れ、顧客削除や利用停止時の削除経路を、業務・法務・セキュリティの担当者と確認します。

TLS・暗号化・認証・権限分離の確認

AWSの資料では、Valkey・Redis OSSの転送中と保管時の暗号化、IAMやAUTH認証、RBACによる権限制御が案内されています(出典: AWS公式「Data security in Amazon ElastiCache」、2026年確認)。

TLSに加え、接続元をSecurity Groupで絞り、開発者・運用者・アプリの権限を分けます。認証情報をソースやログへ出さないよう、Secrets管理とローテーションの担当も決めます。

委託先の監督と漏えい時の連絡の契約条項

委託先の選定、再委託の条件、アクセス権は、契約に含めます。ログ確認、事故報告の期限、削除・返却、監査協力も、同じ契約で定めます。

個人情報保護委員会の通則編ガイドラインは2026年6月に一部改正され、安全管理、委託先監督、漏えい時の報告・本人通知を示しています(出典: 個人情報保護委員会、令和8年6月一部改正)。

適用の判断は法務等へ確認し、開発会社には実装・運用の協力を具体的に依頼します。

障害時にキャッシュを使わず業務を続ける設計

停止時に無限リトライやDBへの一斉アクセスが起きると、障害が広がります。そのため、タイムアウトを短くし、再試行を制限する設計が必要です。

キャッシュなしで原本DBへ戻す処理と、重要処理を止める処理は分けておきます。全キー削除やノード障害を試し、遅くても使える画面と止める処理を、業務担当者が判断できるRunbookにまとめます。

Amazon ElastiCacheのシステム発注・外注に関するよくある質問

費用、委託範囲、導入後の運用者、障害時の復旧方法は、発注のたびに確認されがちな項目です。

Amazon ElastiCacheのシステム発注費用はいくらですか?

初期設定のみは100万〜300万円程度、既存アプリ連携・IaC・監視・負荷試験込みの標準導入は300万〜800万円程度が推定レンジです。

大規模移行、複数リージョン、厳格な監査込みでは800万〜2,000万円以上の場合があります。AWS利用料は別途かかり、保存量、リクエスト、ノードによって変わります。加えて、レプリカ、通信、バックアップでも額が変わります。

確定金額ではありません。RFPの範囲と実測値をそろえて、個別見積もりを取得します。

ElastiCacheの導入はAWSに詳しい社員だけでできますか?

小規模検証なら、既存のAWS・アプリ・DBを理解する社員が進められる場合があります。

本番で個人情報を扱い、複数AZや障害時のフォールバックを使うなら、不足する領域は外注するほうが安全です。性能試験や24時間監視が必要な場合も、外注を検討します。

AWS設定だけでなく、データ鮮度やアプリのリトライまで担えるかを基準に、内製と委託の境界を決めます。

Valkey・Redis OSS・Memcachedの選定も開発会社へ任せられますか?

任せることはできますが、最終判断まで丸投げせず、比較の根拠を出してもらいます。

  • Valkey:新規開発の候補。
  • Redis OSS:既存との互換性と運用知識を確認。
  • Memcached:単純な揮発キャッシュへの適性。
  • 構成:Serverlessとノードベースを、アクセス変動や容量、可用性、Global Datastore、運用負荷、5年程度のTCOで比べる。

方式はPoCの実測を踏まえて選びます。

ElastiCacheに顧客情報を保存しても問題ありませんか?

一律に問題ないとはいえません。保存項目を識別子や短期間のセッション情報に絞り、TLSや保管時暗号化、認証、権限分離を設計します。さらに、ログ・バックアップ管理、削除連携、委託先監督も設計に含めます。

法令や社内規程への適合は、データや目的、委託先、保管場所によって変わります。開発会社だけで判断せず、法務・セキュリティの担当者へ確認します。

まとめ:Amazon ElastiCacheの発注における要件・契約・運用の分け方

最初に、改善対象と目標時間、許容するデータの古さを整理します。停止時の業務継続も、この段階で決めておきます。

PoCや要件定義、本番開発、監視・保守は、必要な範囲で委託します。AWS利用料と開発費は、分けて考えます。

発注前のRFPと比較基準の整備

RFPには、遅い処理や利用量、対象データを記します。加えて、TTLや更新ルール、性能目標を書きます。さらに、セキュリティ、納品物、運用体制も含めます。

Valkey・Redis・Memcachedの選定根拠、Serverless・ノードベースの料金前提を、同じ質問で比べます。

試験、障害時の戻し方、IaC・文書の納品範囲も比べ、将来の変更や委託終了を見据えます。

小さく検証してから本番へ広げる進め方

適切なデータを期限付きで扱うと、RDSやAuroraの負荷を下げ、顧客検索やセッションの応答を改善できる基盤になります。

要件を省いた導入や更新ルールを無視した構成は、費用と不整合を増やします。そのため、代表APIで効果を測り、鮮度やP99、DB負荷を確認します。復旧や月額TCOも確かめたうえで、必要な範囲を広げます。

▼全体ガイドの記事
・Amazon ElastiCacheのシステム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。