マイクロサービス基盤開発でおすすめの開発会社/ベンダー6選と選び方

マイクロサービス基盤の開発会社は、業務支援の範囲、基盤の選択肢、運用の責任範囲で比べると、自社に合う発注先を選びやすくなります。

比較の対象は、株式会社riplaと実在する5社の計6社です。各社の支援内容、パートナー選びの注意点、開発費用の目安を順にまとめています。

▼全体ガイドの記事
・マイクロサービス基盤開発の完全ガイド

マイクロサービス基盤のパートナー選びが重要な理由

マイクロサービスの分割判断を変更単位・障害単位・責任単位の3つで整理した図
3つの観点を並べると、分割後の運用課題を整理しやすくなります。

基盤の成否は、Kubernetesやコンテナを導入するかどうかより、業務境界をどう分けるかで決まります。たとえば、販売、在庫、顧客といった業務の区切り方が中心になります。

加えて、データの所有者や、障害時に業務を続ける範囲も決めておく必要があります。事業部門と技術部門の合意が、その成否に大きく影響します。

変更単位・障害単位・責任単位で見る分割の判断

サービスを分けると、開発・障害・責任のそれぞれの単位が変わります。単位ごとに比べると、分割の影響をつかみやすくなります。

  • 変更単位:複数チームが異なる業務を頻繁に変更するか
  • 障害単位:アクセス量の変動や影響範囲の限定が課題か
  • 責任単位:運用成熟度や担当範囲が明確になっているか

機能を小さく分けると、通信、認証、リトライ、タイムアウト、分散トレーシングの扱いが増えます。開発が自動的に速くなるとは限らず、データ整合性やリリース手順も必要になります。運用が未成熟だと、複雑さがいっそう増します。

共有データベースへ複数サービスが直接つながると、依存関係が残ります。その状態では、サービスを分けても変更の独立性を失いやすくなります。

2026年1月公表のCNCF Annual Cloud Native Surveyでは、コンテナ利用者の82%がKubernetesを本番環境で利用しているとの報告があります。この数字は普及状況を示すもので、自社での採用を勧める結論ではありません。

出典はCloud Native Computing Foundation「2025 Annual Cloud Native Survey」(2026年)です。

発注前に確かめる運用の担当範囲

相談の時点で、見積もりの前提と運用の引き継ぎ範囲を、発注側と開発会社で共有しておきます。

  • 相談条件:対象業務、既存システム、ピーク負荷、目標可用性、個人情報、移行期限、内製化範囲
  • 設計・運用:見積もりに、サービス境界の設計書、API契約、データ移行計画、監視項目、障害時の連絡体制を含める
  • 引き渡し:ソースコードとクラウド環境の引き渡し条件を明記する

SIerへ一括で発注すると、要件定義から保守までの責任をまとめて預けやすくなります。ただし、再委託先やクラウド部分については、どこまでを誰が受け持つかを確認しておく必要があります。

一方で、クラウドベンダーは実行基盤の選択肢が豊富です。業務整理や実装は、別の会社が担うこともあります。

ポイント

分割の単位は、変更・障害・責任のどれを先に改善したいかで決めます。発注前に運用の担当範囲と見積もりの前提をそろえておくと、後の食い違いを減らせます。

株式会社ripla|コンサルから開発まで一貫して支援

riplaは、コンサルティングから開発まで一貫して支援できる企業です。IT事業会社として社内DXを進めた経験を活かしています。

ビジネス成果の創出とシステムの定着支援に強みがあります。営業、顧客、生産の基幹システムで実績があり、販売管理も含めて幅広く対応しています。加えて、企業の業務要件に合わせて柔軟に対応できる体制です。

特徴と強み

riplaへの相談では、業務の変更単位と運用負担をもとに構成を検討します。

  • 要件整理:現場の業務フロー、既存課題、将来追加する機能を確認する
  • 構成案:方式ごとの違いを比べる
  • 設計:責任範囲を整理する

APIの責任、認証・認可、サービスごとのデータ所有は、設計の段階で決めておきます。構成の比較対象には、モジュラーモノリス、マネージドコンテナ、Kubernetesがあります。

