相談する

Capacitorのシステム開発の発注/外注/依頼/委託方法について

Capacitorのシステムを発注するときは、既存Webの資産を洗い出し、端末機能をPoCで検証します。そのうえで、同じRFPで委託先を比べると、追加費用や手戻りを抑えやすくなります。

全体像は、Capacitorのシステム開発の完全ガイドもあわせてご覧ください。

▼全体ガイドの記事
・Capacitorのシステム開発の完全ガイド

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

Capacitorのシステムを発注する前に知るべき全体像

発注範囲をWeb画面と業務フロー、端末機能、サービス運用基盤の3層に分けた図です。
画面の外側にある端末連携や運用基盤も、見積もりの対象になります。

Capacitorの発注では、画面を作る会社を探すだけでは不十分です。Webフロントやネイティブプロジェクトは、バックエンドや外部サービスと連動します。ストア運用までつながっているため、どこまでを委託するかを最初に決めておきます。

Capacitorの役割と仕組み

Capacitorは、Webアプリをネイティブアプリの容器で動かし、必要に応じて端末機能を呼び出す基盤です。UI部品やデータベースそのものではありません。

公式資料では、Web技術で作ったアプリをiOSやAndroidで動かすネイティブランタイムと説明されています。また、React、Vue、Angular、Svelteなどから、Plugin API経由でSwiftやJava・Kotlinの機能を使えます（出典: Capacitor公式ドキュメント、2026年確認）。

  • 既存資産：レスポンシブ画面とAPIは再利用できる可能性があります
  • 追加実装：複雑な業務ロジック、端末内同期、特殊なBluetooth接続は、別途検討が必要です
  • 実装範囲：WebとSwift・Kotlinのネイティブ層を分けて定義します

発注前に分けるべき3つの層

発注範囲を見積もるには、機能を次の3層に分けて整理します。

  • Web画面と業務フロー：ログイン、検索、申請、承認、帳票表示
  • 端末機能：カメラ、バーコード、GPS、通知、Bluetooth、ファイル保存
  • サービス運用基盤：API、認証、データベース、管理画面、監視、ストア申請

たとえば、現場報告アプリなら、報告の入力はWeb画面、写真の撮影はネイティブ連携です。通信断時の一時保存はWebと端末ストレージ、承認結果の反映はAPIと業務ルールに関わります。

この分解によって、画面数では見えない工数が明確になります。一方で、分けずに発注すると、開発後にオフライン対応や権限管理が加わり、納期と予算が膨らみやすくなります。

Capacitorのシステムの発注形態の選び方

発注形態は、目的と社内に残したい開発能力で決めます。要件が固まらず、業務整理から任せたい場合は、一括支援が候補になります。

技術検証から始める場合は、先にPoCを発注します。そのうえで、要件が定まった段階で本開発を依頼すると、検証結果を判断に活かせます。

企画・要件定義から一括で発注する方法

一括発注では、委託範囲と社内で確認しておく点を先に整理します。

  • 委託範囲：課題整理、方式・画面・API設計、開発、テスト、公開、保守
  • 窓口：社内の経験者が少ない場合も、責任範囲を一社に集約しやすい形です
  • 納品物：独自PluginのソースとCI/CD設定の引き渡しも確認します

福井県民生活協同組合のハーツアプリは、企画・要件定義やUI設計を含む公開事例です。ハイブリッドアプリやAPI・CMS、インフラまで含み、運用保守も範囲に入っています。アプリ単体ではなく、サービス全体を見て発注する際の参考になります（出典: 株式会社ゆめみ公開事例、2026年確認）。

発注者側では、まず業務の優先順位と対象ユーザーを決めます。次に、個人情報の扱い、納品物の所有権、公開後の運用担当を決めておくと、見積の前提がそろいやすくなります。特に、独自PluginのソースやCI/CD設定が納品対象外だと、将来の乗り換えが難しくなります。

請負・準委任・ラボ型の使い分け

