マイクロサービス基盤は、業務の変更速度、チームの責任範囲、障害の影響範囲を分けて、複数チームの継続開発や段階的な刷新を支える土台です。
導入判断から費用、発注先の選び方までを順に並べた一覧です。詳しくは関連記事もご覧ください。
▼関連記事一覧
・マイクロサービス基盤開発の進め方/やり方/流れや方法/手法/工程/手順
・マイクロサービス基盤開発でおすすめの開発会社/ベンダー6選と選び方
・マイクロサービス基盤開発の見積相場や費用/コスト/値段について
・マイクロサービス基盤開発の発注/外注/依頼/委託方法について
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
マイクロサービス基盤の全体像
マイクロサービス基盤は、利用者には一つの業務システムとして見せながら、サービスを安全に分けるための共通機能と運用ルールを整えるものです。複数のアプリを並べるだけでは、この状態にはなりません。
アプリを分割するだけでは基盤にならない理由
基盤には、サービスに共通する機能と運用の要素を備えておきます。
- 入口・通信：APIゲートウェイまたはBFFと、サービス間通信の整備
- 実行・データ：認証・認可、コンテナなどの実行環境、サービス別データ管理
- 開発・運用：CI/CD、IaC、ログ、メトリクス、分散トレーシング、シークレット管理の共通化
- 障害対策：タイムアウト、リトライ、サーキットブレーカー、非同期キュー、代替表示の取り決め
要素がサービスごとに異なると、チームは機能開発よりも、接続方式や障害調査の調整に時間を使うことになります。また、在庫サービスが止まっても受注サービスへ影響が広がらないよう、設計の段階で備えておく必要があります。
調整の手間を減らす土台として、マイクロサービス基盤は、分散環境でも壊れにくく、調べやすく、同じ手順でリリースできる状態を組織の標準として提供します。
モノリス・モジュラーモノリスとの違い
モノリスは、一つのアプリケーションとして開発し、デプロイする方式です。構造が単純なため、小規模な業務や変更の少ないシステムでは合理的といえます。
モジュラーモノリスは、一つのアプリケーションの内側を業務モジュールに分ける方式です。将来の分割に備えつつ、運用の複雑さを抑えられる点が特徴です。
マイクロサービスは独立してデプロイしやすい一方、通信やデータ整合性、障害対応が複雑になります。さらに、監視や権限も複雑になります。判断では、サービスの数よりも、変更・障害・責任の単位を分ける事業上の理由を重視します。
マイクロサービス基盤の必要性
必要性は、事業の変更速度と運用の能力で判断します。複数のチームが同時に開発し、機能ごとにリリース頻度や負荷の特性が異なる場合には、有力な選択肢になります。
障害の影響範囲を分けたい場合にも、検討の対象になります。一方で、単一のチームが少数の画面を管理するだけであれば、モジュラーモノリスの方が総保有コストを抑えられることがあります。
導入効果が出やすい業務システム
導入効果が出やすいのは、次のような状況です。
- チームと業務領域：販売、在庫、顧客、請求などで担当チームが分かれている場合
- 変更や負荷の違い：業務領域ごとの変更頻度やピーク負荷の差
- 段階的な刷新：既存基幹システムのうち、変更頻度が高く、影響を小さく検証できる領域から切り出す進め方
たとえば、キャンペーン時にアクセスが増える注文機能と、月末に処理が集中する請求機能は、別々に拡張できます。
この進め方なら、一度に全機能を作り直すリスクを減らせます。ただし、分割後にデータとSLOを誰が管理するかを決めておくことが前提になります。
向いていないケースと代替案
次のような業務では、導入後に複雑さのほうが先に目立つことがあります。
- 小規模な業務：CRUD中心で、扱う機能が限られるケース
- 変更の少ない業務：社内ツールなど、変更頻度の低いシステム
- 厳密な一貫性が必要な業務：トランザクションを一つのデータベースで完結させる構成
通信障害を考慮した設計、監視、テストなどに加えて、オンコールの体制も必要になります。この負担が業務上の価値を上回る可能性があるためです。
代替案は、モジュラーモノリスでドメインの境界とAPI契約を整理し、デプロイや監視を自動化する方法です。そのうえで、特定の領域で負荷や変更が増えた時点で分離すれば、技術の選択を後戻りできる状態に保てます。
マイクロサービス基盤の主な構成要素
構成要素は、利用者から見える入口、実行環境、サービス間通信、データ、開発・運用の自動化に分けると整理しやすくなります。共通化する範囲は、業務の可用性やセキュリティ、運用の人数に応じて決めます。
入口・通信・実行環境
入口、通信、実行環境には、それぞれ次のような役割があります。
- APIゲートウェイ・BFF：認証・認可、ルーティング、レート制限、APIバージョン管理、外部向けレスポンス整形
- サービス間通信：即時応答が不要な在庫更新や通知を、メッセージキューやイベントバス経由で扱う方式
- 実行環境：コンテナの常時稼働、必要時のみ起動するサーバーレス、複数サービスを統合管理するKubernetesのいずれか
非同期化は連鎖障害を抑えるうえで役立ちます。Kubernetesは標準化と柔軟性に優れる反面、クラスタの更新や権限、コスト管理などの知識が要ります。そのため、運用人員が限られる場合は、管理範囲の少ないマネージドな実行環境から始める判断も合理的です。
データ・可観測性・セキュリティ
データは、サービスごとに所有者を決め、別のサービスが他のデータベースへ直接書き込まない設計を基本にします。整合性が必要な処理では、業務イベント、冪等性キー、補償処理を設計し、再実行の手順もあらかじめ定めておきます。
可観測性では、リクエストIDやトレースIDを使って、処理を横断して追えるようにします。稼働率に加えて、レイテンシとエラー率も把握できるようにします。キューの滞留やデプロイ頻度、平均復旧時間も、併せて見ます。
認証情報や個人情報を、ログへ出さない設計も欠かせません。さらに、ログの保存期間と閲覧の権限も管理します。
サービス分割とデータ設計の考え方
サービス分割がうまくいくかどうかは、使うプログラミング言語よりも、境界の設計で決まります。境界を決めるには、業務用語と責任者を整理し、変更の理由とデータの所有権を明らかにします。そのうえで、サービス間の依存を必要最小限に抑えます。
業務上の境界を技術の構造に反映するときには、ドメイン駆動設計の考え方が役立ちます。
販売・在庫・顧客・請求の分け方
業務を切り分けるときは、候補となる領域を挙げたうえで、境界を決める観点と運用期間の両面から見ていきます。
- 分割候補：販売、在庫、顧客、請求などの業務領域
- 境界の判断観点：業務上の責任、変更頻度、障害時の代替策、チームの責任範囲、データ整合性の要件
- 運用期間：数日で切り出せるかより、数年にわたって運用できる境界かどうか
同じ業務用語でも、責任者や更新の頻度が異なることがあります。
たとえば、販売サービスが注文の受付と状態の管理を担い、在庫サービスが引当と出荷可能数を担う形があります。このとき、販売側が在庫データを直接更新せず、引当を依頼して結果をイベントで受け取ると、責任の境界がはっきりします。
細かく分けすぎると、1つの画面を表示するだけで多くのAPIを呼び出すことになります。
共有データベースを避ける設計
複数のサービスが一つのデータベースを直接読み書きすると、スキーマ変更の調整が増え、独立したデプロイの利点が失われます。そのため、サービスごとにデータの所有者を決め、ほかのサービスはAPIまたはイベントを通じて利用する形にします。
即時の整合性が要らない処理では結果整合性を受け入れ、重複したイベントを一度だけ反映する冪等性を持たせます。共有が必要な場合は、恒久化を避けて、移行期限、利用範囲、廃止条件を設計書に明記します。
クラウド・実行基盤の選び方
クラウドは、可用性やネットワーク接続、既存契約などから評価します。データの所在や運用人数、将来の移行可能性も含めて比べると、ブランド名だけで選ぶ判断を避けられます。
マネージドサービスは運用の負担を減らしやすい一方で、サービス固有の機能への依存や、従量課金の把握が必要になります。
マネージドPaaS・コンテナ・Kubernetesの比較
実行基盤は、チームの運用体制と、必要な制御の細かさに応じて選びます。
- マネージドPaaS・サーバーレスコンテナ：少人数チームやPoCに向き、クラスタ更新やノード管理を減らせる点が特徴
- 台数調整できる環境：常時稼働が必要なサービスにも使え、初期の運用負担を抑えやすい選択肢
- Kubernetes：複数チームで共通のデプロイ標準を持つ場合や、細かなスケジューリング・ネットワーク制御が要る場合
CNCFの2025年調査では、コンテナ利用者の82%が本番環境でKubernetesを使っています（出典：CNCF Annual Cloud Native Survey 2025、2026年公表）。
普及していることは選ぶ理由になります。ただし、運用人材が不足したまま採用すると、基盤がボトルネックになります。
比較時に確認する五つの観点
実行基盤を比べるときは、処理量から移行可能性までを見ます。
- 処理量：平常時とピーク時に分けた測定
- 可用性：複数ゾーン、バックアップ、災害復旧の目標
- 運用機能：監視、ログ、トレース、脆弱性スキャン、秘密情報管理との連携
- 既存接続：ERP、販売・倉庫管理、会計、認証基盤との接続方法とネットワーク費
- 移行可能性：データ、設定、コンテナイメージ、IaCを持ち出せるかどうか
比較では、月額の安さだけでなく、設計・運用・移行を含む5年間のTCOを見ます。
マイクロサービス基盤開発の進め方
開発は、業務と運用の現状を把握し、効果を測れる小さな範囲から始めるのが基本です。そのうえで、企画から移行、リリース後の改善まで段階ごとに計画を立て、各段階に中止や見直しの基準を設けます。
▶ 詳細はこちら：マイクロサービス基盤開発の進め方/やり方/流れや方法/手法/工程/手順
企画・要件定義の決定事項
まず、対象業務と利用者、ピーク時の負荷を整理します。次に、可用性と復旧目標、個人情報の扱いを決めます。さらに、既存連携、移行期限、内製化の希望も確認します。
モノリスのまま改善する場合と分割する場合を比べます。その際は、開発速度や障害の影響、運用の工数、5年間のTCOを仮置きしておきます。
作成して残す資料には、コンテキストマップやサービス候補、API契約などを含めます。データ所有者や非同期処理の一覧、SLOなどに加えて、障害時の業務継続方針も書き残します。過剰設計を防ぐため、分割しない領域も明示します。
PoC・設計・開発での検証項目
PoCと本開発では、確かめる内容が段階によって異なります。
- PoC：最も難しい機能で、独立デプロイ、障害分離、データ連携、監視、権限管理、開発者の作業時間の測定
- 本開発：共通テンプレート、CI/CD、テスト環境、ログ形式、アラート基準の先行整備
在庫引当を切り出す場合は、通信が失敗したときの再処理と、二重引当の防止も検証します。
各サービスが、ビルドやテスト、脆弱性検査、リリースを同じ方法で行えば、サービスが増えた後のばらつきを抑えられます。
段階移行・テスト・リリース
段階移行からリリース後の確認までは、次の順で進めます。
- ストラングラーパターンなどで既存機能の外側に新APIを置き、変更頻度の高い領域から切り出す順序
- データ同期の開始時点、二重書き込みの期間、照合方法、切り戻しの条件、並行稼働の終了条件
- 単体、契約、負荷、障害注入、権限の各テストと、バックアップ復元および災害復旧の訓練
- リリース後のデプロイ頻度、変更リードタイム、変更失敗率、平均復旧時間、SLO達成率の測定
測定結果をもとに、技術の導入が事業の成果につながったかどうかを確認します。
マイクロサービス基盤の費用相場と期間
サービス数や移行範囲をまたいで使える、公的な標準価格表はありません。以下に示すのは、エンジニア単価、クラウドの公式料金、一般的な業務システム開発の工数から組み立てた推定のレンジです。確定した見積もりではありません。
金額は、PoCか本番か、既存データを移行するか、24時間運用が必要かによって、大きく変わります。
▶ 詳細はこちら：マイクロサービス基盤開発の見積相場や費用/コスト/値段について
規模別の初期費用・運用費・期間
PoCから本番規模へ広がると、必要な環境も運用の範囲も増えていきます。
- PoC・小規模新規：初期500万〜1,500万円、期間1〜3か月、月5万〜30万円の目安
- 小〜中規模本番：初期1,500万〜4,000万円、期間3〜6か月、月30万〜150万円の目安
- 大規模基盤：初期5,000万〜2億円超、期間9〜18か月、月150万〜800万円超となる可能性
PoC・小規模新規は、3〜5サービスを対象に、マネージド実行環境やCI/CD、基本監視を整える想定です。
小〜中規模本番は5〜15サービスを対象に、API管理やデータベース、非同期処理、検証・本番環境まで含む想定です。
大規模基盤は15〜50サービスを対象に、複数の可用性ゾーンやサービス別データベースを置く想定です。さらに、災害復旧、厳格な監査、既存基幹からの移行まで含みます。
これらは、要件を分解して検討するための初期レンジとして見てください。
見積書で分けるべき費目
見積もりでは、初期費用と継続費用を次のように分けて見ます。
- 開発・移行：アプリ開発、基盤構築、既存連携、データ移行、テストの区分
- 品質・定着：セキュリティ、監視、ドキュメント、教育、保守の区分
- 人月の試算：月80万〜120万円のエンジニアを4〜6人、4〜6か月配置した場合の約1,280万〜4,320万円
- クラウド利用：CPU・メモリ、ロードバランサー、ストレージ、DB、バックアップ、ログ、監視、固定IP、転送、複数環境の費用
PMやQA、設計レビュー、移行リハーサル、予備費も加わります。そのため、基盤案件はアプリ機能だけの見積もりより高くなりやすいです。
マネージドKubernetesの標準サポート料金は、クラスターあたり0.10米ドル/時間です（出典：マネージドKubernetes公式料金表、2026年8月確認）。ノードやストレージ、IP、転送などは別途必要になります。したがって、小さな単価だけを見ても、月額は判断できません。
セキュリティ・法務・運用の必須確認事項
サービスが増えると、守るべき場所も増えていきます。入口やサービス間の通信、データベース、CI/CD、運用者の権限などが対象になります。
後から対策を足すと、API契約やログ設計をやり直すことになりやすいため、認証・認可、秘密情報、脆弱性管理、監査ログは要件定義の段階から組み込みます。
APIの認証・認可とサプライチェーン対策
APIとサプライチェーンでは、次のような対策を設計します。
- 認証・認可：対象の注文・顧客・在庫を操作できるかを、オブジェクト単位で確かめる仕組み
- APIの保護：入力検証、レート制限、過剰なデータ返却、管理APIの公開、サービス間認証、失効トークンへの対応
- 依存物の管理：ライブラリとコンテナのスキャン、修正期限、例外承認、イメージ署名、秘密情報のローテーションを含む運用手順
OWASP API Security Top 10 2023は、認可の不備を重要なリスクとして挙げています。
OWASP API Security Top 10 2023の一覧には、機密性の高い業務フローへの無制限アクセスや設定の不備、外部APIの安全でない利用も含まれます（出典：OWASP API Security Top 10 2023、2023年版）。
個人情報・委託・再委託の確認
個人情報を扱う場合は、管理の対象と確認事項をはっきりさせます。
- データと権限：サービスごとの個人データ、保存リージョン、管理者権限を台帳にまとめる作業
- 委託先の範囲：再委託先、クラウドのサポート担当、ログ解析、バックアップ経路も対象
- 契約と地域：契約、監査、事故時の報告期限、保守や障害対応時のアクセス可能性
個人情報保護委員会の外国第三者提供ガイドラインは、再委託先の事前報告や承認、取扱方法の確認、必要に応じた定期監査などを示しています（出典：個人情報保護委員会「外国にある第三者への提供編」、2025年12月一部改正）。
SLO・障害対応・運用KPI
運用を始める前に、サービスごとのSLOと依存先を決めます。そのうえで、オンコールの担当や重大度、連絡経路、切り戻し手順を定めます。さらに、業務への影響を判断して代替運用へ切り替える責任者もはっきりさせます。
稼働率だけでなく、変更リードタイムやデプロイ頻度、変更失敗率、平均復旧時間を見ます。加えて、アラートの誤検知率、クラウド費用の単位コスト、未対応脆弱性の滞留日数も確認します。
成果は、サービス数の多さよりも、リリースの安全性と業務継続性の改善で判断します。
よくある失敗と対策
失敗の多くは、境界や運用、費用、移行の前提が曖昧なまま開発を始めることで起こります。調整の手間は本番後に表に出やすいため、失敗のパターンを設計レビューに含めます。
早過ぎる分割と共有DB
初期に細かく分けすぎると、API契約やデプロイ、監視、テストが増え、業務の理解が追いつかなくなります。最初のPoCは、変更の頻度や障害の影響が明らかに異なる一つか二つの領域に絞ります。
分割後の運用時間も測ります。また、共有のDBでは、データの責任者が曖昧になり、スキーマ変更が全チームの調整事項になります。
移行の期間だけ共有が必要な場合は、例外として扱います。そのうえで、データを所有するサービス、参照API、移行の完了条件を明示します。
同期APIの連鎖・ログ不足・費用漏れ
一つの画面から多くの同期APIを順に呼ぶと、どれか一つの遅延が全体に広がります。タイムアウトの設定だけでなく、非同期化やキャッシュ、フォールバックまで設計します。キューの再処理や依存先のSLOも、あわせて決めます。
障害の原因を追うには、サービスごとのログだけでなく、相関ID、構造化ログ、分散トレース、業務IDをそろえておく必要があります。テスト環境では、障害を追跡できるかを確かめます。
承認を取るときは、開発費に加えて、監視やオンコール、バックアップ、データ転送、セキュリティ対応を含む運用予算を別枠で立てます。
開発会社/ベンダー・サービスの選び方
実装を担う会社と、クラウド基盤を提供する会社は、役割が違うものとして比べます。そのうえで、業務の整理からアプリ開発、クラウド設計、移行、24時間運用まで、担当が誰かを分けて確認します。
複数の専門会社に分けて任せる場合は、会社ごとにどこまでを受け持つかも比べます。
実績と技術力を確認する質問
実績と技術力は、次のような内容で確かめます。
- 導入実績：分割した業務とサービス数、既存システムの移行方法、稼働後に改善した指標
- 提案資料：サービス境界図、API契約例、データ移行方式、障害時の切り戻し、監視画面のサンプルの提示
- 技術と説明力：データ整合性、API認可、負荷試験、脆弱性対応、IaC、CI/CD、分散トレーシングへの答えと、業務制約とトレードオフの説明
評価では、コンテナやKubernetesの経験に加えて、回答が製品名の羅列で終わっていないかを確かめます。
見積もり・体制・契約の比較
見積もり、契約、体制は、次の点で比べます。
- 見積もり：アプリ開発・基盤構築、移行、テスト、セキュリティ・運用設計、教育の区分と、前提や対象外の明記
- 契約方式：固定価格か準委任か、変更時の単価と承認方法
- 体制・引き継ぎ：各担当の役割分担（責任者、アーキテクト、SRE、セキュリティ・業務・保守）、再委託範囲、障害連絡、コード・設定・設計書の引き渡し
- 契約終了時：契約に含める移行支援と、個人データの削除証明
後から増えやすい費目まで示された提案は、安い一括見積もりより比べやすくなります。
▶ 詳細はこちら：マイクロサービス基盤開発でおすすめの開発会社/ベンダー6選と選び方
▶ 詳細はこちら：マイクロサービス基盤開発の発注/外注/依頼/委託方法について
よくある質問
導入前によく寄せられる疑問に、順に答えます。
判断に迷ったときは、技術の新しさよりも、変更頻度、チームの責任範囲、障害の影響、運用費、移行の安全性を、自社の条件に当てはめて考えます。
マイクロサービス基盤の開発費用はいくらですか？
PoCや小規模新規は500万〜1,500万円、小〜中規模本番は1,500万〜4,000万円が推定の目安です。大規模な移行や災害復旧、監査まで含めると、5,000万〜2億円超になる場合があります。
サービス数だけでなく、移行や可用性、運用時間、セキュリティ、既存連携ごとに分けて見積もります。
小規模企業でもKubernetesを使うべきですか？
Kubernetesは、共通基盤や細かな自動化、移行可能性、複雑なネットワーク制御が要り、運用人員と予算がある場合に検討する選択肢です。
小規模なら、管理範囲の少ないマネージドPaaSやコンテナ実行環境、モジュラーモノリスから始めるほうが適切なこともあります。
既存のモノリスを止めずに移行できますか？
段階移行と並行稼働を設計すれば、止めずに移行することは可能です。まずAPIの入口を整え、変更頻度の高い領域から切り出します。
データ同期や照合、切り戻しの条件、業務部門の受入テストを準備します。二重書き込みやデータの不整合を放置すると移行が長引くため、各段階に終了条件を設定します。
開発会社へ相談する前に何を用意すべきですか？
まず、対象業務と現行のシステム構成、利用者数を整理します。そのうえで、ピーク負荷や可用性、個人情報の有無を書き出し、既存連携や移行期限、希望する運用体制も加えます。
仕様が決まっていなくても、課題や制約、変えたくない業務、PoCで検証したい仮説を示せば、提案を同じ条件で比べられます。
まとめ
マイクロサービス基盤は、変更や障害の単位、データの責任、開発と運用の標準を設計する仕組みです。複数のチームで機能を継続的に変えたい場合や、負荷と障害の影響を領域ごとに分けたい場合に、効果を発揮します。既存システムを段階的に刷新したい場合にも役立ちます。
導入判断の優先事項
最初に、モノリス、モジュラーモノリス、マイクロサービスを比べます。その際は、変更頻度やチーム数、負荷の変動を見ます。さらに、障害の分離、運用人材、TCOも確かめます。
マイクロサービスを採用する場合は、販売、在庫、顧客、請求などの境界も決めます。要件には、サービス別のデータやAPI認可、可観測性に加えて、段階移行と切り戻しも含めます。
見積もりは、アプリ開発費に加えて、基盤、データ移行、監視、セキュリティ、保守、クラウドの従量費に分けて見ます。判断は、技術の新しさやサービス数よりも、業務の変更速度と運用の持続性に対する成果で行います。
発注前に用意する資料
発注の前に、現行の構成図や業務フロー、データ項目を集めておきます。そのうえで、ピーク負荷や可用性、復旧目標、個人情報の範囲を書き出します。移行期限や運用体制、PoCで検証したい課題も、あわせてまとめます。
候補先には、サービス境界、担当の分け方、見積もりの前提、運用開始後の支援、契約終了時の移行方法を、同じ条件で質問します。
▼関連記事一覧
・マイクロサービス基盤開発の進め方/やり方/流れや方法/手法/工程/手順
・マイクロサービス基盤開発でおすすめの開発会社/ベンダー6選と選び方
・マイクロサービス基盤開発の見積相場や費用/コスト/値段について
・マイクロサービス基盤開発の発注/外注/依頼/委託方法について
▼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を創業。