構成は、成果と運用負担を見て選びます。さらに、ログの保管や障害時の切り戻し方法も、あらかじめ決めておきます。

全機能を一度に分けず、変更頻度や障害影響の大きい領域から切り出します。そのうえで、段階導入のロードマップを業務部門にも伝わる形にまとめます。

得意領域・実績

複数部門にまたがる基幹システムの構築・導入を検討する企業に向いています。

  • 既存システム:ERPや販売管理を残し、連携方式を整理して周辺機能を段階追加する
  • 相談目的:マイクロサービス化の狙いを、速度・障害分離・拠点追加・負荷対応に分けて整理する
  • 見積もり:業務コンサル、設計、アプリ、クラウド、移行、監視・保守を別項目にする

株式会社日立製作所|エンタープライズのモダナイゼーションを支援

日立製作所は、モノリシックな既存システムの移行を支援する「マイクロサービステクニカルソリューション」を提供しています。メニューには、アプリ構成設計、クラウド・コンテナ移行のほか、開発プロセスや環境の設計、技術コンサルティング、PoCも含まれます。

特徴と強み

日立の製品群は、大規模環境の要件や共通機能の設計を支援します。

  • 非機能要件:大規模業務の可用性、性能、セキュリティ、運用継続性を含めて検討する
  • 共通機能:通信制御や横断機能をAPIとして提供する
  • 製品群:分散トランザクション管理などを含む

共通機能を担う製品として、Hitachi Microservices Platform(HMP)があります。企業向けの設計や標準化まで相談したい場合に、候補になります。

また、オンプレミスからの移行やDevOps環境の構築も検討できます。教育やPoCも含め、段階的に導入できます。

短期検証を行う場合は、MVP(Minimum Viable Product)にする業務領域を決めます。PoC後に本番化する条件も、事前に確かめてください。

得意領域・実績

移行の連続性や厳格な要件を重視する企業は、次の観点で候補を比べます。

  • 移行・標準化:基幹を止めない段階移行、厳格な金融・製造・公共要件、大規模組織の標準化に向く
  • 実績:カーボン・クレジット市場システムの共同開発事例がある
  • 委託範囲:コンテナ化、サービス境界、API、データ移行、運用引き継ぎを確認する
  • 製品比較:日立製品と既存クラウド・OSSのロックイン、ライセンス、保守費を分ける

ポイント

大規模な既存システムを段階的に移行するなら、事例と委託範囲を照らして候補を絞ります。日立製品は、ロックインやライセンス、保守費を既存のクラウドやOSSと分けて比べて選びます。

SCSK株式会社|クラウドネイティブ化と既存システム刷新に対応

SCSKは、企業のクラウドネイティブ化を支援する「NebulaShift」を展開しています。公式情報では、ビジョンや事業構造に沿ったシステムのモダナイズを支援するとされています。

支援範囲としては、マイグレーション、基盤設計・運用が説明されています。マイクロサービスの高度化や導入、構築に加え、教育やサポートも案内されています。

特徴と強み

オンプレミスや仮想サーバーの業務システムを段階的に移行したい企業に適します。移行先では、クラウドとコンテナを活用した構成を検討できます。

  • 支援範囲:新規・既存アプリ、アジャイル、基盤設計、運用、教育を一続きで計画する
  • 移行設計:対象を決める
  • 同期と切り戻し:移行中のデータ同期方法と戻し方を確認する
  • 費用内訳:SCSK支援、クラウド料、アプリ保守、24時間対応を分ける

残す機能と切り出す機能をどう分けるかが、移行設計の中心になります。ただし、NebulaShiftを採用しても、マイクロサービス化が完了するとは限りません。

得意領域・実績

業務を理解したうえでクラウドネイティブ技術を使いたい中堅・大企業に向きます。また、複数部門が使う基幹系で、移行後の運用や社内教育も依頼したい企業に適します。

  • 内製化支援:実績と担当者の継続性を確認する
  • 見積もり項目:現状分析、既存機能の洗い出し、PoC、基盤、分割、移行、テスト、運用、教育を分ける
  • 停止を避ける条件:並行稼働、二重書き込み、データ照合、復旧目標を金額と合わせて確認する

