Power Appsのシステム開発は、要件整理から定着までの6つの段階を順に進めると、現場で使い続けられる業務システムになります。
構成の選定や稼働の準備も、各段階に含みます。費用と見積もりの確認点も取り上げるので、全体像は完全ガイドとあわせてご覧ください。
▼全体ガイドの記事
・Microsoft Power Appsのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Microsoft Power Appsのシステム開発の全体像
Power Appsは、業務のデジタル化に使うローコード基盤です。Microsoft 365やPower Automate、Dataverseのほか、Power BIやAzure、Dynamics 365とも組み合わせて使います。
入力画面に加えて、登録データの保存や、条件に応じた承認や通知を組み込めます。結果の集計や管理者の確認までを、一つの業務プロセスとして組み立てられます。
業務システムとして使う価値
Power Appsは、分散した業務の連携と処理状況の把握に役立ちます。
- 業務の流れ：入力、判断、承認、対応、集計までを一続きに設計する。
- 適用範囲：入力、申請、現場閲覧の画面として使う範囲。
- 既存基幹の維持：大量・高頻度処理、複雑な制御、特殊帳票は正本として残す。
たとえば、設備点検では、現場担当者がスマートフォンから結果と写真を登録できます。異常時はPower Automateで通知し、修繕が終わるまで管理できます。
処理の結果まで一続きに設計しておくと、導入の効果を測りやすくなります。Power Appsで作る範囲は、基幹システムの役割と分けて考えます。そのため、何を作るかに加えて、作らないものも決めておきます。
キャンバスアプリとモデル駆動型アプリの使い分け
形式は、画面操作の自由度と関係データの管理方法を軸に比べます。
- キャンバスアプリ：画面や操作感を自由に設計できる。
- モデル駆動型アプリ：Dataverseを中心に関係データを管理できる。
キャンバスアプリは、点検や営業報告、訪問記録のように、現場で入力する業務に向きます。在庫確認や写真付き申請も、同じ形式で扱えます。スマートフォンやタブレットで迷わず入力できることを優先する場合に適しています。
少人数の部門で早く試せる一方、画面ごとに処理や権限を足していくと、条件式が複雑になります。その結果、将来の改修やテストに時間がかかることがあります。
モデル駆動型アプリは、Dataverseのテーブルを中心に、フォームやビュー、ダッシュボードを組んで構築します。顧客や案件、設備の情報を、契約や問い合わせも含めて長く管理する業務に適します。
データモデルとセキュリティロールを先に設計できるため、管理業務の標準化や監査を重視する場合に有力な候補になります。画面の自由度よりも、データの一貫性と役割ごとの制御を優先する場合に選ばれやすい形式です。
SharePoint、Dataverse、SQL Serverの選び方
データの複雑さ、管理要件、正本の置き場所をもとに保存先を選びます。
- SharePoint：単純な台帳や部門内申請を小さく始める場合。
- Dataverse：関係データ、監査、細かな権限、将来の拡張を重視する場合。
- SQL ServerやAPI：既存システムに正本がある場合。
販売管理や在庫管理のような業務では、SQL ServerやAPIを通じてPower Appsから参照・更新する構成を検討します。
選ぶ前に、現在のデータ量だけでなく、3〜5年後の利用者数やレコード数も見ておきます。同時更新やバックアップ、監査、他システムからの参照も確認します。
Excelは試作には早く使えます。ただし、同時編集や履歴、権限の管理には限界があります。
見積もりの前に、データの正本と項目の変更者を決め、他システムとの同期や保存期間、削除ルールも決めておきます。後から構成を変えると作り直しになりやすいため、この段階で決めておくと、リスクを抑えられます。
Microsoft Power Appsのシステム開発の進め方
Power Appsの開発は、6つのフェーズを順に進めると、短期導入と長期運用を両立しやすくなります。各段階には、判断基準と完了条件を置きます。
- 要件を整理し、業務課題と完了条件を決める。
- アプリ形式、データ基盤、連携方式を選ぶ。
- データ、権限、連携を設計して開発する。
- 業務シナリオで正常系と例外系をテストする。
- データ移行、教育、障害対応を準備して稼働する。
- 利用状況を測り、運用ルールと改善を続ける。
次の段階へ進む前には、データや権限、業務ルール、運用責任が固まっているかを確認します。画面の作成を先に進めず、各段階の完了を確かめてください。
1. 要件整理フェーズの業務課題と完了条件
画面への要望からは見えにくい業務ルールも含めて、次の観点で要件を整理します。
- 業務棚卸し：紙やExcel、メール、既存システムの業務を、担当者の行動ごとに洗い出す。
- 目的・KPI：申請から承認までの時間短縮、入力漏れの削減、管理者が毎日進捗を確認できること。
- 記録項目：利用者、頻度、入力項目、承認者、差し戻し条件、例外処理、保存期間、個人情報の有無。
- 現場確認：誰がいつ使うか、入力できないと何が止まるか、登録後の判断者、検索情報、二重入力箇所を聞く。
- 完了条件：対象業務、利用者、主要KPI、データの正本、対象外範囲の合意を文書に残す。
2. 選定フェーズのアプリ形式、データ基盤、連携方式
選定では、アプリ形式、データ基盤、既存基幹との接続方式を、一つずつ分けて決めます。
- アプリ形式：現場入力と関係データ管理のどちらを優先するか。
- データ基盤：台帳の単純さや監査・権限要件で選ぶ。
- 接続方式：既存基幹にある正本を踏まえて決める。
現場入力を優先するならキャンバス型、関係データ管理と権限を優先するならモデル駆動型が候補です。
単純な台帳にはSharePoint、監査や複雑な権限にはDataverse、既存基幹が正本ならSQLやAPIを使います。
ライセンス対象者やプレミアムコネクタ、ゲートウェイを比べるほか、API認証やデータ容量も見ます。開発者のスキルと将来の保守担当も、選定の条件に入ります。PoCは2〜6週間程度を推定の目安とします。
PoCでは、入力と検索の流れから承認、通知、権限までを、最小のシナリオで検証します。特に、現場で使えるか、正本を一つにできるか、本番のセキュリティを再現できるかを確認します。
3. 設計・開発フェーズのデータ、権限、連携
設計では画面一覧に加え、データや権限の仕様を決めます。通知や連携、エラー時の処理も仕様に含めます。
- データ：項目、テーブルの関係、入力規則、業務ステータス。
- アクセス：権限ロールと利用者ごとの操作範囲。
- 処理：通知、外部連携、エラー時の動作。
申請システムでは、申請者や所属、内容と、承認者や状態、差し戻し理由、承認日時を、分けて持たせます。
Excelの列をそのまま一つのテーブルに移さず、検索や集計、監査ができる構造にします。さらに、アプリの共有者が全データを見られる権限設計も避けます。
権限と統制には、Microsoft Entra IDのグループや環境、Dataverseのセキュリティロールを使います。行・列レベルのアクセス、条件付きアクセス、DLPも組み合わせます。
閲覧、変更、承認の範囲は、利用者ごとに決めます。開発と検証、本番の環境を分け、SolutionsやPower Platform Pipelinesで変更を移すと、本番の修正を特定の担当者に頼らずに済みます。
4. テストフェーズの正常系と例外系の確認
テストでは、画面が表示されるかだけでなく、申請や連携、利用環境の例外も確認します。
- 申請：差し戻し、再申請、二重登録、承認者不在。
- 連携：権限外閲覧、連携先の停止、タイムアウト。
- 利用環境：添付容量、日付境界、不安定な通信。
Power Automateでは、成功時の動きに加えて、失敗時の通知や再実行を検証します。重複防止と担当者へのエスカレーションも、確認の対象です。
受入テストでは、代表的な利用者に実際の業務を最初から最後まで操作してもらいます。処理時間や入力ミス、確認漏れのほか、問い合わせ内容も記録します。
完了条件は、重大な権限の不備がなく、主要なシナリオが終わっていて、未解決事項の担当者と期限が決まっている状態です。テストデータに個人情報を使う場合は、マスキングと利用後の削除も計画します。
5. 稼働フェーズの移行、教育、障害対応
稼働の準備では、移行の範囲とデータの品質、移行後の照合方法を決めます。
- 移行範囲：旧Excelや紙の対象、過去データの扱い、照合担当。
- データ品質：重複、表記ゆれ、未入力、日付、コード体系。
- ファイル：添付データの保存先。
移行の進め方としては、すべてを一度に移さず、必要な期間と項目に絞る方法もあります。
移行後はサンプルを照合し、利用部門の承認を得ます。リリース時の所有者と環境管理者を決め、問い合わせ窓口や障害時の判断者、切り戻しの方法も明確にします。
利用者には、どの業務をいつからPower Appsで行うか、旧手順をいつ停止するかを伝えます。入力に困ったときの連絡先も案内します。
段階導入では、一部の部門や業務で稼働し、問い合わせと改善点を整理してから対象を広げます。
6. 定着フェーズの利用状況の把握と運用ルール
稼働後は、効果測定と運用体制の点検を続けます。
- 効果測定：業務KPIを確認し、利用ログや現場の声を改善に使う。
- 全社展開：市民開発の自由度とIT部門の統制を両立する。
- 環境運用：管理状態、容量、展開承認を棚卸しする。
確認するKPIには、利用者数や入力完了率、承認時間があります。差し戻しや紙・Excelへの逆戻り、問い合わせ件数も、あわせて見ておきます。
Power BIでは、グラフの数を増やすより、意思決定に必要な指標と更新頻度を決めます。
Microsoft公式のスズキ事例では、Power Apps Premiumを約18,000人分購入しました。さらに、開発者600名以上のコミュニティができたと紹介されています（出典：Microsoft Customer Stories「スズキのPower Apps全社展開」、2025年公開）。
スズキでは、10か月で約1,500アプリに広がりました（出典：Microsoft Customer Stories「スズキのPower Apps全社展開」、2025年公開）。
大規模展開では、アプリ台帳と所有者交代のルールを整えます。命名規則や環境の使い分けを決め、DLPや廃止基準、教育も含めます。
Microsoft Learnは、2026年2月から、Managed Environments未有効のパイプライン対象環境で有効化が始まると案内しています。出典ページは、Microsoft Learn「Admin deployment page – Power Platform」（2026年6月更新）です。
2026年時点では、Power Platform Pipelinesの対象環境にManaged Environmentsを適用する運用も確認します。既存環境についても、管理状態、ライセンス容量、展開承認の手順を棚卸しします。
Microsoft Power Appsの費用相場とコストの内訳
費用は、初期開発費、Microsoftへのライセンス・容量費、稼働後の保守運用費の3つに分けて考えます。以下の開発費は、公式の一律価格ではありません。
ここで示す金額は、リサーチノートで整理した一般的な業務システムの相場と、Power Appsで開発期間を短縮できる可能性をもとにした、記事執筆用の推定レンジです。
実際の金額は、利用人数や要件によって変わります。データ移行や連携、セキュリティ、体制も、金額を左右する要因です。
規模で変わる開発委託費（50万〜2,000万円以上）
開発委託費の推定レンジは、対象業務の規模や構成で変わります。
- PoC・小規模：1業務で50万〜150万円程度。
- 実用アプリ：Dataverseなどを含み150万〜500万円程度。
- 部門システム：複数業務と連携を含み300万〜800万円程度。
- 全社展開：複数アプリや統制を含み800万〜2,000万円以上の可能性。
小規模アプリは、申請、点検、日報など1業務が対象です。SharePointやExcel接続、基本権限、単純な通知を含み、期間は2〜6週間程度を想定します。
現行データの整理や現場ヒアリングが多い場合は、画面作成より準備に時間がかかることがあります。
実用アプリでは、Dataverseや複数画面、承認フロー、Power BIを含み、利用者30〜200人程度での受入テストも行います。
金額を左右するのは、アプリの本数よりも、中身の複雑さです。データ移行の難しさや連携先の数、例外処理が工数を押し上げます。非機能要件や部門間の合意、利用者教育、展開後の支援体制も、工数を増やします。
部門システムには、SQLやAPIとの連携、既存データの移行、ロール設計に加え、環境分離も含まれます。
全社展開では、ALMやDLP、教育が対象になります。監査や監視、基幹連携も含まれます。そのため、安価なPoCの見積もりを、本番システム全体の予算として扱わないことが大切です。
利用人数と契約条件で分けるライセンス費
ライセンス費は、Microsoft公式のグローバル価格と国内参考価格を分けて確認します。
- Microsoft公式：ユーザー単価と大量購入の条件。
- 国内参考価格：契約期間に応じた月額料金。
- 追加費用：本番ライセンス、容量、連携サービスの扱い。
公式価格では、Power Apps Premiumが年払いで1ユーザーあたり月額20米ドルです。
2,000シート以上を購入するプランでは、Power Apps Premiumが月額12米ドルです（出典：Microsoft「Power Apps pricing」、2026年確認）。
これはグローバル価格の表示です。日本での請求額は、契約形態や為替によって変わります。販売チャネルや既存契約、購入規模でも変わります。
NTT東日本の2025年4月以降の法人向け料金表に、Power Apps Premiumが掲載されています。
年間契約の月払いは税込3,462円、月契約は税込3,957円です（出典：NTT東日本「Microsoft 365等料金表」、2025年）。
年間契約の参考価格を100人に適用すると、3,462円×100人×12か月で年約415万円です。これは掲載時点の単純計算で、開発費や他サービス費を含みません。
Developer Planは開発・テスト用です。そのため、本番利用者のライセンス費は無料になりません。
Dataverseの容量は、データベース、ファイル、ログの別に確認します。Power AutomateとPower BIに加えて、AI BuilderやCopilotの扱いも確認します。
Azureやオンプレミスデータゲートウェイも、構成に応じて確認します。
見積もりには、作成者や承認者、閲覧者、外部利用者ごとの人数を記載します。月間処理件数と容量の前提も書いてもらいます。
初期開発費の15〜25％程度を目安にした保守運用費
保守運用では、障害対応と日常管理、継続改善の作業範囲を決めます。
- 日常管理：Power Platformの更新確認、ユーザー追加・削除、権限変更、データ修正、バックアップ、監査ログ確認。
- 監視・改善：フロー監視、軽微な改修、問い合わせ対応。
障害対応も保守運用に含まれます。
一般的な業務システムでは、初期開発費の年15〜25％程度を目安とする考え方があります。24時間監視や厳格なSLA、全社展開、頻繁な改修が必要な場合は、別途増額されます。
要望は最初からすべて盛り込まず、業務効果を測れる最小範囲でPoCを行います。そのうえで、本番化と展開を段階的に進めます。
権限やデータの正本、環境分離、障害時の連絡先は、後から足すと作り直しになりやすいものです。そのため、PoCの段階でも確認します。
削る対象は検証可能な追加機能に限り、セキュリティや運用責任は残します。
Microsoft Power Appsの見積もりを取る際のポイント
「アプリ1本いくら」の金額で比べると、必要な工程が抜けた提案を選んでしまうことがあります。そのため、要件定義から保守までの項目を分け、同じ前提で複数社に依頼します。
ローコード開発の担当範囲に加えて、業務整理やDataverse設計も確認します。API連携やセキュリティ、ALM、内製化支援の範囲も、あわせて見ておきます。
依頼前の業務フローと見積もり前提
依頼前には、対象業務と開発条件を整理します。
- 業務：現行フロー、利用者の役割、画面、データ、承認経路。
- システム：既存システムと移行対象。
- 計画：希望時期と予算の考え方。
仕様書がまだ完成していなくても、現場のExcelや帳票、メール、業務マニュアルを共有すれば、ベンダーは作業を見積もりやすくなります。「必須」「できれば」「対象外」も分けて記載します。
依頼書には、利用者数や同時利用の想定、月間の登録件数を書きます。添付ファイル量や保存期間、連携先も含めます。個人情報の有無や、稼働後の問い合わせ時間帯も入れます。
前提がない見積もりは、安く見えても追加費用につながりやすくなります。金額の比較より、前提条件を比べることが先です。
工程別、ライセンス別、追加条件別の金額内訳
見積書では、開発委託費の工程と成果物を分けて確認します。
- 要件・設計：要件整理、企画、画面、データモデル。
- 開発・連携：Power Apps、Power Automate、Power BI、外部連携。
- 導入準備：移行、権限、環境構築、テスト、教育、リリース。
- ライセンス：利用者区分、契約期間、容量、追加サービス。
- 稼働後：保守の範囲と運用条件。
各項目について、対象範囲や成果物、工数、担当者を書いてもらいます。前提や含まれない作業まで示してもらうと、会社ごとに比較できます。
ライセンスは開発委託費と分け、利用者区分と契約期間を確認します。
Premiumの利用人数を確認し、閲覧者や外部利用者が必要かどうかも見ておきます。Microsoft 365契約の適用範囲、Dataverse容量、Power Automateの費用も確認します。
2026年時点の価格やSKUは変わる可能性があります。販売店の最新見積書と適用期間を保存してください。
技術、内製化、運用から見る開発会社の比較
開発会社は、資格や制作実績に加えて、技術経験や展開計画、内製化後の支援体制から比べます。
- 技術：要件定義、Dataverse、SQL・API、移行、テスト。
- 統制・支援：DLP、環境分離、教育、保守。
- 計画・役割：PoCから全社展開までと内製・外注の分担。
提案では、PoCから全社展開までを段階に分けた計画を出してもらいます。自社とベンダーのどちらが何を担当するかも、明確にしておきます。
担当者が異動しても運用を続けられるように、引き渡しの条件を契約に入れます。対象は、アプリの所有権やSolutions、環境設定、接続情報です。設計書やテスト仕様書、操作マニュアルも含みます。
障害時の一次受付や復旧目標、軽微な改修の範囲を確認します。追加開発の単価や、Microsoftの仕様変更への対応も見ておきます。特定の担当者やベンダーへの依存を避けられるかが、大切な確認点です。
個人情報、権限、障害時の責任分界
個人情報や機密情報を扱う際は、情報管理、委託管理、障害時の対応を見積もりに含めます。
- 情報管理：認証、アクセス制御、ログ、バックアップ、保存、削除。
- 委託管理：委託先、再委託、データの保管場所。
- 障害対応：業務継続、切り分け、手動復旧、旧手順への切り戻し。
個人情報保護委員会は、クラウドサービスでも事業者側の安全管理措置が不要になるわけではないと案内しています（出典：個人情報保護委員会「クラウドサービス利用に関するQ&A」）。
Power Appsの機能を確認したうえで、自社規程と契約に反映します。
Power Automateが失敗したときに業務を続ける人を決めておきます。連携先の障害を切り分ける担当や、データを手動で復旧する方法、停止時に旧手順へ戻す判断も決めます。
セキュリティレビューや脆弱性・権限の確認、障害訓練、運用引き継ぎは、別項目として依頼します。
「開発一式」にまとめてしまうと、重要な作業が含まれているかどうかを比べられなくなります。
Microsoft Power Appsのシステム開発でよくある質問
導入前によくある質問に、開発者や保存先、費用、稼働後の運用の面から答えます。
Power Appsのシステム開発は無料でできますか？
Developer Planは開発・テスト用に無料で使えますが、本番利用者のライセンス費は無料になりません。
Dataverse容量やプレミアムコネクタの費用も発生する場合があります。Power AutomateやPower BI、Azureについても、費用がかかることがあります。
継続して使う場合は、総保有コストを試算します。開発費やライセンス費、容量・連携費に加えて、保守運用費も含めて見ます。
Power Appsの開発は内製と外注のどちらがよいですか？
内製か外注かは、規模、必要な専門性、運用体制で選びます。
- 内製PoC：小規模で、利用者とデータが限られ、担当者がMicrosoft 365に慣れている。
- 経験者へ依頼：個人情報、複雑な権限、基幹API、全社展開、厳格な監査が必要。
- 分担：PoC内製、本番化外注、稼働後の共同運用も可能。
要件定義と設計を外注し、現場担当者が受入と改善に参加する形もあります。
作成の速さより、自社で続けられるかどうかを基準にします。具体的には、データモデルや権限の扱い、障害対応、所有者交代まで見ます。
外注する場合は、設計書やSolutionsの引き渡しと、内製化の範囲を契約に記します。
ExcelやSharePointからDataverseへ移行したほうがよいですか？
移行するかどうかは、保存先の選び方次第です。保存先は、業務の規模やデータ構造、管理要件に合わせて決めます。
- SharePoint：単純な台帳を少人数で扱う場合に始められる。
- Dataverse：関係データ、細かな権限、監査、履歴、複数アプリ利用を重視する場合。
- 正本を参照：既存基幹が正本ならSQLやAPI経由が適することもある。
移行する場合は、不要なデータを整理してから、コードや日付、重複、未入力の状態を確認します。
判断の際は、データ量や同時更新、保存期間を確認します。さらに、重複やバックアップ、連携、将来の利用者数も見ておきます。
全列をそのまま移さず、移行後は利用部門が件数と内容を照合します。
Power Appsで市民開発を進めるときの注意点は何ですか？
市民開発では、試作用と本番データ用の環境を分け、運用ルールを定めます。
- 環境・登録：用途、命名規則、DLP、アプリ登録を決める。
- 権限・連携：所有者交代、権限付与、連携承認の決め方。
- 棚卸し：利用状況と廃止基準を定期的に確認する。
Default環境に重要アプリを集中させたり、個人アカウントだけでフローを所有したりすると、異動や退職後に運用が止まりやすくなります。
全社展開では、現場開発者のコミュニティや教育、相談窓口も用意します。所有者不明や長期間の未使用、高リスクコネクタ、過剰な共有設定を、定期的に確認します。
利便性を保ちながら、リスクに応じてレビューの強度を変えることが定着につながります。
まとめ
Power Apps開発は、要件整理から定着までの6段階を順に進めます。画面作成の速さだけで判断せず、各段階が完了したことを確かめながら進むことが基本です。
データの正本や権限、既存連携を先に決めておくと、本番後の作り直しを抑えやすくなります。例外処理やテスト、運用責任も、早めに決めておくことが大切です。
最初に確認する業務課題、正本、利用者、完了条件
着手時には、対象業務のKPIと対象外の範囲を決め、紙やExcel、メール、既存システムの現行業務を棚卸しします。そのうえで、アプリ形式やデータ基盤、SQLやAPIの利用を選びます。
PoCでは、入力と検索の流れから承認、通知、権限までを、最小のシナリオで検証します。本番化へ進む条件は、数値や合意事項として残してください。
開発費、ライセンス、運用費を分けた比較
開発委託費に加えて、ライセンスや容量、連携を含む総保有コストを比べます。移行や教育、保守運用も、同じ枠で見ておきます。金額は要件や契約条件で変わるため、同じ前提で複数社から見積もりを取ります。
成果物や責任分界、引き継ぎの範囲を確認します。障害対応や内製化後の支援範囲も、あわせて見ておきます。
特に、Power Appsを業務改善の基盤として設計することが、投資効果を高める進め方になります。
▼全体ガイドの記事
・Microsoft Power Appsのシステム開発の完全ガイド
▼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を創業。