契約形態は、要件の不確実性と社内の役割に合わせて選びます。

  • 請負：完成機能と納期を合意し、成果物の受領を重視します
  • 準委任・ラボ型：発注者も開発チームに関わり、週ごとに仕様や優先順位を変えます
  • 社内体制：ラボ型では仕様決定と品質確認の担当者が必要です
  • 組み合わせ：初期検証は準委任か限定請負、本開発は請負、公開後は準委任も選べます

Capacitorのシステムでは、最初から全機能の完成形を決めにくいことがあります。理由は、カメラや通知、既存APIの制約、オフライン同期の複雑さが、実機検証で初めて分かる場合があるからです。

PoCを先に発注するケース

PoCでは、確かめる範囲と後工程で再利用する成果物を、発注時に決めておきます。

  • 検証範囲：主要業務の1画面、ログイン、API通信、カメラまたはバーコード、実機配布
  • 動作確認：WebViewの操作感、権限許可、通信断からの復旧、古い端末、Plugin対応
  • 成果物：Capacitor版、Plugin、未解決制約、量産工数、別方式の条件
  • 再利用：本開発向けのソースコード、環境構築手順、検証結果も納品

検証対象には、実業務で難しい操作を選びます。見た目だけのサンプルでは、その難しさが分かりにくいためです。

ポイント

要件が固まっていなければ一括支援を、技術面に不安があればPoCを先に発注することを候補にします。社内に開発の力を残したいかで、その後の進め方が変わります。

RFP・要件整理の進め方

RFPは、発注先が同じ条件で提案と見積を出すための資料です。RFPには、現行業務、利用者、優先機能を書きます。さらに、既存資産、非機能要件、納品物、保守条件も整理しておきます。

要件定義を軽く扱うと、後半の仕様変更が増えて費用が膨らみやすくなります。そのため、発注前の整理に時間をかけておきます。

現場の言葉で整理する業務要件

業務要件は、現場で使われている言葉のまま、次の観点で書き出します。

  • 業務の流れ：誰が、いつ、どこで入力・確認し、次の業務へ何を渡すか
  • 利用者と目的：利用者別の権限を分け、紙・Excel・電話の作業と測定指標を記録
  • 標準化と対象範囲：部署別の手順を整え、アプリ化する業務と残す業務を決定

利用者は営業担当、現場作業者、管理者、承認者などに分けます。目的は、入力時間の短縮や転記ミスの削減など、測定できる指標にします。

部署ごとに業務が異なる場合は、先に標準手順を決めます。標準化しないと例外処理が増え、画面・権限・テストも複雑になります。そのうえで、Capacitorを採用する前に、アプリ化する業務と残す業務を決めておきます。

技術要件と非機能要件の分け方

RFPでは、技術要件と非機能要件を分けて記載します。

  • 技術要件：対象OS・端末、Capacitorのメジャー版、フロントエンド。API、認証、Plugin、外部サービスも対象です
  • 端末動作：権限拒否、オフライン、バックグラウンド時の挙動。独自PluginのOS別代替操作も決める
  • 非機能要件：起動・応答時間、同時利用者数、可用性、バックアップ。監査、暗号化、脆弱性、障害連絡も対象です

個人情報や顧客情報については、端末内に保存するデータと保存期間を定義します。削除方法や、ログに残せる項目も決めておきます。特に、Capacitorはネイティブ機能にアクセスするため、秘密情報をWebアプリと同じ感覚で保存しないようにします。

RFPに含める成果物と見積条件

複数社の提案を比べるには、RFPの内容、見積項目、納品物をそろえておきます。

  • 要件資料：画面、業務フロー、権限、API・外部システム。データ、端末、テスト、リリース時期も挙げます
  • 既存資産：ソースコードの有無、画面対応、認証、API仕様、開発環境、障害履歴を共有
  • 見積項目：初期開発、要件定義、PoC、申請。クラウド、外部サービス、年間保守、追加改修単価も並べます
  • 納品物：コード、設計・API仕様、Plugin、テスト結果。証明書手順、CI/CD、運用マニュアルも含めます
  • 資料不足時：調査や洗い出しを見積の前工程として分け、前提条件と除外事項もそろえます