アマゾン ウェブ サービス ジャパン合同会社(AWS)|豊富なマネージドサービスで実行基盤を構築

AWSでは、Amazon EKS、Amazon ECS・Fargate、AWS Lambdaを組み合わせられます。Amazon API GatewayやAmazon RDSなども利用できます。

AWSは、実行環境とマネージドサービスを提供するクラウドベンダーです。業務アプリの設計・開発を一括で請け負う会社とは役割が異なるため、AWSパートナーや自社チームも含めて開発体制を比べます。

特徴と強み

AWSの方式選びでは、利用機能と料金体系を合わせて見ます。

  • EKS:サービス数や負荷に応じて選べるKubernetes構成
  • ECS・Fargate:コンテナ運用を簡素化しやすい選択肢

また、Lambdaはイベント駆動の処理に利用できます。

  • EKSの基本料金:標準サポート中は1クラスター1時間0.10米ドル
  • 別料金:EC2、EBS、ロードバランサー、パブリックIPv4などが別途かかる

そのほか、データ転送、ログ、データベースなどの費用も発生します(出典:AWS「Amazon EKSの料金」、2026年確認)。クラスター料金だけで安いと判断せず、全体の費用で比べます。

AWSの公式導入事例では、ミスミグループ本社が基幹システムのマイクロサービス化で開発スピードを3倍にしたと紹介されています。さらに、オンライン受注確定の応答時間を44%削減した事例も紹介されています。

また、AWSの公式導入事例では、ヌーラボのEKS上のデプロイが10秒から1分で完了したと説明されています。ただし、これらは個別企業の事例で、同じ効果が保証されるものではありません。自社の評価指標を設計する際の参考として扱えます。

得意領域・実績

AWS基盤を活かすには、運用体制や移植性も含めて検討します。

  • グローバル展開:グローバルに事業を広げる企業や、アクセス量の変動が大きい企業に向く
  • 複数チーム:複数チームでの開発や、サーバーレスとコンテナの使い分けに適する

マネージドサービスは運用負荷を減らせる一方で、設計力とコスト管理が求められます。そのため、資格の有無だけでなく、業務システムの移行実績やSRE体制も確認します。

発注時は、AWS利用料、導入支援費、アプリ開発費を分けて考えます。監視・障害対応費も、別に見積もってもらいます。

開発会社がアカウントを管理する場合は、ログ閲覧権限や請求情報の扱いを確かめます。退職や契約終了時の引き渡し、障害時の連絡先も、契約に定めておきます。

他クラウドへ移る可能性があるなら、コンテナイメージの扱いを確かめます。TerraformなどのIaCや、データのエクスポート方法も見ておきます。

ポイント

AWSは、EKSの基本料金だけで比べず、別料金の項目と運用体制を合わせて見るのが目安です。資格よりも移行実績とSRE体制を確かめると、発注先の判断がつけやすくなります。

グーグル・クラウド・ジャパン合同会社(Google Cloud)|GKEとCloud Runを要件で使い分け

GKEの細かな実行環境制御とCloud Runの基盤運用の抑制を対比した図
トラフィックや常時稼働の要否、チームの運用スキルも選択時に確認します。

Google Cloudでは、Google Kubernetes Engine(GKE)を利用できます。コンテナ実行のCloud Runや、API管理のApigeeも組み合わせられます。

GKEは、実行環境を細かく制御したい場合に検討できます。一方で、Cloud Runは基盤の運用を抑えたい場合に選べます。使い分けは、トラフィック、常時稼働の要否、チームの運用スキルで判断します。

特徴と強み

Cloud Runは、利用したリソースに応じて課金されます。デフォルトでは、リクエスト処理中の時間などをもとに計算されます。

