Cloud Runのシステムは、実行形態と周辺サービスを業務要件に合わせて選び、組み合わせて作ります。この組み合わせが決まると、業務に合う構成と費用を判断できます。
構成、開発の流れ、費用、開発会社の選び方、運用設計の順に見ていきます。各テーマの詳細は関連記事もご覧ください。
▼関連記事一覧
・Cloud Runのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・Cloud Runのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・Cloud Runのシステム開発の見積相場や費用/コスト/値段について
・Cloud Runのシステム開発の発注/外注/依頼/委託方法について
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Cloud Runのシステムの定義
Cloud Runのシステムは、Cloud Runを実行場所として周辺のマネージドサービスと組み合わせる構成です。
特定の業務システム製品を指すのではなく、クラウド上の構成パターンのことです。この見方で捉えると、採用の可否を構成ごとに判断できます。
実行基盤としてのCloud Runの役割
Cloud Runを業務システムに使うときは、実行基盤として担う役割と、周辺機能が受け持つ範囲を分けて考えます。
- 実行基盤：Dockerなどで作成したコンテナを動かす役割
- サービス展開：画面・API・社内管理画面を、それぞれ別々にデプロイできる仕組み
- 周辺機能：業務データ用DBやユーザー・組織・権限管理は、標準搭載の対象外
Go、Node.js、Pythonなどのように、コンテナイメージを作れる言語やフレームワークを使えます。Java、.NET、Rubyも対象です。
既存アプリを段階的に移行する構成にも使えます。データ保存にはCloud SQLやFirestore、ファイル保存にはCloud Storageを使い、接続情報はSecret Managerで管理します。
Cloud Runを「安いサーバー」とだけ捉えると、後から周辺費用と設計作業が積み上がります。
基本構成：画面・API・データ・監視の組み合わせ
代表的な構成要素は、利用者のアクセスを受ける入口と、画面やAPIです。データ保存、ファイル保存、非同期処理、監視も含まれます。
- 入口：ロードバランサーや認証によるアクセスの受け付け
- データ：Cloud SQLまたはFirestoreへの保存
- ファイルと処理：Cloud Storage、Pub/Sub、Cloud Run Jobsの利用
- 監視：Cloud LoggingとCloud Monitoringへの、ログとメトリクスの集約
監視では、エラー率と応答時間を見るのが基本です。インスタンス数やデータベース接続数も確認します。
画面の応答と重い処理を分けると、待ち時間と障害の影響範囲を抑えられます。たとえば、月末の請求書作成を画面内で実行すると、タイムアウトや二重実行が起きやすくなります。
画面側は受付結果を返し、バックグラウンドで帳票を生成して完了通知を送る構成にできます。
向いている業務システムと注意が必要なシステム
業務のアクセス特性や処理要件から、Cloud Runの適性と比較先を分けて考えます。
- 向く業務：時間帯でアクセス量が変わる処理や、短時間のバッチ
- 比較対象：常時接続や複雑なネットワーク制御が中心なら、GKEや仮想マシンも候補
対象には、ポータルやAPI、申請画面が含まれます。イベント駆動の連携も該当します。加えて、スケール・トゥ・ゼロで低アクセス時にインスタンスを減らせます。
常時大量のアクセスがない場合は、固定台数のサーバーより運用を簡素にできることがあります。ただし、長時間の常駐処理や特殊なOS要件があるかは、比較の時点で確認しておきます。
Cloud Runの採用そのものが目的になると、アプリの制約を後から補うことになり、開発費や運用費が膨らみます。
Cloud Runの種類と他の実行基盤の使い分け
Cloud RunのServiceはHTTPリクエストを処理する役割を持ちます。Jobは完了まで実行する処理を、Worker poolは常時稼働型のバックグラウンド処理を担います。
この3種類は、Google Cloud公式でもコード実行の主要リソースとして整理されています（出典: Google Cloud公式「What is Cloud Run」、2026年8月確認）。
業務フローのどこに、どの実行形態を置くかを決めておくと、構成と見積もりが具体的になります。
業務の性質で分けるService・Job・Worker pool
実行形態は、処理がどう始まり、どれくらい動くかで選びます。
- Service：管理画面やAPIなど、HTTPリクエストへの応答
- Job：夜間集計、データ変換、帳票生成、移行、定期請求など、開始から終了までで完結する仕事
- Worker pool：キューを常時監視する処理
Serviceは自動スケールで急なアクセス増加に対応できます。ただし、インスタンスはステートレスなので、セッションや編集中のデータはDBや外部ストレージに保存します。
Jobは、複数のタスクに分けられる処理であれば並列化して、処理時間を短縮できます。短いイベント処理では、Worker poolよりServiceとPub/Subの組み合わせが運用しやすい場合もあります。
Cloud Run・GKE・仮想マシンの境界
実行基盤は、運用負担、制御の必要性、既存環境への依存という観点で比べます。
- Cloud Run：クラスタやOSの保守をできるだけ減らしたい場合
- GKE：複数コンテナの細かな制御や、独自ネットワーク、スケジューリング、常時稼働処理の集約が必要な場合の候補
- 仮想マシン：既存OSへの依存や、特殊なミドルウェア、コンテナ化が難しいパッケージがある場合の検討先
比較軸には、RTO・RPOやピーク時の同時利用者数、処理時間が入ります。さらに、常時稼働の要否、ネットワーク経路、運用担当者のスキルも含めて比べます。
Cloud RunのServiceは大規模アクセスにもスケールします。ただし、接続先のDBが先に限界に達することがあるため、DBの接続プールと最大インスタンス数も設計します。
パッケージ連携・移行・スクラッチの使い分け
既存サービスの活用から新規開発まで、業務に必要な範囲で組み合わせて使います。
- SaaS・パッケージ連携：Cloud Runを連携APIや拡張機能に絞る形
- 新規構築：マネージドサービスを中心にした構成
- 既存アプリ移行：アプリをコンテナ化して移す作業
- スクラッチ開発：独自業務の機能の開発
競争力に直結しない機能は既存サービスを使い、独自の承認ルールやデータ連携だけを新規に作ると、納期と費用を抑えられます。
移行前には、アプリがコンテナで起動するかを確認します。特に、ローカルファイルや固定IP、メモリ上のセッションは問題になりやすい点です。ほかに、長時間バッチや管理者権限の処理も、移行時に注意が要る処理です。
まず小さな機能でPoCを行い、修正量と性能を確かめます。そのうえで、本番移行の範囲を決めます。
Cloud Runのシステム開発の進め方
業務フローと非機能要件を整理してから構成を決めると、安全に進められます。特に、データ移行や権限は、後から変えると影響が大きくなります。障害復旧と費用上限も、後からの変更が難しい項目です。
一般的には、要件定義から始めてPoC、設計・開発へ進み、テスト・移行を経て、リリース・運用引き継ぎに至ります。
▶ 詳細はこちら：Cloud Runのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
要件定義とPoCでのCloud Runの適性確認
要件定義で業務と品質条件を整理したうえで、PoCによりCloud Run上の動作を確かめます。
- 要件定義：誰がどの業務で何のデータを使い、何分以内に処理するかの決定
- PoC：一つの業務シナリオでの構築・接続・負荷・料金の検証
要件定義では、利用者の役割や承認経路、同時利用者数を洗い出します。さらに、ピーク時間や外部連携先も押さえます。個人情報の有無、保存期間、監査ログの要否は、一覧にします。
RTOは障害からの復旧にかかる時間、RPOは復元できるデータの時点を指します。
PoCは2〜6週間程度で、一つの業務シナリオに絞ります。ビルドからデプロイ、認証とDB接続が動くかを確かめます。さらに、ファイル保存やログ、負荷と概算料金も見ます。
画面の動きだけでなく、失敗時の再実行や権限外データの閲覧防止、インスタンス増加時のDB負荷も検証します。
環境・データ・権限の設計と開発
設計には、環境の分離や自動化、最小権限、公開範囲を含めます。
- 環境とデプロイ：開発・ステージング・本番を分けた管理
- 権限：アプリごとの専用サービスアカウント
- アクセス経路：外部向けと社内専用の画面で分ける防御方法
設定値と秘密情報は環境ごとに分けて管理し、イメージはArtifact Registryに保存します。
CI/CDを使えば、テストや脆弱性チェック、承認、本番デプロイを自動化できます。また、TerraformなどのIaCは、再構築と引き継ぎに役立ちます。
必要最小限のIAM権限を付与します。そのうえで、利用者の権限一覧と、サービスがDBやストレージへアクセスする権限は分けて管理します。
外部向けの画面には、ロードバランサーやTLS、レート制限を組み合わせます。必要に応じて、WAF相当の防御も加えます。一方で、社内専用の画面は、内部Ingressや認証で経路を限定します。
テスト・移行・切り戻し条件の決定とリリース
テスト、データ移行、本番リリースの順に準備を進め、切り戻し条件まで決めておきます。
- 機能・業務・権限・連携・負荷・障害・復旧のテスト
- データ移行のリハーサルと、件数・差分反映の確認
- 運用手順書への、切り戻し条件、連絡先、判断者、復旧手順の記載と訓練
自動スケールしても、DBや外部APIの制限を超えるとエラーになります。そのため、ピーク時の利用者数と連携回数を想定します。そのうえで、最大インスタンス数とタイムアウトに加え、リトライや重複実行対策も確かめます。
移行では、項目の対応と不要データ、文字コードと日付形式、重複ルールを決めておきます。業務部門の検証担当も決め、移行時間はリハーサルで把握します。
Cloud Runのシステム開発費用と月額の相場
費用は、開発費とクラウド利用料に分けて考えます。Cloud Run単体の国内開発費を示す公的統計は確認できていません。そのため、以下の数字は、一般的な工数と構成要素から作った編集上の推定です。
実額は、画面数や権限の複雑さ、外部連携によって変わります。さらに、データ移行やテスト要件、運用時間も影響します。
▶ 詳細はこちら：Cloud Runのシステム開発の見積相場や費用/コスト/値段について
規模別の開発費と期間の目安
規模別の推定額と期間は、含まれる機能をそろえて見比べます。以下の金額は、予算検討用の目安です。
- 技術検証・小規模PoC：100万〜300万円、2週間〜2か月。含むのは、1サービスと簡易認証、ログ、最低限のCI/CDです。
- 小規模業務システム：300万〜800万円、2〜4か月。範囲は、管理画面、API、データ保存、権限、基本監視、1〜2本の連携です。
- 中規模業務システム：800万〜2,000万円、4〜8か月。複数ロール、外部API、バッチ、移行、負荷試験、冗長化、運用設計を含む場合の目安
- 大規模な要件：2,000万〜5,000万円超、8〜18か月となる場合があります。
小規模業務システムのデータ保存は、Cloud SQLまたはFirestoreを使う構成が範囲に入ります。
大規模要件の目安は、基幹連携や大量データ、監査ログ、複数リージョンが必要な場合です。段階移行と24時間運用が必要な場合も含みます。
各金額は、要件の抜けを防ぐための予算検討用の数字です。相場を断定するものではありません。
見積内訳の目安は、要件定義10〜15%、設計25〜35%、製造・単体テスト30〜40%です。さらに、結合・総合テストが15〜20%、移行・教育が5〜10%程度かを見ます。
要件定義を削りすぎると、仕様変更や移行のやり直しで費用が増えます。そこで、画面の製造費だけでなく、非機能要件や運用設計、資料、引き継ぎまで含めて比べます。
Cloud Runと周辺サービスの月額利用料
月額は、Cloud Runの使用量だけでなく、周辺サービスと保守の条件も含めて試算します。
- 利用料：課金方式、利用量、リージョンによって変わる部分
- 総額：DB、通信、ログ、バックアップの費用を加えたもの
- 保守：監視や障害対応など、作業範囲を分けた契約
Cloud Runは、課金方式に応じてCPU秒やメモリGiB秒、リクエスト、通信量などで課金されます。
公式料金表の月間無料枠はCPU 240,000 vCPU秒、メモリ450,000 GiB秒です（出典: Google Cloud公式「Cloud Run pricing」、2026年8月確認）。
課金単位やリージョン、無料枠と通信費は変わる可能性があります。そのため、契約前に料金計算ツールで再計算します。
1 vCPU・0.5GiBのインスタンスが常時稼働すると仮定した単純試算では、1か月のCPU・メモリ使用量は約259.2万vCPU秒・129.6万GiB秒です。
2026年8月の東京リージョン標準単価から無料枠を差し引くと、CPU・メモリ分は月27〜30米ドルほどになります。1ドル150円で換算すると約4,000〜4,500円で、あくまで理論値です。
実際は、Cloud SQLやロードバランサー、Cloud Loggingなどの費用が加わります。さらに、Artifact RegistryやVPC接続、外向き通信、バックアップ費もかかります。
初期予算としては、小規模なら月2万〜10万円、中規模なら月10万〜50万円を置けます。常時稼働や高可用性、大量連携がある構成では、月50万〜150万円超を仮置きし、利用量に応じて見直します。
保守費は、初期開発費の年10〜20%程度を目安にする考え方があります。監視や障害・脆弱性対応、軽微な改修、クラウド費を分けて考えると、不要な作業が固定費になるのを抑えられます。
Cloud Runの開発会社・ベンダーの選び方
開発会社は、資格や知名度よりも、本番運用の経験、コンテナやDB、ネットワークの設計、業務理解で比べます。加えて、保守体制や見積の透明性も確かめます。
Google Cloudに詳しくても、マスタ移行や承認業務、現場の例外処理を整理できなければ、業務システムは現場に定着しません。
Cloud Runの本番実績と担当体制
実績は、Google Cloudの経験だけでなく、Cloud Runで動かしたシステムや利用量、運用担当者まで確認します。
- 技術実績：ServiceとJob、Cloud SQL接続、最大インスタンス数、監視、復旧時間についての質問
- 担当体制：要件定義・設計のエンジニア、主副担当、レビュー、再委託範囲の確認
- 継続性：交代時の引き継ぎ、問い合わせ時間、障害連絡経路についての質問
匿名の事例でも、具体的な構成を説明できるかどうかで、経験の深さが分かります。また、提案の段階から要件定義・設計の担当者にも参加してもらいます。
大規模な会社でも、Cloud Runの部分を別の会社へ再委託する場合があります。そのため、契約で責任の範囲をはっきりさせておきます。
見積書・契約書・納品物の粒度
同じRFPと質問票を各社に渡すと、作業範囲と納品物を同じ条件で比べられます。
- 見積範囲：要件定義、設計、開発、基盤、移行、テスト、教育、保守を分けた内訳
- 金額の前提：人日、単価、期間、前提、対象外、追加変更の算定方法
- 契約と納品：成果物、所有権、アカウント、請求、データ返却、内製化支援の取り決め
一式見積では、監視設定や移行リハーサルが別料金になるため、最終金額を比べにくくなります。
納品物には、要件・画面・API仕様とデータモデル、権限一覧を含めます。加えて、テスト仕様と結果、運用・障害手順も入れます。
対象には、TerraformなどのIaCやコンテナのソース、CI/CD設定、ログとアラート一覧を入れます。ソースやクラウド環境の所有権は、契約で決めておきます。
提案前に聞く質問の標準化
同じ質問を同じ順番で投げかけると、各社の提案を比べられます。
- 構成：本番Cloud Runの構成と規模、DB接続上限、スケール設計の考え方
- 安全性：個人情報のリージョン、バックアップ、ログの扱い方
- 運用：障害時の判断者と判断までの時間、利用料上限と異常検知の設定
- 引き継ぎ：IaCとソースコードの納品形式
発注者側では、業務フローや現行データ、マスタ、アカウントを準備する場合があります。社内規程やテスト担当、移行時の停止時間を用意することもあります。
発注者と開発会社で作業分担表を作り、完了条件まで合意しておきます。そうすると、認識の違いによる移行の遅れや追加費用を防ぎやすくなります。
▶ 詳細はこちら：Cloud Runのシステム開発でおすすめの開発会社/ベンダー6選と選び方
▶ 詳細はこちら：Cloud Runのシステム開発の発注/外注/依頼/委託方法について
Cloud Runのシステムで必要なセキュリティと運用設計
Cloud Runを使えば、OSのパッチやサーバー台数の管理は減らせます。ただし、セキュリティと運用の責任は残ります。
脆弱性や過剰な権限、誤公開を検知する仕組みは、別途用意します。さらに、バックアップ不足や異常課金も検知の対象に入れます。
ステートレス性とデータ保護の前提
データの保存方法と個人情報の扱いは、運用や社内規程も含めて確かめます。
- 状態の保存：インスタンス終了で失われるデータの外部保存
- 個人情報：保存・保護・削除の要件
- 法令・規程：社内規程や法令との照合
公式の設計では、状態データをCloud SQLやMemorystoreなどへ、秘密情報をSecret Managerなどへ保存する形です（出典: Google Cloud公式「Security design overview」、2026年7月更新）。
基本は、セッションやアップロードファイル、処理済みフラグを、ローカルディスクだけに保存しないことです。
個人情報を扱う場合は、保存先とバックアップ先のリージョンや暗号化、アクセスログ、保存期間と削除方法を具体的に決めます。
データレジデンシーや暗号化などのクラウド機能を設定しても、法令や社内規程への対応が済んだとは判断しません。そのうえで、委託先・再委託先の監督や海外での取扱い、業界指針を、法務・情報システム・現場部門と確かめます。
監視・バックアップ・復旧の運用設計
監視項目は、異常の発見と問い合わせ対応に必要なものに絞ります。
- 稼働状況：エラー率、レイテンシ、リクエスト数、インスタンス数
- 資源と処理：CPU・メモリ、Job失敗数、DB接続数、外部APIエラー
- ログと通知：業務影響のある条件に絞った通知、通知先と対応時間の決定
ログにはパスワードやアクセストークンを出さず、問い合わせ用のリクエストIDや処理IDは残します。
バックアップは、実際に復元できるかを検証します。月1回の復旧テストや四半期ごとの障害訓練など、重要度に応じて頻度を決めます。
DBの不整合は、Cloud Runのリビジョンを切り替えても元に戻りません。そのため、アプリ、DB、ストレージ、外部連携の復旧順を一つの手順にまとめます。
2026年のAI活用と新機能の判断
新機能は、提供状況と業務上の必要性を確かめてから、本番で使うかを判断します。
- 機能拡張：AI推論や非同期エージェント処理という選択肢の追加
- 本番採用：提供状況、サポート、費用、データの扱いの確認
- 効果測定：業務の待ち時間や手作業の削減の測定
2026年4月には、Cloud RunのAIエージェントやGPU推論、リモートMCPサーバー、フルスタックアプリなどの拡張が発表されました（出典: Google Cloud公式ブログ「What’s new for Cloud Run at Next ’26」、2026年4月）。
提供状況は、機能ごとに一般提供かプレビューかが異なります。
AIを業務に組み込む際は、参照できるデータや操作履歴、誤処理の差し戻し方法を決めます。業務APIを操作させる場合は、権限分離や承認、レート制限と費用上限、監査ログを設けます。
Cloud Runのシステムに関するよくある質問
料金や既存システムとの互換性、サーバー管理について、導入前によくある質問をまとめました。
Cloud Runのシステム開発にDockerの知識は必要ですか？
担当者には、起動やポート、環境変数、ログ、イメージ管理の知識が求められます。Dockerを深く理解するまでは、全員に必要ありません。
言語やフレームワークによっては、ソースからコンテナをビルドできます。そのため、発注時には、コンテナ化とCI/CDの担当者や、設定ファイル・ソースの引き継ぎ形式を確認します。
オンプレミスの既存業務システムをCloud Runへ移行できますか？
移行できる可能性はありますが、まずコンテナで動かせるかを確かめます。ローカルファイルや固定IP、常時接続は、設計の変更が必要になる場合があります。OS依存や長時間処理、メモリ上のセッションも、設計変更の対象になることがあります。
ローカルファイルなどは、外部ストレージやネットワーク、DB、Jobsなどへ置き換えます。そのうえで、小さな機能でPoCを行い、修正量や性能、移行停止時間を把握してから計画します。
Cloud Runのシステムは月額いくらかかりますか？
Cloud Run単体の料金は、CPUやメモリ、リクエスト、通信量などで決まります。低トラフィックなら、少額で収まる場合があります。
業務システムでは、DBやログのほか、ロードバランサーやバックアップ、ネットワーク費が加わります。目安として、小規模は月2万〜10万円、中規模は月10万〜50万円を仮置きします。
実際のリクエスト数やデータ量、可用性の要件を、料金計算ツールに入力して確かめます。
個人情報を扱うシステムでもCloud Runを使えますか？
使える可能性はありますが、Cloud Runを使うだけで法令や社内規程への対応が終わるわけではありません。
要件には、リージョンや保存先、バックアップ、権限を入れます。監査ログや暗号化、委託先管理、削除方法も含めます。
社内利用であれば、Ingressを内部向けに限定できます。外部利用の場合は、認証やロードバランサーを組み合わせ、操作の経路と内容を記録できるようにします。
開発会社へ相談する前に何を準備すればよいですか？
業務フローや利用者と権限、画面・帳票、連携先を整理します。さらに、データ件数とピーク時間、個人情報、納期と予算上限も整理しておきます。
仕様が未確定でも、現場の課題と優先順位が分かれば、提案を比べられます。加えて、納品物や保守の受付時間、クラウド請求の管理者も伝えます。
ソースコードやIaC、運用手順、テスト結果を納品物に含めるかどうかも、相談します。
まとめ
Cloud Runのシステムは、コンテナの実行基盤に、DBやストレージを組み合わせて作ります。認証やネットワーク、監視も、その構成に含まれます。
Serviceは画面やAPI、Jobは定期処理、Worker poolは常時稼働の処理に使います。
Cloud Run単体の料金だけでなく、周辺サービスや開発、移行、保守を含む総保有コストで判断します。
導入前に押さえる3つの要点
実行基盤の設計、PoC、契約条件は、一続きで確かめます。
- 全体設計：永続化、権限、監視、バックアップを一体で考える
- 適性確認：PoCでコンテナ化、認証、DB接続、負荷、費用を確かめる
- 契約確認：移行分担、IaCやソース納品、障害責任、請求上限を明記する
次に準備する資料
相談や相見積もりでは、業務情報をまとめた資料を、候補先に同じ条件で渡します。
- 業務資料：業務フロー、利用者・権限、既存構成、連携先のまとめ
- 規模・条件：データ件数、ピーク時間、RTO・RPO、個人情報分類、納期、予算の整理
- 候補先の比較：本番実績と、DB・ネットワーク・セキュリティ・移行・運用それぞれの説明力
業務の目的と測定指標が明確であれば、Cloud Runが適切かどうかも含めて、無理のない構成を選べます。
▼関連記事一覧
・Cloud Runのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・Cloud Runのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・Cloud Runのシステム開発の見積相場や費用/コスト/値段について
・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を創業。