記載がない提案は比べにくいため、注意が必要です。

ポイント

RFPは、どの会社が読んでも同じ前提で提案と見積を出せる内容かどうかで確かめます。資料が不足している段階では、調査を見積の前に分けて進めると、前提のずれを抑えられます。

契約形態と責任分界の確認点

契約形態は、成果物の完成責任と仕様変更への柔軟性のどちらを重視するかで変わります。さらに、開発費だけでなく、公開後の責任も決めておきます。特に、OS更新、ストア審査、第三者Pluginの不具合について担当が曖昧だと、公開後にトラブルになります。

請負契約で固定する範囲

請負契約では、完成範囲と変更時の扱いを明確にします。

  • 完成条件：画面・機能、対応OS・端末、テスト基準、納期、検収方法を定める
  • 適する案件：要件が固まった本開発や、期限内に決まった機能を出す案件
  • 変更管理：追加費用、軽微な修正、納期延長、受入テスト回数を定め、条件は契約または別紙で定義します
  • 更新保証：CapacitorやPluginの更新を無償保証に含むか確認する

準委任契約で決める範囲

準委任契約では、一定期間の作業や専門人材の提供を前提に、発注者と開発会社が優先順位を変えながら進めます。そのため、作業範囲と発注者の役割を、あらかじめ決めておきます。

  • 適する作業：一定期間の作業、人材提供、PoC、コード調査、継続開発、公開後の改善
  • 契約条件：成果物完成を一律保証しないため、作業、稼働時間、担当、レビュー、報告、品質確認を明記
  • 発注者の役割：業務責任者と意思決定者を置き、仕様・受入・優先順位を決める
  • 運用：週次レビュー、月次予算確認、課題管理表を組み込む

決める人が曖昧なままだと、チームは稼働しているのに、仕様や受入が定まらないまま進むおそれがあります。

契約書に入れる責任分界の項目

契約書では、責任範囲と管理者を項目ごとに分けて書きます。

  • 資産・権利：Web・API改修、iOS・Androidコード、Pluginソース、第三者ライセンスの範囲
  • アカウント：Apple・Googleの管理者と署名鍵の保管者
  • 事故対応：漏えい、誤送信、障害、審査却下、OS更新後の不具合に対する初動と費用
  • 保守・更新：OS・SDK・Capacitor・Plugin更新を含むか、別見積の対象と期限

2025年12月発表のCapacitor 8では、新規iOSプロジェクトのSwift Package Managerが標準となりました。Androidでも、edge-to-edge対応が強化されました。

既存Pluginによっては、追加作業が生じることがあります。そのため、メジャー更新の別見積では、対象と判断期限を定めておきます（出典：Ionic公式「Announcing Capacitor 8」、2025年12月）。

ポイント

完成責任を重く見るなら請負、仕様を変えながら進めるなら準委任を候補にします。どちらの場合も、公開後の担当範囲を契約書に書いておきます。

Capacitorのシステム開発費用・相場の目安

PoC・アプリ化から大規模まで、4つの規模別に初期開発費の目安を横棒で示した図です。
規模が上がるにつれて、予算レンジも段階的に広がります。

Capacitorはオープンソースのため、ライセンス料が費用の中心ではありません。費用は、既存Web資産の活用度や画面・業務機能の量で変わります。

ほかにも、API連携、端末機能、同期が費用に関わります。検証端末、申請、保守も、見積の対象になります。

ここで示す金額は、Capacitor専用の公的な価格表ではありません。国内BtoBアプリ開発の公開相場と要件をもとにした、予算取りの目安です。

規模別の初期開発費と期間の目安