リクエストがないときにはインスタンスをゼロまで減らせるため、検証環境やアクセス変動の大きいサービスでは、費用を抑えやすい選択肢です。

  • 起動条件:初回起動の遅延と最小インスタンス設定を試算する
  • 追加費用:VPC、DB、ログ、外向き通信も確認する(出典:Google Cloud「Cloud Run pricing」、2026年確認)

GKEを使う場合は、どこまでをマネージドに任せるかを決めておきます。対象には、ノードやクラスタ、監視、ネットワークが含まれます。

API公開や認証を統一する設計も可能です。レート制限やバージョン管理も含めて、Apigeeなどを使う案も検討できます。

費用は、公式料金ページをもとに、開発・検証・本番のプロジェクトを分けて試算します。分割後の固定費と従量費を比べてください。

得意領域・実績

クラウドネイティブな新規サービスを小さく始めたい企業や、イベント・リクエスト量が変動する企業に向いています。データ分析やAI基盤との連携を考える場合にも、検討の対象になります。

Cloud Runなら、少人数でもKubernetesクラスタの細かな運用を避けられます。

  • GKEが候補:常時稼働の高負荷や複雑なネットワークがある
  • 既存要件:特殊なスケジューリングやKubernetes標準がある

提案時には、Cloud RunとGKEの採用理由を比べてもらいます。あわせて、サービス間通信、秘密情報管理、分散トレーシングも確認します。障害時の再実行方法も、具体的に説明してもらうとよいでしょう。

日本マイクロソフト株式会社(Microsoft Azure)|少人数運用にも配慮したコンテナ基盤

日本マイクロソフトは、Azure Kubernetes Service(AKS)を提供しています。Azure Container Apps、Azure API Management、Azure Service Busも利用できます。

Microsoft Entra IDやAzure Monitorなども組み合わせられます。Kubernetesを運用する場合はAKSを、デプロイと自動スケールを簡素化したい場合はContainer Appsを検討できます。

特徴と強み

Container Appsには、同じ環境内のアプリ間で使えるサービスディスカバリとルーティングが組み込まれています。Microsoft Learnでは、アプリ名による通信やDaprによるサービス呼び出しが案内されています。さらに、相互TLS、リトライ、分散トレーシングなども案内されています。

  • HTTP処理:HTTPトラフィックがないときにゼロまでスケールできる
  • イベント駆動:イベントに応じてスケールできます

メッセージ数などに応じたスケールも可能で、Microsoft Learnでも案内されています。出典はMicrosoft Learn「Microservices with Azure Container Apps」(2025年更新)です。

Microsoft製品を使っている企業であれば、Entra ID認証などを組み合わせられます。Service Busによる非同期連携やAzure Monitorによる監視も、検討材料になります。

既存のActive Directoryや業務アプリとの権限設計が曖昧なままだと、認可の扱いがそろわなくなります。そのため、業務ロール、管理者権限、サービス間の認証方式を設計書に含めておく必要があります。

得意領域・実績

Microsoft 365やEntra IDを利用する企業に向いています。.NETやSQL Serverを使う企業にも適しています。業務アプリを段階的にコンテナ化したい企業も候補になります。

少人数のプラットフォームチームで運用負担を抑えたい場合にも適します。AKSとContainer Appsは、ネットワーク制御や常時稼働の要件で選び分けます。イベント処理、運用スキル、将来の移植性も判断材料です。

  • Azure費用:利用料とサポート契約を分ける
  • 開発・運用費:アプリ、API、ID、監視、バックアップも別建てにする

運用当番も含めて、費用を確認してください。リトライやサーキットブレーカーの設定に加えて、重複処理時の業務上の扱いや、メッセージの保管日数を決めておく必要があります。復旧後に再実行する順序も、確認することが大切です。

マイクロサービス基盤のパートナー選びのポイント

パートナー選びで業務境界・移行方法・設計理由・費用の内訳を確認する図
同じ観点を各社の提案に当てはめると、比較の抜けに気づけます。

6社はそれぞれ役割が異なります。ripla、日立、SCSKはSIer候補で、業務整理から開発、移行、運用まで相談しやすい会社です。

