Cloud Runのシステム開発費用は、開発規模、周辺サービス、データ移行・運用の範囲によって、100万〜5,000万円超まで変わります。PoCなどの小規模な検証は100万〜300万円、基幹連携を含む高要件のシステムは2,000万〜5,000万円超が目安です。
▼全体ガイドの記事
・Cloud Runのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Cloud Runのシステムの構成と費用の決まり方
Cloud Runのシステムは、コンテナを実行基盤にして、Web画面、API、バッチ、データ連携を組み合わせた業務システムです。ただし、業務データをCloud Runだけで永続保存することはできません。
そのため、業務データの保存先には、Cloud SQL、Firestore、Cloud Storageを使います。さらに、分析や連携、ログ収集には、要件に応じてBigQuery、Pub/Sub、Cloud Loggingなどを組み合わせます。
Cloud Runは業務システムそのものではなく実行基盤
Cloud Runは、Dockerなどで作ったコンテナをGoogle Cloud上で動かす、フルマネージドの実行環境です。
公式資料は、Cloud Runの実行方法を3種類挙げています（出典: Google Cloud公式「What is Cloud Run」、2026年8月確認）。
- サービス：HTTPリクエストに応答する形式。
- ジョブ：処理が完了すると終了する形式。
- ワーカープール：常時稼働するバックグラウンド処理向けの形式。
見積もりでは、画面、API、保存先、ログ確認の担当を分けて記載します。Cloud Runでは、OSパッチやサーバー台数の管理は軽くできます。
一方で、業務ルールやデータ構造、権限の設計は残ります。障害復旧やバックアップの設計も残ります。
サービス・ジョブ・データ基盤の分け方と費用への影響
画面・API、夜間集計、データ保存先を分けて整理すると、機能の役割に合った構成を選べます。
- 画面・外部API：Cloud Runサービスで処理する部分。
- 夜間集計・帳票：Cloud Run Jobsで実行し、イベントはPub/Subで受け渡します。
- データ保存・分析：Cloud SQLやFirestore、Cloud Storage、BigQueryを使う部分。
サービスごとに、料金、バックアップ、権限、障害時にどこまでを誰が受け持つかが異なります。構成要素が増えるほど、設計・運用の費用も増えます。
長時間接続、複雑なネットワーク、特殊なGPU、細かなホスト制御が中心なら、GKEやCompute Engineが適する場合があります。
初期費用だけでなく、開発期間、運用担当者の人数、将来の移行しやすさも含めた総保有コストで比べます。
Cloud Runのシステム開発の進め方
Cloud Runの開発では、業務要件と非機能要件を整理し、小さな技術検証を挟んでから進めます。早い段階でDB接続や認証、負荷を確かめておくと、本番見積もりの不確実性を下げられます。ログやデータ移行も、同じ段階で確かめておきます。
要件定義で決める利用量・権限・復旧条件
まず、利用者と対象業務を決めます。そのうえで、1日あたりの処理件数、ピーク時間、同時利用者数を整理し、外部APIとの連携も確認します。
機密情報を扱う場合は、東京または大阪など国内リージョンが必要かどうかも決めます。
- 情報管理：保存期間と暗号化、監査ログ、委託先・再委託先を確認する。
- 復旧条件：RTO（目標復旧時間）とRPO（目標復旧時点）の設定。
- 発注者の準備：マスタや過去データ、業務フロー、承認者、受け入れ担当の整理。
RTOとRPOが決まらないと、Cloud SQLの可用性やバックアップ方式を選べず、月額費用も絞れません。マスタ整備や重複確認を発注者が担う場合もあります。そのため、担当者と準備時期を見積書や工程表に記しておきます。
PoCで確かめるコンテナ・DB接続・負荷
PoCでは、代表的な画面またはAPIを一つ選び、ビルドからログ出力までの接続を試します。Cloud SQLまたはFirestore、認証を含む構成で、処理が一連で動くかを確かめます。
- コンテナをビルドし、Artifact Registryへ登録する。
- Cloud Runへデプロイして、DB接続、認証、ログ出力を確かめる。
- 応答時間、同時実行数、コールドスタート、外部APIのタイムアウト、1日あたりの利用料を実測する。
検証期間は2〜6週間程度です。あわせて、PoCを本番開発の範囲に含めるか、別契約にするかも決めておきます。
業務データは、コンテナのローカルファイルに保存しません。インスタンスの停止やスケールイン時には、書き込み領域が永続化されないため、データは外部の永続ストレージに置きます（出典: Google Cloud公式「What is Cloud Run」、2026年8月確認）。PoCでこの原則を確かめておくと、データ消失や作り直しのリスクを抑えられます。
設計・開発・テスト・リリースの段階的な進め方
段階的に進めるには、環境の分け方から本番切替まで、次の5点を契約前に決めておきます。
- 環境分離：開発・ステージング・本番の分割。
- 設定の再現：TerraformなどのIaC（Infrastructure as Code）の利用。
- 自動化：GitHub ActionsやCloud Buildによる、テストとデプロイの自動化。
- 納品物：ソースコード、コンテナ定義、Terraform、設計書、運用手順。
- 本番切替：トラフィックを一度に切り替えず、段階的に移す。
IaCで再現するのは、Cloud Run、IAM、ネットワーク、監視設定です。そのうえで、承認者が本番反映を判断できるようにしておきます。判断の材料となるリリース時の確認条件は、契約前に整理します。
リリース前には、通常業務のシナリオや権限を試験します。さらに、負荷試験、障害試験、バックアップ復元の確認を行います。データ移行も、本番前にリハーサルしておきます。
段階移行では、エラー率と応答時間を見ながら切り替え、切り戻しの費用と事業への影響を抑えます。
Cloud Runのシステム開発費用相場と内訳
Cloud Run単体の日本向け開発費を示す公的統計は、確認できません。そのため、ここに示す金額は、類似の相場、想定工数、周辺サービスの設計範囲から組み立てた編集用の推定です。
特定の案件にそのまま当てはまる価格ではありません。比べるときは、要件・期間・体制をそろえます。既存資産やデータ移行の難易度も、合わせて見ておきます。
技術検証・小規模PoCの費用目安
PoCでは1サービスを対象に、簡易認証、最低限のログ、基本的なCI/CDを試します。
この検証では、Cloud SQLまたはFirestoreへの接続も確かめ、費用は100万〜300万円、期間は2週間〜2か月程度が目安です。
前提は、対象業務を一つに絞り、データ移行や24時間監視を本番同等に作り込まないことです。PoCで検証する仮説と、本番化で追加する機能は分けて見積もります。
小規模業務システムの費用目安
小規模業務システムでは、管理画面と業務APIを作り、ログインと権限を設定します。
Cloud SQLまたはFirestore、基本監視、1〜2回のデータ連携を含めると、300万〜800万円、2〜4か月程度を見込みます。
画面数やロール数、承認フローが増えるほど、バックエンドとテストの工数が増えます。帳票や外部APIの仕様が加わる場合も、同じように工数が増えます。また、要件定義を省いて画面だけを依頼すると、権限や例外処理が後から加わり、相場を超えることがあります。
中規模業務システムの費用目安
中規模では、複数のロールや業務領域、外部APIを扱い、Cloud Run Jobsでバッチを実行します。
データ移行と負荷試験に加えて、監査ログや運用設計も含む場合は、800万〜2,000万円、4〜8か月程度が推定レンジです。
顧客や代理店も利用する場合は、公開範囲とレート制限を決めたうえで、WAF相当の防御や問い合わせ対応も見積もります。特に、非機能要件を後回しにすると、リリース直前の性能やセキュリティへの対応で、予算が膨らみやすくなります。
基幹連携・高要件システムの想定費用
基幹連携では、ERPやWMS、CRM、会計と接続します。さらに、大量のデータを移行することもあります。
複数リージョンや厳格な監査を求め、段階移行や24時間監視も必要な場合は、2,000万〜5,000万円超、8〜18か月程度になる可能性があります。
仕様書が不足していたり、データの欠損や重複があったり、複数部門の承認が必要だったりすると、実装より調査や調整、移行リハーサルに費用がかかります。金額の上限だけでなく、各リスクを誰が負担するかも契約で明確にします。
見積書の要件定義・設計・製造・テスト・移行の工程別内訳
工程別の配分を基準にすると、会社ごとの見積もりを同じ条件で比べられます。ただし、工程ごとの割合は次のとおりで、公的な標準価格ではなく、業務システムの工程配分に基づく確認用の目安です。
- 要件定義：初期開発費の10〜15%程度。
- 設計：25〜35%程度。
- 製造・単体テスト：30〜40%程度。
- 結合・総合テスト：15〜20%程度。
- 移行・教育：5〜10%程度。
工程の名前や含む作業は会社ごとに異なります。そのため、人日や担当職種に加えて、成果物と前提条件まで確認します。
初期開発費、Google Cloudの月額利用料、リリース後の保守・運用費は、分けて記載してもらいます。保守費は一般的な目安として、初期開発費の年10〜20%程度で検討します。
保守の範囲は、監視や障害対応、脆弱性対応、軽微改修、クラウド請求確認に分けて考えます。監視やバックアップを除いた月額見積もりは、本番運用の比較に使えません。
Cloud Runの月額料金と周辺サービス費用
Cloud Runの利用料は、CPUとメモリ、リクエスト、実行時間で積み上がります。通信量も加わります。
リクエストベース課金は原則として、処理中などのインスタンス時間が対象です。一方、インスタンスベース課金は、起動から終了までが対象です。
試算するときは、無料枠、リージョン、課金方式を指定します。同時実行数と最小インスタンス数も、あわせて入力します。
Cloud Run単体の料金を決めるCPU・メモリ・実行時間
公式料金例の条件と地域差を確認すると、試算の前提をそろえられます。
- 標準例：1 vCPU・512MiB、月1,000万件、平均400ミリ秒、同時実行数20の場合は月13.69米ドル。
- 高負荷設定例：CPU負荷が高い条件での料金。
同じ条件でも、1インスタンス1リクエストの設定では月81.72米ドルの例があります。
同時実行数やアプリの性質も、料金に影響します（出典: Google Cloud公式「Cloud Run pricing」、2026年8月確認）。
これはベルギーリージョンの公式例なので、日本の案件にそのまま当てはめられません。東京リージョンや無料枠の有無で金額が動くほか、為替、処理時間、メモリ量も影響します。
1米ドル=150円などで円換算する場合は、仮定を明記します。確定時は、公式料金ページとPricing Calculatorへ同じ条件を入力します。
Cloud SQL・ネットワーク・ログを含む実務上の月額費用
Cloud Runに加え、接続するデータベースやネットワークなどの月額費用も試算に含めます。
- Cloud SQL：DB本体と接続に関わる料金項目。
- 周辺サービス：利用する周辺基盤の費用。
- 構成別の推定月額：小規模・低トラフィックは2万〜10万円、中規模は10万〜50万円、常時稼働・高可用性・大量連携は50万〜150万円超。
Cloud SQLの公式料金は、複数の項目で構成されます（出典: Google Cloud公式「Cloud SQLの料金」、2026年8月確認）。
対象は、CPU・メモリとストレージ・通信です。インスタンスやCloud DNS、延長サポートも含まれます。
周辺には、Cloud StorageやArtifact Registry、Cloud Build、Cloud Loggingがあります。加えて、Secret Manager、ロードバランサー、VPC接続なども費用項目に含まれます。
金額は構成と利用量から組み立てた目安で、Cloud Run単体の定額表ではありません。そのため、Cloud SQLの可用性やログ保存日数、外部通信量を変数にして再計算します。
Jobs・ビルド・バックアップの加算分
Jobs、ビルド、保存にかかる費用は、実行量や保持期間で変わります。見積もりには、次の条件を反映します。
- 定時バッチ：Cloud Run Jobsの料金は、タスク数、実行時間、CPU・メモリ、実行頻度で変わります。
- 公式料金例：Cloud Run Jobsの料金例を、実行条件と合わせて確認する。
- ビルドと保存：ソースコードのデプロイに使うCloud BuildとArtifact Registryは、別料金。
公式例では、1 vCPU・512MiBのジョブを1時間に1回、1回1分、月730回実行します。
無料枠を除く推定は、月0.45米ドルです（出典: Google Cloud公式「Cloud Run pricing」、2026年8月確認）。
処理対象の増加やリトライは、料金を増やします。並列タスクやデータ転送も、料金に加わります。そのため、成功時だけでなく、失敗時の再実行も試算します。
検証用のイメージや古いリビジョンは、保存費を増やします。このため、イメージ保持やログ保存期間、バックアップ世代数を運用設計に含めます。
費用が変動する要因とコスト最適化のポイント
コスト最適化では、料金単価を下げる設定に頼らず、まず不要な処理や重複保存を避けます。次に、必要な可用性を選び、利用量を測ってから固定費の大きい構成へ移します。
安さを優先してバックアップや監視を削ると、障害時の復旧費用が増えます。そのため、業務への影響と合わせて判断します。
同時実行数とCPU・メモリの実測による調整
APIの負荷やアプリの性質によって、同時実行数とリソースの適正値は異なります。
- 同時実行数：低すぎるとインスタンス数と課金時間が増える場合があります。高すぎるとスレッド安全性やDB接続数の上限を超える可能性があります。
- CPU・メモリ：余裕を持たせすぎると月額が増え、過少な設定はタイムアウトや再試行を増やします。
APIごとに負荷試験を行い、応答時間やエラー率を見ます。Cloud SQLの接続数とインスタンス数も、あわせて確認します。
画像処理や帳票生成はPub/SubやJobsへ分けると、必要な時間だけ動かせるため、待ち時間と常時費用を抑えられます。
設定は、処理成功率も含めて評価します。
最小インスタンス数と可用性・費用のバランス
最小インスタンス数は、コールドスタートの許容度と利用頻度に合わせて選びます。
- 低頻度の業務：トラフィックがなければゼロまで減らせます。初回表示に数秒かかっても構わない社内申請や定期APIなら、最小数を0にする選択肢もあります。
- 遅延を避けたい業務：顧客ログインや決済前処理。離脱や売上への影響を考えると、1台以上を維持する価値があります。
- 課金と設定：維持中の課金と、適切な設定数。
公式資料によると、最小インスタンスの維持中は課金されます。
通常の利用量に近い数にすることが、コスト最適化につながります（出典: Google Cloud公式「Set minimum instances for services」、2026年8月確認）。
可用性用の最小インスタンスを、ステージング環境やタグ付きの古いリビジョンに残さない運用も必要です。
DB・ネットワーク・ログの過剰構成の防止
Cloud SQLの稼働、ログの保存、通信経路は全体費用に影響します。業務要件に合わせて、調整する箇所を考えます。
- DB・ログ：サイズやHA、リードレプリカ、バックアップ保持、アーカイブ、ログ除外の決定。
- 処理・通信：キャッシュと通信経路の見直し。
- 個人情報：ログを安易に削除せず、マスキングや権限、保管期間、監査要件を決めて、保存量を抑える。
一覧にはキャッシュや集計テーブルを使い、重い集計の繰り返しを避けます。Cloud RunとDBのリージョンをそろえ、不要な外向き通信を減らします。静的ファイルは、Cloud StorageやCDNから配信します。
Cloud SQLを常時稼働させ、ログを長期保存し、通信を高価な経路へ流すと、Cloud Runの費用を下げても全体額は下がりません。
予算アラートと月次レビューによる料金急増の検知
請求アカウントでは、プロジェクトやサービス別の利用額を見て、予算と予測額のアラートを設定します。月次で確認する項目を決めておくと、増加の原因を追いやすくなります。
- 実行量：Cloud Runのインスタンス時間、リクエスト数、最大数。
- 周辺費用：Cloud SQLのCPU・ストレージ、ログ取り込み、データ転送。
- 開発環境：不要なリソースを停止・削除するルール。
本番開始後1〜3か月は、実利用と見積もりの差を重点的に見ます。超過した場合は、まず不要なリトライや過剰ログ、最小インスタンスを確認します。未使用のイメージも見たうえで、クエリやキャッシュを見直します。
利用量が安定してから長期契約や割引制度を検討すると、需要を読み違えて固定費を抱えるリスクを減らせます。
Cloud Runの見積もりを取る際のポイント
相見積もりでは、総額の安さだけでなく、同じ前提で比べられる形にそろえます。RFPには、サービス数やJobs、DB、環境数を書きます。認証や移行件数、テスト範囲、監視時間帯も書き、各社へ同じ質問をします。
前提がそろわないまま価格を比べると、安く見える会社が作業を除外している可能性があります。
RFPに整理する要件と業務データ
比較条件をそろえるため、業務要件とデータの状態をRFPにまとめます。
- 業務・利用量：対象業務、利用者、画面・API、外部連携、月間・ピーク件数、データ量。
- 運用・安全性：個人情報、希望リージョン、RTO・RPO、稼働・サポート時間。
- 移行データ：テーブル・CSV件数、欠損・重複、照合項目、並行稼働期間。
資料が不足する場合は、調査と要件定義を先に発注する二段階方式も有効です。発注者の準備が多いほど調査工数を減らせますが、社内では難しい現場ヒアリングやデータクレンジングは、支援範囲に含めます。
特に、技術選定より先に、業務の例外処理とデータ責任者を決めることが後戻りの防止につながります。
Cloud Runの本番実績と担当範囲
資格の数だけでなく、実績と担当範囲を確かめます。見積条件や引き継ぎのしやすさも、あわせて確認します。
- 開発・運用実績：Cloud Runの本番事例、コンテナ・DB・ネットワークの設計担当、障害対応時間、移行経験。
- 見積と契約：費用内訳、納品物、所有者、責任分界、変更条件の確認。
- 継続運用：請求明細の閲覧や、内製化・他社への引き継ぎのしやすさ。
Google Cloud事例では、Pepkor ITのPAXIがモノリスをクラウドネイティブなマイクロサービスへ再構築し、Cloud Runへ段階移行しました。
費用例ではありませんが、機能単位の分割と切り替えの参考になります（出典: Google Cloud公式「PEP Case Study」、2026年8月確認）。
見積書では、人日と単価、再委託の有無、設計書・ソースコード・IaCの納品を確認します。
また、クラウドアカウントの所有者と請求の支払者も確かめます。障害時の責任分界と、追加変更の単価も明記します。
月額費用を開発会社が立て替える場合は、発注者が請求明細を見られるようにします。将来の内製化や別会社への引き継ぎでは、特定の担当者しか理解できない構成を避けます。
契約後の運用費と変更ルール
運用開始後の作業と変更条件を分けて、契約に記載します。
- 保守作業：監視とアラートの一次受け、障害調査、脆弱性対応とライブラリ更新、バックアップ確認と復元訓練、軽微改修、料金レビュー。
- 対応体制：平日日中と24時間365日では体制と費用が異なり、対応時間、初動、復旧目標、連絡経路を定めます。
- 変更作業：新機能を月額保守の範囲内にするか、別見積もりにするかの判断。
Cloud SQLのメジャー更新やリージョン追加では、設計・試験・移行が必要になる場合があります。API仕様の変更や監査ログの延長でも、設計や試験、移行が必要になることがあります。
初期見積もりだけでなく、3年間の開発・利用・保守・移行の総額で判断します。
Cloud Runのシステム費用に関するよくある質問（FAQ）
発注の前によく寄せられる、Cloud Runの費用の質問を取り上げます。単体の料金と全体の費用を分けて、利用量や非機能要件によって変わる点を確認します。
Cloud Runならシステム開発費用は必ず安くなりますか？
必ず安くなるとは限りません。サーバーやOSの管理工数は抑えられます。ただし、コンテナ化やDB、認証の費用に加えて、ネットワーク、監視、移行、運用設計の費用は必要です。
低トラフィックで、自動スケールやスケール・トゥ・ゼロを活かせる業務なら、運用負荷と利用料を抑えられます。
Cloud Runのシステム月額費用はいくらですか？
推定では、低トラフィックの小規模構成で月2万〜10万円、中規模で月10万〜50万円です。常時稼働・高可用性・大量連携では、月50万〜150万円超を検討します。
これはCloud Run単体の定額ではなく、Cloud SQL、ログ、ネットワーク、バックアップを含む構成の目安です。
CPUやメモリ、インスタンス数を入力して、Pricing Calculatorで再計算します。DBのサイズやログ保存期間、通信量も、同じ試算に入れます。
既存のオンプレミス業務システムをCloud Runへ移行できますか？
移行できる可能性はあります。ただし、アプリをコンテナ化でき、状態を外部サービスへ分けられることが前提です。
まず、ファイル保存やセッション、バッチを洗い出します。次に、常時接続や固定IP、OS依存の処理も確かめます。
Cloud RunサービスやJobsへ、Cloud SQLやCloud Storageなどの役割を置き換えます。費用は、コードの状態やデータ量によって変わります。並行稼働や切り戻し条件、業務停止の許容時間でも変わります。
Cloud RunとGKEはどちらを選ぶべきですか？
Web API、管理画面、イベント処理を少ないインフラ運用で動かすなら、Cloud Runが候補です。一方、複雑なクラスタ制御や常時稼働、大規模なコンテナ運用、特殊なネットワークが必要な場合は、GKEを比較します。
機能をCloud Runへ無理に合わせず、同じ要件表で評価します。開発費と月額に加えて、運用体制、性能、可用性、将来の拡張も見ます。
見積書で最低限確認すべき項目は何ですか？
見積書では、要件定義から教育までの工程と、サービス構築、監視、バックアップ、保守の範囲を確認します。
作業時間や成果物、前提・除外事項を確かめます。変更ルールや、コードとIaC、アカウント所有者、障害時のSLAも対象です。
初期費用と月額費用が分かれ、料金試算の入力条件が添付されていれば、複数社を比較しやすくなります。
まとめ
開発費の推定レンジは、PoCで100万〜300万円、小規模で300万〜800万円です。中規模は800万〜2,000万円、基幹連携や高要件は2,000万〜5,000万円超です。
費用は、画面やAPI、バッチの範囲によって変わります。DBや認証、通信、監視も費用を左右します。さらに、移行やテスト、保守の範囲も金額に影響します。
相場と月額を分けて見る考え方
月額は、Cloud Runの利用料と、Cloud SQLや周辺サービスの費用を合算して求めます。周辺サービスには、ストレージやログ、ビルド、バックアップ、転送が含まれます。
推定レンジは、低トラフィックの小規模構成で月2万〜10万円、中規模で月10万〜50万円、常時稼働・高可用性・大量連携で月50万〜150万円超です。
公式料金例と実利用量をPricing Calculatorで照合し、最小数、同時実行、DB、ログ保持を調整します。
発注前の確認事項と見積もりへの反映
要件定義を行い、PoCでコンテナやDB接続を確かめます。負荷と認証も確認したうえで、初期費と利用料、保守費を分けた見積もりを取ります。
納品には、コードやTerraform、設計書を含めます。移行表や運用手順、障害時の責任分界も、契約に入れておきます。価格だけでなく、3年間の総コストと業務継続性で比べることが、導入判断の要点です。
▼全体ガイドの記事
・Cloud Runのシステム開発の完全ガイド
▼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を創業。