初期費用と期間は、既存Webの活用度、機能数、連携先に応じて変わります。検証範囲によっても変わります。

  • PoC・アプリ化：既存Webを包み、ログイン・数画面・ストア提出を検証。150万〜500万円程度、1〜3か月
  • 小規模：10〜20機能、API認証、写真・通知、簡易管理画面。500万〜1,500万円程度、3〜6か月
  • 中規模：20〜50機能、外部・基幹連携、権限、帳票、運用設計。1,500万〜3,000万円程度、6〜12か月
  • 大規模：複数連携、オフライン同期、Plugin、厳格な監査、多数端末の検証では、3,000万〜8,000万円以上、12〜18か月以上になることがあります

上記の金額と期間は、既存のAPIと認証が使え、業務ロジックの作り直しが少ない場合を想定しています。要件定義の前の予算の幅を示したもので、Capacitorを使えば必ずこの金額になるわけではありません（出典: 株式会社ripla「BtoBアプリ開発の進め方」、2026年確認）。

機能数だけに頼らない見積の内訳

見積は、工程別の内訳と再利用による差を見て比べます。

  • 初期費用の工程：要件・業務整理、UI/UX・設計、Web、ネイティブ、API。結合・実機テスト、申請、移行・教育も含まれます
  • 配分例：要件定義15〜20%、設計20〜25%、開発30〜35%、テスト20〜25%、管理5〜10%
  • 再利用時の差：Web開発比率が下がる場合があり、端末検証やAPI改修の比率が上がることもあります
  • 工数要因：「一式」と書かれた工程の中身を確かめます。基幹連携、権限、同期、写真圧縮、Pluginで工数は増えます

ここに挙げた工程配分は、公開情報の例です（出典: 株式会社ripla「BtoBアプリ開発の進め方」、2026年確認）。

既存API、デザインシステム、認証、テスト自動化が整っていれば、再利用で費用を抑えられる可能性があります。

保守・クラウド・外部サービスの費用

運用費用は、サービス料金、利用規模、保守範囲に分けて見積もります。

  • 従量課金：クラウド、監視、ログ、通知が発生します。地図、SMS、決済も加わります
  • クラウド目安：中規模は月10万〜50万円程度。同時利用者数、画像・動画、バックアップ、環境数で試算
  • 別費用：Apple・Googleの開発者アカウント、脆弱性診断、端末購入費も確認
  • 保守費：初期費用の年15〜20%程度。初期費用2,000万円なら年300万〜400万円程度
  • 保守範囲：OS対応のみか、障害、問い合わせ、改善、Plugin更新、申請まで含むかで変動

保守率は一般的な予算の考え方で、Capacitor固有の定価ではありません（出典: 株式会社ripla「BtoBアプリ開発の進め方」、2026年確認）。

ポイント

費用は既存Web資産の活用度や機能数、連携先で変わります。金額は要件定義前の予算の幅と見て、基幹連携や同期、Pluginの費用も含めて比べます。

委託先の選定と見積比較のポイント

委託先は、Capacitorの知識だけでなく、業務整理から運用まで任せられるかで選びます。技術ブログの経験が、受託実績や保守体制を示すとは限りません。

候補各社には、公開実績、対応工程、担当者の経験を同じ質問で確認します。契約条件も、同じ形で尋ねます。

Capacitorの実績と関与範囲

実績の有無だけでなく、担当範囲も分けて確認します。

  • 開発範囲：既存Web、API・CMS、認証、カメラ・通知・位置情報、Plugin
  • 公開・運用：ストア公開、監視、OS更新
  • 担当体制：担当者の工程、受託可否、再委託、交代時の引き継ぎを確認

ゆめみのハーツアプリ事例のように、フロントエンドだけでなく企画・API・インフラ・運用保守まで公開されている例は、業務アプリ発注の参考になります。

自社プロダクトでの採用実績は技術の実用性を判断する材料ですが、受託できるとは限りません。そのため、担当予定者が過去事例のどこまで関わったかを聞いておきます。

同じRFPで3社程度を比べる方法