AWS、Google Cloud、Azureは、実行基盤を提供する候補です。直接相談しても、設計・開発・運用のパートナーが別途必要な場合があります。契約主体と責任範囲は、発注前に整理してください。

実績と経験の確認観点

実績では、まず相手の経験の中身を確かめます。

  • 業務境界:件数だけでなく、どの業務をどう分けたか尋ねる
  • 移行方法:既存モノリスからの順序とデータ整合性を確認する

販売と在庫、顧客などを分ける場合でも、受注確定と在庫引当を同じトランザクションで扱う必要がある場合があります。その場合は、非同期化の失敗時に業務をどう戻すかの説明を求めます。

導入事例では、効果だけでなく移行期間、停止時間、運用人数を確認します。あわせて、リリース頻度や障害対応がどう変わったかも尋ねます。

本番後のオンコール、脆弱性対応、Kubernetes更新の担当者も確認します。ログ保管やバックアップテストの担当を聞くと、運用経験を見分けやすくなります。

技術力の評価軸:採用製品より設計理由

提案された製品より、要件に合う構成を選ぶ理由を確認します。

  • 確認事項:要件を整理したうえでの、Kubernetes、Cloud Run、Container Appsの選び分け。
  • 確認事項:サービス数、常時稼働、ピーク負荷、ネットワーク制御といった要件の提示。

データ所在、チームの運用スキル、クラウド移行方針も共有します。採用する構成が必要な理由を説明してもらいます。

小規模なCRUD業務や変更の少ないシステムでは、別案が合う場合があります。モジュラーモノリスやマネージドPaaSは、費用と運用のバランスに優れることがあります。

OWASP API Security Top 10 2023では、認可などのリスクが挙げられています。機微な業務フローへの無制限アクセスや、安全でないAPI利用も対象です。出典はOWASP Foundation「API Security Top 10 2023」(2023年)です。

認証だけでなく、オブジェクト単位の認可やレート制限も設計します。入力検証や外部APIの検証も、設計に含めます。監査ログと秘密情報の保管も、あわせて決めます。

費用の内訳:初期開発・移行・運用・クラウド利用料

案件の規模と移行範囲をそろえたうえで、費用の前提を比べます。

  • 確認事項:日本市場には、マイクロサービス基盤の統一された標準価格表がありません。
  • 確認事項:金額は、2025〜2026年のクラウド公式料金や、一般的な人月単価からの推定です。

基盤構築・移行の工数も使って、費用の幅を組み立てています。PoCや小規模新規開発で3〜5サービスを整える場合は、基本監視とCI/CDを含めて、初期500万〜1,500万円、期間1〜3か月が目安です。

5〜15サービスの本番運用では、初期1,500万〜4,000万円が推定されます。API管理やRDB、非同期処理のほか、検証環境と本番環境を含む規模です。この小〜中規模案件は、期間3〜6か月程度と推定されます。

15〜50サービスの大規模案件では、5,000万〜2億円超となる可能性があります。複数AZやサービス別DBを含む構成で、災害対策と厳格な監査も加わる場合の推定です。

既存データ移行も含むと、期間は9〜18か月になる可能性があります。金額は要件と責任分担で変わるため、断定的な相場ではありません。

エンジニア4〜6人を4〜6か月配置する人件費を試算します。1人月80万〜120万円なら、約1,280万〜4,320万円です。

この試算は人件費のみで、PM、QA、セキュリティなどは別です。さらに、設計レビュー、移行、予備費も加わります。

クラウド費は、CPU・メモリだけでなく関連サービスも含めて試算します。ロードバランサーやDBのほか、ストレージやバックアップ、ログ、監視も対象です。

データ転送、固定IP、サポートも含め、月額で見積もってください。

ポイント

迷ったときは、件数より業務の分け方と移行方法、製品名より設計理由で判断します。費用は初期開発・移行・運用・クラウド利用料に分けて、同じ前提で比べます。

マイクロサービス基盤に関するよくある質問

発注を進める段階では、技術用語の比較とは別に、判断に迷う疑問が出てきます。ここでは、費用、Kubernetes、既存システム移行などの疑問に答えます。

