Azure Cosmos DBのシステム開発は、要件整理、PoC、開発・移行、運用引き継ぎの順に進め、各段階で性能と費用を実測しながら発注の範囲を決めていきます。
発注形態、要件整理、費用、委託先の選び方は、この流れの中で決めることになります。全体像は完全ガイドでも確認できます。
▼全体ガイドの記事
・Azure Cosmos DBのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Azure Cosmos DBのシステムを発注する前に知っておく全体像
Azure Cosmos DBは、Azure上で提供されるフルマネージドの分散NoSQLデータベースです。JSONドキュメントを扱うNoSQL APIに加え、MongoDB、Cassandra、Gremlin、TableなどのAPIを選べます。そのため、既存の知識や移行元の構成に応じて開発方式を検討できます。
Cosmos DBと相性がよい業務システム
読み書きが多く、データ項目の追加や変更が頻繁な領域では、候補になりやすいです。たとえば、会員プロフィールや商品カタログ、注文状態が該当します。
さらに、セッションやチャット履歴も対象になります。IoTの時系列データやリアルタイム在庫も含まれます。
- 複数リージョン：レプリケーションやマルチリージョン書き込みに対応しています。
- 整合性レベル：複数の選択肢から、要件に合うものを選べます。
- イベント連携：Change Feedを、グローバルサービスやイベント駆動型の業務で使えます。
複雑なリレーション、自由度の高い集計帳票、厳密なトランザクションが中心なら、Azure SQLなどのRDBとの役割分担が適切な場合があります。そのため、「Azureを使いたい」と先に決めず、アクセスパターンとデータの関係性を示したうえで、Cosmos DBを採用する理由を委託先と検証します。
発注時に押さえるCosmos DB固有の設計論点
Cosmos DBでは、テーブルを正規化してから画面を作るRDBのやり方とは違い、「どのデータを、どのキーで、どの地域から、どの頻度で読むか」を先に決めます。
- コンテナー：扱うデータの単位の設計。
- パーティションキー：アクセスパターンに合わせた候補の検討。
- インデックス・整合性：要件に合わせた設定。
これらの設計を誤ると、ホットパーティションやクロスパーティションクエリが発生します。その結果、性能だけでなく、RU消費と月額料金にも影響します。
RFPには、同時アクセス数、通常時とピーク時のリクエスト数、許容遅延を記載します。さらに、データ増加量、保持期間、読み取りと書き込みの比率も示します。
- キー候補：委託先に複数案を出してもらいます。
- 実測値：委託先がサンプルデータでRUとP95レイテンシーを測定し、提出します。
測定結果を受け取ると、提案を同じ数値で比べられます。
Azure Cosmos DBの発注形態の選び方
要件が固まっていない場合は、PoCや要件定義を先に発注し、仕様が確定したら開発を発注する段階発注が適しています。
業務要件、画面、連携先、受入条件まで確定している小規模案件では、一括発注も選べます。ただし、Cosmos DBのデータモデルは初回から固定しすぎないことが大切です。
PoC・要件定義を先に発注するケース
既存のRDBやMongoDBから移行する場合は、本番システムの前に代表データと主要クエリで小さく検証します。その際、合格基準を先に決めておくと、技術面と月額上限の両方を判断できます。
- 性能：キーの偏り、毎秒のリクエスト数、P95応答時間の測定。
- 費用：読み取り・書き込みのRUの確認。
- 継続性：障害時の復旧とデータ照合の可否。
要件定義では、業務フローとデータ項目一覧、アクセスパターンを成果物としてまとめます。API一覧と非機能要件、移行方針も入れます。さらに、概算費用と今後の開発計画を加えます。
要件定義を省いて費用を抑えようとすると、後半でパーティションキーや権限設計をやり直すことになり、結果として開発費が増える可能性があります。
一括発注・段階発注・内製併用の使い分け
発注形態は、要件の確定度や社内の運用体制に応じて選びます。
- 一括発注：窓口と責任範囲をまとめ、納期と予算を管理する。
- 段階発注：企画・PoC、基本設計、開発・移行、運用改善に分け、検証結果を次の条件に反映させます。
- 内製併用：自社にAzure運用担当者がいる場合の、業務要件と受入の自社担当。
要件変更が多い一括発注では、変更管理の手続きが増えます。一方で、内製併用では委託先にデータモデリングやアプリ開発を依頼できます。IaCや負荷試験も委託できます。
発注前に、RACIのような役割表で、自社が判断する範囲、委託先が実装する範囲、障害時の意思決定者を書き出します。
RFPと要件整理でAzure Cosmos DBの発注条件を固める進め方
RFPは、技術用語を並べる資料ではなく、委託先が同じ前提で提案と見積を出すための発注条件書です。
まず、現状の業務と解決したい課題、対象ユーザーを記載します。次に、対象データと連携するシステム、希望時期を示します。そのうえで、予算の考え方と提案に求める成果物も書いておきます。
書けない項目は、未確定事項として明示します。そこで、提案側に確認事項と前提条件を出してもらいます。
業務要件とデータ要件の書き分け
業務要件では、登録・検索・更新を行う人と、処理結果を使う業務を定義します。一方、データ要件では、ドキュメントの単位や必須項目を整理します。
- 更新と規模：更新頻度、1件あたりのサイズ、データ増加量を記載します。
- 保持と削除：削除や匿名化の条件を整理します。
- 操作単位：「顧客を検索する」「注文と明細を同時に読む」といった操作ごとに分けます。
Cosmos DBではアクセスパターンがデータモデルを左右します。そのため、RFPに「大量データに対応」とだけ書くと、各社が異なる前提で見積もります。
通常時とピーク時の同時利用者数、ピーク倍率を数値で記載します。さらに、1日の読み書き回数と許容応答時間も数値にします。
まだ測れない数値は、現行ログの調査を要件定義に含めます。そのうえで、推定値と実測値を区別して管理します。
非機能要件・セキュリティ・データ所在地の決め方
非機能要件には、可用性と許容停止時間を含めます。さらに、RTOとRPO、バックアップ保持期間を決めます。障害通知や監視時間、性能、拡張性も記載します。
複数リージョン、マルチリージョン書き込み、強整合性では、設計と料金の条件が変わります。そのため、非機能要件を後回しにせず、構成に応じて確認します。
- 可用性：複数リージョンなどの条件を満たす場合、99.999%の可用性SLAが示されています。
- セキュリティ：個人情報や機密情報の扱いに応じた対策をRFPに含めます。
- 所在地：データを置くリージョンを決めます。
Microsoft Learnが示すSLAが自社構成に適用されるかは、見積時に確認します。
個人情報や機密情報を扱う場合は、日本リージョンへの限定や公開ネットワークの停止をRFPに盛り込みます。具体的には、Private Endpoint、Microsoft Entra ID、Managed Identityを記載します。さらに、Key Vaultや監査ログ、バックアップ復元テストも含めます。
Microsoft Learnは、公開アクセスの制限、マネージドIDやロールベースアクセス制御の利用、復元手順のテストを推奨しています（出典：Microsoft Learn「Secure your account」、2026年）。
RFPに含めるデータ移行と受入条件
既存システムからの移行では、移行元データの品質が費用と納期を左右します。そのため、発注者側で重複や表記揺れ、欠損を確認します。さらに、不要な履歴と個人情報の保存期間も確かめます。
- 作業分担：クレンジング、変換、移行、照合、切り戻しの担当者を決めます。
- 発注者の準備：マスタ整備やデータ確認を担う部署と期限を明記します。
- 受入テスト：性能はAPI応答時間とピーク時エラー率、データは照合と復元、運用は権限・監視・障害連絡を確認します。
発注者の準備が遅れると、委託先だけでは作業を完了できません。
納品物には、IaCやソースコード、API仕様書を含めます。さらに、データモデルとインデックス方針、RU測定結果も納めます。運用手順と障害訓練の記録も加えます。これにより、外注後の属人化を防げます。
Azure Cosmos DBのシステム開発に合う契約形態の選び方
契約形態は、成果物と責任を明確にするか、要件変更に柔軟に対応するかで選びます。また、Cosmos DBは負荷試験やデータ移行の結果で設計を調整する場合があります。そのため、工程ごとに契約を組み合わせる方法が現実的です。
請負契約で固定しやすい範囲
請負契約は、合意した成果物を完成させ、納品・検収する範囲に向いています。
- 適する工程：画面仕様、API仕様、移行手順、テスト項目、受入基準が固まった工程です。
- 契約で定める点：成果物、納期、検収条件、瑕疵対応を契約書と仕様書に記します。
「Cosmos DBを使ったシステム一式」のような曖昧な表現では、どこまでを完成とするかで認識がずれます。
納品物と検収項目には、RU最適化や障害訓練、データ照合を含めます。運用引き継ぎも、検収項目に入れます。さらに、仕様変更時の追加費用と納期変更の扱いを決めておきます。
準委任契約で柔軟に進める範囲
準委任契約は、専門家の作業や技術支援を一定期間依頼する形に向いています。
- 適する工程：要件定義、アーキテクチャレビュー、PoC、データモデリング、性能検証です。
- 依頼時の合意：作業内容、稼働時間、報告方法、成果の定義を明確にします。
準委任であっても成果物は残るため、期間の終わりに何が残るかを決めておきます。たとえば、検証レポートや設計判断の記録、課題一覧があります。次工程の見積や、ソースコードと設定の管理場所も含まれます。
委託先に任せきりにしないよう、自社のプロダクト責任者が優先順位を決める体制も必要です。
段階ごとの契約の組み合わせ
工程に合わせて、要件定義とPoCは準委任、仕様確定後の開発と移行は請負、リリース後の監視改善は保守契約に分けます。
- 要件定義・PoC：準委任契約。
- 開発・移行：仕様確定後の請負契約。
- リリース後：監視改善の保守契約。
工程ごとの責任が分かれるので、PoCの結果を見て本開発を縮小したり延期したりできます。
契約書では、再委託の事前承認と個人情報の取り扱い、インシデント報告期限を確認します。知的財産権と秘密保持も、契約書に記します。加えて、アカウント名義とソースコードの引き渡し、契約終了時のデータ返却・削除を定めます。
個人情報を委託する場合、委託先の安全管理措置や再委託先の監督を確認します（出典：個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年確認）。
Azure Cosmos DBのシステム開発費用相場とコストの内訳
費用は、開発会社へ支払う初期開発費と、Azureへ支払うクラウド利用料に分けて考えます。
内訳は、要件定義からテスト、Azure構築、監視、運用引き継ぎまでの工程ごとに分けます。内訳が不明確だと、安い見積でも後から追加費用が発生しがちです。
規模と工程で変わる開発費の目安
次の数字は、Azure利用料を除いた業務システム開発の概算レンジです。Cosmos DB専用の公表市場統計ではなく、一般的な業務システムの費用・工程データに、Cosmos DB固有の設計・検証・移行・運用を加味した推定です。
- PoC・小規模API：100万〜300万円程度です。
- 小〜中規模：認証、管理画面、外部API、移行、監視を含み500万〜1,500万円程度です。
- 対象機能：マルチリージョン、Change Feed、イベント連携、障害訓練、厳格な権限管理を含む案件は1,500万〜5,000万円程度です。
- 大規模移行・基幹案件：既存DBからの大規模移行や複数部門・複数システム連携を含む場合、5,000万円〜数億円になる可能性があります。
期間の目安は、PoCで1〜2か月、小〜中規模で3〜6か月です。さらに、高可用性や複数連携では6〜12か月、大規模移行では12〜24か月以上です。
金額は、機能数や画面数、外部連携数で変わります。移行データ量や同時接続、データ所在地も影響します。RTO・RPOと既存システムの品質も、金額に関わります。
概算は、一般的な業務システムの費用レンジと、要件定義10〜15%、開発30〜40%、テスト15〜20%、保守年10〜20%の比率を参考にしています。
個別案件の確定金額ではありません（出典：社内NotebookLM Q&A「業務システム全般_11」、2026年）。
RU・保存・リージョンで変わるAzure利用料
Azure Cosmos DBの利用料は、スループットと保存データ、インデックスで決まります。リージョン数やバックアップ、可用性ゾーンも関わります。加えて、データ転送も料金に影響します。
- 手動プロビジョニング：設定したRU/sに基づく課金。
- Autoscale：時間ごとの最大RU/sに基づく課金。
- サーバーレス：消費したRUに基づく課金。
RU/sはスループットの単位です。Azure料金計算ツールでは、リージョン、API、スループット、ストレージを分けて入力します。
Microsoft Learnの例では、500 RU/sを100 RU/sあたり毎時0.008米ドルとして計算しています。その場合、730時間では29.20米ドル／月です。
サーバーレスの例は、月2,000万RUで5米ドル、2億5,000万RUで62.50米ドルです（出典：Microsoft Learn「Plan and Manage Costs」、2026年）。
これらは説明用の金額で、実際の料金はリージョンや契約、為替で変わります。保存やバックアップ、通信、割引でも変わります。
開発・検証環境では、対象サブスクリプションの1アカウントに限り、無料枠が適用される場合があります。無料枠の内容は、1,000 RU/sのプロビジョニング済みスループットと25GBのストレージです。ただし、無料枠はサーバーレスには適用されません（出典：Microsoft Learn「Lifetime Free Tier」、2026年）。
PoCと本番の構成は混同せず、本番予算は負荷試験後の実測値で見積もります。
保守・監視・追加改修の年間予算
ランニングコストには、Azure利用料のほか、監視と障害対応が含まれます。さらに、バックアップ復元テストと、OSやライブラリの更新も必要になります。そのほか、脆弱性対応や追加改修、問い合わせ対応も費用に入ります。
- 保守費の目安：年間で初期開発費の10〜20%程度から検討できます。
- 手厚い対応：24時間監視や即時対応は別途見積もりが必要です。
たとえば初期開発費が1,500万円なら、保守費の起点は年150万〜300万円程度、月額では約12.5万〜25万円程度です。
保守費は保守範囲の比率から出した目安で、特定の会社が提示する金額ではありません。見積書では、月次報告や監視対象、障害一次切り分けを分けて確認します。さらに、復旧支援と軽微改修の時間、追加作業の単価も個別に見ます。
Azure Cosmos DBの委託先選定と見積比較のポイント
委託先は、Azureの利用経験だけでなく、Cosmos DB固有のデータ設計を担えるかで選びます。RU最適化や移行、障害訓練、運用監視まで任せられるかも見ます。
Microsoft Learnには、Cosmos DBのNoSQL移行やアプリ開発に対応するパートナー一覧があります。ただし、掲載は案件の成功や自社案件への適合を保証するものではなく、一覧も更新されます（出典：Microsoft Learn「Azure Cosmos DBへの移行およびアプリケーション開発パートナー」、2026年）。
本番実績と担当者の経験
「Azure案件があります」という説明だけで判断せず、Cosmos DBの本番利用経験を確認します。
- 設計経験：選んだAPIとパーティションキーの決め方を聞きます。
- 性能管理：ピーク時のRUやレイテンシーの管理方法を確認します。
- 移行経験：移行元、データ量、停止時間、並行稼働、照合、切り戻しを質問します。
提案書に実績が書かれていても、実際に担当するエンジニアが同じとは限りません。そのため、面談にはデータモデリング担当やアプリ担当、インフラ・セキュリティ担当、運用責任者に参加してもらいます。
委託先には、想定するデータモデルと障害時の判断を説明してもらいます。
公開できない事例は、社名を無理に求めず、規模、課題、設計判断、結果を匿名化して確認します。
同じ前提と内訳での見積比較
複数社には、同じデータ量や画面数、外部連携数を前提にしたRFPを渡します。リージョン要件とテスト範囲も、同じ条件で揃えます。
- 工程別内訳：要件定義とPoC、設計と開発、Azure構築と移行、テストとリリース、教育と保守に分けます。
- 工数と単価：各工程の人月または工数、単価を確認します。
Azure費用は、開発会社の費用とは分けて提示してもらいます。そのうえで、RU/sやAutoscaleの最大値、ストレージの前提を記載してもらいます。さらに、リージョンやバックアップ、転送、周辺サービスの前提も書いてもらいます。
監視、移行、性能改善、運用設計が抜けた見積は比較できません。ただし、高い見積でも、納品物とリスク対策が具体的なら、総保有コストが下がる場合があります。
過剰カスタマイズとロックインのリスク
Azureの標準機能で解決できる課題に独自機能を増やしすぎると、開発費と保守費が膨らみます。
- 構成の必要性：使わない高可用性構成や過剰な自動インデックスを避けます。
- クエリと機能：不要なクロスパーティションクエリや要件のないAI機能に注意します。
- 提案の根拠：必要性、代替案、将来拡張の条件を説明してもらいます。
ロックイン対策として、Azureアカウントは発注者名義にします。ソースコードやIaC、設計書は、自社で保管します。テストデータや監視設定、運用手順も、自社の手元に残します。
別サービスへの移行を完全に保証させる必要はありません。ただし、データエクスポートやAPIの責任範囲は決めておき、契約終了時の支援や認証情報の返却・削除も定めます。これにより、委託先の変更に備えられます。
発注後のテスト・データ移行・運用引き継ぎの進め方
発注後は、発注者が受入判定できる状態を作ります。単体・結合テストに加えて、RUやP95レイテンシー、ピーク負荷を確認します。
さらに、障害とバックアップ復元、権限と監査、移行データの照合も確かめます。そのうえで、運用担当者が手順を実行できることまで検証します。
PoCと負荷試験での数値の確認
負荷試験では、平均値だけでなくピーク時のRU消費やP95・P99の応答時間を記録します。加えて、スロットリングやエラー率、パーティションごとの偏りも残します。
- 実データに近づける：実利用に近いデータサイズとクエリで試験します。
- 利用者数だけに頼らない：想定ユーザー数だけを入力した試験にはしません。
Cosmos DBの料金や性能は、アクセスパターンで変わります。
2025〜2026年に注目される統合ベクトルストアを使う場合も、AI機能の実装前に元データの表記揺れや重複、更新責任、評価データを整理します。Microsoft Learnによると、Cosmos DB for NoSQLではJSONデータと埋め込みを同じ場所に保存でき、DiskANNなどのベクトルインデックスも利用できます。
量、次元数、検索精度、RU、更新頻度をPoCで確認してから本番機能にします（出典：Microsoft Learn「Integrated Vector Store」、2026年）。
移行リハーサルと切り戻し
移行の順番と切り戻しを事前に試し、所要時間と担当者を確認します。
- サンプル移行と全量移行を試し、所要時間と担当者を記録します。
- 差分移行後にデータを照合し、アプリ接続を切り替えます。
- 旧環境への切り戻しを、リハーサルで確かめます。
停止できない業務では、並行稼働やChange Feedなども候補になります。その場合、整合性と重複排除の方法を事前に決めておきます。
移行完了の判定は、総件数だけでなく、重要項目や更新日時、関連する状態、個人情報のマスキングを照合して行います。さらに、移行後に業務部門が確認する画面や帳票を決め、問題があった場合の切り戻し期限も設定します。
特に、発注側のデータ担当者が検証に加わらないと、技術的には移行できても業務上の欠損を見逃しかねません。
運用引き継ぎと費用管理
運用開始後は、利用状況と安全性に関わる項目を継続して確認します。
- 利用状況：RU消費、ストレージ、スロットリング、エラー率、P95レイテンシー、パーティションの偏りを監視します。
- 保護状態：バックアップ状態と権限変更の監視。
- 予算超過：Cost Managementで予算とアラートを設定し、Autoscaleの最大値や複数リージョンの追加による超過を通知します。
引き継ぎでは、手順書を読むだけで終わらせず、発注者の担当者にアラート確認とログ調査、バックアップ復元を実行してもらいます。さらに、アクセス権変更と障害連絡も担当してもらいます。
委託先との保守契約に、月次レビューや性能改善の提案、Azureサービスの更新確認、緊急時の連絡先を含めておけば、納品後も安定して運用できます。
よくある質問（FAQ）
Azure Cosmos DBの発注では、技術選定だけでなく、費用や契約、移行、運用の責任分担がよく質問されます。そこで、特に重要な質問への回答を、発注前の判断に使える形でまとめます。
Azure Cosmos DBのシステムを外注するといくらかかりますか？
PoCや小規模APIは100万〜300万円程度、小〜中規模の業務システムは500万〜1,500万円程度が概算の起点です。
マルチリージョンや大規模移行は、1,500万〜5,000万円程度から数億円まで広がる場合があります。幅が広いぶん、見積は要件定義、移行、テスト、Azure構築、保守を分けて取得します。
請負契約と準委任契約はどちらを選べばよいですか？
要件と成果物が固まっている開発・移行工程は請負契約、調査やPoC、要件定義のように結果を見ながら進める工程は準委任契約が合いやすいです。
実務では、要件定義を準委任、仕様確定後の開発を請負、運用を保守契約に分ける段階的な組み合わせが使いやすいです。
Azure Cosmos DBの委託先は何を基準に選べばよいですか？
Cosmos DBの本番実績や、パーティションキーとRUの設計力、既存データの移行経験を確認します。あわせて、Azureのセキュリティと監視、障害訓練、納品物の範囲を見ます。
提案書の会社名や認定だけで判断せず、担当エンジニアに、具体的な設計判断や負荷試験、失敗時の対応を説明してもらいます。
既存データベースからAzure Cosmos DBへ移行できますか？
移行は可能ですが、単純なコピーではなく、データモデルとパーティションキー、クエリを見直します。インデックスや整合性、アプリの接続方式も、あわせて検討します。
移行は、サンプル移行と本番リハーサルを行い、データ照合や差分反映、切り戻し、業務部門の受入まで含めて計画します。
まとめ
発注前に決めるべき要点
Azure Cosmos DBを採用する理由と、Cosmos DB以外が適する処理を整理します。
- 設計前提：アクセスパターン、パーティションキー、RU/s、整合性、リージョンをRFPに記します。
- 運用・移行：RTO・RPO、セキュリティ、移行対象を整理します。
未確定事項が多ければPoC・要件定義から段階発注します。確定した開発範囲は請負、検証や専門支援は準委任に分けます。
見積では、開発費とAzure利用料を分けます。加えて、初期費用と保守費、移行と運用引き継ぎも分けて見ます。さらに、実績とあわせて、担当者の設計力と納品物も確認します。
最初の一歩は実測できるPoC
大規模な本番開発の前に、代表データと主要クエリで検証します。
- 測定項目：性能、RU、月額、移行、障害復旧を確認します。
- 構成と予算：測定結果をもとに見直し、過剰なカスタマイズや予想外の追加費用を抑える。
確認項目を質問票にまとめ、提案の前提と費用、契約、体制、受入条件を同じ書式で提出してもらいます。
自社の業務とデータに合うパートナーを選び、納品後も自社で運用判断できるシステムを構築します。
▼全体ガイドの記事
・Azure Cosmos DBのシステム開発の完全ガイド
▼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を創業。