同じ条件で提案を比べるため、比較先と提示条件をそろえます。

  • 比較先：同じRFPを3社程度へ渡し、異なる強みの会社を含める
  • 提示条件：必須・任意機能、端末、API、テスト、申請、保守
  • 評価項目：金額、前提、除外項目を横並びにします。納品物、日程、リスク、体制も、同じ表に並べます
  • 会社の強み：SIer、アプリとWebの開発会社、Capacitor・Ionicの専門会社など

BPS株式会社は、ネイティブ、Flutter、React Native、Capacitor、PWAを端末機能や既存Webとの相性で比較します。

同社は、方式を比較して支援する方針を公開しています（出典: BPS株式会社のアプリ開発サービス、2026年確認）。さらに、API・認証・通知・ストア運用も支援対象です。要件に応じて方式を比べられる会社が候補になります。

総額・品質・引き継ぎで見る見積比較

総額、品質、将来の引き継ぎを、次の観点で比べます。

  • 評価表：要件、質問、Plugin経験、実機テスト。API・認証・安全性、申請、保守も評価の対象に含めます
  • 採点：各項目を5段階で評価し、安い見積がテストや保守を除外していないか確かめる
  • 評価項目：納品物、担当体制、費用、納期も表に含める
  • 総所有コスト：5年間のTCOに、更新、追加、運用、問い合わせ、障害、会社変更費を含める
  • 引き継ぎ：コード・設計書の受領とCI/CD・署名鍵の自社管理を確認

TCO（総所有コスト）には、クラウドや外部APIの費用、端末更新も含めます。

ポイント

迷ったときは、業務整理から運用まで一社で任せられるかを基準にします。見積は総額だけで比べず、品質と引き継ぎまで同じ表で並べます。

発注後の失敗を防ぐ検証・セキュリティ・運用のポイント

納品条件に含める項目として、情報保護、セキュリティ試験、Apple要件、Google要件を並べた図です。
4つの領域を納品条件に揃えると、確認漏れを見つけやすくなります。

Capacitorは、Web資産を活かしやすい一方で、ネイティブアプリとして配布します。そのため、Webだけのテストでは不十分です。

通信や端末サイズ、OSの違いを計画に含めます。加えて、権限やバックグラウンドの動作、審査、第三者SDKも確かめる対象です。

PoCと実機テストによる採用可否の判断

実機検証では、業務で使う操作と端末差を確かめます。

  • 業務操作：ログイン、入力、撮影、送信。承認、通知、ログアウトを通常時と通信断で試す
  • 対象端末：複数メーカーのAndroid、世代の異なるiPhone、タブレット、業務用スキャナ
  • 方式の再評価：別方式へ移行した事例の理由も確かめる

別方式へ移行した事例では、WebViewの挙動や画面遷移のもたつき、Plugin制約が理由として公開されています。開発費の増加も、理由に挙がっています。

Capacitorが不適切だという意味ではありません。重い描画や複雑なアニメーション、OS固有の操作、厳しいバックグラウンド要件がある場合は、方式を比べます。React NativeやFlutter、Swift・Kotlinも選択肢です（出典: 株式会社STRACT開発チーム公開記事、2026年確認）。

納品条件に含めるセキュリティとストア要件

納品条件には、次の4つの領域を含めて整理します。

  • 情報保護：認証情報を直書きせず、端末保存、TLS、入力検証、権限、監査ログ、マスキングを確認
  • セキュリティ試験：OWASP MASVS・MASTGのStorage、Auth、Network、Platform、Code、Privacyを参照
  • Apple要件：Capacitorを含む一定の第三者SDKにPrivacy Manifestと署名が必要
  • Google要件：2026年8月31日以降、新規・更新アプリはAndroid 16・API 36以上

公開日が近い案件では、Capacitor、Plugin、Xcode、Android Studioの組み合わせを見積時に固定します。また、審査日程も見積の段階で決めます（出典：Apple Developer「Third-party SDK requirements」、2026年確認／Google Android Developers、2026年7月更新）。