マイクロサービス基盤の開発費用はいくらですか?

開発規模や移行対象によって、必要な予算帯は異なります。

  • 確認事項:小規模PoCは500万〜1,500万円、本番の小〜中規模基盤は1,500万〜4,000万円が目安です。
  • 確認事項:大規模移行を含む場合は、5,000万〜2億円超と推定されます。

サービス数に加えて、既存データ移行や可用性、運用体制によって金額が変わります。連携や監査の要件も、金額を左右します。初期開発費と月額のクラウド・保守費を分けて見積もってください。

マイクロサービスならKubernetesが必須ですか?

選択の基準は、求める制御の範囲と運用体制です。

  • 確認事項:Kubernetesは必須ではありません。
  • 確認事項:複雑なネットワーク制御、サービス数、移植性が必要ならGKE、EKS、AKSを検討します。

標準化されたプラットフォーム運用が必要な場合も、これらが候補です。一方で、人員が限られる新規サービスや小規模構成では、別の選択肢もあります。Cloud Run、Fargate、Azure Container Appsなどが適することがあります。

採用理由と将来の運用費を説明できる会社を選んでください。

既存のモノリスを一度にマイクロサービス化すべきですか?

既存移行では、対象業務と切り出す方法を段階ごとに決めます。

  • 確認事項:一度に全面移行する必要はありません。
  • 確認事項:変更頻度や負荷変動が大きい業務を、一つ選んで段階移行します。

障害影響を切り離したい領域も候補になります。ストラングラーパターンなどで、外側から切り出す方法が現実的です。

移行計画には、データ同期と並行稼働を含めます。照合と切り戻しの手順も、計画に入れます。利用者への影響は、PoCと本番移行計画の両方で確かめます。

開発会社とクラウドベンダーはどちらに相談すべきですか?

相談先は、設計から運用までの依頼範囲によって選びます。

  • 確認事項:業務要件、既存システム、移行、利用者定着、運用まで一括相談するならSIerや開発会社が向きます。
  • 確認事項:AWS、Google Cloud、Azureを先に指定するなら、認定パートナーとの組み合わせを検討します。

どちらの場合も、アプリや基盤の責任を確認します。データ、監視、障害対応の受け持ちも、同じように確かめます。どこまでを誰が受け持つかは、一枚の図と契約書で明確にしておきます。

ポイント

迷ったときは、Kubernetesを採用するかどうかを求める制御の範囲と運用体制で決め、移行は対象業務ごとに段階を区切って進めます。費用は初期開発費と月額費を分けて見積もります。

まとめ

会社選びでは、業務開発・移行を担う会社と、実行基盤を提供する会社を分けて比べます。

候補は、ripla、日立製作所、SCSKと、AWS、Google Cloud、Microsoft Azureの6社です。

知名度やKubernetes採用だけでなく、サービス境界やデータ所有も確認します。APIセキュリティや監視も確かめてください。障害対応と移行計画も、同様に見ておきます。

6社の役割の違い

SIerや開発会社に頼むか、基盤を決めてパートナーを組むかで、発注の方法が変わります。業務整理から既存移行、アプリ開発、クラウド運用まで、必要な範囲を整理します。

同じ前提を各社に示し、役割と責任範囲を比べます。

問い合わせ前の業務と運用の条件整理

問い合わせ前に、費用項目と導入後の効果を測る指標を整理します。

  • 確認事項:費用は、アプリ開発と基盤構築、既存連携や移行に分けて見積もります。
  • 確認事項:セキュリティ・監視、保守・SRE、クラウド従量費も、別々に扱います。

小さなPoCで効果を測り、変更リードタイムやデプロイ頻度を確認します。そのうえで、障害影響範囲、MTTR、クラウド単価も見ながら、必要な範囲だけを段階的に広げます。

対象業務と現行構成を整理したうえで、複数社に同じ条件で相談すると、納得できる発注につながります。

▼全体ガイドの記事
・マイクロサービス基盤開発の完全ガイド

会社紹介

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

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

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

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

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

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