公開後の保守SLAと引き継ぎ

公開後に起きる問題に備え、監視と障害対応、引き継ぎを決めておきます。

  • 監視：クラッシュ率、APIエラー、ログイン失敗、通知・同期失敗、画面利用率
  • SLA：障害重要度、受付時間、一次回答、復旧目標、代替手段、報告期限
  • 更新予定：審査却下や証明書切れに備え、ストア更新カレンダーを作る
  • 引き継ぎ：コード、設計、環境変数管理、ビルド手順。テストアカウント、端末・Plugin、制約、障害履歴も引き継ぎ対象です

秘密鍵は共有範囲を絞り、アカウントの所有者と権限付与の手続きは自社で管理します。

よくある質問

発注では、技術の可否だけでなく、費用、既存Webの再利用、保守範囲も委託先へ確認します。

既存のWebシステムをCapacitorでアプリ化できますか？

レスポンシブ画面、安定したAPI、モバイル向け認証があれば、既存資産を活用できる可能性があります。

カメラ、通知、GPS、Bluetooth、オフライン保存、端末固有SDKに対応する場合は、Pluginやネイティブコードが必要なことがあります。コードとAPIを洗い出し、Webの再利用範囲を調べます。

Capacitorのシステム開発はどのくらいの費用ですか？

既存Webのアプリ化・PoCは150万〜500万円程度です。小規模業務アプリは500万〜1,500万円程度、中規模は1,500万〜3,000万円程度が目安です。

基幹連携、オフライン同期、独自Plugin、多数端末の検証が必要なら、3,000万〜8,000万円以上になる可能性があります。

Capacitor固有の定価ではありません。同じRFPを渡して、要件定義、テスト、申請、保守を含めた見積を比べます。

Capacitorに対応できる開発会社はどう探しますか？

既存Web・API連携、端末機能、独自Plugin、実機テストを確認できる会社を探します。申請、OS更新、障害対応も、担当範囲として確かめます。

同じRFPで、公開実績と担当者の提案・実装経験を聞きます。再委託、納品物、保守SLAも確かめます。

要件によっては、Flutter、React Native、ネイティブ、PWAも比べられる会社が望ましいです。

公開後の保守も同じ会社へ依頼するべきですか？

初回リリース後の障害や、OS・SDK・Plugin更新まで任せたい場合は、開発会社に保守を依頼すると、引き継ぎの負担を抑えやすくなります。

保守範囲と料金が曖昧だと、OS対応や審査のたびに追加費用が発生します。そのため、契約では年間保守の対象と別見積の作業を分けます。対応時間や復旧目標、ソース引き渡しも、契約に書いておきます。

まとめ

発注前に固める3つの判断軸

発注前に、既存Webの再利用範囲、端末機能とオフライン要件、公開後の保守担当を決めます。判断軸が明確になると、Capacitorと他のクロスプラットフォーム技術、ネイティブ開発を同じ基準で比べられます。

最初に依頼する調査・相談の内容

最初の相談では、次の内容を開発会社へ伝えます。

  • 相談内容：見積前のWeb・API洗い出し、主要業務のPoC、RFP作成支援から選ぶ
  • 共有情報：対象ユーザー、業務課題、現行Web、端末機能、希望時期。資料が少なくても発注範囲を整理できる
  • 要件整理：Web、ネイティブ、API・運用基盤と既存資産を分ける
  • 予算目安：アプリ化・PoCは150万〜500万円、小規模は500万〜1,500万円、中規模は1,500万〜3,000万円
  • 比較：Capacitor 8・Apple・Google要件を踏まえ、同じRFPで比べると追加費用や手戻りを抑えやすくなります

費用は金額幅の目安です。見積には、API・基幹連携や同期、Pluginを含めて確かめます。実機テストや申請、年間保守も、同じ見積に入れて比べます。

▼全体ガイドの記事
・Capacitorのシステム開発の完全ガイド

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

株式会社riplaの会社HPはこちら

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

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

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